Separate accepted and rejected files

Currently it's not possible to distinguish between accepted and rejected files. The onDrop and the onDropAccepted functions gets only called with the accepted files. The onDropRejected function on the other side gets only called with the rejected files. But sometimes it's useful to react to both states.
This pull request implements the feature in a backward compatible way. The onDrop function gets the rejected files passed as second parameter. The onDropAccepted and the onDropRejected functions behaves the same.

Yes, it can break code, because the onDrop method gets always called now. Previously it was only called if all files were accepted. So I think a major release would be the best.
I think it may also be useful to pass the accepted files as second parameter to the onDropRejected function. So a user could display an error message like "2 files from 8 couldn't be uploaded". What do you think?
With this addition, every method gets now all files passed.

onDrop(passedFiles, rejectedFiles) => Gets always called and is useful to handle custom behavior
onDropAccepted(files) => Gets called if all files are accepted and is useful to handle the success state
onDropRejected(rejectedFiles, passedFiles) => Gets called if any of the files will be rejected and is usefull to handle the failed state

I've updated the pull request and I've changed only the style issue. Let me know if I should also implement the suggested onDropRejected behavior.

@akkie I'm not sure we should change the signature of this method. In the described use case the onDrop method should be used to implement the custom logic. What we could do to make it simplier is to export filter function i.e. allow custom filters. See #104

BTW for your example of showing that some files didn't get accepted, it's not even needed to export anything. So you could do:
onDrop = (acceptedFiled, rejectedFiles) => {
    if (rejectedFiles.length) {
        // show message that some files were rejected
    }
    this.setState({
        files: acceptedFiles
    });
}

Yes, you are right. I thought it would be useful for the sake of consistency. But I'm also fine with the current implementation. Anyway the filter option should be implemented into another pull request.

Great :+1:

This change is in the documentation, but there was no release on npm.

I've released a new version: https://github.com/okonet/react-dropzone/releases/tag/3.7.0


Face Recognition using ReactJS

Description 📜
It's a Face Recognition application, made using ReactJS  and Face-Recognition API, here user can select any image and the application detect the faces and here also 'Tag' feature is added by which you can Tag your friends.

Fixes #1249

Type of change 📝

[x] Add a new project

Domain of Contribution 📊

[] Project using only HTML & CSS
[] Project using HTML, CSS & JS
[x] Project using ReactJs

Checklist ✅

[x] I have performed a self-review of my own code or work.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] My changes generate no new warnings.
[x] I'm GSSoC'22 contributor

Screenshots / Gif (Recommended) 📸
https://user-images.githubusercontent.com/77873383/167076438-335600d7-e29b-4e9b-a82f-fa2ec0a3df42.mp4

@gurjeetsinghvirdee  updated


[Impeller] Allow batching/threading of geometry computation workloads incl. compute.

Overview
The current design of the geometry system requires each geometry object to individually compute its own vertices to provide these synchronously to the rendering contents. We'd like to adjust this so that the geometry computations can be conditionally offloaded onto compute workloads, which should be significantly faster. On devices that do not support compute or for algorithms that are not trivially parallelizable, we may still be able to offload tasks to worker threads.
Background
A compute workload is going to be dispatched to a minmum number of threads, for example 1024 on macOS and iPhone 13. Some parallel algorithms used, like prefix sum, require barrier synchronization, meaning all threads must hit the same barriers and do some amount of work. Thus a compute workload operating over a 3 point polyline will perform about the same as a compute workload operating over a 300 point polyline. In addtion, there is some CPU side cost in creating and encoding compute commands. As a result of this, we don't want to map entity geometry objects 1:1 with compute commands. Instead we'd like to batch them up into as few compute commands as reasonable.
For non-compute workloads, offloading to a worker thread means that the existing encoding can continue to make progress - provided we have some way to eventually delay upload until the computation is ready. Since we've moved to async encoding for Metal (and are trying to do this for Vulkan) we can actually push both the CPU bound workload and encoding into worker threads (given correct synchronization) and continue on. Naturally, we don't want to spin up a worker thread per geometry as a given scene may have hundreds or thousand of individual geometry pieces.
Overview
Prototyped here: https://github.com/flutter/engine/pull/42285
This PR introduces a system for batching up compute commands, which is called a GeometryPass. Each EntityPass will lazily contruct a GeometryPass object. This object will have methods that are specific to the type of geometry being computed, and will eagerly return IndirectCommandArguments which can be used by the rendering contents to encode commands whose vertex count we don't yet know. When the render pass is encoded, it will first enqueue and encode the commamd buffer, which insures all geometry data required by the render pass is ready before the vertex/fragment stages start.
In this PR, the indirect arguments are not yet used. Only the ConvexTessellation has been implemented, as this is the simplest algorithm for batching.
In performance testing locally, this doesn't perform noticably better or worse than the current CPU based convex tessellator. Large gains require polyline computation to also be moved to compute. Note that batching commands requires a bit more state to be tracked. For convex tessellation, we need to know the start of the current piece of geometry. We'll likely need to encode more data for polyine computation, et cetera. This slightly increaases the costs of the shaders but without batching its not likely to be feasible to use compute except for extremely large geometry.

Instead of doing this we just made geometry computations much faster!


xCode 8 issues: ViewController' does not conform to protocol 'VuforiaEAGLViewSceneSource'

After upgrade to xCode 8 ... swift 3 (recommend) ....  not working when I download this default project
'ViewController' does not conform to protocol 'VuforiaEAGLViewSceneSource'
Any Advice?

@markleeyw
I updated this project to support Xcode8 and Swift3. Please try new version.
Maybe failed to convert syntax of these protocol methods...


RoutedEvents for DataGrid

Is your feature request related to a problem? Please describe.
Most of the events on the data grid (CellEditEnded) do not have an associated RoutedEvent.
Describe the solution you'd like
Would it be possible to add RoutedEvent's to some of the DataGrid?
Describe alternatives you've considered
No response
Additional context
No response

Is it fine if I open a PR to try and implement this?

Adding a new parameter to the constructor is a breaking change. Yes. You don't really need to change it though, as you can pass static event definition directly from there.
But saying this, why does this event need to be routed? Each routed event decreases performance, which might be noticeable with hundreds of cells on the screen. WPF also didn't have this event as routed https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.datagrid.preparingcellforedit?view=windowsdesktop-8.0


Support for the histogram diff algorithm

In Git, the default diff algorithm used when merging is not the Myers algorithm implemented here, but the so-called histogram algorithm, which can significantly improve the quality of merges.
To see an example where the diff algorithm makes a difference to the merged output, see for instance the test cases in this PR, which shows a case where using Myers creates various conflicts, while using histogram merges cleanly.
I wonder if implementing the histogram algorithm (in addition to Myers) would be in scope for this library?

This has been implemented in a different crate: imara-mergy, which did so by vendoring parts of diffy and integrating it with imara-diff.


Launching throws error with Exllamav2 stating "Tokenizers" are not found

