tiledbsoma 1.15.0 pre-check

Following our established procedure

osx_64 passed on retry

Let me 'get this green' for pre-check & unblock some things in the dependency chain tonight & I'll definitely do that moving forward

Derp, I needed to do this too
https://github.com/single-cell-data/TileDB-SOMA/pull/3460
-- so I'll re-run this pre-check with (a) that PR once backported to release-1.15 and merged; (b) somacore==1.0.26 here; (c) scipy<0.15 here; (d) tiledb-py moved to tests as long as I can figure it out

@jdblischak https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/237/commits/7cb1d9f8f410574e42612b5749e2b9dd456bdfd1 has the aformentioned four changes

This commit
https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/237/commits/721f2fce128bd4136d75f47cac210de8c5d54830
is because 45 minutes (!) into the build on the previous commit I got a failure with
2024-12-17T05:50:07.1157920Z Encountered problems while solving:
2024-12-17T05:50:07.1158670Z   - nothing provides scipy <0.15.0 needed by tiledbsoma-py-1.15.0-py310h06877d3_0
2024-12-17T05:50:07.1159270Z   - unsupported request

which I cannot with.

nothing provides scipy <0.15.0 needed by tiledbsoma-py-1.15.0-py310h06877d3_0

This is bizarre. Clearly scipy <0.15.0 exists. I can investigate later today, but I agree let's not block the release for this

is because 45 minutes (!) into the build on the previous commit I got a failure with

This delay is because scipy is only a runtime requirement. Thus this didn't surface until the test section when the runtime dependencies are installed.

nothing provides scipy <0.15.0 needed by tiledbsoma-py-1.15.0-py310h06877d3_0

Figured it out. It's scipy 1.15.0, not 0.15.0


List associated lines next to selected Node in presentation server

this is for glossary author

Currently blocked by https://github.com/odpi/egeria/issues/3434. We are not getting the relationship information that we need from the API call that gets the Lines associated with the Term.


Lost new line formatting long form article

what happens
When I hit enter while drafting a long form article new lines were previewed as correctly rendered in yakihonne
However after publication new lines appeared as lost in njump, and not in yakihonne

This was not the case when I used ordered lists.

https://yakihonne.com/article/naddr1qvzqqqr4gupzq96n3hp2vfmf6z2y8uvvxl97xk86kkalnqghx4p25lzl79c76a7yqq252u352fmks7fdxum4qaz9fym4g7j0vaayu9u5h4l
njump.me/naddr1qvzqqqr4gupzq96n3hp2vfmf6z2y8uvvxl97xk86kkalnqghx4p25lzl79c76a7yqq252u352fmks7fdxum4qaz9fym4g7j0vaayu9u5h4l

https://github.com/nostrability/nostrability/issues/146

This is a bug on Yakihonne. Single newlines are ignored on Markdown, only double newlines should be rendered as actual newlines.


Where to specificity V8 Runtime flags?

v8 has a number of options that are enabled via runtime flags. Is there any way to pass these flags (or flags for a different runtime such as wasmtime) to a prebuilt envoy when envoy is invoked, or are runtime flags for Wasm VMs only based on those baked in when building? If the later .. where are these flags baked in/where can they be modified?

cc @PiotrSikora @mathetake @lizan

What are runtime flags specifically you're looking at? If those need to be specified at build time look at v8.patch for V8. I'm not sure what is for wasmtime or wavm.

Thanks @lizan .. not sure how I lost track of this post. I was wanting to experiment with both build and runtime flags for v8. The v8.patch file seems to be specific to the v8 build and I assumed it is applying patches directly to the v8 repository downloaded from https://github.com/v8/v8 (actually https://chromium.googlesource.com/v8/v8). Looking at the patch seems to confirm that. That said, v8 is bought in not by envoy but by proxy-wasm-cpp-host which envoy brings in.  And I notice that proxy-wasm-cpp-host also has a v8.patch file that does a subset of what the v8.patch found in envoy does. Assuming the process for modifying the v8 build is to create a patch file for the v8 source and to replace the current v8.patch file, the question is which v8.patch am I replacing .. the one in envoy repo or the one in proxy-wasm-cpp-host?


[Bug] export & directly import fails to keep image URLs

Scenario:
I create a collection with an image file
I add one entry, and add the image as URL
I export the collection
I delete the entries
I import the same JSON
Problem: The image is no longer present
 "image_1": {
    "path": "http:\/\/somedomain.com\/some\/folder\/picture.jpg"
  },

after
 "image_1": [],

I have same problem.

I think this is an obvious bug.
I tried it on the next branch, but it didn't improve.
I use Gallary instead of Image Field as a workaround.


Mini reporter should have an empty line before the output

Should be an empty line above 1 passed.

Is this a solved issue? I tested this with the example code provided here on my Mac's Iterm 2 terminal and I'm not having the same issue. Looks like this:

Is there something else I would have to do to recreate the issue?

@Bearlock This issue is for master, not the published release.

@sindresorhus Ah, understood. Thanks for the clarification.

This was fixed in #514! Feel free to close it.


FIX: LooseVersion bug in interfaces/registration.py

When attempting to check the FreeSurfer version, LooseVersion was called on fs.preprocess.FSversion, which returns a LooseVersion object by itself. This resulted in LooseVersion throwing an error (because it expects a string).
I've fixed this and confirmed that the version-check logic works as expected.
(There's also a bunch of detailed comments on /anat/mni.py which I wrote for myself when I was first learning how the interface was structured. I can remove those from the PR if that's better.)

Ugh, sorry, this is my fault. Can you switch to freesurfer.Info.looseversion()? I was trying not to break apps that depended on FSVersion, and broke our own. I'll submit a patch to nipype, to restore the old behavior, but we shouldn't depend on it.


provide progress indicator for docker cp

Currently there's no feedback on copy progress, so you're not sure when a copy will complete.  Feedback could be something like that provided by docker pull or the command line utility scp.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

I agree. This is currently my main shortcoming of using docker cp versus ssh directly. I'd prefer using docker cp since my current setup doesn't rely on the host for storage or environment variables (dumb host).

Sorry, @ErikGrimes, but I'm closing this. There were quite some concerns about adding this on the pull request (see https://github.com/docker/docker/pull/17014#issuecomment-166982627).
Thanks for suggesting!


kubectl --wait=true & helm --wait=true

Would be nice to be able to specify the --wait flag to kubectl, to allow it to wait until the resources are running before continuing.
Same with the Helm step type.
Alternatively add an extraArgs field that allows users to specify --wait, --warnings-as-errors, --wait-for-jobs, or whatever else they need.

The functionality of what --wait actually does isn't that obvious. It doesn't exist on kubectl create, and docs suggest it only waits for objects to be removed not deleted. This must be double checked, and if an additional kubectl wait (the subcommand, not the flag) is wanted instead.
Should we instead just refer to running a container step type that does the kubectl wait on all the resources they want?

I think it would be difficult to generically "wait" for any and all resources that are created from a kubectly apply or helm install. It may as you suggest be better to let the user control this more granularly. For example you could wait for all pods with a certain label to be ready:
kubectl wait --for=condition=ready pod -l app=netshoot , see https://stackoverflow.com/a/60810347/5342320
Caveats to consider: Jobs https://stackoverflow.com/questions/55303430/kubectl-wait-waits-forever?rq=1


How to get currently playing song?

Hello everyone!
This is my code. It is quite urgent because we are doing this for a school project.

Please help us. Thanks in advance

I can't find anything in the documentation. I even used chat gpt to search for the documentation for the correct way to get the name of the currently playing song but the object current.Item doesn't have a .name property. I cannot get the track name no matter what I try.

Hi,
This page should have the solution
https://johnnycrazy.github.io/SpotifyAPI-NET/docs/iplayableitem


Add option to lint while typing instead of waiting for file save

While browsing through the source code I noticed that the getConfig method returns onSave: true.
Would it be possible to add a configuration so that we can change this settings to lint while writing the code instead of only checking after saving ?
Similar to ruby-lsp's behaviour with Rubocop
https://github.com/crystal-ameba/vscode-crystal-ameba/assets/75388869/367909e5-ec16-4b94-a119-9f6f75ee0356

WIP implementation here. Won't be usable until after the next ameba release though.
https://github.com/nobodywasishere/vscode-crystal-ameba/tree/nobody/lint-on-type


Inject multiple times to the same file

When trying to inject multiple times to the same file, only one of the injections applies.

Hi! currently this is by design. Multiple different injections require multiple different files. If you have a ton of injections, which make up most of the content of a file, consider rebuilding the entire file with generators each time.

That was fast! Unfortunately re-generating the entire file isn't possible for me, specifically what I'm trying to do is add an import to a file and then use that import, so I need to insert two non-consecutive lines, but I don't want the rest of the file to change nor can I tell what its current content is.

@GuyPie You can write multiple template files that target the same file but different before/after locations.
e.g:
01_inject_a_file.txt
---
to: path/to/file.txt
inject: true
after: LOCATION_A
---
first injection

02_inject_b_file.txt
---
to: path/to/file.txt
inject: true
after: LOCATION_B
---
second injection

That way you should be able to achive your goal while separating the different "concerns".
Hope it helps

Thanks @tobmaster, but that's exactly what I tried initially and it doesn't work - what ends up happening is only one the injections takes effect.

Oh, I thought I tried that before. Then sorry for misleading you. I will retry it

I retried it successfully in hygen 1.4.8 with this:
https://gist.github.com/tobmaster/8489f1b0a850216c73c2619144a69e90

You're right! I had a skip_if that stopped it from working. Sorry, closing this.


"Go to definition" still broken in after updating to 1.25

VSCode Version: 1.25
OS Version: MacOS 10.12.6

Steps to Reproduce:

Use export default to export an unnamed function from a javascript file
Import the function from another file
Cmd-click an instance of the function in the file where you imported it.

Does this issue occur when all extensions are disabled?: Yes
I've been following various issues relating to this bug, mostly now suggesting that it has been fixed. But clearly in the most recent update it is still a problem! Please fix this asap as am forced to downgrade to March release until it is.

Duplicate of #51918


Swift 4.2 compatibility

I think it's just requiring a few Xcode fix-me clicks.

Just pushed a Swift 4.2 version with tag 0.4.4. Check it out!


