Customizing the Floating Action Button notch requires rewriting Floating Action Button

The way Floating Action Button creates a notch in a Bottom App Bar, currently I can't change the notch without completely copying the FAB code to make a new button and a new notch.
I think that we can have a more composable API, where the notch computation and the fab widget are orthogonal constructs.
If that's the way we want the API to work, feel free to close.

Can you explain why you had to copy the FAB code?

The code to create the Notch is a part of the private _FloatingActionButtonState, managed here.
I want to try out using different Bezier curves on the edge rounding, but to do that I need to bring all the rest of the code with it.
Ideally, I should be able to pass a ComputeNotch as a parameter to the FloatingActionButton or have a NotchProvider.of(context) that I can set in my app's Theme.

We discussed this offline, and it seems like the best place to move the notch computation is the Scaffold, since it's defining a boundary between the FloatingActionButton and the BottomAppBar.
We can also expose the computation done by the FloatingActionButton currently as a defaultComputeNotch.

I believe originally we thought it will make sense to have the FAB define it's notch, so the shapes of the FAB and the notch are coupled.
If we still think the same we can have the FAB take a ComputeNotch parameter (that has a default value).
Otherwise we can do what Dave suggest - make this a Scaffold parameter.
I'm slightly leaning towards keeping it in the FAB, because I expect the shape of the FAB and the notch to be coupled.
@HansMuller @DaveShuckerow let me know what you think.

@DaveShuckerow in the case you mentioned above did you want to replace the entire notch computation or just change the proportional positioning of some control points?

[per offline discussion with @amirh ]
We could give FloatingActionButton a ComputeNotch valued notchBuilder property. ScaffoldGeometry.floatingActionBarComputeNotch would return the FAB's notchBuilder.
We're hoping that we can remove https://docs.flutter.io/flutter/material/Scaffold/setFloatingActionButtonNotchFor.html. It's unlikely to have been used much and wouldn't be needed anymore.
We'd also provide notch builder functions, with some handy parameters, for circular and diamond shaped notches.

Discussing this some more - since Scaffold#floatingActionButton's type is Widget we would not be able to fetch its notch safely without looking at RTTI.
The options we currently consider:

uncouple the notch computation logic from the FAB (by adding a ComputeNotch property to Scaffold)
have Scaffold check if the type of floatingActionButton is a 'NotchMaker' (name TBD)
keep the setFloatingActionButtonNotchFor protocol

The Scaffold's FAB can be any widget at all, so - for 2 - in addition to making FloatingActionButton implement NotchMaker, we'd probably also have to provide a NotchMakerHolder widget like PreferredSize.
The  setFloatingActionButtonNotchFor protocol doesn't really work, since it has to be possible to build a Scaffold for which the NotchMaker is defined.
I think #1 is the best solution, since it's simpler than 2, and 3 (our current solution) doesn't work in general.

I agree about option 1 being both simpler and more useful from an API users' perspective.

There are 2 issues discussed here:

Customizability of the FAB notch (issue raised in the first comment)
Changing the notchmaker API so that it is set in a more 'Fluttery' way by passing parameters to Widget constructors.

Looks like we know what to do with #2.
Regarding #1, @DaveShuckerow  can you help me better understand the bits you wanted to customize? was it the s1 and s2 parameters used in the notch computation? or did you want to completely replace the notch computation logic?

From an offline discussion, the requirement is the ability to replace the notch computation.

Fixed by #18372


[FEATURE] Non-textural documents.

Is your feature request related to a problem? Please describe.
I'm interested in experimenting with image-based documents but it appears this currently isn't possible as the core Document class only has a textual representation.  Has any thought been given to adding support for image documents?  This appears to be well supported in the Python langchain project this is modelled after.
Describe the solution you'd like
Would like to see support for image+textual documents.
Describe alternatives you've considered
None possible?
Additional context
None.

@yeroc could you describe your use case in more details? What do you plan to do with the images?
In general, the library can be extended to support images along with the text, but this it too early at this point as no major model provider offers an API to the multimodal models.

@langchain4j Thanks for your interest.  I was hoping to use BLIP/BLIP-2 models to generate captions for photos.  Something along the lines of this article which shows how to do something similar with the Python version of LangChain.


streaming multiple responses from request to http.ServerResponse

Is it possible to stream responses from multiple requests to http server response?
something like-
router.get('/streamingApi',(req,res)=> {
request('http://localhost:3000/first').pipe(res);
request('http://localhost:3000/second').pipe(res);
request('http://localhost:3000/third').pipe(res);
}
I want to return the stream to browser as it arrives, but when I run the above, only the first one pipes and then the connection closes. any suggestions?

Hi @msreekm, have you managed to find the resolution to response streaming? Or going raw http(s) is the only viable option?


Adding a name attribute to any input works on WebAsm and Mobile but crashes on Desktop

Problem

Adding a name attribute to any input crashes the application on form submit.
Steps To Reproduce

Create any input with a name attribute
Try to use it on form submit

Expected behavior
This should not crash on any platform, but crashes on Desktop, while it works on WebAsm and Mobile
Environment:

Dioxus version: 0.3.2
Rust version: 1.67
EDIT: Tested on rust 1.70 and still same problem
OS info: Windows
App platform: Desktop

Example code
pub fn Content(cx: Scope) -> Element {
    cx.render(rsx! {
        main {
            form {
                prevent_default: "onsubmit",
                onsubmit: move |event| {
                    let name = event.values.clone();
                    println!("{:?}", name);
                },

                div {
                    label {
                        r#for: "explain",
                        "Explain"
                    }

                    input {
                        name: "explain",
                        r#type: "checkbox",
                        id: "explain",
                    }
                }

                button {
                    r#type: "submit",
                    "Start Activity"
                }
            }

        }
    })
}

It looks like this issue was fixed after the 0.3 release. If you switch to the git version of dioxus with:
dioxus = { git = "https://github.com/DioxusLabs/dioxus" }
dioxus-desktop = { git = "https://github.com/DioxusLabs/dioxus" }

The example above works as expected

This issue may be closed, as I can confirm that this indeed is not an issue anymore on dioxus desktop.


Slack events cause the bot to try to respond to its own messages

Describe the bug
The slack api will also sent requests to the bot for the messages that the bot is sending. That's well known and it's on purpose.  The problem is that since the composer runtime is calling the dialog manager from the OnTurnAsync, all those events get to the bot and it will start replying to them as if the messages were coming from the user.
Should we prevent this by setting some event handling specific for slack in the composer bot or should these events be discarded at the adapter level?
Version
1.4.0
To Reproduce
Just run a composer bot using the slack-adapter and talk to the bot.
Expected behavior
Only answer the users messages

We've got some ideas on how to improve this, but it will require some changes across the stack. @carlosscastro & @EricDahlvang I'll assign to you for now.
Fundamentally, configured adapters need to the ability to drive the dialog system behavior. But this is something not supported today.

What would you suggest is a good workaround for now?
I moved the execution of the composer dialog to OnActivityMessageAsync but that prevents me from greeting new users in Teams and Web.
Another option I used was leaving it in OnTurnAsync and checking for slack channelId and then if the From.Id is the same as recipient then I would ignore it.
Both involve changing the runtime so not helping anyone that wants to use the default runtime. I'd go with option 2 if it is not solvable in the composer UI.

@cwhitten can you elaborate a bit more on this?

configured adapters need to the ability to drive the dialog system behavior.

@martinlarosa I would suggest you introduce a middleware that tests if the incoming message has a subtype of 'bot_message' or the 'bot_id' field is present, and if so, ignore it. This will tell your bot to ignore any message from any bot.
Alternatively, you can compare the incoming user against the bot's own user ID - however, this requires you to go fetch the bot's user id using one of Slack's APIs, or store it when your bot user is first created.

@martinlarosa, did you have a chance to try out @benbrown's suggestion?

I don't have the time to test that right now. I went with my  option two since I need to handle some events outside of composer, at least with the current version.
So I'm triggering the composer dialog from OnMessageActivityAsync
then in OnConversationUpdateActivityAsync I'm triggering it only if it's not from slack.
Not elegant and probably not a definitive solution, but since I don't need to handle other conversation updates for slack for now, it works.
With current work priorities I'll probably will wait till the next version of composer comes out and see what new options brings along.


Хуйня не рабочая

Сделал все строго по мануалу, пуш не работает, клики не работают как будто в атрибутах проставлен точный путь

Руки не из плеч растут просто
I am disappointed by these people, who instead of supporting modules try to offend authors.
@mosario it definitely works for 10 000+ people. If you need help, you need to provide more details

@gugu just close the pointless issue,  make him learn how to behave in the community 🤷♂

I have no access to do this. I hope someone who has an access can close this shame

@supasate Could you close that issue?


pkg: Latest react version

Codecov Report

Merging #1361 (ef130f5) into docs/fixsite (ca7d47f) will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff              @@
##           docs/fixsite    #1361   +/-   ##
=============================================
  Coverage         97.68%   97.68%
=============================================
  Files                92       92
  Lines              1728     1728
  Branches            345      345
=============================================
  Hits               1688     1688
  Misses               12       12
  Partials             28       28

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ca7d47f...ef130f5. Read the comment docs.


Cross compiling and running asm_tests

Hi,
I am tyring to cross-compile the different test files in the arm/asm_tests directory, and then simulate them using python arm-sim.py <path_to_elf_file>.
For example, when I run the above command with the compiled version of adc_00.S, I get the following output, after which the program gets stuck in an infinite loop and must be manually exited:
sparse memory size 400 addr mask 3ff block mask fffffc00
XXX<PHONE_NUMBER>
WARNING: syscall not implemented: 0

I have the gcc-arm-linux-gnueabi cross-compiler installed.
I would appreciate it if you could point out where I could be going wrong, or if the test files cannot be used in this manner.
Thank you!

Unfortunately we've haven't done a great job keeping track of the state of these tests.  The files in arm/asm_tests are meant to be automatically compiled, executed, and verified using py.test and the test driver arm_asm_tests.py, however, these aren't currently working for me.
However, I am able to compile and run the tests directly (as you are trying to do) successfully. The following is my setup:
  $ arm-unknown-linux-uclibcgnueabi-gcc -nostdlib ../arm/asm_tests/adc-00.S -o /tmp/a.out
  $ python ../arm/arm-sim.py --debug insts,mem,regdump,syscalls /tmp/a.out

NOTE: Using sparse storage
sparse memory size 400 addr mask 3ff block mask fffffc00
XXX<PHONE_NUMBER>
  8094 e3a02001 mov      0
0 :00000000 1 :00000001 2 :00000001 3 :00000000
4 :00000000 5 :00000000 6 :00000000 7 :00000000
8 :00000000 9 :00000000 10:00000000 11:00000000
12:00000000 13:bfffc000 14:00000000 15:00000000
----
  8098 e3a03001 mov      1
0 :00000000 1 :00000001 2 :00000001 3 :00000001
4 :00000000 5 :00000000 6 :00000000 7 :00000000
8 :00000000 9 :00000000 10:00000000 11:00000000
12:00000000 13:bfffc000 14:00000000 15:00000000
----
  809c e3a04000 mov      2
0 :00000000 1 :00000001 2 :00000001 3 :00000001
4 :00000000 5 :00000000 6 :00000000 7 :00000000
8 :00000000 9 :00000000 10:00000000 11:00000000
12:00000000 13:bfffc000 14:00000000 15:00000000
----
  80a0 e0a24003 adc      3
0 :00000000 1 :00000001 2 :00000001 3 :00000001
4 :00000002 5 :00000000 6 :00000000 7 :00000000
8 :00000000 9 :00000000 10:00000000 11:00000000
12:00000000 13:bfffc000 14:00000000 15:00000000
----
  80a4 e3a07001 mov      4
0 :00000000 1 :00000001 2 :00000001 3 :00000001
4 :00000002 5 :00000000 6 :00000000 7 :00000001
8 :00000000 9 :00000000 10:00000000 11:00000000
12:00000000 13:bfffc000 14:00000000 15:00000000
----
  80a8 ef000000 swi      5        syscall_exit( status=0 )
 retval=0 errno=0

0 :00000000 1 :00000001 2 :00000001 3 :00000001
4 :00000002 5 :00000000 6 :00000000 7 :00000001
8 :00000000 9 :00000000 10:00000000 11:00000000
12:00000000 13:bfffc000 14:00000000 15:00000000
----
DONE! Status = 0

Make sure you pass the -nostdlib flag!  If that still isn't working, it may be because your cross compiler is using glibc.  We only explicitly support newlib cross compiler based flows; I'm not sure that should effect these assembly tests but I wouldn't be surprised if that is causing a problem.

Thank you for the prompt reply! I am now able to compile and run the tests using these instructions.
The -nostdlib flag was the key to getting it work.


mod whitelisting?

Right now I am using this plugin to block all loaders. Mainly this is because I don't have the time to research every mod to check if it is "cheaty." I feel like if I allow forge so people can use a minimap, that also lets them use any other mod that is not in the EZP config list.
My understanding is that EZP allows all mods with the exception of a handful in the config list. Is there any way to reverse this function and disallow all mods unless they are whitelisted? In other words, I want to be able to block all mods that are not in the config list.
Is this possible?
Thanks for your time

Hello,
Only the mods in the list can be blocked. If you'd like any others blocked don't hesitate to suggest them and I'll try to block them.
Thanks for using eZProtector!

OK, definitely not what i was looking for, but thank you for your time :)


