Kwxm/costing/secp256k1

This adds benchmarks and costing functions for the verifySchnorrSecp256k1Signature and verifyEcdsaSecp256k1Signature, and extends the cost model JSON file to include the inferred models.
Benchmark results and inferred costing functions
The verifySchnorrSecp256k1Signature function takes a variable length message, and as you might expect the benchmarks show that the execution time depends linearly on the message size:

R fits an excellent linear model to this data.
The verifyEcdsaSecp256k1Signature function takes a fixed length message (32 bytes, usually a hash of some larger message) and you'd expect that to be constant time. But no!

For some reason the function processes about 10% of the messages much more quickly than the others.  This is a real effect: I've run the benchmarks several times with different inputs on two different machines and seen a similar pattern in every case.  I'm not sure why this is.  I'm feeding the benchmarks with completely random inputs, and it may be the case that for example only certain bytestrings are valid signatures, and the function returns quickly if they're not. What's definitely not happening is that it returns quickly for invalid signatures and slowly for valid ones: these algorithms have to examine every bit of the message before they can return a result, so good and bad signatures should take the same time to check (and if they don't it opens up a side-channel attack); also I'm surely not randomly generating correct signatures (although ideally we would generate both good and bad inputs to make sure that nothing odd's going on; later though).  I'm looking at the DSIGN code and the underlying implementations to try to get a better idea of what's going on.  Regardless of the cause of this, we have to model the results that we have here because users can also supply random inputs. I've just gone for a constant cost equal to the mean time over all of the samples (indicated by the dotted red line above). Perhaps it would be better to discard the stuff that's below the mean and take the average of the expensive executions, but I'll leave that until I have a better understanding of what's going on.
Note also that both of these functions are quite expensive.  The size measure which we use is one unit for every 4 bytes (annoyingly), so verifying a signature for a 10000-byte message will cost about 260µs, which is a large part of a validation budget (so signing hashes is a good plan; also it might be difficult to get such a large bytestring into a validator).  The expense is presumably due to the underlying implementation, but there may also me some overhead from going through the DSIGN interface.  I plan to update the existing verifySignature function (which is extremely fast) to use that, and that should give us some idea of what the overhead is.
Updating the cost model
I didn't run the entire set of costing benchmarks; instead I ran the ones for the new builtins along with a few of the older ones for comparison.  The evaluator has sped up by 20% or so since we last updated the full cost model, but I just kept the old costing functions (from the old evaluator) and added new ones for the new buitlins (from the current evaluator), so there's some inconsistency.  However, this doesn't matter too much.  Before deploying a new version we should recalibrate the entire cost model, but the evaluator is still evolving and there's not much point in doing all of that right now; the models for the new functions are at least of the correct form and the right order of magnitude, so this model should give a resonable approximation to real execution times.  I've made an issue to do a full recalibration once things have settled down (SCP-3930). What does matter is having a good cost model in the branch for the upcoming hard fork; to that end we need to backport this stuff to the relevant branch, re-run the benchmarks for the signature verification functions with the evaluator in the branch, and update the cost model accordingly: see SCP-3931.

@kozross You might want to take a look at this since it's your functions that we're costing.  I don't seem to be able to add you as a reviewer though.

I now understand what's up with the benchmark results for verifyEcdsaSecp256k1.  Recall that the results looked like this:

It turns out that as I suspected not every 64-byte bytestring is a valid ECDSA signature.  A signature consists of a pair (r,s) of two 32-byte values (see the Wikipedia article on ECDSA).  However, for every value of r there are two possible values for s, one effectively the negative of the other.  Looking at the implementation of secp256k1_ecdsa_verify (or at least the Bitcoin inplementation, which is the one I assume we're using, and which underlies the Haskell implementation: see ecdsaVerify in this file), we have at the end
    return (!secp256k1_scalar_is_high(&s) &&
            secp256k1_pubkey_load(ctx, &q, pubkey) &&
            secp256k1_ecdsa_sig_verify(&r, &s, &q, &m));

It's dong a check on the value of s and returning immediately if it fails.  The check is here:
static int secp256k1_scalar_is_high(const secp256k1_scalar *a) {
    return *a > EXHAUSTIVE_TEST_ORDER / 2;
}

Now the value of EXHAUSTIVE_TEST_ORDER is determined  by some Sage code here which does complicated elliptic curve computations.  It's difficult to work out what it's returning, but I reckon it's 255 or 256, so the check above is throwing out values of s whose first byte is greater than 127 or thereabouts.  I think this is ensuring that the signature contains a canonical choice of the two possible values of the parameter s.  Presumably this is mandated by some standard somewhere, but I haven't been able to track that down.
So if we feed our Haskell function randomly-generated 64-byte bytestrings as signatures, it should return quickly in 50% of cases (I checked, and it runs quickly if the last byte is >= 0x7E and slowly otherwise, because then it really does go on and perform the full signature check).
But why are only about 10%of the results above fast, not 50%?  This is because I used a Hedgehog generator to generate randm bytestrings:
listOfSizedByteStrings :: Int -> Int -> [ByteString]
listOfSizedByteStrings m n = unsafePerformIO . G.sample $ G.list (R.singleton m) (G.bytes (R.singleton n))

What I'd forgotten (this caught me out before) is that sample secretly resizes its generator to size 30,  so this is biased towards small bytes.
Conclusion
We need to rework this. By accident it gives us pretty reasonable results, but we should make sure that it's doing something sensible in future.  I can think of two approaches:

Generate random bytestrings properly.  This will give us results where 50% of the times are fast and 50% are slow.  Taking the mean of these would underestimate the common case of successful signature verification, so we'd have to do something in the R code like discarding everything below the mean and taking the mean of the remaining samples. This is probably a bit fragile.
Generate random messages and then use the DSIGN infrastructure to generate only valid keys and signatures.  This would be pretty robust, but relies on the assumption that verification of valid signatures is the worst case, which is probably pretty safe.

I've made an issue for that at SCP-XXXX
We also need to rework the generation of benchmark inputs in general (probably minimising the use of Hedgehog, since that also has some problems due to generating large shrink trees that we don't use) but there's already an issue for that.

we have to care about all kinds of inputs, not just sensible ones generated with 2.

That was my original thinking too, but the ones with silly inputs fail rapidly and it's the correct ones (with both valid and invalid, but correctly formed, signatures) that take a long time, so in this case we would be OK, but perhaps only by luck.  If we take approach 1 then we'll either have to have special modelling code in the R file to filter out the fast failures or accept them and under-cost proper verifications. But then if we take approach 2 we'll need special code to generate sensible inputs, so there'll still be extra complexity but somewhere different. I'll think about it a bit more before taking any action.  This was supposed to be the simple constant-time case too...

After some more digging, it seems out that the requirement that the only the low value of the s component of an ECDSA signature is accepted is peculiar to bitcoin: see https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#LOW_S

A different implementation of secp256k1 ECDSA signature checking might not carry out this check, so perhaps the Plutus Core specification should mention this.

I went for approach (1) in https://github.com/input-output-hk/plutus/pull/4602.


Rotate an array to the right by 3 position.

add in array folder.
Rotate an array to the right by 3 position.
n<=10

hi please can you assign me this issue @akshitagupta15june

Yeah

Hey can you assign this issue to me @akshitagupta15june :)

PR raised for #137 this issue please check

@akshitagupta15june Is this still open for contribution?


Refresh presigned urls for cdf queries

Refresh presigned urls for cdf queries

@zsxwing I'll merge this first, if you have comments, I'll update in https://github.com/delta-io/delta-sharing/pull/221


fix 'unfold this'

fix 'todo:   unfold this'

Thanks for this, but I've simply removed that TODO. It's actually OK as it is.


whers is Caddyfile

(centos 7)
Install  caddy
curl https://getcaddy.com | bash -s hook.service,http.git

Then
caddy -service install

so,where is my Caddyfile?

in
/etc/local/bin/Caddyfile

?

Hello @zuohuadong! Check the issue #4 please 😄 Hope it helps! Soon we'll clarify this on the docs.


AnalyticsConsole, debugging tool for tracked events

Since this includes the same bumps and updates from https://github.com/LedgerHQ/ledger-live-mobile/pull/1468 I'm HODL'ing it until we can rebase it to not include all these changes.

This pr backports the analytics console concept from LLD to LLM, allowing us to view as an overlay on the screen the events that are getting tracked via analytics. This is specially useful for product to find the name of an event to polish metrics and to identify missing or incorrect events.

It has already helped identify the fact that we were missing all the events from the first launch of the app. The component in charge of this was not getting the update of the hasCompletedOnboarding flag having changed and therefore we remained with uninitialised analytics for the duration of the first launch. Subsequent launched would work as expected, but we lost the metrics of all the first launches. This should be addressed here too.
Type
Feature
Context
n/a
Parts of the app affected / Test plan

During onboarding, clicking on the Powered by ledger footer multiple times should take you to the debug screen.
Enable the analytics console in the mock & test screen
Complete the onboarding and take a look at events tracked.

Note: This behaves strangely with live reload so for best reliability don't edit the code while you are debugging the events. Relaunch the app completely if possible.

Rebased, updated, should be ok to QA at this point to me @gre


Use SwiftDriver's Triple parser

SwiftDriver's Triple parser is more robust than our bespoke one, and it's already tested.

Replace all use of Triple with the SwiftDriver's one
"uname -m" and "sw_vers" commands are replaced with libc uname
Darwin version -> macOS version conversion is now done by the Triple

@swift-ci test

@swift-ci test


Transitioning Boards to plugin

This PR is for pulling out Boards content from docs.mm.com
Content migration to GitHub: https://github.com/mattermost/focalboard/pull/4862

Hi @esethna! This PR should be ready for your final review. Thanks!

Error trying to update the PR.
Please do it manually.


Project build error

The specified task executable location "/Library/Frameworks/Mono.framework/Versions/5.12.0/lib/mono/4.5/aspnet_compiler.exe" is invalid. (MSB6004) (ChameleonForms.Example)
OS: Mac OS X
Visual Studio 2017
Please help.
Secondly, why do I get error Html.BeginChameleonForm extension. not found?

I created a new .net mvc app and just realised Chameleon Forms not compatible in a way

Hi,
Chameleon Forms only works with ASP.NET MVC 5 on full framework at this point in time. It won’t work in dotnet core and this won’t work on a Mac.
--

On 1 Jun 2018, at 5:10 pm, leslieharland<EMAIL_ADDRESS>wrote:
I created a new .net mvc app and just realised Chameleon Forms not compatible in a way
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


i64

Most of the TODO notes should be addressed before merging.  Specifically, advanced operators like power **, modulo %, comparison operators, etc. need to support i64 casting.  While I'm at it, I want to do some tangentially related work to support compound assignment with those operators, because it will touch the same code
The only thing I might not want to actually do is automatic casting from i64 to i32 on assignment and vice versa, as that might be a more serious footgun than similar float-to-int casting which I allow on assignment


I now own PR 3000. you can't win now!

Description

This PR is related to the issue #
Tasks

[ ] Tested on Linux
[ ] Tested on Windows
[ ] Tested on macOS
[ ] Tested on iOS
[ ] Tested on Android

How to test this PR?

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode({1280, 720}), "Minimal, complete and verifiable example");
    window.setFramerateLimit(60);

    while (window.isOpen())
    {
        while (const auto event = window.pollEvent())
        {
            if (event.is<sf::Event::Closed>())
                window.close();
        }

        window.clear();
        window.display();
    }
}