.NET Core Debug Output Target

Type (choose one): Question
NLog version: 4.4 beta
Platform: .Net Core
Current NLog config (xml or C#, if relevant)
            var debuggerTarget = new DebugTarget() { Name = "Debugger" };
            config.AddTarget(debuggerTarget);
            debuggerTarget.Layout = @"${date:format=HH\:mm\:ss} ${logger} ${message}";
            config.LoggingRules.Add(new LoggingRule("*", LogLevel.Debug, debuggerTarget));

I am using VS 2015 Update 2, Enterprise.  I am attempting to get log output to show up in the debug output window on a .Net Core console app using code configuration.  I searched the posts here and did not see any reports of issues with this feature.  My console logs and rolling files are working just fine - but the debug output window does not.  Can someone point me in the right direction?
Thanks!  (And awesome work on NLog!)

The DebugTarget is only a target which keeps the last message as an property, for debugging purpose.
To which debug output do you like to write? Do you have an C# example (if you would write it yourself)

Ahh, I see - I completely misunderstood the DebugTarget.  Thank you for clarifying. :)
I was looking to get my logs to show up in the debug output panel inside visual studio.  Yes, System.Diagnostics has a mechanism to write to the debug output panel, I could write my own Target to accomplish this.
Thanks again for the clarification!

Well we have a trace and debuggertarget, but those are absent in .NET core because the needed classes aren't available at that platform

Or has that changed recently?

I am not sure if anything has changed in core that would enable the DebuggerTarget.  Sorry I cant speak to that specifically.
We will likely just write something that passes the logged message to Debug.Writeline in addition to passing to the logger.  We can just put it in our façade.


 This seems to cause an Network error:

And the status being displayed as offline wrongly:

Implement a retry mechanism and a different online check (maybe using the API) and cache the last commit per session. Possibly get the last commit through the own API where it could be cached.

Possibility to integrate in API:
https://stackoverflow.com/questions/25921757/how-to-get-last-commit-date-inside-a-folder-directory-in-github-repo#:~:text=Try git log -n 1,cD %3A committer date%2C RFC2822 style


Unable to Upload file from Desktop

Is it possible to upload a file from desktop to web using Selenide?

@nikgupta19 Sure. Just use method $.uploadFile().
For example, $("input#cv").uploadFile(new File("c:/Desktop/cv.pdf"));


preserving key order in objects

This may be a non-goal for sajson, but I wanted to preserve the order of keys, so I can write everything back to a file minimizing differences with the original file.
As a quick hack I added a couple of #ifdefs to disable key sorting and to remove affected functions:
https://github.com/project-gemmi/gemmi/commit/8668beeb012d6e2232e0cd39cf6434a06ed78b9c
Not sure if it's worth upstreaming, but just to let you know.

I think this would be fine to upstream, though I'd probably be explicit and name it SAJSON_UNSORTED_OBJECT_KEYS


This breaks everybody who had a tree for development.

i.e. please fix this merge conflict:
[stewart@birb occ]$ git pull
remote: Counting objects: 2496, done.
remote: Total 2496 (delta 917), reused 917 (delta 917), pack-reused 1579
Receiving objects: 100% (2496/2496), 1.92 MiB | 1.08 MiB/s, done.
Resolving deltas: 100% (1953/1953), completed with 180 local objects.
From github.com:open-power/occ
 + 69fb587...30ed768 master     -> origin/master  (forced update)
 * [new branch]      master_p8  -> origin/master_p8