Transit near me parking icon in tooltip

Summary of changes
Asana Ticket: Transit Near Me | add parking icon for stations with parking
When clicking on a stop in Transit Near Me the tooltip should now have a parking icon(if parking is available)

I believe this is ready for another look over since the wallaby test is failing on master as well

Sweet. I'll merge it in with my admin powers, hoping those other tests will start being less inconsistent soon :)


spirv-diff: Same module produces a diff (OpTypeForwardPointer)

So I by mistake ran spirv-diff on the same module copied to another file and it showed a diff for just OpTypeForwardPointer so I played around with it some smaller examples to isolate the case (note it has same issue for both .spv and .spvasm version as well for both Shader and Kernel examples)
$ cp a.spvasm b.spvasm
$ diff a.spvasm b.spvasm
$ spirv-diff a.spvasm b.spvasm
 ; SPIR-V
 ; Version: 1.6
 ; Generator: Khronos SPIR-V Tools Assembler; 0
-; Bound: 7
+; Bound: 12
 ; Schema: 0
                OpCapability Kernel
                OpCapability Addresses
                OpCapability Linkage
                OpMemoryModel Logical OpenCL
-               OpName %1 "structptr"
+               OpName %7 "structptr"
-               OpTypeForwardPointer %1 UniformConstant
+               OpTypeForwardPointer %7 UniformConstant
           %2 = OpTypeInt 32 0
-          %3 = OpTypeStruct %1 %2
-          %4 = OpTypeStruct %2 %1
-          %5 = OpTypeStruct %2 %2 %1
-          %6 = OpTypeStruct %2 %2 %2 %1
-          %1 = OpTypePointer UniformConstant %3
+          %8 = OpTypeStruct %7 %2
+          %9 = OpTypeStruct %2 %7
+         %10 = OpTypeStruct %2 %2 %7
+         %11 = OpTypeStruct %2 %2 %2 %7
+          %7 = OpTypePointer UniformConstant %8

Original module for reproducing
               OpCapability Kernel
               OpCapability Addresses
               OpCapability Linkage
               OpMemoryModel Logical OpenCL
               OpName %structptr "structptr"
               OpTypeForwardPointer %structptr UniformConstant
       %uint = OpTypeInt 32 0
   %structt1 = OpTypeStruct %structptr %uint
   %structt2 = OpTypeStruct %uint %structptr
   %structt3 = OpTypeStruct %uint %uint %structptr
   %structt4 = OpTypeStruct %uint %uint %uint %structptr
  %structptr = OpTypePointer UniformConstant %structt1

cc @ShabbyX

Thanks for the report, I'll take a look.


Add readme.md for nacos-discovery-provider-example

The examples usually have a very nice readme that walk users through the steps of getting up and running. Unfortunately, the nacos-discovery-provider-example does not have one. Could you please add it?

Ah, apologizes @fangjian0423 I should have checked more carefully before creating a new issue. I used the link you provided in https://github.com/spring-io/start.spring.io/issues/217#issuecomment-543096838. I'll update the metadata to use the link you've provided here instead. Thanks!


bitwarden: build from source, rename bin build to bitwarden-bin

Description of changes
Bitwarden package is now built from source.

Keep the bin-based build around since some may prefer that, and this is also an important package for many to have working and up-to-date.
@Kiwi I have carried you over as a maintainer for the source build. If you do not want that, let me know and I will remove.
Since this may be considered by some to be a “major” change, I have added a release notes entry, but am okay removing it if it is felt unnecessary.
I have not made the version between the two common to allow them to be updated at a different pace, as it remains to be seen how easy maintenance of the source build will be.
I’ve been running the source build for 11+ days now without any problems for my usage. In particular, though, testing of the functionality of the “desktop_native” feature would be appreciated, as that seems most likely to have gone awry—afaik I don’t use anything it does and it’s not clear to me how to exercise it manually.
I have renamed the original file to bitwarden-bin in a separate commit to make the history and per-commit diffs more clear.

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

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

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

[x] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

bitwarden-bin works well but bitwarden failed to build.

$ nix run github:nixos/nixpkgs/pull/212712/head#bitwarden
error: builder for '/nix/store/s8niinrdv5q85fhsbhrvfdwqzsgkn92v-bitwarden-desktop-2023.1.1-npm-deps.drv' failed with exit code 127;
       last 7 log lines:
       > unpacking sources
       > unpacking source archive /nix/store/bkbnk2y7jzzixgqgyn2p3y7mpllcjkvh-source
       > source root is source
       > patching sources
       > /nix/store/vcin1kwfmn4izsm8lcn6706qygf6cqdk-stdenv-linux/setup: line 112: jq: command not found
       > /nix/store/vcin1kwfmn4izsm8lcn6706qygf6cqdk-stdenv-linux/setup: line 112: sponge: command not found
       > /nix/store/vcin1kwfmn4izsm8lcn6706qygf6cqdk-stdenv-linux/setup: line 129: pop_var_context: head of shell_variables not a function context
       For full logs, run 'nix log /nix/store/s8niinrdv5q85fhsbhrvfdwqzsgkn92v-bitwarden-desktop-2023.1.1-npm-deps.drv'.
error: 1 dependencies of derivation '/nix/store/hsprymna30djpjnr6qy7f5lcwb9p1c72-bitwarden-desktop-2023.1.1.drv' failed to build

$ nix log /nix/store/s8niinrdv5q85fhsbhrvfdwqzsgkn92v-bitwarden-desktop-2023.1.1-npm-deps.drv
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/bkbnk2y7jzzixgqgyn2p3y7mpllcjkvh-source
source root is source
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
/nix/store/vcin1kwfmn4izsm8lcn6706qygf6cqdk-stdenv-linux/setup: line 112: jq: command not found
/nix/store/vcin1kwfmn4izsm8lcn6706qygf6cqdk-stdenv-linux/setup: line 112: sponge: command not found
/nix/store/vcin1kwfmn4izsm8lcn6706qygf6cqdk-stdenv-linux/setup: line 129: pop_var_context: head of shell_variables not a function context

The binary build keeps resource files under opt, makes it look cleaner. Can we do the same with the source build?