Just a meme PR

Mods, banban this guy


Choosing "upgrade" for "External Services"/ "LB services" shows a page with all fields of a regular service.

Server Version - V0.43.0-rc2
Create an external service.
Choosing "upgrade" for "External Services" shows a page with all fields of a regular service which are editable.
The only supported field that should be allowed to change as part of upgrade should be labels?
The same behavior is also seen for LB service.

Upgrade removed for everything but 'regular' services.

Tested with Server Version - V0.43.0-rc3
"Upgrade" option is not presented in the UI for "External Services"/ "LB services" any more.


Fix errors and make a Dockerfile

Considering how Docker is used very often in research communities, I thought adding a Dockerfile to semantic_suma would be beneficial!
The suggested Dockerfile solves 3 issues that semantic_suma has:

RangeNet not showing correct segmentation output on RTX devices

This is solved in line 38 in Dockerfile sed -i 's/builder->setFp16Mode(true)/builder->setFp16Mode(false)/g' /catkin_ws/src/rangenet_lib/src/netTensorRT.cpp
The solution is from https://github.com/PRBonn/rangenet_lib/issues/9

Compilation fails due to updates in Boost library dependencies in Ubuntu 20.04 or higher

This is solved by line 42 in Dockerfile sed -i 's/find_package(Boost REQUIRED COMPONENTS filesystem system)/find_package(Boost 1.65.1 REQUIRED COMPONENTS filesystem system serialization thread date_time regex timer chrono)/g' /catkin_ws/src/semantic_suma/CMakeLists.txt
The solution is from https://github.com/PRBonn/semantic_suma/issues/12

Glow dependency broke the recommended compilation method

This is solved by rolling back the glow dependency version to the old one that worked, line 45 in Dockerfile cd glow && git checkout e66d7f855514baed8dca0d1b82d7a51151c9eef3

With this Dockerfile, we can build the image with docker build -t semantic_suma:latest, and run it by docker run -it -e "DISPLAY=$DISPLAY" -e "QT_X11_NO_MITSHM=1" -e "XAUTHORITY=$XAUTH" -v "/tmp/.X11-unix:/tmp/.X11-unix:rw" -v /kitti:/data --runtime=nvidia --net=host --ipc=host --privileged semantic_suma:latest. The GUI is visualized via X11, so prior to starting a docker container, xhost +local:docker command should be used.
Below is a gif screenshot of the Dockerfile successfully building a container and running semantic_suma.

That's great and solves directly the problem that people currently have with the outdated version (and my breaking changes to glow).
I quickly looked at the changes and it seems reasonable. About the ROS part, I'm not sure if it's strictly needed, but for now we can do it with this.
Thanks a lot for your contribution and I hope I will find some time in the future to also remove here the nasty dependency on catkin.


Supporting AnimatedTabBar repo.

Hello,
Thanks for your awesome repo.
I need to use this repo. to support Dark Mode. I tried to use SwiftTheme with AnimatedTabBarAppearance.shared but it is not working.
I also tried, Custom Behaviors as following:
NotificationCenter.default.addObserver(self, selector: #selector(updateTabBarItem), name:NSNotification.Name(rawValue: "ThemeUpdateNotification"), object: nil)

@objc func updateTabBarItem() {

        if UserDefaultsManager.shared.isNightMode {
            AnimatedTabBarAppearance.shared.backgroundColor = .red

        } else {
            AnimatedTabBarAppearance.shared.backgroundColor = .white
        }
 }

But I think it will need refresh because when I open/close the app it worked.
Can you please tell me how to do it immediately without open/close the app?

Hello, I think this question is more about how to control AnimatedTabBar instead of SwiftTheme :)

Thanks for your reply I appreciate it. I also asked AnimatedTabBar.
I think it will be awesome and useful for other people if we write a solution here.