Auto-merging src/ssx/ssx/ssxssxfiles.mk
CONFLICT (content): Merge conflict in src/ssx/ssx/ssxssxfiles.mk
Auto-merging src/ssx/ssx/ssx_timer_init.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_timer_init.c
Auto-merging src/ssx/ssx/ssx_timer_core.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_timer_core.c
Auto-merging src/ssx/ssx/ssx_thread_init.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_thread_init.c
Auto-merging src/ssx/ssx/ssx_thread_core.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_thread_core.c
Auto-merging src/ssx/ssx/ssx_stack_init.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_stack_init.c
Auto-merging src/ssx/ssx/ssx_semaphore_init.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_semaphore_init.c
Auto-merging src/ssx/ssx/ssx_semaphore_core.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_semaphore_core.c
Auto-merging src/ssx/ssx/ssx_macros.h
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_macros.h
Auto-merging src/ssx/ssx/ssx_kernel.h
Auto-merging src/ssx/ssx/ssx_init.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_init.c
Auto-merging src/ssx/ssx/ssx_core.c
CONFLICT (content): Merge conflict in src/ssx/ssx/ssx_core.c
Auto-merging src/ssx/ssx/ssx_api.h
Auto-merging src/ssx/ssx/ssx.h
Auto-merging src/ssx/ssx/Makefile
CONFLICT (content): Merge conflict in src/ssx/ssx/Makefile
Auto-merging src/ssx/ppc405/ssxppc405files.mk
CONFLICT (content): Merge conflict in src/ssx/ppc405/ssxppc405files.mk
Auto-merging src/ssx/ppc405/ssx_port_types.h
Auto-merging src/ssx/ppc405/ppc405_thread_init.S
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_thread_init.S
Auto-merging src/ssx/ppc405/ppc405_spr.h
Auto-merging src/ssx/ppc405/ppc405_msr.h
Auto-merging src/ssx/ppc405/ppc405_mmu_asm.S
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_mmu_asm.S
Auto-merging src/ssx/ppc405/ppc405_mmu.h
Auto-merging src/ssx/ppc405/ppc405_mmu.c
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_mmu.c
Auto-merging src/ssx/ppc405/ppc405_lib_core.c
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_lib_core.c
Auto-merging src/ssx/ppc405/ppc405_irq_init.c
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_irq_init.c
Auto-merging src/ssx/ppc405/ppc405_irq_core.c
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_irq_core.c
Auto-merging src/ssx/ppc405/ppc405_irq.h
Auto-merging src/ssx/ppc405/ppc405_init.c
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_init.c
Auto-merging src/ssx/ppc405/ppc405_exceptions.S
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_exceptions.S
Auto-merging src/ssx/ppc405/ppc405_dcr.h
Auto-merging src/ssx/ppc405/ppc405_core.c
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_core.c
Auto-merging src/ssx/ppc405/ppc405_context.h
Auto-merging src/ssx/ppc405/ppc405_cache_init.S
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_cache_init.S
Auto-merging src/ssx/ppc405/ppc405_cache_core.c
Auto-merging src/ssx/ppc405/ppc405_cache.h
Auto-merging src/ssx/ppc405/ppc405_breakpoint.S
CONFLICT (content): Merge conflict in src/ssx/ppc405/ppc405_breakpoint.S
Auto-merging src/ssx/ppc405/ppc405_boot.S
Auto-merging src/ssx/ppc405/ppc405.h
Auto-merging src/ssx/ppc405/Makefile
CONFLICT (content): Merge conflict in src/ssx/ppc405/Makefile
Auto-merging src/ssx/ppc32/ssxppc32files.mk
CONFLICT (content): Merge conflict in src/ssx/ppc32/ssxppc32files.mk
Auto-merging src/ssx/ppc32/savegpr.S
CONFLICT (content): Merge conflict in src/ssx/ppc32/savegpr.S
Auto-merging src/ssx/ppc32/ppc32_gcc.h
Auto-merging src/ssx/ppc32/ppc32_gcc.c
Auto-merging src/ssx/ppc32/ppc32_asm.h
CONFLICT (content): Merge conflict in src/ssx/ppc32/ppc32_asm.h
Auto-merging src/ssx/ppc32/ppc32.h
CONFLICT (modify/delete): src/ssx/ppc32/gnu/stubs-32.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/ppc32/gnu/stubs-32.h left in tree.
Auto-merging src/ssx/ppc32/div64.S
CONFLICT (content): Merge conflict in src/ssx/ppc32/div64.S
Auto-merging src/ssx/ppc32/Makefile
CONFLICT (content): Merge conflict in src/ssx/ppc32/Makefile
CONFLICT (modify/delete): src/ssx/pgp/ssxpgpfiles.mk deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/ssxpgpfiles.mk left in tree.
CONFLICT (modify/delete): src/ssx/pgp/ssx_port.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/ssx_port.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/ssx.mk deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/ssx.mk left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/tpc_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/tpc_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/tod_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/tod_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/tod_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/tod_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/sramctl_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/sramctl_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/sensors_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/sensors_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/sensors_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/sensors_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/sbe_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/sbe_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/sbe_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/sbe_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pore_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pore_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pore_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pore_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/plb_arbiter_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/plb_arbiter_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/plb_arbiter_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/plb_arbiter_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pibmem_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pibmem_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pibmem_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pibmem_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pcbs_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pcbs_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pcbs_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pcbs_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pc_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pc_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pc_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pc_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/pba_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/pba_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/oha_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/oha_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/oha_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/oha_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/ocb_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/ocb_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/ocb_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/ocb_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/mcs_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/mcs_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/mcs_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/mcs_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/icp_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/icp_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/icp_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/icp_firmware_registers.h left in tree.
Removing src/ssx/pgp/registers/i2cengine_register_addresses.h
Removing src/ssx/pgp/registers/i2cengine_firmware_registers.h
CONFLICT (modify/delete): src/ssx/pgp/registers/fasti2c_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/fasti2c_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/fasti2c_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/fasti2c_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/centaur_register_addresses.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/centaur_register_addresses.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/registers/centaur_firmware_registers.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/registers/centaur_firmware_registers.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_vrm.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_vrm.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_trace.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_trace.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_sramctl.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_sramctl.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_pore.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_pore.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_pmc.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_pmc.c left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_ocb.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_ocb.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_irq_init.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_irq_init.c left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_init.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_init.c left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_id.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_id.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_core.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_core.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_centaur.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_centaur.h left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_centaur.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_centaur.c left in tree.
CONFLICT (modify/delete): src/ssx/pgp/pgp_async_pore.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/pgp_async_pore.c left in tree.
Removing src/ssx/pgp/linkssx.cmd
CONFLICT (modify/delete): src/ssx/pgp/Makefile deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/ssx/pgp/Makefile left in tree.
Auto-merging src/ssx/occhw/ssx_port.h
Auto-merging src/ssx/occhw/occhw_scom.h
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_scom.h
Auto-merging src/ssx/occhw/occhw_pba.h
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_pba.h
Auto-merging src/ssx/occhw/occhw_pba.c
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_pba.c
Auto-merging src/ssx/occhw/occhw_ocb.c
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_ocb.c
Auto-merging src/ssx/occhw/occhw_irq.h
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_irq.h
Auto-merging src/ssx/occhw/occhw_id.c
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_id.c
Auto-merging src/ssx/occhw/occhw_cache.S
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_cache.S
Auto-merging src/ssx/occhw/occhw_async_pba.c
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_async_pba.c
Auto-merging src/ssx/occhw/occhw_async_ocb.c
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_async_ocb.c
Auto-merging src/ssx/occhw/occhw_async.h
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_async.h
Auto-merging src/ssx/occhw/occhw_async.c
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw_async.c
Auto-merging src/ssx/occhw/occhw.h
CONFLICT (content): Merge conflict in src/ssx/occhw/occhw.h
Auto-merging src/ppe/tools/ppetracepp/Makefile
Auto-merging src/ppe/pk/ppe/pkppefiles.mk
Auto-merging src/occ_gpe1/topfiles.mk
Auto-merging src/occ_gpe0/pss_constants.h
Auto-merging src/occ_gpe0/apss_constants.h
Auto-merging src/occ_405/trac/trac_service_codes.h
Auto-merging src/occ_405/trac/trac_interface.h
Auto-merging src/occ_405/trac/trac_interface.c
Auto-merging src/occ_405/trac/trac.h
Auto-merging src/occ_405/topfiles.mk
CONFLICT (content): Merge conflict in src/occ_405/topfiles.mk
Auto-merging src/occ_405/timer/timer_service_codes.h
Auto-merging src/occ_405/timer/timer.h
Auto-merging src/occ_405/timer/timer.c
Auto-merging src/occ_405/thread/thread_service_codes.h
Auto-merging src/occ_405/thread/threadSch.h
Auto-merging src/occ_405/thread/threadSch.c
CONFLICT (content): Merge conflict in src/occ_405/thread/threadSch.c
Auto-merging src/occ_405/thread/thread.h
Auto-merging src/occ_405/thread/test/threadtest.c
Auto-merging src/occ_405/thread/test/app.mk
Auto-merging src/occ_405/thread/test/Makefile
Auto-merging src/occ_405/thread/chom.c
Auto-merging src/occ_405/state.h
Auto-merging src/occ_405/state.c
CONFLICT (content): Merge conflict in src/occ_405/state.c
Auto-merging src/occ_405/sensor/sensor_table.c
CONFLICT (content): Merge conflict in src/occ_405/sensor/sensor_table.c
Auto-merging src/occ_405/sensor/sensor_service_codes.h
Auto-merging src/occ_405/sensor/sensor_query_list.h
Auto-merging src/occ_405/sensor/sensor_query_list.c
Auto-merging src/occ_405/sensor/sensor_info.c
Auto-merging src/occ_405/sensor/sensor_enum.h
CONFLICT (content): Merge conflict in src/occ_405/sensor/sensor_enum.h
Auto-merging src/occ_405/sensor/sensor.h
Auto-merging src/occ_405/sensor/sensor.c
Auto-merging src/occ_405/scom.h
Auto-merging src/occ_405/scom.c
Auto-merging src/occ_405/rtls/test/rtls_tables.c
Auto-merging src/occ_405/rtls/test/main.c
Auto-merging src/occ_405/rtls/test/app.mk
Auto-merging src/occ_405/rtls/test/Makefile
Auto-merging src/occ_405/rtls/rtls_tables.c
Auto-merging src/occ_405/rtls/rtls_service_codes.h
Auto-merging src/occ_405/rtls/rtls.h
Auto-merging src/occ_405/rtls/rtls.c
Auto-merging src/occ_405/reset.c
CONFLICT (content): Merge conflict in src/occ_405/reset.c
Auto-merging src/occ_405/pss/test/apsstest.c
Auto-merging src/occ_405/pss/test/app.mk
Auto-merging src/occ_405/pss/test/Makefile
Auto-merging src/occ_405/pss/pss_service_codes.h
Auto-merging src/occ_405/pss/dpss_init.c
Auto-merging src/occ_405/pss/dpss.h
Auto-merging src/occ_405/pss/dpss.c
Auto-merging src/occ_405/pss/apss.h
Auto-merging src/occ_405/pss/apss.c
Auto-merging src/occ_405/proc/test/main.c
Auto-merging src/occ_405/proc/test/app.mk
Auto-merging src/occ_405/proc/test/Makefile
Auto-merging src/occ_405/proc/proc_pstate.h
CONFLICT (content): Merge conflict in src/occ_405/proc/proc_pstate.h
Auto-merging src/occ_405/proc/proc_data_service_codes.h
Auto-merging src/occ_405/proc/proc_data_control.h
Auto-merging src/occ_405/proc/proc_data_control.c
Auto-merging src/occ_405/proc/proc_data.h
Auto-merging src/occ_405/occ_sys_config.h
CONFLICT (content): Merge conflict in src/occ_405/occ_sys_config.h
Auto-merging src/occ_405/occ_sys_config.c
Auto-merging src/occ_405/occ_service_codes.h
Auto-merging src/occ_405/occ_defs.mk
Auto-merging src/occ_405/occLinkInputFile
CONFLICT (content): Merge conflict in src/occ_405/occLinkInputFile
Auto-merging src/occ_405/mode.h
Auto-merging src/occ_405/mode.c
Auto-merging src/occ_405/main.c
CONFLICT (content): Merge conflict in src/occ_405/main.c
Auto-merging src/occ_405/linkocc.cmd
Auto-merging src/occ_405/incl/occ_common.h
Auto-merging src/occ_405/incl/comp_ids.h
Auto-merging src/occ_405/incl/common_types.h
CONFLICT (content): Merge conflict in src/occ_405/incl/common_types.h
Auto-merging src/occ_405/homer.h
Auto-merging src/occ_405/homer.c
Auto-merging src/occ_405/firdata/fir_data_collect.c
Auto-merging src/occ_405/errl/test/test.mk
Auto-merging src/occ_405/errl/test/parser.c
Auto-merging src/occ_405/errl/test/gpefiles.mk
Auto-merging src/occ_405/errl/test/errltest.c
Auto-merging src/occ_405/errl/test/app.mk
Auto-merging src/occ_405/errl/test/Makefile
Auto-merging src/occ_405/errl/errl.h
Auto-merging src/occ_405/errl/errl.c
Auto-merging src/occ_405/dcom/dcom_thread.c
Auto-merging src/occ_405/dcom/dcom_service_codes.h
Auto-merging src/occ_405/dcom/dcomSlaveTx.c
Auto-merging src/occ_405/dcom/dcomSlaveRx.c
CONFLICT (content): Merge conflict in src/occ_405/dcom/dcomSlaveRx.c
Auto-merging src/occ_405/dcom/dcomMasterTx.c
Auto-merging src/occ_405/dcom/dcomMasterRx.c
Auto-merging src/occ_405/dcom/dcom.h
CONFLICT (content): Merge conflict in src/occ_405/dcom/dcom.h
Auto-merging src/occ_405/dcom/dcom.c
CONFLICT (content): Merge conflict in src/occ_405/dcom/dcom.c
Auto-merging src/occ_405/cmdh/ll_ffdc.S
Auto-merging src/occ_405/cmdh/ffdc.h
Auto-merging src/occ_405/cmdh/ffdc.c
Auto-merging src/occ_405/cmdh/cmdh_tunable_parms.h
Auto-merging src/occ_405/cmdh/cmdh_tunable_parms.c
Auto-merging src/occ_405/cmdh/cmdh_thread.c
Auto-merging src/occ_405/cmdh/cmdh_snapshot.h
Auto-merging src/occ_405/cmdh/cmdh_snapshot.c
CONFLICT (content): Merge conflict in src/occ_405/cmdh/cmdh_snapshot.c
Auto-merging src/occ_405/cmdh/cmdh_service_codes.h
Auto-merging src/occ_405/cmdh/cmdh_mnfg_intf.h
Auto-merging src/occ_405/cmdh/cmdh_mnfg_intf.c
CONFLICT (content): Merge conflict in src/occ_405/cmdh/cmdh_mnfg_intf.c
Auto-merging src/occ_405/cmdh/cmdh_fsp_cmds_datacnfg.h
CONFLICT (content): Merge conflict in src/occ_405/cmdh/cmdh_fsp_cmds_datacnfg.h
Auto-merging src/occ_405/cmdh/cmdh_fsp_cmds_datacnfg.c
CONFLICT (content): Merge conflict in src/occ_405/cmdh/cmdh_fsp_cmds_datacnfg.c
Auto-merging src/occ_405/cmdh/cmdh_fsp_cmds.h
Auto-merging src/occ_405/cmdh/cmdh_fsp_cmds.c
CONFLICT (content): Merge conflict in src/occ_405/cmdh/cmdh_fsp_cmds.c
Auto-merging src/occ_405/cmdh/cmdh_fsp.h
Auto-merging src/occ_405/cmdh/cmdh_fsp.c
CONFLICT (content): Merge conflict in src/occ_405/cmdh/cmdh_fsp.c
Auto-merging src/occ_405/cmdh/cmdh_dbug_cmd.h
Auto-merging src/occ_405/cmdh/cmdh_dbug_cmd.c
Auto-merging src/occ_405/cent/centaur_data_service_codes.h
Auto-merging src/occ_405/cent/centaur_data.h
Auto-merging src/occ_405/cent/centaur_data.c
Auto-merging src/occ_405/cent/centaur_control.h
Auto-merging src/occ_405/cent/centaur_control.c
Auto-merging src/occ_405/arl_test_data.h
Auto-merging src/occ_405/arl_test.c
Auto-merging src/occ_405/amec/amec_tasks.c
Auto-merging src/occ_405/amec/amec_sys.h
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_sys.h
Auto-merging src/occ_405/amec/amec_smh.h
Auto-merging src/occ_405/amec/amec_slave_smh.h
Auto-merging src/occ_405/amec/amec_service_codes.h
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_service_codes.h
Auto-merging src/occ_405/amec/amec_sensors_power.c
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_sensors_power.c
Auto-merging src/occ_405/amec/amec_sensors_fw.h
Auto-merging src/occ_405/amec/amec_sensors_fw.c
Auto-merging src/occ_405/amec/amec_sensors_core.h
Auto-merging src/occ_405/amec/amec_sensors_core.c
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_sensors_core.c
Auto-merging src/occ_405/amec/amec_sensors_centaur.h
Auto-merging src/occ_405/amec/amec_sensors_centaur.c
Auto-merging src/occ_405/amec/amec_perfcount.h
Auto-merging src/occ_405/amec/amec_perfcount.c
Auto-merging src/occ_405/amec/amec_pcap.h
Auto-merging src/occ_405/amec/amec_pcap.c
Auto-merging src/occ_405/amec/amec_part.h
Auto-merging src/occ_405/amec/amec_part.c
Auto-merging src/occ_405/amec/amec_parm_table.c
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_parm_table.c
Auto-merging src/occ_405/amec/amec_parm.h
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_parm.h
Auto-merging src/occ_405/amec/amec_parm.c
Auto-merging src/occ_405/amec/amec_oversub.h
Auto-merging src/occ_405/amec/amec_oversub.c
Auto-merging src/occ_405/amec/amec_master_smh.h
Auto-merging src/occ_405/amec/amec_master_smh.c
Auto-merging src/occ_405/amec/amec_init.c
Auto-merging src/occ_405/amec/amec_health.h
Auto-merging src/occ_405/amec/amec_health.c
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_health.c
Auto-merging src/occ_405/amec/amec_freq.h
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_freq.h
Auto-merging src/occ_405/amec/amec_freq.c
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_freq.c
Auto-merging src/occ_405/amec/amec_external.h
Auto-merging src/occ_405/amec/amec_dps.h
Auto-merging src/occ_405/amec/amec_dps.c
Auto-merging src/occ_405/amec/amec_data.h
Auto-merging src/occ_405/amec/amec_data.c
Auto-merging src/occ_405/amec/amec_controller.h
Auto-merging src/occ_405/amec/amec_controller.c
Auto-merging src/occ_405/amec/amec_analytics.h
Auto-merging src/occ_405/amec/amec_analytics.c
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_analytics.c
Auto-merging src/occ_405/amec/amec_amester.h
CONFLICT (content): Merge conflict in src/occ_405/amec/amec_amester.h
Auto-merging src/occ_405/amec/amec_amester.c
Auto-merging src/occBootLoader/bootMain.h
CONFLICT (content): Merge conflict in src/occBootLoader/bootMain.h
Auto-merging src/occBootLoader/bootMain.c
CONFLICT (content): Merge conflict in src/occBootLoader/bootMain.c
Removing src/occApplet/testApplet/traceTest.c
Removing src/occApplet/testApplet/testApltId.h
CONFLICT (modify/delete): src/occApplet/testApplet/sensorTest.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/occApplet/testApplet/sensorTest.c left in tree.
Removing src/occApplet/testApplet/pstApplet.c
Removing src/occApplet/testApplet/linkTestApplet.cmd
Removing src/occApplet/testApplet/errlTest.c
Removing src/occApplet/testApplet/apsstest.c
Removing src/occApplet/testApplet/Makefile
Removing src/occApplet/template.c
Removing src/occApplet/productApplet/productappletfiles.mk
Removing src/occApplet/productApplet/occLinkInputFile
Removing src/occApplet/productApplet/linkProductApplet.cmd
Removing src/occApplet/productApplet/apssInitApplet.c
Removing src/occApplet/productApplet/Makefile
Removing src/occApplet/Makefile
Removing src/occ/thread/thrm_thread.h
Removing src/occ/thread/thrm_thread.c
Removing src/occ/ssx_app_cfg.h
CONFLICT (modify/delete): src/occ/proc/proc_pstate.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/occ/proc/proc_pstate.c left in tree.
Removing src/occ/proc/proc_data.c
Removing src/occ/gpe/pss_macros.h
Removing src/occ/gpe/pore_test_pss.pS
Removing src/occ/gpe/pore_test_error.pS
Removing src/occ/gpe/pore_test.pS
Removing src/occ/gpe/gpe_macros.h
Removing src/occ/gpe/apss_meas_read_start.pS
Removing src/occ/gpe/apss_meas_read_cont.pS
Removing src/occ/gpe/apss_meas_read_complete.pS
Removing src/occ/gpe/apss_init.pS
Removing src/occ/gpe/apss_composite.pS
Removing src/occ/gpe/apss_altitude.pS
Removing src/occ/common.c
Removing src/occ/app.mk
Removing src/occ/aplt/incl/appletId.h
Removing src/occ/aplt/appletManager.h
Removing src/occ/aplt/appletManager.c
Removing src/occ/aplt/aplt_service_codes.h
CONFLICT (modify/delete): src/occ/amec/amec_slave_smh.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/occ/amec/amec_slave_smh.c left in tree.
Removing src/occ/Makefile
CONFLICT (modify/delete): src/lib/vrm.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/vrm.h left in tree.
CONFLICT (modify/delete): src/lib/vrm.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/vrm.c left in tree.
CONFLICT (modify/delete): src/lib/time.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/time.c left in tree.
CONFLICT (modify/delete): src/lib/string.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/string.h left in tree.
CONFLICT (modify/delete): src/lib/strdup.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/strdup.c left in tree.
CONFLICT (modify/delete): src/lib/strcasecmp.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/strcasecmp.c left in tree.
CONFLICT (modify/delete): src/lib/ssx_dump.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/ssx_dump.h left in tree.
CONFLICT (modify/delete): src/lib/special_wakeup.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/special_wakeup.h left in tree.
CONFLICT (modify/delete): src/lib/special_wakeup.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/special_wakeup.c left in tree.
CONFLICT (modify/delete): src/lib/simics_stdio.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/simics_stdio.h left in tree.
CONFLICT (modify/delete): src/lib/pstates.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pstates.h left in tree.
CONFLICT (modify/delete): src/lib/pstates.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pstates.c left in tree.
Auto-merging src/lib/ppc405lib/strtox.h
CONFLICT (content): Merge conflict in src/lib/ppc405lib/strtox.h
Auto-merging src/lib/ppc405lib/strtox.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/strtox.c
Auto-merging src/lib/ppc405lib/string_stream.h
CONFLICT (content): Merge conflict in src/lib/ppc405lib/string_stream.h
Auto-merging src/lib/ppc405lib/string_stream.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/string_stream.c
Auto-merging src/lib/ppc405lib/stdlib.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/stdlib.c
Auto-merging src/lib/ppc405lib/ssx_io.h
CONFLICT (content): Merge conflict in src/lib/ppc405lib/ssx_io.h
Auto-merging src/lib/ppc405lib/ssx_io.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/ssx_io.c
Auto-merging src/lib/ppc405lib/ssx_dump.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/ssx_dump.c
Auto-merging src/lib/ppc405lib/sprintf.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/sprintf.c
Auto-merging src/lib/ppc405lib/simics_stdio_addresses.h
CONFLICT (content): Merge conflict in src/lib/ppc405lib/simics_stdio_addresses.h
Auto-merging src/lib/ppc405lib/simics_stdio.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/simics_stdio.c
Auto-merging src/lib/ppc405lib/puts.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/puts.c
Auto-merging src/lib/ppc405lib/printf.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/printf.c
Auto-merging src/lib/ppc405lib/polling.h
CONFLICT (content): Merge conflict in src/lib/ppc405lib/polling.h
Auto-merging src/lib/ppc405lib/libssx.h
Auto-merging src/lib/ppc405lib/fgetc.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/fgetc.c
Auto-merging src/lib/ppc405lib/ctype_table.c
CONFLICT (content): Merge conflict in src/lib/ppc405lib/ctype_table.c
Auto-merging src/lib/ppc405lib/ctype.h
CONFLICT (content): Merge conflict in src/lib/ppc405lib/ctype.h
CONFLICT (modify/delete): src/lib/pore_hooks.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pore_hooks.h left in tree.
CONFLICT (modify/delete): src/lib/polling.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/polling.c left in tree.
CONFLICT (modify/delete): src/lib/pmc_dcm.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pmc_dcm.h left in tree.
CONFLICT (modify/delete): src/lib/pmc_dcm.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pmc_dcm.c left in tree.
CONFLICT (modify/delete): src/lib/pgp_config.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pgp_config.h left in tree.
CONFLICT (modify/delete): src/lib/pgas_ppc.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pgas_ppc.h left in tree.
CONFLICT (modify/delete): src/lib/pgas.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/pgas.h left in tree.
CONFLICT (modify/delete): src/lib/memcpy.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/memcpy.c left in tree.
CONFLICT (modify/delete): src/lib/libssx.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/libssx.h left in tree.
CONFLICT (modify/delete): src/lib/libgpefiles.mk deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/libgpefiles.mk left in tree.
CONFLICT (modify/delete): src/lib/libfiles.mk deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/libfiles.mk left in tree.
CONFLICT (modify/delete): src/lib/heartbeat.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/heartbeat.h left in tree.
CONFLICT (modify/delete): src/lib/heartbeat.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/heartbeat.c left in tree.
CONFLICT (modify/delete): src/lib/gpsm_init.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpsm_init.c left in tree.
Removing src/lib/gpsm_dcm_fast_handler.S
CONFLICT (modify/delete): src/lib/gpsm_dcm.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpsm_dcm.h left in tree.
CONFLICT (modify/delete): src/lib/gpsm_dcm.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpsm_dcm.c left in tree.
CONFLICT (modify/delete): src/lib/gpsm.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpsm.h left in tree.
CONFLICT (modify/delete): src/lib/gpsm.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpsm.c left in tree.
CONFLICT (modify/delete): src/lib/gpe_scom.pS deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_scom.pS left in tree.
CONFLICT (modify/delete): src/lib/gpe_scom.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_scom.h left in tree.
CONFLICT (modify/delete): src/lib/gpe_pba_pgas.pS deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_pba_pgas.pS left in tree.
CONFLICT (modify/delete): src/lib/gpe_pba.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_pba.h left in tree.
CONFLICT (modify/delete): src/lib/gpe_pba.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_pba.c left in tree.
CONFLICT (modify/delete): src/lib/gpe_data.pS deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_data.pS left in tree.
CONFLICT (modify/delete): src/lib/gpe_data.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_data.h left in tree.
CONFLICT (modify/delete): src/lib/gpe_control.pS deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_control.pS left in tree.
CONFLICT (modify/delete): src/lib/gpe_control.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe_control.h left in tree.
CONFLICT (modify/delete): src/lib/gpe.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/gpe.h left in tree.
CONFLICT (modify/delete): src/lib/errno.h deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/errno.h left in tree.
CONFLICT (modify/delete): src/lib/ctype.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/ctype.c left in tree.
Auto-merging src/lib/common/string.c
CONFLICT (content): Merge conflict in src/lib/common/string.c
Auto-merging src/lib/common/memset.c
CONFLICT (content): Merge conflict in src/lib/common/memset.c
Auto-merging src/lib/common/libcommonfiles.mk
CONFLICT (modify/delete): src/lib/assert.c deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/assert.c left in tree.
CONFLICT (modify/delete): src/lib/Makefile deleted in 30ed7685e39b12255247d0c30db8660f4e42eadb and modified in HEAD. Version HEAD of src/lib/Makefile left in tree.
Auto-merging src/include/registers/tpc_firmware_registers.h
CONFLICT (content): Merge conflict in src/include/registers/tpc_firmware_registers.h
Auto-merging src/include/registers/sramctl_firmware_registers.h
CONFLICT (content): Merge conflict in src/include/registers/sramctl_firmware_registers.h
Auto-merging src/include/registers/pmc_register_addresses.h
CONFLICT (content): Merge conflict in src/include/registers/pmc_register_addresses.h
Auto-merging src/include/registers/pmc_firmware_registers.h
CONFLICT (content): Merge conflict in src/include/registers/pmc_firmware_registers.h
Auto-merging src/include/registers/pba_firmware_registers.h
CONFLICT (content): Merge conflict in src/include/registers/pba_firmware_registers.h
Auto-merging src/include/occhw_common.h
CONFLICT (content): Merge conflict in src/include/occhw_common.h
Auto-merging src/Makefile
CONFLICT (content): Merge conflict in src/Makefile
Automatic merge failed; fix conflicts and then commit the result.