What's the reason to keep bitwarden-bin around?

Either way, I’m happy to drop it now if that’s preferred.

I'd prefer that. But if someone plans on using the -bin version going forward we can keep it.

@ofborg build bitwarden-bin

If there are none known issues with the source build, I see no benefit in keeping the binary one. (Normally we keep binary builds for big-parallel packages like chromium, and bitwarden might not qualify?)


[Release sdk status] adaptation for testproxy

test link:
https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1289228&view=results

/check-enforcer override


[libepoxy] update to 1.5.10

Describe the pull request

What does your PR fix?
Fixes #27395

Which triplets are supported/not supported? Have you updated the CI baseline?
tripplets unchanged

Does your PR follow the maintainer guide?

Yes

If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

Thanks for the update!


Promote the use of custom.js for theme customizations

One of the biggest problems we have with updating an existing implementation of a theme is that the theme's source code often is modified. Once these edits have been made, it makes it pretty hard to apply updates - especially to a large number of stores. The edits can be made directly to the theme's JS files, or they live as inline scripts scattered throughout the DOM (not good).
custom.js is a file where you can perform theme modification without the need to edit Theme source code or inline JS inside liquid files. When combined with the new version of section.js, you can customize and extend any existing JS in the theme without the need to touch source code.
custom.js itself is very simple, just a empty JS file with maybe some comments. The power of it lies in documentation and examples.

I must admit, I'm guilty of editing theme, cart, etc. I hadn't even thought about the upgradeability of doing so.
If we're not supposed to edit these files, would it not be wise to have them served as a Shopify global asset instead of baked right into the theme files?

The idea of not editing them is fairly recent and we're still investigating if it is indeed the right approach. Not moving forward with an official solution until we're sure its the right one.

Moved to https://github.com/Shopify/theme-scripts/issues/1


cmd_floating: Support enable and disable commands too.

This is especially relevant in combination with for_window, e.g.:
for_window [title="Terminal"] floating enable.

This is one of those where it's easier to review the code without whitespace changes, ie: https://github.com/SirCmpwn/sway/pull/263/files?w=1

Looks good. Will merge once Travis is happy with it.

Thanks!


Just advice

Hey dude,
maybe you can take a look for FuelPHP ORM. They have good example for your ORM :+1:

hey have good example for your ORM

What do you mean?

well, they have pretty good structure I think, and so easy to use.
even I say so I just compare FuelPHP ORM with Yii which using ActiveRecord ORM and yours.

just look at their documentation. I think that will be your reference to build ORM sytax more easy :smile:

Thanks.
Is it a separate package that can be used independently from the framework?

yep and you're welcome.

Thanks.
I appreciate the suggestion.


Update

Descriptions can be found in the respective commits

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@63ebb53). Click here to learn what that means.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main   #21555   +/-   ##
=======================================
  Coverage        ?   48.08%
=======================================
  Files           ?     1032
  Lines           ?   140126
  Branches        ?        0
=======================================
  Hits            ?    67377
  Misses          ?    64660
  Partials        ?     8089

Impacted Files
Coverage Δ

modules/context/context.go
66.59% <100.00%> (ø)

modules/setting/setting.go
50.48% <100.00%> (ø)

modules/templates/base.go
64.36% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@Justman10000 please read the contributor guide.

Too much break changes. And the PR's aim is not clear.

What a thing? I tested everything locally! It works...

@Justman10000 you need to (at least):

Name your PR with a short summary of your change
Explain why you made the change in the PR description and show what changed (usually with screenshots)
Show you are a responsible contributor by reading the contributor guide

@Justman10000 you need to (at least):
1. Name your PR with a short summary of your change

2. Explain why you made the change in the PR description and show what changed (usually with screenshots)

3.  I'm sure you've noticed that all commits have descriptions, which means that no unique title for the PR is possible!
Then I would need about 5-10 screenshots! No thanks... Besides, you put up the code, then you will understand it too
...

@Justman10000 you need to (at least):
1. Name your PR with a short summary of your change

2. Explain why you made the change in the PR description and show what changed (usually with screenshots)

3.  I'm sure you've noticed that all commits have descriptions, which means that no unique title for the PR is possible!
Then I would need about 5-10 screenshots! No thanks... Besides, you put up the code, then you will understand it too
We all know that no one reads through this....

As I said, I have tested everything and it works

I'm sure you've noticed that all commits have descriptions, which means that no unique title for the PR is possible!

If you had read the contributing guidelines you would see that the merge commit is named using the PR title. To have a sensible git tree history, we can't have commits say "Update". If you can't give your PR a unique title it means your changeset changes more than one thing. Therefore you should split it into multiple PRs (small diffs are better).

Then I would need about 5-10 screenshots! No thanks... Besides, you put up the code, then you will understand it too

As the author of a PR, it's your responsibility to convince the maintainers to merge your PR. Attaching screenshots shows your PR adds value and is a good tool to convince the maintainers to merge.

We all know that no one reads through this....

That's wrong. These guidelines are important to avoid bad PRs and you should read them if you want your PR merged.

As I said, I have tested everything and it works

The build is failing.

Sorry but I also agree with other maintainers and contributors' comments.
I think the changes of this PR are too many and some of them are lacking of thinking. At the mean time  the complexity it brings seems much bigger than the benefit  it brings.
TBH, I  can not imagine a real scenario that a site admin tries to set these  values to true/false/false/true/true/false to fine tune the UI. Why do they need such combination? If they  want to customize Gitea, there are already a good approach https://docs.gitea.io/en-us/customizing-gitea/ , they could just edit the templates. They could also empty the footer.tmpl to get what they want.
And one more thing, although you swear that "I have tested everything and it works", but if "ShowFooter=false", then where are the rendered JS and CSS resources? And please be polite first .... mentioning f**king won't help anything.

Sorry but I also agree with other maintainers and contributors' comments.
I think the changes of this PR are too many and some of them are lacking of thinking. At the mean time the complexity it brings seems much bigger than the benefit it brings.
TBH, I can not imagine a real scenario that a site admin tries to set these values to true/false/false/true/true/false to fine tune the UI. Why do they need such combination? If they want to customize Gitea, there are already a good approach https://docs.gitea.io/en-us/customizing-gitea/ , they could just edit the templates. They could also empty the footer.tmpl to get what they want.
And one more thing, although you swear that "I have tested everything and it works", but if "ShowFooter=false", then where are the rendered JS and CSS resources? And please be polite first .... mentioning f**king won't help anything.

It's about being able to hide things like the copyright...

It's about being able to hide things like the copyright...