Problem solved by installing it manually instead of using pod :(
Then, simply change this line:
tabBar.backgroundColor = AnimatedTabBarAppearance.shared.backgroundColor
With:
tabBar.theme_backgroundColor = ..
Icons are another story 💪🏼


CLI config file not found under macOS

The client is using xdg to find where the clever-tools.json file is on the system. But it's using SearchConfigFile() for that. Thus, it's looking in XDG_CONFIG_HOME:

~/.config (Unix)
~/Library/Application Support (macOS)

But the clever-tools.jsonfile is in $HOME/.config/clever-cloud/ folder on both systems, so the file is not found if the user is using macOS (I didn't check for Windows).

~/Library/Application Support (macOS) seems the standard directory to store configurations on OSX.
Maybe the clever-tools use a tool library for XDG, https://www.npmjs.com/package/xdg?activeTab=code
https://github.com/CleverCloud/clever-tools/issues/655

Even if the clever-tools are updated anytime soon, it will take some time for users to have a config file in the good folder. Maybe we can support the current situation in the meantime ?


Seaport 1.4

This PR highlights changes from Seaport 1.3 to Seaport 1.4 and is meant to facilitate review and discussion of those changes.

Codecov Report
Base: 100.00% // Head: 100.00% // No change to project coverage :thumbsup:

Coverage data is based on head (1aa86e4) compared to base (e99e1e3).
Patch coverage: 100.00% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@              Coverage Diff              @@
##           seaport-1.3      #999   +/-   ##
=============================================
  Coverage       100.00%   100.00%
=============================================
  Files               47        46    -1
  Lines             2661      2657    -4
  Branches           393       396    +3
=============================================
- Hits              2661      2657    -4

Flag
Coverage Δ

foundry
77.78% <79.71%> (-0.03%)
:arrow_down:

production
100.00% <100.00%> (ø)

reference
100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

contracts/Seaport.sol
100.00% <ø> (ø)

contracts/lib/Consideration.sol
100.00% <ø> (ø)

contracts/lib/ConsiderationDecoder.sol
100.00% <ø> (ø)

contracts/lib/LowLevelHelpers.sol
100.00% <ø> (ø)

reference/ReferenceConsideration.sol
100.00% <ø> (ø)

contracts/lib/ConsiderationBase.sol
100.00% <100.00%> (ø)

contracts/lib/FulfillmentApplier.sol
100.00% <100.00%> (ø)

contracts/lib/OrderCombiner.sol
100.00% <100.00%> (ø)

contracts/lib/OrderValidator.sol
100.00% <100.00%> (ø)

contracts/lib/Verifiers.sol
100.00% <100.00%> (ø)

... and 5 more

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Categorize jumpy functions

It seems there are more-or-less two types of functions.

Functions that construct new arrays. (e.g. jp.array, jp.ones, jp.eye).
Functions that take arrays as input, manipulate them, and output the result (e.g. jp.matmul).

Functions in category 1 are affected by the global switch, in contrast to the functions in category 2. Category 2 functions decide on their implementation based on the array types (numpy, jax, builtin-in) of its inputs. Making this split explicit may make implementing a call order later on easier?
It might be worth splitting jumpy into three files: custom functions, category 1 and category 2 functions
This will make it easier to test as the functions in each file should operate in a "similar" way.

Done in #30


feat(go): add generateSecuredApiKey helper

🧭 What and Why
🎟 JIRA Ticket: DI-1782
Add GenerateSecuredApiKey to the go client, also fix the type and the playground

yes it's working well now, thanks for making me test !

The description of the pr needs to be updated but no biggy

updated !


Support for null strings

Any tips/suggestions for getting null as a value? I know JSR won't allow null to be passed in because it's not a constant but is there any clean way of doing it besides generating my own TestParameterValuesProvider for every parameter that needs to support null?
// Doesn't work
@Test
fun someTest(@TestParameter(value = [null, "", "foo"]) param: String) {
    ...
}

// Ugly bc you'd have to define the provider for every String argument in every test method
@Test
fun someTest(@TestParameter(valuesProvider = FooProvider::class) param: String) {
    ...
}

class FooProvider : TestParameter.TestParameterValuesProvider {
    override fun provideValues(): MutableList<String?> {
        return mutableListOf(null, "", "foo")
    }
}

Hi Daniel,
At the moment, your workaround seems to be the best solution for getting a null value, but I agree it's not ideal.
The following change would make it a lot easier to test for null values:
@Test
fun someTest(@TestParameter(value = ["null", "", "foo"]) param: String) {
   // "null" wouldn't be interpreted as String but as null value
    ...
}

I've implemented this and I'm now re-running all Google tests to see if any existing code is relying on a "null" string being "null". If this turns out to work, I'll push it onto a new release.

This change has been released in v1.3

@nymanjens Thanks! This is exactly what I needed. You rock.


support to disable exllama for gptq

fixes #599
adding gptq_disable_exllama: true to the yml config should fix the issue with gptq

The author of the linked issue mentions
    raise ValueError('Expected a cuda device, but got: {}'.format(device))
ValueError: Expected a cuda device, but got: cpu

after setting it. Is that due to cuda com?

Executing the example yaml file in this branch thows an error related to modifying the LlamaConfig object:
  File "/home/axolotl/scripts/finetune.py", line 52, in <module>
    fire.Fire(do_cli)
  File "/opt/conda/lib/python3.10/site-packages/fire/core.py", line 141, in Fire
    component_trace = _Fire(component, args, parsed_flag_args, context, name)
  File "/opt/conda/lib/python3.10/site-packages/fire/core.py", line 475, in _Fire
    component, remaining_args = _CallAndUpdateTrace(
  File "/opt/conda/lib/python3.10/site-packages/fire/core.py", line 691, in _CallAndUpdateTrace
    component = fn(*varargs, **kwargs)
  File "/home/axolotl/scripts/finetune.py", line 48, in do_cli
    train(cfg=parsed_cfg, cli_args=parsed_cli_args, dataset_meta=dataset_meta)
  File "/home/axolotl/src/axolotl/train.py", line 58, in train
    model, peft_config = load_model(cfg, tokenizer, inference=cli_args.inference)
  File "/home/axolotl/src/axolotl/utils/models.py", line 202, in load_model
    model_config["disable_exllama"] = cfg.gptq_disable_exllama
TypeError: 'LlamaConfig' object does not support item assignment
Traceback (most recent call last):
  File "/opt/conda/bin/accelerate", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.10/site-packages/accelerate/commands/accelerate_cli.py", line 47, in main
    args.func(args)
  File "/opt/conda/lib/python3.10/site-packages/accelerate/commands/launch.py", line 986, in launch_command
    simple_launcher(args)
  File "/opt/conda/lib/python3.10/site-packages/accelerate/commands/launch.py", line 628, in simple_launcher
    raise subprocess.CalledProcessError(returncode=process.returncode, cmd=cmd)
subprocess.CalledProcessError: Command '['/opt/conda/bin/python', 'scripts/finetune.py', 'examples/llama-2/gptq-lora.yml']' returned non-zero exit status 1.```

@Napuh I updated the fix, lmk if that works.

Now it's throwing the same error as in #599, ValueError: Found modules on cpu/disk. Using Exllama backend requires all the modules to be on GPU.You can deactivate exllama backend by setting disable_exllama=True in the quantization config object.
Im executing accelerate launch scripts/finetune.py examples/llama-2/gptq-lora.yml, am I doing something wrong?
Also script keeps loading after model downloading for about 5 minutes, and no memory is ever allocated on the gpu (monitored manually via nvidia-smi).

@Napuh hopefully this most recent commit resolves it.

Latest commit solves the config issue with exllama, but now it's throwing ValueError: Expected a cuda device, but got: cpu, the same error as if I edit the config.json manually.
#456 may be related as it's the same error, but the scenario is different from this one.

@winglian Latest commit solves the config issue with exllama, but now it's throwing ValueError: Expected a cuda device, but got: cpu, the same error as if I edit the config.json manually.
#456 may be related as it's the same error, but the scenario is different from this one.

https://github.com/OpenAccess-AI-Collective/axolotl/pull/609 should fix the issue for the device check when logging gpu utilization


add S3copy File lock and length check

Well, the basic file lock and file length is ready. Please go on, and add file lock and length check in onSubmit method. If file is locked or length is greater than 0, then return false, otherwise return true. This method will block unnecessary action from submission.  Don't forget to remove file lock in onActionFinished method.
Please refine this PR based on  CopyScheduler.onSubmit and CopyScheduler.onActionFinished. :)


Fix SLES PAYG E2E tests.

This is an update to the previous PR https://github.com/GoogleCloudPlatform/compute-image-import/pull/60. Zypper requires an active subscription to install updates. However, if the image is intended to be used on GCE with a PAYG license, then it doesn't need to have a subscritpion. And therefore we can request Zypper updates only for BYOL images.
/cc @MahmoudNada0
/assign @MahmoudNada0

/hold

/lgtm

/unhold


Move spotify implementation from mopidy to spotifyd

Hey everyone.
First of all, thx very much for this project. Its awesome, and we are currently building a setup, having a lot of fun. However I do have a suggestion to make. I most likely will implement it for my setup anyway and maybe you will like it.
Currently the spotify implementation is based on mopidy. As much as I like mopidy, it has quite some flaws. There is e.g. thee need to create a device password. Mopidy is based on python 2.7 up to now https://github.com/mopidy/mopidy/issues/779 and the issue tracking the change to python 3 started in the year 2014, while python 2.7 will be end of life by the end of 2019. It might be they manage to switch by the end of the year, but who knows. Further mopidy is not known to be very fast or lightweight either, resulting in a slower boot up etc. (At least I read people reporting that.)
As an alternative, I would like to suggest spotifyd. spotifyd is an extremely lightweight standalone spotify implementation. The ready to use binary has almost zero dependencies and runs out of the box on raspbery pi. Depending on the compiled features it is usually less then 10MB in size and the best part, one wouldn't need the device-password any more, simplifying the setup process. Spotifyd can be controlled via an mpris dbus interfaces. E.g. playerctl could be used. Or one could use the dbus interface directly.

Hi Deisi,
since I seem to have a problem with mopidy (https://github.com/MiczFlor/RPi-Jukebox-RFID/issues/607) this might be a way to fix my problem. It would be nice if you could give instructions how to use spotifyd instead of mopidy after you've implemented it on your Phoniebox.
Thanks in advance and cheers
Hamsert

Hey, I started looking into it and encounter some problems.

Spotifyd has currently a broken mpris setup making it impossible to use for playing https://github.com/Spotifyd/spotifyd/issues/417
I then realized that phoniebox is heavily based on MPD. To use Spotifyd together with MPD phoniebox would need some sort of statemachine to keep track of who is playing what. Else there will be conflicts.
I then took a look if it is possible to have Spotify within MPD. Currently this is not possible but I started a threat in the MPD forum about this. https://forum.musicpd.org/viewtopic.php?f=8&t=7871

Hi @deisi
do you think we should close this thread? From the sound of it, mopidy is the best option right now?

Well I still have it on my list, but we can close it here. Oce I start
moving I might reopen something alike.
Micz Flor<EMAIL_ADDRESS>schrieb am Sa., 16. Nov. 2019, 12:42:

Hi @deisi https://github.com/deisi
do you think we should close this thread? From the sound of it, mopidy is
the best option right now?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MiczFlor/RPi-Jukebox-RFID/issues/618?email_source=notifications&email_token=ABJPMNGMJYMU2OGV3FIEDODQT7MARA5CNFSM4JFRCOM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHPSVA#issuecomment-554629460,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJPMNE7XLI6JGS3LJ3PMYLQT7MARANCNFSM4JFRCOMQ
.

Mopidy is very close to completing the port to python3. It's probably not an issue, as the developer is committed to getting a stable release on python3 before the end of the year.


chat exec pluginapi

A Exec function on client conn to send chat messages as if the client would have send it

You're right.
but the complete idea of sending chatMsgs as a client is kinda dirty


Slogan to JS

Possibly via a scheme backend?

@hengestone Thanks for bringing this up. Slogan uses Gambit Scheme as the backend and Gambit can emit JavaScript. This is not yet integrated into the Slogan compiler toolchain. There are other issues to take care of like extending the FFI to support JavaScript. But the basic integration should be straightforward.

I only found some old references to the Gambit JS target, any docs on how to use it that you can pint me to?
Thanks!
Ps. I think slogan is amazing, don't know how you kept it hidden so long ;-)

@hengestone The starting point should be to pass the -target js command line argument to gsc from the Slogan compiler. These changes will go in the src/repl.scm and src/core/compiler.scm files. If you are interested, please fork Slogan and try to get this working. But as I said in the previous comment, more coding will be required to get scheme->js and js<-scheme function calls to work. I am not sure how good the integration between gambit and js is. Probably we will have to build the FFI scaffolding ourselves.

Some more information on using the JS backend is here: https://webmail.iro.umontreal.ca/pipermail/gambit-list/2016-August/008384.html. Reproducing some useful parts of the thread:
> Yes that is mostly correct.  However I would recommend the following
> commands:
>
> for JavaScript:
>
> $ cd lib
> $ make _gambit.js
> $ cd ..
> $ gsc/gsc -:=. -warnings -target js code.scm
> $ gsc/gsc -:=. -warnings -target js -link -l lib/_gambit.js code.js
> $ cat code_.js code.js lib/_gambit.js > p.js
> $ node p.js
>
> for Python:
>
> $ cd lib
> $ make _gambit.py
> $ cd ..
> $ gsc/gsc -:=. -warnings -target python code.scm
> $ gsc/gsc -:=. -warnings -target python -link -l lib/_gambit.py code.py
> $ cat code_.py code.py lib/_gambit.py > p.py
> $ python p.py
>
> Note that there was a small ordering problem in the generated code (now
> fixed) that prevented the Python code to run properly.
>
> The universal backend is a WIP but close to a “final product”.  Remaining
> on the TODO:
>
> 1) changes to the Gambit library (lib/*.scm) and the runtime system to
> support more of the Gambit system features, in particular non-blocking I/O
> which is needed to support Gambit’s green threads
> 2) integration to the main installation process (to build and install
> _gambit.js, _gambit.py, etc in the Gambit installation directory)
> 3) documentation (!)
>
> The universal backend is definitely usable without #1 (some users have
> built commercial products with it) as long as the application uses
> ##inline-host-* to interface with hand written code to do the
> user-interface or I/O.
>
> Here is a simple example for using ##inline-host-* in JavaScript:
>
> (declare (extended-bindings))
>
> (##inline-host-declaration "
>
> function rand(n) {
>   return Math.floor(n * Math.random());
> }
>
> ")
>
> (define (rand n)
>   (+ 1 (##inline-host-expression "g_host2scm(rand(g_scm2host(@1@)))" n)))
>
> (println (rand 6))
> (println (rand 6))
> (println (rand 6))
> (println (rand 6))
>
> (##inline-host-statement "console.log(@1@);" 123)
> (##inline-host-statement "console.log(@1@);" "hello")
> (##inline-host-statement "console.log(@1@);" 'world)
> (##inline-host-statement "console.log(@1@);" (cons 11 22))
> (##inline-host-statement "console.log(@1@);" (vector 11 22 33))
> (##inline-host-statement "console.log(@1@);" rand)
>
> Hope that helps!
>
> Marc

Thanks - I'm currently unable to compile gambit, but I filed a bug report and will try out the backend when that gets resolved.

@hengestone Are you able to compiler Slogan? If you are able to, a gambit compiler binary will be created under platform/gsc/gsc.

Yes, and have a slogan prompt :+1:


natal init fails

Hello! This project looks very promising`. I would love to give it a try but I've been stuck so far by this error:
$ natal init FutureApp
Creating FutureApp

Creating Leiningen project
Updating Leiningen project
Creating React Native skeleton
Installing Pod dependencies
Updating Xcode project
Creating Natal config
CoreData: annotation:  Failed to load optimized model at path '/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/Frameworks/InstrumentsPackaging.framework/Versions/A/Resources/XRPackageModel.momd/XRPackageModel 9.0.omo'
CoreData: annotation:  Failed to load optimized model at path '/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/Frameworks/InstrumentsPackaging.framework/Versions/A/Resources/XRPackageModel.momd/XRPackageModel 9.0.omo'
Compiling ClojureScript
Compiling Xcode project
Command failed: xcodebuild -workspace native/ios/FutureApp.xcworkspace -scheme FutureApp -destination platform='iOS Simulator',OS=latest,id='C32AE35F-AC5D-486C-B37A-2F27D98B70A3' test

Versions of software used:

Node v9.5.0
Watchman stable 4.9.0
Xcode 9.2 (9C40b)
Natal 0.2.0

The verbose log is available as a gist: https://gist.github.com/piotr-yuxuan/c10777d25677df32e3fc37b0cd7adb62

I'd recommend trying the more actively maintained successor to this project: https://github.com/drapanjanas/re-natal

Thanks for your anwser, closing.


Simplify travis

Simplify travis

Hi @lowks
Thanks for the pull request. It would be nice if we could use Travis' own version of Elixir and specify the Elixir version at the same time. Unfortunately that does not seem possible right now. Until we can do that I will keep the current (verbose) way. So I'm closing this because it does not lock the Elixir version.

I think you can specify the version of elixir by giving the version in travis.yml too. If you don't put it, it will default to 1.0.2


[QUESTION] What happened to import events with chunk reading?

Prerequisites

[X] Have read and understood: https://github.com/Maatwebsite/Laravel-Excel/blob/3.1/.github/SUPPORT.md
[X] Checked if your Laravel Excel version is still supported: https://docs.laravel-excel.com/3.1/getting-started/support.html#supported-versions
[X] Checked that your question isn't already asked before.
[X] Filled in the entire issue template

Versions

PHP version: 7.4.4
Laravel version: 7.9.2
Package version: 3.1.19

Description
I'm trying to run some events before and after WithChunkReading in combination with ShouldQueue.
I saw that there was a PR (#2027) some time ago that got closed. The last comment in that PR said it was released.
But I don't see the changes in the latest version of this package. Was there a reason to not add those chunk events?

No custom events were added. You can just use Before/AfterImport .

Ok, thanks for the confirmation. Apparently it were the events BeforeSheet and AfterSheet.


Separate the serialisation (preimage) and the hashing in GetInputSign…

GetInputSignatureHash was doing 2 things:

Serialising the transaction and specific input to create a preimage
Hashing the preimage and returning the hash

This pull request is simply splitting these into 2 separate functions:
GetInputPreimage()
GetInputSignatureHash()

Codecov Report

Merging #9 (05654b0) into master (e4a51e7) will decrease coverage by 0.13%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master       #9      +/-   ##
==========================================
- Coverage   76.55%   76.41%   -0.14%
==========================================
  Files          16       16
  Lines         806      810       +4
==========================================
+ Hits          617      619       +2
- Misses        133      134       +1
- Partials       56       57       +1

Impacted Files
Coverage Δ

signaturehash.go
85.29% <66.66%> (-2.21%)
:arrow_down:

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 e4a51e7...05654b0. Read the comment docs.

Codecov Report

Merging #9 (05654b0) into master (e4a51e7) will decrease coverage by 0.13%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master       #9      +/-   ##
==========================================
- Coverage   76.55%   76.41%   -0.14%
==========================================
  Files          16       16
  Lines         806      810       +4
==========================================
+ Hits          617      619       +2
- Misses        133      134       +1
- Partials       56       57       +1

Impacted Files
Coverage Δ

signaturehash.go
85.29% <66.66%> (-2.21%)
:arrow_down:

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 e4a51e7...05654b0. Read the comment docs.

Missing unit test

Missing unit test


fix beautify stack split error - fixes #509

This tiny PR fixes #509 and #459 when beautifyStack returns null.

Under what conditions does stack-utils return null? That seems like a poor choice. Sam, would you mind taking a look and seeing if it wouldn't be better to modify stack-utils? Maybe it should just return an empty string instead of null?
Part of any stack-utils PR would need to include checking how changes would affect node-tap.
Sorry for complicating this. I'd do it myself but I'm slammed for the next few weeks

It's the last line of the clean function. The stack trace of the error looks like this
/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/assert.js:78:7
From previous event:
    Test.exit (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/test.js:195:10)
    Test.run (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/test.js:142:8)
    Runner._runTest (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:114:14)
    Runner.<anonymous> (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:101:15)
From previous event:
    eachSeries (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:39:17)
    Runner._runTestWithHooks (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:91:9)
    each (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:35:27)
    Runner._runConcurrent (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:124:9)
    /Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:182:16
From previous event:
    Runner.run (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/runner.js:181:4)
    process.<anonymous> (/Users/sam/Projects/playground/ava-test/node_modules/ava/index.js:85:10)
    process.<anonymous> (/Users/sam/Projects/playground/ava-test/node_modules/ava/lib/test-worker.js:102:10)

Because of the internals of stack-utils the result array in the clean method is empty which results in null.

It's the last line of the clean function.

It should return an empty string there.

There is actually a test that to check if it returns null if it are all internals.
https://github.com/tapjs/stack-utils/blob/master/test/test.js#L57-L60
Will create an issue and do a PR.

There is actually a test that to check if it returns null if it are all internals.

Definitely not what I would expect when the method name is .clean().

Will create an issue and do a PR.

:+1:

@jamestalmage bumped stack-utils and removed previous changes.

Thanks Sam!

You're welcome :)


Add version to docker-images

As title suggests. Best option would be a workflow that updates the version on push to main.

comment from @eeberhard

As a side note, how do you feel about tagging the ros2-control image with the version (for example, as :iron and :iron-3.18)? That way if we keep iron but upgrade ros2_control to some other version later, we can distinguish them. Not in scope for this PR but goes in a similar direction and I think would be useful to do.

comment from @LouisBrunner

I think we should just make our own version for this. e.g. v2.3.0+iron

comment from me:

Fair suggestion, do we take the version from a VERSION file?

I don't mind where we get the version at the moment, as long as we produce 2 tags (v2.3.0+iron and v2.3.0, as it makes package management easier later). I don't mind which of these tags is the ones that makes it into git either.

Iron and humble would be different versions, e.g. v1.4.5+humble and v2.3.1+iron. There is no reason for them to be linked (after all they aren't necessarily compatible).

A couple of weeks ago, we decided that in the near future, we'll drop the ros2-control image and only ship one ros2-ws image that contains all dependencies we need for ROS2 and ROS2 Control. @LouisBrunner What would be your suggestion for the tags of the image? vX.Y.Z+ROS_DISTRO? I think we could already start to set that up.

So the new ros2-ws will be equivalent to the old ros2-control?
Yeah I think a version like that makes sense.

Name is not 100% sure but yeah essentially that's it.

The + is not allowed in docker images tags though it seems

Ah, that's a shame. I guess we can do multi-tags and include vX.Y.Z, vX.Y.Z-ROS_DISTRO and ROS_DISTRO and that should be both standard Docker and mostly semver-compliant.


Something about accuracy

I have tested your code, but I find it doesn't appear like what you claimed.
Maybe I have something wrong in test method.
If you want my test dataset, you can leave you email or send the email to<EMAIL_ADDRESS>

Can you develop a bit more on your problem ?

I downloaded soe deepfake videos from youtube. I use your code to test it's performance. But I find your code has a high prob on normal video, and a low prob on deepfake video.

This is result: youtube_deepfake video class prediction : 1.0
youtube_normal video class prediction : 1.0

you can download it : https://www.youtube.com/watch?v=77m3XlhQwaI

Hi,
where is the training code? If I want to train the code  on my dataset


Invitation from open spaced repetition

I want to invite you to join @open-spaced-repetition. Would you like to join it and move this repository to the organization? I hope you can continue to maintain it in the organization.

@L-M-Sherlock The link in the "About" section of this repository incorrectly points to the previous location, and I do not have permission to change it. There was a check box "Use your GitHub Pages website". It’s strange that it didn’t update itself during the transfer. Can you please fix it?

I have set you as the admin of this repo just now. You can give it a try.


Cannot read property 'origin' of undefined

Hi,
I am Getting error while implementing CandleStickChart same as given the documentation. But getting following error.
render() {
		var { type, width, data, ratio } = this.props;
		return (

            {
				data && data.length &&
				 <ChartCanvas ratio={ratio} width={width} height={400}
					margin={{ left: 50, right: 50, top: 10, bottom: 30 }} type={type}
					seriesName="MSFT"
					data={data}
					xAccessor={d => d.date} xScaleProvider={discontinuousTimeScaleProvider}
					xExtents={[new Date(2012, 0, 1), new Date(2012, 6, 2)]}>

				<Chart id={1} yExtents={d => [d.high, d.low]}>
					<XAxis axisAt="bottom" orient="bottom" ticks={6}/>
					<YAxis axisAt="left" orient="left" ticks={5} />
					<CandlestickSeries />
				</Chart>
			</ChartCanvas>
		}

		);
	}

import React, { Component, PropTypes } from 'react';
import * as d3 from 'd3'
import * as ReStock from 'react-stockcharts'
var { ChartCanvas, Chart, series, scale, coordinates, tooltip, axes, indicator, helper } = ReStock;
var { CandlestickSeries } = series;
var { XAxis, YAxis } = axes;
var { fitWidth, TypeChooser } = helper;
import CandleStickChart from './CandleStickChart'

class ChartView extends Component {

constructor(props) {
    super(props);

    this.state = {
      posts: []
    };
  }
componentDidMount() {
    var parseDate = d3.timeParse("%Y-%m-%d %H:%M:%S");
    d3.tsv(`http://localhost:3000/MSFT.tsv`, (err, data) => {
	/* change MSFT.tsv to MSFT_full.tsv above to see how this works with lots of data points */
       data.forEach((d, i) => {
            d.date = new Date(d3.timeParse("%Y-%m-%d")(d.date).getTime());
            d.open = +d.open;
            d.high = +d.high;
            d.low = +d.low;
            d.close = +d.close;
            d.volume = +d.volume;
            // console.log(d);
        });
        this.setState({ posts:data });
    });

  }

    render() {
        return (
            /* change the type from hybrid to svg to compare the performance between svg and canvas */
            <TypeChooser type="hybrid">{type => <CandleStickChart data={this.state.posts} type={type} />}</TypeChooser>
        );
    }
}
ChartView.propTypes = {

};
export default ChartView;

Condition is falling at this condition . But not able to understand the reason of failing.

not sure what this is

            {
				data && data.length &&
				 <ChartCanvas ratio={ratio} width={width} height={400}
					margin={{ left: 50, right: 50, top: 10, bottom: 30 }} type={type}
					seriesName="MSFT

there are many examples which are working, use that as a starting point, If you continue to have a problem share a plunker with a minimal reproducible example

This is the conditional rendering of the chart when the data is available. It seems to be config issue of webpack rather than that of this library. The component used in my tags are resolving to some script instead of chart component, thats why condition is failing

@vikas0380 what config did you change in your webpack to get this to work?


test(pie): modify test data. close #18732

Brief Information
This pull request is in the type of:

[ ] bug fixing
[ ] new feature
[ ] others

What does this PR do?

Fixed issues

Details
Before: What was the problem?

After: How does it behave after the fixing?

Document Info
One of the following should be checked.

[ ] This PR doesn't relate to document changes
[ ] The document should be updated later
[ ] The document changes have been made in apache/echarts-doc#xxx

Misc
ZRender Changes

[ ] This PR depends on ZRender changes (ecomfe/zrender#xxx).

Related test cases or examples to use the new APIs
N.A.
Others
Merging options

[ ] Please squash the commits into a single one when merging.

Other information

It's not necessary to modify the test case. This is an example of echarts-examples repo. You can submit a PR there if you'd like to. The link of this example file is https://github.com/apache/echarts-examples/blob/gh-pages/public/examples/ts/pie-half-donut.ts


Adaptive column example has incomplete row

How to reproduce this bug

Run the latest develop in Chrome.
Adjust the window's width.
Observe that sometimes a row is incomplete, while it should be.

Possible causes

Because of floating point rounding, a row's children might have a total width that is greater than the screen's width.

Closing this issue due to discontinuation of the adaptive packages.


Add TypeScript support for semantic colors

Proposal: Add TypeScript support for semantic colors

Summary
Recently I learned that in styles I can use OS colors using code like {semantic: 'selectedContentBackgroundColor'}. But when I do so TypeScript gives an error:
No overload matches this call.
  Overload 1 of 2, '(props: Readonly<ViewProps>): View', gave the following error.
    Type '{ backgroundColor: { semantic: string; }; }' is not assignable to type 'false | ViewStyle | RegisteredStyle<ViewStyle> | RecursiveArray<false | ViewStyle | RegisteredStyle<ViewStyle> | null | undefined> | readonly (false | ... 3 more ... | undefined)[] | null | undefined'.
      Types of property 'backgroundColor' are incompatible.
        Type '{ semantic: string; }' is not assignable to type 'string'.
  Overload 2 of 2, '(props: ViewProps, context?: any): View', gave the following error.
    Type '{ backgroundColor: { semantic: string; }; }' is not assignable to type 'false | ViewStyle | RegisteredStyle<ViewStyle> | RecursiveArray<false | ViewStyle | RegisteredStyle<ViewStyle> | null | undefined> | readonly (false | ... 3 more ... | undefined)[] | null | undefined'.
      Types of property 'backgroundColor' are incompatible.
        Type '{ semantic: string; }' is not assignable to type 'string'.ts(2769)

Motivation
Proper TypeScript support

I believe this is fixed by using PlatformColor and the 0.63 typings for react-native.  The details of the object layout of the colors are intentionally hidden.
https://github.com/DefinitelyTyped/DefinitelyTyped/commit/d2a9bce984b33920378ff6661fdf9c683274a0b4#diff-7c5007b14419e07403a6a320e5b22742

Correct. If needed we can backport this to the RN 0.62 typings; let me know.

I don't think it's urgent. We can wait until we're on 0.63. Thanks.

@acoates-ms Any idea of the support of PlatformColor on RN Windows?

PlatformColor should work in 0.63. -- It takes an array of values of a XAML resource keys that should be used. -- It unfortunately currently does not support fallback values, so only the first value is used.
In 0.62 you can use colors with the format of {windowsBrush: }. -- But there is no typings for that, and going forward PlatformColor is the thing we will be supporting.


Stepup related logging shows wrong key_id

I am not quite sure what it is that is logged in the key_id in stepup related logs. eg:
{"channel":"app","level":"WARNING","message":"After Stepup authentication update received LoA","context":{"key_id":"_2B40C7186DC7624C4804DE96F9454826","result":{}},"extra":{"session_id":"teia448dodmj9ea57sqegcjf4k","request_id":"6745867f3dd09"}}

The key_id for other logs is the id of the SAML signing key.

Could this be related to https://github.com/OpenConext/OpenConext-engineblock/issues/1241 ?


[1.12] general ci fixes

Testing

Trade-offs

Dependencies

Screenshots

:tada: This PR is included in version 2.25.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


autoclosing markdown preview when closing md file

Issue Type: Feature Request
When editing markdown file, it is quite convenient to have the preview in a aplit view. However, when I switch to another opened file (or closing the md file), the preview of markdown and the split is still there. This is annoying because I can only use half of the window for the new file.
VS Code version: Code 1.30.1 (dea8705087adb1b5e5ae1d9123278e178656186a, 2018-12-18T18:05:00.654Z)
OS version: Darwin x64 18.2.0

Is this request planned in a future milestone ?
It is a bit counterintuitive that once a .md file opened, the markdown preview is opened ad vitam aeternam until the user closes it manually.
Or at least have an option to enable/disable this behaviour.

Is there any solution for this? Seems very annoying to close the preview manually each time we open the md files!

Maybe you can try this extention: markdown-auto-preview

@vv13 do you know anything similar for svg files?

The workflow is similar, i use 'jock.svg'.
Leonardo Rick @.***> 于2024年8月26日周一 04:38写道：

@vv13 https://github.com/vv13 do you know anything similar for svg
files?
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/66132#issuecomment-2308985902,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACIA35DRFQZHF7C42E4KARDZTI6DNAVCNFSM6AAAAABNC22UYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYHE4DKOJQGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

@vv13 the svg preview with do not autoclose when closing the file with jock.svg


Fail fast on invalid entity instead of persit time SQLException

We can add @NonNull annotation on non nullable fields in our entities (in Blog entity for example) to avoid SQLException at persist time when particular non nullable field on given entity is not set (null). @NonNull annotation will raise NPE faster so we can just fail on entity creation (before entity is saved). This will make tracing errors much easier than digging through stack traces of SQLException. WDYT?

Fail-fast is always welcome for me :+1:

Sounds good. @NonNull from Lombok of course?

Any update on this? :) @goostleek

I think we can proceed with that one. The discussion is over. There were no objections to the proposed approach.


panic in one component caused the app to exit?

I'm interested in the idea of "locally running components" presented by Service Weaver, and I hope it can help me build a modular monolithic service composed of many functions. In my team the application is divided into hundreds of microservices, which is difficult to maintain.
However, one advantage of microservices is that they provide physical fault isolation. For example, a panic during release will not cause a large-scale breakdown of the entire system, if the caller handles those RPC error correctly.
Since Service Weaver runs the application in multiple processes, I think of the component as an analogy to a single microservice. Problems within a component only affect itself. So I tried adding a Panicker in the Step by Step example, and then executed weaver multi deploy, called the Panicker. But this caused the app to exit. Did I misunderstand something here?
code:
// Panicker component.
type Panicker interface {
	Panic(context.Context, string) (string, error)
}

// Implementation of the Panicker component.
type panicker struct {
	weaver.Implements[Panicker]
}

// Panic causes panic when certain inputs are encountered
func (p *panicker) Panic(_ context.Context, s string) (string, error) {
	if s == "panic" {
		panic("panicker: " + s)
	}
	return "all good", nil
}

// app is the main component of the application. weaver.Run creates
// it and passes it to serve.
type app struct {
	weaver.Implements[weaver.Main]
	reverser weaver.Ref[Reverser]
	panicker weaver.Ref[Panicker]
	hello    weaver.Listener
}

func serve(ctx context.Context, app *app) error {
	// The hello listener will listen on a random port chosen by the operating
	// system. This behavior can be changed in the config file.
	fmt.Printf("hello listener available on %v\n", app.hello)

	// Serve the /hello endpoint.
	http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
		name := r.URL.Query().Get("name")
		if name == "" {
			name = "World"
		}
		reversed, err := app.reverser.Get().Reverse(ctx, name)
		if err != nil {
			http.Error(w, err.Error(), http.StatusInternalServerError)
			return
		}
		panicked, err := app.panicker.Get().Panic(ctx, name)
		if err != nil {
			http.Error(w, err.Error(), http.StatusInternalServerError)
			return
		}
		fmt.Fprintf(w, "Hello, %s, and %s\n", reversed, panicked)
	})
	return http.Serve(app.hello, nil)
}

stderr:
❯ weaver multi deploy weaver.toml
╭───────────────────────────────────────────────────╮
│ app        : hello                                │
│ deployment : 157a2898-1aaf-4a62-bd90-cf532a7f89f3 │
╰───────────────────────────────────────────────────╯
S0101 08:00:00.000000 stdout               dfb270dd                      │ hello listener available on <IP_ADDRESS>:12345
S0101 08:00:00.000000 stdout               99b2877c                      │ hello listener available on <IP_ADDRESS>:12345
S0101 08:00:00.000000 stderr               54f72854                      │ panic: panicker panicked: panic [recovered]
S0101 08:00:00.000000 stderr               54f72854                      │        panic: panicker panicked: panic
S0101 08:00:00.000000 stderr               54f72854                      │
S0101 08:00:00.000000 stderr               54f72854                      │ goroutine 25 [running]:
S0101 08:00:00.000000 stderr               54f72854                      │ github.com/ServiceWeaver/weaver/runtime/codegen.CatchPanics({0xbf0660, 0xc00061a030})
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/go/pkg/mod/github.com/!service!weaver/weaver@v0.22.0/runtime/codegen/errors.go:29 +0xee
S0101 08:00:00.000000 stderr               54f72854                      │ main.panicker_server_stub.panic.func1()
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/code/hello/weaver_gen.go:350 +0x2c
S0101 08:00:00.000000 stderr               54f72854                      │ panic({0xbf0660?, 0xc00061a030?})
S0101 08:00:00.000000 stderr               54f72854                      │        /usr/local/go/src/runtime/panic.go:914 +0x21f
S0101 08:00:00.000000 stderr               54f72854                      │ main.(*panicker).Panic(0x0?, {0xc000612035?, 0x5?}, {0xc00060e030?, 0xc00051f9e8?})
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/code/hello/panicker.go:22 +0x65
S0101 08:00:00.000000 stderr               54f72854                      │ main.panicker_server_stub.panic({{0x7f300d60d010?, 0xc0005a60a0?}, 0xc000538018?}, {0xe58100, 0xc000616050}, {0xc000612031?, 0xc000538018?, 0xc0005a60a0?})
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/code/hello/weaver_gen.go:362 +0x11e
S0101 08:00:00.000000 stderr               54f72854                      │ github.com/ServiceWeaver/weaver/internal/weaver.(*RemoteWeavelet).addHandlers.func1({0xe58100, 0xc000616050}, {0xc000612031, 0x9, 0x9})
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/go/pkg/mod/github.com/!service!weaver/weaver@v0.22.0/internal/weaver/remoteweavelet.go:597 +0xc3
S0101 08:00:00.000000 stderr               54f72854                      │ github.com/ServiceWeaver/weaver/internal/net/call.(*serverConnection).runHandler(0xc000163e60, 0xc000037620, 0x1, {0xc000612000, 0x3a, 0x3a})
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/go/pkg/mod/github.com/!service!weaver/weaver@v0.22.0/internal/net/call/call.go:1001 +0x8f9
S0101 08:00:00.000000 stderr               54f72854                      │ github.com/ServiceWeaver/weaver/internal/net/call.(*serverConnection).readRequests(0xc000163e60, {0xe58100?, 0xc0005b9810}, 0xc000037620, 0xc000013bd8)
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/go/pkg/mod/github.com/!service!weaver/weaver@v0.22.0/internal/net/call/call.go:921 +0x1ac
S0101 08:00:00.000000 stderr               54f72854                      │ created by github.com/ServiceWeaver/weaver/internal/net/call.(*serverState).serveConnection in goroutine 42
S0101 08:00:00.000000 stderr               54f72854                      │        /home/sean/go/pkg/mod/github.com/!service!weaver/weaver@v0.22.0/internal/net/call/call.go:281 +0x376
2023/12/20 19:40:07 http: proxy error: EOF
capture stdout: EOF

status:
❯ weaver multi status
╭────────────────────────────────────────────────────╮
│ DEPLOYMENTS                                        │
├───────┬──────────────────────────────────────┬─────┤
│ APP   │ DEPLOYMENT                           │ AGE │
├───────┼──────────────────────────────────────┼─────┤
│ hello │ 23e97041-3acf-4e68-bbe2-bb70e278d59d │ 7s  │
╰───────┴──────────────────────────────────────┴─────╯
╭────────────────────────────────────────────────────────╮
│ COMPONENTS                                             │
├───────┬────────────┬────────────────┬──────────────────┤
│ APP   │ DEPLOYMENT │ COMPONENT      │ REPLICA PIDS     │
├───────┼────────────┼────────────────┼──────────────────┤
│ hello │ 23e97041   │ weaver.Main    │ 1566909, 1566921 │
│ hello │ 23e97041   │ hello.Panicker │ 1566959, 1566973 │
│ hello │ 23e97041   │ hello.Reverser │ 1566934, 1566946 │
╰───────┴────────────┴────────────────┴──────────────────╯
╭─────────────────────────────────────────────────╮
│ LISTENERS                                       │
├───────┬────────────┬──────────┬─────────────────┤
│ APP   │ DEPLOYMENT │ LISTENER │ ADDRESS         │
├───────┼────────────┼──────────┼─────────────────┤
│ hello │ 23e97041   │ hello    │ <IP_ADDRESS>:12345 │
╰───────┴────────────┴──────────┴─────────────────╯

Hi @soaringk, happy to hear you're interested in Service Weaver!  Here's the code that's responsible for that:
https://github.com/ServiceWeaver/weaver/blob/abde5cad1004a59d716d6301b18411788ee5a721/internal/tool/multi/deployer.go#L380
I should note that this is specific to the weaver multi deployer. The weaver gke and weaver kube deployers restart failed components.
Previously, the weaver multi deployer also restarted failed components. Later, we decided that the weaver multi deployer was largely for testing your application before you deploy it with a more production-ready deployer like weaver gke and weaver kube. Because of this, if something panicked when testing locally, we wanted to escalate the error instead of swallowing it.
We're open to revisiting that decision though!

if something panicked when testing locally, we wanted to escalate the error instead of swallowing it

Hi @mwhittaker, thank you for your response. I agree with you, and this is especially true for Testing. However, waver gke and waver kube seem to become the only way of actually deploying application, while weaver multi can only be used for testing. It that true?
Would it be a good idea to add a flag to weaver multi command so that it can be used for both testing and deploying? Such as weaver multi deploy --release=true.

Hi @soaringk. That's correct, weaver gke, weaver kube and the experimental weaver ssh are intended for deployment into production. However, there's nothing preventing you from running weaver kube, weaver ssh or weaver gke on your local machine. For the latter, we have a weaver gke local variation.
Could you provide more details about your usecase? I'm curious about how you plan to use weaver multi to deploy your application into production.
As Michael mentioned, we can revisit the decisions made regarding weaver multi. Right now, we view weaver multi as a deployer that someone can use to quickly run and test on their local machine.

Hi @rgrandl. I must have missed this weaver gee local variation. Thank you for your information.
I tried running the above example with this variation and I found that the app seemed to keep "retrying". I could see the panic log in stderr and the app was never truly shut down, but the response was never received. Therefore, the curl command hanged until I interrupted it. Is this expected? Because calls in RPC usually just return err to the caller if something bad happens.

Speaking of my use case, my team is responsible for product development, while deployment is managed by a separate infrastructure team. As a result, it may require some additional effort to deploy the weaver to a Kubernetes cluster, as I am not familiar with this layer.
In the beginning, I assumed that running the service weaver would be similar to deploying a single executable, while still having all the features of microservices. As a member of the product team, I can focus on writing code as usual and without worrying about the deployment process.

If I make the program panic with a probability of one-tenth, I would see that when the panic occurs, one instance becomes unhealthy, but I still receive the correct response, which should be from another instance.
❯ weaver gke-local status
╭───────────────────────────────────────────────────────────────╮
│ Deployments                                                   │
├───────┬──────────────────────────────────────┬───────┬────────┤
│ APP   │ DEPLOYMENT                           │ AGE   │ STATUS │
├───────┼──────────────────────────────────────┼───────┼────────┤
│ hello │ 26459c14-d58b-4d68-9c40-2aacaf2972ad │ 1m10s │ ACTIVE │
╰───────┴──────────────────────────────────────┴───────┴────────╯
╭───────────────────────────────────────────────────────────╮
│ COMPONENTS                                                │
├───────┬────────────┬───────────┬────────────────┬─────────┤
│ APP   │ DEPLOYMENT │ LOCATION  │ COMPONENT      │ HEALTHY │
├───────┼────────────┼───────────┼────────────────┼─────────┤
│ hello │ 26459c14   │ cn-south1 │ weaver.Main    │ 2/2     │
│ hello │ 26459c14   │ cn-south1 │ hello.Panicker │ 1/1     │
│ hello │ 26459c14   │ cn-south1 │ hello.Reverser │ 2/2     │
╰───────┴────────────┴───────────┴────────────────┴─────────╯
╭─────────────────────────────────────────────────────────────────────────────────────────╮
│ TRAFFIC                                                                                │
├───────────┬────────────┬───────┬────────────┬───────────┬────────────┬──────────────────┤
│ HOST      │ VISIBILITY │ APP   │ DEPLOYMENT │ LOCATION  │ ADDRESS    │ TRAFFIC FRACTION │
├───────────┼────────────┼───────┼────────────┼───────────┼────────────┼──────────────────┤
│ hello.com │ public     │ hello │ 26459c14   │ cn-south1 │ [::]:45619 │ 0.5              │
│ hello.com │ public     │ hello │ 26459c14   │ cn-south1 │ [::]:41887 │ 0.5              │
╰───────────┴────────────┴───────┴────────────┴───────────┴────────────┴──────────────────╯
╭─────────────────────────────╮
│ ROLLOUT OF hello            │
├─────────────────┬───────────┤
│                 │ cn-south1 │
├─────────────────┼───────────┤
│ TIME            │ 26459c14  │
│ Dec 25 08:14:31 │ 1.00      │
╰─────────────────┴───────────╯


Remove deprecated cache_hit arg

Closes issue #20

@CannonLock any progress on this one?

Go ahead and merge this and do new things on a new branch 😜 !


How to iterate through children spans from current transaction ?

Is your feature request related to a problem? Please describe.
A common problem of relying on an ORMs is the "N+1 queries" pattern.
To make sure that application performances are fine, I want to add transaction labels with number of spans per type / subtype.
Describe the solution you'd like
I think the best way to do that would be in a middleware, at the very end of the transaction execution.
I would like to be able to write this:
import collections
import elasticapm

class AddCountPerSpanTypeMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        res = self.get_response(request)

        apm_transaction = elasticapm.traces.execution_context.get_transaction()
       if not apm_transaction.spans:
           return res

       breakdown_per_type = collections.defaultdict(int)
       for a_span in (apm_transaction.spans or tuple()):
           breakdown_per_type[a_span.type]  += 1
           if a_span.subtype:
               breakdown_per_type[a_span.type + '/' + a_span.subtype] += 1

       elasticapm.tag(span_count_by_time=dict(breakdown_per_type.items())
       return res

But as I understand it, the current data model links a span to a transaction, but not the other way around: the Transaction class does not have a spans property
Describe alternatives you've considered
I managed to work around this by patching Transaction.track_span_duration, but this is just a hack at the moment
import elasticapm.traces

original_track_span_duration = elasticapm.traces.Transaction.track_span_duration

def patched_track_span_duration(transaction, span_type, span_subtype, self_duration):
    original_track_span_duration(span, span_type, span_subtype, self_duration)
    if not hasattr(transaction, 'breakdown_per_type'):
        transaction.breakdown_per_type = collections.defaultdict(int)
    transaction.breakdown_per_type[span_type] += 1
    if span_subtype:
        transaction.breakdown_per_type[span_type + '/' + span_subtype] += 1

elasticapm.traces.Transaction.track_span_duration = patched_track_span_duration

Additional context
Linking transaction and spans objects in both directions may create ref-cycles, maybe that's why it has not been implemented so far ?
For the particular usecase I describe, I don't need the full Span objects, just their type & subtypes.

I don't think this is a data model change that we're going to make. A transaction can have unlimited spans attached to it, and tracking them in the transaction object could be costly, when on the Elasticsearch end it's trivial to query out all spans that are tied to a given transaction.
It's possible that this could be a useful feature in Kibana. You might consider opening an issue over in https://github.com/elastic/apm with more information on how you use this information.


Allow SocietyOfMind agent to work with function calling and tools.

Why are these changes needed?
Resolves #1553, and adds tests to ensure it doesn't break again.
Checks

[ ] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

Codecov Report
Attention: 13 lines in your changes are missing coverage. Please review.

Comparison is base (3e33a2c) 35.28% compared to head (f21d480) 19.57%.

Files
Patch %
Lines

autogen/agentchat/contrib/society_of_mind_agent.py
0.00%
13 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1569       +/-   ##
===========================================
- Coverage   35.28%   19.57%   -15.72%
===========================================
  Files          44       44
  Lines        5311     5324       +13
  Branches     1231     1305       +74
===========================================
- Hits         1874     1042      -832
- Misses       3283     4145      +862
+ Partials      154      137       -17

Flag
Coverage Δ

unittests
19.57% <0.00%> (-15.72%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Tutorial - Animation control chapter - example not seek back

https://lib.vizzuhq.com/latest/#chapter-0.15

fixed in 0.5.0 doc


R200: No visual effects change in 'cpp-config-ui' when adjust some options

Required Info

Camera Model
R200

Firmware Version
<IP_ADDRESS>

Operating System & Version
Ubuntu 14.04.4 LTS

Kernel Version (Linux Only)
4.4.0-040400-generic

Build System
Makefile

Use 'cpp-config-ui' to test options of R200, with Start Capture, when adjust option 'COLOR_GAIN', or 'COLOR_HUE', or 'COLOR_SHARPNESS', the value be changed correctly, but there's no visual effects change.
What's the correct behavior?

For the R200 camera, COLOR_GAIN has no visual effect when COLOR_AUTO_EXPOSURE is set to 1.
Visual effects of HUE and SHARPNESS are subtle, but clearly visible when you zoom in to the pixel level.

COLOR_EXPOSURE or COLOR_ENABLE_AUTO_EXPOSURE?
I can't see these 2 options in cpp-config-ui, and the range of them are 0 - 0, why it be set to 1?

@wangji1 This is a known bug and documented in #19 as an outstanding issue


[doc]change directory of the ssh keys

Compatible with Symfony3

@chalasr modifications done

Merged in 2.0.
Thank you @n1c01a5.


PodIp not set

in kubernetes 1.5.1 pod info ( name ip )  is async so in some case it's set 3 or 5 sec after app start we need to handle this case ( start condition )
bug track -> https://github.com/kubernetes/kubernetes/issues/39113

It's an error that we use pod IP in the deployment, statefulset, & daemonset yamls, in reality it isn't  used for anything anymore. I will remove it from those yamls to avoid this issue there.
So this issue will only affect those running the provisioner as a standalone pod. I don't want to do anything to solve this that will affect the other (better & documented) ways of running. Any objections to just waiting for them to fix this bug?

i'm not sure about this one
I have setup the nfs-provider with DaemonSet and this idiot set the nfs server adresse as my server domain
( kube1.domain.tld ) and not the podIp  it's since I have updated to kube 1.5.1

Can I see the daemonset yaml? I get you should be able to use pod ip if you want to.
I'll work on a proper fix, I realized theres an easy way to do it that works everywhere

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  creationTimestamp: 2016-12-25T18:43:47Z
  generation: 1
  labels:
    app: nfs-provisioner
  name: nfs-provisioner
  namespace: default
  resourceVersion: "6059087"
  selfLink: /apis/extensions/v1beta1/namespaces/default/daemonsets/nfs-provisioner
  uid: 122ea6b2-cad2-11e6-853c-7054d216f5a7
spec:
  selector:
    matchLabels:
      app: nfs-provisioner
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nfs-provisioner
    spec:
      containers:
      - args:
        - -provisioner=eko.ovh/nfs
        - grace-period=0
        env:
        - name: POD_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.podIP
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName
        image: quay.io/kubernetes_incubator/nfs-provisioner:v1.0.1
        imagePullPolicy: IfNotPresent
        name: nfs-provisioner
        ports:
        - containerPort: 2049
          name: nfs
          protocol: TCP
        - containerPort: 20048
          name: mountd
          protocol: TCP
        - containerPort: 111
          name: rpcbind
          protocol: TCP
        - containerPort: 111
          name: rpcbind-udp
          protocol: UDP
        resources: {}
        securityContext:
          capabilities:
            add:
            - DAC_READ_SEARCH
        terminationMessagePath: /dev/termination-log
        volumeMounts:
        - mountPath: /export
          name: export-volume
      dnsPolicy: ClusterFirst
      nodeSelector:
        app: nfs-provisioner
      restartPolicy: Always
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - hostPath:
          path: /mnt/data
        name: export-volume
status:
  currentNumberScheduled: 1
  desiredNumberScheduled: 1
  numberMisscheduled: 0

any ide for fix the problem ?

If NODE_NAME is set, the provisioner will use it to set the nfs server ip to the spec.nodeName. which I assume you do not want because then there would be an nfs server from your tld. So if you want it to use the pod IP instead, have to remove this:
 - name: NODE_NAME
   valueFrom:
     fieldRef:
       apiVersion: v1
       fieldPath: spec.nodeName

Now, the problem with using pod IP you have found is that it isn't set for a few seconds at the beginning, so if it were to try to Provision a PV for a PVC in those few seconds, it would use the output of hostname -p instead of the pod IP which is also wrong. Do I understand correctly?
I am working on making it smarter, to not use hostname -p except when it's running out of cluster and has no other choice.

okay I got it 👍

OK, this particular issue is fixed by https://github.com/kubernetes-incubator/nfs-provisioner/pull/52 . if pod IP is not set in time, provision will fail and retry a couple seconds later.
So I will have to find a proper place to document this but basically new behavior is:

if NODE_NAME is set, NFS server IP will be set to the name of the node it's running on
if SERVICE_NAME is set, POD_IP and POD_NAMESPACE must also be set: if the service is valid, NFS server IP will be set to the cluster IP of the service
if neither NODE_NAME or SERVICE_NAME is set, NFS server IP will be set to the (potentially unstable) pod IP from POD_IP

if any questions don't hesitate to ask :)


Extend titleFrom documentation with group mode

titleFrom does not work with a repeater in group mode

Wouldn't it still work in group mode so long as the titleFrom was available in every group?
Perhaps we could add a titleFrom to the group definitions to better support it in group mode?

Wouldn't it still work in group mode so long as the titleFrom was available in every group?

currently it wouldn't.

Perhaps we could add a titleFrom to the group definitions to better support it in group mode?

maybe, not sure it's worth it, though.

Yeah, I've confirmed it doesn't work in group mode either, and making it available to the group is not foolproof for two reasons - the fact that it would need the same field in each group type for one, and secondly, then there is no way to tell which group a particular item is, as the title at the moment is the only thing that identifies the group.


Add Custom Extension to Client Hello Message

I would like to add a custom extension to client hello message(in addition to the built in extension - see picture below from wireshark).
On openssl.org documentation I have found some information at: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_add_client_custom_ext.html but I would like to know which files I need to edit/modify to achieve the target objective.
I will appreciate assistance.

The process is:
Create an SSL_CTX in the normal way, the call SSL_CTX_add_custom_ext, supplying the reference to the SSL_CTX you created. The second argument is the assigned type of the extension (obtained from whatever standards document the extension is defined in). The third argument is the context  that the extension is valid for - you just want it in the ClientHello then this would be SSL_EXT_CLIENT_HELLO. The following arguments are the callbacks you need to write for adding, freeing, and parsing the custom extension.

I would like to know which files I need to edit/modify to achieve the target objective.

This question makes no sense. You don't need to edit/modify any files except those in your own application.

Thanks @mattcaswell  for your response. I have gone through OpenSSL code and I can see all the inbuilt extensions in the code, for instance:
TLSEXT_TYPE_padding
TLSEXT_TYPE_renegotiate
TLSEXT_TYPE_max_fragment_length
TLSEXT_TYPE_server_name
TLSEXT_TYPE_session_ticket
TLSEXT_TYPE_signature_algorithms.

I want to add custom extension but when I 'mimic' how the inbuilt extensions have been added, my custom extension is not appearing in the client hello message when I check on WireShark

Does your "add" callback get called, and does it return 1?

Hello @mattcaswell, kindly let me know if my approach will yield the desired results of adding the custom extension in client hello at TLS Handshake(inspected using WireShark).
I have tried to edit the file .../ssl/statem/extensions_cust.c and define custom extensions e.g:
static const custom_ext_method *meths = {
    {
        TLSEXT_TYPE_custom_extension_1,
        ENDPOINT_CLIENT,
        SSL_EXT_CLIENT_HELLO,
        NULL, NULL, NULL, NULL, NULL, NULL
    },
    {
        TLSEXT_TYPE_custom_extension_1,
        ENDPOINT_CLIENT,
        SSL_EXT_CLIENT_HELLO,
        NULL, NULL, NULL, NULL, NULL, NULL
    }
};```

Then I complile the project to get openssl.exe which am using to generate the SSL certificate.

Matt was trying to tell you that you don't need to modify the openssl code at all.  So editing ssl/statem/extensions_cust.c is not the intended approach.  You define funtions in your own application code matching the 'add', 'free', and 'parse' callback type signatures described in SSL_CTX_add_custom_ext(3), and then you call SSL_CTX_add_custom_ext() to set those callbacks as active on your SSL_CTX.

Thanks @kaduk for clarifying, I have not created  SSL_CTX before, kindly could you be having some guidelines on how to go about it?

@tom-njoroge an SSL_CTX is required in order to make any kind of TLS connection, so you probably have been using them somehow even if you aren't explicitly aware of it.  In order to make my explanation more understandable to you, could you say a little bit about how you normally initiate a TLS connection (without any custom extensions)?

@kaduk I make TLS connections by using SSL certificates which I install on the server.

@tom-njoroge surely there is some software involved!  It sounds like you are using some existing (open-source?) software rather than writing your own from scratch, though?

@kaduk I have been using existing software which meets the requirements. This time I need to add an extension and I will appreciate steps of creating SSL_CTX to achieve that.

@tom-njoroge Well, backing up to the start again, if you need custom functionality it has to go in either the application or in openssl.  Matt and I had been assuming that it would go in the application, since most people ask questions about how to get something working with their application, and it's usually easiest for them (and simplest from a maintainability perspective) to keep the modifications in the application.  If the custom functionality goes into openssl, then you or your successor has to maintain that code, port it to new releases of openssl, etc., indefinitely, which is a lot of work.  If, on the other hand, the extension is standardized somewhere then the implementation might be appropriate to incoprorate into openssl upstream and the openssl project would maintain it.  But without knowing more about what your application is or what the extension is, it's very hard for me to give good advice for what you should do.

Thanks @kaduk  and @mattcaswell for your input. I had not coded an application on low level using C language. Now I understand that I need to add the functionality to the application I want to make TLS connection. I have found some sample code which I have built on to achieve the intended goal. The example is at: https://aticleworld.com/ssl-server-client-using-openssl-in-c/

Marking as inactive, to be closed at the end of 3.4 dev, barring further input


SignalR Connection remains lingering

Hello, I noticed that the connections remain in memory after disconnecting, so I was wondering how does that affect performance and is there an easy way to delete the unused SignalR (connection) objects? Thanks!

They remain in memory so you can reconnect and resume as normal. Are you suggesting something like a destroy function that disconnects and removes the connection object, handlers, etc.?
Something like that might be reasonable. Are you aware of any similar functionality in the official/other SignalR clients?

Yes, a destroy method. I don't know any similar functionality, I just noticed that the number of connections is increasing every time I move from a screen (and I close the connection) and back to the screen (and I start the connection).

Could you use one connection globally in the application, then stop/start it as needed?

Yeah, it did the trick. Thanks!


Update modes.md

Fix typo
What kind of change does this PR introduce? (check one with "x")

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[x] Other... Please describe:

What is the current behavior? (You can also link to an open issue here)
There is a typo.
What is the new behavior?
The typo is fixed
Does this PR introduce a breaking change? (check one with "x")

[ ] Yes
[x] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Thanks!


Show data for PUT requests in rollbar-php

Details in https://app.clubhouse.io/rollbar/story/20293/show-data-for-put-requests-in-rollbar-php

There was a user report of an item that occurred during a PUT request with a POST body and that the body of the request was not included in the payload. This was using 0.18.2. I think that since 1.0 we have been including the POST body in the payload, but just double check that before closing this.

This is ready for review in PR https://github.com/rollbar/rollbar-php/pull/266
Note: POST fields are only going to be included if Rollbar is configured with include_raw_request_body


Update root documentation for new build and installation processes.

Updated documentation.  Split out docker and host install into their own
files.  Added an environment document.
Updated the default value for TINYSCHEME_SRC to reflect the build
instructions more closely.
Small fix to the Makefile.
Signed-off-by: Mic Bowman<EMAIL_ADDRESS>

this addresses #105

My past comments are all resolved. There is one i thought i made but don't see so maybe somehow got lost. We currently say in README.md this means (at least) two different physical systems if using SGX-enabled hardware. If running in SGX simulation mode, this could be two virtual machines or containers. This is not really true : we can run out-of-the-box on a single machine in SGX-HW mode with containers (and presumably also with sgx-enabled kvm VMs, not that i really want to go into documenting that :-). In fact, even without docker you could run sawtooth in VM (obviously not PoET but then that is currently broken anyway) and just keep the rest in host?
So maybe more accurate phrasing could be along the lines of This means if you want to run PDO on a single physical host, either PDO or sawtooth will have to run in a VM or container. In particular, to run PDO in HW mode the PDO component has to run in an SGX-enabled environment. Below instructions make sure that the host and the docker components fullfill this requirement.
Related, we say recommended configuration for the split but then from what follows it's clear that it really is a required configuration practically speaking: s/recommend/required/ ?

addressed in my commit, see above ...


Help with maintenance

Dear maintainers,
I'll like to help with maintenance - in particular to upgrade the dependency avoiding the use of m2r.
This is a follow-up of the issue I raised there: https://github.com/sphinx-contrib/github-administration/issues/30

@stephenfin would you be willing to grant me the relevant permission in the absence of answer from the current maintainers?

Would you be able to open a PR with the relevant fixes first? If @ikalnytskyi isn't available, we'll also need to reach out to the PyPI team to request access there so it's going to be some time before this can be fixed fully

I have requested access to the project on PyPI. If this is accepted, I will look to merge the open PRs and get the gate passing again. We can also explore adding additional maintainers to help limit the bus factor.


Make DirectVT-apps configurable via settings

Description
I took the XML-format as the basis for the settings storage format. I don't consider formats that rely on fixed indentation (like YAML), since I use environment variables to store configuration blocks/parts.

<document> - Top-level element

<thing> - Second level element

<name> - Third level element

To simplify parsing and structure in general, I consider the following forms of element declaration to be equivalent
<document>
    <thing name="a">text1</thing>
    <thing name="b">text2</thing>
</document>

<document>
    <thing="text1" name="a"/>
    <thing="text2" name="b"/>
</document>

<document>
    <thing name="a">
        "text1"
    </thing>
    <thing name="b">
        "text2"
    </thing>
</document>

<document>
    <thing>
        "text1"
        <name="a"/>
    </thing>
    <thing>
        <name="b"/>
        "text2"
    </thing>
</document>

<document>
    <thing="t">
        "ext"
        <name>
            "a"
        </name>
        "1"
    </thing>
    <thing>
        <name>
            "b"
        </name>
        "text"
        "2"
    </thing>
</document>

Defaults
Use asterisk at the end of the element name to set defaults.
The following declarations are the same
<document>
    <thing name="text">another_text</thing>
    <thing name="text">another_text</thing>
</document>

<document>
    <thing* name="text"/> <!-- skip this element and set name="text" as default for the following things -->
    <thing>another_text</thing>
    <thing>another_text</thing>
</document>

<document>
    <thing* name="text"/>
    <thing="another_text"/>
    <thing="another_text"/>
</document>

<document>
    <thing*="another_text" name="text"/>  <!-- skip this element and set thing="another_text" and name="text" as default for the following things -->
    <thing/>
    <thing/>
</document>

Configuration example
id=Term is a built-in terminal emulator.
~/.config/vtm/settings.xml
<config>
    <menu>
        <selected=Term /> <!-- set selected using menu item id -->
        <item splitter label="apps">
            <notes>
                " Default applications group                         \n"
                " It can be configured in ~/.config/vtm/settings.xml "
            </notes>
        </item>
        <item* />    <!-- use asterisk at the end of the element name to set defaults -->
        <item* index=-1 hidden=no slimmenu=false type=SHELL fgcolor=#00000000 bgcolor=#00000000 winsize=0,0 wincoor=0,0 />
        <item id=Term label="Term" type=DirectVT title="Terminal Emulator" notes=" Run built-in terminal emulator ">
            <hotkeys>
                <action=start key="Ctrl+'t'"/>
                <action=close key="Ctrl+'z'"/>
            </hotkeys>
            <param="vtm -r term">
                <scrollback>
                    <size=20000 />
                    <growstep=0 />
                </scrollback>
                <colors>
                    <palette>
                        <color=0xFF101010 index=0 />  <!-- 0  blackdk   -->
                        <color=0xFF1F0FC4 />          <!-- 1  reddk     -->
                        <color=0xFF0EA112 />          <!-- 2  greendk   -->
                        <color=0xFF009CC0 />          <!-- 3  yellowdk  -->
                        <color=0xFFDB3700 />          <!-- 4  bluedk    -->
                        <color=0xFF981787 />          <!-- 5  magentadk -->
                        <color=0xFFDD963B />          <!-- 6  cyandk    -->
                        <color=0xFFBBBBBB />          <!-- 7  whitedk   -->
                        <color=0xFF757575 />          <!-- 8  blacklt   -->
                        <color=0xFF5648E6 />          <!-- 9  redlt     -->
                        <color=0xFF0CC615 />          <!-- 10 greenlt   -->
                        <color=0xFFA5F1F8 />          <!-- 11 yellowlt  -->
                        <color=0xFFFF783A />          <!-- 12 bluelt    -->
                        <color=0xFF9E00B3 />          <!-- 13 magentalt -->
                        <color=0xFFD6D660 />          <!-- 14 cyanlt    -->
                        <color=0xFFF3F3F3 index=15 /> <!-- 15 whitelt   -->
                    </palette>
                    <default>
                        <fg=15 /> <!-- 256-color index is allowed -->
                        <bg=0 />
                    </default>
                    <match fx=selection bg="0xFF007F00" fg=15 />  <!-- set fx to use cell::shaders: xlight | selection |contrast | invert | reverse -->
                    <selection>
                        <text fx=selection bg=12 fg=15 />
                        <ansi fx=xlight/>
                        <none fx=selection bg=8 fg=7 />
                    </selection>
                </colors>
                <tablen=8 />      <!-- Tab length. -->
                <maxline=65535 /> <!-- Max line length. Line splits if it exceeds the limit. -->
                <cursor>
                    <style="underline"/> <!-- block | underline  -->
                    <blink="400"/>       <!-- blink period in ms -->
                </cursor>
                <menu>
                    <enabled="on"/>
                    <slim="off"/>
                </menu>
                <wrap="on"/>
                <selection>
                    <mode="plain"/> <!-- plain | ansi | disabled -->
                </selection>
                <hotkeys>
                    <action=findNext key="Alt+RightArrow"/>
                    <action=findPrev key="Alt+LeftArrow"/>
                </hotkeys>
            </param>
        </item>
        <item id=mc        label="mc"        type=SHELL    title="Midnight Commander"    param="mc"               notes=" Run Midnight Commander in its own window (if it is installed) "/>
        <item id=Tile      label="Tile"      type=Group    title="Tiling Window Manager" param="h1:1(Term, Term)" notes=" Run Tiling Window Manager with two terminals attached "/>
        <item id=View      label=View        type=Region   title="\e[11:3pView: Region"                           notes=" Set desktop region "/>
        <item id=Settings  label=Settings    type=DirectVT title="Settings"              param="$0 -r settings"   notes=" Configure frame rate " winsize=50,15 />
        <item id=Logs      label=Logs        type=DirectVT title="Logs Title"            param="$0 -r logs"       notes=" Run Logs application "/>
        <item splitter label="demo" notes=" Demo apps                    \n Feel the Desktopio Framework "/>
        <item id=Gems      label="Gems"      type=DirectVT title="Gems Title"            param="$0 -r gems"       notes=" App Distribution Hub "/>
        <item id=Text      label="Text"      type=DirectVT title="Text Title"            param="$0 -r text"       notes=" Text Editor "/>
        <item id=Calc      label="Calc"      type=DirectVT title="Calc Title"            param="$0 -r calc"       notes=" Spreadsheet Calculator "/>
        <item id=Test      label="Test"      type=DirectVT title="Test Title"            param="$0 -r test"       notes=" Test Page "/>
        <item id=Truecolor label="Truecolor" type=DirectVT title="True Title"            param="$0 -r truecolor"  notes=" Truecolor Test "/>
        <autorun>
            <item*=Term winsize=48%,48% /> <!-- item*=_item_id_ - assign the same _item_id_ to each item by default -->
            <item wincoor=0,0 />
            <item wincoor=52%,0 />
            <item wincoor=0,52% />
            <item=mc wincoor=52%,52% />
        </autorun>
    </menu>
    <hotkeys>
        <action=prevWindow key="Ctrl+PgUp"/>
        <action=nextWindow key="Ctrl+PgDn"/>
    </hotkeys>
</config>

I just compiled vtm 0.8.0 (commit hash: 253d039eed8934f3192804f32464cc6914e7cddf).
Trying the example config in settings, the Term app isn't launching.
FYI here's the menuitem for Term:

When click on it, I do get the notes message appearing in the top left, but no app is created.
when I run vtm -r term bash from outside vtm, it works well.
when replacing the menuitem with a type=SHELL, the Term application launches correctly     <menuitem id=Term index=1 label="Term" bgcolor=#0a0a0a fgcolor=15 slimmenu notes="$0 -r Term:\nTerminal emulator" type=DirectVT param="vtm -r term bash"/>

I don't know if there are any logs I can look at for error messages, if there are, please let me know.

@joehakimrahme One moment, I'll see what's going on here.

Everything looks right. To view the logs, you can run the server part and the client part in separate terminals

server: vtm -s
client: vtm

The server will output something like
apps: app type: directvt, menu item id: Term
dtvt: new child process: 'vtm -r term bash' at the current working directory
dtvt: conpty created: { 65, 50 }
dtvt: id: 7236 reading thread started
dtvt: id: 9376 writing thread started
dtvt: id: 19532 logging thread for process:12308 started
    12308:   os: DirectVT detected
    12308: Desktopio Terminal v0.8.0
    12308: host: started at 60fps
    12308: diff: id: 20340 rendering thread started
    12308: xpty: new child process: 'bash' at the current working directory
    12308: xpty: conpty created: { 65, 48 }
    12308: xpty: id: 19312 reading thread started
    12308: xpty: id: 8196 writing thread started

You can also check the uniqueness of id=Term

Also vtm should be in PATH, because the absolute path is not specified in the parameters.

Good catch, it was a PATH issue. Even replacing vtm with ./vtm worked, so even relative paths are good if they resolve.
Do you think it's worth updating the README to mention something about this?

Thanks for the tip, I'll clarify this point in the readme when I finish config_v2, more settings will be possible there 🙂

The best solution is to replace param=“vtm -r term bash” with param=“$0 -r term bash”. $0 will be auto converted to the current module file name with full path.

New xml-parser can change the values of elements while maintaining the original formatting and comments

This is necessary to preserve the settings.xml original formatting (+comments) when changing settings using vtm.