This is not going to be fixed. The occ repository was not following the conventions we put in place for the other repositories that had a P8 / P9 split. This has been fixed by a branch rename. What you previously saw as 'master' is now 'master-p8'. You should be able to fix up you .git/config to point your local development branch at the 'master-p8' as the pull source if that is what you intend to do.


TypeError: Invalid file: WindowsPath('example_mandarin.wav')

When I tried to run code in WINDOWS
from speechbrain.pretrained import EncoderDecoderASR
asr_model = EncoderDecoderASR.from_hparams(source="speechbrain/asr-wav2vec2-transformer-aishell",
                                               savedir="pretrained_models/asr-wav2vec2-transformer-aishell")
res = asr_model.transcribe_file('speechbrain/asr-wav2vec2-transformer-aishell/example_mandarin.wav')

I got the error:

I looked at some of the code located in the file "\speechbrain\pretrained\interfaces.py":

and I found that the function torchaudio.load(path, channels_first=False) requires a str. However, the function fetch  in
this file return an object with the type  pathlib.WindowsPath , so actually I use it instead of an str. And this raised the error.
I wonder if this is an incompatibility issue on Windows? I have avoided this problem in some other way, but I sincerely hope it can be resolved.

from speechbrain.inference.separation import SepformerSeparation as separator
import torchaudio
model = separator.from_hparams(source="speechbrain/sepformer-whamr-enhancement", savedir='pretrained_models/sepformer-whamr-enhancement4')
enhanced_speech = model.separate_file(path='1min.mp3')
can you tell me how you corrected it