Since there are too many UI elements, I think the customized-template  ( https://docs.gitea.io/en-us/customizing-gitea/ ) works better for this requirement.
Gitea is for everyone, each user would have their preference, but Gitea can not continue adding more and more options, it will a mess in the end.

It's about being able to hide things like the copyright...

Since there are too many UI elements, I think the customized-template ( https://docs.gitea.io/en-us/customizing-gitea/ ) works better for this requirement.
Gitea is for everyone, each user would have their preference, but Gitea can not continue adding more and more options, it will a mess in the end.

Is it possible to overwrite the copyright somewhere?

It's about being able to hide things like the copyright...

Since there are too many UI elements, I think the customized-template ( https://docs.gitea.io/en-us/customizing-gitea/ ) works better for this requirement.
Gitea is for everyone, each user would have their preference, but Gitea can not continue adding more and more options, it will a mess in the end.

Is it possible to overwrite the copyright somewhere?

That is what the templates are for. Look at thos page and you will see it isnt stock
https://codeberg.org/
Likewise please review https://docs.gitea.io/en-us/customizing-gitea/

It's about being able to hide things like the copyright...

Since there are too many UI elements, I think the customized-template ( https://docs.gitea.io/en-us/customizing-gitea/ ) works better for this requirement.
Gitea is for everyone, each user would have their preference, but Gitea can not continue adding more and more options, it will a mess in the end.

Is it possible to overwrite the copyright somewhere?

That is what the templates are for. Look at this page and you will see it isnt stock
https://codeberg.org/
Likewise please review https://docs.gitea.io/en-us/customizing-gitea/

Hmm, interesting! Well, I wasted all my time again


Deployment on GCloud Run fails with Streamlit error

I got thru most of the steps to deploy on Google Cloud Run fine.  IAM service accounts set up and Docker images built fine.  Then I get an error for streamlit starting.
Perhaps there's a build incompatibility from MacOS Apple M1 silicon to Google Cloud Run?
john@johns-MacBook-Air langchain-streamlit-docker-template % gcloud run deploy langchaindocs-app --image=us-west4-docker.pkg.dev/langchaindocs/app/langchaindocs-app:latest \
    --region=us-west4 \
<EMAIL_ADDRESS>Allow unauthenticated invocations to [langchaindocs-app] (y/N)?

Deploying container to Cloud Run service [langchaindocs-app] in project [langchaindocs] region [us-west4]
⠏ Deploying new service... Revision 'langchaindocs-app-00001-cey' is not ready and cannot serve traffic. The us
er-provided container failed to start and listen on the port defined provided by the PORT=8080 environment vari
able. Logs for this revision might contain more information.

LOGS:

2023-06-22 22:46:31.781 PDT
terminated: Application failed to start: Failed to create init process: failed to load /app/.venv/bin/streamlit: exec format error
[Open in Logs Explorer](https://console.cloud.google.com/logs/query;query=resource.type%20%3D%20%22cloud_run_revision%22%0Aresource.labels.service_name%20%3D%20%22langchaindocs-app%22%0Aresource.labels.location%20%3D%20%22us-west4%22%0A%20severity%3E%3DDEFAULT;timeRange=2023-06-23T05:46:31.781088098Z%2F2023-06-23T05:46:31.781088098Z--PT1H;pinnedLogId=2023-06-23T05:46:31.781088098Z%2F649531b7000beb49347c9fff?authuser=1&project=langchaindocs)
{
insertId: "649531b7000beb49347c9fff"
labels: {1}
logName: "projects/langchaindocs/logs/run.googleapis.com%2Fvarlog%2Fsystem"
receiveTimestamp: "2023-06-23T05:46:31.782735362Z"
resource: {2}
severity: "ERROR"
textPayload: "terminated: Application failed to start: Failed to create init process: failed to load /app/.venv/bin/streamlit: exec format error"
timestamp: "2023-06-23T05:46:31.781088098Z"
}

Here's the build results - I mostly imagine that the streamlit binary is incompatible on the Cloud Run image??
john@johns-MacBook-Air langchain-streamlit-docker-template % DOCKER_BUILDKIT=1 docker build --target=runtime . -t us-west4-docker.pkg.dev/langchaindocs/app/langchaindocs-app:latest
[+] Building 3.3s (16/16) FINISHED
 => [internal] load build definition from Dockerfile                                                       0.0s
 => => transferring dockerfile: 1.00kB                                                                     0.0s
 => [internal] load .dockerignore                                                                          0.0s
 => => transferring context: 2B                                                                            0.0s
 => [internal] load metadata for docker.io/library/python:3.11-buster                                      3.2s
 => [internal] load metadata for docker.io/library/python:3.11-slim-buster                                 3.2s
 => [builder 1/6] FROM docker.io/library/python:3.11-buster@sha256:3a19b4d6ce4402d11bb19aa11416e4a262a60a  0.0s
 => [internal] load build context                                                                          0.0s
 => => transferring context: 830B                                                                          0.0s
 => [runtime 1/4] FROM docker.io/library/python:3.11-slim-buster@sha256:c46b0ae5728c2247b99903098ade3176a  0.0s
 => CACHED [builder 2/6] RUN apt-get update && apt-get install -y git                                      0.0s
 => CACHED [builder 3/6] RUN pip install poetry==1.4.2                                                     0.0s
 => CACHED [builder 4/6] WORKDIR /app                                                                      0.0s
 => CACHED [builder 5/6] COPY pyproject.toml poetry.lock ./                                                0.0s
 => CACHED [builder 6/6] RUN poetry install --without dev --no-root && rm -rf /tmp/poetry_cache            0.0s
 => CACHED [runtime 2/4] COPY --from=builder /app/.venv /app/.venv                                         0.0s
 => CACHED [runtime 3/4] COPY ./demo_app ./demo_app                                                        0.0s
 => CACHED [runtime 4/4] COPY ./.streamlit ./.streamlit                                                    0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => writing image sha256:a6c01022c2fc85c7cf46512769638f4eb52cb98adab7c989e285e98ed5e0f80a               0.0s
 => => naming to us-west4-docker.pkg.dev/langchaindocs/app/langchaindocs-app:latest                        0.0s

Have you changed the location of your app? As long as your container is working on Local, it should start on Cloud Run.  Share your Dockerfile.

No the location isn't changed, and the container is working on Local.
john@johns-Air langchain-streamlit-docker-template % docker compose up
[+] Running 2/1
 ✔ Network langchain-streamlit-docker-template_default                 Created                         0.1s
 ✔ Container langchain-streamlit-docker-template-langchain-chat-app-1  Created                         0.1s
Attaching to langchain-streamlit-docker-template-langchain-chat-app-1
langchain-streamlit-docker-template-langchain-chat-app-1  |
langchain-streamlit-docker-template-langchain-chat-app-1  | Collecting usage statistics. To deactivate, set browser.gatherUsageStats to False.
langchain-streamlit-docker-template-langchain-chat-app-1  |
langchain-streamlit-docker-template-langchain-chat-app-1  |
langchain-streamlit-docker-template-langchain-chat-app-1  |   You can now view your Streamlit app in your browser.
langchain-streamlit-docker-template-langchain-chat-app-1  |

And the Dockerfile is unchanged from your original repo.  I'm not sure how to check the compatibility of the streamlit binary with the container's operating system on gcloud.
The only other thing I can think of is authentication on gcloud is off.  But that doesn't appear to be related.

# The builder image, used to build the virtual environment
FROM python:3.11-buster as builder

RUN apt-get update && apt-get install -y git

RUN pip install poetry==1.4.2

ENV POETRY_NO_INTERACTION=1 \
    POETRY_VIRTUALENVS_IN_PROJECT=1 \
    POETRY_VIRTUALENVS_CREATE=1 \
    POETRY_CACHE_DIR=/tmp/poetry_cache

ENV HOST=<IP_ADDRESS>
ENV LISTEN_PORT 8080
EXPOSE 8080

WORKDIR /app

#COPY pyproject.toml ./app/pyproject.toml
#COPY poetry.lock ./app/poetry.lock
COPY pyproject.toml poetry.lock ./

RUN poetry install --without dev --no-root && rm -rf $POETRY_CACHE_DIR

# The runtime image, used to just run the code provided its virtual environment
FROM python:3.11-slim-buster as runtime

ENV VIRTUAL_ENV=/app/.venv \
    PATH="/app/.venv/bin:$PATH"

COPY --from=builder ${VIRTUAL_ENV} ${VIRTUAL_ENV}

COPY ./demo_app ./demo_app
COPY ./.streamlit ./.streamlit

CMD ["streamlit", "run", "demo_app/main.py", "--server.port", "8080"]

I eventually got it to work. You have to build with Cloud Build if you have an M1 Mac.

Closing.


The options for the mountpoint are missing in template

Describe the bug
The options specified for the mountpoint (not the directories) configuration are not being added to the /etc/auto.master.d/00-* file.
Based on the examples given in the REAMDE this should be an available feature:
#   - mountpoint: /net
#     options:
#       - "--timeout=60"

Playbook
Requirements file for ansible-galaxy import:
---
roles:
  - name: robertdebock.autofs
    version: "1.2.6"

Playbook:
---
- name: Deploy autofs mounts
  hosts: all
  become: yes
  gather_facts: yes

  roles:
    - role: robertdebock.autofs

autofs_maps variable:
---
autofs_maps:
  - mountpoint: /home
    options:
      - "--timeout=60"  # <-- This is not being added
    directories:
      - path: "*"
        server: "nfs.server.example:/&"
        options:
          - rw
          - nfsvers=4
          - exec
          - nosuid
          - sync
          - rsize=8192
          - wsize=8192

Output
I don't believe the playbook output is relevant here, instead here are the files created:
root:~ # cat /etc/auto.master.d/00-home.autofs
#
# Ansible managed
#
/home /etc/auto.home

root:~ # cat /etc/auto.home
#
# Ansible managed
#
* -rw,nfsvers=4,exec,nosuid,sync,rsize=8192,wsize=819 nfs.server.example:/&

Problem File
The problem appears to be in templates/template.autofs.j2 on line 2. The template does not have any logic for including options specified for the mountpoint.
A solution would be to update it to loop through the options for the mountpoint and add them if present (based on how the templates/map.j2 template works):
{{ item.mountpoint }} /etc/auto.{{ item.mountpoint | regex_replace('/', '') }} {% if item.options is defined %}{% for option in item.options %}{{ option }}{% if not loop.last %} {% endif %}{% endfor %} {% endif %}

I am making the assumption that the options are separated by a space and not a comma. I can't find any reference material that explicitly states which one it is.
Environment

Control node OS: RHEL 7.9
Control node Ansible version: 2.10.4
Managed node OS: RHEL 7.9

Good find, your PR has been merged, I'll release a new version and close the issue.
Thanks for your pro-active behaviour!

Good find, your PR has been merged, I'll release a new version and close the issue.
Thanks for your pro-active behaviour!

Fixed with version 1.2.7.

Fixed with version 1.2.7.


Reading TCanvases

We have a root file here written by the MAGIC Mars software with the following structure
MStatusDisplay (MStatusArray, thin wrapper around TObjectArray)
  - ...
  - IntMeanPedEx (TCanvas)
    - pad 1 (TPad, canvas.GetPad(1))
         - IntMeanPedEx Mean (MH Camera, a wrapper around TH1)
    - ...
  - ...

Any chance for reading this data using uproot?
Example file here:
example_mars_file.zip

I was looking at this file today. The issue you encountered trying to read this object was a bug, and a rather simple one. It will be fixed in the next version (PR #262).
Beyond that, we can read the array, but not the objects in it:
>>> import uproot
>>> f = uproot.open("issue260.root")
>>> print(f["MStatusDisplay"])'
[<TNamed b'' at 0x77bc282710b8>, <Undefined (failed to read 'TCanvas' version 8) at 0x77bc28271400>,
<Undefined at 0x77bc27a14278>, <Undefined at 0x77bc27a142e8>, <Undefined at 0x77bc27a14358>,
<Undefined at 0x77bc27a143c8>, <Undefined at 0x77bc27a14438>, <Undefined at 0x77bc27a144a8>,
<Undefined at 0x77bc27a14518>, <Undefined at 0x77bc27a14588>, <Undefined at 0x77bc27a145f8>,
<Undefined at 0x77bc27a14668>, <Undefined at 0x77bc27a146d8>, <Undefined at 0x77bc27a14748>,
<Undefined at 0x77bc27a147b8>, <Undefined at 0x77bc27a14828>, <Undefined at 0x77bc27a14898>,
<Undefined at 0x77bc27a14908>, <Undefined at 0x77bc27a14978>, <Undefined at 0x77bc27a149e8>,
<Undefined at 0x77bc27a14a58>, <Undefined at 0x77bc27a14ac8>, <Undefined at 0x77bc27a14b38>]

The first is a TNamed with title b'/data/M1/OSA/Analysis/2019/02/27/sequence_M1_05080236.txt', the second is a TCanvas that can't be read due to missing features in uproot, and the others I don't know. Even the process of identifying what their types are didn't succeed.
If this contains mostly TCanvases or other graphics, I don't see how that would be very useful in Python without the C++ functions that draw them. I'm wondering what would be gained by going through the process of identifying why they couldn't be read and fixing those issues.
(Other than the goodness of doing things right, which is hard to do all the time...)

There are histograms in those tcanvases. De would like to get to the data of the histograms.

Looking into it, the reason all of those class instances are Undefined is because the file has no streamer for TCanvas. Without streamers, I would have to write the "which byte means what field?" code by hand, accounting for different versions of the class. (This is what I would have to convert to Python and maintain.)
I don't know why streamers are sometimes missing—the statement that ROOT files are self-describing relies on those streamers being present; without them, the meaning of the file depends on the C++ (or Python) code that interprets it. In some of these cases, the streamers are in the original ROOT file but missing in a file that was combined by hadd.
How important is it to read these via TCanvas, rather than some other list of histograms, like a TObjArray of TH1F?

How important is it to read these via TCanvas, rather than some other list of histograms, like a TObjArray of TH1F?

The way those files were created is out of our control.

Looking into it, the reason all of those class instances are Undefined is because the file has no streamer for TCanvas.

How would that be changed? Is it an option somewhere for the TFile or how is it determined if thoses streamers are written or not?

I was at first going to say "no," because the streamers are supposed to be automatically added, but I did some digging.
First of all, you can check for the existence of a streamer in ROOT as TFile::ShowStreamerInfo() and uproot as file.showstreamers(). TCanvas isn't in there.
I found this: https://root.cern.ch/doc/master/classTStreamerInfo.html#a1a95df423cc1c955372c82c4e391d87e
TClass::GetClass("TCanvas")->GetStreamerInfo()->ForceWriteInfo(output, kTRUE);

made the difference between a file being written with TCanvas streamers and without.
So then I tried applying it to your file—just opening it in UPDATE mode, calling the above to force writing of TCanvas's streamer, and then TFile::Write and TFile::Close. Attempting to read it back in uproot led to an error that I tracked down to a line in TAttCanvas (a TCanvas dependency). Your TAttCanvas object has a different version than the TAttCanvas streamer that I put into the file. Well, that's to be expected: I wrote a particular version of the canvas streamers into the file, which very likely differs from the particular version of the objects you wrote.
So at the least, we might be able to do it if you ForceWriteInfo the TCanvas streamer into your file in the same version of ROOT that was used to make the file. This sounds fragile and version-dependent, but that's exactly why streamers are supposed to be automatically written to ROOT files: the version dependence is supposed to be shipped with the file so that another version of ROOT (or uproot) can read it.

Thanks for the feedback!
So, in root i did the following:
root [0] gSystem.Load("libmars.so")
(int)0
root [1] TFile* output = new TFile("ssignal05080236.001_M1.root", "UPDATE");
root [2] TClass::GetClass("TCanvas")->GetStreamerInfo()->ForceWriteInfo(output, kTRUE);
root [3] output->Write();
root [4] output->Close();
root [5] .q

And then I tried opening in uproot:
Which gives me
In [1]: import uproot

In [2]: f = uproot.open('ssignal05080236.001_M1.root')

In [3]: print(f['MStatusDisplay;1'])
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-a3dc7540616e> in <module>()
----> 1 print(f['MStatusDisplay;1'])

~/.local/lib/python3.6/site-packages/uproot/rootio.py in __getitem__(self, name)
    236
    237     def __getitem__(self, name):
--> 238         return self.get(name)
    239
    240     def __len__(self):

~/.local/lib/python3.6/site-packages/uproot/rootio.py in get(self, name, cycle)
    347                 if key._fName == name:
    348                     if cycle == key._fCycle:
--> 349                         return key.get()
    350                     elif cycle is None and last is None:
    351                         last = key

~/.local/lib/python3.6/site-packages/uproot/rootio.py in get(self, dismiss)
    914
    915         try:
--> 916             return _classof(self._context, self._fClassName).read(self._source, self._cursor.copied(), self._context, self)
    917         finally:
    918             if dismiss:

~/.local/lib/python3.6/site-packages/uproot/rootio.py in read(cls, source, cursor, context, parent, asclass)
   1269             context = context.copy()
   1270         out = cls.__new__(cls)
-> 1271         out = cls._readinto(out, source, cursor, context, parent, asclass=asclass)
   1272         out._postprocess(source, cursor, context, parent)
   1273         return out

~/.local/lib/python3.6/site-packages/uproot/rootio.py in _readinto(cls, self, source, cursor, context, parent, asclass)

~/.local/lib/python3.6/site-packages/uproot/rootio.py in _readinto(cls, self, source, cursor, context, parent, asclass)
   1279         name = cursor.string(source)
   1280         size, low = cursor.fields(source, struct.Struct(">ii"))
-> 1281         self.extend([_readobjany(source, cursor, context, parent, asclass=asclass) for i in range(size)])
   1282         _endcheck(start, cursor, cnt)
   1283         return self

~/.local/lib/python3.6/site-packages/uproot/rootio.py in <listcomp>(.0)
   1279         name = cursor.string(source)
   1280         size, low = cursor.fields(source, struct.Struct(">ii"))
-> 1281         self.extend([_readobjany(source, cursor, context, parent, asclass=asclass) for i in range(size)])
   1282         _endcheck(start, cursor, cnt)
   1283         return self

~/.local/lib/python3.6/site-packages/uproot/rootio.py in _readobjany(source, cursor, context, parent, asclass)
    479
    480         if asclass is None:
--> 481             obj = fct.read(source, cursor, context, parent)     # new object
    482             if isinstance(obj, Undefined):
    483                 obj._classname = cname

~/.local/lib/python3.6/site-packages/uproot/rootio.py in read(cls, source, cursor, context, parent)
    856             context = context.copy()
    857         out = cls.__new__(cls)
--> 858         out = cls._readinto(out, source, cursor, context, parent)
    859         out._postprocess(source, cursor, context, parent)
    860         return out

~/.local/lib/python3.6/site-packages/uproot/rootio.py in _readinto(cls, self, source, cursor, context, parent, asclass)

~/.local/lib/python3.6/site-packages/uproot/rootio.py in read(cls, source, cursor, context, parent)
    856             context = context.copy()
    857         out = cls.__new__(cls)
--> 858         out = cls._readinto(out, source, cursor, context, parent)
    859         out._postprocess(source, cursor, context, parent)
    860         return out

~/.local/lib/python3.6/site-packages/uproot/rootio.py in _readinto(cls, self, source, cursor, context, parent, asclass)

~/.local/lib/python3.6/site-packages/uproot/rootio.py in read(cls, source, cursor, context, parent, classname)
   1374             context = context.copy()
   1375         out = cls.__new__(cls)
-> 1376         out = cls._readinto(out, source, cursor, context, parent)
   1377         out._postprocess(source, cursor, context, parent)
   1378         out._classname = classname

~/.local/lib/python3.6/site-packages/uproot/rootio.py in _readinto(cls, self, source, cursor, context, parent)
   1384         start, cnt, self._classversion = _startcheck(source, cursor)
   1385         if cnt is None:
-> 1386             raise TypeError("cannot read objects of type {0} and cannot even skip over this one (returning Undefined) because its size is not known\n  in file: {1}".format("???" if self._classname is None else self._classname.decode("ascii"), context.sourcepath))
   1387
   1388         cursor.skip(cnt - 6)

TypeError: cannot read objects of type ??? and cannot even skip over this one (returning Undefined) because its size is not known
  in file: ssignal05080236.001_M1.root

There are streamers for TCanvas and TPad in the file now:
StreamerInfo for class: TCanvas, version=8, checksum=0x80c291f4
  TPad            BASE            offset=  0 type= 0 A Graphics pad
  fCatt           TAttCanvas      offset=  0 type=62 Canvas attributes

Here is the updated file:
mars_file_with_tcanvas_streamer.zip

This is the same thing I tried on my own, with the same result. (Same error message, but when I use Python, not iPython, it gives me more information, that the error occurred in the generated code for TAttCanvas.) Without knowing the ROOT version number that created the TCanvas, I couldn't be sure that the TCanvas streamer I added is exactly the same as the TCanvas objects in the file.
For that matter, I can't be sure of it from your description, either, unless you independently verified that. The place where this fails is where it compares the TAttCanvas object version against the TAttCanvas class-streamer version, sees that it doesn't have a compatible match, and then goes into the "Undefined" code—which wouldn't help you because it's simply trying to skip the object and give you a placeholder—and finds that it can't get the number of bytes it would need to skip.
If you're sure that you have the same ROOT version, do you want to keep pursuing this? I don't know how many issues away from the solution we are—if it's just a matter of getting that version number right or if it's a long chain of fixes for complex graphical object types.
If you have the capability in your workflow to add a streamer to the file, do you also have the capability to copy the histograms to some TObjArray? (In UPDATE mode, just like adding the streamer?) ROOT does some referencing, so it might only "simlink" the histograms. If this kind of intervention—either copying the histograms or adding the streamers—would defeat the purpose of using uproot, maybe it's time to use PyROOT for this part of your workflow.

would defeat the purpose of using uproot, maybe it's time to use PyROOT for this part of your workflow.

I agree. Sadly, I think this will be the way to go. Would have been nice to just get it with uproot.

Without knowing the ROOT version number that created the TCanvas, I couldn't be sure that the TCanvas streamer I added is exactly the same as the TCanvas objects in the file.

Should be 5.36 something, I used the latest 5.36 branch on gihub to write the streamer info, might have been wrong.

Oh, that's also a very old version. There might have been additional difficulties crossing the ROOT 5 → 6 border that I didn't think of.
Sorry that this didn't work out.


Deriving a store from props

My issue copied from Reddit.
What would be the solution to make Easy State work similar to getDerivedStateFromProps? What if I wanted a child component to update the store depending on the props passed from a parent component?
class Parent extends Component {
  store = store({ number: Math.random() });

  handleButtonClick = () => {
      this.store.number = Math.random();
  };

  render() {
      return (

              <button onClick={this.handleButtonClick}>Generate Random Number</button>
              <Child number={this.store.number} />

      );
  }
}

class Child extends Component {
  store = store({
      // number needs to update based on the number prop passed from parent on will receive props
      number: this.props.number + 1,
  });

  render() {
      return
{this.store.number}
;
  }
}

How to derive a store from props on will receive props?

solkimicreb
Ouch, I didn't think about that change :D I guess I could make it work exactly like it is now with two differences.
It would get the first local store on the component as the second argument, instead of the state.
It would merge the returned object with the first local store on the component, instead of the state.
Your example would look like this:
class Child extends Component {
  store = store({
    number: this.props.number + 1
  });

  static getDerivedStateFromProps (props, store) {
    return { number: this.props.number + 1 };
  }

  render() {
    return
{this.store.number}
;
  }
}

This would place a few (tiny) restrictions on components with getDerivedStateFromProps.
These components should not have more than one local store to avoid confusion (of which store would receive the update object from getDerivedStateFromProps).
These components should not use vanilla React state in concjuction with local stores to avoid the above confusion.
Do you think this would be okay? Thanks for the catch (:
Edit: another approach would be to keep the exact current behavior with props and state and pass in a third argument, which is an array of local stores. Those stores could be mutated directly in the function, while the return value would be merged with state (as it is right now.) This feels a bit dirtier, but it would only extend the current behavior, instead of replacing some of it. Would this be better?
Edit2: I think I vouch for the first one, as the restrictions in places are also best practices. It might be beneficial to enforce them.

Thanks for putting the issue here 🙂 I also read your other comment in Reddit since this.
I agree that it shouldn't be called getDerivedStateFromProps. I have two proposals:
1. Don't do anything. Data should be derived with computed properties (getters).
class Child extends Component {
  constructor (props) {
    super(props)

    this.store = store({
      get number () {
        return props.number + 1
      }
    })
  }

  render() {
    return
{this.store.number}

  }
}

I think this is a cleaner approach then having a separate static method, but it might be only my preference.
**2. Add a new deriveStoresFromProps static method.
class Child extends Component {
  store = store({})

  render() {
    return
{this.store.number}

  }

  static deriveStoresFromProps(props, store) {
    store.number = props.number + 1
  }
}

deriveStoresFromProps(props, ...stores) would get the new props and all of the local stores of the component as arguments. It could then mutate the stores directly inside the function.
I am a bit afraid of the static nature of getDerivedStateFromProps. It might cause issues in the future, when it turns out why the React team decided to make it static. I suspect that they want to enforce pureness and idempotency with it.
Which one do you prefer? Both are easily doable, leaves vanilla React behavior untouched and includes now breaking changes.

The first approach is nice, but it's kind of a pain to make a getter for each property. Would the first approach reduce performance if the value is accessed many times continuously? Also, would it be possible to access the this if store was not in the constructor?
store = store({
  // Don't think the `this` refers to the component instance.
  number: this.props.number
});

For the second approach, would each mutation to the store trigger an update to the component? Would it be better for the second approach to be:
static getDerivedStoreFromProps(props, store) {
  if (props.number !== this.store.number) {
    // Store shallowly merged with current store.
    return store({ number: props.number });
  }

  return null;
}

Yes, the static nature makes it seem like they want to further enforce practices on state immutability.

I wouldn't worry about performance for either approach, it won't be an issue. Renders are async batched, multiple synchronous mutations of the same store won't trigger multiple renders.
Yep, the first approach can only be used inside constructor functions. The second approach could work with a return value. I chose to do direct mutation, because this way we can support multiple local stores (there could only be a single return value). Honestly, I don't like it either way 😄  for now.

Dang, would like to create a store without having to create constructor.
Hm. I don't see why there would be multiple local stores in a component, similar to how each component should only have one state. I think it may be a good thing to enforce a rule of having a single local store in each component with getDerivedStoreFromProps.
I guess if you don't want to limit users to only having one local store, then deriveStoresFromProps would be fine.

I have some prototypes for this, but I like neither of them 😄 I won't merge any of them before the stable React 16.3 release.

I did not forget this issue 🙂 I am just waiting for things to settle. There are similar issues for other, bigger libraries - like mobx, but nobody came up with a good solution yet. I could do one of the workarounds, but it would totally 'unstaticize' the static method. I fear that it wouldn't go nicely with the React team's future plans.

Hi @Penspinner!
I finally merged in the new deriveStoresFromProps lifecycle method and released v5.1.0. You can read more about it in this docs section.
Feel free to reopen the issue, if needed. 🙂


get_helm.sh broken

as of a few hours ago it appears that the get_helm.sh script is broken when trying to verify available versions.  I'm not sure if github changed their paging or if the url the script is using is broken.
We are using an older version 2.14.3 and 2.16.7 respectively and both are listed as unavailable via the default script.  I ended up figuring out a super hacky way to get around it in the meantime so our builds can resume.
I had to change release_url to https://github.com/helm/helm/releases?after=v2.15.0 as an example to get 2.14.3.
As I said the summary of it is that https://github.com/helm/helm/releases data is coming back with limited releases so the parsing fails when looking for something not on the first page now.

Reverted in https://github.com/helm/helm/pull/9056. Sorry for the trouble.


Hidden files & ignored directories

This pull request introduces the fixes proposed in #92.
More specifically, CK will now ignore all hidden directories (leading . on Linux/Mac, some attribute on Windows) when it is walking the project directory. Additionally, the existing .git ignore has been ported to work on every operating system.
I added quite a few tests. I can verify that all those on Windows run, but I currently do not have a Linux (or Mac) machine to run the Linux specific tests. I hope that in case GitHub CI can't run these, someone can verify that these indeed pass.
I've taken the liberty to increment the version and change some of the documentation. If there's anything else you want me to do, or change, let me know!

Thanks! Could you also run tests before just to make sure?

It seems to break, see the results of github CI in the main branch.

It seems the tests all pass but it fails due to this.

Thanks. We can ignore the break then.
We should remove this configuration from codecov, I don't want it to break
my builds :)
Maurício Aniche
Delft University of Technology
http://www.mauricioaniche.com
On Sun, Jan 30, 2022 at 10:18 AM Paul Huebner @.***>
wrote:

It seems the tests all pass
https://github.com/mauricioaniche/ck/runs/4996681631?check_suite_focus=true
but it fails due to this
https://codecov.io/gh/mauricioaniche/ck/commit/3f0f51c78f8bb0d2d2b225c295fbd5ea0c257775
.
[image: AAAAA]
https://camo.githubusercontent.com/ce15314b3b5a3a57b8d34c4297f268c696e2674e8f7c672537b8e1c6ab231370/68747470733a2f2f692e696d6775722e636f6d2f734375436452512e706e67
—
Reply to this email directly, view it on GitHub
https://github.com/mauricioaniche/ck/pull/97#issuecomment-1025141735,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYTTEEZNHHJEARXPQLXO3UYU3BHANCNFSM5NEDDSWA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Clarifying

Closes https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/6840
reference https://docs.microsoft.com/en-us/sharepoint/manage-sites-in-new-admin-center

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@MikePlumleyMSFT PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Remove deprecated prop-types reference for Text

Please select one of the following

[ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
[x] I am making a fix / change for the macOS implementation of react-native
[ ] I am making a change required for Microsoft usage of react-native

Summary
The PropTypes package is deprecated on RN Core.
To help folks get off of the package, this deprecation path was left in place.
Removing the reference fixes #1433
NOTE: This was recently un-deprecated by the core team to allow more time for folks to migrate: https://github.com/facebook/react-native/commit/b966d297245a4c1e2c744cfe571396cfa7e5ffd3
I'm assuming desktop doesn't have the same legacy issues so I think it's fine to remove.
Changelog
[macOS] [Fix] - Remove reference to deprecated package in TextView
Test Plan
Before
https://user-images.githubusercontent.com/96719/202828000-c3b32a27-25b3-4397-acea-1bcbc1538df2.mp4
After
https://user-images.githubusercontent.com/96719/202828373-943d5b15-8311-41c9-b275-ff47cd517697.mp4

Nice!

@amgleitman did you have a reason to keep these last merge? I remember they came up

I added the lines that were being deleted as part of fc1770921310ecda49358797cbad5e87be7809e1, which corresponds to 3f629049ba9773793978cf9093c7a71af15e3e8d in RNCore.
The removal of these lines in RNCore happened in 3e229f27bc9c7556876ff776abf70147289d544b, which didn't make it into a stable release until 0.69.


Incorrect padding of unused bytes

Describe the bug
When a frame is defined with some unoccupied bytes, and encoded frame data is using padding of 0x0, while the encoded data from Canoe is using padding of 0xF.
Definition in ldf:
  Frame: 0, ECU, 8 {
    s1, 0 ;
    s2, 8 ;
    s3, 24 ;
    s4, 40 ;
  }

  signal size:
  s1: 8
  s2: 16
  s3: 16
  s4: 15

Payload in Canoe:

Payload generated from lib:

Environment:

OS: (e.g. Linux)
Python version: (e.g. 3.8.5)
ldfparser version: (e.g. 0.2.1)

Optionally include the output of 'pipdeptree --warn silence -p ldfparser'

Additional context
Add any other context about the problem here.

I haven't found much info from the specs, nothing mentioned in J2602 spec regarding padding.
I've found this from ISO17987-2-2016:

I do feel this may be a breaking change, maybe this change can be introduced as an optional, add a parameter to use a different padding to the encode API.
The frame is coming from Canoe simulated slave ECU.

I'm thinking add an additional parameter to the encode APIs. I'll look into it and see what way is more straightforward and propose a PR later.


Activate core packages before activating third party packages

In package activation, linter-* is activated before notifications package. Which results in https://github.com/steelbrain/package-deps/issues/25
I have to work it around by waiting 20 ms before getting the view of the notification, see this line
It would be nice to have this issue resolved in the core instead of working it around in every package.

This kind of doesnt make sense. It looks like something in linter-perl is calling atom.views.getView on a notification. Why?

@benogle here's the line that calls atom.views.getView on the notification, it does this so we can "monkey patch" a few things in it, and change the info notification into a success notification once the installation is complete.
But that's not the problem here, because the notification registry knows it's an instance of the Notification class and still throws that error, it needs to be fixed :)

Maybe the solution is to add something to the notification that can handle the progress case. Ideally we'd avoid the need for monkey patches like this, and avoid reliance on order of operations.
We could register the notification view outside of the activation method, but that could have an impact on startup speed.

@benogle I do agree that is the long term fix, but it would take a lot of time, I figured it would be a faster way to monkey patch it in my package, but I'll still be happy with it if you guys choose to implement that instead of activation of core packages before third party ones

Can you experiment with registering the NotificationView outside of the activate method? I am down if it does not add anything to startup time. That would be the most minimal code change.

@benogle I will do that and report back, Thanks!

@steelbrain Is there any update on this? Or can this be closed?

Sorry @lee-dohm but I've been very busy lately and haven't been able to work on this. The issue still remains. I have a question in mind however, @benogle isn't the module's main file only included when the module is about to be activated? Why would it make a difference if we register the view outside of activate. We will still run into this race-condition where third party packages try to get view of elements that core packages haven't registered yet.

Thanks for the update @steelbrain! It's quite alright, I just wanted to confirm :grinning:

Potential fix is in https://github.com/atom/atom/pull/10891


Displayed newest initialisation time as default

When on a MSS server multiple forecast data sets with different initialisation times are present, the default setting should be to disply the newest initialisation time. This is the most likely to be looked upon.
This is currently not the case. Please fix it.

@joernu76 @jgrooss This might be interfering with a previous design decision we made when creating the Multilayer window. I might need some more input to find a proper solution. Or maybe I am thinking too much about it.
Per default and if possible, the initialisation times are carried over from the previous selection, which are not necessarily the newest or oldest.
E.g.

Layer A has initialisation times X and Y
Layer B has initialisation times Y and Z
Where Z is newer than Y is newer than X

The user picks Layer A, and it defaults to Y
Then the user picks Layer B, it defaults to Y from the previous selection, even though Z is newer
Would this be considered unwanted behaviour?

It is complicated.
I think we now store a couple of options persistently.
Once a new init time has been selected, it will probably be transfered to new chosen layers?
I think a call to get_capabilities should "invalidate" currently stored init_time(s) (are they stored somewhere...?) and update them with the most recently available one for that layer.
Would that make more sense?


chore(main): release 1.12.0

:robot: I have created a release beep boop
1.12.0 (2024-07-23)
Features

remove num extension, add Duration extension (27d68c9)

Chores

rollback DartFunExtension (ca76027)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/luoyi58624/luoyi_dart_base/releases/tag/v1.12.0 :sunflower:


Fix database does not exists error when is_member(), schema_id() function gets called in parallel query mode.

Description
This PR intends to solve the issue of parallel worker not being able to obtain correct logical database name. Whenever get_cur_db_name() is called, it returns static char current_db_name[] which is initialised as empty. Now, parallel workers are not aware of the database name. For them, it is empty whenever get_cur_db_name() gets called. Hence, we were getting the following error:
database "" does not exist

So, to communicate the logical database name and more data related to babelfish we have introduced a struct BabelfishFixedParallelState. Currently BabelfishFixedParallelState has only 1 field, i.e., logical_db_name, we can add more fields to it whenever necessary. Then we will write the logical_db_name in DSM during initialisation (in InitializeParallelDSM) using a hook. Another hook is used while trying to fetch the logical database name in ParallelWorkerMain().
In this way we are introduction a mechanism through which we can communicate any babelfish related information to parallel workers.
Issues Resolved
BABEL-4538, BABEL-4481, BABEL-4421
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the PostgreSQL license, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 71.842%

Totals

Change from base Build<PHONE_NUMBER>:
0.006%

Covered Lines:
39805

Relevant Lines:
55406

💛  - Coveralls


Bump k8s deps for 1.21.0 release

See also https://github.com/projectcontour/contour/pull/3581

Also makes it possible to run the e2e/example tests against a kind cluster with a specific node image
Uses latest kind CLI tool to support running a k8s 1.21.0 image

Seems blocked on https://github.com/kubernetes-sigs/controller-runtime/issues/1473

Hmmm, I don't think we'll be able to do this for the 1.15 release then, which is unfortunate, since the controller is already using that client-go version.

We could pick a main branch commit of controller runtime to use temporarily since it’s supposedly fixed there, what to people think?

We could pick a main branch commit of controller runtime to use temporarily since it’s supposedly fixed there, what do people think? Would be good to keep the operator usable properly on k8s 1.21 so our compatibility matrix is correct

Wondering if we even need to bump the client-go version; I'd guess that things would work fine on a 1.21 cluster even without updating the deps. If we do want to pin to a main branch commit, we should probably eyeball what else is in there to make sure we're not shooting ourselves in the foot

Given that the Operator is still alpha, we probably can get away with trusting to hope for the client-go compatibility for now.

pulled https://github.com/projectcontour/contour-operator/pull/328 out so we can remove the dep bump from consideration

@sunjayBhatia can you resolve the merge conflict when you have a moment?

@sunjayBhatia can you resolve the merge conflict when you have a moment?

focusing on https://github.com/projectcontour/contour-operator/pull/328 for a bit since that is problematic with/without the client change

Saw there's a beta controller-runtime release out now: https://github.com/kubernetes-sigs/controller-runtime/tree/v0.9.0-beta.0
I'll leave this to @danehans to decide if he wants to take that dependency for 1.15, or wait for an official release.

I'll leave this to @danehans to decide if he wants to take that dependency for 1.15, or wait for an official release.

I'm fine with alpha.


Add new Rita-B zhs translation

Ok, at this point we may have one error in the translation because of me (#534) and one error with the Weakest relic, since qcf:Weakest is showing up in the description... but at this point I just don't have the energy to go find a fix with Rita, the fix enters later.


Allow html tag

Hello, I would like to allow the html tag <strong> in some cases. how can I do ?

nvm my bad


feat: improve quote or rate discrimination

Description
This PR changes the discriminator between quotes and rates, i.e previously, receiveAddress was the big discriminator, which allowed us to detect a rate is a rate (non-executable, price only) vs. a quote (executable, with bip44/like params attached).
This had a few issues:

Whenever the user actually connected a wallet, we were unable to do gas estimations if applicable
Since receiveAddress wouldn't be attached to a rate quote, it wouldn't be visible at confirm step (see #8289) until final quote time

This PR improves things by bringing quoteOrRate as a discriminator in trade quotes and trade rates, as well as consistently passing receiveAddress back.
Issue (if applicable)

closes #8289
Risk

High Risk PRs Require 2 approvals

High. Touches the whole quotes vs. rates logic. Risks of broken swappers at rate time, final quotes being missing or being stale rates, as well as execution being either borked with infinite "Sign and broadcast" spin, or funds not landing on custom receive addy

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

Testing

Test all swappers e2e without custom receive addy and ensure flow is happy e2e
Test all swappers e2e with custom receive addy (or with cross-account trades) and ensure flow is happy e2e
Test at least one sell Tx for each chain family (UTXO, EVM, ATOM, THOR, SOL)

Engineering

Operations

[ ] :checkered_flag: My feature is behind a flag and doesn't require operations testing (yet)

Screenshots (if applicable)

Same-Account EVM swaps

https://jam.dev/c/9eefdd34-fe4b-4fac-9a85-670a2484b22f

Cross-Account EVM swaps

https://jam.dev/c/ea739b2e-a050-402e-bd89-fa9f6e0f7bb4

Same-Account SOL swaps

https://jam.dev/c/6f1a586f-dbca-4e0f-a046-9884cb43d6ff

Cross-account SOL swaps

Untestable yet as neither native nor Ledger supports Solana just yet

Same-Account Cosmos swaps (cross-account irrelevant, there is only one supported token for Cosmos so ATOM sells are always cross-account)

https://jam.dev/c/937b5379-4994-417b-a30b-d8d374434b64

UTXO swaps (cross-account irrelevant, there is only one token for UTXOs so UTXO sells are always cross-account)

https://jam.dev/c/014e03ba-ff6a-4877-9a23-adb8a587fbc4

RUNE swaps (cross-account irrelevant, there is only one token for THORChain so RUNE sells are always cross-account

https://jam.dev/c/9a593c51-3ca2-46f2-8a0c-cd6e7dc21450

I had some flaky behaviors that are looking bad upstream I think:

@NeOMakinG confirming all of the issues above are either expected (fixed in different PRs/captured as issues previously) and unrelated, or fixed in the case of Chainflip swaps.

Chainflip swap "error c" jam.dev/c/5578b075-f9cf-4631-9ea9-d9ae741f5e13

I was able to repro:

develop is also borked however, this never loads:

Fixed in bcd115106b for Chainflip and Li.Fi: https://jam.dev/c/524d3b1c-d0f1-4fcc-8a39-ad6609ffc6d4

Rune to cosmos swap Invalid pubkey jam.dev/c/ea135569-1477-42f5-89b3-395a1e725b2d

Unrelated to this PR, see https://github.com/shapeshift/web/issues/8351

Cosmos to rune invalid pubkey jam.dev/c/eb224475-6e14-446e-939f-746ed2d73e12

Unrelated to this PR, see https://github.com/shapeshift/web/issues/8351

RUNE => Avax (Invalid pubkey) jam.dev/c/e1fceca8-5826-487c-b87c-47ecb8792509

Unrelated to this PR, see https://github.com/shapeshift/web/issues/8351

LiFi ❌ Route error is not handled gracefully jam.dev/c/e1fceca8-5826-487c-b87c-47ecb8792509

Looks like this isn't the correct Jam as I there's no Li.Fi in it, but Li.Fi errors are unrelated to this PR, bridges fixed in https://github.com/shapeshift/web/pull/8348 (though that PR didn't make its way into develop yet, so will still happen here) and Li.Fi unstable quotes are tackled in a PR on top of this one (meaning we may still encounter it here, though keep it mind it's a v. rare occurence) i.e https://github.com/shapeshift/web/pull/8350

EVM cross account CowSwap ❌ jam.dev/c/f9e0ede7-0b02-4f8d-8015-0a86b552f081

@NeOMakinG not sure what we mean by cross-account here, as CoW doesn't support cross-account trades (see in the Jam below), however, confirmed CoW is happy:
https://jam.dev/c/15a5d2eb-9f37-4afd-9307-9944d45394fa

Tyvm for the review big @0xApotheosis!

❔ UTXO - THORChain node down at time of writing
❔ Solana - I couldn't get any SOL on my Phantom wallet due to lack of test funds

Tested Jupiter for sanitys's sake so you don't have to:
https://jam.dev/c/c3c5cd99-a1ec-461f-a904-d73698b1981e


doesn't generate new bot instance

Hello,
if I am running:
docker run -d --name sinusbot --restart=always -p 8087:8087 -v scripts:/opt/sinusbot/scripts -v data:/opt/sinusbot/data sinusbot/docker
I don't get this info:
[...]
-------------------------------------------------------------------------------
Generating new bot instance with account 'admin' and password 'YOUR_PASSWORD_HERE'
PLEASE MAKE SURE TO CHANGE THE PASSWORD DIRECTLY AFTER YOUR FIRST LOGIN!!!
-------------------------------------------------------------------------------
[...]

and if I do it with the override env I can't login in either with admin and my env password.
Here is the log from a new generated container:
6/29/2018 4:55:57 PM Copied original scripts to the volume
6/29/2018 4:55:57 PM Updating youtube-dl...
6/29/2018 4:55:59 PM Updating to version 2018.06.25 ...
6/29/2018 4:56:03 PM Updated youtube-dl. Restart youtube-dl to use the new version.
6/29/2018 4:56:03 PM youtube-dl updated
6/29/2018 4:56:03 PM Starting SinusBot...
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/!!!!!!!] WARN   !!!!!!!   All rights reserved.
6/29/2018 4:56:03 PM
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/SCRIPTS] INFO   Loading ScriptPlugin advertising.js
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/SCRIPTS] INFO   Loading ScriptPlugin alonemode.js
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/SCRIPTS] INFO   Loading ScriptPlugin bookmark.js
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/SCRIPTS] INFO   Loading ScriptPlugin followme.js
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/SCRIPTS] INFO   Loading ScriptPlugin norecording.js
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/SCRIPTS] INFO   Loading ScriptPlugin rememberChannel.js
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/SCRIPTS] INFO   Loading ScriptPlugin welcome.js
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 2892373d          INFO   Loading instances
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 2892373d          INFO   Loading instance://14c9410e-1e44-400d-a32f-c7849eb4a04e
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 2892373d 14c9410e INFO   Initialization complete
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/FFMPEG ] INFO   FFmpeg/avcodec v3741798; license: LGPL version 2.1 or later; 81 codecs
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/FFMPEG ] INFO   FFmpeg/avformat v3742052; license: LGPL version 2.1 or later; 143 formats
6/29/2018 4:56:03 PM 2018/06/29 14:56:03 [GENERAL/YTDL   ] INFO   youtube-dl checking...
6/29/2018 4:56:04 PM 2018/06/29 14:56:04 [GENERAL/YTDL   ] INFO   youtube-dl version compatible, support enabled
6/29/2018 4:56:04 PM 2018/06/29 14:56:04 [GENERAL/!!!!!!!] NOTICE You may now configure and launch the bots from the webinterface. http://<IP_ADDRESS>:8087
6/29/2018 4:56:05 PM 2018/06/29 14:56:05 [GENERAL/RADIO  ] INFO   RadioStation data loaded
6/29/2018 4:56:05 PM 2018/06/29 14:56:05 [GENERAL/RADIO  ] INFO   Imported radio stations