Followed the install instructions, launching the server.py in exui throws the below error:
  File "G:\_AI\exui\server.py", line 11, in <module>
    from backend.models import update_model, load_models, get_model_info, list_models, remove_model, load_model, unload_model, get_loaded_model
  File "G:\_AI\exui\backend\models.py", line 5, in <module>
    from exllamav2 import(
  File "C:\Users\Adzei\AppData\Local\Programs\Python\Python310\lib\site-packages\exllamav2\__init__.py", line 9, in <module>
    from exllamav2.tokenizer.tokenizer import ExLlamaV2Tokenizer
  File "C:\Users\Adzei\AppData\Local\Programs\Python\Python310\lib\site-packages\exllamav2\tokenizer\__init__.py", line 5, in <module>
    from exllamav2.tokenizer.hf import ExLlamaV2TokenizerHF
  File "C:\Users\Adzei\AppData\Local\Programs\Python\Python310\lib\site-packages\exllamav2\tokenizer\hf.py", line 4, in <module>
    from tokenizers import Tokenizer
ModuleNotFoundError: No module named 'tokenizers'```

Workaround is to install the "tokenizers" package which does not seem to be included in the provided requirements.txt So just do a pip install tokenizers in your venv.


Title: Improve the services section of the website

Is your feature request related to a problem? Please describe.
Upon visiting your Services section, I noticed a few areas that could be improved to further enhance its effectiveness.
Describe the solution you'd like.
I can improve it with some formatting in the CSS.
Describe alternatives you've considered.
I have considered the altenative is that I can improve the font size and font theme, also give some rellevant padding to look good in the website.
Add any other context or screenshots about the feature request here.
Please assign this issue to under GSSOC'23 as I want to contribute it.

Sure @heet-26

please assign me this issue

I would like to work on this issue. Kindly assign it to me.

@agamjotsingh18 I have raised the PR of this issue. Kindly see it so that I can work on further issue.

hey @agamjotsingh18 I've developed many websites, I want to work on this project, kindly assign it to me.


Grafana won't start without user: "1000" in docker-compose

You can try using user: "472:472".
https://grafana.com/docs/grafana/latest/installation/docker/#migrate-from-previous-docker-containers-versions

@CVJoint Thanks for your tip, unfortunately this requires a user with the ID 472 on the OS

Possible solution: use https://hub.docker.com/r/stereum/init to set correct owner & permissions of grafana's data dir.

Possible solution: use https://hub.docker.com/r/stereum/init to set correct owner & permissions of grafana's data dir.


Database URL with hostname not accepted

Only localhost is accepted as hostname for a database URL, but it does not work when using another entry in /etc/hosts.
The problem is in the URL parsing regex:
https://github.com/terminusdb/terminus-javascript-sdk/blob/11107c8aca2937bea3e65bff9b0349a0d6939677/WOQLClient.js#L774-L782

Fixed in latest version


Change project file condition handling to be case-insensitive

Had to fiddle with the test a bit because one of the test projects uses the given build configuration as part of its output path, but this should fix #1889.

Uhh, soo, travis is out of disk space?

I'm not sure with which person I have to sleep with to get this bigger.

regarding mono build issue: https://github.com/travis-ci/travis-ci/issues/6524


Forced reading of highlight prevents reading sections with a priority extract

you mentioned that if one wanted to extract a section of a pdf, then one could just extract the title and read below.
In practice, this cannot be done, however, because of the solution you had for moving to a part of a pdf in the incremental reading queue. That is to say, it forces you to be at that part at all times. So if you try to scroll down at all it just brings you back up to the section heading, so you cannot actually incrementally read a section within the incremental reader if you try to use this method of highlighting the section heading.
Even if you try to highlight the entire section it won't let you read that section in the incremental queue because it then changes to forcing you to read the center of that highlight:

oof yeah that's very annoying, fixed :) will be in the next release


Tags do not get populated in Asana.

Tags do not get populated in Asana. No error in the console. Tested in Jira and it worked.
Chrome Version 48.0.2564.116 (64-bit)

They started showing up after about 20 minutes, so it must have just been that it was not synched


feat: add more info about colors in sgr sequences

Implement changes based on issue #16 and fix SGR 59.

fix unhandled runtime error in SGR 59
replace unformatted RGB values for truecolor with hex values
add matching hex values for ANSI256 colors
add info about type of color being used (ANSI, ANSI256, 24-bit RGB)
adjust test data

SGR 59 was not handled correctly:

Example of output after changes:
λ printf '\x1b[34m\x1b[30m\x1b[39m\x1b[38:2:45:134:211m\x1b[38:5:34m\x1b[59m\x1b[58:5:34m\x1b[58:5:2m\x1b[58:2:43:56:233m\x1b[107m\x1b[58:5:2m\x1b[48:5:12m' | ./sequin
 CSI 34m: ANSI foreground color: Blue
 CSI 30m: ANSI foreground color: Black
 CSI 39m: Default foreground color
 CSI 38:2:45:134:211m: 24-bit RGB foreground color: #2D86D3
 CSI 38:5:34m: ANSI256 foreground color: 34 (#00AF00)
 CSI 59m: Default underline color
 CSI 58:5:34m: ANSI256 underline color: 34 (#00AF00)
 CSI 58:5:2m: ANSI256 underline color: 2 (Green)
 CSI 58:2:43:56:233m: 24-bit RGB underline color: #2B38E9
 CSI 107m: Bright ANSI background color: White
 CSI 58:5:2m: ANSI256 underline color: 2 (Green)
 CSI 48:5:12m: ANSI256 background color: 12 (Bright blue)

Note
Using hex strings has an added bonus for emulators like Konsole, which can have a color preview built-in:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

34 of 42 (80.95%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.5%) to 87.389%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sgr.go
34
42
80.95%

Totals

Change from base Build<PHONE_NUMBER>8:
-0.5%

Covered Lines:
686

Relevant Lines:
785

💛  - Coveralls

done the bright thing on main.

This is such great revision. Thanks, @mkotowski!!

True that! Thanks so much @mkotowski !


Automate and update SPECpower coefficients data

Adds web scraper logic to SPEC power results, updating and automating to process to retrieve data on a more regular basis and keep our coefficients data more up to date and accurate

Completed with the implementation of #62


asp-for now not working when casting in asp.net core 2

The asp-for casting shown below used to work in core 1.0 and core 1.1 but now doesn't in core 2.0?
<input asp-for="@(Model as ServiceOperative).JobTitleClient" class="form-control" />
It now gives the following error -
InvalidOperationException: Templates can be used only with field access, property access, single-dimension array index, or single-parameter custom indexer expressions.
The following gets round the initial error, but then renders the name/id as somodel_JobTitleClient - which then will not bind to the object server-side
var somodel = (Model as ServiceOperative);
<input<EMAIL_ADDRESS>class="form-control" />
I tried a bunch of alternatives to the above but had to revert to using @Html.EditorFor for now...   =painful rework   :(

@pranavkm can you take a look? Presumably we changed our expression generator here...
Also cc @rynowak

This issue was moved to aspnet/Razor#2065


Implement tiling patterns for the SVG back-end

It may not be perfect, but some PDFs, such as #10796, can be rendered.
Fixes #10796.
Improves #4985.

/botio-linux preview

@timvandermeij @janpe2 Please review it.

/botio-linux preview

Nice work; thank you for improving the SVG back-end!


Rust: Proposal on tag key concatenation

Still trying to make a more idiomatic representation for colon separated keys.
Will probably then repeat this for pipe and semi-colon separated values if we are happy with it.

merged into PR#24


Update environment.yml

RISE is apparently now supported through conda-forge; damianavila82 hasn't updated his anaconda files in some time.

perfect - thanks!


Wiznet 5500 (IDFGH-1849)

Environment

Development Kit:      [ESP32-Wrover-Kit|ESP32-DevKitC|ESP32-PICO-Kit|ESP32-LyraT|ESP32-LyraTD-MSC|none]
Kit version (for WroverKit/PicoKit/DevKitC): [v1|v2|v3|v4]
Module or chip used:  [ESP32-WROOM-32|ESP32-WROOM-32D|ESP32-WROOM-32U|ESP32-WROVER|ESP32-WROVER-I|ESP32-WROVER-B|ESP32-WROVER-IB|ESP32-SOLO-1|ESP32-PICO-D4|ESP32]
IDF version (run git describe --tags to find it):
// v3.2-dev-1148-g96cd3b75c
Build System:         [Make|CMake]
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
// 1.22.0-80-g6c4433a
Operating System:     [Windows|Linux|macOS]
Power Supply:         [USB|external 5V|external 3.3V|Battery]

Problem Description
What would be the ESP-IDF approach to adding Adafruit Featherwing Ethernet Wiznet 5500 https://learn.adafruit.com/adafruit-wiz5500-wiznet-ethernet-featherwing/overview
    ESP_ERROR_CHECK(esp_event_loop_create_default());
    ESP_ERROR_CHECK(tcpip_adapter_set_default_eth_handlers());
    ESP_ERROR_CHECK(esp_event_handler_register(ETH_EVENT, ESP_EVENT_ANY_ID, &eth_event_handler, NULL));
    ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, IP_EVENT_ETH_GOT_IP, &got_ip_event_handler, NULL));

    eth_mac_config_t mac_config = ETH_MAC_DEFAULT_CONFIG();
    eth_phy_config_t phy_config = ETH_PHY_DEFAULT_CONFIG();
#if CONFIG_EXAMPLE_USE_INTERNAL_ETHERNET
    esp_eth_mac_t *mac = esp_eth_mac_new_esp32(&mac_config);
#if CONFIG_EXAMPLE_ETH_PHY_IP101
    esp_eth_phy_t *phy = esp_eth_phy_new_ip101(&phy_config);
#elif CONFIG_EXAMPLE_ETH_PHY_RTL8201
    esp_eth_phy_t *phy = esp_eth_phy_new_rtl8201(&phy_config);
#elif CONFIG_EXAMPLE_ETH_PHY_LAN8720
    esp_eth_phy_t *phy = esp_eth_phy_new_lan8720(&phy_config);
#elif CONFIG_EXAMPLE_ETH_PHY_DP83848
    esp_eth_phy_t *phy = esp_eth_phy_new_dp83848(&phy_config);
#endif
#elif CONFIG_EXAMPLE_USE_SPI_ETHERNET

I noticed you have some CONFIG_EXAMPLE_USE_SPI_ETHERNET has any one had any success using this for that chipset?

Hi @drdelgado W5500 is not compatible with LwIP because W5500=PHY+MAC+TCP/IP, it has a hardware TCP/IP engine. If you want to use Ethernet with less pins, you can give DM9051 a try. Currently it's the only SPI Ethernet we support in idf.

@suda-morris I thought we talked about that in the other issue.  There is a valid workaround to have w5500 work with lwip in macraw mode.  It's fine if you don't want to support it, just don't use incompatibility as an excuse :stuck_out_tongue:

Thanks for correcting me @negativekelvin :sweat_smile:
W5500 is cool if we can have it in IDF, but I'm sorry it's not in a high priority now. I hope I can do some extra experiment on the macraw mode and bring it to idf.

Hi all,
There is an attempt to add W5500 to the ESP32 LWIP stack : https://github.com/johnnytolengo/w5500lwip
Maybe it's a good starting point

@psykokwak-com at https://github.com/espressif/esp-idf/issues/2303#issuecomment-676798043 has another implementation that works and can be used as a reference when implementing a driver using the MACRAW socket of these chips.


Domain and Effect creation

Leo: Why is there no code sample for addDomain like there is for addEffect ?

Nate: There is no reason. I'll add an issue for this. We also need to better describe how you can create domains and effects (simple objects vs classes)

👍 for highlighting "simple objects vs classes," I tripped over that one for a while.

@keturn I've sent out a PR that documents the creation process here:
https://github.com/vigetlabs/microcosm/pull/275
I'm happy to help clear things up. Would you be willing to share what tripped you up, so I can make sure to cover it in the docs?

The way I remember it is that I thought "both Domain and Effect have register methods that refer to methods on this., I'll make them both classes",
and then things confusingly Did Not Work until I made the Domain a simple object instead.
However, the documentation in this patch says you can use either approach with either thing. Is that a change since version 11?

Hmmm. It looks like we added it in 10.2.0:
https://github.com/vigetlabs/microcosm/blob/master/CHANGELOG.md#1020
So I'm not sure. We use the class form on a project that's still on 11.x without a problem.
Either way, I am glad that the class form jives with how you were thinking about Domains and Effects!

Just merged a related PR. I'm going to close this out.


feat: allow imports in inline templates

I've made an attempt at supporting Jinja2 include/import in inline templates in

templated values in copier.yml,
templated folder names,
templated file names, and
templated text file content.

Closes #718 (I hope :crossed_fingers:, or maybe some day).

To make this work, I've added a new option _jinja_paths: Dict[str, str] in copier.yml which is a mapping from identifiers to paths relative to the repository root from which additional Jinja2 templates are loaded, e.g.:
_jinja_paths:
  $: includes

A template can be included like this:
{% include "$:name-slug.jinja" %}

Under the hood, the Jinja2 PrefixLoader is used. My reasons for this approach are:

Templates to be included for, e.g., deriving values from answers are typically not copied to the project and IMO should be placed in a dedicated folder to avoid mixing them with other files. Instead of hardcoding the name for this folder, I think it's better to make it configurable.
I had thought about resolving the referenced template relative to where it is being used (e.g. an {% include ... %} in copier.yml would resolve relative to this file, an {% include ... %} in some templated folder name would resolve relative to this templated folder in the template, etc.), but this might easily require using / in the include path which isn't possible due to filesystem restrictions (i.e. a folder name like {% include "includes/name-slug.jinja" %} is not possible). IMO, the typical use case is to have a central collection of Jinja2 templates to be included or macros to be imported which suggests giving this "special" path an abstract identifier.

I consider this PR a basis for further discussion rather than ready to be merged (unless you think it's exactly what you had in mind :smile_cat:) since #718 doesn't fully specify the usage of this feature, so that I imagined how I would use it.
WDYT, @yajo?

Windows seems to choke on some character in the templated path name. I'll investigate this once I have some feedback on the general idea.

Double quotes are indeed invalid characters in Windows paths, try using single quotes instead.

Thanks, @pawamoy! I've changed the quotes, but CI on Windows is still failing. Might still be the : character.
About using / in paths: I just stumbled over the docs section on generating a directory structure which suggests it is actually possible to include path separators. Perhaps a Jinja2 include in a templated folder name might look like this:
📁 my_copier_template
├── 📄 copier.yml
├── 📁 includes
│   └── 📄 name-slug.jinja
└── 📁 template
    └── 📄 {% include '..' + _copier_conf.sep + 'includes' + _copier_conf.sep + 'name-slug.jinja' %}.py

Not super readable, but might work. Would this be preferable over using a prefixed/named load path?
Perhaps it's not actually the filesystem that doesn't support / in folder names, but I observed that Path::iterdir() in
https://github.com/copier-org/copier/blob/468b9ff78cf2331a70d8b99a6b1a812e3c40f1c4/copier/main.py#L542
splits at the / in {% include '../includes/name-slug.jinja' %}.

Not super readable, but might work.

The DX might be better if we used a Jinja2 filter, e.g.:
{% include ['..', 'includes', 'name-slug.jinja']|join(_copier_conf.sep) %}.py

Or with a custom filter for even better readability which internally uses _copier_conf.sep:
{% include joinpath('..', 'includes', 'name-slug.jinja') %}.py

Might still be the : character.

Ah, true, I remember now that I couldn't use : in tracks/movies file names on Windows.

I have revised this PR and think it's ready for a review now.
I've reverted the initial approach with the _jinja_paths setting and Jinja's PrefixLoader because I dislike that API and don't think it's the right approach. I realized that it is possible to use path separators in templated folder/file names, although it turned out that Jinja requires the POSIX path separator in include/import statements which means _copier_conf.sep cannot be used in templated folder or file names on Windows. So, I've come up with a more flexible and IMO intuitive solution:
Jinja includes/imports are now relative to the template root independent of the include/import target (copier.yml, templated folder name, templated file name, templated text file content) and I think this is the simplest, most flexible, most intuitive, and most robust approach. I was thinking about using relative paths (relative to the include/import target, e.g. relative to copier.yml when it's inside copier.yml, or relative to a folder when it's in a templated folder name, etc.), but I eventually didn't pursue this approach further for two reasons:

I think the main use case is to include/import from a central place rather than from a location relative to the target. Relative paths would make the include/import statements long and difficult to read when moving up several times in the filesystem.
I think the correct relative path might not be obvious when using a generated directory structure where the template contains only one folder that might render to a deeply nested folder, so it might be unclear whether the include/import path is relative to the templated folder name or the rendered (nested) folder.

I'm absolutely open for discussion though because it's an important design decision that will be difficult to change later without introducing a breaking change. WDYT?

I think this PR is ready to be merged now. Two CI jobs are failing because of timeout issues.


Add AMQPS support (TLS) in the CLIENT mode

In the CLIENT mode, when the environment variable AMQP_CERT_DIR / configuration property amqp.certDir is specified, the bridge will open the AMQP connection with SASL EXTERNAL and the TLS certificates from the $AMQP_CERT_DIR path (ca.crt, tls.crt and tls.key).
Additionally run_bridge.sh is now using $MESSAGING_SERVICE_PORT_AMQPS_BROKER for the port where to connect. This is the port where link routing is enabled in EnMasse.

The second part of this change is in EnMasseProject/enmasse#199.


chore(avm): add SET serialize comments and simplify signature

Current dependencies on/for this PR:

master

PR #4476   👈

This stack of pull requests is managed by Graphite.

Benchmark results
Metrics with a significant change:

batch_insert_into_append_only_tree_32_depth_ms (512): 312 (+31%)
batch_insert_into_append_only_tree_32_depth_hash_ms (512): 0.568 (+30%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 545b3341 and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,636
180,516
720,036

l1_rollup_calldata_gas
222,456
870,684
3,464,412

l1_rollup_execution_gas
314,943
988,424
3,684,069

l2_block_processing_time_in_ms
1,240 (+7%)
4,373 (+1%)
17,385 (+1%)

note_successful_decrypting_time_in_ms
303 (-1%)
971 (+1%)
3,707 (+3%)

note_trial_decrypting_time_in_ms
12.6 (-38%)
103 (+11%)
146 (+4%)

l2_block_building_time_in_ms
17,907
70,947 (+1%)
284,283

l2_block_rollup_simulation_time_in_ms
13,077
51,771
207,857

l2_block_public_tx_process_time_in_ms
4,795
19,094 (+1%)
76,168

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
14,753 (-4%)
28,933 (-1%)

note_history_successful_decrypting_time_in_ms
2,323 (-4%)
4,564 (+1%)

note_history_trial_decrypting_time_in_ms
85.5
208 (+3%)

node_database_size_in_bytes
17,285,200
33,034,320

pxe_database_size_in_bytes
29,923
59,478

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
312
44,476
26,153

private-kernel-ordering
198
44,473
16,553

base-rollup
1,401
128,930
881

root-rollup
82.1
4,088
677

private-kernel-inner
444
71,607
26,153

public-kernel-private-input
247
32,563
26,153

public-kernel-non-first-iteration
246
32,605
26,153

merge-rollup
7.65 (+1%)
2,608
881

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
2 leaves
8 leaves
16 leaves
32 leaves
128 leaves
64 leaves
512 leaves
1024 leaves
2048 leaves
8192 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.3 (+1%)
11.0 (+1%)
12.6
17.0
22.8
64.3
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.9
17.5
23.0
31.6
47.0
143
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.597 (+1%)
0.616 (+1%)
0.538
0.528
0.478
0.442
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
N/A
N/A
N/A
74.5
48.2 (+2%)
:warning: 312 (+31%)
460
899
3,564 (+1%)

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
N/A
N/A
N/A
159
96.0
543
1,055
2,079
8,223

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
0.460
0.495 (+1%)
:warning: 0.568 (+30%)
0.431
0.427
0.428

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
N/A
N/A
N/A
104 (+1%)
56.4
352 (+1%)
685
1,370 (+1%)
5,437 (+1%)

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
N/A
N/A
N/A
197
104
691
1,363
2,707
10,771

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
0.494
0.495
0.479 (+1%)
0.472
0.475 (+1%)
0.472

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
56.5
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
94.1
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
0.578
N/A
N/A
N/A
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
17,187
39,991

Transaction processing duration by data writes.

Metric
0 new commitments
1 new commitments

tx_pxe_processing_time_ms
557
1,317

Metric
0 public data writes
1 public data writes

tx_sequencer_processing_time_ms
0.512 (-14%)
590

Merge activity

Feb 7, 12:10 PM EST: @fcarreiro merged this pull request with Graphite.


86 and 64

Are obfuscation techniques different for x86 and x64 files?

Hello! No, they are not different except for the architectural features of the compiler for 32 and 64 bits


Support for indexes on fields of embedded properties type like EMBEDDED/EMBEDDEDLIST/EMBEDDEDMAP/EMBEDDEDSET

I am using OrientDB as a document store and need to query nested fields of a document among millions of records. Hence i needed indexing support on fields inside EMBEDDED object, EMBEDDEDLIST/SET/MAP. I saw the above requirement is labelled with 3.0 milestone - https://github.com/orientechnologies/orientdb/issues/5201 .
I know this feature is in your roadmap but i need it asap. I am waiting on this feature for a customer deployment and it is blocked because of performance issues without indexing.
I have added support for this in my commit. All tests are running fine. Please review it and merge it and make it available in next release asap. I have come a long way in using OrientDB in my project and now i am blocked on a customer deployment due to this.
Please take a look at my UT in orientdb-core - "com.orientechnologies.orient.core.sql.EmbeddedIndexingTest". These are all the scenarios i wanted and with my changes/commit, they are working fine.

Any updates on this PR? I am blocked on this issue for a customer deliverable and getting this merged would be of great help.

The team is getting more time to analyze this because we're under release of v3.0M1. Please give us some more days.

hi @theleapofcode,
This is pretty impressive but anyway it miss some points that is actually the complicate part of the index management, the handling of index changes on update, I got your code and tried it out, it work and is pretty nice.
Anyway changing this snippet:
		Map<String, ODocument> emap1 = new HashMap<String, ODocument>();
		emap1.put("personal", mobile3);
		emap1.put("official", mobile4);
		person1.field("mobilesmap", emap1);
		person1.save();

To:
    Map<String, ODocument> emap1 = new HashMap<String, ODocument>();
    emap1.put("official", mobile4);
    person1.field("mobilesmap", emap1);
    person1.save();

    emap1 = person1.field("mobilesmap");
    emap1.put("personal", mobile3);
    person1.save();

a test failed.
So is so far good, but we cannot include this till the updated is supported, in any case as soon as we start to work on this we can start from this pull request.
if you will to work also in include the support of update we can give you any help/info you need.
I'm aware that this is quite important for you so we will try to push a bit on this as well.
Regards

Hi @tglman ,
Thanks for the review and feedback. I have pushed a fix for properly handling indexes on embedded fields upon updating of records. Also added UTs to check update scenarios for all cases. And the scenario you mentioned in your review is also working. Please review my PR and merge it asap.
Regards,
Dileep

Added a commit for support of lucene index on embedded fields just like others along with UTs. Please review the code and merge asap.

Nice work! If a merge can happen, it would be fantastic, as this is a much needed addition to ODB.
After this, all we then need is automatic class and property creation upon insert and allowing indexing without schema and we are at a true No-SQL solution like Mongo. 😄
Scott

@tglman Please take care of this PR. Thanks @theleapofcode for this.

Hi,
I'm sorry to stop you again, anyway this time I'll try to list all the requirements needed for declare the embedded index supported:
I annotate the cases this pull request support with an (Ok,No,Maybe)

Support of indexing of a plain nested property "a.b.c"  (Ok)
Support of indexing of nested collection "a.b.c" where b is a collection (Ok)
Support of indexing of deep nesting "a.b.c.d.e...." (No)
Support of indexing of  nested collection of collection "a.b.c" where all fields "a","b","c" are embedded collections without document structures in the middle (Maybe).
Support of update of a single or multiple element of a nested structure (Only Some cases)
Support remove of index nested filed (Maybe)
Support remove of index nested filed with a mix of nested collections and document (No)

This are not requirement for OrientDB but from your example you want them inside

Support of index of filtered maps (Ok).
Support of index of filtered collections (is not described in this PR, but for completeness is a requirement) (No)

Anyway you are not too far, all you need to do is support in a better way the events on the nested operations, inside orient we have a tracking structure that let us know what value is actually changed of the document and as well keep track of deleted values for clean up the index, you already manipulated the code that use it : https://github.com/orientechnologies/orientdb/pull/7093/files#diff-221d36d3f64505bf02bf2315fc8570eeR216 but there is not changes that show the support of nesting.
In the specific there is a: https://github.com/orientechnologies/orientdb/blob/develop/core/src/main/java/com/orientechnologies/orient/core/record/impl/ONestedMultiValueChangeEvent.java that keep the changes of a nested collection of a nested collection, and it can have inside eventually a document that has is own tracking that should get out and checked as well.
Another point i see you do most of the tests just on SQL, that is a bit limited use case because it not yet support some way to update  like: ((Map<String,ODocument>) doc.field("map")).get("some").remove("nested_field"), this with the current code is not going to trigger the index because of the missing management for nested events.
So for consider this pull request done and mergiable should support the cases listed before, with arbitrary nesting in both SQL and Java api.
I'm aware you really need this change, but is farly important for us to merge only complete features.
Feel free to ask any question or if you need reach us for help is something is not clear, your work is definitely valuable, we just need to be fineshed up.
Regards

@tglman thanks for the detailed analysis. @theleapofcode this PR is something OrientDB users really wanted and they were waiting for it since long time ago (see @smolinari). Please let us know if you have time to work on it so we can put in the upcoming 3.0M1 next week. Thanks so much.

Thanks @tglman for the detailed analysis.
@lvca I would love to contribute this feature as I and lot of others are waiting for this. But its very hard for me to find time this week as i am neck deep into my project work. Even for this PR, i could somehow squeeze a day worth of time and contribute. But as @tglman pointed, there are lot more analysis and cases i need to add to make it complete and frankly i wont be able to complete it this week.
For my immediate requirement in my project, my fork works fine and i can live with it till its officially added. Also whatever i have done seems to be in the right direction and if you guys can prioritize this feature and build upon my PR and include it in next release, it would be great for me and lot of others.
Let me see if i can squeeze few hours here and there to work on this but i cannot commit dedicated time. Will keep you updated if i find time to work on this. Hope you can understand. Looking forward to release of this feature asap.
Regards,
Dileep

Hi guys, any news on this? I see users demand this feature. Look at: https://groups.google.com/d/msg/orient-database/wVUXCuzdVeY/quQ9SI8zBQAJ

Hi @lvca,
I have not yet worked on this. And to be frank will not be able to work on this anytime soon.. Busy with lot of work on my project and other stuff. If you guys can prioritize this requirement and add it in your upcoming release, it would be great. Will keep you updated in case i do work on this if time permits.
Regards,
Dileep


Issue trying to run XML transformation

Running an xml transformation on an Appsettings key. Is there a problem including the ' character? I'm using the snippet i found on the github xml section. Getting the following issue below:
Transformation found: configuration/appsettings/add[@key='ida:KeyName']/@value: https://websitedomain.onmicrosoft.com/siteName
Transformation found: configuration/appsettings/add[@key='KeyName2']/@value: http://siteName.azurewebsites.net/
Transforming file E:\Work\24\s\AppName\App.config
System.Management.Automation.MethodInvocationException: Exception calling "Transform" with "4" argument(s): "The ''' character, hexadecimal value 0x27, cannot be included in a name." ---> System.Xml.XmlException: The ''' character, hexadecimal value 0x27, cannot be included in a name.

It looks like this was throwing the error due to the : in the key name. Probably can be resolved by fixing that issue.


Support for multiple schema directories?

Is it possible, and if not, is there any interest in allowing the CLI to support multiple --schema-dir flags?
For example:
pg-schema-diff plan --dsn "..." --schema-dir ./sql/init/ --schema-dir ./sql/feature/commenting/

This would take all of the .sql files in ./sql/init/ and all of the .sql files in ./sql/feature/commenting/ and read them in to one DDLSchemaSource (and then continue to generate a diff/plan as currently implemented).
Obviously with this example we could just use a single --schema-dir flag and pass the top-level ./sql/ directory to it; however, my usecase is twofold:

The ./sql/features/ directory has hundreds of subdirectories (with hundreds of .sql files) and our tooling allows us to know which subdirectory needs to have its .sql files diffed and applied which would improve overall performance (and minimize potential errors with unrelated .sql files)
When building our base postgres docker image (which is based off of supabase/postgres) for QA/perf testing, we need to point to their initial set of .sql files and our main ./sql/ directory. Since there is no shared, top-level directory then we need to copy one of the directories over during the build. Having support for multiple --schema-dir flags would simplify this process.

If there's interest in supporting this, then I'm happy to take a crack at sending a PR; however, I have very limited Go experience and I'm more than fine if someone else wants to jump on this :)

I think your use case makes sense, and we can implement it as a feature. I --might-- not consider implementing it if it added significant complexity to the CLI, but this is really a matter of just adding a for loop.
It might even make sense to support globs in the future.

Implemented! 🎉
My previous response wasn't a critique of your idea by the way -- I realize it kind of read like that! It's a good idea! It's more just commenting on the general philosophy of reducing scope of the library to minimize the amount of code that needs to be maintained.


Extract error when scanning datasets - Couldn't find any dimension coordinates

dachar version:
Python version:
Operating System:

Description
Could not find any dimension coordinates to use to order the datasets for concatenation

This only occurs for one dataset:
/group_workspaces/jasmin2/cp4cds1/vol1/data/c3s-cmip5/output1/ICHEC/EC-EARTH/historical/fx/atmos/fx/r0i0p0/areacella/v20130211/*.nc
This is because the netcdf files for different experiments (historical, rcp26, rcp45, rcp85) are all in the same directory. There should only be the file for the historical experiment here.

Passed this on to Ruth who says 'we don't seem to supply the CDS with areacella which is odd in itself, but means that this directory could be deleted reconfigured and no issue.'


[Snyk] Security upgrade python from 3.9-slim to 3.13.0b3-slim

This PR was automatically created by Snyk using the credentials of a real user.![snyk-top-banner](https://github.com/andygongea/OWASP-Benchmark/assets/818805/c518c423-16fe-447e-b67f-ad5a49b5d123)
Snyk has created this PR to fix 5 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

cmd/suggestion/nas/darts/v1beta1/Dockerfile

We recommend upgrading to python:3.13.0b3-slim, as this image has only 43 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Integer Overflow or Wraparound SNYK-DEBIAN12-ZLIB-6008963
  500

Integer Overflow or Wraparound SNYK-DEBIAN12-KRB5-1549480
  150

CVE-2024-26462 SNYK-DEBIAN12-KRB5-6277421
  150

Access Restriction Bypass SNYK-DEBIAN12-SHADOW-1559391
  150

Incorrect Permission Assignment for Critical Resource SNYK-DEBIAN12-SHADOW-1559403
  150

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
3120

Relevant Lines:
4270

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
3120

Relevant Lines:
4270

💛  - Coveralls


Kick off

First time trying to add npm package.
Here is how to do so: https://bugfender.com/blog/how-to-create-an-npm-package/
What I need to test it:

report from Cypress, positive and negative

How to add custom argvs: https://nodejs.org/en/knowledge/command-line/how-to-parse-command-line-arguments/

Description of the json and what we need from it"
- jsonObj.stats - stats about whole run
   - jsonObj.stats.suits = how many test suits (files)
   - jsonObj.stats.tests = how many tests run in process (it)
   - jsonObj.stats.passes = how many tests passes
   - jsonObj.stats.failures = how many tests failed
   - jsonObj.stats.pending = how many tests are pending
   - jsonObj.stats.skipped = how many tests were skipped (I think it's broken and it's using pending as skipped)
   - duration = in miliseconds

- `jsonObj.results`
- suites = how many "descriptions" it has
- suites.tests = what tests are in (they have UUID!)
- suites.failures = what tests failed, we can search through them by UUID for path
- suites.pending = what tests are waiting/are skipped


Can we find ip data from this?

hello eflyjason
is it possible to get ip-address data from this script?
example: http://who.is/whois-ip/ip-address/<IP_ADDRESS>

it is possible by speedywhois.com
visit there..
On Fri, Sep 4, 2015 at 6:05 PM, jackchurchill85<EMAIL_ADDRESS>wrote:

hello eflyjason
is it possible to get ip-address data from this script?
example: http://who.is/whois-ip/ip-address/<IP_ADDRESS>
—
Reply to this email directly or view it on GitHub
https://github.com/eflyjason/php-simple-whois-parser/issues/2.

i will add this as feature of next version. wait please! :)

okay thanks :)


Implement operator + for Series

With HPAT_CONFIG_PIPELINE_HPAT=0 the old test hpat.tests.test_series.TestSeries.test_series_sum2 do not work:
No definition for lowering <built-in function add>(series(float64, array(float64, 1d, C), none, False), series(float64, array(float64, 1d, C), none, False)) -> series(float64, array(float64, 1d, C), none, False)

File "hpat\tests\test_series.py", line 859:
        def test_impl(S):
            return (S + S).sum()
            ^

[1] During: lowering "$0.3 = S + S" at c:\Users\spokhode\Documents\hpat-workspace\hpat\hpat\tests\test_series.py (859)

As I can understand add operator for Series is not implemented yet.
Originally posted by @PokhodenkoSA in https://github.com/IntelPython/hpat/pull/203#issuecomment-539889035

@PokhodenkoSA Can we close this (as it should work already)?

Sure.


MINOR: Fix flaky shouldCreateTopicWhenTopicLeaderNotAvailableAndThenTopicNotFound

This test is taking two iterations since the firs iteration is designed to fail due to unknow topic leader. However both the timeout and the backoff are set to 50ms, while the actual SYSTEM time is used. This means we are likely to timeout before executing the second iteration. I thought about using a mock time but dropped that idea as it may forgo the purpose of this test, instead I set the backoff time to 10ms so that we are almost unlikely to hit this error anymore.

Found a minor issue while fixing this which is that when we have non-empty not-ready topics, but the topics-to-create is empty (which is possible as the test shouldCreateTopicWhenTopicLeaderNotAvailableAndThenTopicNotFound itself illustrates), we still call an empty create-topic function. Though it does not incur any round-trip it would still waste some cycles, so I branched it off and hence also simplified some unit tests.

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

ping @cadonna for reviews.


Add support for performing module-specified namespace or system configuration at installation/load time

Per conversations with HSOPS, we'd like to ask for support of pre-packaged installation-time configuration of a module as part of the install/load command (or another command that also encompasses installation/loading). In particular, we imagine modules that contain a CPF file that is identified either by its name or file path would be iris merged programmatically before the Reload lifecycle phase.
This feature would not include user-specific installation-time configuration. That is a separate issue.

Spec:
You can put a CPF file path in module.xml as a resource (you can have more than one)
We'll add a pre-reload lifecycle phase (named "Initialize") and hook into that from the CPF file's resource processor class - default behavior is to do the CPF merge during Initialize, but a resource attribute can be overridden to do this later instead (in a named phase)
Sets of configuration:
Creating namespace + database(s) into which module will be installed (covered in #629)
Module-specific configuration (mappings, creating roles/resources, granting SQL privileges - covered here)
User-specified configuration (OAuth config, UM integration config - equivalent to an "env" file for docker run; this is covered in #632)
Orchestrate this across multiple namespaces: #630


Expose current routes context pathname as useRoutesPath()

There should be a way to get current routes context pathname.
Equal is done as useOutlet() for outlet and  useParams() for params
This change adds useRoutesPath() and Returns the pathname element under current router context...

The naming should be consistent and useRoutePathname is probably a more descriptive name.

The naming should be consistent and useRoutePathname is probably a more descriptive name.

Yes sounds better..  All build is ok just final cross-package exports fails do you know what is that ?
I think it is some compare if all exports are in booth packages react-router and react-router-dom but not sure about this check on end on all test what is idea behind it..
 FAIL  packages/react-router-native/__tests__/exports-test.js

Yes sounds better..  All build is ok just final cross-package exports fails do you know what is that ?
I think it is some compare if all exports are in booth packages react-router and react-router-dom but not sure about this check on end on all test what is idea behind it..
 FAIL  packages/react-router-native/__tests__/exports-test.js

I fixed missing reexports for useRoutePathname and build is ok now...

I fixed missing reexports for useRoutePathname and build is ok now...

Thanks for the PR @damikun. What is your use case? We are not likely to merge new API unless we understand where our current API falls short.

Hi @mjackson its been while since I create it :)  but I think it was explained in this post: https://github.com/remix-run/react-router/issues/7735

@mjackson @damikun
Can the pathname not get it's own context? Currently the useNavigate hook for example needs the pathname too and rerenders every time you change anything. That would be really nice and save much rerenderers.

useResolvedPath(".").pathname


[#120268519] Add gorouter latency monitor to datadog

What
This sets up a gorouter datadog monitor with a warning threshold of
400ms and a critical threshold set at 800ms. These values have been
derived from reviewing the data held in datadog for the past month. If
we had them implemented during the load testing session then they would
have fired.
How to review
Deploy from this branch with ENABLE_DATADOG=true and check the monitors for your deployment in datadog.
Who can review
Not @LeePorte

This appears to work well under the somewhat contrived test conditions that I set up:

Deploy
bosh ssh to each router and monit stop gorouter
DataDog monitor is triggered

There is another monitor for gorouter not running. you might be better off hitting the healthcheck app with vagetta.

@LeePorte hit it with my what now? Did I miss something?

https://github.com/tsenart/vegeta


customEntityTransform not applied in list items because of wrong Param in getListMarkup

Hi,
there is a bug in the code in index.js:
 const listHtml = getListMarkup(           listBlocks,           entityMap,           hashtagConfig,           customEntityTransform         );
Should inlcude the directional paramater:
 const listHtml = getListMarkup(           listBlocks,           entityMap,           hashtagConfig, directional,           customEntityTransform         );
The missing paramater blocks entity rendering in list items.

I don't think you need a pull request for such a small change.
Commit is here in my fork:
https://github.com/teknologist/draftjs-to-html/commit/1824c62bf42ffdfd5fdbb75e8299685dfb93ac23

Hey @teknologist: can you plz create PR for this.

Closed by this pr: https://github.com/jpuri/draftjs-to-html/pull/11
Upgrade will be released soon.


vcs branch returns different information for each vcs

git shows all branches
hg and bzr show the current branch
svn shows the url suffix behind the root url

Since all vcs only support showing the current branch that will be the default. An option --all will allow to list all branches for the vcs which support that (git and hg).


Use upstream glutin

This change is

@bors-servo delegate+
r=me

:v: @paulrouget can now approve this pull request

:pushpin: Commit b9d6b93 has been approved by paulrouget

@bors-servo r+

:hourglass: Testing commit b9d6b938a0164c7f061b20d1fcf45f57f8d26325 with merge 1946b14560501e99e6745be20bf9d54b8d23c522...

:sunny: Test successful - status-travis
Approved by: paulrouget
Pushing 1946b14560501e99e6745be20bf9d54b8d23c522 to master...


Place layer missing expected boundary records

Details
Follows #228, the place layer should have included the boundary=postal_code records.  This simplifies logic to allow them to load.

Remove unnecessary if statement that excluded expected place records
Add test .osm.pbf file with data including boundary=postal_code
Make building exclusion less specific (Simplifies #228)

Included test file includes relation mentioned in #227 reporting the original issue.
https://www.openstreetmap.org/relation/1405640#map=15/52.5511/13.3320
SELECT *
    FROM osm.building_polygon bp
    WHERE osm_id = -1405640
    ;

SELECT *
    FROM osm.place_polygon bp
    WHERE osm_id = -1405640
    ;

Screenshot from DBeaver showing the record from osm.place_polygon including member_ids.


Irresponsive Edit Menu Options

Meaningless Cut, Copy option when no text is selected
Meaningless Paste option when the clipboard is empty

Undo and redo are now responsive since v0.0.7 - 153b2a49755cc9850561b05ce2c6bbf03af9a24a

Cut, Copy, Paste, Show Clipboard, Erase Clipboard options are also reposnive now -  e346566f372518f7fed4edd9321fb62f5b7a04e1
Will be available from next release

Update released


Spinning loading indicator

While this is happening, clicking on any item to expand it doesn't work.  I wonder if #3 would help here 🤔
This occurs on window reload, and does eventually resolve, but takes nearly a minute

is this a repo that I could have a look at by any chance?

so this very long loading time only happens on startup and afterwards it doesn't?

could you check whether this still occurs on version 0.5.6 that I just released? turns out the library I was using did a lot of unnecessary file watches on startup that I have now removed.

Repo was https://github.com/cursorless-dev/cursorless.  But I just checked in 0.5.6 and it's now working great!


throwing in a map function should be caught by valita and treated as an error

Consider:
v.unknown().map(u => {throw new Error('oops')}).try(1);

Currently the exception bubbles through, but it should be caught by map and wrapped into the ValitaError

A solution is to create a utility function that does it
const vCatch = <I,O>(fn: (i:I)=>O) => (i: I) => {
    try {return v.ok(fn(i));}
    catch (e) {return v.err(`Captured Error: ${e.toString()}`);}
};

v.string().chain(vCatch(s => readFileSync(s)));

would you consider adding a chainEx function which expects the next value or an Exception so we can indicate 'explicitly' that this exception should be caught?
v.string().chainEx(s => fs.readFileSync(s))


Creating an object from another object's properties loses type definitions

I create an object of methods - methodsObj, then use the object's properties to create a new object (via simple assignment) - otherMethodsObj. Using typeof on the otherMethodsObj object loses the types of the original methods (flow.org working example):
const method1 = (d: number): void => {};
const method2 = (d: string): void => {};

const methodsObj = {
  method1,
  method2,
};

const otherMethodsObj = {
  method1: methodsObj.method1,
  method2: methodsObj.method2,
};

const nextMethods: typeof otherMethodsObj = {
  method1: (l: boolean): void => {}, // should be "boolean is incompatible with number"
  method2: (l: string): void => {},
  c: true
}

This bug is here for quite some time now, and I've encountered it in several places. :/
from: https://github.com/facebook/flow/issues/4770
🔴 "No errors" (but there is)
https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCiAHgIYC2OMBAvGAN4DaA1nlgFwB2AruQEZ4ATgF0w7AM4ZBAS04BzAL6pqGMMTFEylamDr1UYQ2EYBmE8PZgzAGlRKgA
type Example = {[key:number] :string}
let x : Example = {
    [33]: 33,
}

🍏 "errors !" (as it should)
https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgCiAHgIYC2OMBAvGAN4DaA1nlgFwB2AruQEZ4ATgF0w7AM4ZBAS04BzAL6pqGMMTFEylamDr0lxRgGYjouiaA
type Example = {[key:number] :string}
let x : Example = {}
x[33] = 33


Go into more details on how you can cluster scope.

A diagram would be nice.  And what to debug if clustering is not working.

We should describe:

the app/probe architecture, what each bit does, and how they find each other
what this means when running against the hosted apps


GLM Update

Integrated Dan's GLM tools and Predictors data for US States

Basic GLM integration finished, using DB supplied Predictors for US States only.
Next PR will allow user submitted Predictors.


Use a plus sign on layer title

We should use a plus sign on layer title on sidebar right to show that it is an expandable item.

We should get rid of the three vertical dots on the left, or the arrow on the right?


Tests/modit

Refactoring of DIT/MODIT done
Changes:

I adopted DIT/MODIT with the pre-computation of the contribution and index for wavenumber to a default because I found it was more accurate and as much as fast (slightly faster). The 3D cases are moved to experimental/ditfnu.py and  experimental/moditfnu.py for future dev.
now we have three methods for opacity computation (LPF/DIT/MODIT). Each scheme needs some initialization prior to opacity computation. For LPF, we need to make nu matrix (make_numatrix0), for DIT/MODIT we need to precompute contribution and indexing of wavenumber to the lineshape density matrix. I made a common module for these purposes: spec.initspec. make_numatrix0 is duplicated but decided not to remove.

Also, I compared LPF and MODIT for CO cross section similar to a comparison of Fig 3. in the paper.

Run tests/comparison/modit_CO.py to reproduce this result.

self merge.


Rewrite to ES6

It would involve new code layout and some time so new branch for this task should be created in main repo.
#80

using Browserify was mentioned by @danprince

I can split client code into something like that:

Player module for Player class and CurrentPlayer class which extends Player class to add input handling
PlayerList module for PlayerList class which has lists of all players
maybe also similar class for food

I would recommend breaking it up into:

Rendering module
Game/State module
Chat module
Events module

Rendering module is completely independent of state, just needs to know about what should be on screen at a given point.
Game/State module keeps track of data that has arrived from the socket in the events module as well as passing mouse/keyboard inputs to the server (through the events module).
Chat module just handles rendering chat messages and passing input to and from the events module.
Events module is the wrapper for all of the socket stuff. Everything else hooks into here.
Quite happy to do any of the above and pretty comfortable with ES6 too.

@danprince Your way looks better than mine I'm with you :+1:

Cool, happy to get this underway then. @huytd Any chance I could be added as a collaborator to get things kicked off?

Initial feelings on this as a style?
https://github.com/danprince/agar.io-clone/blob/es6/client/js/render.js

@danprince  Bowserify is laying in es6-refactor branch so you can pull if you want, and the code looks quite nice. :+1:

Cool, nearly finished modularising + ES6ing all of the client side.

Removing help wanted tag since there's already people working on that :)

Hi, what is left to do on this branch? I did a quick test and it seemed to be working pretty good except for a bug parsing chat commands.

Discussion continued with PR #128

So are people still up for this? the es6-refactor branch looks incredibly outdated at the moment.

yeah, if anyone is willing to dedicate some time to it. It would be nice.

The day has come! I have completely refactored the site to use es6.
https://github.com/underGhost/agar.io-clone/tree/es6-refactor
What did you do?

Took the guts of the current site and converted to es6.
Refactored the code and removed 99% of linter errors (there was a lot of hoisting and methods called before being declared).

What came of it?

Cleaner code
Easier maintainability
Pretty es6 things
Helped with the games latency

What is still needed:

Testing - I have tested pretty much everything except player consumption.
Build System - I need to refactor the site to build server side.

Contributors

Need help with the thinks listed above.
If you contribute I recommend using Atom if you're not already. I use the following packages to help with linting:

language-babel, linter, linter-eslint

Please let feel free to contribute in any way and pull it down to give it a test!

Wow! Awesome man! :+1:
Since we use ES6, how about using template string?
https://github.com/underGhost/agar.io-clone/blob/es6-refactor/server/index.js#L63

Thanks! I'll be sure to update all of them :+1:

Updated the strings to template strings @huytd

Great! Do you want to make a pull request to es6-refactor branch of this repo?

@underGhost That looks awesome! Great job :smile:

Thank you!


Erroneous negative IOB calculated when basal schedule rises >2x

@iainct reports at https://github.com/openaps/openaps/issues/88#issuecomment-204859700 that oref0 erroneously calculated a negative IOB based on a basal_profile.json that increases from 0.2 U/hr to 1.4 U/hr over the course of 60 minutes:
{ "i": 17, "start": "17:00:00", "rate": 0.2, "minutes": 1020 },
{ "i": 18, "start": "18:00:00", "rate": 0.8, "minutes": 1080 },
{ "i": 19, "start": "19:00:00", "rate": 1.4, "minutes": 1140 }

As oref0 currently calculates IOB based on the assumption that the currently scheduled basal profile is "close enough" to use for the last DIA hours' worth of pumphistory, this kind of basal profile is dangerous to use with oref0.
For now, we should detect when ( max_daily_basal / min_daily_basal ) > 3, and error out in that case.  In the long term, we should probably make oref0-calculate-iob smarter about using the basal scheduled at the time of each entry in pumphistory to calculate IOB as well.  I suspect we might want to keep the max/min > 3 check in place even after doing that, though.

Coded up the 3x limit.  Can I get some feedback on whether to merge #96 to dev as a fix for this?

You may want to consider using mmhistorytools to normalize temp basals (and suspends) against a basal schedule. It makes no estimations or assumptions about rates staying similar.

This just hit the top of my "stuff to look at" list. Using this issue to track discussion about the best way of integrating mmhistorytools.

Any reason why we can't use the iob report from the last loop run as a starting point for the iob calculation? Then we only need to assume that the current basal profile is "close enough" for the time since last run, not over the whole DIA.  Would also degrade nicely to current behaviour in the event of a break in looping. Sounds like mmhistorytools is the best solution going forward, but something like this might work in the meantime?
It means we're storing some state in the openaps implementation, which might be dangerous? Is it a deliberate design to not do this?

Yes, we made a design decision to avoid relying on oref0 keeping any state. In addition to simplifying things generally, that means that we can have multiple rigs running oref0, and if one of them comes into range, it only needs to pick up the latest pumphistory and current temp to get up to speed. After that, all the rigs perform the same deterministic calculations and come to the same conclusion given the same inputs.

OK, that makes sense. Thanks. Back to using pump history for the full DIA then.

I've got a rig working with pump-history-prepared.json as the output of the mmhistorytools prepare command. Naturally I've had to modify oref0/lib/iob to accept the normalized pump history. Just wondering is it best to assume that some people will update oref0 but won't add the mmhistorytools device? Should the iob process include a switch for the type of history input, or is it OK to require users to update their reports?

Nice!  Good progress.
We'll need to figure out some way to ensure backwards compatibility.  If we want to deprecate the old data format, we can add a deprecation warning, but for now we'll have to be able to parse both formats.  Ideally we could autodetect which they're using, and act accordingly, but if that's not possible then we'll need to add a switch that defaults to the old behavior.

The old format uses "_type" while the new format uses "type" so we could use the existence of the "_type" key to switch to the old behaviour. Is that robust enough?

Rather than adding something subtle like that, I'd add an extra field that makes it really obvious what is going on.

Do we have that option?  If adding a field would require modifying mmhistorytools, perhaps just keying off the name of the type field would be sufficient...

Not tested, but something like this as part of an openAPS alias:
cat mm_tools_output.json | json -E "this.mmTools = true" > mm_tools_output_marked.json

That could work. There's another subtle issue - mmhistorytools doesn't have a field for percent type basal and oref0 doesn't include percent basals in iob. There is a human-readable description string, and we could look for a '%' character in this - but there's no guarantee that that description string won't change. Worth a PR to include a basal type field?

The normalize command (which is the last step in the prepare shortcut command) converts percent-based temp basals to absolute (U/hour) in all cases.

On Aug 22, 2016, at 6:44 PM, Paul Dickens<EMAIL_ADDRESS>wrote:
That could work. There's another subtle issue - mmhistorytools doesn't have a field for percent type basal and oref0 doesn't include percent basals in iob. There is a human-readable description string, and we could look for a '%' character in this - but there's no guarantee that that description string won't change. Worth a PR to include a basal type field?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Whoa, only just noticed this; we have three >2x basal changes during the day in the current profile. @thebookins is the commit with the change public?

Just to note that this is more of an issue with increasing basal doses (which will calculate negative IOB when it shouldn't) than decreasing basal doses (which will calculate positive IOB when it shouldn't).

Noted! Guess the changes is this one: https://github.com/openaps/oref0/compare/dev...thebookins:wip/basal-aware-iob ? The IOB test doesn't pass on the committed code.

Ah right, figured why the test wasn't working - our code now assumes the profile contains the default variables, so bolussnooze_dia_divisor: 2 missing from the test caused the bolus snooze IOB to be miscalculated. We should change the tests to use the full profile object; the current method of passing in a profile that's missing variables that are actually passed in when the loop runs can cause the tests to not actually test the real loop behavior.

@sulkaharo yes that's the branch. I'll tidy up tonight and implement the mmTools switch. The tests also need to be rewritten: the history object in the iob tests will be different depending on the value of mmTools.
@loudnate thanks for the clarification. How would you suggest excluding percent basals in the iob calculation? What about something like an optional argument --exclude-percent-basals for the normalize command?

@thebookins I think the point of loudnate's comment was that mmhistorytools works out what the effective basal rate was in U/hr given the current basal rate and the percentage. This means that data leaving the tool all looks like it was generated on a U/hr basal rate.

@cjo20 That's fine, and we could certainly calculate iob using the normalized output, but I was thinking we should match the current behaviour, which is to ignore percent-based temp basals (presumably because if there is one in the history it's a genuine - albeit temporary - basal rate change, and not an action of oref0).

No; if that is the current behavior, it is entirely a side effect of not supporting percent basals at all. If you set the pump to percent basal mode, it totally disables OpenAPS, which will fail to set (absolute) temps until it is corrected.
I think we should calculate IOB based on the normalized output for simplicity.

https://github.com/openaps/oref0/compare/dev...sulkaharo:wip/accoutforbasalprofile now contains an alternate implementation that doesn't require mmhistorytools. (One less component to worry about.)

https://github.com/openaps/oref0/compare/dev...thebookins:wip/basal-aware-iob2 is an attempt at allowing for mmhistorytools prepared data, and also defaulting to the current behaviour. Currently planning to use an optional argument in oref0-calculate-iob.js to switch between the two data sources. I'll remove the percent basal check (thanks @scottleibrand and @cjo20 and also plan to add tests for square wave boluses and suspend/resume.
@sulkaharo nice! Do you think the overhead of adding mmhistory tools outweighs its advantages?

@sulkaharo One advantage of mmhistorytools is that it does additional cleaning up of the pump history (such as bolus wizard de-duplication)

mmhistorytools also adds synthetic temp basal to zero records during pump suspends, so IOB would still be accurate afterward even if you don't temp to zero manually.

I think the only argument for not using mmhistorytools is that it's yet another component to the system, which needs maintaining. It's also implemented in Python while rest of oref0 is in Javascript / shell, so this would (correct me if I'm wrong) be the first dependency that'd change it so oref0 is not self-contained in being able to read raw device data and then act on it. Would the module be rolled in as part of oref0 repo? @loudnate opinions? You seem to be shifting focus to Loop. Me and @jasoncalabrese have also discussed for a long time that we should refactor the codebase a little so we could directly share code between Nightscout and oref0 and this would potentially make this harder. So it's really just a question of maintenance and the future development of the codebase.

I'm not sure the distinction between oref0 and not-oref0 is that important. Why would it be critical that someone should be able to pull/process device data without using anything at all other than the oref0 repo? We already have to pull code from several repos to get the system up and running (openaps, oref0, openaps-contrib, decocare), I don't see one more being an issue.

IMHO I like the modularity that mmhistorytools allows, and the output is generic so you could imagine an equivalent historytools implementation for other pumps and this makes oref0 more device agnostic. The iob process then becomes simpler as it's not mixing up history parsing and iob tracking. I'm a newbie to this discussion though and not sure about the Javascript / Python issue. Glad for the discussion as we're keen to avoid the iob errors overnight.

Also since we know that the current behaviour of oref0 isn't correct the best way to fix it for all users is to fix oref0.  Then when they update it will be more correct without having to reconfigure their loop.
If we go the mmhistorytools route it shouldn't be an option, we should rip out the current implementation and force everyone to switch to the new way, but thats really disruptive.
I hope I'm wrong, but it's my assumption that the python projects will see less maintenance going forward.

Not implementing this change because the tool might be less well maintained going forward isn't a great idea. The nature of this change means it is predominantly an extra pass on the input data; it can be reimplemented at a later date in javascript if that is what someone wants to do. At that point, people can switch over to the oref0 implementation easily.
Not breaking backwards compatibility seems to be a goal for the project; previous features have been tested to ensure that people weren't left with broken loops when they upgrade. To fit with the UX of the project, the new features will probably have to be separate oref0 commands, which will involve people changing their openaps.ini.
It might be worthwhile giving people a fixed switchover date; give log messages / notifications that people are using a deprecated method which will be going away in a future release. Then when enough time has been given, strip out the old method.

Regarding data formats going forward: Nightscout currently expects the data in a format that's based on a slightly cleaned up log of MedTronic -style events; anyone adopting mmhistorytools will also need to go on passing the old format logs around for Nightscout visualization. Ideal case would be we could get to a place where our data is as device independent as possible and visualization friendly; what's the best way forward for that? The mmhistorytools data cleaning is great for IOB calculation but potentially not great for visualization (given it hides the original actions of the pump).
Not breaking loops sounds like a good goal to me - there's been a couple changes where the loop behavior changed slightly with an update and a new config file was expected, but this was not obvious by reading the logs when running the loop. And how to fix breaking changes has definitely not been obvious in the errors.
Re: dependencies - we should consider importing the dependencies into the main repo, so 1) it can be guaranteed that dependencies are available if the repo is available, and 2) the exact version we expect of each dependency can be tested. Same goes for Nightscout btw, where we've had issues with dependencies on deploys. The left-pad debacle was kind of eye-opening in this regard.

Hey mmhistorytools usage question: what's the right way to do time zone processing with the tools in the pipeline? I'm currently adding the time zone information to the logs, but looks like if I do this with the log processed with mmhistorytools, the IOB calculation fails (shows 0 IOB at all times).

@sulkaharo With https://github.com/openaps/oref0/compare/dev...thebookins:wip/basal-aware-iob2 I'm doing something like this:

Add a report to run the history tool over the raw pump data:  $ openaps report add raw-pump/pump-history-prepared.json JSON history prepare raw-pump/pump-history-raw.json --basal-profile raw-pump/selected-basal-profile.json

Change the report monitor/pump-history.json to take the output of step 1 as input (or create a new report using the tz device).
Add remainder = --prepared to the report oref0-monitor/iob.json

Doing this I get the expected IOB.

So hey plan for immediate future: I'll PR the change that fixes the negative basal issue and basal rate issues in, while we look at all the work needed to get the mmhistorytools version in (as that requires writing instructions on needed changes to the loop setup). My patch doesn't require any changes to config.

Might be worth documenting that it requires lodash to be installed.

lodash is in the dependencies list in package.json; as far as I know there's no way to install oref0 without npm auto-installing the dependencies?

I just pull the head of the code to my repo on my rig and it seems to pick up the updated code, without having to re-run npm install, hence not automatically pulling lodash.

Right, guess you've used npm link to install oref0? Using the recommended npm install -g . to install from source copies the code to /usr/lib/node_modules/oref0/ and ensures the dependencies are installed, as well as ensuring that pulling a new version will need to be installed before it's actually taken into use.

The easy way to get the global install and npm link setup is to use the little npm script I added a little while ago.
npm run global-install
You only need to do that when there are new dependencies or new oref0 tools.

Did a quick experiment to compare the mmhistorytools and oref0 solution to this issue using a 12-hour pump history (see pic below). The basal iob is not the same for the two methods if some of the temp basal periods cross basal profile boundaries. Ideally in this situation we should split the temp basal into two (or more) normalized basals. (I think mmhistorytools does something like this.) It might be possible look up the basal profile for each synthetic micro bolus and then adjust the microbolus size up or down, but this could get messy.

Nice analysis @thebookins.  I agree that would be ideal, and that's one of the reasons I'd like to support mmhistorytools.  But as your data shows, the IOB calculations are pretty darn close between the red and green, so I'm happy to :shipit: as-is and allow people to use mmhistorytools if they want the more precise IOB.

Good plan @scottleibrand. I'm happy to have a go at writing the instructions to include mmhistorytools in the config if that would be useful. Any immediate plans to import mmhistorytools into the main repo?

Happy to merge mmhistorytools support if it's done using additional config and fully backwards compatible with existing setups and @sulkaharo's fix.

It is backwards compat... it'd be simpler to use mmhistorytools all the time.  The recipes/templates all work, and it's installable via pip so it all works the same way.

Here's some example output using mmhistorytools and other stuff in tandem with getting it into NS: https://github.com/bewest/openaps-example/blob/master/effects/cumulative-results.json

@thebookins that's an awesome analysis? Did you implement a tool to run that? Can you run the same against https://github.com/sulkaharo/oref0/tree/wip/split-temp-basals which implements splitting the temps the same manner as mmhistorytool, so the IOB should align much closer

Hey @sulkaharo, no problem. I ran the analysis again, this time against your branch wip/split-temp-basals (the red 'oref0' line in the graph). Looks different but still not the same as mmhistorytools, unless I did something wrong.

Any chance you could share the method for generating those images? It'd probably be a useful tool to have for future development.

@cjo20, @sulkaharo I've added my scripts for generating the above analyses at https://github.com/openaps/oref0/compare/dev...thebookins:wip/experiments. It's not an automatic tool yet, just a node and a python script that require some manual changes to generate the graphs. Note that to run against the mmistorytools method in https://github.com/openaps/oref0/compare/dev...thebookins:wip/basal-aware-iob2 you will need to set the boolean prepared in experiment.js to true. Hope it's useful.

Found a bug with the help of the new test data; rewrote the splitter logic and pushed.
When I run the plotter, it processes data for some time and then spits out:
Traceback (most recent call last):
  File "plot.py", line 53, in <module>
    main()
  File "plot.py", line 24, in main
    starttime = datetime.strptime(data_original[0]["t"], '%I:%M:%S %p')
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_strptime.py", line 325, in _strptime
    (data_string, format))
ValueError: time data '11:00:00' does not match format '%I:%M:%S %p'

Any idea what might be going on? Wonder if this is a locale difference in how the experiment.js output works?

Sounds like it's a timezone issue for sure. Your error message says 'time data 11:00:00 does not match...' I expect the tool to cover 18:00:00 to 06:00:00. I'm at +10, you're at +3 hence the 7 hour difference between 18:00:00 and 11:00:00. I did wonder if that would be a problem :smile:. I will have a look tonight and see if I can figure it out.

@sulkaharo I have made a minor change to the python script to hard code the starting time (it's an arbitrary time scale anyway). I think the toLocaleTimeString() function is behaving differently (12-hour vs 24-hour time). Probably simplest to just ignore the timestamp for the moment.

@thebookins can you also commit the mmhistorytools branch json output? I still have issues getting the branch going but would love to compare the outputs

@sulkaharo I have committed the three output files (original, mmhistorytools, oref0). The plot.py script should work against this output now.

Hi All,
I'm trying to understand the properties of the IOB object netbasalinsulin and hightempinsulin. They don't appear to be used in any downstream code (e.g. determine-basal). I also don't get why you'd want to keep track of undecayed basal insulin for the last DIA hours. Is this just legacy code? OK to remove in the mmhistorytools branch?

Yes, that is legacy from the old way of doing meal assist. Advanced meal assist doesn't use them any longer. I was going to remove them after we release AMA to master, but you're welcome to do so in any branch that isn't going to be released soon.

@thebookins awesome, the plot now aligns correctly and as expected, split-temp-basals pretty much matches the mmhistorytools output. Looks to me like there's a 0.05 unit difference in the early plot (split branch adding one extra microbolus for some reason) and the latter curve matches exactly.

@sulkaharo great work! Nice to have this issue fixed. I'm still working on the alternate setup using mmhistorytools - I'll make sure it merges with yours and then put it out there for feedback. We use square boluses a bit and it would be nice to have them considered too.

The branch is now merged as #202, so just merge with dev. We're still missing support for pump suspends, so that needs adding.
Re: square waves - we used those before looping but the loop should remove the need to use and the square prevents the loop from working when the square is taking effect. Can you describe how you're using them, so we can take those use cases better into account. :)

Cool, I'll merge with dev then.
Re square waves: we've only been looping overnight for a few months now and don't have a mobile rig yet, so the loop isn't running at dinner, when our son tends to need a dual wave delivery to avoid going low later (we have played with basal rates but the dual tends to work best).
The square wave appears in the pump history shortly after starting it, with the amount equal to the insulin delivered up until that point. Then when the square is finished the amount field is updated to the total delivered. Unless I'm mistaken, that whole amount is added to IOB and decayed using the timestamp at the start, so the IOB will be underestimated for a bit after the square is finished.

Did this end up getting merged?

I have an alternate setup using mmhistorytools ready to go, but there was some concern about adding in another dependency. I can submit the PR if there is still interest. mmhistorytools should handle square waves and pump suspend/resumes.

If we can figure out how to integrate it into oref0-setup so it gets all set up from scratch without any extra work on the user's part, I think that would address most of that concern.  Are you (or is anyone else in this thread) interested in doing that work?

Happy to have a crack at it. Will post here when it's ready for review.

I've PR'd my changes as https://github.com/openaps/oref0/pull/279. Hoping it's not too opinionated! The graph below compares the old behavior (blue) against this PR (green) and @sulkaharo 's fixes in oref0.

Anyone care to test https://github.com/openaps/oref0/tree/wip/mmhistorytools-integration and let us know how it goes?


TypeId of types in dependencies depends on the main crate

e.g.
$ tree
.
├── Makefile
├── x
│   ├── Cargo.toml
│   └── src
│       └── lib.rs
├── y
│   ├── Cargo.toml
│   └── src
│       └── main.rs
└── z
    ├── Cargo.toml
    └── src
        └── main.rs

6 directories, 7 files

// x/src/lib.rs
pub struct Foo { x: i32 }

pub fn go() {
    println!("{:?}", std::any::TypeId::of::<Foo>());
}

// {y,z}/src/main.rs
extern crate x;

fn main() {
    x::go();
}

Running them gives TypeId { t:<PHONE_NUMBER>898941418 } for y and TypeId { t:<PHONE_NUMBER>591603564 } for z.
I'm filing this as a Cargo issue because I suspect it may be caused by metadata cargo is passing. It seems unfortunate that changing the context in which a crate appears should change its internal typeids, but I'm not sure this is a bug (or if it's solvable).

Repo: https://github.com/huonw/cargo-issue-1244 just run make.

What in the world is happening here

@alexcrichton: If I run the following sequence of commands, I get two different TypeIds:
rustc x\src\lib.rs --crate-name x --crate-type lib -g -C metadata=y -C extra-filename=-y --out-dir .
rustc x\src\lib.rs --crate-name x --crate-type lib -g -C metadata=z -C extra-filename=-z --out-dir .
rustc y\src\main.rs --crate-name y --crate-type bin -g --out-dir . -L . --extern x=libx-y.rlib
rustc z\src\main.rs --crate-name z --crate-type bin -g --out-dir . -L . --extern x=libx-z.rlib
.\y
.\z

Output:
TypeId { t:<PHONE_NUMBER>7172906008 }
TypeId { t:<PHONE_NUMBER>5564179121 }

If I change both compilations of x to use metadata=x, however, they match.  That is:
rustc x\src\lib.rs --crate-name x --crate-type lib -g -C metadata=x -C extra-filename=-y --out-dir .
rustc x\src\lib.rs --crate-name x --crate-type lib -g -C metadata=x -C extra-filename=-z --out-dir .
rustc y\src\main.rs --crate-name y --crate-type bin -g --out-dir . -L . --extern x=libx-y.rlib
rustc z\src\main.rs --crate-name z --crate-type bin -g --out-dir . -L . --extern x=libx-z.rlib
.\y
.\z

Outputs:
TypeId { t:<PHONE_NUMBER>9377429615 }
TypeId { t:<PHONE_NUMBER>9377429615 }

It looks very much like the crate metadata is influencing the TypeId; either it shouldn't, or Cargo should be passing the same metadata for both compilations.  For reference:
rustc 1.0.0-nightly (92ff8ea52 2015-01-27 23:08:13 +0000)
binary: rustc
commit-hash: 92ff8ea52816982ad4cbfac8168e216d32d74c77
commit-date: 2015-01-27 23:08:13 +0000
host: i686-pc-windows-gnu
release: 1.0.0-nightly

Oh right, I forgot about that. Thanks @DanielKeep!
This is basically highly inter-related to https://github.com/rust-lang/cargo/issues/497 because the metadata comes from the hash of the PackageId and in this case the PackageId points at a Path. The Path that it points at is the root path of the first compilation, not necessarily at the dependant package itself.
For example, in @huonw's example, the first path is .../z and the other is .../y. This is the path listed for the x crate (despite it being in a different path).
That's at least the source of the bug at least :)

Sure!


Add support Amazon Bedrock Claud 3.0

Add support Amazon Bedrock Claud 3.0

We need to add support for Claude's Messages API as a prerequisite. All previous Claude versions support this. See:
https://docs.anthropic.com/claude/reference/migrating-from-text-completions-to-messages

Initial attempt over at https://github.com/spring-projects/spring-ai/pull/424
@tzolov - would you be able to comment on how we can incorporate support for the new Messages API? It's currently sitting in a new package, as the APIs are quite different.
The package name at least should change, as this isn't Claude 3 specific. I've tested on Instant, 2 and 3 models.
Thanks

Resolved with #424


Hive "es.mapping.routing" Error

elasticsearch-hadoop 6.0.0
Hive External Table Seting One:
'es.mapping.join'='my_join_field'   #my_join_field type map<string,string>
es.mapping.routing not set
 Prompt mistakes when writing table
     "Field [my_join_field] needs to be a primitive; found [map<string,string>]"

Hive External Table Seting Two:
 'es.mapping.join'='my_join_field'   #my_join_field type map<string,string>
 'es.mapping.routing'='<4>'   #Specify the constant Or field

  Prompt OK when writing table。

And this is not in conformity with the
"- Added a chained field extractor that checks for routing first, and if
a routing has not been set, will search for the join field's parent id. "

Join and Routing fields must be primitive fields, ideally string data. It's not clear to me how a map of strings can make sense as a join field. The second run you had is using a constant value of 4 which is a primitive value, and thus preempts even checking for a join field value.
If you still feel like this is an error, please let me know, but this looks like it's functioning as intended.

I didn't think so,
Join properties can only be set to the string when the parent is, when the child is an object, that object inside the Hive how do you say?
If the subdocument join set to a string, will prompt can not find the parent.
In addition, you can take a look at this, I don't think so I understand error：https://www.elastic.co/guide/en/elasticsearch/hadoop/current/configuration.html
es.mapping.join (default none)
The document field/property name containing the document’s join field. Constants are not accepted. Join fields on a document must contain either the parent relation name as a string, or an object that contains the child relation name and the id of its parent. If a child document is identified when using this setting, the document’s routing is automatically set to the parent id if no other routing is configured in es.mapping.routing.
es.mapping.routing (default depends on es.mapping.join)
The document field/property name containing the document routing. To specify a constant, use the  format. If a join field is specified with es.mapping.join, then this defaults to the value of the join field’s parent id. If a join field is not specified, then this defaults to none.

@jbaiera
I didn't think so,
Join properties can only be set to the string when the parent is, when the child is an object, that object inside the Hive how do you say?
If the subdocument join set to a string, will prompt can not find the parent.
In addition, you can take a look at this, I don't think so I understand error：https://www.elastic.co/guide/en/elasticsearch/hadoop/current/configuration.html
es.mapping.join (default none)
The document field/property name containing the document’s join field. Constants are not accepted. Join fields on a document must contain either the parent relation name as a string, or an object that contains the child relation name and the id of its parent. If a child document is identified when using this setting, the document’s routing is automatically set to the parent id if no other routing is configured in es.mapping.routing.
es.mapping.routing (default depends on es.mapping.join)
The document field/property name containing the document routing. To specify a constant, use the format. If a join field is specified with es.mapping.join, then this defaults to the value of the join field’s parent id. If a join field is not specified, then this defaults to none.

Ah it seems you are correct. I had forgot about the child data format case. I'll take a look again.

what should be the value in     es.mapping.join ?   (both for parent and child).
Example:

my my index

PUT test_tree
{
"mappings":{
"properties":{
"fam_details": {
"type":"join",
"relations":{
"danfamily":[ "comfamily", "enterfamily" ],
"comfamily":"richardfamily"
}}}}}

Data inserted in from Spark2 using esHadoop and mapping for

Parent insert
esconf["es.mapping.id"] = "uniqueid"
esconf["es.mapping.join"] = "fam_details" , /  also tried danfamily /
Child insert
esconf["es.mapping.id"] = "uniqueid of child"
esconf["es.mapping.join"] = "comfamily"
esconf["es.mapping.routing"] = "uniqueid"   (same field as parent)
I am able to insert data from spark.  I am able to search data
but no data when i query using has_parent, has_child queries
Any Help

what should be the value in es.mapping.join ? (both for parent and child).
Example:

my my index

PUT test_tree
{
"mappings":{
"properties":{
"fam_details": {
"type":"join",
"relations":{
"danfamily":[ "comfamily", "enterfamily" ],
"comfamily":"richardfamily"
}}}}}

Data inserted in from Spark2 using esHadoop and mapping for

Parent insert
esconf["es.mapping.id"] = "uniqueid"
esconf["es.mapping.join"] = "fam_details" , / also tried danfamily /
Child insert
esconf["es.mapping.id"] = "uniqueid of child"
esconf["es.mapping.join"] = "comfamily"
esconf["es.mapping.routing"] = "uniqueid" (same field as parent)
I am able to insert data from spark. I am able to search data
but no data when i query using has_parent, has_child queries
Any Help

Ah it seems you are correct. I had forgot about the child data format case. I'll take a look again.

Ah it seems you are correct. I had forgot about the child data format case. I'll take a look again.

what should be the value in es.mapping.join ? (both for parent and child).
Example:
my my index
PUT test_tree
{
"mappings":{
"properties":{
"fam_details": {
"type":"join",
"relations":{
"danfamily":[ "comfamily", "enterfamily" ],
"comfamily":"richardfamily"
}}}}}
Data inserted in from Spark2 using esHadoop and mapping for
Parent insert
esconf["es.mapping.id"] = "uniqueid"
esconf["es.mapping.join"] = "fam_details" , / also tried danfamily /
Child insert
esconf["es.mapping.id"] = "uniqueid of child"
esconf["es.mapping.join"] = "comfamily"
esconf["es.mapping.routing"] = "uniqueid" (same field as parent)
I am able to insert data from spark. I am able to search data
but no data when i query using has_parent, has_child queries
Any Help

what should be the value in es.mapping.join ? (both for parent and child).
Example:

my my index

PUT test_tree
{
"mappings":{
"properties":{
"fam_details": {
"type":"join",
"relations":{
"danfamily":[ "comfamily", "enterfamily" ],
"comfamily":"richardfamily"
}}}}}

Data inserted in from Spark2 using esHadoop and mapping for

Parent insert
esconf["es.mapping.id"] = "uniqueid"
esconf["es.mapping.join"] = "fam_details" , / also tried danfamily /
Child insert
esconf["es.mapping.id"] = "uniqueid of child"
esconf["es.mapping.join"] = "comfamily"
esconf["es.mapping.routing"] = "uniqueid" (same field as parent)
I am able to insert data from spark. I am able to search data
but no data when i query using has_parent, has_child queries
Any Help

Ah it seems you are correct. I had forgot about the child data format case. I'll take a look again.

@myamor163 ,  Can you please help with this setting ?


add support for property()

It could be turned into a proper XPath function by making an new secondary instance available to all forms e.g. <instance id="__properties">.
The expression "property('something') could then be re-written to "instance('__properties')/something".
This would be somewhat similar to CommCare. If this (lengthy) approach is chosen, the preloaders should obtain their values in the same manner.

Duplicate of #57


Create LICENSE

fixes #7

Creative Commons License can't be used for software as far as I know.
I am usually a Mozilla License kinda guy if you don't know what to take

Ou celle-là: https://choosealicense.com/licenses/gpl-3.0/


Bump to Avro 1.11.1

What is currently missing?
Avro version 1.11.1 has been released with some python improvements: https://s.apache.org/avro-1.11.1-announce
How could this be improved?
Python

AVRO-3542 Scale assignment optimization
AVRO-3521 "Scale" property from decimal object
AVRO-3380 Byte reading in avro.io does not assert read bytes to requested nbytes
AVRO-3229 validate the default value of an enum field
AVRO-3218 Pass LogicalType to BytesDecimalSchema

Is this a feature you would work on yourself?
[X] I plan to open a pull request for this feature

This was fixed in #516 where avro requirement was bumped to 1.11.1+ containing changed included in https://github.com/apache/avro/tree/branch-1.11 at the time of merge, and an approved patch from https://github.com/apache/avro/pull/2039