rm perp dex-specific metrics

Summary

As we move towards deprecating this model, we'll need to remove sector-specific metrics that are no longer available
Removing market_pair, trading_fees, and txn_fees metrics which are sourced from perp dex models

Test Plan

Ran datahub model locally

remove from the fact_daily_asset_metrics_datahub datahub as well (downstream model of fact_daily_app_datahub.

Good catch, thanks!


Expressions in REST project not working v 1.37

Describe the bug
According https://castlemock.com/expressions/ I can use expressions in REST projects, but is not working in docker version 1.37
To Reproduce
Steps to reproduce the behavior:

Pull docker image 1.37
docker pull castlemock/castlemock:1.37
docker run -d -p 9000:8080 -v $(pwd):/root/.castlemock --name castlemock castlemock/castlemock:1.37
Create rest project, application, resource and GET method
Add following body to a new response:
{
"test": "test",
"abc": ${RANDOM_BOOLEAN()}
}
Call the REST service and see response:
{
"test": "test",
"abc": ${RANDOM_BOOLEAN()}
}

Expected behavior
abc should be a random boolean.
Screenshots

Desktop (please complete the following information):

OS: mac - docker
Browser n/a
Version docker image 1.37

Hi @jorgeagarzone.
I can see that you haven’t enabled expressions on the mock page. Check the checkbox “Use expressions”, save and try again. I hope it helps.
Best regards,
Karl Dahlgren

I am just blind and had not seen the checkbox , jejejej thanks man.

Haha, no problem.
Feel free to create another issue if you get blind again and need some support =)
Good luck!
Best regards,
Karl Dahlgren


Password protect web UI

Is it possible to password protect the web UI, so that I can buy a domain and use cloudflare tunnels to access it remotely? Example below (pulled from StackOverflow)

You can probably do this in the lighttpd config directly, though I don't have the details to hand.


minor: change ouput_schema

It's may be not right for KeyCalculationExtension.output_schema. I notice that output_schema is depend on self.input.schema
https://github.com/ArroyoSystems/arroyo/blob/68fb412bfd15e706e59cbaac8295942d30badfee/crates/arroyo-planner/src/extension/key_calculation.rs#L112-L115
But according to func new_named_and_trimmed, the schema of KeyCaclculationExtension may not equal to self.input.schema
https://github.com/ArroyoSystems/arroyo/blob/68fb412bfd15e706e59cbaac8295942d30badfee/crates/arroyo-planner/src/extension/key_calculation.rs#L39-L57

Sorry, wrong understand


VcfFilter subset

Implements a -subSet option in vcfFilter, in which the user can provide a float between 0 and 1 to retain a proportion of variants in the output file. Pseudorandom, so it will not guarantee a particular number of variants in the output.
This serves as an alternative to sampleVcf, which already has a similar functionality for producing subsets of Vcf files. However, sampleVcf reads the whole Vcf into memory, shuffles the slice of Vcf structs, and returns a precise number of variants. While this is useful, say if you wanted precisely 1000 variants, this program is not memory efficient. To get precisely 1000 variants from a large vcf file, I would recommend first subsetting with vcfFilter to perhaps 1M variants and then further subsetting with sampleVcf to get the final product.
Passes tests.
I also reorganized a bit of code related to sampleVcf for clarity (mainly moving some code into a helper function)

I am trying to survey the status of our pull requests.  I think this one is waiting on an update to remove the option to run with a random seed.  Is that correct?  If that is true, I think we could merge without that, since it is not a bug, and a later pull request could remove the random seed option from this and possibly other programs.


Move the testbed federation config to the production repositories

Part of https://github.com/SovereignCloudStack/issues/issues/412

Removed comments and moved the other one on  top of the parameter


Feature/create cluster

This PR is to enable 2 things, which will be amazing for next level of AKS Developer Experience we could aim for. ❤☕

Multi Step Wizard Mechanism.
Minimalistic Create Standard AKS Cluster

Details: (Please also refer to screenshots below)
The Create Cluster will appear as a subscription level subMenu, the key thing about this feature drop is that this feature is short, needs least input form the user and all user need to add is the valid cluster name and in step-2 select the Predefined resource group name form the drop down.
With this experience we are enhancing the developer experience and now fully one-click functionality to create standard cluster with just 2 steps from VsCode.
User will right-click on their subscription in the tree note, select Create Standard Cluster --> which will initiate a 2 step wizard - Ste-1 : Will accept valid cluster name and Step-2 : Select Resrouce Group Name - as a location the location of the resource group name will be taken as the location of the cluster and all user need to do is now setback and let VsCode experience do its thing call the aks managed operation and in the end user gets served with message box with click -> nav to the portal cluster page which will take user to the exact cluster which is created.
Thanks all, @peterbom , @rzhang628 , @qpetraroia and fyi : @gambtho ❤☕ 🎊
This kind of originated from this discussion here: https://github.com/Azure/vscode-aks-tools/discussions/204
workflow:

Looks great @Tatsinnit, is there a vsix I can test?


sink(ticdc): asynchronously close the mq producers

What problem does this PR solve?

Issue Number: close #4241
What is changed and how it works?
as suggested by https://github.com/pingcap/tiflow/pull/4249#issuecomment-1099812788, close the sink asynchronously.
close the producer (kafka / pulsar) in an asynchronous way.
Check List
Tests

Manual test (add detailed scripts or steps below)

Master branch, close the sink Manager would block a period of time.

This PR, sink Manager closed immediately, does not block the processor's progress.

Code changes
Side effects
Related changes
Release note
None

/run-kafka-integration-test

/run-kafka-integration-test

/run-kafka-integration-test

Can we do some correctness tests? For example, the correctness of shutting down the producer asynchronously after encountering a kafka error and resuming it again?

It looks already covered by the integration test kafka_sink_error_resume ?

/run-kafka-integration-test

/run-all-tests

/run-all-tests

/run-integration-test
/run-kafka-integration-test

Can we do some correctness tests? For example, the correctness of shutting down the producer asynchronously after encountering a kafka error and resuming it again?

It looks already covered by the integration test kafka_sink_error_resume ?

I don't think it's the same as the scenario where we actually have a problem? Otherwise this integration test should have caught the problem long ago?

Can we do some correctness tests? For example, the correctness of shutting down the producer asynchronously after encountering a kafka error and resuming it again?

It looks already covered by the integration test kafka_sink_error_resume ?

I don't think it's the same as the scenario where we actually have a problem? Otherwise this integration test should have caught the problem long ago?

Can we do some correctness tests? For example, the correctness of shutting down the producer asynchronously after encountering a kafka error and resuming it again?