Hi @PortStone,
for that you have do remove the files in your ./data folder.
Best regards
Max

Thanks.


[ BAEL-4339 ] - How to get Junit 4 to ignore a Base Test Class?

Some examples of how to bypass base test class with JUnit 4.

[x] add ignored tests
[x] update run from java

bad pull request


Allow configuring slack channel per application

The extension already permits overriding the default slack hook channel.  It would be helpful for teams to set the channel per application to allow some control about who sees the messages.

For now, You can create multiple custom actions and achieve this..
For eg.
<controller_dir>/custom/actions/slack-alert-with-hookA
<controller_dir>/custom/actions/slack-alert-with-hookB
The custom.xml

slack-alert-with-hookA
slack-alert.sh

slack-alert-with-hookB
slack-alert.sh


operator docker build ARM support

Need to build the operator for ARM, as part of the build process.

Added in the latest release


Requested a balance and received 'You need register before'

As you can see below, I've received the message with a wallet address after the register request, I'd requested some Doge via a testnet faucet, then I requested a balance to be told 'You need register before'. I had already registered.
re: +register
from sodogetiptest sent 11 hours ago
GaryLittlemore registered, your address is nqKNVFNDpC6PSxPcYHrwmf7A62vchy82f5
re: +balance
from sodogetiptest sent 39 minutes ago
You need register before

