Cargo build fail, that rustc version is 1.45.2

cargo build
Updating crates.io index
Compiling version_check v0.9.2
Compiling const_fn v0.4.1 (/root/const_fn-master)
error: failed to run custom build command for const_fn v0.4.1 (/root/const_fn-master)
Caused by:
process didn't exit successfully: /root/const_fn-master/target/debug/build/const_fn-13eda46b8fb9e1dc/build-script-build (exit code: 101)
--- stdout
cargo:rustc-cfg=const_fn_has_build_script
--- stderr
thread 'main' panicked at 'unexpected output from rustc --version', build.rs:8:17
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /builddir/build/BUILD/rustc-1.45.2-src/vendor/backtrace/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /builddir/build/BUILD/rustc-1.45.2-src/vendor/backtrace/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1076
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1537
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:218
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:486
11: std::panicking::begin_panic
at /builddir/build/BUILD/rustc-1.45.2-src/src/libstd/panicking.rs:410
12: build_script_build::main
at ./build.rs:8
13: std::rt::lang_start::{{closure}}
at /builddir/build/BUILD/rustc-1.45.2-src/src/libstd/rt.rs:67
14: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:52
15: std::panicking::try::do_call
at src/libstd/panicking.rs:297
16: std::panicking::try
at src/libstd/panicking.rs:274
17: std::panic::catch_unwind
at src/libstd/panic.rs:394
18: std::rt::lang_start_internal
at src/libstd/rt.rs:51
19: std::rt::lang_start
at /builddir/build/BUILD/rustc-1.45.2-src/src/libstd/rt.rs:67
20: main
21: __libc_start_main
22:

Hmm, I'm not sure what is happening... I run CI on Rust 1.45.2 in #25 and it compiles successfully. Also it compiles successfully on my laptop.

thread 'main' panicked at 'unexpected output from rustc --version', build.rs:8:17

