Create specification for the Verkle State Network

This is just the first version of the spec.
Plan is to keep updating and refining as we progress.

Once merged, it would be good to open an issue that outlines the attack vector that was discussed today so that it is documented somewhere.

Once merged, it would be good to open an issue that outlines the attack vector that was discussed today so that it is documented somewhere.

I'm very confident that it is possible to prevent the attack. I created an issue to discuss the problem and solution: https://github.com/ethereum/portal-network-specs/issues/297
Once more research is done and finalized, we can include it in the specification as well.
My current main concern is that proof size is more than doubling the size of the root nodes, which might not be too bad (considering that majority of nodes are not root nodes).

I updated the spec:

It follows new directory structure
Renaming "mini-trie" nodes to bundle (upper level) and fragment (lower level)
Reference to recursive gossip is removed

this allowed us to use smaller proof (using IPA and multiproof)

Restructure content key/value types

there were some small issues with original writing, and now they are aligned with new proofs

I'm sure there will be more fixes and polishing later on, but I would say we can merge this as it is and iterate afterwards.


Use copysign

the problem is in the rewrite of the tests -- if you deal with that, I will put this through and check timings later

Tests are now passing @JeffreySarnoff.

Thanks! Could you tag a new release, please?

Thanks! Could you tag a new release, please?
On 1 Jun 2017 2:36 p.m., "Jeffrey Sarnoff"<EMAIL_ADDRESS>wrote:
Merged #7 https://github.com/JeffreySarnoff/AdjacentFloats.jl/pull/7.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/JeffreySarnoff/AdjacentFloats.jl/pull/7#event-1106051030,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALtTqSM-K9yzomyKNgqobZo6xPFmeyNks5r_r5fgaJpZM4NqWKf
.

done

Thanks!


Allow reading Parquet maps that lack a values field

Which issue does this PR close?

Closes #1642.
Rationale for this change
The Parquet spec does not require the values field of a map to be present, but current readers will error out if this field is missing.
What changes are included in this PR?
Changes both the record reader and arrow reader to read a MAP lacking values as a list of keys. This matches the behavior of arrow-cpp.
Are there any user-facing changes?
No

I also poked around in https://github.com/apache/parquet-testing/tree/master/data for an example of such a file, but it seems like we do not have one.

Correct, which is why the effort in the tests to produce one. I'll try submitting one I have on hand to parquet-testing.

https://github.com/apache/parquet-testing/pull/63 submitted. Maybe we can hold off on merging this to see if the test file will be accepted.

Looks like the test is in the final phases of being accepted.

https://github.com/apache/parquet-testing/pull/63

Let's wait for that to complete and then we can merge this one too

Should the tests here be modified first to read the new file?

Should the tests here be modified first to read the new file?

Yes pls

Not sure what markdown is failing in CI