issue resolved, problem caused due to the DB being reset.


CHANGELOG

Hi,
do you have changelog anywhere? I could not find any.

I keep a changelog in the GitHub releases. You might also want to browse the closed pull requests for an overview of the changes.


fix spreadsheet loaded types

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/66
Originally created by @wwright on 2018-08-09 21:45:54

Updating some issues with data types in historical schema.

View 1 previous comment from the original issue on GitLab


Need a Otel standard example

Opentelemetry is quite intrusive for Go.Please give a standardized example of Gin for reference，Thank you.

An example of both Gin, slog and OTEL in a single project ?

yes, I use otelgin.middleware with slog-gin，but log not has span and traceId, I see slog-multi make baseAttributes to store the otel message


makefile: Added force-deps command.

Related: https://github.com/improbable-eng/thanos/issues/449
Signed-off-by: Bartek Plotka<EMAIL_ADDRESS>Verification
Local

Actually ... am i being a fool?
➜  thanos git:(1858548) make vendor
>> dep ensure
grouped write of manifest, lock and vendor: failed to export google.golang.org/grpc: fatal: failed to unpack tree object 168a6198bcb0ef175f7dacec0b8691fc141dc9b8
: exit status 128
make[1]: *** [force-deps] Error 1
make: *** [vendor] Error 2