This error occurs only when version_check::triple() returns None:
https://github.com/taiki-e/const_fn/blob/edb58a40486592a4c66c8d2f01678e2d9ac99e2d/build.rs#L6-L9
https://github.com/taiki-e/const_fn/blob/edb58a40486592a4c66c8d2f01678e2d9ac99e2d/build.rs#L23-L25
So, this error may actually mean that version_check is failing to run rustc or to parse it. (I don't feel it's a bug in their parser because I've successfully parsed the same version in other environments.)

@APIPLM
I don't know the exact way to fix this, but there are possibilities that you can fix it in the following ways:

Remove build artifacts (i.e., run cargo clean)
Stop uses of compiler caching tool if you used (e.g., sccache) (https://github.com/SergioBenitez/version_check/issues/15)
Use later version of Rust (It may be a bug in an older version of rustc or cargo)

If you can't solve it other ways than by updating Rust, it might be useful for debugging if you can provide the following information:

Output of rustc --version.
Version of OS.
Whether it can be reproduced with other versions of Rust.

@taiki-e Thanks for your help. you are right. It is about Rustc and Cargo version. In my side, I have backup VM machine, which has the almost same version of CentOS( the original one having patch 3.10.0-1127.19.1 , the backup 3.10.0-1127.13.1) and GCC  same version which is (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) . In the backup machine, I reference to like install rust on archlinux( https://wiki.archlinux.org/index.php/Rust). In the original one. I just installed all packages by yum (like yum install Rust-x86-64, Rust-src, rust-std-static and so on). I was wondering why there are people put the old version in the repo for Centos. But the point is how yum and rpm work like what rustc cargo have for package manager. If something point is incorrect, point out, please.

@taiki-e  As go further to build time-main(version "0.2.16" https://github.com/time-rs/time). The below error come out. Seem like related to const_fn
Running rustc --crate-name time --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -Cembed-b itcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="deprecated"' --cfg 'feature="libc"' --cfg 'feature="std"' --cfg 'feature="stdweb"' --cfg 'feature="winapi "' -C metadata=61a653f1280f4071 -C extra-filename=-61a653f1280f4071 --out-dir /root/time-main/target/debug/deps -C incremental=/root/time-main/target/debug/incremental -L d ependency=/root/time-main/target/debug/deps --extern cfg_if=/root/time-main/target/debug/deps/libcfg_if-748f21f0c8637ed0.rmeta --extern const_fn=/root/time-main/target/debu g/deps/libconst_fn-c998fcebd195f88b.so --extern libc=/root/time-main/target/debug/deps/liblibc-3b067de2f719f3b2.rmeta --extern standback=/root/time-main/target/debug/deps/l ibstandback-6cba24141a007cb4.rmeta --extern time_macros=/root/time-main/target/debug/deps/libtime_macros-297d54a75eca283c.rmeta --cfg __time_02_supports_non_exhaustive --cf g __time_02_instant_checked_ops --cfg __time_02_nonzero_signed --cfg __time_02_use_trait_as_underscore
error: core::num::<impl i64>::checked_add is not yet stable as a const fn
--> src/duration.rs:622:36
|
622 |         let mut seconds = try_opt!(self.seconds.checked_add(rhs.seconds));
|                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: core::num::<impl i64>::checked_add is not yet stable as a const fn
--> src/duration.rs:627:32
|
627 |             seconds = try_opt!(seconds.checked_add(1));
|                                ^^^^^^^^^^^^^^^^^^^^^^
error: core::num::<impl i64>::checked_sub is not yet stable as a const fn
--> src/duration.rs:630:32
|
630 |             seconds = try_opt!(seconds.checked_sub(1));
|                                ^^^^^^^^^^^^^^^^^^^^^^
error: core::num::<impl i64>::checked_mul is not yet stable as a const fn
--> src/duration.rs:678:31
|
678 |             try_opt!(try_opt!(self.seconds.checked_mul(rhs as i64)).checked_add(extra_secs));
|                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: core::num::<impl i64>::checked_add is not yet stable as a const fn
--> src/duration.rs:678:22
|
678 |             try_opt!(try_opt!(self.seconds.checked_mul(rhs as i64)).checked_add(extra_secs));
|                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to 5 previous errors
error: could not compile time.

In the backup machine, I reference to like install rust on archlinux( https://wiki.archlinux.org/index.php/Rust). In the original one. I just installed all packages by yum (like yum install Rust-x86-64, Rust-src, rust-std-static and so on).

I think it's likely that the rustc or cargo provided by the vendor is a little broken.
I would suggest making sure rustup update 1.45.2 && cargo +1.45.2 build works well on the backup machine that installed rust by rustup.
If that succeeds, by uninstalling rust installed by yum once & reinstalling rust by rustup, then it should probably compile fine even with 1.45.2 on the original machine.

 I believe I already pushed up a newer commit that fixed it, but if not it's in my laptop.

@taiki-e  you are right. in backup one after rustup update 1.45.2 and set to it active channel.
it is still working. it is about installing toolchain(rustc, cargo and so on) by rustup. And also before running "cargo build", make sure it is clear, already removed its dependence version_check-0.9.2.crate in the folder /root/.cargo/registry/cache/github.com-1ecc6299db9ec823 and the src version_check-0.9.2.rs in the folder /root/.cargo/registry/src/github.com-1ecc6299db9ec823
in the original machine, uninstalled rust installed by yum and install rust 1.45.2 by rustup. then there is no issue as compiling the const_fn-master.  I was wondering what happened as installing 1.45.2 and yum install rust.x86_64. I think that we can close this issue.

@jhpratt Thanks, as I said that that issue might related to this crate when seeing the message like "error: core::num::::checked_add is not yet stable as a const fn". As running cargo build on rustc 1.45.2 and cargo 1.45.1, it work fine for time 0.2.16. But running cargo build on rustc 1.46.0 and cargo 1.46.0 (stable version) for times 0.2.16. there is the issue as I posted in the above. And also in the code level, I can see you that you mentioned that "This function is const fn when using rustc >= 1.46." and but it not like that.Same like as you said you might have not commit the latest code to repo ,but the comment in the source code already mentioned that.
@taiki-e if you have any comments. Feel freely to say. Thanks in advance.

As said in #26, I believe this issue is completely resolved so I'll close this.

(Marked as a (fixed) bug. It's likely that version_check failed to determine the version because the linux vendor added some extra strings to the version info, but we fixed them by improving the parser. I'll update the changelog of v0.4.2 to mention about this.)

@jhpratt you are right. that issue is not related this one.  As I checked out the latest time-rs(0.2.18),then built in the rustc 1.46.0, there is not the issue as I said in the above.


incorporate ftp://ftp.expasy.org/databases/enzyme

build ec collection, store cofactor info

done


Required files for SGDET_on_custom_images.ipynb

Hi @Maelic , first of all thank: you for sharing your precious work!
I am currently trying to run the Scene Graph generation  on custom images (i.e. SGDET_on_custom_images.ipynb) but I am struggling to understand where to find the correct files to put in the configuration, dictionary and weights paths. To be more clear, I am talking about the following lines of code in your notebook:
config_path = "../checkpoints/VG150/SGDET/penet-yolov8m/config.yml" dict_path = "../datasets/VG150/VG-SGG-dicts-with-attri.json" weights_path = "../checkpoints/VG150/SGDET/penet-yolov8m/best_model_epoch_2.pth"
Could you please help me providing further information and/or links to get the required files?

Hi @claudio-dg ,
I have just uploaded the model weights for penet-yolov8m on VG150 and two other datasets, please have a look in the MODEL_ZOO.
Just to let you know, you will probably have to modify the config.yml file which I uploaded with the weights as there might be some wrong paths. Don't hesitate to try other models as well!
Good luck!

Thank you for your feedback @Maelic, I really appreciate it!
I was trying to modify the config.yaml file and path_catalog.py as you suggested, but now I am stuck at this runtime error regarding the split mask. Would you be so kind to help me understanding how to solve it?
YOLOv8m summary: 295 layers, 25943170 parameters, 25943154 gradients, 79.5 GFLOPs
Split mask: [False False False ... False False False]
Traceback (most recent call last):
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/my_scripts/SGDET_on_cutom_images.py", line 73, in
model = SGG_Model(config_path, dict_path, weights_path, rel_conf=0.01, box_conf=0.1, show_fps=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/my_scripts/demo_model.py", line 61, in init
self.load_model()
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/my_scripts/demo_model.py", line 68, in load_model
self.model = build_detection_model(self.cfg)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/detector/detectors.py", line 11, in build_detection_model
return meta_arch(cfg)
^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/detector/generalized_yolo.py", line 28, in init
self.roi_heads = build_roi_heads(cfg, self.backbone.out_channels)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/roi_heads/roi_heads.py", line 69, in build_roi_heads
roi_heads.append(("relation", build_roi_relation_head(cfg, in_channels)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/roi_heads/relation_head/relation_head.py", line 117, in build_roi_relation_head
return ROIRelationHead(cfg, in_channels)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/roi_heads/relation_head/relation_head.py", line 40, in init
self.predictor = make_roi_relation_predictor(cfg, feat_dim)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/roi_heads/relation_head/roi_relation_predictors.py", line 9, in make_roi_relation_predictor
return func(cfg, in_channels)
^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/roi_heads/relation_head/predictors/default_predictors.py", line 773, in init
super().init(config, in_channels)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/modeling/roi_heads/relation_head/predictors/default_predictors.py", line 34, in init
self.statistics = get_dataset_statistics(self.cfg)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/data/build.py", line 54, in get_dataset_statistics
statistics.append(dataset.get_statistics())
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/data/datasets/visual_genome.py", line 130, in get_statistics
fg_matrix, bg_matrix, predicate_new_order, predicate_new_order_count, pred_prop, triplet_freq, pred_weight = get_VG_statistics(img_dir=self.img_dir, roidb_file=self.roidb_file, dict_file=self.dict_file,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/data/datasets/visual_genome.py", line 275, in get_VG_statistics
train_data = VGDataset(split='train', img_dir=img_dir, roidb_file=roidb_file,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/data/datasets/visual_genome.py", line 78, in init
self.filenames = [self.filenames[i] for i in np.where(self.split_mask)[0]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/claudiodelgaizo/Downloads/SGG-Benchmark-main/sgg_benchmark/data/datasets/visual_genome.py", line 78, in
self.filenames = [self.filenames[i] for i in np.where(self.split_mask)[0]]
~~~~~~~~~~~~~~^^^
IndexError: list index out of range

Did you download the Visual Genome dataset? It is still required to download the dataset, even for inference. I will remove this requirement when I have time. Meanwhile, you can download the images and data file following the DATASET.md

I did but I couldn't unzip it properly into one single folder, I managed to do it now and solved that, thanks again! I hope not to bother you again XD

No worries, I know the codebase is not very friendly for out-of-the-box inference on custom images, but as I said I have a strictly limited amount of time to work on that right now :)
If it's working now, I'm closing the issue.


Support multiple arguments in --options string

Fixes #293.

3.9 failed but the error looks like a blip, re-running

Thanks for the PR!


Add unit test for FrameworkStatusReporter

What is the purpose of the change

Add unit test for FrameworkStatusReporter
Extract constants
Fix typo

Codecov Report

Merging #8653 (b2aec1c) into 3.0 (17ba017) will increase coverage by 0.21%.
The diff coverage is 90.90%.

:exclamation: Current head b2aec1c differs from pull request most recent head 470018c. Consider uploading reports for the commit 470018c to get more accurate results

@@             Coverage Diff              @@
##                3.0    #8653      +/-   ##
============================================
+ Coverage     62.94%   63.15%   +0.21%
+ Complexity      313      311       -2
============================================
  Files          1117     1121       +4
  Lines         46811    46869      +58
  Branches       7046     7032      -14
============================================
+ Hits          29465    29601     +136
+ Misses        14057    13972      -85
- Partials       3289     3296       +7

Impacted Files
Coverage Δ

...bo/registry/client/migration/MigrationInvoker.java
59.16% <85.71%> (+0.76%)
:arrow_up:

...t/migration/DefaultMigrationAddressComparator.java
78.04% <100.00%> (ø)

.../dubbo/registry/integration/RegistryDirectory.java
47.17% <100.00%> (ø)

...ache/dubbo/rpc/protocol/tri/TransportObserver.java
0.00% <0.00%> (-87.50%)
:arrow_down:

...che/dubbo/metadata/AbstractServiceNameMapping.java
35.13% <0.00%> (-29.73%)
:arrow_down:

...ng/transport/dispatcher/all/AllChannelHandler.java
62.06% <0.00%> (-20.69%)
:arrow_down:

...ng/transport/dispatcher/WrappedChannelHandler.java
43.47% <0.00%> (-15.22%)
:arrow_down:

...he/dubbo/common/config/CompositeConfiguration.java
46.42% <0.00%> (-14.29%)
:arrow_down:

...dubbo/common/status/support/LoadStatusChecker.java
50.00% <0.00%> (-11.54%)
:arrow_down:

...mmon/threadpool/support/fixed/FixedThreadPool.java
80.00% <0.00%> (-7.50%)
:arrow_down:

... and 103 more

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 17ba017...470018c. Read the comment docs.


Result are inconsistent with SearchUrlCommand(s)

In this case, Google prefixPreview seems to work correctly:

In this case, DuckDuckGo should be the first result. It seems the prefixPreview's result got lost:

This is definitely a bug. I'll need to investigate.
Also almost no work has gone into making accurate scores. That needs to be addressed eventually. But I think that might be unrelated to this.

This is now fixed.
The cause was that in application.conf commandNames was set to ["ddg" "duckduckgo"] instead of ["ddg", "duckduckgo"]. Apparently HOCON doesn't work like Clojure. 😛
But I'm a little surprised ["ddg" "duckduckgo"] get's intepreted as List("ddg duckduckgo"). I'm not sure if that's a bug or part of the HOCON specification. I'd rather it have fail...


Add script generating DTS overlay for Zephyr

This PR introduces a new script that generates overlay DTS for Zephyr from the LiteX configuration csv file.

Actually, should this be in https://github.com/litex-hub/litex-devicetree instead?


Removing properties from entities is too complicated

AFAIK, the easiest way to delete a property by name from an entity is this one:
entity.setProperties(entity.getProperties().remove("property_name"));

I don't like that we have to work with JsonNodes to delete properties, maybe adding a very simple
void removeProperty(String key)

would be nicer? I think we would only need to add this to the AbstractEntity class.

Turns out I was kinda wrong, you can just do:
entity.getProperties().remove(property);

I still don't really like it, but not enough to fix it

For documentation: There is now removeProperty(...) and removeProperties(...) as a shortcut.


Install script contains adware

calling npm install has a postinstall adware script which outputs the following text:
Thanks for installing styled-components 🙏
                 Please consider donating to our open collective
                        to help us maintain this package.

                           Number of contributors: 186
                              Number of backers: 22
                             Annual budget: US$ 1,269
                             Current balance: US$ 687

     👉  Donate: https://opencollective.com/styled-components/donate

the adware script which injects the ad above should probably be removed.
It's understandable that you guys need money, but even if yours was the most important package in the folder this still would be unacceptable.
Can you imagine what it would be like if everyone did what you are doing here?  An entire console filled with advertisements?
Please, recognize the golden rule, act as you wish others to act, and remove this adware.

Oh, I'm personally totally following the golden rule: I'd love to see everybody in open source make money! I'd love to see more ads in my terminal of developers trying to make a living doing what they love :100: (not an official opinion of the project)

Duplicate of https://github.com/styled-components/styled-components/issues/1590
Btw you can also call it the open-collective hook and not adware, as it has a name :wink:
Anyway, we discussed this before and would be totally happy to shorten this to a brief message with a link to our opencollective or removing it altogether.
cc @probablyup

In favor of making it shorter like nodemon!


Spaces in Contact Phone Number are breaking search filter

Finding a contact by phoneNumbers will not return the contact unless filter string is identical to contact phone number:
Example: filter: '049999111' will return contact with phone number '0499991111'
however
Example: filter: '049999111' will not return contact with phone number '04 9999 1111'
Example: filter: '04 9999 111' will not return contact with phone number '0499991111'
Example: filter: '9111' will return contact with phone number '0499991111'
however
Example: filter: '9111' will not return contact with phone number '04 9999 1111'
Since the phone number is unknown what format it will be in, the spacing should be disregarded
Cordova 7.1.0
Cordova iOS 4.5.5
iOS 12.1 iPhone X

Temporarily I have transformed my filter searches to be in the format of "123 123 123" to fix the spaces interfering with my search's

We are archiving this repository following Apache Cordova's Deprecation Policy. We will not continue to work on this repository. Therefore all issues and pull requests are being closed. Thanks for your contribution.


SAM Decompresses Java ZIP at every Invocation (can't hot start)

I am testing locally a Java Lambda + API Gateway instance. At every invocation SAM decompresses de ZIP package and mounts it into a Docker image, which makes testing VERY slow, since every small query string change will trigger the whole process.
Can't the Docker image be cached, and only be recreated once the ZIP package's File Modification time changes? Or maybe just compute a fast Hash (e.g. CRC32) to check if the ZIP changed at all.
It feels like every HTTP request will trigger a cold start.

@feinstein You can point the CodeUri to a directory with the source files instead of zipping. Is that an option for you?

It's still slow, it doesn't have to decompress anymore, but it still needs to fetch and mount the image at every HTTP Request.

@jfuss related to this: can we keep the SAM Local instance running as if it was a hot lambda instance?
I am asking this because it's very annoying to test this with IntelliJ IDEA, for each HTTP Request I do, I have to send the Request, click the Debug button, wait for it all to connect and hit a breakpoint (it does take a while) and then after the Response is returned the debugger disconnects and I have to do it all over again. It would be a much better experience if the debugger could remain connected to the container and keep getting invocations from HTTP Requests automatically.

@feinstein That is expected and is by design currently. A single invoke will create the container (and therefore mount), execute, and then remove the container. This allows the CLI to reload changes to the function code without having to kill and restart the command and keeps the commands stateless. We understand that this is a sharper edge of the CLI and that these interactions can be improved but right now this is the experience.
You can follow along at #239, which is an issue about the warm start experience.
Closing this as a duplicate of #239 but happy to re-open if there is something not covered.

I see, well, this is unfortunate, I was moving to SAM Local so I could make my builds simpler and easier to iterate/test... But this is way slower than what I had. Thanks for the support!

@feinstein Understood. The team is very aware of this issue and pain point. We are looking at ways to make this better but don't have anything to share at the moment.

@jfuss can you provide an example for

@feinstein You can point the CodeUri to a directory with the source files instead of zipping. Is that an option for you?

This works but decompresses every time: CodeUri: ./target/aws-logs-metricfilter-handler-1.0-SNAPSHOT.jar
This doesn't work: CodeUri: ./src/main/java
START RequestId: 5654a685-d974-10c1-9f8a-84ec89677cd8 Version: $LATEST java.lang.ClassNotFoundException: software.amazon.logs.loggroup.HandlerWrapper


KAFKA-14406: Fix double iteration of restoring records

While restoring a batch of records, RocksDBStore was iterating the ConsumerRecords, building a list of KeyValues, and then iterating that list of KeyValues to add them to the RocksDB batch.
Simply adding the key and value directly to the RocksDB batch prevents this unnecessary second iteration, and the creation of itermediate KeyValue objects, improving the performance of state restoration, and reducing unnecessary object allocation.
This also simplifies the API of RocksDBAccessor, as prepareBatchForRestore is no longer needed.

I think this might need a ticket. If you don't mind creating one. It would be good to track this to see when we get the fix in and what branches it's on

test failures are unrelated, merging to trunk

@ableegoldman Thanks. My JIRA username is nicktelford.


[Doc] Add variables to variable table for schedule.

'last_executed_session_time' and 'last_executed_session_unixtime' are added to the table.

@muga Could you review this PR. I would like to add 'last_executed_session_unixtime' to list of pre-defined variables.

@muga Thank you for your pointing out. I revert package-lock.json.

Merged


2 issues on macOS Big Sur

Looks a great app! I noticed two issues on Big Sur:

Unhandled Promise Rejection Error: ZIP file not provided: [  ... ] on every app launch.
The app blanks out when I delete a snippet and needs to be reloaded. Is this intentional? Also Command + Del does not work to delete a snippet, but right click > Delete does.

But the app itself processes the code and outputs results just fine. Thanks!

for "Command + Del does not work to delete a snippet", I have not implemented it, it only supports right-click to delete snippet.
and I think the latest version would fix the other things you noticed.
thanks for like it.


Tabs drop down does not always close

Detailed description

Describe in detail the issue you're having.
After getting a fix for Issue #659, Still unable to close the dropdown when we focus out on our page.

Is this a feature request (new component, new icon), a bug, or a general issue?
bug

Is this issue related to a specific component?
Tabs in 'sm' breakpoint.

What did you expect to happen? What happened instead? What would you like to see changed?
I expect to focus out and the dropdown to close.

What browser are you working in?
Chrome

What version of the Carbon Design System are you using?
v10.4
carbon-angular - 3.13.2

What offering/product do you work on? Any pressing ship or release dates we should be aware of?
IWR

Will add sandbox if possible.
More Details
I've debugged this a bit more. Based upon the change from Issue #659 I see :
@HostListener("focusout", ["$event"])
focusOut(event) {
if (this.tabListVisible && event.relatedTarget === null) {
this.tabListVisible = false;
}
}
Upon debugging, I noticed that "event.relatedTarget" is not null. I'm not sure why. Our page does have content around the tab. When I debug the evet the "relatedTarget" is a div sometimes.

Here is sandbox that shows the issues:
https://stackblitz.com/edit/carbon-angular-tabs-pthu4k


Add support for OpenAI's o1-preview and o1-mini models

What problem or use case are you trying to solve?
OpenAI's new models o1-preview and o1-mini expose a slightly different API than previous models. Thus, changes need to be made to OpenHand's codebase in order to support these new models.
Describe the UX of the solution you'd like
The UX stays the same. However, according to OpenAI, these new models introduce a new paradigm of interaction. They now have a built-in chain-of-thought process that might require us to redesign the way the model is prompted.
Do you have thoughts on the technical implementation?
Through a trial-and-error process I identified at least five differences with the new API:

"system" is no longer supported as a valid option for role
max_tokens changed to max_completion_tokens
temperature only supports the value 1 (this doesn't make sense to me, maybe with this new paradigm the temperature concept is no longer required?)
top_p only supports the value 1
stop is no longer supported

Note: These are just my empirical observations. There's still no mention of these new models on OpenAI's official documentation for chat. Actually, I think this "issue" should be formally addressed only after the official docs are available and there's more information about the new prompting paradigm for these models.

Thanks for bringing that up! Fortunately litellm was also busy already in the meantime and added some extra support, but I haven't yet tried out, what on our end is needed on top.

My guess is it should mostly just work! Might make sense to expose some new options though, e.g. via env vars

litellm/llms/OpenAI/o1_reasoning.py
They do translate parameters, but may need drop_params to be set in OH to prevent errors.

I tested via openrouter.
It sets up but when I ask OpenHands to do something it anwser to me this :
Agent encountered an error while processing the last action. Error: NotFoundError: litellm.NotFoundError: NotFoundError: OpenrouterException - 404 page not found Please try again.

What version do you use, @Volko61 ? It's brand new, it works in the latest development version.

I just figured out that I have this issue on other openrouter models,
I'm reinstalling docker desktop and openhand to try again
I'm on windows

What version do you use, @Volko61 ? It's brand new, it works in the latest development version.

I still get the issue :
Hi! I'm OpenHands, an AI Software Engineer. What would you like to build with me today?
Create a tetris game in python
Agent encountered an error while processing the last action.
Error: APIError: litellm.APIError: APIError: OpenrouterException - Connection error.
Please try again.
Do you have any idea why ?
(I'm on 0.9 btw, I just copy paste the get started command in WSL)

Here are the logs
20:10:47 - openhands:INFO: agent_controller.py:150 - [Agent Controller 62aacc1a-5603-4adc-8091-47bc096814dc] Starting step loop...
20:10:47 - openhands:INFO: session.py:139 - Server event
20:10:47 - openhands:INFO: runtime.py:270 -
-----------------------------------Container logs:-----------------------------------
|INFO:     <IP_ADDRESS>:42986 - "GET /alive HTTP/1.1" 200 OK
20:10:47 - openhands:INFO: runtime.py:375 - Awaiting session
20:10:47 - openhands:INFO: runtime.py:270 -
-----------------------------------Container logs:-----------------------------------
|INFO:     <IP_ADDRESS>:42986 - "GET /alive HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:43112 - "GET /api/list-files HTTP/1.1" 200 OK
20:11:04 - USER_ACTION
MessageAction (source=EventSource.USER)
CONTENT: Create a tetris game in python
20:11:04 - openhands:INFO: session.py:139 - Server event
20:11:04 - openhands:INFO: runtime.py:270 -
-----------------------------------Container logs:-----------------------------------
|INFO:     <IP_ADDRESS>:42986 - "POST /list_files HTTP/1.1" 200 OK
|INFO:     <IP_ADDRESS>:42986 - "GET /alive HTTP/1.1" 200 OK
|INFO:     <IP_ADDRESS>:42986 - "POST /execute_action HTTP/1.1" 200 OK
20:11:04 - openhands:INFO: runtime.py:375 - Awaiting session
20:11:04 - openhands:INFO: runtime.py:270 -
-----------------------------------Container logs:-----------------------------------
|INFO:     <IP_ADDRESS>:53266 - "GET /alive HTTP/1.1" 200 OK
|INFO:     <IP_ADDRESS>:53266 - "POST /list_files HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:48538 - "GET /api/list-files HTTP/1.1" 200 OK
==============
CodeActAgent LEVEL 0 LOCAL STEP 0 GLOBAL STEP 0
Give Feedback / Get Help: https://github.com/BerriAI/litellm/issues/new
LiteLLM.Info: If you need to debug this error, use `litellm.set_verbose=True'.
20:11:07 - openhands:ERROR: codeact_agent.py:214 - litellm.APIError: APIError: OpenrouterException - Connection error.
20:11:07 - ACTION
AgentFinishAction(outputs={}, thought='Agent encountered an error while processing the last action.\nError: APIError: litellm.APIError: APIError: OpenrouterException - Connection error.\nPlease try again.', action='finish')
20:11:07 - openhands:INFO: session.py:139 - Server event
20:11:07 - openhands:INFO: session.py:139 - Server event
20:11:07 - openhands:INFO: runtime.py:270 -
-----------------------------------Container logs:-----------------------------------
|INFO:     <IP_ADDRESS>:53266 - "GET /alive HTTP/1.1" 200 OK
|INFO:     <IP_ADDRESS>:53266 - "POST /execute_action HTTP/1.1" 200 OK
20:11:07 - openhands:INFO: runtime.py:375 - Awaiting session
20:11:07 - openhands:INFO: runtime.py:270 -
-----------------------------------Container logs:-----------------------------------
|INFO:     <IP_ADDRESS>:53266 - "GET /alive HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:48538 - "GET /api/list-files HTTP/1.1" 200 OK

What have you set up in the configuration screen (cog wheel bottom right)?

What have you set up in the UI's configuration screen (cog wheel bottom right)?

I tested with openrouter with o1, claude3.5 and I also tested with llama3.1 8B with groq

Something is strange is that when I open it it shows the advanced tab. But even if I go to the non advanced tab and save it does not work and when I reopen the settings, it reopens in advanced tab

If you're using the docker command to start OH, please try ghcr.io/all-hands-ai/openhands:0.9.3 where it says 0.9 or "main" instead of "0.9.3" to get the most current version (and images) and keep us posted if the situation changes.

If you're using the docker command to start OH, please try ghcr.io/all-hands-ai/openhands:0.9.3 where it says 0.9 or "main" instead of "0.9.3" to get the most current version (and images) and keep us posted if the situation changes.

@tobitege
I tried with 0.9.3 and got the same issue

If you're using the docker command to start OH, please try ghcr.io/all-hands-ai/openhands:0.9.3 where it says 0.9 or "main" instead of "0.9.3" to get the most current version (and images) and keep us posted if the situation changes.

@tobitege I tried with 0.9.3 and got the same issue

Sorry, forgot to explicitly mention to also remove all OH images you may see in your docker desktop first.

It works!
I had no problem with this setting. I'll update the interface to include it in the default slider.

If you're using the docker command to start OH, please try ghcr.io/all-hands-ai/openhands:0.9.3 where it says 0.9 or "main" instead of "0.9.3" to get the most current version (and images) and keep us posted if the situation changes.

@tobitege I tried with 0.9.3 and got the same issue

Sorry, forgot to explicitly mention to also remove all OH images you may see in your docker desktop first.

@tobitege I've removed all OH images before testing again and same issue

@amanape
I think "Base URL" should be the top, then the Model, then the API key, this sounds very good "logically", thx!

My issue just solved him self with :


Fix JPH_MassProperties_ScaleToMass;

It calculated the right answer, but didn't do anything with it

Thanks!


Fix form elements resolution

May resolve #29 :)
Original results:
 $ phantomjs ./renderer/resource/render.js https://www.buglloc.com/static/gryffin/forms-unencoded-fields.html | head -1 | python -mjson.tool

{
    "response": {
        "headers": {...},
        "contentType": "text/html; charset=utf-8",
        "status": 200,
        "url": "https://www.buglloc.com/static/gryffin/forms-unencoded-fields.html",
        "body": "\nfoo\n<form name=\"with-query\" action=\"/\" method=\"post\">\n\t<input type=\"text\" name=\"foo[]\" value=\"some\">\n\t<select name=\"bar[]\">\n\t\t<option value=\"one\">One</option>\n\t\t<option value=\"two\">Two</option>\n\t</select>\n\t<input type=\"submit\" name=\"save\" value=\"Save\">\n</form>\n\n\n",
        "details": {
            "links": [],
            "forms": []
        }
    },
    "elasped": 586,
    "ok": 1,
    "msgType": "domSteady",
    "signature": "==lXlKfYWch7H9VdJgPCmJ=="
}

After apply this PR:
 $ phantomjs ./renderer/resource/render.js https://www.buglloc.com/static/gryffin/forms-unencoded-fields.html | head -1 | python -mjson.tool
{
    "response": {
        "headers": {...},
        "contentType": "text/html; charset=utf-8",
        "status": 200,
        "url": "https://www.buglloc.com/static/gryffin/forms-unencoded-fields.html",
        "body": "\nfoo\n<form name=\"with-query\" action=\"/\" method=\"post\">\n\t<input type=\"text\" name=\"foo[]\" value=\"some\">\n\t<select name=\"bar[]\">\n\t\t<option value=\"one\">One</option>\n\t\t<option value=\"two\">Two</option>\n\t</select>\n\t<input type=\"submit\" name=\"save\" value=\"Save\">\n</form>\n\n\n",
        "details": {
            "links": [
                {
                    "text": "foo",
                    "url": "https://www.buglloc.com/foo"
                }
            ],
            "forms": [
                {
                    "data": "bar%5B%5D=one&foo%5B%5D=some&save=Save",
                    "dataType": {
                        "bar%5B%5D": "select-one",
                        "foo%5B%5D": "text",
                        "save": "submit"
                    },
                    "method": "post",
                    "url": "https://www.buglloc.com/"
                },
                {
                    "data": "bar%5B%5D=two&foo%5B%5D=some&save=Save",
                    "dataType": null,
                    "method": "post",
                    "url": "https://www.buglloc.com/"
                }
            ],
            "jsLinkFeedback": true
        }
    },
    "elasped": 580,
    "ok": 1,
    "msgType": "domSteady",
    "signature": "==lXlKfYWch7H9VdJgPCmJ=="
}

Thanks for the bug hunting. But unfortunately this is NOT a good fix.
Can you please replace f[name] with f[input.name] instead of input? and check if it can fundamentally solve your problem?
Main reason of your issue is because name (i.e., bar%5B%5D) is an URI encoded version of input.name (i.e., bar[]), as in
https://github.com/yahoo/gryffin/pull/30/files#diff-00c99a77228efa95757ceb327151661dR312 . This makes the form f[name] fails to get an array of same named elements.
Thanks! (or leave it for me to send a PR may be next week) :)

CLA is valid!

Can you explain why the use of input in this case is wrong?
Funny, but at first I did exactly as you mentioned (use f[input.name] instead input). But then I can't understand the reasons for not using input and submit PR with input :)
I understand the reason of my issue, otherwise I would not make any patches.

Can you please replace f[name] with f[input.name] instead of input? and check if it can fundamentally solve your problem?

Sure! I previously checked both version with f[input.name] and input.

Given the following use case:
<form><input name=a type=radio value=M><input name=a type=radio value=F></form>

f[input.name] returns two input elements
input will return the element being iterated

Oh, i see. I was wrong, thanks!

No problem. Really thanks for hunting the bug. :+1:

and I see another potential bug. it looks like you have a not-so-standard element like <select type="select-one"> inside your form, which I didn't expect elements like select and textarea would have a type attribute. that makes dataType to see 'select-one' instead of 'select'. this won't kill gryffin for now, as it's not being really used I believe. better to separately set the type if those three if-else branches.


The device doesnt work for my tracks

The idea is great i love it! But i can´t get it to work for my ableton live session. I got it customized for your own session and i get the same tracks you have in your proyect instead of the ones in mine. Also it would be great if you could change the view grid so you could see more of the song. Great work keep it up!

Same issue here. And as it seems like one cam make a wish here... I wish the tool would be positioned between devices and clips, sitting nicely integrated rather than floating. ++ Great work

Hi guys! I will come back to this! I don't think I will add the option without the floating window, as that usually gets too small to see the track info and beat match. The floating window is resizable and remembers where you positioned it, so you can of "cheat" integrate it.
All best :D


robots.txt disallows everything despite "Environment: production"

I wanted to add robots.txt to my site so I added
enableRobotsTXT: true

to my config.yaml. That didn't turn out as expected. It got the following content:
User-agent: *
# robotstxt.org - if ENV production variable is false robots will be disallowed.

  Disallow: /

On the web server I render my site using just hugo. On my workstation I tried with hugo server --environment=production but got the same result. The command wrote the environment as I specified it however:
$ hugo server --environment=production
...
Environment: "production"
Serving pages from memory
...

I'm running Hugo 0.57.2.
After some digging I found that layouts/robots.txt in this git is looking for the environment variable HUGO_ENV or the configuration variable params.env (Site.Params.env).
My conclusion is that the Ananke theme got environment support before Hugo did and when Hugo added it in version 0.53 it was in a slightly different way. Running hugo server will set the environment to development and running hugo will set it to production. It can be overridden by OS environment variable HUGO_ENVIRONMENT(note, not HUGO_ENV!) or by using the --environment option.
My opinion is that the Ananke theme shall support the official way of specifying environment.

HUGO_ENV is what we use on all of our production sites and it works fine.
I agree though that we should change params.env to Hugo's newer environment setting (though, truth is, we only use HUGO_ENV at work and I'm not sure of the value of the second setting (someone else added it to the theme).

Which version of Hugo are you using? I just upgraded to 0.57.2 and when I set HUGO_ENV it's not used. Look at the Environment: line:
$ HUGO_ENV=production hugo server
Building sites … WARN 2019/08/21 23:55:49 Page's .Hugo is deprecated and will be removed in a future release. Use the global hugo function.
WARN 2019/08/21 23:55:49 Page's .RSSLink is deprecated and will be removed in a future release. Use the Output Format's link, e.g. something like:
    {{ with .OutputFormats.Get "RSS" }}{{ .RelPermalink }}{{ end }}.
WARN 2019/08/21 23:55:49 Page's .URL is deprecated and will be removed in a future release. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url.

                   | EN
+------------------+----+
  Pages            | 23
  Paginator pages  |  0
  Non-page files   | 37
  Static files     |  5
  Processed images |  0
  Aliases          |  1
  Sitemaps         |  1
  Cleaned          |  0

Total in 515 ms
Watching for changes in /home/user/git/labanskoller.se/{archetypes,content,data,layouts,static,themes}
Watching for config changes in /home/user/git/labanskoller.se/config.yaml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address <IP_ADDRESS>)
Press Ctrl+C to stop

Using HUGO_ENVIRONMENT however works:
 HUGO_ENVIRONMENT=production hugo server
Building sites … WARN 2019/08/21 23:56:55 Page's .Hugo is deprecated and will be removed in a future release. Use the global hugo function.
WARN 2019/08/21 23:56:55 Page's .RSSLink is deprecated and will be removed in a future release. Use the Output Format's link, e.g. something like:
    {{ with .OutputFormats.Get "RSS" }}{{ .RelPermalink }}{{ end }}.
WARN 2019/08/21 23:56:55 Page's .URL is deprecated and will be removed in a future release. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url.

                   | EN
+------------------+----+
  Pages            | 23
  Paginator pages  |  0
  Non-page files   | 37
  Static files     |  5
  Processed images |  0
  Aliases          |  1
  Sitemaps         |  1
  Cleaned          |  0

Total in 521 ms
Watching for changes in /home/user/git/labanskoller.se/{archetypes,content,data,layouts,static,themes}
Watching for config changes in /home/user/git/labanskoller.se/config.yaml
Environment: "production"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address <IP_ADDRESS>)
Press Ctrl+C to stop

I already made a proposal before I read your comment. I'll link a pull request we can discuss.

Also, please see this message by Bjørn Erik Pedersen about the official support: https://discourse.gohugo.io/t/how-to-serve-different-files-depending-on-environment/16212/2

HUGO_ENV is for the server, not for Hugo, but Hugo can use it HUGO_ENV=production hugo serve and that works fine. Where you have Environment: "development" in your build log is Hugo's environment.
As this would be a breaking change for some, we'd have to be careful about changing the other value. Perhaps add it as an additional conditional at first with a warning (we don't really have that for themes though) and swap it outright later.

I'm not sure I follow what you mean by "server". Do you refer to the server which hosts your site (so a physical server or a VM) and that HUGO_ENV is just an environment variable you chose to set on that server so it could be used in the Ananke theme? Or do you refer to Hugo's built-in web server started by hugo server?
If the latter I don't see any difference between running hugo to template files to the filesystem or hugo server to start a web server when it comes to the handling of HUGO_ENV and HUGO_ENVIRONMENT. hugo server is nice enough to tell me which environment is being used so it's easy to check. To test how hugo behaves I changed robots.txt to use hugo.Environment instead as suggested by my pull request.
Since production is the default environment when running just hugo I tried to change it the other way: to development. Running HUGO_ENV=development hugo rendered robots.txt as   Disallow: which is the production configuration but running HUGO_ENVIRONMENT=development hugo successfully changed the environment and robots.txt was rendered as   Disallow: /.
I agree that it's wise to be careful and backwards compatible. Do you think it's OK to skip the support for Site.Params.env? I've not seen that anywhere else but I'm new to Hugo and don't know the history.

Do you think it's OK to skip the support for Site.Params.env?

Sorry, I think you answered that question already in your first comment:

I agree though that we should change params.env to Hugo's newer environment setting

Yes, HUGO_ENV is often used as a setting in deployment. That should not change here. The other value that is now a Param should change to Hugo's env.

I've added a new commit (03aad29541f74c53dc5df35db29d13888f93b32e) to the pull request. I now try to support both ways. When deciding what CSS classes to add to <body> however I feel I need to choose only one way, and I hope you agree that the future is to use Hugo's built-in environment support so I chose that over HUGO_ENV. Tell me if you can't accept that. I don't know to what extent those CSS classes are used in the field. Please see the second paragraph in the commit message:
   Continue supporting HUGO_ENV

    Revert some of the changes done in
    a7324c5f15effe5d2b78992fc7b829b29152a7f9. Continue supporting the
    environment variable "HUGO_ENV" which doesn't affect Hugo while still
    supporting the new, official ways of setting the environment.

    <body> will however get a class named by the official environment only
    since it would be confusing to add both a "development" class and a
    "production" class at the same time if the site is rendered using this
    command for instance:

      $ HUGO_ENV=production hugo server

    <body> will however get a class named by the official environment only
    since it would be confusing to add both a "development" class and a
    "production" class at the same time if the site is rendered using this
    command for instance:

      $ HUGO_ENV=production hugo server

I would think the code to check production could be changed to
{{ if hugo.IsProduction }}

I use this on my site, which I have just started. I use this because I am using a github workflow to deploy. Its not convenient to pass HUGO_ENV to the hugo command and the template ignore the -e option.

About robots.txt, I was surprised by the fact that HUGO_ENV production produced
User-agent: *
Disallow:

instead of what seems to be expected for indexing to occur
User-agent: *
Allow: /

Sitemap: http://www.example.com/sitemap.xml

Is there a reason?

We are still in the hugo.Environment using production as a default problem... This makes any attempt to use hugo.Environment variable very risky.

HUGO_ENVIRONMENT env variable is not respected, only outdated HUGO_ENV is.


Enable JMC flag for Visual Studio

Just my code (JMC) is a helpful VS compiler flag that enables a debugging feature to automatically step over calls to system, framework, and other non-user code.
see https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2022#BKMK_C___Just_My_Code

Don't mean to be nosey :), but seems like this should be a build option. I've read this can have adverse affects on exception handling from dependent libraries.

@ashwinbhat @kwokcb Since I don't set this flag in my own Visual Studio environment, I'm open to ideas on how it would best be handled in MaterialX.  A build flag would be the most flexible, especially if there are tradeoffs involved in enabling it.

Based on the documentation and checking with the internal team, I don't see any impact on behavior.
This can be enabled via commandline using -DCMAKE_VS_JUST_MY_CODE_DEBUGGING=ON so no need to add it to CMake setting. I'll close this PR


feat: adding hash to fee transaction schema

I've preferred to call dataUpdateHash to be more descriptive. I feel that only hash is not detailed enough so users can understand that it refers to the dataUpdateHash


feat/add-kelly-strategy

This pull request adds a new trading strategy "kelly_criterion" to the trader and adds the parameter TRADING_STRATEGY that contains the trading strategy in use. The favoured type of strategy can be set as an enviconment variable. The current trading strategy "bet_amount_per_conf_threshold" is still the default when starting the trader. The new trading strategy is the Kelly Criterion and it is explained here.
Note: For utilizing the strategy in an effective way, the parameter SAMPLE_BETS_CLOSING_DAYS has also been added and can be set as an environment variable. It determines the amount of days until markets' closing times and makes the trader only bet on those markets that close wihtin SAMPLE_BETS_CLOSING_DAYS amount of days. Small values for this parameter ensure that wins can be redeemed within short periods of time and can also be reinvested earlier. As the Kelly Criterion places bets based on the amount of tokens that are available to bet, this leads to a steeper profit curve. It is also useful to gather trading data within short timeframes and make adjustments to the trader.
Introduction
The Kelly Criterion is the calculation rule for the Kelly fraction $f^*$, which is the portion of the gambling capital to be wagered in order to maximize the profit considering the payoff odds and the probability of winning. The calculation rule is given by
$$
f^* = \frac{bp - (1 - p)}{b},
$$
where $f^*$ is the Kelly fraction of the bankroll, which is the maximum available gambling capital, $b$ is the net odds received on the wager (bet amount excluded), $p$ is the probability of winning, and $(1-p)$ is the probability of losing (Beygelzimer et. al., 2012).
In traditional betting frameworks, the odds for a bet are usually fixed when placing a bet and stay the same regardless of the betting amount. The Kelly Criterion was originally designed for static odds and faces some challenges when being used in scenarios with dynamic odds. In prediction markets run by Constant Product Market Makers (CPMMs) the odds depend on the bet amount. As the Kelly Criterion calculates the optimal bet amount based on the odds, there exist an interdependence of bet amount and odds. The following sections provide a way to calculate the optimal absolute Kelly bet amount depending on the Bankroll and number of outcome tokens for each outcome before placing the bet. The here derived function only applies for prediction markets run by CPMMs with binary outcomes.
Kelly equation with dynamic odds
General Equation
The Kelly formula can be converted into
$$
f^* = \frac{Q \cdot p - 1}{Q - 1},
$$
where $Q$ is the gross payoff odds, i.e., in the event of a win, $Q$ times the amount wagered $( Q > 1 )$ will be received, including the initial investment.
As the Kelly formula calculates the fraction $f^*$ of the bankroll $B$ (Maximum available gambling capital) to bet it can be written as
$$
f^*=\frac{X}{B},
$$
where $X$ is the absolute Kelly bet amount. Setting both equations equal to each other results in
$$
\frac{X}{B} = \frac{Q \cdot p - 1}{Q - 1}
$$
Odds Function
The odds $Q$ for a bet in a prediction market run by a CPMM are calculated as
$$
Q=\frac{n_r}{X},
$$
where $n_r$ is the number of the selected outcome token received from placing a bet X, if the market closes with the answer selected outcome.
To calculate the number of received tokens $n_r$, the general bet placement algorithm of a CPMM prediction market needs to be understood: When a user submits a bet placement transaction to a prediction market with binary outcomes, this transaction includes among other parameters the investment amount $X$ and the vote for the selected asset class. In the following explanations we denote asset class $A$ as the asset class of the selected outcome. CPMMs are designed to always keep the product of their asset amounts $R_A$ and $R_B$ constant when a trade is done. With this condition a trading function for binary CPMM prediction markets can be defined as:
$$
φ(R) = R_A \cdot R_B.
$$
As $A$ and $B$ are the only two asset classes that the Market contains, Asset $A$ cannot simply be traded with a token that is not contained within the market. This would reduce $R_A$ while leaving $R_B$ untouched and violate the constant product rule. Therefore, a purchase is done in two steps. First, tokens of each asset class are purchased proportional to the current reserves represented by their weights, ensuring that the asset prices do not change (Angeris et. al., 2021). Next the purchased tokens of the not voted asset class are swapped to tokens of the voted asset class. So the total number of received tokens is
$$
n_r = n_A + n_{swap},
$$
where $n_A$ represents the number of $A$ tokens purchased from step 1 and $n_{swap}$ is the number of $A$ tokens received from trading the in step 1 purchased $B$ tokens $n_B$ to $A$ tokens.
Step 1: Proportional asset purchase
In the first step the bet amount is split by the number of asset classes $N=2$ in the market and tokens $n_i$ of each asset class are minted proportionally to the current reserves. It is important to understand that this operation does not reduce the number of asset in the market, but it creates new tokens in return for the investment amount that was sent along with the bet placement transaction. The number of tokens minted can be calculated as
$$
n_i = \frac{X}{Np_i}.
$$
$p_i$ is the reported price of one token of asset class $i$ in terms of the numeraire, which is the collateral token (e.g. xDAI) that the market uses to provide and remove liquidity (e.g. xDAI). The reported prices are their unscaled prices $P_i$ relative to the unscaled price of the numeraire $P_n$.
$$
p_i = \frac{P_i}{P_n}
$$
Given the trading function $φ(R) = R_A \cdot R_B$ their gradient
$$
P=∇φ(R)
$$
is denoted as the vector of unscaled prices (Angeris et. al., 2021). This results in the unscaled prices $P_A=R_B$ and $P_B=R_A$.
If we want to calculate the amount of assets that we get from sending $X$ to the market, we need to know their reported prices in the numeraire currency xDAI. The reported prices of assets in a prediction market always add up to 1 as only the tokens of one outcome will be worth 1 xDAI after market closing (Chen & Pennock, 2012). Thus, the sum of the unscaled prices of assets in the market equals the unscaled price of the numeraire, which is also the sum of the partial derivatives of the trading function for each asset class: $P_n=R_A+R_B$. With this the prices $p_i$ can be calculated by
$$
p_A = \frac{R_B}{R_B+R_A}
$$
$$
p_B = \frac{R_A}{R_B+R_A}
$$
and the number of tokens minted for each asset class are:
$$
n_A = \frac{X(R_B + R_A)}{N\cdot R_B}
$$
$$
n_B = \frac{X(R_B + R_A)}{N\cdot R_A}.
$$
Step 2: Swap to voted outcome asset
Next, the created assets $n_B$ of the not voted asset class $B$ are swapped to tokens of the voted asset class $A$. The number of received tokens from the swap is the difference in the reserves of asset class $A$ before and after the swap:
$$
n_{swap} = R_A - R_A^+
$$
$n_{swap}$ can be calculated using the trading function $φ(R) = R_A \cdot R_B$:
$$
φ(R^+) = φ(R)
$$
$$
R_A^+ \cdot R_B^+ = R_A \cdot R_B
$$
$$
R_A^+ = \frac{R_A \cdot R_B}{R_B^+}
$$
$R_A^+$ and $R_B^+$ represent the new asset reserves for asset class $A$ and $B$ after the trade. With $R_B^+ = R_B + n_B$ we get
$$
n_{swap} = R_A - \frac{R_A \cdot R_B}{R_B + \frac{X(R_B+R_A)}{N \cdot R_A}}.
$$
It follows
$$
n_r = \frac{X(R_B + R_A)}{N\cdot R_B} + R_A - \frac{R_A \cdot R_B}{R_B + \frac{X(R_B+R_A)}{N \cdot R_A}},
$$
and
$$
Q = \frac{\frac{X(R_B + R_A)}{N\cdot R_B} + R_A - \frac{R_A \cdot R_B}{R_B + \frac{X(R_B+R_A)}{N \cdot R_A}}}{X}
$$
Solve Kelly function for $X$
The Odds depending on the investment amount $X$ can now be inserted in the original Kelly function and solved for $X$:
$$
f^* = \frac{\frac{\frac{X(R_B + R_A)}{N\cdot R_B} + R_A - \frac{R_A \cdot R_B}{R_B + \frac{X(R_B+R_A)}{N \cdot R_A}}}{X} \cdot p - 1}{\frac{\frac{X(R_B + R_A)}{N\cdot R_B} + R_A - \frac{R_A \cdot R_B}{R_B + \frac{X(R_B+R_A)}{N \cdot R_A}}}{X} - 1}
$$
For easier notation we replace $R_A$ with $a$, $R_B$ with $b$ and set $N=2$. After simplification the function looks as follows:
$$
f^* =\frac{-2xab-2xb^2-4b^2a+xpa^2+2xpab+xpb^2+4pa^2b+4pab^2}{xa^2-xb^2+4a^2b}
$$
Most prediction markets take fees for placing a bet based on the bet amount. The equation can be extended by a fee factor $f$ with $0 \leq f \leq 1$ that discounts the investment amount $X$:
$$
f^* =\frac{-2xfab-2xfb^2-4b^2a+xfpa^2+2xfpab+xfpb^2+4pa^2b+4pab^2}{xfa^2-xfb^2+4a^2b}
$$
Using $f^* = \frac{X}{B}$, the equation can be solved for $X$:
$$
X=\frac{-4a^2b+Bb^2pf+2Babpf+Ba^2pf-2Bb^2f-2Babf\pm\sqrt{(4a^2b-Bb^2pf-2Babpf-Ba^2pf+2Bb^2f+2Babf)^2-4(a^2f-b^2f)(-4Bab^2p-4Ba^2bp+4Bab^2)}}{2(a^2f-b^2f)}
$$
Additionally if a prediction contains along with the probability score also a confidence score $c$, the probability $p$ can be reduced by $c$ with $0 \leq c \leq 1$, resulting in the updated equation:
$$
X=\frac{-4a^2b+Bb^2pcf+2Babpcf+Ba^2pcf-2Bb^2f-2Babf\pm\sqrt{(4a^2b-Bb^2pcf-2Babpcf-Ba^2pcf+2Bb^2f+2Babf)^2-4(a^2f-b^2f)(-4Bab^2pc-4Ba^2bpc+4Bab^2)}}{2(a^2f-b^2f)}
$$
Conclusion
The solved equation for X calculates the Kelly bet amount for the outcome of a CPMM prediction market with binary outcomes based on the current reserves $R_i=a$, $R_B=b$, a probability $p$ obtained from an external source, the market fees $f$ and the current bankroll $B$, which is the total amount available to bet.
References
Angeris, G., Agrawal, A., Evans, A., Chitra, T., & Boyd, S. (2021). Constant Function Market Makers: Multi-Asset Trades via Convex Optimization. arXiv preprint arXiv:2107.12484 [math.OC].
Beygelzimer, A., Langford, J., & Pennock, D. (2012). Learning Performance of Prediction Markets with Kelly Bettors. arXiv preprint arXiv:1201.6655 [cs.AI].
Chen, Y., & Pennock, D. M. (2012). A Utility Framework for Bounded-Loss Market Makers. arXiv preprint arXiv:1206.5252 [cs.GT].

Thank you for this contribution @jhehemann :)


Add YouLess component

I do understand I have got a fork, but the component hasn't been update for 11 months

When it's a fork, the bit can't approve it, since the commits/ last update of the origin needs to be checked, but I can ;)


Enable secure processing of XML Files

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.


Initial JSDoc

Adds initial JSDoc. This PR is meant more as an initial draft and is expected to receive more commits which will address inconsistent/incorrect documentation before merging into the base repository.

If this PR is still not ready for merging or review, please convert it into a draft.

I've checked over the documentation and I believe that no changes will be necessary after all (or at least I didn't find any) so I'll mark the draft as a normal PR now.


Samtay/alpha

@briceburg alpha

@SamTay this is looking great -- I think we should close out the planning issues ( #2 ) and go about setting up near-term milestones for the next iteration.
Thanks again for making this happen -- I look forward to trying it!


Fix logic for passing open PRs limit

Make changes to handling limits for open PRs:

DEPENDABOT_OPEN_PULL_REQUESTS_LIMIT always has a value and hence should always be passed from the task to the container.
Parsed value for open-pull-requests-limit should be validated and not default to 5.

@mburumaxwell Why should the parsed value not be default to 5?

@mburumaxwell Why should the parsed value not be default to 5?

My bad, I thought that value is required but I was wrong as per docs. Fixed in #436


Can't pass a string argument with spaces to the main function

Description:
$title.
This worked on 0.991.0. https://github.com/ballerina-platform/ballerina-lang/issues/2298 also used to work on 0.991.0 but doesn't work now - may have to recheck if something changed in how we use picocli with the jBallerina changes, to result in these issues.
Steps to reproduce:
import ballerina/io;

public function main(string s) {
    io:println(s);
}

$ ballerina run xyz.bal "spaces here !"
Compiling source
        xyz.bal

Generating executables
Running executables

ballerina: too many arguments to call the 'main' function

Affected Versions:
1.0.1

I checked with 1.0.3 build and it works fine.
➜  jballerina-1.0.3 ./bin/ballerina run foo.bal "this is a space"
Compiling source
	foo.bal

Generating executables
Running executables

this is a space

I just checked this and it's not working for me either.

Looks like a specific issue with picoli lib on linux machines


hook preSave not working on use updateOne

I have an endpoint for update user password, but when use Model.updateOne method, hooks is not called.
See my mode boot:
static boot({ schema }) {
    this.addHook('preSave', 'UserHook.hashPassword')
    this.addHook('preUpdate', 'UserHook.hashPassword')
}

See my hook:
'use strict'

const Hash = use('Hash')

const UserHook = (exports = module.exports = {})

UserHook.hashPassword = async (user) => {
  user.password = await Hash.make(user.password)
}

Can you help me?

Hooks only work for updates on the instance, not when triggering remote updates. You'll have to first load the User, then change the password, and then trigger a save.

Try checking the "hooks" documentation
https://mongoosejs.com/docs/middleware.html#pre
Maybe you should be looking for pre('updateOne') which should be preUpdateOne


change domain from always-on.app to mission-critical.app

good callout, but actually we should change it to this zone, which is currently in use in -Connected (at least for some stuff). Or we can also buy a second domain which aligns with the name used by -Online?


Any support for push-notifications?

Hello,
Does it support push-notifications? Any plans for it ?
Thank you,

Do you mead AppMetrika Push SDK? I'll dig into it next week :)

Hello, does the library support push-notifications?

implementation with Push SDK
https://github.com/dndev-company/react-native-yandex-appmetrica
but it seems without ios implementation


[cli] i am unable to figure out how to use alternate credentials

this could be just a documentation issue. in 1.6, we had --config to specify alternate credentials. how about 2.2? is there any way i can do the same thing (short of running rancher cli in docker and doing -v someother.json:/root/.rancher/cli2.json)?

@rmalchow There is currently not a way to do that without using docker as you suggested.


DT: Add option to treat NULL as category

This commit adds an option to treat NULL as a level in the categorical
feature. The level is added as a string (instead of a NULL value) to
ensure MADlib arrays don't have NULLs in them during the binning
procedure.

thank you for this!

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/madlib-pr-build/131/


Feature: Add support for Lucid Link v3+

What feature or improvement do you think would benefit Files?
They have updated the file structure and no longer give a path for the cloud spaces in v3.
Requirements

Search C:/Volumes and find all system link paths to display as Lucid link drives this would work for v2 and v3 clients

Files Version
<IP_ADDRESS>
Windows Version
10.0.26100.2314
Comments
No response

What would the symlinks be called?

It's based on what the user enters as a name, problem is the developers don't put that name anywhere in the files for v3 as far as I can see.

So how are you meant to be able to tell whether it's a LucidLink drive or not?

If someone puts their own system link in the C:\Volumes then we couldn't but I don't see that accidentally happening.

Can there be multiple folders under volumes?

Yes it a folder per workspace that contains a system link per file space

So there can be multiple workspace folders and multiple file space folders?

Yes


Sourcing of third party RPMs

Kyle helped us set up a ublue-os COPR where we can put stuff, and some of the images are pulling from RPMFusion, etc. We don't really have policy around third party repos but we should probably start talking about that.
This is all working ok for now, but long term we should just use the packages feature here for stuff when we can and just build them with actions.

I'm personally not a fan of the idea of adding xone or xpadeno but I did reconize the thrid party repo as a known eninity. While the Ubuntu build, and what I assume its replacement Bluefin, both use Tailscale.
I think it is important to declere if any repos are used outsdie of the defualts; and how a set standard on how those are added the the build. The main build script seems to be a perfectly fine way to do it, one block with everything listed and nothing else happening in that code block.

Yea, we need to make sure the end user can trace and know exactly what's on the image.

Quick note from an impromptu postmortem on the build failures. New 6.3.1 kernel needed a fix for xone to build, which was committed upstream 2 weeks ago but xone never released a new version, so negativo didn't pick it up because they're packaging the latest upstream. That caused the failure which led to main also not building.
For akmods we might consider just building them in our copr to remove a 3rd party dep, but also do git builds so we can rev faster if need be, and then we just need to decide if we gate in the build step or the rpm step.

I would like to focus that main images should stay as minimal as possible. Firejail doesnt work for me, so even having RPM Firefox is a bit bloat for me.
COPRS I use:

gocryptfs
ryzenadj

I would really like a minimal, hardened Kernel, hardened malloc version.

Main will stay relativly faithful to upstream. While adding QoL additions to make life easier for general user


Require await when calling "gen" prefixed functions

At Facebook I came across a convention to prefix all functions that return Promise with gen. So that it's immediately clear to a developer that they need to await it:
await this.genDoSomething();

The reason why this is important is that if you forget await then (while having type-valid code):
a) execution of async block is not suspended;
b) the method may fail silently while still being type-correct.
It would be great to have an eslint rule to enforce this. I'd be willing to help with creating one. Can someone knowledgable say if this is feasible and how can I go about this?

babel-eslint doesn't come with any rules so you wouldn't be making a PR here. If we accept it, it would go in https://github.com/babel/eslint-plugin-babel, although it seems to be a bit specific and maybe better as a custom rule?
You can definetely check that an Identifier in the CallExpression starts with gen but there's no way to know it returns a Promise or if other methods to start with gen as well.

Thanks @hzoo I'd like this rule to only check that all gen-prefixed functions are awaited. That I can do, right?

Sorry, yeah for sure (just not this in this particular repo)

Thanks @hzoo !


add the target support in PyGNMI

CVP is the Arista management tool. CVP has a database with the data streamed from the EOS devices.
CVP supports gNMI so we can sub on CVP to OC paths streamed by the device.
Here's the doc
Here's an example using gNMIc.
-a is the cvp address and  --target is the device SN
to sub to the BGP YANG container in the cvp database (cvp address is <IP_ADDRESS>) for the device spine1:
gnmic -a <IP_ADDRESS>:443 subscribe --path "openconfig:/network-instances/network-instance/protocols/protocol/bgp/" --token=$token --target=spine1_SN --skip-verify

Hey @ksator ,
Thanks for submitting a new request. We've just released a new version of pygnmi, which is 0.7.1. It adds target key, which needs to be passed to methods get(), set() and subscribe2() if you want to set that parameter. The sample code looks like:
    with gNMIclient(target=(ENV_HOSTNAME, ENV_PORT),
                    username=ENV_USERNAME,
                    password=ENV_PASSWORD) as gconn:
        gconn.capabilities()
        result = gconn.get(prefix="/openconfig-interfaces:interfaces",
                           path=["/interface[name=Loopback0]"],
                           target="dev-pygnmi-eos-001")
        print(result)

or:
    with gNMIclient(target=(ENV_HOSTNAME, ENV_PORT),
                    username=ENV_USERNAME,
                    password=ENV_PASSWORD) as gconn:
        gconn.capabilities()
        result = gconn.get(path=["/openconfig-interfaces:interfaces/interface[name=Loopback0]"],
                           target="dev-pygnmi-eos-001")
        print(result)

Please, give it a go and let me know
Best,
Anton

Hello @ksator ,
Give a try with the latest 0.7.3, I've changed a bit logic of target.
Best,
Anton

I just tried using 0.7.4
arista@devbox:~$ pip freeze | grep pyg
pygnmi==0.7.4
arista@devbox:~$

and it works using this kind of script
arista@devbox:~$ cat test8.py
"""
pygnmi script
"""

from pygnmi.client import gNMIclient

TELEMETRY_REQUEST = {
                         'subscription': [
                             {
                                #'path': 'openconfig:/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state',
                                 'path': 'openconfig:/network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=<IP_ADDRESS>]/state/session-state',
                                 'mode': 'target_defined'
                             }
                         ],
                         'mode': 'stream',
                         'encoding': 'json'
                     }

with open("token.tok") as f:
    TOKEN = f.read().strip('\n')

if __name__ == "__main__":
    with gNMIclient(target=('<IP_ADDRESS>', '443'), token=TOKEN, skip_verify=True) as gconn:
        gconn.capabilities()
        for item in gconn.subscribe2(subscribe=TELEMETRY_REQUEST, target="spine1"):
                print(item)

equivalents gnmic command
gnmic -a <IP_ADDRESS>:443 subscribe --path "openconfig:/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state" --token=`cat token.tok` --target=spine1 --skip-verify

gnmic -a <IP_ADDRESS>:443 subscribe --path "openconfig:/network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]/bgp/neighbors/neighbor[neighbor-address=<IP_ADDRESS>]/state/session-state" --token=`cat token.tok` --target=spine1 --skip-verify

Thank you so much @akarneliuk !
This issue can be closed


Making the 1Password workshop on demand

Description
Sales get a lot of requests about this workshop.
I am adding it to  Resources as there is clearly a demand for it.
Checklist:

[ ] I have reviewed the style guide.
[ ] If blogging, I have reviewed the blogging guide.
[ ] I have manually confirmed that all new links work.
[ ] I added aliases (i.e., redirects) for all filename changes.
[ ] If making css changes, I rebuilt the bundle.

Why does it say to have errors on lines I didn't even touch?!

Why does it say to have errors on lines I didn't even touch?!

I have a fix incoming shortly (this was some linting issues not caught in a merge from a community member).


Add jittering when flushing data to disk

cc @robskillington @martin-mao

Coverage decreased (-0.0004%) to 78.699% when pulling 29a3f030080797d536710e03ff43eefec7e1a2e8 on xichen-flush-jitter into edcd4cdbc82ba3a22e0a108058d24db2ef452639 on master.

Coverage decreased (-0.0004%) to 78.699% when pulling 29a3f030080797d536710e03ff43eefec7e1a2e8 on xichen-flush-jitter into edcd4cdbc82ba3a22e0a108058d24db2ef452639 on master.

We might want to think about the implications of this, for background repair it's probably ok that some take a little longer than others to repair.  However for flushing to disk, delaying the beginning of that process means we extend the time where data is held purely in memory (with the exception of the commit log which is very expensive to bootstrap from).  I think we can get away with a very small jitter, perhaps say 2-5 minutes, but 30 minutes definitely seems to aggressive.

Agreed we want to flush as early as possible, although 2-5 minutes might not be not long enough to spread out disk flushing across all nodes given a reasonably large cluster. Can start with 5 minutes and go from there.

Yeah, perhaps let's go with 5 minutes and I'll try to fix any underlying issues that cause degradation of perf during the actual flush.
Can you perhaps fix the dbRepairer also setting a global rand.Seed to use it's own source?


feat: zip package implemented

Added zip package to create a zip file of the extension with the 'npm run build' command.

Why you removed this?

@KrishEnacton  use gulp-zip or jszip


question: running worker as different user

Hi,
What's the recommended method of getting the frankenphp workers to run as different users?
I figure if running from a Docker container, the userid can be configured in the Dockerfile or the container creation.
But if running caddy 'locally' with the Frankenphp module enabled, is there a way to specify the effective userid/groupid? Caddy is normally run as root, and I believe now php is running as root, instead of falling down to something like 'www-data' or similar.
Is there a general Caddy directive for this that would work, or is there a Frankenphp-specific method?

I could be wrong, but the only reason Caddy runs as root is to use port 80 and 443, which you can give permission to do that:
sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary

Other than that, you can use something like authbind to handle that in a more fine-grained way: https://manpages.ubuntu.com/manpages/mantic/en/man1/authbind.1.html
Ultimately, you probably shouldn't be running any network services as root, but instead grant those services specific privileges and run them as a restricted user.

Almost every service in an Ubuntu / Debian system starts at root, then
drops privileges when running. So it isn't an unsecure or weird thing to do.
But I do seem to read up that forking itself is not really a thing in most
Go programs, so it seems even Caddy itself doesn't have a feature for this.
setcap is a nice way to overcome this and run the entire daemon as the
correct user from the start, thanks!
I also might just use sysctl to change the privileged ports.
On Mon, 27 Nov 2023 at 11:19, Rob Landers @.***> wrote:

I could be wrong, but the only reason Caddy runs as root is to use port 80
and 443, which you can give permission to do that:
sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary
Other than that, you can use something like authbind to handle that in a
more fine-grained way:
https://manpages.ubuntu.com/manpages/mantic/en/man1/authbind.1.html
Ultimately, you probably shouldn't be running any network services as
root, but instead grant those services specific privileges and run them as
a restricted user.
—
Reply to this email directly, view it on GitHub
https://github.com/dunglas/frankenphp/issues/320#issuecomment-1827545196,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMD2DQMVCULBP5QLQETEN3YGRSKLAVCNFSM6AAAAAA73YIDZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRXGU2DKMJZGY
.
You are receiving this because you authored the thread.Message ID:
@.***>


trainer_log.jsonl 输出不完整？

Reminder

[X] I have read the README and searched the existing issues.

Reproduction
trainer_log.jsonl 输出不完整是设计就是这样，还是bug？但trainer_state.json的log_history又是完整的

Expected behavior
trainer_log.jsonl 输出不完整是设计就是这样，还是bug？但trainer_state.json的log_history又是完整的
System Info
No response
Others
No response

Duplicate of https://github.com/hiyouga/LLaMA-Factory/issues/3658


Fine tune layer selector

This PR fixes cartodb.js side of https://github.com/CartoDB/cartodb/issues/10093
In addition to the issue's description, the layer selector should only be visible in the settings view in the Builder. That's why we need to segment when the vis is rendered from an embed view (by default) or by Builder.
cc @alonsogarciapablo @xavijam

showLayerSelector comes from the user's settings, through layer_selector option, IMO is a bad idea to mess with these values, they should remain inmutable. I've changed a bit the approach but avoiding to touch the options from settings.


Make a timestamp macro with ms and add to uncommon messages

Main change is adding ms accuracy - but also as a macro, so it's easy to use anywhere (and easy to change if required)
Running on linux

Hmm, if you're gonna change the format anyway, why not just switch to time-since-epoch? The server stuff all uses that to make it machine-readable... Any idea how many poolops do machine-processing of their logs? (I ask because if we switch to seconds or ms since epoch it makes more sense to only call printf once). Otherwise looks good.
On November 15, 2015 3:39:56 PM PST, kanoi<EMAIL_ADDRESS>wrote:

Main change is adding ms accuracy - but also as a macro, so it's easy
to use anywhere (and easy to change if required)
Running on linux
You can view, comment on, or merge this pull request online at:
https://github.com/TheBlueMatt/RelayNode/pull/21
-- Commit Summary --

Make a timestamp macro with ms and add to uncommon messages

-- File Changes --
M c++/client.cpp (11)
M c++/connection.cpp (2)
M c++/p2pclient.cpp (2)
M c++/relayproxy.cpp (1)
M c++/utils.h (18)
-- Patch Links --
https://github.com/TheBlueMatt/RelayNode/pull/21.patch
https://github.com/TheBlueMatt/RelayNode/pull/21.diff

Reply to this email directly or view it on GitHub:
https://github.com/TheBlueMatt/RelayNode/pull/21

Yeah I spend my life looking at screen logs - so it's easy to compare visually when something appears.
Maybe add the sec.usec also before/after the stamp?

Yeah adding this accuracy shows the poor transmission times of the current public relay.
Guess I better just use it in my own git.

Hmm? I was being lazy since I had a big rewrite I was testing to merge first. Where are you seeing poor transmission times?
On November 27, 2015 4:19:48 PM EST, kanoi<EMAIL_ADDRESS>wrote:

Yeah adding this accuracy shows the poor transmission times of the
current public relay.
Guess I better just use it in my own git.

Reply to this email directly or view it on GitHub:
https://github.com/TheBlueMatt/RelayNode/pull/21#issuecomment-160204823

You need this accuracy to make any useful analysis of the relay times.

Wait, so are you saying this showed you some bad relay times or just you got tired of waiting? Anyway, I've been planning on merging, just been busy rewriting the server side code and a new protocol version. Should have that stuff mostly done in a week or two depending on how much I get done while in HK.
On November 27, 2015 4:19:48 PM EST, kanoi<EMAIL_ADDRESS>wrote:

Yeah adding this accuracy shows the poor transmission times of the
current public relay.
Guess I better just use it in my own git.

Reply to this email directly or view it on GitHub:
https://github.com/TheBlueMatt/RelayNode/pull/21#issuecomment-160204823

No, it shows unexpected results from multiple relays at certain times.
Indeed I've not done a reliable analysis of it yet - though, as I said, this accuracy would be necessary to do that, however:
I guess at this point I need to state the obvious.
Using such a relay is way faster than not using it.
Peer to peer relaying of blocks is slow (by nature) but even slower due to the bitcoin protocol being unable to be upgraded to include trust and thus allow faster transmission of valid hashed blocks that are not fully transaction verified. Full verification takes a LONG time. Full verification is required in bitcoind before transferring a block to another node, yet that other node will of course also do that full verification before considering it.
In gmaxwell's words: https://github.com/bitcoin/bitcoin/issues/7049#issuecomment-157569702

In general our experience suggests that trust settings are black magic that cannot be configured correctly even by experts

The down side of that black magic of trust would be that invalid blocks would be checked by more nodes. However if that trust level check included an EXCEPTIONALLY quick check of the hash and that the block indeed hashes a known previous block, then that would greatly reduce the amount of invalid block relaying done by bitcoin, using this black magic, since creating a hashed valid block is not all that easy to do ...
So it would seem that you have indeed produced black magic with your relay.

I think you might be surprised with how fast block validation is on reasonably nice hardware (ie most servers you'd ever buy or recent hardware you'd buy if you care at all about performance) is (often faster than network latency). The inefficiency of the p2p network seems to come a bunch from the way the networking stack is written (incl the message processing thread and the way relay is done), but mostly from the fact that it is a p2p network... You're never gonna best something that is centralized and smart enough to get better routing.
I'm confused on what you mean by unexpected results, though. I know sometimes relays won't compress well (go look at 21's blocks.....) and end up spending time compressing for no gain, only to lose more packets than some miner's personal relay network and not win the race (there's an issue about exploring non-tcp relays and I'm gonna turn off the p2p access to the relay network soon which should help some).
As for the relay network introducing trust relationships in Bitcoin, I'd hope no one is spv mining on its headers (it probably won't actually get you much if you do - the spv mining wins are largely related to delays getting the data and calling getblocktemplate, not validating the block, so just validating the block and using the blocknotofy stuff to create your own empty block should be just as quick).
On November 27, 2015 5:40:31 PM EST, kanoi<EMAIL_ADDRESS>wrote:

No, it shows unexpected results from multiple relays at certain times.
Indeed I've not done a reliable analysis of it yet - though, as I said,
this accuracy would be necessary to do that, however:
I guess at this point I need to state the obvious.
Using such a relay is way faster than not using it.
Peer to peer relaying of blocks is slow (by nature) but even slower due
to the bitcoin protocol being unable to be upgraded to include trust
and thus allow faster transmission of valid hashed blocks that are not
fully transaction verified. Full verification takes a LONG time.
Full verification is required in bitcoind before transferring a block
to another node, yet that other node will of course also do that full
verification before considering it.
In gmaxwell's words:
https://github.com/bitcoin/bitcoin/issues/7049#issuecomment-157569702

In general our experience suggests that trust settings are black
magic that cannot be configured correctly even by experts

The down side of that black magic of trust would be that invalid blocks
would be checked by more nodes. However if that trust level check
included an EXCEPTIONALLY quick check of the hash and that the
block indeed hashes a known previous block, then that would greatly
reduce the amount of invalid block relaying done by bitcoin, using this
black magic, since creating a hashed valid block is not all that easy
to do ...
So it would seem that you have indeed produced black magic with your
relay.

Reply to this email directly or view it on GitHub:
https://github.com/TheBlueMatt/RelayNode/pull/21#issuecomment-160223304

I think you might be surprised at just how slow bitcoind full verification is on good hardware ... I doubt you've verified it's performance, if you'd make the statement suggesting it's fast.
I've verified this on fast hardware over many months where I have full logs of the stages of block changes ... and this was the first reason why I added ms accuracy to cgminer and ckpool (in the past) and now the relay also (though I hacked it into my copy of the relay code a while back also)
Here the last 2 blocks:
Relay time : [2015-11-27 23:45:00.816+00] ...00005b1c ...
Notify time : 2015-11-27 23:45:01.806+00 ... 00005b1c ...
Relay time : [2015-11-27 23:45:38.823+00] ...000052d0 ...
Notify time : 2015-11-27 23:45:39.294+00 ... 000052d0 ...

The first case a 990ms gross processing time, the second case a 471ms gross processing time.
And yes I can find fast ones also - it's not the hardware that's the issue, bitcoind's full block verification takes a lot of CPU power.
Hmm maybe gmaxwell is right about people not understanding trust and considering trust black magic ...
My bitcoind (since it is based on core) does full validation.
The relay network allows fast relaying of blocks without the unnecessary full validation of those blocks multiple extra times ...
... since my node that receives the block does the full validation once rather than it being done MANY times during the peer 2 peer bitcoind version of block relaying ... and thus slowing down he bitcoin peer 2 peer block relay dramatically.

As for the relay network introducing trust relationships in Bitcoin, I'd hope no one is spv mining on its headers

f2pool, who you recently helped get the relay working well for them, SPV mines
The fact that they SPV mine has been VERY common knowledge in the bitcoin world for a long time ... and was discussed in the #bitcoin-dev IRC channel when the major v2/v3 fork occurred due to SPV mining ... and they publicly state they do also.

Yes, excuse me, I was basing my assertion partially on how Bitcoin Core master (ie 0.12) performs. Between using libsecp256k1 for signature verification, the mempool limiting stuff, the better sigcache, the smarter BIP30 handling, etc (see https://github.com/bitcoin/bitcoin/issues/6976 and, eg, https://github.com/bitcoin/bitcoin/pull/7037), block connection (and getblocktemplate) are much faster. Also, adding a massive dbcache and running things on an SSD can make a massive difference.
I'm aware that SPV mining is happeneing (f2pool is not the only major miner who does it), but I have no indication that f2pool is SPV mining on blocks it receives from the relay network. As mentioned in the last comment, I do not think f2pool would see similar gains by SPV mining on relay network headers.

I'm aware that SPV mining is happeneing (f2pool is not the only major miner who does it), but I have no indication that f2pool is SPV mining on blocks it receives from the relay network. As mentioned in the last comment, I do not think f2pool would see similar gains by SPV mining on relay network headers.

f2pool's SPV mining is stratum based so this is correct.

I'm aware that SPV mining is happeneing (f2pool is not the only major miner who
does it), but I have no indication that f2pool is SPV mining on blocks it receives
from the relay network. As mentioned in the last comment, I do not think f2pool
would see similar gains by SPV mining on relay network headers.

f2pool's SPV mining is stratum based so this is correct.

... so that's where you got the idea of poolbench when the 2 of you were working with f2pool ... the way they do their spv is the same
... maybe if any pools want to, they might want to stop f2pool (and antpool and ...) using their nodes to spv mine ...

... maybe if any pools want to, they might want to stop f2pool (and antpool and ...) using their nodes to spv mine ...

Blocking f2pool from SPV mining off of your pool would really only hurt your own pool since it would slow down their block changes for blocks you mine.

 ... maybe if any pools want to, they might want to stop f2pool
 (and antpool and ...) using their nodes to spv mine ...

Ah the power of a larger misbehaving mining pool over a smaller mining pool.
We should bow down to their power and let them use our nodes for SPV mining ... since ... ? are you saying SPV mining is ok and we should not hinder them?

Firstly, there's 3 ways to do SPV mining:

mining stratum on other pools (which at the moment they are even scummy enough to do dead mining - no actual hardware mining, just connecting to other pools and using their block change information ... wow a pool that big wont even put up any hash rate to another pool they are using to help them SPV mine ...yeah that's the obvious hint how to stop them at the moment)
relay - doesn't matter what you guys say, the relay is blatantly obviously faster than the peer 2 peer block relaying of the network ... otherwise there's no point to the relay ... and only a fool would think that coders are unable to do the same simple SPV mining that is done with their dead stratum mining nodes. It may not be used for that at the moment, but anyone with half an ounce of nous would spot the obvious
bitcoin daemon - again the obvious for any coder - change in there to do something with the block when it first arrives rather than wait for verification
did I say 3? Yeah the obvious 4th is to (slowly) code their own versions of 1, 2 and 3 rather than just hack into current code and get it done quickly.

The macro itself (as is obvious) is just c, not c++
Recent 0.12 of bitcoin master has a c++ version which may 'look' better for this since it's c++

Though I'm gonna avoid commenting on 1 or 3, the point I was making is less that it is somehow impossible to SPV mine on what you get back from the relay network (obviously that is bogus), but that doing so will likely not net you very much with a reasonable architecture. Since there is little to no time between receiving the block header on the relay connection and receiving the full block, the only advantage to SPV mining on the relay network is (in a properly-architected pool) local block validation latency. WIth a warm sigcache and utxo cache, this is incredibly fast on 0.12, (50 to 200 ms or so) at which point its largely not worth the risk of maybe, once, mining an invalid block because of it.

I dont care much at all about C vs C++, though I do care about avoiding additional printfs (ala HASH_PRINT and HASH_FORMAT, which have fixed a bunch of bugs on the log-processing stuff :) )

yeah the main point to that was to be able to just stick the macro anywhere it was required without having to rewrite the message printed after it (since the macro's not linefeed terminated)

Yea, I only mention it in general, it was a big issue since there are multiple block prints near the same time, it shouldn't really ever be an issue for clients or where its used here. Merged (without the change to relayproxy).


README out of date regarding Visual Comparison tests

Where to find the issue
README.md
Describe the issue
Some sections in the cwa-website README.md which are associated with Visual Comparison tests are no longer relevant or correct because these tests are no longer part of the Cypress test suite.
The Visual Comparison tests were disabled in Aug / Sep 2020 through PR https://github.com/corona-warn-app/cwa-website/pull/302 and https://github.com/corona-warn-app/cwa-website/pull/372. The remnants of the use of cypress-plugin-snapshots were then removed in Nov 2021 through PR https://github.com/corona-warn-app/cwa-website/pull/2113.
The comment that "Run all specs" should not be used no longer applies. Executing:
npm run test:prepare
npm run test:open

then selecting "Run 6 integration specs" in the Cypress console results in 74 tests being run successfully with 0 failures.

Suggested change
Remove from README.md:

"Be aware that you should only run one file after another and not click on Run all specs since the screenshot test library has a bug which causes falsy tests for Visual Comparison."

"IMPORTANT: In case Visual Comparison tests are failing after changes to css, header or footer, delete the .png files from ./cypress/integration/image_screenshots and run the blog e2e tests with npm run test (without :open!) to recreate the screenshots. Additionally, apply the screenshots to the codebase."

PR #2161 is submitted to resolve this issue.