It looks already covered by the integration test kafka_sink_error_resume ?

I don't think it's the same as the scenario where we actually have a problem? Otherwise this integration test should have caught the problem long ago?

I think the test purpose is that the producer asynchronously closed after encountering a kafka error and resuming it again, it's should be covered already.

Otherwise this integration test should have caught the problem long ago?

Do you mean the problem that blocked a long time? It's not covered by the case  kafka_sink_error_resume, so that does not expose the problem.  Let's have a try to cover it by the integration test.

Can we do some correctness tests? For example, the correctness of shutting down the producer asynchronously after encountering a kafka error and resuming it again?

It looks already covered by the integration test kafka_sink_error_resume ?

I don't think it's the same as the scenario where we actually have a problem? Otherwise this integration test should have caught the problem long ago?

I think the test purpose is that the producer asynchronously closed after encountering a kafka error and resuming it again, it's should be covered already.

Otherwise this integration test should have caught the problem long ago?

Do you mean the problem that blocked a long time? It's not covered by the case  kafka_sink_error_resume, so that does not expose the problem.  We have some test in test-infra to inject chaos to make the problems happens periodically. I will try to cover it in the integration test.

/run-verify-ci

Do we only need the two versions of cherry-pick?

Can we add asynchronous close only to the close method of mq sink so that we don't need to add a new interface for the producer and write duplicate code. This behavior should really just be a special case of an mq sink close.

Or maybe we can pass ctx directly into close, I don't know how to do that better. cc: @asddongmen @overvenus @3AceShowHand  What do you think?

/run-verify-ci

Can we add asynchronous close only to the close method of mq sink so that we don't need to add a new interface for the producer and write duplicate code. This behavior should really just be a special case of an mq sink close.

Or maybe we can pass ctx directly into close, I don't know how to do that better. cc: @asddongmen @overvenus @3AceShowHand What do you think?

I would prefer the current implementation, it looks simple enough.

Can we add asynchronous close only to the close method of mq sink so that we don't need to add a new interface for the producer and write duplicate code. This behavior should really just be a special case of an mq sink close.

Or maybe we can pass ctx directly into close, I don't know how to do that better. cc: @asddongmen @overvenus @3AceShowHand What do you think?

maybe we can pass ctx directly into close

Do you mean Producer.Close()?  It looks like we have to start a goroutine just like now.
The current one is simple enough I think.

/run-verify-ci

/run-all-tests

/run-integration-test

/merge


Update PowerShell script to install Winget in Windows Sandbox

The original script actually contained a typo. I have created #4264 to fix this, as well as get the latest Winget and install the required dependencies. I believe the PR is ready to merge, it just needs someone to approve and merge. If I have done something wrong or it needs improving then please let me know.

Thank you @glawrence . This issue was fixed in https://github.com/MicrosoftDocs/windows-dev-docs/commit/ca90ce0471458f85af6dc789200b263affcfd8ec


Update ModelDB documentation to V2

Thanks for raising this issue @mvartakAtVerta - will you be working on the docs to resolve this issue?

Yes, I'll be working on these docs.
ᐧ
On Wed, Mar 27, 2019 at 7:32 AM Sarah Maddox<EMAIL_ADDRESS>wrote:

Thanks for raising this issue @mvartakAtVerta
https://github.com/mvartakAtVerta - will you be working on the docs to
resolve this issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/website/issues/560#issuecomment-477182748,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aq71Og4riBJXLacEPOMvHZMRPS4EbeMlks5va4EAgaJpZM4cMviJ
.

@mvartakAtVerta Would you like to tackle this issue during the Kubeflow Doc Sprint (July 10-12)?

Is this planned to be done soon?

Related issue: https://github.com/kubeflow/website/issues/943

I'm closing this issue as there's been no activity on it for 9 months. If anyone would like to work on a ModelDB doc, please do re-open the issue.
/close


Add payment and personal chat when paid.

Added the chat. Left for me to add is payment with stripe.

Added payment with stripe. Need to edit the checkout page and to make the chat available for 24hours after the payment.

Users can send files - images and others via chat.


Add 'ob deploy build' command

As discussed in https://github.com/obsidiansystems/obelisk/issues/368
I have:

[x] Based work on latest develop branch
[x] Followed the contribution guide
[x] Looked for lint in my changes with hlint . (lint found code you did not write can be left alone)
[ ] Run the test suite: $(nix-build -A selftest --no-out-link)
[x] Updated the changelog
[ ] (Optional) Run CI tests locally: nix-build release.nix -A build.x86_64-linux --no-out-link (or x86_64-darwin on macOS)

There's also potential to add the checks done by ob deploy init:
https://github.com/obsidiansystems/obelisk/blob/d89b1a6b696903df0dd74f93bdc9c847ff99b80b/lib/command/src/Obelisk/Command/Deploy.hs#L77-L82
as Ryan mentioned, but I didn't think it made much sense for ob deploy build. I can add ob deploy prepare which would run these checks on top of the build.


Push New Release to NPM

Could you push the new release to npm?

sure. will do this evening

published v0.2.0


Troubles after forking

Hi,
I'm trying to use laraadmin, but I need to make some customizations such as adding multilanguage support.
I've made a fork as said in documentation. But then, when using that fork, I have the following error (updating employees module):
exception 'ErrorException' with message 'Undefined index: listing_col'
in \vendor\dwij\laraadmin\src\CodeGenerator.php:295
After comparing my forked code with published laraadmin code I can see is not the same. Why is this? Do I have to make something else?

I just located what I think is the culprit on line 38 of src/Installs/migrations/2014_05_26_060000_create_module_fields_table.php
$table->boolean('listing_col')->default(true);
It seems to be missing in my migration files, I vendor published well before I forked the repo, so there must have been something missing in between the two. You should be ok with manually creating the column in the db.


pypi versions not properly recognized for wheels-only

For pypi packages which only distribute wheels, e.g., pygmsh, shields.io doesn't generate a proper version badge, https://img.shields.io/pypi/v/pygmsh.svg.

Thanks for this issue. Would like to get this resolved.
Do you think you could make a PR?

Where in the code would I have to look?

Yep, that's the one.
You can run npm install to pull in the dependencies, then node server.js 1111 localhost, and open http://localhost:1111/try.html.
If you don't have node 6+ installed, you'll need that first. Would suggest installing it via nodenv or nvm which are available in most package managers.

I just noticed that it suddenly works. This was probably an issue on pypi's end. Closing.


Removes readme and contributing.md from generate heading lint

Removes readme and contributing.md from generate heading

Yep I did


Disable redundant transitive linking with shared libraries

All targets which depend on shared libraries had to be re-linked before this change which is not needed.

Why not using CMAKE_LINK_DEPENDS_NO_SHARED in your own package instead of forcing that behavior in facelift itself ?

Why not using CMAKE_LINK_DEPENDS_NO_SHARED in your own package instead of forcing that behavior in facelift itself ? What makes you believe that all users of Facelift want that behavior ?

Thanks for that comment. I fully agree with you. Looks like CMake developers already tried to make it default behaviour:
https://cmake-developers.cmake.narkive.com/dTGZ68X4/should-cmake-link-depends-no-shared-be-on-by-default.
It needs to be reverted.

Why not using CMAKE_LINK_DEPENDS_NO_SHARED in your own package instead of forcing that behavior in facelift itself ? What makes you believe that all users of Facelift want that behavior ?

I see at least two problems with the current implementation of the facelift macros:

You will need to recreate "facelift_add_library" macro logic in the upper layer to add set_target_property only for non-interface libraries (INTERFACE library can't have LINK_DEPENDS_NO_SHARED set).
Library name might differ from the one you requested. Looks like it might be not an issue because it goes only for INTERFACE and OBJECT libraries (I'm not sure about OBJECT)
set(TARGET_NAME ${TARGET_NAME}_)
or
set(IMPLEMENTATION_TARGET_NAME ${TARGET_NAME}_OBJECTS)

So my questions are:

What were the reasons to change the given target name inside facelift_add_library?
Why facelift_add_library changes given library type? (logic could be more straightforward - for example, you need always provide library type and the function will only validate if the entire configuration is correct)

If I'm wrong please correct me. If I've missed any documentation which contains answers to my questions I would be glad to see it:)

Why not using CMAKE_LINK_DEPENDS_NO_SHARED in your own package instead of forcing that behavior in facelift itself ? What makes you believe that all users of Facelift want that behavior ?

I see at least two problems with the current implementation of the facelift macros:

You will need to recreate "facelift_add_library" macro logic in the upper layer to add set_target_property only for non-interface libraries (INTERFACE library can't have LINK_DEPENDS_NO_SHARED set).

AFAIU, you simply need to set CMAKE_LINK_DEPENDS_NO_SHARED once for all, before calling facelift_add_library.

Library name might differ from the one you requested. Looks like it might be not an issue because it goes only for INTERFACE and OBJECT libraries (I'm not sure about OBJECT)
set(TARGET_NAME ${TARGET_NAME}_)
or
set(IMPLEMENTATION_TARGET_NAME ${TARGET_NAME}_OBJECTS)

So my questions are:

What were the reasons to change the given target name inside facelift_add_library?
Why facelift_add_library changes given library type? (logic could be more straightforward - for example, you need always provide library type and the function will only validate if the entire configuration is correct)
The reason is the monolithic build. See the corresponding doxygen-based documentation (added by https://github.com/Pelagicore/facelift/commit/ad90feb9501b233792e3e136a789ff35afbc7e4f#diff-4636a4bb7c60c257a6c8e053e025ce49).

If I'm wrong please correct me. If I've missed any documentation which contains answers to my questions I would be glad to see it:)

Please


Under the images screen, I would like to have a update button, which would check for updates of an image.

Is your enhancement related to a problem? Please describe
Would be nice to be able to easily update one or more all images in your store.
Describe the solution you'd like
Add updat image (Greyed out if none selected).  If I select then do a podman pull of all selected images to see if their are updates available.
Describe alternatives you've considered
No response
Additional context
No response

I think the first step is a button update that only pull the same image name/tag (and if remote tag is not existing then of course it'll say there is an error)

We could for example have a Fetch Update button on the top right, and Podman Desktop could filter images that are linked to a registry (not localhost), and image with a tag without sha256, to check for update.

I can named an image docker.io/httpd:florent and it's not a tag available on the remote (even if I used a good prefix)
First step = only update the image if clicked
Later improvement: periodic checks / status indicator, etc.

I can named an image docker.io/httpd:florent and it's not a tag available on the remote (even if I used a good prefix)

In that case if the tag is not available, we could have a push icon (ideas, not in the first step, need discussion etc.)

I think the first step is a button update that only pull the same image name/tag (and if remote tag is not existing then of course it'll say there is an error)

I think we should reuse the Pull Image page to do the update, as error handling etc. is something complex. Here is a quick POC, where I added an Update Image action to images that redirect to the Pull Image page with prefilled input.
https://github.com/user-attachments/assets/d6383f80-1daa-4649-8011-4db5b675c56f

⚠ this require change in a few component, first the Typehead component do not take default value, so this is a problem; the PullImage need a mechanism to received image to pull, here I quickly use the query param and use router.goto('images/pull?imageName=...')

I will mark this issue as postponed and add it to the next  Bi-Weekly Team meeting so we can discuss this in more depth.
Here is the POC branch for reference https://github.com/axel7083/podman-desktop/tree/poc/image-update-mechanism


JNI_CreateJavaVM()

Do you have plans to add JNI_CreateJavaVM()?

Feel free to open a PR adding anything that's missing!

I think it should be fn JNI_CreateJavaVM(pvm: *mut *mut JavaVM, penv: *mut *mut c_void, args: *mut c_void); but i am a bit lost at trying to use it: https://github.com/kud1ing/rucaja/blob/master/src/main.rs

I have only personally used JNI from the other direction unfortunately.

Do you have any idea how to create a *mut *mut in Rust in general?

For penv? From the docs it looks like that's an out pointer where JNI will place the JniEnv, so it'd look something like
let mut jvm = ptr::null_mut();
let mut env = ptr::null_mut();
let mut args = /* ... */;

let ret = JNI_CreateJavaVM(&mut jvm, &mut env as *mut _, &mut args as *mut _);

Thank you. It compiles now (had to change args: *mut c_void to args: *mut JavaVMInitArgs though), but gives a Segmentation fault: 11.

Well ok, the C++ version crashes too.

Thank you for your support. I am now able to call a Java method from Rust.
fn JNI_CreateJavaVM(pvm: *mut *mut JavaVM, penv: *mut *mut JNIEnv, args: *mut JavaVMInitArgs) -> jint;

works for me, while the direct translation of jni.h would probably be
fn JNI_CreateJavaVM(pvm: *mut *mut JavaVM, penv: *mut *mut c_void, args: *mut c_void);

What do you think?

I prefer to stick to an exact translation of what the header contains personally.

In this case we'd need to overcome this error:
casting &mut *mut *const jni_sys::JNINativeInterface_ as *mut *mut std::os::raw::c_void is invalid

You have to first cast to *mut *mut *const jni_sys::JNINativeInterface_ and then to *mut *mut c_void.

Thanks.


Fixing bug #138 maintainer name in provenance files

Fixes #138
For some reason I could not test because of a broken vendor package. Are you using go 1.9+? I was building and trying to run tests with 1.8
vendor/go.uber.org/zap/field.go:33: syntax error: unexpected = in type declaration

awesome thanks!
@Cryptophobia please try with Go 1.10+ and let me know if this passes

Yes, already tried. Passes with Go 1.9.7 :+1:  . Did not do the full e2e test with all the storage providers just AWS.


Fix broken Ollama link

What does this PR do?
Fixes a broken Ollama link and formatting on this page: https://llama-stack.readthedocs.io/en/latest/distributions/self_hosted_distro/ollama.html

To:

Before submitting

[x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).

Hi @yanxi0830,
Thanks for the opportunity to contribute! I'm really excited about where this project is headed. Thanks for allowing contributors like me to get involved. I've recently merged a PR into the llama-recipes repository (link) and @wukaixingxp mentioned that llama-stack is a core focus area for your team so I've submitted two PRs to llama-stack [1] [2]. I'm keen to continue contributing 🙏.
My main goal is actually to join Meta AI (ideally with the llama team). The opportunity to work on a technology with such potential fires me up, and I want to be part of its journey.
This is a stack-ranked list of areas that I think I should focus on next:

Improving the quality of Retrieval results
I've been getting some 500 errors when uploading a lot of documents to the memory banks / different mime-types.
VLLM / OpenAI Compatible endpoint support
Tool Registry for Agents
Disable code_interpreter in tool-calling agent

I'd be keen to know which areas you consider most vital or if there’s other issues I could help address. It seems that you guys are currently focused on an internal roadmap and don't have much capacity for reviewing non-documentation PRs at the moment. If that's the case, is there anything I can do to help you make faster progress towards that roadmap and help make llama-stack a huge success?
Please consider me a resource for your team—I'm here to help wherever I can make the most impact.


Error on compiling for Android

Hey, thanks for this awesome lib!.
I'm configuring it for Android and I get an error when I run: react-native run-android:
Building and installing the app on the device (cd android && ./gradlew installDebug)...

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':app'.
> A problem occurred configuring project ':react-native-google-signin'.
   > Could not resolve all dependencies for configuration ':react-native-google-signin:_debugCompile'.
      > Could not find com.google.android.gms:play-services-auth:8.3.0.
        Searched in the following locations:
            file:/home/pjnovas/.m2/repository/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.pom
            file:/home/pjnovas/.m2/repository/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.jar
            https://jcenter.bintray.com/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.pom
            https://jcenter.bintray.com/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.jar
            http://dl.bintray.com/mkonicek/maven/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.pom
            http://dl.bintray.com/mkonicek/maven/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.jar
            file:/home/pjnovas/adt-bundle-linux-x86_64-20131030/sdk/extras/android/m2repository/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.pom
            file:/home/pjnovas/adt-bundle-linux-x86_64-20131030/sdk/extras/android/m2repository/com/google/android/gms/play-services-auth/8.3.0/play-services-auth-8.3.0.jar
        Required by:
            TourneyReact:react-native-google-signin:unspecified

I'm at Ubuntu 14.04 and Node 5.1.1
Any ideas?, thanks!

If you open android SDK manager (with android), under Extras I suspect the Google Play Services are missing. Click to install and you should be fine ;)

@devfd thanks for the quick response, I've tried to install it and the error is still the same, I'm with react-native 0.16 and for Android I have installed only the necessary for react-native, maybe I'm missing another package? (I'm new to Android)

@devfd thanks for the help, it was a problem with my pc and the instalation of the sdk, I end up trying in another pc with ubuntu and copying from there the entire extras folder.


Lab 8 Test6_1

Summary
Any idea why my sword is shimmering so many times, it is not my add method but smtg else but i cant figure it out
Description of the question / problem here.
Description:
Clarifications or details with respect to the issue you are facing
Code Snippets
Attach code snippets (if any)
Screenshots
Screenshots (if any)

You may want to check that went you go from eg. Room 1 to Room 2, if you Sword is being taken on hand, the sword in Room 1 should move into Room 2 and Room 1 does not have any Sword left. Hope this helps!

I think it might be that you didnt remove the sword from the previous room. When you take sword and bring it to next room, the room you left from should not have a sword anymore

i believe that you need to remove the sword from the first room first when you bring the sword to the next room

you should remove the sword once it is taken, this could be the reason the sword appears so many times!


Glaz counters Smoke

Does this counter exist on the graph currently?
No
Counter information

Operator doing the countering: Glaz
Operator being countered: Smoke
Counter level: Soft Counter
Description of how one operator counters the other operator: The Thermal Feedback System on Glaz's OTs-03 can see through Smoke's Gas Grenades.

Do you think the community would agree with this information?
The graph is made less readable when more information is added to it. Are you sure this is a worthwhile change? This was a community suggestion and I think it does let Glaz abuse Smoke's ability. Definitely a soft counter, probably not hard.

Fixed by #140


Contact diary edit screens (EXPOSUREAPP-4161 EXPOSUREAPP-4162)

Contact diary edit screens for location and person
incl. bottom sheets

Left some comments.
Tested branch on Pixel 2 device. Working good so far.


docs: note about explicit saml client cleanup

Oh, that was fast! Thank you @leleuj!

Thank you for your contribution.


Titlebar-less view for Windows

A concept based on @flagello’s Essence

Key idea:

Use the “Great VS Button” to call out the main menu.
The title-bar-like zone is used for tabs/editor panel titles.

Very cool ideas 👍

Wow.
I love how the dark theme spans to the titlebar on Mac too now, but on Windows, you get the same ugly titlebar that does not match the theme and mostly just wastes space. It would be much nicer how Office, Edge etc do it where the design the titlebar merges into the design of the application.

Making better use of the title bar space makes a lot of sense.
We need to make sure that whatever we do satisfies the following requirements:

Users can easily drag the whole window without interfering with their ability to drag individual tabs
Users should continue to be able to see the name of the topmost file in a group when multiple groups are displayed
Users should continue to be able to invoke quick open from a group to open a new file in that group
Users should continue to be able to identify the active group
New users should be able to quickly discover core functionality

We really appreciate the design suggestions. It would be great to hear your thoughts on ways we can meet the above requirements and improve the title bar and overall screen real estate.

Also need to mention Visual Studio here, which does this very nice

@stevencl

Users can easily drag the whole window without interfering with their ability to drag individual tabs

In the tabless mode, the entire title bar can be used to drag the window, while the “group swapping” is replaced by dragging a handle shown when the mouse is over the title bar zone. In the tabbed mode, an extra top margin is added for full-window  dragging, just like Chrome.

Users should continue to be able to see the name of the topmost file in a group when multiple groups are displayed
Users should continue to be able to identify the active group

You can use color, or typography, to stress the current panel.

New users should be able to quickly discover core functionality

The “Great Button” can be stressed to identify that it contains the main menu. Also, the command input can be combined with it (a special tab?)

Users should continue to be able to invoke quick open from a group to open a new file in that group
A Plus button on the tab zone?

I just upgraded to 1.8.0 and the floating effect on menu (i.e. refresh rate) is very annoying to my eyes. To repeat, follow these steps:

Click on Help menu
Move mouse to left side menus (e.g. File/Edit) very fast.
Notice the refresh rate and how it appear to your eye.

@MythicAngel, thanks for the feedback. I think this would probably be best opened as a separate issue though?

Thanks @be5invis. I could see how this would work. I don't think we would even need a handle to enable group swapping. Just clicking in the area of a group that does not contain the name or path of the top most file should kick off the drag.
I'm not convinced by the 'great/hero button' though. Over the last couple of weeks I've watched a large number of people use VS Code for the first time and have observed people taking some time to discover the activity bar and the functionality exposed there. Since this is core to the experience of the product, we would want to decrease the time it takes new users to learn about the activity bar and viewlets. I don't think hiding the activity bar by default would help us there.

I agree. I would just get rid of the titlebar.

@stevencl If you add some animation about stressing the Great Button, they would like to click it, and show the activity bar directly after they click.

-- Sorry for the English, I used Google Translator --
For those who need the title bar, enable / disable suggestion like Firefox. For those who want to continue to show the information they currently have.

The title bar would follow the theme of VSCode or Windows (in this case Windows 10, since it allows you to change the color)? I'm thinking based on the Firefox Gif. Suggestions?
And if the menu bar is active you should get the VSCode theme similar to Firefox. What do you think?

A button with the VS icon (@be5invis  image) would have these functions only if the menu bar was disabled, correct? (If you do not want to delete it)

We need to make sure that whatever we do satisfies the following requirements:

Users can easily drag the whole window without interfering with their ability to drag individual tabs

Note that when we have many tabs open in browsers, they also leave a space between the minimize button and the button for a new tab. Could this space be placed and be used to drag the window?
See that when we lower the Firefox and Chrome window it adds a space so that the entire window can be dragged. Could this space be added to when you have a group of tabs and when the window is dimmed?

New users should be able to quickly discover core functionality

I do not know (a strange idea maybe) ... a simple gif showing which option would like to use (and we clicked it already would put the configuration), saying that these configurations could be changed as it wished? As if it were a welcome screen with a little introduction?
Follow a print (very ugly) to get an idea of how it could stay.
When we leave the Menu bar active.

When we hide the menu bar.

When we have a group of tabs with the Menu bar hidden.

Any update on this?
The current title bar is very distracting.

I also wonder if this will ever tie into the rumoured tabbed shell http://www.windowscentral.com/windows-10-tabbed-shell

any news ?

any update?

Yes. I think the idea of changing the grey title/menu bar to black/dark colors  is much needed here.

I would love to see this.

i'll just mention the atom equivalent to this issue
https://github.com/sindrets/atom-title-bar-replacer

Any Updates on This?

Is this a thing yet?
It looks amazing and I really want this. The community for this product is amazing.

Dec 12 marks the first anniversary of this issue. Cross fingers*

My opinion:
Use the 'VS logo' button in Windows to drag the window since the tabs are also dragable.
In MacOS/Linux replace the 'VS logo' button with their native window control buttons which also provide drag area to move the window (if I'm not mistaken).
I think this is the best solution to this problem because it works on all platforms.

People on small laptop screens are always looking to save screen real estate.
In regard to stevencl's requirements,

Users can easily drag the whole window without interfering with their ability to drag individual tabs

Users should continue to be able to see the name of the topmost file in a group when multiple groups are displayed

Users should continue to be able to invoke quick open from a group to open a new file in that group

Users should continue to be able to identify the active group

New users should be able to quickly discover core functionality

I think it's worth considering that people who actively choose to hide the title bar are, for the most part, advanced users who know what they're doing – who prefer key commands and window managers over poking around the GUI with a mouse. A warning modal could even be added.
You can hide the title bar in Atom (also iTerm) and it works fine. Draggable surfaces are the empty space in the tab bar and the bottom menu bar. You can slightly shade the background of inactive panes/groups to make it clear which is focused. I think this is much more intuitive than reading text in the title bar.

Just to add to Dpren's point, this is something browsers have had for a long time; and for good reason.

@dpren I think we can meet all the requirements @stevencl posted with some smart design ideas:

Users can easily drag the whole window without interfering with their ability to drag individual tabs
Just always leave a little empty space right of the tabs. Nothing will ever go there and they'll always be able to drag the window from there.
Users should continue to be able to see the name of the topmost file in a group when multiple groups are displayed
I don't think the top bar will be an issue on this
Users should continue to be able to invoke quick open from a group to open a new file in that group
Ctrl+P is fine, and it's dropdown menu will just stay on top of the tabs as it does now
Users should continue to be able to identify the active group
It will be the only one with a highlighted tab
New users should be able to quickly discover core functionality
The titlebar-less will be a functionality they'll have to activate (I don't think it's necessary to make it active by default), just as they have the menu bar active by default (and btw, I think the menu bar is far more useful to discover new functionalities than the top bar).
The only issue may be that, by removing the top bar, we'll also have to get rid of the "split editors" and "more" buttons. Again, for useful as they may be I think one will want the top bar gone once he's gotten some confidence with the editor, which means he'll probably have wondered what those little buttons there did, and he could discover the "split editor" thing even just by dragging a tab to the left (that's how I discovered it both here and on Visual Studio).

any news yet?

me too

I guess the best way to do this right now is to know the color that you have near the top bar and then changing the windows accent color to that one.

You can change the color of the near status bar part with this code in the VSCode settings:
"workbench.colorCustomizations": {    "editorGroupHeader.tabsBackground": "#color",    "tab.activeBackground": "#color",    "tab.inactiveBackground": "#color",    "activityBar.background": "#color" }
Then, you in the windows 10 "Change your accent color" settings , there is an advanced color picker option, where you can enter your desired #color.

@Bernardi23 what is that color scheme?

how to hide context menu?

In your VSCode settings:
"window.menuBarVisibilty": false
or, you can press alt to toggle it with this:
"window.menuBarVisibility": "toggle"
On Mon, Aug 20, 2018 at 11:30 AM Vinicius Gati<EMAIL_ADDRESS>wrote:

how to hide context menu?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/17060#issuecomment-414335995,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AicUug68fcqCzputGXgbJ3pmWmaFS9kmks5uSsgAgaJpZM4LKST6
.

I'm a little too late,sorry about that. But I'm using my own settings!
On Sun, Jun 24, 2018 at 10:04 AM 0-1-0-1<EMAIL_ADDRESS>wrote:

@Bernardi23 https://github.com/Bernardi23 what is that color scheme?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/17060#issuecomment-399755122,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AicUurHhpStkT189RmJoX6kOEHfsQkqYks5t_45sgaJpZM4LKST6
.

It's finally added!
On patch 1.26.1 the support for custom titlebar was finally added  for Windows and Linux, although it's still in preview. You just have to add this to your settings:
"window.titleBarStyle": "custom"
You can customize it a little bit as wel, for example:
"workbench.colorCustomizations": { "titleBar.backgroundColor": "#color" }

@Bernardi23 @be5invis

#### Looking amazing!


Mixer takes >10s to receive first snapshot from Galley

Example:
2019-03-28T01:27:27.726465Z    info    Built new config.Snapshot: id='0'
2019-03-28T01:27:39.832587Z    info    Built new config.Snapshot: id='1'

(source: https://storage.googleapis.com/istio-prow/pr-logs/pull/istio_istio/12711/e2e-dashboard/14038/artifacts/dashboard-test-d04eec5ec43944e5917d54/istio-telemetry-6894cbc4d-sh92x_container:mixer.prev.log)
This is more than the expected liveness threshold in Mixer (5s) and causes a livelock with crashlooping.
/cc @ozevren

It's actually second snapshot, not first...


Scrolling issue with tab bar like desktop.

Describe the bug
If I activate the desktop handling with my adressbar at the bottom, so that I have my adressbar on the bottom with the open tabs, a certain point approximately where the fingerprint scanner is does not register touch input.
To Reproduce
Steps to reproduce the behavior:
Have activated webpage at the bottom with the tab bar like desktop and go to a random webpage. Start scrolling and try to hit a point right below where the fingerprint scanner is placed.
Expected behavior
The browser won't register your touch and as long as you keep your finger on the screen, you can move it around as much as you want without any change. You have to lift it up and hit another point on the screen to be able to keep scrolling.

Device: [Samsung s23U
Android Version : [e.g. A12]
Kiwi Browser Version [ e.g. the newest one ]

Additional context
Add any other context about the problem here.
It's like there is maybe a touch hitbox activated which comes with the newly implemented layout of the tab bar.
I started noticing it while reading on webpages and certain scroll touches were not registered. The issue is not there when you turn off this tab handling or go to chrome flags.

I can confirm this issue, it makes the desktop tab switcher unusable. I hope this gets fixed soon as I really like this feature.

Unfortunately in the newest update it still persists. Maybe it's caused because this hitbox is used to bring up the hidden url bar on the bottom while scrolling, and this function got deleted but the hotbox still remains there?


Don't use import class when building with library evolution enabled

Fixes a compiler warning.
Motivation:
Nobody likes warnings.
Modifications:
Just use import Foundation
Result:
Warnings are gone.

@swift-ci please smoke test


Fix Prototype Pollution

📊 Metadata *
Bounty URL: https://www.huntr.dev/bounties/1-npm-flat
⚙ Description *
The flat module is vulnerable against a prototype pollution issue, which is possible through the bypass of the fix proposed previously (hughsk/flat@20ef0ef).
This could lead to RCE through a well known issue when interfacing flat with the handlebars template engine.
💻 Technical Description *
Fixed by adding missing magical attributes, to filter.
-      if (key1 === '__proto__') {
+      if (key1 === '__proto__' || key1 === 'constructor' || key1 === 'prototype') {

🐛 Proof of Concept (PoC) *

Install the package(npm i flat), run the below code:

const { unflatten } = require('flat');
let object = unflatten(JSON.parse('{"prototype":{"test":true}}'));
console.log(object.prototype.test)

Outputs: true.

🔥 Proof of Fix (PoF) *
After fix object is unmodified

👍 User Acceptance Testing (UAT)
After fix functionality is unafected

Congratulations alromh87 - your fix has been selected! 🎉
Thanks for being part of the community & helping secure the world's open source code.
If you have any questions, please respond in the comments section, or hit us up on Discord. Your bounty is on its way - keep hunting!
Come join us on Discord