@prabhakm you don't have /Users/xxxxxx/goprojects/bin/ for some reason

@prabhakm  I feel like you need just mkdir bin directory

Fixed in different PR.


Would Like to Help

Sorry to clutter issues, but couldn't find a real contact method.
This project is sweet. I'd like to help. Anything specific you'd like someone to take a crack at?

I'm working on getting a Gitter set up but it'll probably be a few days.
Brain dump of some things on my radar:
Lower commitment
Probably the lowest hanging fruit is adding config examples if you want to just play with things a bit and submit a PR to the examples/ directory. I saw someone mention that this might fill a niche for Mercurial users who want something like tig, so you could look into that... Otherwise, how could this be used for managing Docker, Kubernetes, etc? Is there a tool that you use frequently that could be made easier/faster with Rat? As we uncover more use cases, that will generate ideas for new features.
Write some automated tests 😬
Mid commitment
Write some external annotators. On my radar is a unified diff parser/annotator to implement applying patches (e.g. git staging single hunks and single lines) but I haven't looked too deeply into it. Check out the annotators/ dir for an example that parses regexes.
Refactoring. The configuration parsing stuff in particular could probably be rewritten or heavily cleaned up.
Higher commitment
I'd like to have support for multiple key-stroke keybindings. There's issue #4 for that.
Issue #3: would be nice for folks to be able to use whatever keybindings they want for the builtin actions (moving cursor, paging up/down, etc.)
Issue #17: sourcing many files from ~/.config/rat instead of just one. I also think it would be interesting to source any .ratrc files in current working directory or containing directories (similar to ) so that you could have project specific rat configs. This would require a protocol for merging mode definitions as you travelled upwards, but I don't think it'd be that crazy. The project is still at the stage where I'm not planning any backwards compatibility so we can try out things like this and if it doesn't work out or we decide it's a bad idea, we can just take it out.
Somewhere out on my radar is being able to mark multiple lines and then execute some command with all of the selected ones. This would allow you to diff to arbitrary git commits, for example.
Implement searching with /, n, and S-n (#22). I think this should use an annotator under the hood. Would also be nice if somehow I could hit n and S-n to go to next/previous annotation of some specified class. Been mulling this over but still not sure how exactly it should work so if you have some ideas there...

Awesome!  I’ll reply here or on the appropriate issue if I start to attempt any of those

I'm going to try and write some tests for the config file

Would you object if I added a real parser using this and sent a PR? You could feel free to reject the PR if you don't like it, just wondering if you might be interested.
https://github.com/pointlander/peg

No objections. That would be awesome 👍