Not sure what markdown is failing in CI.
Edit: I managed a conda env with prettier and there were no issues reported. Very puzzling (esp since there's no output beyond "this job failed"). Maybe it's just a transient thing. 🤷

I retriggered the job -- I bet it was some sort of github infrastructure blip


[stable/prometheus-cloudwatch-exporter] added changelog

What this PR does / why we need it:
It adds a CHANGELOG.md containing past changes based on git commit messages.
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign scottrigby

/assign gianrubio

/lgtm


About Blazor Documentation

Does the documentation edited for Preview 4.
I have tried the javascript Introp in preview 4 but the procedure cannot work for me.

Hello @Honda99 ... Yes, they were updated for Preview 4 (and Preview 5 updates have been merged and are live now).
What step (or steps) in the doc isn't working? If it's something quick that I can answer quickly here, I will. Otherwise, I'll recommend a support forum, such as Stack Overflow, or a support chat, such as Slack or Gitter. There are only a handful of doc authors here, so we don't have the staffing to offer general product support.


Clean up default Gatsby cruft

There's a ton of Gatsby related boilerplate leftover from the starter template that should be removed

this should be closed right?


chore: Add modelName, sessionId, requestId usage

PR-Codex overview
This PR introduces additional fields to the usageEventSchema in the service-utils package, enhancing the tracking of usage events by including identifiers for the model, session, and request.
Detailed summary

Added modelName as an optional string to usageEventSchema.
Added sessionId as an optional string to usageEventSchema.
Added requestId as an optional string to usageEventSchema.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Merge activity

Dec 9, 7:17 PM EST: The merge label 'merge-queue' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.


Failed Relationship import removes uploaded file

I am on the dev version of Explorer as of reporting this bug.
I uploaded a csv file (livejournal.csv). Then created a node table and a relationship table. Then I went to Import Data and prepared to import livejournal.csv and clicked "Start Import" So I see this.

The file apparently had an error. So it gives me this message in this window.

When I click "Close", the uploaded file seem lost. I get to the following page.

If I instead click on somewhere else on the behind screen, I go back to the import view and livejournal.csv is still there (so as in the image before I clicked "Start Import".

Can you provide the full dataset?


Update robloxlib.py

added some more code onto robloxlib.py
thats about it

I doubt the creator of this repository is going to ever check, but this should be added.

@elisnowden I also think he won't check this at all. I might make a new repo and put my code in it and give the creator credit for making the original code.


fix kotlin isXx property name

Codecov Report

Merging #3268 into master will decrease coverage by 0.25%.
The diff coverage is 77.77%.

@@             Coverage Diff              @@
##             master    #3268      +/-   ##
============================================
- Coverage     80.38%   80.13%   -0.26%
- Complexity     7356     7381      +25
============================================
  Files           156      157       +1
  Lines         27534    27685     +151
  Branches       6597     6636      +39
============================================
+ Hits          22134    22186      +52
- Misses         3470     3552      +82
- Partials       1930     1947      +17

Impacted Files
Coverage Δ
Complexity Δ

...main/java/com/alibaba/fastjson/util/TypeUtils.java
79.84% <66.66%> (-0.05%)
644.00 <3.00> (+1.00)
:arrow_down:

...n/java/com/alibaba/fastjson/util/JavaBeanInfo.java
86.72% <100.00%> (+0.28%)
212.00 <0.00> (ø)

...om/alibaba/fastjson/serializer/EnumSerializer.java
66.66% <0.00%> (-33.34%)
5.00% <0.00%> (+2.00%)
:arrow_down:

...baba/fastjson/serializer/ASMSerializerFactory.java
92.39% <0.00%> (-3.95%)
193.00% <0.00%> (-8.00%)

...m/alibaba/fastjson/serializer/SerializeConfig.java
76.59% <0.00%> (-1.64%)
137.00% <0.00%> (+5.00%)
:arrow_down:

...m/alibaba/fastjson/serializer/SerializeWriter.java
64.31% <0.00%> (-1.33%)
356.00% <0.00%> (-2.00%)

...main/java/com/alibaba/fastjson/util/FieldInfo.java
86.44% <0.00%> (ø)
94.00% <0.00%> (+1.00%)

...n/parser/deserializer/EnumCreatorDeserializer.java
54.54% <0.00%> (ø)
2.00% <0.00%> (?%)

...ava/com/alibaba/fastjson/parser/JSONLexerBase.java
71.38% <0.00%> (+0.03%)
829.00% <0.00%> (+1.00%)

... and 8 more

Continue to review full report at Codecov.

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


get-initial-password action wrong password

Bug Description
get-initial-password action currently does not work as intended if one or more WordPress instances join the relation and/or a new WordPress instance replaces an existing old one(remove & deploy).
It seems to be due to relation-data among WordPress peers not getting cleared by Juju.
It may be worthwhile to store the data elsewhere(new juju secrets perhaps?).
To Reproduce

Deploy and relate necessary charms

juju deploy charmed-osm-mariadb-k8s mariadb
juju deploy wordpress-k8s --channel=edge
juju relate wordpress-k8s mariadb

Run get-initial-password action
juju run-action wordpress-k8s/0 get-initial-password

Navigate to wordpress (http://UNIT_ADDRESS/wp-login.php) and login with password
Should succeed.

Deploy another instance of wordpress
juju deploy wordpress-k8s --channel=edge wordpress-k8s-2

Run get-initial-password action
juju run-actino wordpress-k8s-2/0 get-initial-password

Navigate to second wordpress unit and login with second password
Fails.

6.a. Navigate to second wordpress unit and login with first password
Succeeds.
Environment
Wordpress-k8s channel edge
Relevant log output
N/A

Additional context
No response

The charm does not support a single database to work w/ multiple wordpress instances. Closing.


ocamlPackages.ppxlib: 0.30.0 -> 0.32.0

Description of changes

Some 5.1 incompatibilities with ppx are addressed in later versions, e.g. https://github.com/ocaml-ppx/ppxlib/pull/432.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This breaks vcaml and ppx_cstubs with OCaml 5.1. An easy “fix” might be to mark them as broken.


Automation for Prefect 2.0

This is a pull request to put the basics of terraform automation for Prefect 2.0 in place.
The content of this is an exact copy of an implementation I came up with recently and my thoughts about what the 2.0 needs can be found on its README file (also pushed as part of this PR). Happy to get more eyes and hands on this for sure.
Something to note is that I created a branch on my forked repo named "2.x", keeping the existing 1.0 implementation as it is in the main branch, similar to what has been done for the Prefect library. If we think we'd like to proceed with a similar approach it would be better to get this merged into "2.x" instead of "main".
(Actually we shouldn't merge this as it is because it will override the 1.0 implementation on main, but we should decide first where 2.0 should live)
Resolves: #3

This is great to see @maikelpenz!  We have transitioned from Prefect 1 to Prefect 2 and will feel much more comfortable when our Prefect 2.0 settings can join the rest of our infrastructure in Terraform. Thank you and another vote for making a quick decision on the new branch and letting this out in the wild, even as a sub-1.0 release for testing.

Hey there! Thanks so much for your contribution, this looks like an awesome start at something we've wanted to tackle for awhile. I left a few comments throughout for your consideration, but most of them are minor and we can tackle them later.
We should be able to accept this change in the next few days, but it may be a few weeks until we can do a deeper review and get something published on the Terraform registry.

Thank you very much for jumping into this PR @jawnsy. Give me some days to go through your review 👍.

@jawnsy most of your comments have been addressed. Two things to note:

To create "blocks" through terraform I need to retrieve the "block schema" for what I want (e.g S3, Kubernetes). And the API I am using is the one that gets the block schema by checksum. This is because I found out the same checksum is used across workspaces. However, I am not sure this is the same checksum "across accounts". This is not a big problem as every Prefect Cloud user can adjust to the checksum set for their account, but if there was an API available to get block schema by name it would be simpler (and potentially global).

Second note is around merging this to master. I understand you'd be happy to get this as it is into master but I just want to make sure @tekumara is across this as he released the 1.0 version of this automation. If we want to keep both maybe we put this in a separate branch. Will leave this with you and I can make changes to my PR if you wish.

Thanks so much everyone for this effort!  We can put terraforming our Prefect 2 installation on the roadmap thanks to this nice surprise. Best wishes!

Thanks for checking @maikelpenz ! No problem for us, we have an internal version of the provider so we're happy for this to be a Prefect 2 only provider.


Samples not stopping when they should

I'm having this odd issue where for some samples, it continues playing past where it should stop, making them play a bit of the next sample by mistake.
Not sure if it's my set up or something wrong with my wav files.
Using asm68k, problems started after migration from MegaPCM 1.x to MegaPCM 2
https://github.com/user-attachments/assets/43bfeb0b-0342-419f-a9b2-33304dffb2ba
Here I play a couple of samples, some working ones and some with the problematic ends.
$A0 being especially bad
$9E being the most subtle, leaving an awful click at the end
(not recorded : $AA seems to have syncing problems, this was not the case on MegaPCM 1.x)
SoundDriver_DACOnly.zip
Here's what I have, if anything seems wrong about my setup, let me know.
EDIT : just tested it out with https://github.com/vladikcomper/s1disasm-megapcm2 , seems it is the samples and settings that are giving trouble.

I linked this sample table to the debug version of Mega PCM 2 and it logged a few interesting things. I have a feeling some WAV files are corrupted (at least that's what it looks like).
Take of of problematic samples for example ($A0):
KDEBUG MESSAGE: Sample: type=50, flags=00, pitch=A2, start=guimokick2, end=guimokick2_end
KDEBUG MESSAGE: Detected WAVE header
KDEBUG MESSAGE: Seeking data chunk: Skipping 00000010 bytes
KDEBUG MESSAGE: Checking data chunk at guimokick2+24
KDEBUG MESSAGE: WAVE data offsets: start=guimokick2+2C, end=guimosnare2+68A

The sample record specified start=guimokick2, end=guimokick2_end, but since it's a WAV file Mega PCM 2 went ahead to locate the exact boundaries of WAVE file's data block (so it won't attempt to "play" headers and metadata/tags). And this is where overflow comes from: WAVE data offsets: start=guimokick2+2C, end=guimosnare2+68A (data block pointers seem to overflow into the next sample.
Here's another one, similarly corrupted:
KDEBUG MESSAGE: Sample: type=50, flags=00, pitch=DF, start=guimosnare2, end=guimosnare2_end
KDEBUG MESSAGE: Detected WAVE header
KDEBUG MESSAGE: Seeking data chunk: Skipping 00000010 bytes
KDEBUG MESSAGE: Checking data chunk at guimosnare2+24
KDEBUG MESSAGE: WAVE data offsets: start=guimosnare2+2C, end=guimosnare3+92

Fill log of loaded sample for reference:
output.log
So something's up with these files. Were they abruptly truncated without fixing the header?
I need to inspect this more closely. I'll get back with the results soon.

FFmpeg also doesn't like these samples:
$ ffprobe -i GuimO/kick2.wav -hide_banner
[wav @ 0x55886a35f900] Packet corrupt (stream = 0, dts = NOPTS).
[wav @ 0x55886a35f900] Estimating duration from bitrate, this may be inaccurate
Input #0, wav, from 'GuimO/kick2.wav':
  Duration: 00:00:00.39, bitrate: 67 kb/s
  Stream #0:0: Audio: pcm_u8 ([1][0][0][0] / 0x0001), 8272 Hz, 1 channels, u8, 66 kb/s

I wonder how this happened though. Were they edited by some old glitchy tool or truncated at some point?

Full list of corrupted files according to ffprobe:
Scrsh2sy78.wav
[wav @ 0x563809214900] Packet corrupt (stream = 0, dts = NOPTS).

VCome_on.wav
[wav @ 0x55b457a89900] Packet corrupt (stream = 0, dts = NOPTS).

woodyyeah.wav
[wav @ 0x559a04b79900] Packet corrupt (stream = 0, dts = NOPTS).

GuimO/clap.wav
[wav @ 0x55cdd3159900] Packet corrupt (stream = 0, dts = NOPTS).

GuimO/kick2.wav
[wav @ 0x55d7bfc7b900] Packet corrupt (stream = 0, dts = NOPTS).

GuimO/Snare2.wav
[wav @ 0x55b9037b6900] Packet corrupt (stream = 0, dts = NOPTS).

GuimO/wood.wav
[wav @ 0x55ed957be900] Packet corrupt (stream = 0, dts = NOPTS).

Ok this makes a whole lot of sense if that's how MegaPCM2 detects its borders.
On MegaPCM1 I would manually truncate the samples via hex editor rather than on an audio editor to save on some space, neglecting the header entirely.
So essentially, all I have to do is fix the headers on the wav files.

@VAdaPEGA Here, I fixed it for you =P
vadapega-wav-fixed.tar.gz
I just ran used SOX utility on Linux to copy audiostreams as-is and it automatically fixed the header. I could've used FFMpeg as well, but it adds an extra 22 byte section in WAVE with codec metadata (totally harmless, just space wasted).
$ mkdir fixed
$ for i in *.wav ; do sox $i fixed/$i ; done
sox WARN wav: Premature EOF on .wav input file
sox WARN wav: Premature EOF on .wav input file
sox WARN wav: Premature EOF on .wav input file
sox WARN wav: Premature EOF on .wav input file

I didn't test it yet, but I'm sure it should play fine now.
And yeah, Mega PCM 2 is quite high-level now; so it reads actual WAVE headers and plays according to them (when uploading sample table to Z80 in MegaPCM_LoadSampleTable), no more cheap tricks of skipping bytes like in 1.x.
I'm glad to hear it was just abruptly truncated though; so I don't have to deal with potential broken WAVE editors and their edge cases.

Whoa awesome, thanks for the help!

@VAdaPEGA I just noticed you mentioned sample $AA had desync problems. I took a closer look and it turned out to be a legit bug! You triggered quite a rare edge case with unusually low sample rate (4 kHz).
Can you try this patched version? It should fix desync issues with extremely low-rate samples:
megapcm-2.0.1.tar.gz
Here's a demo ROM I used to test this (sample $AA seems to play properly here):
rom.zip
In case you wonder what the bug is:
Mega PCM 2 always buffers samples at double the max rate (50416 Hz in case of PCM) so it can survive up to 33% of CPU time without ROM access by playing solely from a 256-byte "read ahead" buffer (in Z80 RAM). On the other hand, it plays previously buffered data in parallel (it's always buffer 2 samples @50kHz, play 1 sample at the desired rate). High enough rates keep the balance: the buffer is only half-full most of the time. But 4 kHz is so low, the buffer is always full and accepts new samples every other time.
This isn't an issue though: I always check if buffer is full in the playback loop. Except for one edge case: if "read ahead" buffer is full and Z80 was about to switch banks, it mistakenly buffered first 2 samples from the next bank without checking. This pushed buffer pointer beyond a threshold and caused overrun for one iteration... which would eat up and skip ~256 samples. And again, since it's 4 Khz, 256 samples become noticeable.

I was gonna make a separate issue for the weird syncing problems but was too tired to write up about it, thanks for looking into it!
The patched version works well!


Local or remote?

Hi, thought faster-whisper ran locally, but there seems to be a connection to hugginface.co on every request.  Is this to convert to text, or is it to check if the model has been downloaded?  Is there a way to remain totally local?

@mike99mac , hello. You can download/save model to your local path then pass this path when initializing fw model. In this case, the model will no longer download from the hf hub.
Ex:
model_path = '/path/faster-whisper-large-v3-fine-tuning'
model = WhisperModel(model_path, device="cuda")


Deploy on CI

I am tackling this now.

For now, I will just have it install our project and make sure our notebooks run.

We are doing this now in ibis-vega-transform


Tapping a ballistically-scrolling list with competing gesture recognizers on iOS leaves it overscrolled

Take a vertical list in a horizontal list on iOS (or tap "o" in hot reload on Android to fake iOS).
Overscroll the vertical list, then quickly release and tap the list.
The list pauses, overscrolled, and doesn't return until you jiggle it.
You can see this in the Tabs demo, for instance.

I believe @Hixie fixed this recently.


Google colab plot not working.

I am using the code directly from the jupyter notebook we were given to use but the plot doesn't show when I run it. Any ideas?

I realize this is a repeat of #26 and ubsuny/23-Homework7G5#33

If anybody has this problem, here is what I did. Remove the:
%matplotlib notebook

Click restart and run all


New version

When will a next stable version of Torque?
3.2?

Yes, it will be 3.2 although we don't have a release date yet.  We have successfully finished everything that we wanted to finish for 3.2 so it's just a matter of time.


changes to axis handling

This has a few changes in structure to get the axis correctly se issues: #92 , #93 and #90 .
NB currently ancillary file is hardcoded to get a specific ice configuration in line 556 of mop_utils.py.
Issue #90 is not yet fully resolved as I'm not yet sure how many ancillary files we need and which.
I wanted to push the other changes so we can move on with the ice and potentially work out other issues before committing to a solution for this issue.
Main issue resolved is that now define_grid for 2D lat/lon variables work. So we can write ice data. This involved changing (and hopefully improving) the code dealing with the axis. I think it should have solved other potential issues that we hadn't encountered yet.
However, I expect things to break down again s soon as we hit a pseudo axis or transects etc. Fixing them without an example is hard.
Other changes are in plevinterp see #93 plus I basically removed a interp function that was only calling np.interp and used directly np.interp in apply_ufunc.
Added function calc_mrsos() to calculate moisture of first 10cm of soil: #69. Haven't yet tested or removed previous function.
I think there was also the start of changes to the way we update the mopper.db database but not sure they are fully working. I will use this pull request to review everything that I changed and might have forgotten about :-)
Make sure to update your conf files.

After reviewing file changes I see that I also:

fixed #89 the function that uses timestamps to check which files are in range
started adding some tests (see #84 )
removed more obsolete functions/code
fixed issues with longitude being between -180-180 instead of 0-360


Add hyper-darkmatter theme

Checklist for submitting an awesome plugin, theme, or resource:

[x] The title for my package or theme uses its npm title (hyper-plugin-example)
[x] The link for my package or theme uses the npmjs.com link (https://www.npmjs.com/package/hyper-plugin-example)
[x] There is a visual representation of what my plugin or theme does in the repo. (Plugin: screenshot or gif || Theme: screenshot of the theme applied to Hyper)
[x] Put your awesome item at the BOTTOM of the correct (plugin, theme, or resource) list.
[x] VERY IMPORTANT: I've written a short (one sentence) description for my package or theme as the description of the awesome plugin, theme, or resource in the README.md file I'm submitting in the PR.

I also added .DS_Store to the .gitignore, if you don't mind.


Improve campaign creation wizard layout

Feedback from user testing: layout and design of the campaign creation wizard was confusing in the following places:

Date hidden and always was skipped
Previous, Next, and Submit buttons are oddly placed
Need example description to be helpful to know what to write
Add clarifying text/layout for Add OMK button.
Add clarifying text/layout for adding managers.
Enable ability to add custom tags. Instead of only having to edit the survey file on Github.
Remote mapping workflow is confusing. See separate ticket.
Confusing when you're in Edit mode (after a campaign has been created) and there isn't a submit button on the main General Information view.

Hi @dimasciput , @cchristelis and  @smit1678
General information:

I suggest to keep with the homepage buttons colors and make then orange
Place the date fields below the campaign name
Add the help text to the campaign description, type, tags and managers - here's some default text I added, @cchristelis maybe you would suggest something better)
Keep the Next and Previous buttons on the same line and the Submit (for the new campaign)/Update (for the existing campaign, make it visible on the general information tab too) - below them as it works for the whole page, correct?
Regarding the custom tag which has a value, how about using the colon ":" after the tag name before the value, @meomancer , did you find the solution for this?

@smit1678 , could you please link here the ticket regarding the remote mapping workflow?

Thanks @MariaSolovyeva , that layout looks better. @ann26 can you try to implement this? Thanks.

ok @dimasciput

Hi @MariaSolovyeva , there are two input boxes for start date and end date in the form. Should we remove the upper start date and end date?

Hi @ann26 I think we can keep the dates on the top, just as the reminders, maybe we can remove editing possibility from there

Hi @MariaSolovyeva ok, I have included it in the new ui, please see #374

Ok that great, thank you @ann26


update numeric literals topic for leading underscores

non-decimal integer literals can now have leading underscores.
For example, 0x_ff is valid in C# 7.2
/cc @gafter

7.2 shenanigans yet again! I can take this too once I'm done with #3240.

@garg000dhruv That would be great. I'm going to leave it unassigned until we get the first one done, in case someone else wants to jump in.

@BillWagner I can take this one now if you'd like.

It's yours.


Merge storage interface changes from master

https://github.com/prometheus/prometheus/pull/1805 got merged into upstream master. As a result, the Frankenstein-specific querying modifications are now simplified (in a separate followup commit).

Added another merge-related fixup commit.


Snapshot hub support file

Hi! What is your PR about?

[x] Add images for your space
[ [x]
grumpy-finance .zip

Add custom domain for your space

[ ]x Add alias for migrate your space
[ x] Add or edit a skin
~Edit your space with GitHub?~ (deprecated) Please migrate your space to ENS https://docs.snapshot.page/spaces/migrate
~Create your space with GitHub~ (deprecated) Create your space with ENS instead https://docs.snapshot.page/spaces/create

Hey @tommdi, I'm not sure what do you want to do with this file?

Closing this PR for now, feel free to open it again once you've done the changes.


Create table in same database as superclass

Before this change, using with_model with a superclass that connects to a database other than the database configured for ActiveRecord::Base would end up creating the table in the wrong database.

@nertzy any chance we could have this reviewed and merged? It's an important change to properly work with multiple database connections introduced by Rails 6.


Kafka Scaler not scaling down

Report
I wanted to a get a hand at the Kafka consumer pods auto-scaling capabilities using KEDA Kafka auto-scaler.
I tried to use references in https://tech.groww.in/event-driven-autoscaling-in-kubernetes-using-keda-c6aa27a10a80 ( https://github.com/leegin/KEDA-kafka). The scaling-up of consumers happen while it doesn't scale down after messages are consumed from the topic.
The ScaledObject has the following status always:

kubectl get so
NAME                 SCALETARGETKIND      SCALETARGETNAME             MIN   MAX   TRIGGERS   AUTHENTICATION              READY   ACTIVE    AGE
kafka-scaledobject   apps/v1.Deployment   kafka-consumer-deployment   0     5     kafka                                  False   True   145m
rabbitmq-consumer    apps/v1.Deployment   rabbitmq-consumer                 10    rabbitmq   rabbitmq-consumer-trigger   True    False     9h

To confirm i also tried with rabbit-mq scaler and it worked as expected.
I don't know if the problem is with the consumer or with the scaler.
Please help me with a working sample or configuration where scale-up and scale-down happens.
Expected Behavior
Scaling down of the consumer pods when no messages available in the Kafka topics.
Actual Behavior
Scaling down of the consumer pods isn't happening
Steps to Reproduce the Problem
Reproduce as in
https://tech.groww.in/event-driven-autoscaling-in-kubernetes-using-keda-c6aa27a10a80 ( https://github.com/leegin/KEDA-kafka).
Logs from KEDA operator
example

KEDA Version
2.3.0
Kubernetes Version
1.19
Platform
No response
Scaler Details
Kafka Scaler
Anything else?
No response

Are you sure that those messages were consumed from the Kafka topic? Maybe the offset hasn't been properly committed? You might want to change setting: offsetResetPolicy: latest

It now works but with a caveat.
I tried with a clean setup with offsetResetPolicy: latest and offsetResetPolicy: earliest. In both cases, it scaled down after 5 mins (300s) to be precise although i have set my coolDownPeriod to a low of 30s. Is this the expected behaviour or something wrong ??
I also observer that it scales up from minReplicaCount to maxReplicaCount for any kind of load. In this mode, we are forced to use maxReplicaCount pods for all kinds of load.
Can't it scale up based on the load and choose a number between minReplicaCount to maxReplicaCount

Sorry for the delay, this get's lost somehow.
It should scale gradually as well, it is just a matter of setting the right threshold.
In which point (replicas count) do you see the 5mins scale down? It is from 1->0 replica?


Visualization

Hello, and thank you for open-sourcing your work. It has been incredibly helpful and timely in addressing my urgent needs. However, I have a question: how can I obtain and visualize the point cloud data after removing snow?
Thank you for your assistance.

Hi,
Thanks for your message. You need to slice the point cloud where prediction is not snow. You need to use any visualization tool  or library like pptk or open3d for visualization.  I will be travelling till 6th October. I will come back to you with details after 6th October. If I forget, please send me a message.

Hi, Thanks for your message. You need to slice the point cloud where prediction is not snow. You need to use any visualization tool or library like pptk or open3d for visualization. I will be travelling till 6th October. I will come back to you with details after 6th October. If I forget, please send me a message.

Thanks for your work! If now the possible time for sharing something about visualization?


Can't Disable SSDP Descover (UPnP/Cast) Requests

the issue is related to ssdp dicover protocol,

even after disabling :

chrome://flags/#load-media-router-component-extension
chrome://flags/#media-router-cast-allow-all-ips
chrome://flags/#cast-media-route-provider

ssdp packets are still being generated, every time ungoogled-chromium is executed and every few seconds during use and it also triggers if the Cast... button is pressed :

OS/Platform and version: Archlinux
ungoogled-chromium version: 81.0.4044.129 installed from binary precompiled package

i've just noticed issue #991, sorry if this report is considered a duplicate; however it seems that this issue is well known and consistent across the board "chrome based browsers", never the less it's worth digging deeper in the source code in order to figure out what is actually going on here.


Make Field generic

Currently Noir is only compiles for bn254's scalar field, however there is nothing stopping it from being generic over any field.
This issue starts a discussion on the work needed to be done to make the compiler generic, and considerations.
Field Trait
We would need a NoirField Trait instead of a FieldElement struct. The trait methods will initially be the methods that are on FieldElement.
Noir will need to be aware of the possible Fields, however we can delegate this list to ACIR, similar to how we delegate all possible OPCODEs there.
Security Level
The security level of a group would need to be documented in Noir also, so that user can be warned when they are using a group which has < 128 bit security.
Some considerations about the implementation:
Question: Should Noir have implementations of all fields supported?
Compiling with implementations for all supported fields, is the current idea and here are the advantages and disadvantages.
Advantages

dyn will not need to be used.
There will be a single field element implementation per field that backends can choose to hook into.

Disadvantages

program will now contain all possible Field element implementations, increasing the binary size.
If a backend wants to use a new field, they will need to first upstream the implementation and implement the NoirField trait for it (This may not be a disadvantage)
Backends will need to convert from a NoirField trait to the type their proving system uses. (unless they implement it over a NoirField Trait) This may mean a lot of deserialising and subsequent performance loss.

Since NoirField trait can be implemented for the arkworks Field trait, we can immediately get all Field implementations that arkwork uses. For newer fields, I believe that the surface area for the NoirField trait is small and generic enough that wrapping a new field is negligible.
Other ideas would be for backends to supply their own field element implementation to plug into Noir, however this encourages code duplication between backends and may lead to non-deterministic constraint systems in the same field, if the field element implementation differs.
Compiler aware Field
The compiler currently does not need to be aware of the chosen field implementation, since there is only one. It is however aware of the different backends and we would have the same mechanism where the chosen field is passed as a parameter value in the package manager config file, and the package manager picks the corresponding data structure which is then passed to the compiler.
Rough Action steps

Replace the FieldElement struct with the Field trait, but still only compile for bn254.
Add all supported Fields noir_field as an enum. We then can add a new method in the Proving system trait supported_fields which allows the backends to specify which of these Fields they support. At this moment in time, there will only be one supported Field, which is bn254.
Add bls12-381 and allow the user to state they want to use bls12-381. The barretenberg backend should return an error, as it only supports bn254. We modify the arkworks backend adding bls12_381 to its supported_fields , adding the bls12_381 field as a viable field and testing whether it compiles.

First PR will be for a generic field trait, this will be the most intrusive refactr

Field trait abstraction does not seem to work well as generics need to be monomorphised at compile time, so we need to create all of the variants at compile time and store them. We then run into the problem of each Program being a different type as Programs are generic over they field. We could possibly make nargo generic over the field, however as seen from here: https://github.com/noir-lang/noir/tree/field_trait_fail ; the api is clunky and the changes made somewhat hurt readability.
It seems that we will need to use compilation flags and a toolchain installer in the long run.This might take some time, so below I list a few short term solutions.
A short term alternative is to choose the field size at runtime, however this seems to require a library akin to BigUint/BigInt.
Another short term alternative is to also have the Field be an enum and have the possible variants be each field. This would not blow up the size of FieldElement, since an enum is roughly the size of it's largest component plus a discriminant, and most fields are about 256 bits. These short term solutions would ideally allow one to make the field generic, with the least amount of change.

I've pushed the branch a bit more in #60. A couple comments:

if Program goes through successive elaborations, the actual distinction between fields does not seem to matter in the first few phases, especially in the Parser/ Token / Lexer levels. Int and Integer could contain a single concrete type (let's say NumericField, which payload would be .. bytes), which would make vast swaths of the compiler monomorphic. It would only be in later stages that a ParsedProgram (containing a deeply nested NumericField data) would become a ParsedAndFieldInterpretedProgram<F>.
the code size vs. performance trade-off is somewhat controllable through lto. Do you have context on why code size matters here?
the problem with having the Field be an enum is what happens when two such value meet. You then need to pattern-match to check they are the same type, in order to have them interact. The dynamic behavior gives you just an (admittedly much faster) dyn FieldElement.

if Program goes through successive elaborations, the actual distinction between fields does not seem to matter in the first few phases, especially in the Parser/ Token / Lexer levels. Int and Integer could contain a single concrete type (let's say NumericField, which payload would be .. bytes), which would make vast swaths of the compiler monomorphic. It would only be in later stages that a ParsedProgram (containing a deeply nested NumericField data) would become a ParsedAndFieldInterpretedProgram.

Yeah, having the Lexer and Parser contain the underlying field is not ideal as you would need to monomorphise them for each available field, when they do not explicitly use field operations.
I'd also further say that having the underlying field for the analysis phase is also not ideal since we do not need it for resolution and for the type checker the underlying field is always opaque. I wonder if instead of a bytes payload, a BigInteger could be used which may mean that the Interpreter could also use NumericField.
With bytes, we would not be able to do this, since we need to do field operations in the Interpreter. We could possibly avoid any field reductions until we get to the part of the code where we need an underlying field and reduce there. This could possibly be the backend.  ACVM and ACIR could possibly still be generic, and the compiler would instantiate it as ACIR maybe.

the code size vs. performance trade-off is somewhat controllable through lto. Do you have context on why code size matters here?

Ideally the compiler would be runnable on the browser, although I am not entirely sure if the code size will be a problem in the end. My assumption was that 20MB for the compiler right now, along with a possible SRS might be a lot. This could be mute after the backends are conditional compiled and optimisations are applied.

the problem with having the Field be an enum is what happens when two such value meet. You then need to pattern-match to check they are the same type, in order to have them interact. The dynamic behavior gives you just an (admittedly much faster) dyn FieldElement.

Yep, this was why I stopped on the field_trait_fail branch. Semantically it did not make sense, because you can only ever have one field on a  given run of the compiler.
Another slightly convoluted method would be to specify an ACVM backend with it's field and proving system at compile time. For libraries like arkworks this may become convoluted but for libraries that only have a single concrete field implementation, it seems reasonable. This implies that the compiler would be built with all available fields.
Will give this more thought as I also believe using conditional compilation is a viable strategy via a mechanism like Rustup; however the BigInt strategy may allow for generic fields in the short term without modifying the code drastically, so that we can figure out a better long term strategy.

PR #71 conditionally compiles each backend and field. The only problem with this is that rust features are meant to be additive, so it is currently not easy to say "I want to enable only one of these features". Multiple features can be enabled at the same time, from dependencies.
The most straightforward way to stop this would be to add cfg_any for each pair of features, which is not desired

closed by #71


come visit thedildohub for cheap dildos

https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com
https://thedildohub.com

ok fine


BLD: simplifications in meson.build files

simplify Pythran usage, removing unnecessary custom_target's
remove unused variable names
improve use of Tempita where possible
avoid use of py3 but rather rely on shebang files

This is happy now, should be good to go.


Added convenience methods .json() and .text() to the promise returned…

Added convenience methods .json() and .text() to the promise returned by fetch()
This allows for (compacted) calls such as:
fetch('http://example/').text()
.then(theText => console.log(theText))

This PR references this issue: https://github.com/bitinn/node-fetch/issues/36

I don't think #36 discussed this matter, it was in fact discussing new Request(), ie. using Request constructor directly, according to Fetch API https://fetch.spec.whatwg.org/
Likewise, you can write a helper library that wraps node-fetch to achieve the api shorthand you desire.

:-1: this module should strictly follow the standard. Plus,
fetch('http://example/').text()
.then(theText => console.log(theText))

isn't that much better than
fetch('http://example/').((r) => r.text())
.then(theText => console.log(theText))

closing outdated PR


Add /wgs84 frame to point click publisher when available.

Add /wgs84 frame to point click publisher when available.

:+1:
Looks good, works for me.


Allow users to avoid losing rare ordinals

ord wallet send protects against losing rare ordinals. Given that we now have a bounty based around ordinal names, and the wallet does not have any way to protect against sending specific named ordinals, we should add some way for a user to specify specific ordinals that should not be sent.

Potential strategies:

Make user make a literal list of ordinals that they wanted to keep
Label addresses in bitcoin core
Use different derive paths


Fixes #3107 - Use correct CloudFormation region check

coverage: 93.273% (-0.6%) from 93.907% when pulling 6e07056d703dadef81d09d31810eb0daaab5cc42 on cody-fix-cloudformation-config-region-check into 3416f209e989aeb6df3f7b23d1667f82c07403dd on main.


View about us restaurant for customers

About Us
7.1 View About us

Objective: The feature allows customers to view about restaurant.

View About us

Requirements
        User Story
        Acceptance Criteria
        Notes

About UsAs a customer, I want to see the details about the restaurant so that I can know their history

When customers navigate to the Yummy website

Then the customer can click the "About" menu in the header

Customer should be able to see About restaurant

Add comments

hi @mmafrar , regarding the task. I believe its already there right. Since i could see the information regarding the restaurant

@Pravin030399 Referring to your comment, assigning this to @Naqibullah-sediqi as he already completed the work

Assigning @Pravin030399 as he completed unit testing for this


Need to click and hold to select annotation

I am using Annotorious on a Drupal site to annotate images but I am running into an issue where I need to click and hold on an annotation in order to view it. This is only happening in readOnly mode. What's strange is that this is only occurring on images that are placed in the body of articles and not in images placed separately. Here is my initialization code:
var anno = Annotorious.init({
    image: imgElement,
    readOnly: readOnly1 || window.location.search !== "?mode=annotation"
  });

  anno.setAuthInfo({'id': user_data.id, 'displayName': user_data.displayName});

  var page_url = window.location.pathname;

  jQuery.ajax({
    type: "GET",
    url: "/recogito_integration/get",
    dataType: 'json',
    headers: {
      'pageurl': page_url,
    },

    success: function (data) {
      console.log(data);
      for (annotation in data) {

        w3c = convert_annotation_w3c(data[annotation]);
        if(w3c.type != "Annotation" && imgElement["src"] == w3c["target"]["source"])
        {
          anno.addAnnotation(w3c);
        }
      }
    },
    error: function (xhr, status, error) {
      alert(xhr.responseText);
    }
  });

  anno.on('selectAnnotation', function (annotation) {
    highlightAnnotatedContent(annotation);

  });

  anno.on('createAnnotation', function (annotation) {
    create_annotation(annotation);
  });

  anno.on('updateAnnotation', function (annotation, previous) {

    console.log(annotation);
    console.log(previous);
    update_annotation(annotation, previous);
  });

  anno.on('deleteAnnotation', function (annotation) {
    delete_annotation(annotation);
  });

Thanks in advance for the help.

Hard to tell since that's definitely not the normal Annotorious behavior. When you click an annotation, that will fire the selectAnnotation event, so the question is: what does your highlightAnnotatedContent do?

highlightAnnotatedContent just hides some stuff for which the user does not have permission, but the issue is still there when I comment out that line.

I just confirmed that this works as intended in Annotorious standard, v2.4, with image enclosed in <p>, in read-only mode. That means there must be something specific in your code.
If you can create a live example online where I can reproduce this, I'm happy to take a look.

Thanks.
I think I see the issue, for some reason the editor's display attribute is set to none so it is being hidden, I am working on fixing it now.

Just checking: were you able to resolve this and/or figure out what's causing it?

I wasn't able to figure out what was causing the issue but I worked around it in CSS, ```javascript
.r6o-editor{
display: block !important;
}

Interesting. The editor is a <div> and has block as the default display property. I.e. this must be some external stylesheet on your page "bleeding through", and overriding the editor <div>s default display. In that case, forcing it back like you did is exactly the right way to fix it, I'd say. (I'm closing the issue.)


feat (BDD) : NDM integration testing

Added YAMLs for integration testing
Udev functions for simulating devices. The udev functions could be used to trigger fake udev events so that ndm detects the events and updates the CRs. functions will be required to create a fake disk,
trigger add/remove/change events
sanity tests will be done in a single node minikube cluster and functions for interfacing with the cluster is included.The cluster start and stop is not included as this will be done by the VM. Status of cluster, and generation of kube-config files will be checked
package to query kube-API server and retrieve results in a predefined format is included. The various resources like configmap, CRD etc can also be created using this package. These resources will be created using the YAMLs
The basic tests include:
a) running NDM and checking for pod
b) checking for sparse disks
c) check for external disk already attached
d) check for external disk attached at runtime

Signed-off-by: Akhil Mohan<EMAIL_ADDRESS>

Codecov Report

Merging #236 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #236   +/-   ##
=======================================
  Coverage   51.48%   51.48%
=======================================
  Files          49       49
  Lines        2259     2259
=======================================
  Hits         1163     1163
  Misses       1007     1007
  Partials       89       89

Continue to review full report at Codecov.

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


feat: add api key support

This PR adds API key support. Internal doc: go/gapic-api-key-support
The new logic is:
(1) if API key is provided via StubSettings.apiKey, use the API key, we are done
(2) if both GOOGLE_API_KEY and GOOGLE_APPLICATION_CREDENTIALS env variables are set, throw exception; if GOOGLE_API_KEY is provided, use the API key; otherwise, use the normal ADC flow.
This PR has been tested with java-language. https://github.com/arithmetic1728/java-language/pull/1

Please remove "Do Not Merge" when ready.

Will remove the "Do Not Merge" after a manual test with samples.


Missing Repos from Configure CLA

We are running a private install of CLA assistant.  I upgrade to the latest version last week.  We recently add a new org  in Github.  We would like to add some of the repos from the new org to CLA, but I am not seeing them in drop down list.  I can see the original 2 orgs, but not the new one.  I am owner on the Org, so I should be able to see them, right?
What settings are required in the new org to ensure it shows up in the list?
Steps to reproduce the problem:

Setup CLA
Login with github cred
select Configure CLA
select choose a repo

What is the expected result?
Get a list of all repos that I have admin permission
What happens instead?
I get the original 2 orgs, but I don't get my new one.

Could you check your GitHub settings as described in this comment, please: # 176 comment

I did see this.  I think that I have this correctly set.  The new org is the last one on the list and is authorized for this application.

Ok, can you check also the Third-Party Access policy in the settings of your org, please?

Closing this issue.    Didn't realize that this only pulled in public repos.


chore: Use workspaces feature for our JS packages

Rationale
We started to have multiple JS packages in our project: frontend, relayer, subgraph. Besides, we have dependencies on the top level package.json that are only meant to be used with the contracts.
The benefits of workspaces are: This will allow installing the dependencies of all of our JS packages by one command. Yarn will automatically enhance the installation and make it more performant. Commands can be run from the top level of our project folder. We will have only one lockfile.
Implementation
See this: https://classic.yarnpkg.com/lang/en/docs/workspaces/
Btw this npm preinstall script on the top-level package.json should prevent the usage of npm in our setup: "preinstall": "npx only-allow yarn"
Additionally, I would like to see moving the linting / formatting dependencies of the contracts inside its own package.json inside the contracts folder. npm scripts should be added for running it. These scripts should be referenced in the makefile. Adds another layer, but that's a proper setup of JS dependencies. If a change on the linting / formatting command has to be made, it should be done in the package.json.
Another addition, the pkg build of the relayer should also be an npm script and not be inside the makefile.

Me like this. Lets look into it as a part of the "technical debt" phase next month.


Duplicate deploy section on docker swarm docker-compose file

There is a duplicate deploy section on https://github.com/zatosource/zato-build/blob/master/docker/swarm/docker-compose.yml.template#L105 (there is another one on line 127)
This causes issues when running the dockerize command.

Thank you for the ticket, we will have a look soon.

Sorry, I spoke too fast.
I followed the while installation workflow from https://zato.io/docs/admin/guide/install/py3/swarm.html on a newly created cloud instance and it got working without issues from dockerize (basically dockerize does not care what it templates)
What I meant to say in my first attempt, is that the generated docker-compose.yml is not valid, because it contains duplicate keys.  VScode hilighted the duplicate key and I noticed it.
Sorry for not being clear the first time around.  I think the issue still stands, though!

Right, I understand it. I do not specialise in Docker though and @DimShadoWWW is our Docker person - he will follow up. Thanks again.

Hello @stratosgear ,
Thank you, I will update the template and upload the correction after the tests.


Support S3 log streaming

Is your feature request related to a problem? Please describe.
S3 log streaming is now an option. We should add the JSON body

Tracking internally at https://github.com/tailscale/corp/issues/24533


bazel: workaround invalid nonnull warning in v8

Since gcc 12 it seems there are some false positives around this warning.
Upstream gcc reports:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107252
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199

We can't use --per_file_copt in this case because we build this in the host configuration https://github.com/bazelbuild/bazel/issues/12406
Upstream v8 report: https://bugs.chromium.org/p/v8/issues/detail?id=13441
Fixes https://github.com/envoyproxy/envoy/issues/23692
Signed-off-by: Keith Smiley<EMAIL_ADDRESS>

/retest

/retest


Support loading RX2/REX file using SMDI

Support loading RX2/REX file using SMDI
This is kind of a two-part feature request.
It'd be awesome to stick Recycle files (RX2/REX) on the device and load the individual samples into the sampler via SMDI.
https://github.com/ehasting/zoeos/tree/master/ExternalLibsAndTools/Deprecated/NativeLibs/OpenSMDI

@Ruxton Do you know of usage examples of OpenSMDI with other SCSI storage devices? It is not clear to me that any kind of work is needed on the RaSCSI side to enable this protocol.
A facility for uploading arbitrary file to the RPi's file system is easy enough, if that's what you're asking about.

A facility for uploading arbitrary file to the RPi's file system is easy enough, if that's what you're asking about.

This would be the first part, the second part would then need a "SMDI Send to device" on those files that:

processes the REX/RX2 into it's individual slices/samples
initate and SMDI session over SCSI
send the samples over SCSI using SMDI

Examples of things that do this:

Recycle 2.0 allows you to send like this, but there is no longer support and getting it working these days is becoming annoying
Chicken Systems Translator Professional can send packs of samples like this
https://sourceforge.net/projects/esmdi/files/esmdi/0.1/
SoundForge used to do this, not sure if it still does

Also, there is:

[Peavey's original spec for SMDI]
(https://github.com/ehasting/zoeos/raw/master/ExternalLibsAndTools/Deprecated/NativeLibs/OpenSMDI/UnknowCrap/smdi.pdf)
OpenSMDI Manual

@Ruxton Understood, thanks for the overview. I had a look at the OpenSMDI library code and quickly realized that it is for Windows, and depends on VS2007 to compile. Are you aware of a Linux version of this library? In my opinion it is out of the scope for RaSCSI to implement a proprietary protocol and manage compatibility with a range of non-standard hardware clients, so we absolutely must have a 3rd party library that provides this layer to even consider the feature request.
While I can see how this would be an incredibly useful feature for sampler users, with the information we have right now I honestly don't think it's feasible.

I uploaded the original spec to archive.org for posterity and discoverability -- https://archive.org/details/smdi_20220929
It is a non-free file so I don't think it's correct to be distributing it in a GPL repo.

Set up forks for OpenSMDI and ESMDI on GitHub (distributed under GPL3) and started modernizing the C code to compile on Linux.
https://github.com/rdmark/OpenSMDI
https://github.com/rdmark/ESMDI
Still absolutely no guarantees, but I felt compelled to at least get these two pieces of code to a working state as a POC. Plus, it seems noone has ever properly put them under revision control, and were floating around in tarballs on archive.org and elsewhere, so I thought this was the dignified thing to do. :)

thanks for your efforts @rdmark
It's definitely something i could help with as a programmer and owner of an e-mu ultra sampler. I just dont have my RASCSI setup yet due to the Pi shortages, so it's gonna be a while til i come across one or they start shipping again O_O and with no exposure to this project, i felt it was best to raise the request first and get the conversation happening.

I got both OpenSMDI and ESMDI to a state where they compile and link on Debian (gcc 10 and 12), x86_64 and ARM. The statically linked esmdi crashes instantly, so there's certainly still some more progress to be made. But at least it is something!
If you're good at debugging Linux software please by all means clone the repos and see what you can figure out! PRs are very welcome. :)
BTW, I set it up so that OpenSMDI is a submodule of ESMDI. So you need to initialize the submodule when closing ESMDI. F.e.:
git clone --recurse-submodules [repo URL]

After cloning ESMDI, you want to first compile the OpenSMDI libraries (cd opensmdi && make), and ESMDI second.


Value of type 'UIImageView' has no member 'kf'

Issue Description
after installing kingfisher it give the error "Value of type 'UIImageView' has no member 'kf'" using swift 3.2 in xcode 9 & pod version 3.x
What
Able to access member variable on compile time by auto complete but after building it give this error.
Reproduce

@onevcat  kindly, can you check please ?

@SURYAKANTSHARMA Can you paste your Podfile.lock as well?
nd remember to add import Kingfisher before you try to use any API from Kingfisher.

import Kingfisher is previously there.
issue get resolved ,It work perfecty fine now, I don't think it is your library issue because it is while i am upgrading xcode and swift version. But it look weired when autocomplete give suggestion while writing the code and get error on building the project.

Maybe it's an Xcode issue. Usually restart Xcode / clean derived data path would fix it.


Add support for filtering to a set of prefixes

Filtering to a set of prefixes would allow searches to take the view of a single ontology or identifier source, allowing large and detailed identifier sources like UMLS to be filtered out when not needed. The specific need here is from the UI, who have found that filtering to MONDO (and possibly HP) removes a lot of problematic matches, and would like NameRes to handle this so that they don't need to reduce the number of results when they filter these results at their end.
Theoretically, there are two ways in which we could do this:

Filter only on the preferred identifier, i.e. concept A with a preferred ID of MONDO:1234 and a secondary ID of HP:4567 will be returned if filtering on MONDO but not if filtering on HP.
Filter on any identifier, i.e. concept A with a preferred ID of MONDO:1234 and a secondary ID of HP:4567 will be returned if filtering on MONDO AND if filtering on HP, but not on other prefixes.

I think the first approach is fine for an initial implementation, but we can also implement the second if needed. Of course a complete implementation would included both filter_only_prefix and filter_out_prefix fields, but to meet this use-case we only need filter_only_prefix.

We have now implemented this for the first approach. Closing.


Boxstarter does not recogniz Chocolatey v<IP_ADDRESS>

I setup a machine initially using a Boxstarter package script launched from the web.  I then upgraded chocolatey to the latest version.  Made some changes to the script and attempted to run again and it thinks chocolatey is no longer installed and so attempts to install again.
Is there a way around this?  Can boxstarter be upgraded to work with the latest version of Chocolatey?

I apologize for this confusion. So currently, boxstarter does not work with the new chocolatey. There are some fundamental modifications that need to be made to boxstarter for it to work with the chocolatey rewrite. This is an important issue that I do plan to address. In the meantime, boxstarter will install the last powershell based version of chocolatey if it is not present. It does this using a modified installer so that if you have the newer version, the two will coexist peacfully and the older version will only be used by boxstarter while normal commandline calls to chocolatey will use the newer version.
This seems to be getting many folks confused. I'm inclined to add some messaging to that install to make it more clear what is happening.

This caught me by surprise. We're using an authenticated feed and with the new chocolatey we no longer needed the nuget credential workaround. Not a huge issue to fix (just keep the workaround for boxstarter). Does the issue stem from the chocolatey command interception?

Thats correct. Boxstarter runs chocolaty in its own PS session and "monkey patches" a few of its functions. I have done some prototyping with using the choco.dll and it is possible to accomplish the same functionality but needs quite a bit of work.

Do you end up treating the new choco like an ABI?

I just released v2.5.1 whose main focus was to further isolate the boxstarter specific chocolatey install from any user install and add extra messaging during the install and on each chocolatey package install to clarify that boxstarter uses its own version. Hope this helps.


Update storage-table-design-guide.md

Trying to get page ready for update

#sign-off

Hi @jasonnewyork, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (jahogg). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@jasonnewyork : Thanks for your contribution to the Azure documentation! The author, @jasonnewyork, has been notified to review your proposed change.

Microsoft authors of articles need to make updates through the private repository so the updates can be staged and validated by the current validation rules. After you review staging and fix all validation issues, you can add the sign-off comment to let the PR reviewers know the updates are ready to be merged.
It�s easy to access the private repo version of your articles in GitHub. Just add �pr to the URL, as follows:
Public repo URL: https://github.com/Azure/azure-content/blob/master/articles/azure-portal-overview.md
Private repo URL: https://github.com/Azure/azure-content-pr/blob/master/articles/azure-portal-overview.md
We've closed this pull request. Please resubmit the updates through the private repo. If you need perms to the private repo, see the contributor guide instructions.


Support for session enabled queue

Please explain or add example on how to receive message from session enabled queues.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ae05c9ae-995f-def7-91fd-3210d4cd6178
Version Independent ID: c6456f34-7074-28bb-e897-b32e9d04e5ad
Content: Use AMQP with Java Message Service API & Azure Service Bus
Content Source: articles/service-bus-messaging/service-bus-java-how-to-use-jms-api-amqp.md
Service: service-bus-messaging
GitHub Login: @axisc
Microsoft Alias: aschhab

@dreamuth Thank you for your feedback! We will review and provide an update as appropriate.

@axisc / @spelluru Do we any sample available for this ? Please provide your thoughts here.

Yes, this is available in the Azure Service Bus under the samples folder

This page is dedicated to JMS, I couldn't find any example for JMS with session enabled queue. Could you please provide the exact link to the sample file?


Needs license

Hi! Just making sure you know, this repo is missing a license. I'm planning on doing a contribution (I wanna get the beta client working), but I need to know what license this is under before I do that.

Ah my bad. Lemme throw one on.

Closed by 5613508e3a44357246b26df270c0dee2ad3950ce!


Assertion fails on node_drawer.rs:35

Hi all,
I managed to compile build_octree and sdl_viewer, and I created a octree directory from my .ply file. But when I try to visualize it with sdl_viewer I get the following error:
[mellon@mellon-hp loc_acquisition_2019-05-28-08-10-36.velodyne_only.octree]$ RUST_BACKTRACE=1 ~/Source/google/point_cloud_viewer/target/release/sdl_viewer .
Currently visible nodes: 3927, time to calculate: 2.710629ms
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `5001`,
 right: `6668`', sdl_viewer/src/node_drawer.rs:35:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: std::panicking::begin_panic_fmt
   7: sdl_viewer::node_drawer::reshuffle
   8: sdl_viewer::node_drawer::NodeViewContainer::consume_arrived_nodes
   9: sdl_viewer::PointCloudRenderer::draw
  10: sdl_viewer::run
  11: sdl_viewer::main
  12: std::rt::lang_start::{{closure}}
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
  15: std::rt::lang_start_internal
  16: main
  17: __libc_start_main
  18: _start

As you can see it seems to come from the parameters given to the reshuffle function.
For info I'm using Fedora 29, and I installed all the required packages using dnf: rust, protobuf-compiler, golang, cmake, SDL2, and SDL2-devel. Rust gRPC protobuf plugin was intalled using cargo install grpcio-compiler as indicated in the README. The symbolic link on target/protobuf/bin/protoc to the systems protoc is set. The local cargo environment is added to my PATH:
[mellon@mellon-hp loc_acquisition_2019-05-28-08-10-36.velodyne_only.octree]$ echo $PATH | tr ':' '\n' | grep cargo
/home/mellon/.cargo/bin

And I'm using Rust 1.35.0:
[mellon@mellon-hp loc_acquisition_2019-05-28-08-10-36.velodyne_only.octree]$ rustc --version
rustc 1.35.0

Any ideas on how to solve this ?

Hi Ellon,
sorry to hear you ran into problems.
Just 2 hours ago we fixed a severe bug affecting octree generation (see #296). Can you please try build_octree again and see if it now works?

Hi @feuerste,
Thanks for your reply.
Indeed I was one commit behind the one that fixed this bug (bad timing for a git clone :laughing: ). It seems to work fine now. :) Thanks !


Move Bot code to attachment

In the original design of Medplum Bots, our hypothesis was that bots would be limited to 10-20 lines of JavaScript code for short snippets of logic.  Therefore, we chose a simple "string" property for bot source.
Over the past 2 years of Medplum Bots in production, we have been quite surprised by the creativity of our users.  Almost immediately, we noticed users submitting full Webpack bundled outputs.  As Bots grew, users wanted to use TypeScript over JavaScript.  That "breaks" the current experience in notable ways:

Inefficient database representation
Ugly diffs / change tracking
Ambiguous usage for "TypeScript" vs "JavaScript"

Proposal:

Mark the current Bot.code as deprecated.  We will continue to support it indefinitely, but it will not be the recommended path.
Add new Bot.sourceCode property with type Attachment.  Optional property that represents the original source code.
Add new Bot.executableCode property with type Attachment.  Optional property that represents the post-build executable code.
Update the <BotEditor> component to upload code as FHIR Binary resources, and updates the sourceCode and executableCode properties with references to the Binary resources.
Update the CLI bot commands to do the same.
Update the $deploy operation (see below)

On sourceCode vs executableCode:  This is intended to manage the reality of TypeScript vs JavaScript.  Users often want to save the original TypeScript source.  But we cannot execute TypeScript, so users need to upload the executable JavaScript which is the output of their build process using tsc, webpack, rollup, vite, or whatever.
While both sourceCode and executableCode are marked as "optional", obviously one of them will be required for the $deploy operation.  When deploying a Bot, the logic will be:

Use executableCode if available
Otherwise use sourceCode
Otherwise throw an error

Interesting to see this evolving - unexpected!

Fixed in https://github.com/medplum/medplum/pull/2528


Fix build with LibreSSL 2.7

LibreSSL 2.7 adds OpenSSL 1.1 API leading to conflicts in method names
See also: https://bugs.freebsd.org/227187
Signed-off-by: Bernard Spil<EMAIL_ADDRESS>

Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement.
After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.

User @Sp1l isn't covered by a CLA. They will need to complete the form at https://identity.linuxfoundation.org/projects/cncf

Regards,
CLA GitHub bot

Patch provided under MIT license.

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

@jboeuf   @nicolasnoble what are your thoughts on supporting LibreSSL in general?
@Sp1l  two issues I have with this PR:

it doesn't explain in detail why supporting LibreSSL would be beneficial (new platforms supported? differences between OpenSSL and LibreSSL?) and why it would outweigh the maintenance costs.
anytime we add "support" for some library/platforms, it is also wise to add the tests to make sure the support won't get broken in the future (with no test it's pretty much guaranteed to become broken sooner or later).

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Cleaning up old PRs.  If this is still something you want to pursue, please re-open.


Remove cookies middleware

Note Since version 1.5.0, the cookie-parser middleware no longer needs to be used for this module to work. This module now directly reads and writes cookies on req/res. Using cookie-parser may result in issues if the secret is not the same between this module and cookie-parser.

See https://github.com/expressjs/session

It's amazing how many people are still including it in their Express code, I see it every single day. lol

It's amazing how many people who are still including require('cookie-parser') in their Express code, I see it every single day. lol

Hey,
It really is.
But what I would like to know is how the process may be done via express-session.
Do you know any ways of setting a cookie via an express-session, without cookie-parser.


Add Our Testimonial Component.

Deliverables

Add Our Testimonial Component.
Use Dummy Data.
Add Hover Effect.

Sample

Additional context

Tech/Framework:- React Js

I would like to work on this issue. Please assign me.

@shreyanshi16 at the same time we assign only one issue. So kindly complete the assigned issue. after you can work on it :)

@codewithvk may I work on it?

@Castella1313 we need to code it. Are you interested?

Can I work on this issue?

@Castella1313 we need to code it. Are you interested?

yes I'm :) please assign it to me

@Castella1313 No, we don't need to add a button.


added dmenu config variable & started experimenting with xdotool

I really like your tool!
what I did is just added some dmenu configs to make it look like the current dmenu that I'm using and added a couple of lines to experiment on having this script actually paste what I  select on the program :-)

I don't understand the point of dmenu_config at all, just pass in your dmenu args to the script, they will work.
Using xdotool to press a certain sequence of keys that you assume map to a "paste" action is a recipe for disaster.
I won't merge anything involving hardcoding dmenu variables, since the whole point is that they are transparently passed to dmenu -- just pass them to the script (see the readme).
I would consider one that has a sensible method to paste directly.

Maybe instructions how to customise clipmenu from dwm's config.h? E.g.
static const char dmenufont[] = "-*-terminus-medium-r-*-*-18-*-*-*-*-*-*-*";
static const char *clipcmd[]  = { "clipmenu", "-fn", dmenufont, NULL };

I don't see why one should tell people how to edit config.h in something that is totally unrelated to config.h...

Just an example to show how clipmenu is run...

That's fair enough, although I don't think adding examples for config.h makes sense by itself.
I added some information in the readme at d5a944917.

Closing this out for now, but I'm still open to a patch with xdotool if you'd find that valuable to your workflow. :-)

I have been working on other projects but I'll take a look at this later. What you commented about hardcoding dmenu variables makes total sense... I really didn't followed your logic until I took a closer look. I'll experiment a bit more with xdotool or other alternative, what I'm trying to accomplish is something similar to what other clipboard managers do, say, when a text is selected is automatically pasted. Thanks anyways!


Create a MapOperator Factory

The source has been refactored so all map operators reside in a single sub package. Add a factory to this sub package for building map operators.

This has been added. The factory works of a parameter list input. The parameter "Map Type" indicates the name of the map to be built. A sublist also named the same as the "Map Type" parameter value must exist and contain the necessary information to construct the subclass. Similar subclass types (i.e. point cloud operators) have their own factories called from this higher level factory.


 You all do a great job! :-)
But something that makes me a little bit confused is the documentation about this project because some parts of it seem to be very outdated. For example within lucetc there are many different options like witx_specs, wiggle_bindings or veriwasm (there are other, too) which are not documentated (But which are very important).
In a very rapidly changing ecosystem like wasm this makes it sometimes really hard to stay on track with that project. Maybe there are other people thinking the same? Is there any documentation i maybe not found? Currently the repo is my first source of documentation about lucetc/lucet-wasi/etc. but there are some parts which are hard to understand.

Hi, we are focusing all our efforts on Wasmtime these days, and don't suggest using Lucet for new projects. For the last year or so Lucet is only getting minor updates to its dependencies (we track updates to cranelift) and some improvements required for Wasmtime feature parity. We suggest all users switch to Wasmtime as soon as they can - it now has all of the features that previously only Lucet had, like AOT compilation and userfaultfd-based memory pooling.

Allright, thanks!


Accessibility support

When I start talkback on my device all pages are read at once. I would expect just the current one

This is because the pages are not stacked on each other but layed out horizontally out of the view of the device. So I can see why all the pages were read.

Are you interested in changing that wrong behavior?

The trick is to use ExcludeSemantics. Check this: https://youtu.be/bWbBgbmAdQs?t=681

I will see if this is a viable solution some time in the future.

Ah you won't do it anyway it would help other...


Implement retry in case of error

🚀 Feature Proposal
Implement a new "retry" option in @loadable/component.
Motivation
We monitor our errors with Sentry and we see quite a lot of errors coming with lazy-loaded components. Indeed, on flaky network, it's easy to have a request aborted and the component is never loaded. In our applications, we have started to wrap all dynamic imports passed to loadable with a retry function such as:
const Example = loadable(() =>
  retry(
    () => import('./Example'),
    { retries: 3 }
  )
)

where retry is a simple function:
type Options = {
  retries?: number
  interval?: number
  exponentialBackoff?: boolean
}

// taken from https://dev.to/goenning/how-to-retry-when-react-lazy-fails-mb5
export function retry<R>(
  fn: () => Promise<R>,
  { retries = 3, interval = 500, exponentialBackoff = true }: Options = {}
) {
  return new Promise<R>((resolve, reject) => {
    fn()
      .then(resolve)
      .catch((error) => {
        setTimeout(() => {
          if (retries === 1) {
            reject(error)
            return
          }

          // Passing on "reject" is the important part
          retry(fn, {
            retries: retries - 1,
            interval: exponentialBackoff ? interval * 2 : interval,
          }).then(resolve, reject)
        }, interval)
      })
  })
}

Example
const Example = loadable(() => import('./Example'),  {retries: 3})

Pitch
I'm wondering if this is something that could be directly implemented as part of loadable.

Good point. As a matter of fact - our own Sentry is filled with the same reports.

If you agree, I'd be happy to work a PR.

That could be a little complicated as right now errors are just thrown, expected to be handled on the nearest ErrorBoundary.
The question - should network problems be still reported (so the error has to be thrown), or in case they are retry-able loadable can swallow them?

I don't know if you are able to differentiate network errors from other kinds of errors when using dynamic imports. Do you know?
Regarding errors just being thrown at the moment, if the retry is optional, we could still retry all errors as it would not be a breaking change. What do you think?

I don't know if you are able to differentiate network errors

You can, but that is abstraction leaking, so you should not try to differentiate.

Regarding errors just being thrown at the moment...

This moment can alter the implementation a lot. Providing ErrorBoundary with built-in retry mechanism and built-in reporting can be a better solution, and actually can be done right now. Well, almost - such error boundary cannot distinguish LoadableError from any error coming from within loaded content. So we are circling back to the problem of "how to differentiate"

I might be missing something but I think the retry function I shared in my issue is only retrying errors related to the dynamic import, not errors within the loaded component.
By the way, I deployed it on our main app in production and almost all the ChunkLoadError are gone.

If only error boundary could detect chunk loading error (thrown by loadable) - then it can do retry.
Wrapping import with any extra code is breaking SSR. There is an update to a babel plugin to make that impossible as well.

Wrapping import with any extra code is breaking SSR. There is an update to a babel plugin to make that impossible as well.

What do you mean by "breaking SSR"? We use this technique on an SSR application and I didn't notice any issues. 🤔

Hello!
Facing the same issue some time. I would like to try @ValentinH solution, will let you know when it will be tested it on production

I think this issue is still relevant. My last question was not answered actually.

What do you mean by "breaking SSR"? We use this technique on an SSR application and I didn't notice any issues. 🤔

Loadable babel plugin is reading your imports and create another structure which is expected to "do the same". But logic there is very simply - it reads a file from the import and rewrites it to require for SSR. In other words - all your "additions" will be just discarded.
See test - https://github.com/gregberge/loadable-components/blob/main/packages/babel-plugin/src/snapshots/index.test.js.snap#L27-L56

Actually, I'm fine if my addition are discarded for the server bundle. The important thing here is to retry on the browser one. Or do you mean that it will actually break the require on the server?
I checked and on our applications we actually only use loadable in components that are wrapped with NoSsr wrappers.

It's more about the general unpredictibility of the result.
Let's double-check if #511 can solve your issue. Probably with the minimal changes we can teach guard to retry import if needed. cc @hedgepigdaniel

It's more about the general unpredictibility of the result.
Let's double-check if #511 can solve your issue. Probably with the minimal changes we can teach guard to retry import if needed. cc @hedgepigdaniel

Hmm maybe - perhaps if guard received a createImportPromise/tryImport (that could be called multiple times to retry) rather than an already created importPromise

Sounds correct. However, before doing anything we should double-check our ability to measure and report such problems.
So, @ValentinH - how did you found that you have this problem? NewRelic, Sentry, other custom error monitoring? Is there something we can do better here?

I found this issue thanks to our Sentry integration. If I recall correctly the error was "Chunkload error". When we started wrapping all our dynamic imports with the retry function I shared in the original post, we noticed a clear decrease of that error.

hi guys..any update?

@hedgepigdaniel is busy right now a little but I hope quite soon we'll break the status quo.

This issue is still relevant.

This issue is still relevant.

Any update on this topic, I think it's still relevant what @ValentinH suggested!

I'm currently trying to use the retry function created by @ValentinH to wrap my import statements as follows:
const SomeComponent = loadable(() => retry(() => import('./SomeComponent')))

The code works great (thank you!) but unfortunately it masks the types of the props of SomeComponent. I've tried to import types from loadable__types but haven't found a way to pass the props from retry to loadable.
For instance, this attempt:
import { DefaultComponent } from 'loadable__component'

type RetryType = () => Promise<{ default: React.ComponentType<any> }>

export function retry(
  fn: () => Promise<DefaultComponent<RetryType>>,
  { retries = 3, interval = 500, exponentialBackoff = true }: Options = {}
) {
  return new Promise<<DefaultComponent<RetryType>>((resolve, reject) => {
    fn()
      .then(resolve)
      .catch((error) => {
        setTimeout(() => {
          if (retries === 1) {
            reject(error)
            return
          }

          // Passing on "reject" is the important part
          retry(fn, {
            retries: retries - 1,
            interval: exponentialBackoff ? interval * 2 : interval,
          }).then(resolve, reject)
        }, interval)
      })
  })
}

...gives this error:

...Type 'Promise<typeof import("path/to/file")>' is not assignable to type 'Promise<DefaultComponent>'.

Any suggestions on improving the type of the retry function?

@YPCrumble you need to use a generic signature. I have updated my original message with what you are looking for 😉

@ValentinH worked perfectly, thank you @ValentinH !!!

This issue is still problematic, if it's not prioritized / fixable at the moment can we link this in the docs? Discoverability of this solution can help future users from wasting few hours hopefully.

Not stale

Funny how I also did the exact same thing with retry and it works.
I'm not sure if it should really be incorporated in this library though, its easier to maintain one simple library than a do-all giant.
An entry in the docs would suffice, if you ask me.
Another entry I'd expect (which is what I was looking for, and stumbled upon this issue instead) is to generally describe some good practices on what to do in case of fail, so how to "wrap" things with try catch and what are our options to safely recover from this (because even retrying network requests will return with error eventually, unless you want to repeat it indefinitely)

Not stale


Throwing a warning with react-router

I'm getting the following when attempting to use this with react-router:
Warning: [react-router] You cannot change <Router routes>; it will be ignored
I tried wrapping  and also wrapping the components rendered by react-router and got this warning both ways.

We do not change anything that is passed in so this is not related to React Sidebar.

@balloob that warning gets thrown only when React Sidebar displays itself, so it does seem to be caused by React Sidebar (i.e. when I drag the cursor in from the left to show the sidebar via its built in swipe-to-display, the warning appears)

Looks like it was caused by pulling the Router block into a component, which I did to gain access to the provider-provided state for setting open.


Version 53 build failure on Debian stretch.

warning: unknown warning option '-Wno-undefined-var-template'; did you mean '-Wno-undefined-internal'? [-Wunknown-warning-option] warning: unknown warning option '-Wno-nonportable-include-path'; did you mean '-Wno-gnu-include-next'? [-Wunknown-warning-option] ../../printing/backend/print_backend_cups.cc:243:21: error: use of undeclared identifier 'cupsGetPPD'     ppd_file_path = cupsGetPPD(name);                     ^ ../../printing/backend/print_backend_cups.cc:256:21: error: use of undeclared identifier 'cupsGetPPD2'     ppd_file_path = cupsGetPPD2(http.http(), name);                     ^ 2 warnings and 2 errors generated. [9649/19401] CXX obj/device/bluetooth/device_bluetooth.bluetooth_remote_gatt_characteristic.o
This seems to be the issue

../../printing/backend/print_backend_cups.cc:243:21: error: use of undeclared identifier 'cupsGetPPD'

Version:
53.0.2785.116-1.2

This is more likely an issue with cups or the chromium source code but would like to hear about possible fixes or workarounds.

Chromium 53 is going to be phased out very soon. If you want, you can use a snapshot of the repo at 1a246c50b9c78a95c024442156d244baff26c54a and build Chromium 54 (which is what I'm using right now). I haven't tagged 54 because I didn't finish porting to all of the platforms. But I just discovered that Chromium 55 released, so I'm currently in the middle of upgrading the patches to that.

Thanks for getting back to me. This will work great thanks. I look forward to 55 being available in the future.


NumberBox does not respect ThemeManager theme

I implemented NumberBox in my application that is set up to work in Dark Mode. However, NumberBox did not respect the theme.
Specifying ThemeManager.RequestedTheme on the control itself can be used as a workaround.
<ui:NumberBox Header="Clients to start" Value="{Binding NumberOfClientsToStart, Mode=TwoWay}" InputScope="Number" SpinButtonPlacementMode="Compact" Text="Clients to start"/>

<ui:NumberBox Header="Clients to start" Value="{Binding NumberOfClientsToStart, Mode=TwoWay}" InputScope="Number" SpinButtonPlacementMode="Compact" Text="Clients to start" ui:ThemeManager.RequestedTheme="Dark"/>

Apologies. This was submitted to the wrong repository by mistake.


[Discussion] End Goal of Dogecoin

It seems the end goal for Dogecoin is for everyone to be a miner + Dogecoiner.

High decentralization
Having coin utility
High security; improbable to have 51% attack

Yet, the compute complexity rescaling of Proof of Work does not seem to incentivize this goal.
The more people join the mining pool, the less reward per miner & higher power consumption per block
It means: The more people join mining, the more inefficient decentralized mining becomes.
Proposed alternative:
Use non-intrusive identity verification.
Periodic verification of identity of miner based on:

Data labelling to help the science and engineering community (captcha) or
Monthly Dogecoin spending
(Selected based on miner's privacy preference)

The verification produce a scaling factor for the block reward for each miner.
How does this drive Dogecoin towards the end goal:

Develop Dogecoin utility / adoption in science and engineering community.
Promote spending of Dogecoin; centralized hoarding address will receive less block reward.
Move away from the complexity rescaling heurstic; block time can scale linearly as more people join

Constructive discussions below
Super Franky

If there is a Dogecoin spending API (something like OpenBanking API), I can code a lite neural net to produce desired block reward scaling factor

Hi! Do you have any code towards this?

Hi! Do you have any code towards this?

Data Labelling tools and library: https://github.com/heartexlabs/awesome-data-labeling

UI can be copied from Amazon's SageMaker: https://github.com/aws-samples/amazon-sagemaker-ground-truth-task-uis

For monthly Dogecoin spending, some codes need to be developed on the wallet app.

OpenBanking API can be helpful: https://github.com/adorsys/open-banking-gateway

All of this can be done without changes to Dogecoin Core? Please develop this, it's awesome! Let us know on reddit how you progress! https://www.reddit.com/r/dogecoindev/

All of this can be done without changes to Dogecoin Core? Please develop this, it's awesome! Let us know on reddit how you progress! https://www.reddit.com/r/dogecoindev/

All of these need to be done directly to the Dogecoin Core.
Complexity rescaling needs to be replaced by Data labeling and Dogecoin monthly spending.
This is a direct change to the core of Dogecoin mining algorithm.


Added support for Google material icons in icon-button element

@hai-cea Fixed the missing quotes on className="material-icons"

@Zadielerick Can you sync with master pls?


Bug: The automated rebirths don't harvest Yggdrasil and don't use blood NUMBER boosts before rebirthing

Title says all

at least for me, ygg harvest does occur. have not tested blood.

at least for me, ygg harvest does occur. have not tested blood.

Level 4 fruit on a 1 hour (and 2 minute) rebirth. Harvests happen when the fruit is at 4/4, but that's not happening with a 1 hour rebirth. After 1 hour, the fruit is at 1/4. Two minutes later, a rebirth happens and the fruit is wasted because it's not being harvested.

Did not gain a single seed over an entire day with 1h2min rebirths - maybe there is some setting I need to toggle to make sure that all fruits are eaten/harvested immediately ahead of an automated rebirth?

Same issue, auto rebirths don't seem to harvest before rebirthing and blood gets unused.

I believe the function PreRebirth() in BaseRebirth.cs is checking for AnyHarvestable() and if there are any it does a HarvestAll(). The HarvestAll() function probably does not work, unlike ActuallyHarvest(), the latter is a private function while the first is a internal static. Unfortunately I don't know any C# but that is where I'd look first. Btw, the 'Harvest All Now' button too doesn't work, at least for me.


Remove xeger from run dependency

Comment:
The latest version of pydantic_factories vendors xeger. As such, it's not needed as a runtime dependency anymore.

PR welcomed!


For a primitives array, uniqWith(identical) is still much slower than plain uniq, which is much slower than a Set-based implementation

I apologize for bringing this up again, as I have no constructive suggestions.
Thinking about removing our uniqIdentical, differenceIdentical and similar function from our code-base given recent improvements within the library (or at least implement them using With functions), I ran an old test I had and was somewhat surprised by how bad the results were.
http://bit.ly/1PfgsTk (Let it run, it'll finish after some time)

I'm not sure there is anything to do here.  If we can speed up uniqWith(identical) that would be great.  But do note that uniq has different, and to my mind better, behavior than either of the others in your test.  It is testing value equality.  That is what FP is all about.  In the end, uniq returns only a single value, as can be seen in this variant: http://bit.ly/1OmqS60.  The other two return 350 identical values with different references.  Yes, the 350000 had been reduced to 350, but this is still not the correct answer from a value-based perspective.
http://bit.ly/1Omu2qD gives a somewhat different view.  Here, there are a number of different values, with a combination of equal and different references.  uniq is by far the slowest, but it correctly gives the number of distinct values.  If you want to compare references, then the native approach is unsurprisingly quite a bit faster than all the function calls necessary for a *With or *By approach.  This seems to be scaling approximately linearly, so when we hit 350000 values, it's painful: http://bit.ly/1OmsVHp.
If people really want to support a reference-based version, it would be easy enough to use something like R.compose(Array.from, R.constructN(1, Set)) in environments that support it and default to slower implementations elsewhere.  But moving anything to reference equality seems to me a move in the wrong direction.

Of course I don't suggest giving up value equality. But the fact is that for a large list of strings (e.g. guids), all Ramda functions that rely on _contains are providing the exact same functionality as other libraries which rely on reference equality, but with pretty bad performance in comparison. I was under the impression that Scott's work fixed this issue (by providing a faster path for primitive-items arrays), but the situation is still pretty bad, it seems.
uniq is just one example. Lately I've struggling with both intersection and difference.

I'd love to hear suggestions.  One thing that comes to mind is to pass through the list(s) and see if everything is primitive and then use a simpler path for that case, I suppose.
If we can speed up the case that worries you without sacrificing the correctness of the cases that worry me, we'd definitely have a big win.