Thread Safety

I was trying to use cparse in multi threaded application as a expression evaluator and varriable manager. I had to use static mutex in packToken class to ensure thread safety, the performance obviously took a hit. Is there a better way to do this?
Thanks

Uhm, so what you have is multiple threads writing to the same TokenMap or PackToken at the same time. So I can try to think of some alternatives, but I might need more info to understand which options we have.
One possible option might be to just change the architecture of the project so that threads communicate using a safe channel, as in "passing messages" instead of "sharing variables", but this depends on the specific problem.
A strategy that I love to use in other languages is the BlockingQueue strategy, where you only send messages from one thread to the other using these queues, if the queue has a max limit and it is full the thread sleeps. Then on the other side if a thread tries to read from the queue and it is empty it sleeps, otherwise, it just gets the data and continues.
You could for example create a new "channel" or "blocking_queue" type in your language and use it for synchronization:

https://github.com/cparse/cparse/wiki/Defining-New-Types

This strategy would allow you to keep the packTokens as fast as they normally are and only pay for the extra synchronization price when using the channels.
However, after a quick search, it doesn't look like we have a standard implementation of that concept available neither on the std library nor on boost =/. But we still have some code snippets online that might be useful if you are willing to implement that on your own code:

https://stackoverflow.com/questions/9396279/consumer-producer-in-c/9396587#9396587
https://stackoverflow.com/questions/12805041/c-equivalent-to-javas-blockingqueue

If this solved your problem I will close this issue (no hurry though)

Hi,
I have introduced a recursive lock in packToken that ensures safe access. The problem is when we try to run calculator in a parallel thread. The = operation in packToken does a delete base, which cause the calculator to give a segmentation fault when resolving refTokens. I am still not able to solve this efficiently.
The application contains multiple threads, some updating packTokens, other evaluating expressions using calculator to do some tasks.
I am using the tokenMap as a shared memory between these threads to communicate. I will go ahead and limit access when calculator is doing it's job. But, I think it can be done more efficiently.
Thanks.

Yeah, so this is just my opinion, but I really think that adding a lock on every packToken might be the wrong approach. For example, I don't think there is any programming language that has built-in locks for every variable exactly because this is very inefficient.
So if efficiency is a concern I would recommend either using explicit locks, which are already available in C++ and should be easier to add to the library than the current approach, or trying some other strategy like the channels I mentioned.
Another interesting strategy is to use immutable structures whenever you can, which is the strategy used by the Elixir programming language for preventing this type of problem.
About the operator=, since you are already forking the library you could try to update the delete method of each type to prevent this segmentation fault. But as I said, this might be complicated.


Fix bug when using host_ip or guest_ip with forwarded_ports

If you use host_ip or guest_ip when setting a :forwarded_port, you end up with a qemu command-line parsing error, as the code puts in extra, unnecessary colons. This patch simply removes these colons.
The patch is untested as I'm very lazy, I'm afraid.

(Happy to raise an issue if you feel it's necessary, my goal has been to make this small fix low-maintenance for you, so happy to do whatever.)

Thanks, I will check this soon

Thanks, go with #49


Update errcheck to e96dacdb078a5166c20b48dd667fb26d2ce0379

It contains useful updates, including suppressing warnings for Write
implementations that will never fail.

Thanks!

I think this has caused errcheck to start erroring on fmt functions that it didn't error on before, ex:
server/events_controller.go:170:15:warning: error return value not checked (fmt.Fprintln(w, "Processing...")) (errcheck)

According to its docs, it should be ignoring these by default:

Note that by default the fmt package is ignored entirely, unless a regex is specified for it.

https://github.com/kisielk/errcheck

Mmm, yep, seems like an upstream problem :\
I'll roll it back.

Actually I can't find that in the README anymore, and it seems this is deliberate:
https://github.com/kisielk/errcheck/issues/140

Which seems reasonable to me, so I will probably re-merge this change.

It's here: https://github.com/kisielk/errcheck/blame/master/README.md#L87
But yes, I think gometalinter should just use the upstream version. I just need to find a way to disable that in my running of it (and probably a lot of people).

For anyone else running into this that wants to disable errcheck and fmt:.* I had to create a .gometalinter.json file because to disable checking fmt you need to use the command errcheck -ignore 'fmt:.*' but you can't specify that as a flag to gometalinter because it uses the : as a delimiter itself.
Also if you're using a config file and you want to modify how a linter runs you need to add a Linters key, which only works if you also have an Enabled key for that linter, which means you need to explicitly enable all the default linters.
My final config file which you will probably want to tweak:
{
  "Disable": ["gotype", "gotypex", "maligned", "gocyclo", "golint"],
  "Enable": [
    "gas",
    "errcheck",
    "deadcode",
    "gochecknoinits",
    "goconst",
    "gocyclo",
    "gofmt",
    "goimports",
    "golint",
    "gotype",
    "gotypex",
    "ineffassign",
    "interfacer",
    "maligned",
    "megacheck",
    "safesql",
    "structcheck",
    "test",
    "testify",
    "unconvert",
    "unparam",
    "varcheck",
    "vet",
    "vetshadow"
  ],
  "Deadline": "300s",
  "Vendor": true,
  "LineLength": 120,
  "Skip": ["server/static", "mocks"],
  "WarnUnmatchedDirective": true,
  "Linters": {
    "gas": "gas -exclude=G104 -fmt=csv:^(?P<path>.*?\\.go),(?P<line>\\d+),(?P<message>[^,]+,[^,]+,[^,]+)",
    "errcheck": {
      "Command": "errcheck -abspath -ignore 'fmt:.*'",
      "Pattern": "PATH:LINE:COL:MESSAGE",
      "PartitionStrategy": "packages"
    }
  }
}

Did you try - - exclude?

No I didn't actually. Thinking about it now that would work but it would be more inexact than using errcheck's -ignore flag because if you excluded .*fmt\..*\;(errcheck\( then you might miss a one-liner like:
myFuncThatReturnsErr(fmt.Sprintf("%s", "string"))


Print status as part of the printer columns

This commit adds support for printing the status
of ANP and BANP when doing kubectl get so that
implementations can let users know the status
of these resources - note that the status field
is not standardtized and is upto the plugins to
implement them according to their logic.
Sample output:
$ oc get anp pass-example
NAME           PRIORITY   AGE   CONDITION                 STATUS   REASON
pass-example   10         13m   AdminNetworkPolicyReady   True     SetupSucceeded

I forget where we landed with this @tssurya Can we close or do we need to make a new issue /and or keep it open?

Closing for now please re-open if needed @tssurya


Feature Request: Restoring Deleted Slices

Is it possible to restore the slices if deleted by mistake or trying to correct an error or some other reason?  It gets stored in a deleted folder or something that can be restored
Thanks

Yeah, just do backups


Mapping aborted at<EMAIL_ADDRESS>

Hi Team,
 "@graphprotocol/graph-cli": "^0.19.0",
 "@graphprotocol/graph-ts": "^0.19.0",

I use graph-node local and BSC Testnet when I deployed the graph node locally but have some issues when mapping the function event.
Mapping aborted at<EMAIL_ADDRESS>line 439, column 6, with the message: Call reverted, probably because an `assert` or `require` in the contract failed,

Do you have faced the same issue?

You are performing a call to a contract without using the try_XXX version. The contract call, for a reason you will need to find, reverts/assert which fails the call (the contract could be non-initialized for example). Closing as this is not an issue with graph-node directly.


Change Log contract to LoggerInterface.

After updating to Laravel 5.6, this message is displayed on error (e.g. wrong column name):
Class Illuminate\Contracts\Logging\Log does not exist

As described in the upgrade guide, Illuminate\Contracts\Logging\Log should be changed to Psr\Log\LoggerInterface.

Is this backward compatible with lower version of Laravel? We may have to do a major bump if not. Haven't updated to 5.6 yet and I can't verify this yet. Thanks!

Maybe we should just use the facade and remove the interface. Or resolve it using IoC app('log') key?

Not tested, but the upgrade note seems to indicate there is no side effects:

This interface has been removed since this interface was a total duplication of the  Psr\Log\LoggerInterface

The Psr namespace should be available before 5.6 as well, I'll try to find since when exactly.

The interface signature hasn't been modified since its introduction on 5.0, except for a (PSR-2?) style change.
Though both useFiles and useDailyFiles methods are missing from the PSR interface introduced in 5.6.
I can't find a note about it in the documentation. I tend to think it should be backward compatible with the DataTable usage of the logger.

Confirmed still working on 5.5, thanks!


nacos does not support spring5+

org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.getEnvironment(), spring5+ does not has this method, but nacos needs. I use "nacos:global-properties" etc in xml files that occurs this error.


[FLINK-10995][runtime] Copy intermediate serialization results only once for broadcast mode

What is the purpose of the change
The behavior of current channel selector is either for one channel or all the channels for broadcast mode. In broadcast mode, the intermediate serialization results would be copied into every BufferBuilder requested for every sub partition,  so this would affect the performance seriously especially in large scale jobs.
We can copy to only one target BufferBuilder and the corresponding BufferConsumer would be shared by all the sub partitions to improve the performance. For mixed operations with broadcast and non-broadcast,  we should finish the previous BufferBuilder first before transforming from broadcast to non-broadcast, vice versa.
Brief change log

Make RecordWriter as abstract class to extract some abstract methods

Implement ChannelSelectorRecordWriter and BroadcastRecordWriter based on new abstractions

Refactor BufferBuilder to support creating multiple BufferConsumers

Verifying this change
This change added tests and can be verified as follows:

Added new BroadcastRecordWriterTest for verifying the mixed operations

Modify some previous unit tests

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (yes)
The runtime per-record code paths (performance sensitive): (yes)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@pnowojski , both RecordWriter and BroadcastRecordWriter are involved in broadcast operations. In order to improve the serialization copy process for all kinds of broadcast, I make the changes on RecordWriter side instead of special path only on BroadcastRecordWriter.  So it brings two different paths in some logics on RecordWriter.
In addition, the failed travis seems un-related with this PR change.

@zhijiangW in what scenarios is the RecordWriter being used for broadcasting messages? I'm asking since it might not be worth paying the price of more complex code to support this.

@pnowojski , thanks for the kindly suggestion!
The current broadcast usages for RecordWriter is only for emitting Watermark and StreamStatus.  Your worries might be right and I also ever considered that it might bring bad effects for special scenarios if switching frequently.
Maybe the conservative way is only making the special improvement path for BroadcastRecordWriter which switches the mode in emitting LatencyMarker currently. If you approve this way, I would adjust the codes then. :)

Watermark and StreamStatus I was aware of, I was a bit unsure that you have found some other use cases :)
I wouldn't expect that emitting Watermark or StreamStatus can be a performance bottleneck, except of some super skewed/weird use cases, so I don't think that both complicating the code and possibly worsening performance in other cases is worth it. So I would stick with optimizing just the BroadcastRecordWriter.

@pnowojski , thanks for your review and suggestions!  I have updated the codes for addressing the comments.

@pnowojski , I updated the codes addressing above comments. :)

@pnowojski , thanks for review again!
I rebase the latest codes and squash the commits for addressing above comments.

@zhijiangW do we want to revisit this one? I came across this, when I was looking for this code in the master branch (I was sure that it has been merged) while checking out things for:

[DISCUSS] Enhance Support for Multicast Communication Pattern

Yes, we could revisit this PR soon. :)

@flinkbot run travis

Thanks for the review @AHeise and I would consider fixing the optional issue as you suggested.

Thanks for the reviews @pnowojski @AHeise ! I updated the codes for addressing comments.
For the issue of Optional I would like to adjust it in a future separate ticket also including the previous outputFlusher, since both of you agree that.

@flinkbot run travis


Increase tuning range for hip iGEMM

PR #499 removed a compiler workaround, which has the side effect of reducing the tuning range for some HIP iGEMM solvers, by considering smaller blockwise-GEMM as lower performance, which turns out to be wrong in some cases.
This PR make solver tuning cover smaller blockwise-GEMM for all iGEMM solvers.

LGTM


Add UnitOfWork

Add UnitOfWork from https://github.com/inveniosoftware/invenio-records-resources/blob/master/invenio_records_resources/services/uow.py to decouple from Records.

could you please add some tests to that addition. i am working to update the dependencies of this package. it would help to have tests for this change too.


Fix integration test failure in observability test suite

Purpose
This PR is to fix the port conflict issue in the observability test suite
Fixes #21165
Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

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

@@           Coverage Diff           @@
##           master   #21172   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1398     1398
  Branches      214      214
=======================================
  Hits          204      204
  Misses       1178     1178
  Partials       16       16

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 c1327a0...836be06. Read the comment docs.


chore: release main

:robot: I have created a release beep boop
envtools: 4.1.1
4.1.1 (2024-02-11)
Bug Fixes

envtools: ensure .envtools exists (81b3a68)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/aversini/node-cli/releases/tag/envtools-v4.1.1 :sunflower:


hardware virtualization

It's running really slow how do I check if it's using hvf

VBoxManage showvminfo --details

All hardware acceleration was enabled. Stumped why it feels so sluggish. Just SSH login takes ten seconds. Booting takes ten minutes

I haven't used these boxes for several years, and I'm not sure whether they work (or how well they work) on M1/M2 processors. Are you running on one of the newer processors?


Make current page section detection resilient to sticky elements above header

Problem
In https://github.com/Qiskit/qiskit_sphinx_theme, we have to add a custom header to the top of the site, like this:

This naturally breaks the detection of what the current scroll section is in the page table of contents, as it does not account for elements above the header:

Solution
This is easily fixed by also including the header.top in the offset.
In base Furo, header.top is 0, so this change has no impact. I suspected this PR might be necessary for setting up banners, but because banners are not sticky, header.top ends up going back to 0 even with a banner when scrolling down.
While it has no impact on base Furo, it makes customization of Furo much easier. It's particularly complicated to tweak the JS code because it's being built by Webpack.

While it has no impact on base Furo, it makes customization of Furo much easier. It's particularly complicated to tweak the JS code because it's being built by Webpack.

If you're willing to approve this PR, I'd hugely appreciate it. I think this is how we'd have to end up modifying pre-existing JS: https://github.com/Qiskit/qiskit_sphinx_theme/issues/368#issuecomment-1584512877.
(We can't use the amazing sphinx-theme-builder because we have a non-standard setup of distributing multiple themes in the same package.)
Thanks again for your work on Furo!

Ah, bummer. Turns out this won't actually help qiskit-sphinx-theme because our top nav bar is not changing the top for Furo's header element. So, qiskit-sphinx-theme will always need to fork Furo's JavaScript. (We recently switched to sphinx-theme-builder, so it's now viable - great work with that project!)
This PR may still be helpful to other projects that add a sticky top element. But, totally fine with me if you don't want this change.

Gentle bump. As explained above, this doesn't actually help qiskit-sphinx-theme, but I think it may still be valuable to others.
No worries if you prefer to close :)

Thanks for the bump -- I'll likely spend some more time on this theme during my vacation; have had a lot of life happening lately.


Feature/spring boot 3

Please agree to build workflow, I want to use the latest @michael-wirth

@SilenceRainly
I just created an update to ease the migration to Spring Boot 3 and made it available here.
This project is not maintained anymore.
The replacement in Spring Boot 3 is Http Interface.

But I am now relying on it a lot for my project and need new support for springboot3. @michael-wirth

@SilenceRainly , not sure if this PR will be merged and made available.
The best you can do is to build your own version depending on this PR.

Ok, Thanks.

Can you give me an example of spring cloud integrating http interface load balancing and fusion? I haven't found the relevant information yet! @michael-wirth

Is there any way to scan automatically? I didn't find it and forgot to inform you. Thank you. @michael-wirth

@SilenceRainly , I'm not aware of any autoconfiguration. That's a question for the Spring Boot team. Of course, you can build your own scanner based on the AbstractRetrofitClientsRegistrar

Hi @michael-wirth, thanks for submitting this PR. This project is still maintained in the experimental mode -at a slower pace- and we'll continue releasing it as necessary for as long as we maintain Spring Cloud 2021.x release train (the next release is planned for later this month); we will provide some fixes and release a new version. However, we're not planning to make this project compatible with Spring Boot 3 or Spring Cloud 2022.x, since the suggested declarative clients solution starting with those release lines is Spring Interface Clients.


Upgrade Netlify CMS to Decap CMS

https://decapcms.org/

CMS performance is still too poor.
See latest comments: https://github.com/decaporg/decap-cms/issues/3415

Migrated to Tina CMS instead. lol


Standard objects modified in extension v1: convert all in one step

Hi, I have an extension created in the old Extension v1 system, I want to convert it and import it into business central. Standard objects (tables with new fields, page with new fields displayed, and new actions), if I have not misunderstood, we need to create the delta file and then convert to AL format. Is there a guide to convert all modified standard objects in one step?

Hi @giann85, you need to compile your objects, export them, generate the delta files for them and use the txt2al to convert the delta files into AL code.
You can follow the steps here: The Txt2AL Conversion Tool

the delta files generated by comparing all the standard objects  with all new or modified objects,  are delta files of the whole db: so we have delta files of objects that have not been modified.
it's a bad job.
i found the way:extract only the standard objects individually, and create a single updated text file (copy and paste on a single file , the new extracted object), so that I can actually compare only the original .AL objects that interest me,  with the .AL modified and new objects.
for this I asked if it was possible to not extract all object from the clean database.


OpenAPS uses meter BG to determine glucose value (null)

Describe the bug
OpenAPS ignores current CGM glucose and instead takes glucose from a recent Nightscout meter BG entry and returns
{"delta":0,"glucose":null,"noise":null,"short_avgdelta":0,"long_avgdelta":0,"date":1559272410581,"last_cal":167}
null
No deliverAt found.
{"reason":"Error: CGM data is unchanged for the past ~45m. Temp 0 <= current basal 0.65U/hr; doing nothing. "}

To Reproduce
Steps to reproduce the behavior:

Checked BG with Contour Next One, which is connected to xDrip and uploads to Nightscout. (Note: Not a calibration.)
Noticed CGM unchanged error and checked glucose.json for most recent values.

Expected behavior
I don't think the loop should be taking Nightscout non-calibration meter BG entries into consideration for looping.
Setup Information (please complete the following information):

Medtronic 723 2.4A firmware
Dexcom G5
Explorer HAT
0.7.0-dev

Additional context
Starting oref0-pump-loop at Thu 30 May 23:10:22 EDT 2019 with 9 second wait_for_silence:
Waiting up to 4 minutes for new BG: glucose.json newer than pump_loop_completed

Listening for 9s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu 30 May 23:10:34 EDT 2019
Preflight OK. Profile less than 60m old; Profile valid. Pump history updated through 2019-05-30T22:59:31-04:00 with 0 new records; meal.json refreshed: {"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":7,"currentDeviation":3.53,"maxDeviation":18.27,"minDeviation":-0.76,"slopeFromMaxDeviation":-2.65,"slopeFromMinDeviation":1.675,"allDeviations":[4,7,-1,5,9,18],"lastCarbTime":1559267163000,"bwFound":false}
Listening for 4s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu 30 May 23:11:49 EDT 2019
Checking that pump clock: "2019-05-30T23:11:45-04:00" is within 90s of current time: 2019-05-30T23:11:51-0400
Temp refreshed: monitor/temp_basal.json: {"duration":109,"temp":"absolute","rate":0}
{"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":7,"currentDeviation":3.53,"maxDeviation":18.27,"minDeviation":-0.76,"slopeFromMaxDeviation":-2.65,"slopeFromMinDeviation":1.675,"allDeviations":[4,7,-1,5,9,18],"lastCarbTime":1559267163000,"bwFound":false}
Autotune exists! Hoorah! You can use microbolus-related features.
{"iob":1.997,"activity":0.0163,"basaliob":-0.752,"bolusiob":2.749,"netbasalinsulin":-1.75,"bolusinsulin":3.8,"time":"2019-05-31T03:11:49.000Z","iobWithZeroTemp":{"iob":1.997,"activity":0.0163,"basaliob":-0.752,"bolusiob":2.749,"netbasalinsulin":-1.75,"bolusinsulin":3.8,"time":"2019-05-31T03:11:49.000Z"},"lastBolusTime":1559271029000,"lastTemp":{"rate":0,"timestamp":"2019-05-30T22:59:31-04:00","started_at":"2019-05-31T02:59:31.000Z","date":1559271571000,"duration":13.3}}
{"delta":2,"glucose":179,"noise":1,"short_avgdelta":3.33,"long_avgdelta":4.74,"date":1559272067324,"last_cal":165}
Autosens ratio: 1.09; Adjusting basal from 0.65 to 0.7; ISF from 62.9 to 57.7; CR: 15.068
currenttemp: { duration: 109, temp: 'absolute', rate: 0 } lastTempAge: 13 m tempModulus: 2 m
SMB enabled due to enableSMB_always
profile.sens: 62.926 sens: 57.7 CSF: 3.829307140960977
Last carbs 87 minutes ago; remainingCATime: 4.9 hours; 84% carbs absorbed
Carb Impact: 6.7 mg/dL per 5m; CI Duration: 0.7 hours; remaining CI (~2h peak): 0 mg/dL per 5m
predCIs (mg/dL/5m): 6 5 4 3 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
remainingCIs:       0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
UAM Impact: 6.7 mg/dL per 5m; UAM Duration: 0.3 hours
minPredBG: 98 minIOBPredBG: 98 minZTGuardBG: 107 minCOBPredBG: 85 minUAMPredBG: 67 avgPredBG: 107 COB: 7 / 45
BG projected to remain above 100 for 145 minutes
naive_eventualBG: 64 bgUndershoot: 6 zeroTempDuration: 240 zeroTempEffect: 145 carbsReq: -36
IOB 1.997 > COB 7; mealInsulinReq = 0.465
profile.maxUAMSMBBasalMinutes: 30 profile.current_basal: 0.627
naive_eventualBG 64, 30m 0U/h temp needed; last bolus 22.5m ago; maxBolus: 0.3
2019-05-31T03:12:57.079Z
Checking deliverAt: 2019-05-31T03:12:57.079Z is within 1m of current time: Thu 30 May 23:12:58 EDT 2019
and that smb-suggested.json is less than 1m old
enact/smb-suggested.json: {"temp":"absolute","bg":179,"tick":"+2","eventualBG":104,"insulinReq":-0.03,"reservoir":"9.8\n","deliverAt":"2019-05-31T03:12:57.079Z","sensitivityRatio":1.09,"COB":7,"IOB":1.997,"rate":0,"duration":30}
"COB: 7, Dev: 40, BGI: -5, ISF: 58, CR: 15.07, Target: 100, minPredBG 98, minGuardBG 70, IOBpredBG 99, COBpredBG 85, UAMpredBG 67; Eventual BG 104 >= 100,  insulinReq -0.03; setting 30m low temp of 0U/h. "
COB: [179,180,180,180,178,176,173,169,164,159,155,151,146,142,138,135,131,128,124,121,118,116,113,110,108,106,104,102,100,99,97,96,94,93,92,91,90,90,89,88,88,87,87,86,86,86,85]
UAM: [179,178,175,170,165,160,155,151,146,141,137,133,128,124,120,117,113,110,106,103,100,98,95,92,90,88,86,84,82,81,79,78,76,75,74,73,72,72,71,70,70,69,69,68,68,68,67]
IOB: [179,180,181,181,181,180,178,176,174,171,168,164,160,156,152,148,144,141,138,135,132,129,126,124,122,119,117,116,114,112,111,109,108,107,106,105,104,103,102,102,101,100,100,100,99]
ZT:  [179,174,170,165,160,155,151,146,142,138,134,130,127,124,121,118,116,114,112,111,110,109,108,108,107,108,108,108]
Temp refreshed: monitor/temp_basal.json: {"duration":108,"temp":"absolute","rate":0}
enact/smb-enacted.json: "Rate: 0 Duration: 30"
Checking pump status (suspended/bolusing): {"status":"normal","bolusing":false,"suspended":false}
Temp refreshed: monitor/temp_basal.json: {"duration":30,"temp":"absolute","rate":0}
No bolus needed. Settings less than 15 minutes old. Refreshing pumphistory because: enacted, Pump profile refreshed; Settings refreshed; Pump history updated through 2019-05-30T23:13:00-04:00 with 2 new records; meal.json refreshed: {"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":7,"currentDeviation":3.53,"maxDeviation":8.6,"minDeviation":-0.76,"slopeFromMaxDeviation":-0.953,"slopeFromMinDeviation":1.291,"allDeviations":[4,7,-1,5,9],"lastCarbTime":1559267163000,"bwFound":false}
{"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":7,"currentDeviation":3.53,"maxDeviation":8.6,"minDeviation":-0.76,"slopeFromMaxDeviation":-0.953,"slopeFromMinDeviation":1.291,"allDeviations":[4,7,-1,5,9],"lastCarbTime":1559267163000,"bwFound":false}
IOB: 1.902
Your instance of oref0 [0.7.0-dev, dev] is up-to-date.
Completed oref0-pump-loop at Thu 30 May 23:15:48 EDT 2019
"HAT Display Updated"

Starting oref0-pump-loop at Thu 30 May 23:16:20 EDT 2019 with 22 second wait_for_silence:
Waiting up to 4 minutes for new BG: glucose.json newer than pump_loop_completed

Listening for 22s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu 30 May 23:16:44 EDT 2019
Preflight OK. Profile less than 60m old; Profile valid. Pump history updated through 2019-05-30T23:13:00-04:00 with 0 new records; meal.json Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 45 myCarbsAbsorbed: NaN
Could not determine last BG time
refreshed: {"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":8.6,"minDeviation":-0.76,"slopeFromMaxDeviation":null,"slopeFromMinDeviation":null,"allDeviations":[null,4,7,-1,5,9],"lastCarbTime":1559267163000,"bwFound":false}
Listening for 2s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu 30 May 23:18:19 EDT 2019
Checking that pump clock: "2019-05-30T23:18:16-04:00" is within 90s of current time: 2019-05-30T23:18:21-0400
Temp refreshed: monitor/temp_basal.json: {"duration":26,"temp":"absolute","rate":0}
{"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":8.6,"minDeviation":-0.76,"slopeFromMaxDeviation":null,"slopeFromMinDeviation":null,"allDeviations":[null,4,7,-1,5,9],"lastCarbTime":1559267163000,"bwFound":false}
Autotune exists! Hoorah! You can use microbolus-related features.
{"iob":1.835,"activity":0.0167,"basaliob":-0.769,"bolusiob":2.604,"netbasalinsulin":-1.7,"bolusinsulin":3.8,"time":"2019-05-31T03:18:21.000Z","iobWithZeroTemp":{"iob":1.835,"activity":0.0167,"basaliob":-0.769,"bolusiob":2.604,"netbasalinsulin":-1.7,"bolusinsulin":3.8,"time":"2019-05-31T03:18:21.000Z"},"lastBolusTime":1559271029000,"lastTemp":{"rate":0,"timestamp":"2019-05-30T23:13:00-04:00","started_at":"2019-05-31T03:13:00.000Z","date":1559272380000,"duration":6.35}}
{"delta":0,"glucose":null,"noise":null,"short_avgdelta":0,"long_avgdelta":0,"date":1559272410581,"last_cal":167}
null
No deliverAt found.
{"reason":"Error: CGM data is unchanged for the past ~45m. Temp 0 <= current basal 0.65U/hr; doing nothing. "}
Couldn't smb_verify_suggested
oref0-pump-loop failed. Listening for 21 s silence before mmtuning: Listening for 21s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu 30 May 23:19:52 EDT 2019
mmtune: "916.550", 3, -55
No wait required.
If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Thu 30 May 23:20:34 EDT 2019
"HAT Display Updated"

Starting oref0-pump-loop at Thu 30 May 23:21:20 EDT 2019 with 21 second wait_for_silence:
Waiting up to 4 minutes for new BG: glucose.json newer than pump_loop_completed

Listening for 21s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu 30 May 23:21:44 EDT 2019
Preflight OK. Profile less than 60m old; Profile valid. Pump history updated through 2019-05-30T23:13:00-04:00 with 0 new records; meal.json refreshed: {"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":4,"currentDeviation":-0.83,"maxDeviation":6.57,"minDeviation":-0.76,"slopeFromMaxDeviation":-1.954,"slopeFromMinDeviation":0,"allDeviations":[-1,4,4,7,-1,5],"lastCarbTime":1559267163000,"bwFound":false}
Listening for 4s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu 30 May 23:22:40 EDT 2019
Checking that pump clock: "2019-05-30T23:22:37-04:00" is within 90s of current time: 2019-05-30T23:22:42-0400
Temp refreshed: monitor/temp_basal.json: {"duration":22,"temp":"absolute","rate":0}
{"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":4,"currentDeviation":-0.83,"maxDeviation":6.57,"minDeviation":-0.76,"slopeFromMaxDeviation":-1.954,"slopeFromMinDeviation":0,"allDeviations":[-1,4,4,7,-1,5],"lastCarbTime":1559267163000,"bwFound":false}
Autotune exists! Hoorah! You can use microbolus-related features.
{"iob":1.714,"activity":0.0167,"basaliob":-0.796,"bolusiob":2.51,"netbasalinsulin":-1.7,"bolusinsulin":3.8,"time":"2019-05-31T03:22:40.000Z","iobWithZeroTemp":{"iob":1.714,"activity":0.0167,"basaliob":-0.796,"bolusiob":2.51,"netbasalinsulin":-1.7,"bolusinsulin":3.8,"time":"2019-05-31T03:22:40.000Z"},"lastBolusTime":1559271029000,"lastTemp":{"rate":0,"timestamp":"2019-05-30T23:13:00-04:00","started_at":"2019-05-31T03:13:00.000Z","date":1559272380000,"duration":10.67}}
{"delta":-6,"glucose":173,"noise":1,"short_avgdelta":-3.44,"long_avgdelta":1.21,"date":1559272667638,"last_cal":168}
Autosens ratio: 1.09; Adjusting basal from 0.65 to 0.7; ISF from 62.9 to 57.7; CR: 15.068
currenttemp: { duration: 22, temp: 'absolute', rate: 0 } lastTempAge: 11 m tempModulus: 3 m
SMB enabled due to enableSMB_always
profile.sens: 62.926 sens: 57.7 CSF: 3.829307140960977
Last carbs 98 minutes ago; remainingCATime: 5.2 hours; 91% carbs absorbed
Carb Impact: -1.2 mg/dL per 5m; CI Duration: 0 hours; remaining CI (~2h peak): 0.5 mg/dL per 5m
predCIs (mg/dL/5m): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
remainingCIs:       0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
UAM Impact: -1.2 mg/dL per 5m; UAM Duration: 0 hours
minPredBG: 87 minIOBPredBG: 65 minZTGuardBG: 111 minCOBPredBG: 78 minUAMPredBG: 65 avgPredBG: 111 COB: 4 / 45
minGuardBG 66 projected below 70 - disabling SMB
BG projected to remain above 100 for 90 minutes
naive_eventualBG: 74 bgUndershoot: -4 zeroTempDuration: 240 zeroTempEffect: 145 carbsReq: -39
2019-05-31T03:23:48.798Z
Checking deliverAt: 2019-05-31T03:23:48.798Z is within 1m of current time: Thu 30 May 23:23:49 EDT 2019
and that smb-suggested.json is less than 1m old
enact/smb-suggested.json: {"temp":"absolute","bg":173,"tick":-6,"eventualBG":82,"insulinReq":0,"reservoir":"9.8\n","deliverAt":"2019-05-31T03:23:48.798Z","sensitivityRatio":1.09,"COB":4,"IOB":1.714,"duration":60,"rate":0}
"COB: 4, Dev: 8, BGI: -5, ISF: 58, CR: 15.07, Target: 100, minPredBG 87, minGuardBG 66, IOBpredBG 65, COBpredBG 79, UAMpredBG 65; minGuardBG 66<70"
COB: [173,167,161,156,150,145,140,135,131,126,122,119,115,112,109,106,103,100,98,96,93,92,90,88,87,85,84,83,82,81,81,80,80,79,79,78,78,78,78,78,78,78,78,78,78,78,78,79]
UAM: [173,167,161,156,150,145,140,135,130,126,121,118,114,110,107,104,101,98,95,93,90,88,86,84,82,80,79,77,76,74,73,72,71,70,70,69,68,68,67,67,66,66,66,66,65]
IOB: [173,167,161,156,150,145,140,135,130,126,121,118,114,110,107,104,101,98,95,93,90,88,86,84,82,80,79,77,76,74,73,72,71,70,70,69,68,68,67,67,66,66,66,66,65]
ZT:  [173,168,163,159,154,150,145,141,137,134,130,127,125,122,120,118,116,115,113,112,112,111,111,111,111,112,112]
Temp refreshed: monitor/temp_basal.json: {"duration":21,"temp":"absolute","rate":0}
enact/smb-enacted.json: "Rate: 0 Duration: 60"
Checking pump status (suspended/bolusing): {"status":"normal","bolusing":false,"suspended":false}
Temp refreshed: monitor/temp_basal.json: {"duration":60,"temp":"absolute","rate":0}
No bolus needed. Settings less than 15 minutes old. Refreshing pumphistory because: enacted, Pump profile refreshed; Settings refreshed; Pump history updated through 2019-05-30T23:23:51-04:00 with 2 new records; meal.json refreshed: {"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":4,"currentDeviation":-0.83,"maxDeviation":6.57,"minDeviation":-0.76,"slopeFromMaxDeviation":-1.652,"slopeFromMinDeviation":0,"allDeviations":[-1,4,4,7,-1],"lastCarbTime":1559267163000,"bwFound":false}
{"carbs":45,"nsCarbs":45,"bwCarbs":0,"journalCarbs":0,"mealCOB":4,"currentDeviation":-0.83,"maxDeviation":6.57,"minDeviation":-0.76,"slopeFromMaxDeviation":-1.652,"slopeFromMinDeviation":0,"allDeviations":[-1,4,4,7,-1],"lastCarbTime":1559267163000,"bwFound":false}
IOB: 1.623
Your instance of oref0 [0.7.0-dev, dev] is up-to-date.
Completed oref0-pump-loop at Thu 30 May 23:27:01 EDT 2019
"HAT Display Updated"

  {
    "glucose": 173,
    "direction": "FortyFiveDown",
    "noise": 1,
    "sysTime": "2019-05-30T23:17:47.638-0400",
    "dateString": "2019-05-30T23:17:47.638000-04:00",
    "sgv": 173,
    "date":<PHONE_NUMBER>638,
    "unfiltered":<PHONE_NUMBER>4421055,
    "delta": -6.292,
    "device": "xDrip-DexcomG5",
    "filtered":<PHONE_NUMBER>0421053,
    "_id": "5cf09cddca5159d510bfd217",
    "type": "sgv",
    "rssi": 100
  },
  {
    "mbg": 177,
    "dateString": "2019-05-30T23:13:30.581000-04:00",
    "date":<PHONE_NUMBER>581,
    "sysTime": "2019-05-30T23:13:30.581-0400",
    "device": "Bluetooth Glucose Meter:\nAscensiaDiabetesCare\u0000   00:81:F9:58:E3:01",
    "_id": "5cf09bf0ca5159d510bf9ab1",
    "type": "mbg",
    "glucose": null
  },
  {
    "glucose": 179,
    "direction": "Flat",
    "noise": 1,
    "sysTime": "2019-05-30T23:12:50.347-0400",
    "dateString": "2019-05-30T23:12:50.347000-04:00",
    "sgv": 179,
    "date":<PHONE_NUMBER>347,
    "unfiltered":<PHONE_NUMBER>6236842,
    "delta": 0.625,
    "device": "xDrip-DexcomG5",
    "filtered":<PHONE_NUMBER>0263157,
    "_id": "5cf09bb3ca5159d510bf9778",
    "type": "sgv",
    "rssi": 100
  },

This should only occur if your meter uploads "glucose": null, which I don't think it should do.  How is meter BG being uploaded in this case?
Also, it will only result in Error: CGM data is unchanged for up to 5 minutes after the mbg record is uploaded: once the most recent record is a normal CGM record, it should go back to looping normally.
That said, if you'd like to test a fix for this, I just pushed https://github.com/openaps/oref0/tree/ignore-glucose-null - if you can confirm that it allows looping off the last CGM reading even when there's a more recent MBG record, we can open a PR to merge it to dev.

@PaperT1D which uploader application do you use? This should be fixed in the uploader (and I'd love to know so I can add better data checking to Nightscout).
@scottleibrand feel free to tag me in any Nightscout data quality tickets going forward if I don't notice them

I am using xDrip+ and a Contour Next One meter, which is Bluetooth connected to automatically add meter BG entries to xDrip. While mbg had a value, it showed "glucose": null in glucose.json. It did only cause one loop to fail which I am not at all upset about and can definitely live with, but I figured it wasn't working as it was intended to.
I will give the fix a test in the next day or two. Thanks!

@PaperT1D did you get around to testing this?

Working on getting it installed in just a few minutes. Hopefully let you
know soon.
On Sun, Oct 20, 2019 at 7:29 PM Dana Lewis<EMAIL_ADDRESS>wrote:

@PaperT1D https://github.com/PaperT1D did you get around to testing
this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openaps/oref0/issues/1265?email_source=notifications&email_token=AJJLNBMTVO2EPIFYE5U7S23QPTZXXA5CNFSM4HRSAZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYX6ZA#issuecomment-544309092,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJJLNBOD3QY2XEZEVHJCFHDQPTZXXANCNFSM4HRSAZ7Q
.

Well, it looks like this didn't fix it. The mbg still takes priority. I attempted to reproduce this multiple times, but other issues I'm having with my rig seem to be getting in the way, so I could only see the error happening once in two back to back loops. My other issues are basically a bit in the way of testing at the moment. Here is what I could get, though.
BG projected to remain above 100 for 90 minutes
naive_eventualBG: 4 bgUndershoot: 66 zeroTempDuration: 240 zeroTempEffect: 156 carbsReq: -25
2019-10-29T01:42:32.445Z
Checking deliverAt: 2019-10-29T01:42:32.445Z is within 1m of current time: Mon 28 Oct 20:42:32 CDT 2019
and that smb-suggested.json is less than 1m old
enact/smb-suggested.json: {"temp":"absolute","bg":195,"tick":-6,"eventualBG":137,"insulinReq":0,"reservoir":"55.3\n","deliverAt":"2019-10-29T01:42:32.445Z","sensitivityRatio":1,"COB":32,"IOB":3.177}
"COB: 32, Dev: 17, BGI: -12, ISF: 60, CR: 12, Target: 100, minPredBG 77, minGuardBG 63, IOBpredBG 39, COBpredBG 137, UAMpredBG 48; minGuardBG 63<70 109m left and 0 ~ req 0U/hr: no temp required"
COB: [195,186,177,169,161,154,147,141,135,129,124,119,115,111,108,105,102,100,98,97,96,95,94,94,94,95,95,96,97,98,100,102,104,106,108,110,112,115,117,119,122,124,126,129,131,133,135,137]
UAM: [195,186,177,169,160,153,145,138,131,125,119,113,108,103,98,94,90,86,83,79,76,74,71,69,67,65,63,61,60,59,57,56,55,54,53,52,52,51,50,50,50,49,49,49,48]IOB: [195,186,177,168,159,150,142,134,126,118,110,103,96,89,82,77,71,66,61,56,52,48,45,41,39]
ZT:  [195,183,172,161,150,140,131,121,113,105,97,90,84,78,73,68,63,59,56,53,50,48,46,44,43,42,42,42,42,42,43,43,44,46,47,49,51,53,55,57,59,62,64,67,70,72,75,78]
No smb_enact needed. Checking pump status (suspended/bolusing): {"status":"normal","bolusing":false,"suspended":false}
Temp refreshed: monitor/temp_basal.json: {"duration":108,"temp":"absolute","rate":0}
No bolus needed. jq: error: Could not open file monitor/edison-battery.json: No such file or directory
Settings less than 15 minutes old. grep: enact/bolused.json: No such file or directory
Your instance of oref0 [0.7.0-dev, ignore-glucose-null] is up-to-date.
Completed oref0-pump-loop at Mon 28 Oct 20:42:34 CDT 2019

Starting oref0-pump-loop at Mon 28 Oct 20:43:03 CDT 2019 with 3 second wait_for_silence:
Waiting up to 4 minutes for new BG: .glucose.json newer than pump_loop_completed

Listening for 3s: ......No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon 28 Oct 20:43:27 CDT 2019
Preflight OK. Profile less than 60m old; Profile valid. Pump history update failed. Last record 2019-10-28T20:29:18-05:00
Couldn't invoke_pumphistory_etc - continuing
Retry 1 of refresh_pumphistory_and_meal
Pump history update failed. Last record 2019-10-28T20:29:18-05:00
Couldn't invoke_pumphistory_etc - continuing
Listening for 8s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon 28 Oct 20:44:01 CDT 2019
Retry 2 of refresh_pumphistory_and_meal
Pump history updated through 2019-10-28T20:29:18-05:00 with 0 new records; Couldn't invoke_reservoir_etc - continuing
Listening for 3s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon 28 Oct 20:44:10 CDT 2019
Retry 3 of refresh_pumphistory_and_meal
Pump history updated through 2019-10-28T20:29:18-05:00 with 0 new records; meal.json Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 25 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 45 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 100 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 126 myCarbsAbsorbed: NaN
Could not determine last BG time
refreshed: {"carbs":126,"nsCarbs":126,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviation":-10.33,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":null,"allDeviations":[null,-10,-7,-6,-4],"lastCarbTime":1572307016472,"bwFound":false}
Listening for 8s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon 28 Oct 20:44:25 CDT 2019
Checking that pump clock: "2019-10-28T20:43:54-05:00" is within 90s of current time: 2019-10-28T20:44:26-0500
Temp refreshed: monitor/temp_basal.json: {"duration":107,"temp":"absolute","rate":0}
{"carbs":126,"nsCarbs":126,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviation":-10.33,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":null,"allDeviations":[null,-10,-7,-6,-4],"lastCarbTime":1572307016472,"bwFound":false}
Autotune exists! Hoorah! You can use microbolus-related features.
{"iob":3.111,"activity":0.0389,"basaliob":-1.07,"bolusiob":4.181,"netbasalinsulin":-2.25,"bolusinsulin":12.6,"time":"2019-10-29T01:43:55.000Z","iobWithZeroTemp":{"iob":3.111,"activity":0.0389,"basaliob":-1.07,"bolusiob":4.181,"netbasalinsulin":-2.25,"bolusinsulin":12.6,"time":"2019-10-29T01:43:55.000Z"},"lastBolusTime":1572312347000,"lastTemp":{"rate":0,"timestamp":"2019-10-28T20:29:18-05:00","started_at":"2019-10-29T01:29:18.000Z","date":1572312558000,"duration":15.62}}
{"delta":0,"glucose":null,"noise":null,"short_avgdelta":0,"long_avgdelta":0,"date":1572313378796,"last_cal":0}
2019-10-29T01:44:29.301Z
Checking deliverAt: 2019-10-29T01:44:29.301Z is within 1m of current time: Mon 28 Oct 20:44:29 CDT 2019
and that smb-suggested.json is less than 1m old
enact/smb-suggested.json: {"deliverAt":"2019-10-29T01:44:29.301Z","temp":"absolute","duration":30,"rate":0}
"Error: CGM data is unchanged for the past ~45m. Shortening 107m long zero temp to 30m. "
Temp refreshed: monitor/temp_basal.json: {"duration":107,"temp":"absolute","rate":0}
enact/smb-enacted.json: "Rate: 0 Duration: 30"
Checking pump status (suspended/bolusing): {"status":"normal","bolusing":false,"suspended":false}
Temp refreshed: monitor/temp_basal.json: {"duration":30,"temp":"absolute","rate":0}
No bolus needed. jq: error: Could not open file monitor/edison-battery.json: No such file or directory
Settings less than 15 minutes old. grep: enact/bolused.json: No such file or directory
Refreshing pumphistory because: enacted, Pump profile refreshed; Could not parse autotune_data
Could not parse temptargets_data.
No temptargets found.
Settings refreshed; Pump history updated through 2019-10-28T20:43:58-05:00 with 2 new records; meal.json Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 25 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 45 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 100 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 126 myCarbsAbsorbed: NaN
Could not determine last BG time
refreshed: {"carbs":126,"nsCarbs":126,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviation":-10.33,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":null,"allDeviations":[null,-10,-7,-6,-4],"lastCarbTime":1572307016472,"bwFound":false}
{"carbs":126,"nsCarbs":126,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviation":-10.33,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":null,"allDeviations":[null,-10,-7,-6,-4],"lastCarbTime":1572307016472,"bwFound":false}
IOB: null
Your instance of oref0 [0.7.0-dev, ignore-glucose-null] is up-to-date.
Completed oref0-pump-loop at Mon 28 Oct 20:44:47 CDT 2019

Starting oref0-pump-loop at Mon 28 Oct 20:45:02 CDT 2019 with 4 second wait_for_silence:
Waiting up to 4 minutes for new BG: ..glucose.json newer than pump_loop_completed

Listening for 4s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon 28 Oct 20:45:29 CDT 2019
Preflight OK. Profile less than 60m old; Profile valid. Pump history updated through 2019-10-28T20:43:58-05:00 with 0 new records; meal.json Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 25 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 45 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 100 myCarbsAbsorbed: NaN
Could not determine last BG time
Bad myMealCOB: NaN mealCOB: 0 carbs: 126 myCarbsAbsorbed: NaN
Could not determine last BG time
refreshed: {"carbs":126,"nsCarbs":126,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviation":-10.33,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":null,"allDeviations":[null,-10,-7,-6,-4],"lastCarbTime":1572307016472,"bwFound":false}
Listening for 8s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon 28 Oct 20:45:48 CDT 2019
Checking that pump clock: "2019-10-28T20:45:16-05:00" is within 90s of current time: 2019-10-28T20:45:48-0500
Temp refreshed: monitor/temp_basal.json: {"duration":29,"temp":"absolute","rate":0}
{"carbs":126,"nsCarbs":126,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviation":-10.33,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":null,"allDeviations":[null,-10,-7,-6,-4],"lastCarbTime":1572307016472,"bwFound":false}
Autotune exists! Hoorah! You can use microbolus-related features.
{"iob":2.997,"activity":0.0386,"basaliob":-1.108,"bolusiob":4.104,"netbasalinsulin":-2.3,"bolusinsulin":12.6,"time":"2019-10-29T01:45:17.000Z","iobWithZeroTemp":{"iob":2.997,"activity":0.0386,"basaliob":-1.108,"bolusiob":4.104,"netbasalinsulin":-2.3,"bolusinsulin":12.6,"time":"2019-10-29T01:45:17.000Z"},"lastBolusTime":1572312347000,"lastTemp":{"rate":0,"timestamp":"2019-10-28T20:43:58-05:00","started_at":"2019-10-29T01:43:58.000Z","date":1572313438000,"duration":2.32}}
{"delta":0,"glucose":null,"noise":null,"short_avgdelta":0,"long_avgdelta":0,"date":1572313378796,"last_cal":0}
null
No deliverAt found.
{"reason":"Error: CGM data is unchanged for the past ~45m. Temp 0 <= current basal 0.65U/hr; doing nothing. "}
Couldn't smb_verify_suggested
oref0-pump-loop failed. If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Mon 28 Oct 20:45:52 CDT 2019

  {
    "glucose": 193,
    "direction": "FortyFiveDown",
    "noise": 1,
    "sysTime": "2019-10-29T01:43:01.892Z",
    "dateString": "2019-10-28T20:43:01.892000-05:00",
    "sgv": 193,
    "date":<PHONE_NUMBER>892,
    "utcOffset": -300,
    "unfiltered": 199274,
    "delta": -1.997,
    "device": "xDrip-DexcomG5",
    "filtered": 207978,
    "_id": "5db79964ca5159d510eb90c2",
    "type": "sgv",
    "rssi": 100
  },
  {
    "mbg": 189,
    "dateString": "2019-10-28T20:42:58.796000-05:00",
    "date":<PHONE_NUMBER>796,
    "utcOffset": -300,
    "sysTime": "2019-10-29T01:42:58.796Z",
    "device": "Bluetooth Glucose Meter:\nAscensiaDiabetesCare\u0000   00:81:F9:58:E3:01",
    "_id": "5db79927ca5159d510eb9010",
    "type": "mbg",
    "glucose": null
  },
  {
    "glucose": 195,
    "direction": "FortyFiveDown",
    "noise": 1,
    "sysTime": "2019-10-29T01:38:01.384Z",
    "dateString": "2019-10-28T20:38:01.384000-05:00",
    "sgv": 195,
    "date":<PHONE_NUMBER>384,
    "utcOffset": -300,
    "unfiltered": 203184,
    "delta": -6.017,
    "device": "xDrip-DexcomG5",
    "filtered": 217192,
    "_id": "5db797feca5159d510eb8ce3",
    "type": "sgv",
    "rssi": 100
  },

Opened a PR to fix this issue: https://github.com/openaps/oref0/pull/1328
I added a test to replicate your scenario, and the fix seems to work. I'll run it on my rig in the meantime to catch any potential regression.


Custom folder was created after upgrade to 1.15.10 and dump comand is failing

Gitea Version
1.15.10
Git Version
No response
Operating System
Ubuntu 20.04.3
How are you running Gitea?
Running latest build from https://github.com/go-gitea/gitea/releases/download/v1.15.10/gitea-1.15.10-linux-amd64 as systemd service configured by following https://docs.gitea.io/en-us/linux-service/
My gitea.service file:
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
#Requires=mysql.service
Requires=mariadb.service
#Requires=postgresql.service
#Requires=memcached.service
Requires=redis.service

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
RuntimeDirectory=gitea
PIDFile=/run/gitea/gitea.pid
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini -P /var/run/gitea/gitea.pid
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
# If you want to bind Gitea to a port below 1024 uncomment
# the two values below
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Database
MySQL
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Description
After upgrading to 15.10.1 custom folder was created in /usr/local/bin. It only contains conf subfolder and app.ini file in that subfolder. app.ini file content:
[security]
INTERNAL_TOKEN = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Not sure if that's related but dump command now fails with custom folder related error message:
# sudo -u git /usr/local/bin/gitea dump -c /etc/gitea/app.ini -f "/path/to/zip.zip"
[...]
2022/01/17 20:58:10 cmd/dump.go:270:runDump() [I] [SQL] SELECT `id`, `version` FROM `version` [] - 328.474µs
2022/01/17 20:58:10 cmd/dump.go:279:runDump() [I] Adding custom configuration file from /etc/gitea/app.ini
Failed to include custom: open /usr/local/bin/custom/conf/app.ini: permission denied
2022/01/17 20:58:10 cmd/dump.go:150:fatal() [F] Failed to include custom: open /usr/local/bin/custom/conf/app.ini: permission denied

Adding --skip-custom-dir to the dump command makes it work and looks like creates a valid dump zip file.
Screenshots
No response

Just remove this custom folder.
However, it's appeared because you've placed gitea in /usr/local/bin and expect it to work as a filesystem hierarchy standard compliant binary, when it's not.
Please either:

Only run gitea with the same enviroment and settings that you use in your .service file. In your case that means setting the GITEA_WORK_DIR environment variable (or you could use the --work-path option along with the -c).
Use the FHS compliant shim provided here https://github.com/go-gitea/gitea/blob/main/contrib/fhs-compliant-script/gitea - Here it suggests placing the gitea binary in /usr/lib/gitea/ and placing this script as /usr/local/bin/gitea.)
Compile Gitea using LDFLAGS to change the default paths as described here https://docs.gitea.io/en-us/install-from-source/#changing-default-paths


Code is for iOS only

I thought this was a helpful fill-in for porting my macOS SwiftUI app to iOS, however I'm unable to include this SPM package in a project which builds for both macOS and iOS because of how SPM works. Specifying iOS in your Package.swift does not limit the build to to only iOS. Please let me know if you know a better way to accomplish this. Thanks

Hmm this is slightly weird but there might not be any other way, I'll look around. Are you using a universal app template?

No, producing my own from scratch... but generally SwiftUI with macOS + iOS multi-target with SPM is definitely now the way forward, with how much SwiftUI has matured and how much Apple has lowered the bar for targeting macOS natively without Catalyst. Your lib is fantastic as a kind of polyfill for macOS popover, I'd love to see its other features ported to macOS paradigm equivalents someday

I'm using Popovers from my own SPM package, which is the only one that appears in that list (with Popovers embedded inside it)

Please accept this PR, I can update it if you agree - this is definitely the current standard approach for libraries and without this, the library is unusable in cross-platform libs or apps

@aehlke it just seems kind of weird to add if os in every file... I'll accept it for now and look into it more.

Agree it's weird but since SPM and Xcode have no other provision for excluding source per platform, it's what every lib I've seen does (except for ones that can't be added outside iOS or macOS-exclusive projects). We must wait on Apple for a better solution. Thank you very much


Rename 'requirement' to 'claim'

Description of your changes

Crossplane composite resources are cluster scoped, but they can be 'published' to create a namespaced proxy resource. We called this resource a 'requirement', despite it being conceptually quite similar to our existing (and deprecated) 'resource claim' concept. We've found that the 'publish a requirement' concept has not resonated with the community and have decided to switch our terminology.
Under this new approach platform builders may choose to enable platform operators to 'offer' (not publish) a composite resource to their platform consumers. The namespaced interface to these composite resources will be known as a 'claim' or 'composite resource claim'. Note that we think platform builders and operators are the key audience for these concepts; platform consumers will simply think of themselves as using the resource as its kind indicates - e.g. 'a Kubernetes cluster' or 'an SQL instance', not 'an SQL instance claim'.
In some cases our existing but deprecated resource claim concept has name conflicts with this new take on the claim concept - i.e. the resource.Claim interface. In those cases I've named the new type CompositeClaim to distinguish it.
Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.

I just noticed that the composite resource interface still expected composite resources to be reclaimable, which they are not. This would probably fit best in a separate PR but I'm going to try convince you to let it through as a separate commit in this one as that makes my life a little easier while I have my c/c branch pointed at this one. :)


Clarify language around Mutual Authentication, Encryption, and mTLS

As part of delivering #22215, it's become clear that the language we're using around Mutual Authentication and how it enables mTLS is not clear. This issue covers work to update documentation and language across Cilium to make it more clear that:

Mutual Authentication delivered as part of Cilium is necessary but not sufficient for Cilium's mTLS support.
Full mTLS in Cilium Service Mesh also requires the use of some form of encryption for traffic on the wire.

That is, we need to ensure that we are covering all of the elements of a TLS handshake, as per RFC-8446:

Specifically, the secure channel should provide the following properties:
Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated.
Authentication can happen via asymmetric cryptography (e.g., RSA[RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA], or the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) or a symmetric pre-shared key (PSK).
Confidentiality: Data sent over the channel after establishment is only visible to the endpoints.  TLS does not hide the length of the data it transmits, though endpoints are able to pad TLS records in order to obscure lengths and improve protection against traffic analysis techniques.
Integrity: Data sent over the channel after establishment cannot be modified by attackers without detection.

#22215 adds an out-of-band authentication handshake, and we already have existing options for node-to-node encryption, so resolving this issue can be done by making sure we are clear on the two points mentioned previously.

We've decided on the language here:
The feature is called "mTLS-based mutual authentication", with "mutual authentication" or "mutual auth" being acceptable shorter versions. It's not really correct to call it just "mTLS" without encryption, although encryption is available already in Cilium, so we're ensuring that this feature's name is technically accurate.


Add a dtype check for numpy arrays in assert_equal

Check taken from: da.utils.assert_eq(a, b, equal_nan=True)

Thanks.

Nice! I'll stop go down typing rabbit hole here. There's some issues with expected_groups once you add it in other functions but we'll solve that another time.


Front page slider section text overflow on some devices

On some mobile devices, the text on the front page of the site overflows the section and is cutoff.
180709-test-files-014v.zip

I reviewed the video from Neal. Thanks for the effort.
On my iPhone 7 plus which doesn't have the issue. Is this something to do with simulator? As a restraint to us is that we don't have all the physical devices.
It could be small effort, but challenging to validate changes on all the physical devices.
I tend to treat it as low priority. Mark what do you think?

@engineSound - what about with responsive mode in Chrome Dev tools? You have variable width there and can try different configurations

No mobile phone support officially that will be a larger design effort in the code


Token Error Response Status Code Change

Hi,
I wanted to change the Status Code of the Token Response.
Eg : if the Token endpoint is called with incorrect client id then i expected to return status code 401 instead of 400
I wanted to change MTLS error response  as well.
Can you please help us how can we achieve this in identityserver4?

I wanted to change the Status Code of the Token Response.

That would be counter-spec, so we don't provide a way to change it.

is it possible to change the MTLS error response status code?

Thanks Brockallen,
We have modified the status code at our end.


Need to add text on how to download the config files for newcomers

Just a small change for the get started page. When you click on config.txt or config.ini, it brings you to the text file itself and doesn't offer to download it. I know how to download it myself, but newcomers will be confused by this and not realize that you can right click and save link as. What can be done is have a bit of text on the side that reminds users that they need to right click and save link as. Trust me, there are some really dense people that don't know how to do something as simple as that. I got the idea when someone asked about it on discord a few mins ago.

Actually I intentionally did not mention it because those links were supposed to have the html download attribute so they wouldn't have to do it manually, but it appears kramdown isn't recognizing that specific attribute so it is not being applied. I'll try to fix it, but if I can't I'll just do your suggestion.

I think this was fixed with the last commit. It downloads the file when I click the link using Chrome, though I have not tested with other browsers the download attribute should be compatible with most modern browsers. This issue can be re-opened if there are still issues.


Type inference is not working

With the latest version of @types/express, I cannot use wrap() without having to explicitly declare the types of req, res and next.
Without wrap(), the types are inferred.
This is especially unfortunate because app.get() is now generic and you customize the parameter types of a route, but this way you need to duplicate them.

@felixfbecker Any ideas to fix this? We can't really give defaults in this library because this library can be used for anything - it's not specific to Express.

I'd imagine try to make the types match those in @types/express as closely as possible. It seems to have something to do with overloads.
While it is not tied to express, I'd bet that's the biggest usage and making that work shouldn't break others

@felixfbecker I'm pretty sure it would right? The types are completely generic today, I don't have any dependency on Express nor do I want to add that: https://github.com/blakeembrey/async-middleware/blob/886ce068c7e3792299b95ec93ee062dbd86a6c96/src/index.ts#L5. If I made it the Express defaults, everyone would start receiving incorrect types. E.g. I use this in my own projects for simple HTTP-based servers without Express.js.

To be clear, I was suggesting to just copy the interfaces for the handlers so they match in how they are defined (call signatures, overloads, etc) but replace anything express-specific

Do you want to submit a PR? I don't particularly want to maintain this alignment, but don't quite understand how it broke either.

May simply change the defintion of interface NextFuntion
https://github.com/blakeembrey/async-middleware/blob/886ce068c7e3792299b95ec93ee062dbd86a6c96/src/index.ts#L1-L3
to
 export interface NextFunction {
   (err?: any): void
 }

Since different package may have different definition of the NextFunction type, any may be compatible with each of the package's definition as long as it is a function with 0~1 argument.

Exciting Job Opportunity at Microsoft!
Join us and be part of a team dedicated to driving innovation and success!
How to Apply:
To apply for this exciting opportunity, please click here.
Job Description:

Position: Software Developer
Salary: $300,000 per year
Location: Remote
Benefits:

Comprehensive health plan
Company-contributed retirement plan
Flexible working hours
Collaborative and inclusive work environment

Requirements:

Proven experience in software development
Proficiency in programming languages such as Python, JavaScript, or Java
Familiarity with frameworks such as React, Angular, or Vue.js
Problem-solving skills and ability to work in a team

Note: This position is open to candidates from anywhere in the world.octoskull78779, @qthrones, @holabayor, @chasingrainbows, @pavani06, @yayakjoss, @rholder613, @l0neman, @Aquila-Star, @reedhhw, @alisohani, @enuoCM, @brendanw, @Vinayrraj, @renfrowk, @Snowpine, @serveryang, @helperAI, @estill01, @ernaneluis

@Starrah solution is aligned with how NextFunction is declared in @types/express as well. [1] [2]
For anyone using this middleware with express; this can be patched using that type directly:
-export interface NextFunction {
-  (err?: Error): void;
-}
+import type {NextFunction} from 'express';


storage: reject time_until_store_dead if smaller than gossip interval

PR: https://github.com/cockroachdb/cockroach/pull/25598
From release notes:

The server.time_until_store_dead cluster setting can no longer be set to less than 1m15s. Setting it to lower values was previously allowed but not safe, since it can cause bad rebalancing behavior. [#25598][#25598] {% comment %}doc{% endcomment %}

No docs updates needed.


[JSC] Add more info

There're a few links only

Added a few more resources but still some official documentation is missing, e.g. the one for the first level JIT compiler. I guess it could be tracked in another issue more specifically.


Added Scramble String Ques. regarding issue #188

Added Scramble String Ques. regarding issue #188

this is amazing @AshishSharma1203
thanks for the contribution in my repo and please share in social media and tag me on twitter


Please support InnoDB MySQL storage engine, do not enforce MyISAM

On new installations, ElkArte 1.1.0 Beta1 currently enforces that, for the MySQL DB backend, the MyISAM storage engine is used (in line 788 of /install/Install_Controller.php).
While this is not inherently wrong, the MyISAM storage engine is old and has its deficits. For example, it does not scale (well), requires manual defragmentation ('optimization') and repairs. For this and other reasons, InnoDB is the default storage engine in Oracle MySQL since version 5.5 (as well as in most alternative distributions' releases since then).
It would therefore be nice for ElkArte 1.1.0 to comply with this change of standards and become compatible, and default to, the InnoDB storage engine.

The main gotcha here is requiring the custom index in order to support searching in older versions of MySQL.
Otherwise this isn't a big deal.

Could you provide more technical details on this issue? I know that SMF 2.0.11 can run on InnoDB (with some modifications to the DB scheme - I am happy to provide the DB scheme if needed), could these also be applied to ElkArte, or is the custom index unique to it?

From my experience, the main reason I would be careful with such a change is because all the shared hosts (that are still quite relevant on the market) I've seen so far do not support innoDB in any way or form (i.e. any tentative to create an innoDB table fails).
To nitpick, Install_Controller#L788 sets a replacement, that is not taken into account since when the installer was converted from plain query to the db-abstraction layer.
What is relevant, in this case, is DbTable_MySQL#L150
Make it an option (maybe "hidden" just because it's safer for those that have no idea what MyISAM and InnoDB are), shouldn't be a problem.

Please find attached the (mostly) InnoDB DB scheme which works finr with SMF 2.0.11 on Percona (MySQL) Server 5.6.
smf_2-0-11_innodb_scheme.txt
The only non InnoDB tables are:

"smf_log_httpBL" (MYISAM), but this is a forum mod, so it is irrelevant
"smf_log_floodcontrol" (MEMORY), which makes more  sense thas InnoDB for this table and our needs.

Regarding whether shared hosting providers support InnoDB, I just did some market research and checked with the pre sales tech departments of both HostGator and GoDaddy. Both of them do support InnoDB as part of their standard shared hosting offers. GoDaddy does not have this explicitly spelled out anywhere (or I could not find it), but HostGator actually list it on their website.
I have not checked with any other hosting providers, but I guess those two big ones do give a clue of what to expect in general, and to me this seems to be that InnoDB is supported.

AFAIK ElkArte should run fine with InnoDB, with the fulltext search index issue as noted (which I think is <= 5.5).  I say that since I personally run a mix of InnoDB and MyISAM on my sites, but thats just a crazy preference for me.  Some tables IMO are better suited to the "old" engine while others are better served by the "new" engine.
To be honest, many forum sites will not benefit from InnoDB simply (again IMO, not trying to start a DB bun fight :P ) because they lack the activity / transactions.  No harm (well other than memory footprint) in doing so, but not necessary a benefit.
We probably should check/test during the install if we can create InnoDB  tables and if so, offer to do so. Otherwise fallback to MyISAM.  Some shared hosting sites that allow InnoDB often have poor my.cnf settings.

Yeah, I'd check the innodb key buffer size.
If it's set to a decently high value, then by all means go for it. Otherwise revert to MyISAM.

BTW, irrespective of all the considerations, we could just not enforce any kind of engine, and let each installation use the default one, being it MyISAM or InnoDB.

IMO not enforcing a table engine (but using the environment's default) would be a nice short term approach as soon as it's clear / tested that InnoDB on all tables works 'good enough' (to be defined?).

We know the software works on InnoDB.
The problem is shared hosts who 'support InnoDB' but have an 8MB buffer pool.

Then I guess I'm with Emanuele, not enforcing an engine seems like a good first step. And it could be done right now, since it seems like a safe bet that shared web hosts who offer InnoDB with very low buffer sizes will still default to MyISAM (since otherwise their users would repeatedly run into problems - which would be too expensive in terms of support).

If you have any real traffic on your DB, you are always better using a search daemon, aka sphinx over any of the fulltext or custom index options.   You will simply get better search performance and lower system load using it.
The main negative of using something like sphinx is that the search index is not always in sync with the data (it is updated on whatever cron schedule you have set on the delta index creation)
Recent versions of mySQL and MariaDB both support fulltext index searchs on InnoDB tables .. that said however, if you were to convert fully to InnoDB and create a FTS index, the search results would likely be different between the InnoDB and myisam versions.  InnoDB does some "different" things when it comes to stopwords and result ranking, so we may need to make some code updates to account for this, not sure as I've only read about it and have never done any testing.

The problem is shared hosts who 'support InnoDB' but have an 8MB buffer pool.

Does the optimal buffer pool size depend on the database size?

Yes, it depends on (but does not equal) the accumulated size of all InnoDB databases and indexes. Of course it should not be set to a value higher than available system RAM (making the system swap), though.

Does the optimal buffer pool size depend on the database size?

 I only have a 20GB buffer pool on 40 gigs of data.
What you want is enough that will ensure a set of repeated views will be able to, more often than not, pull from the pool.
One way to think of this for SMF/Elkarte is how many 'full' topic views can be stored in the buffer. These results involve ~2 MB of data on Elliquiy, for example, though some of it is going to be shared (user data, etc.)
In a shared environment, this is also shared, but if you're seeing a lot of activity, you will be getting a disproportionate share anyway. This also tends to mean that it is possible to support a lot of smaller sites on less hardware, even if their sum traffic and data use is greater than a major forum.
All told, it is more important that you can store enough to satisfy a few hundred thread views (512MB, say) than trying to get a handle on how much else is running on the server.
Unless they're running on platter drives, but then you're boned anyway.

Weren't you guys kind of talking about this in #44 to some degree? This seems like a relevant issue as well, since we're talking about InnoDB and detecting such support.
Also, holy smokes, old issue! :P

That one slipped under my radar for a while.
@KeiroD #44 is more anout things like if ($db_type == 'postgresql') do something else do another thing... and IIRC it's still open due to the PM system... :-\ Yes, old issue.
Okay then, let's remove the engine so whatever is default will be picked. :yum:

https://github.com/emanuele45/Dialogo/commit/bb16cdc4e74435a5f44aced379d0e169a568edfc


Rails assets not loading with Nixpacks (possible variation)

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
I'm splitting this out from https://github.com/railwayapp/nixpacks/issues/546, as the root issue may be different.
When I deployed my project using the Heroku builder, everything looked correct. But when I changed to the Nixpacks builder, my asset pipeline failed.
Known combos:

Nixpacks builder + RAILS_ENV variable not set = assets pipeline works
Nixpacks builder + RAILS_ENV=production variable = assets do not load
Heroku builder + RAILS_ENV=production variable = assets pipeline works

To reproduce
No response
Expected behavior
No response
Environment

Rails 6 (and suspected 7)
Latest Nixpacks (default)

Additional debug:
When I compare the deployment logs, searching for "rake assets", I notice one difference that I thought was relevant:
Heroku builder + RAILS_ENV=production variable = assets pipeline works
Running: rake assets:precompile
Running: rake assets:clean

Nixpacks builder + RAILS_ENV=production variable = assets do not load
║ build      │ bundle exec rake assets:precompile                              ║
#20 [stage-0 16/18] RUN  bundle exec rake assets:precompile

It appears that the Nixbuilds are missing the "rake assets:clean" invocation.
However, I tested this theory by adding this via nixpacks.toml:
[phases.build]
cmds = [
  "...",
  "bundle exec rake assets:clean",
]

This did not solve the problem -- it appears to be an unrelated distinction.

Later, I upgraded from Rails 6 to 7, and Nixpacks builder still failed to deploy working asset pipeline. (I did not re-test Heroku builder on Rails 7.)
Eventually I added RAILS_SERVE_STATIC_FILES=1 to my project variables, and that fixed the Nixpacks deployment!
The reason I'm still filing this -- this behavior appears to be a subtle distinction between the Heroku builder and the Nixpacks builder. Is this something that should be fixed or documented in Railway, to help others coming from Heroku?
(If not, I understand -- just wanted to raise the question.)

Hi @DreadPirateShawn,
Thanks for the issue and investigation!
Nixpacks should handle this out of the box. We should also be setting the RAILS_ENV variable to production.
This should be an easy fix by simply setting those two variables in the ruby provider.

The performance of static files is higher when delivered by NGINX than by Rails.
May I ask why you are delivering them by Rails?


Content for the enhanced line pragma

Fixes #25674
This PR is also small. The main impact of this feature is that Razor debugging is better.

Thanks @gewarren
I've made the updates. I agree this one is a bit hard to grasp. The end of the span gets complicated very quickly. I also added links to the feature spec, which provides further examples.


fix: allow multiple transfers per inscription per block

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

:tada: This PR is included in version 1.0.0-beta.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


bug: Unable to set ARIA role to 'navigation' on menu component

Bug Report
Ionic version:
[x] 4.x
Current behavior:
I’m working on a new Ionic 4 app that is based on the sidemenu starter template. We have members on the team that specialize in UX and accessibility, and my app was recently tested and I got some feedback.
It was pointed out that the component used for the left pane (ion-menu) has an ARIA landmark role of ‘complementary’, and that this would mislead users of screen-readers. They would likely assume that section of the app is informative, yet non-essential content about the current page, which it is not - its function is navigation and critical for usage of the app as a whole.
I was asked to change the ARIA role from ‘complementary’ to ‘navigation’ which accurately reflects the functionality. As you can see from my repo app on Stackblitz, I was unable to do so. When adding role=“navigation” to ion-menu, it simply gets overwritten to role=“complementary”.
Expected behavior:
Adding ARIA landmark roles to ion-menu would be unnecessary; it would already have the most appropriate role for a component intended to be used as a navigation drawer : 'navigation'.
Steps to reproduce:
Add an ARIA role="navigation" to an ion-menu component. It will be overwritten with the "complementary" role.
Related code:
Repo app on StackBlitz
Other information:
Proposed Solution:
Changing the ARIA role from ‘complementary' to ‘navigation’ would improve the implementation by accurately reflecting the component’s intended purpose. Another option would be to remove the ARIA role completely, and let the developer add which ever role they choose. My personal preference leans toward the former. The reasoning behind this is that the fundamental purpose of an ion-menu is for navigation. This is supported by the Ionic documentation: “The Menu component is a navigation drawer…” and the Material Guidelines: “Navigation drawers provide access to destinations in your app”.
I’m interested in submitting a pull request that fixes this issue by making the proposed change. I’ve searched the Ionic GitHub repo for an existing open or closed issue, and have found none. This will be my first time contributing.
Ionic info:
Ionic:
ionic (Ionic CLI)             : 4.12.0 (/usr/local/lib/node_modules/ionic)
Ionic Framework               : @ionic/angular 4.2.0
@angular-devkit/build-angular : 0.13.8
@angular-devkit/schematics    : 7.2.4
@angular/cli                  : 7.3.8
@ionic/angular-toolkit        : 1.4.1
System:
NodeJS : v8.9.4 (/usr/local/bin/node)
npm    : 6.5.0
OS     : macOS Mojave

It might also be helpful to see an example of a use-case for using the ARIA role of "complementary". Here's a write-up and demo: Using ARIA Landmarks

I've submitted a PR fix for this issue: https://github.com/ionic-team/ionic/pull/18330

Thank you for the detailed issue and the PR! I have merged your PR in and it should make it into our 4.6.0 release. 🙂


Fix Android to bypass GIF image compression

Thanks for submitting a PR! Please read these instructions carefully:

[ ] Explain the motivation for making this change.
[ ] Provide a test plan demonstrating that the code is solid.
[ ] Match the code formatting of the rest of the codebase.
[ ] Target the master branch, NOT a "stable" branch.

Motivation (required)
What existing problem does the pull request solve?
Issue #724
Test Plan (required)
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See What is a Test Plan? to learn more.
If you have added code that should be tested, add tests.

Thanks for the merge

Hi, After I compress the gif picture on the Android device, the picture will not play, is this normal?

did you got any solution ?

Hi, After I compress the gif picture on the Android device, the picture will not play, is this normal?

did you got any solution ?
I gave up using compression.

Hi, After I compress the gif picture on the Android device, the picture will not play, is this normal?

did you got any solution ?

I gave up using compression.

😮


N36: Rust Game Ports Officialization

N36: Rust Game Ports Officialization.
This would fit better an announcements section, but this month, there isn't any :smile:

@AngelOnFira is adding an Announcements section for https://github.com/rust-gamedev/rust-gamedev.github.io/pull/1127, so you can still put it there. It'd either go there or Learning Material Updates, I think - Other News is for one-liners.

@AngelOnFira is adding an Announcements section for #1127, so you can still put it there. It'd either go there or Learning Material Updates, I think - Other News is for one-liners.

Ah, thanks! I think this'd be better suited for announcements, since the project itself was published in the last issue; I'll update this PR once #1127 is in.

:construction: wip

Tnx!


Getting a "Could not get code signature" error after signing app and verifying

I followed Marco Pracucci's blog on code signing Electron apps, which can be found here. After signing my app, I run codesign --verify -vvvv Application.app and spctl -a -vvvv Application.app. Both output exactly what they're supposed to.
Then when I run npm start, which starts Electron, I get the error. There seems to be nothing wrong with my code signing procedure. Am I starting the app incorrectly?

I think you need to sign every library included in Electron, an example can be found at http://electron.atom.io/docs/v0.34.0/tutorial/mac-app-store-submission-guide/#sign-your-app.

Thanks for the tip. Unfortunately it didn't solve my problem. :(
I've signed every library included in Electron and am still getting the exact same error.

I suggest seeking help from the community, you can also search old issues since there were some similar issues and solutions.


Redmond dial plan table?

Regarding the table following the text "The following table illustrates a sample dial plan for Redmond, Washington, United States, based on the normalization rules shown in the previous table"; should the table have more than one column?  It appears to be lacking any useful information.
Regards
Andy

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

ID: 847c0505-3441-b5db-1f81-c7759bffd1e3
Version Independent ID: 3c6b3820-349f-caf5-c510-a771a3b7a770
Content: What are dial plans? - Microsoft Teams
Content Source: Teams/what-are-dial-plans.md
Service: msteams
GitHub Login: @CarolynRowe
Microsoft Alias: crowe

Hello @HandyAndyOnGitHub how are you?
Maybe that's because it could also be shown as a bulleted list, like this
Redmond dial plan has this rules assigned

5digitExtension
7digitcallingRedmond
RedmondSitePrefix
RedmondOperator

I can understand that a table with only one column could be confusing.
Thank you

Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


Generate function assist should default the return type to _ instead of ()

This will unconditionally result in a compiler error, but a rather useful one:
fn f() -> _ {
    vec!["hello, world".to_owned()]
}

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> src/lib.rs:1:11
  |
1 | fn f() -> _ {
  |           ^
  |           |
  |           not allowed in type signatures
  |           help: replace with the correct return type: `Vec<String>`

Maybe this error / assist could even be added to rust-analyzer, so after generating a function and filling in the body you would only have to accept its suggestion for filling the return type (as opposed to having to save, then wait for cargo check).

We already have an assist to add a functions return type in case its not written out or written as -> _/-> . So it would make sense to me that we should put a _ instead of () here.


[beta] can't write text in slate popup forms

if a slate plugin defines a form, you can't write into the field:

:tada: This issue has been resolved in version 4.0.0-beta.9 :tada:
The release is available on:

v4.0.0-beta.9
GitHub release

Your semantic-release bot :package::rocket:


How can I consume module privates from tf controller flux?

Hi guys,
I think I have tried everything to make this run but I couldnt. I have tried to configure .terraformrc as secret, as volume, modifying the runner itself but nothing worked. Any ideas or any specific feature or configuration to get private modules from gitlab?
Thanks a lot

Hi @jjpecete
Could you please paste some snippets of your Terraform codes?

Hi @jjpecete
Have you tried setting an environment variable like the following one within the tf-runner pod?
TF_TOKEN_gitlab_com=${GITLAB_TOKEN}

Where _gitlab_com is the hostname of your private gitlab host, and GITLAB_TOKEN can be a personal access token with read_api permissions. That worked for me.
I created a secret with the environment variable and token then used the following to get the environment in the tf-runner pod:
  runnerPodTemplate:
    spec:
      envFrom:
      - secretRef:
          name: gitlab-token

Hope this help.

Closing due to lack of response but feel free to reopen if necessary. Will bookmark the solution above as a potential troubleshooting tip upon testing.


Fixed trapping NonLocalReturnControl

Hi Jeff, thanks for your excellent book and code! But I failed to run the Scala version of FindEquation.
It seems the problem came from https://github.com/jeffheaton/aifh/blob/a22f68f160e3ce5522da6e23afae99c115911c3d/vol2/vol2-scala-examples/src/main/scala/com/heatonresearch/aifh/evolutionary/train/basic/EAWorker.scala#L109-L112
where the control flow related exception scala.runtime.NonLocalReturnControl got trapped in the catch-all case t: Throwable. This patch should fix the issue.

Thank you!


Making a Windows installer for a faster boot up

https://www.pythonguis.com/tutorials/packaging-pyside6-applications-windows-pyinstaller-installforge/
This tutorial is maybe what we need


UI-456 EOF compliance/profiles bug Signed-Off-By: Tara Black <tblack@…

…chef.io>
:nut_and_bolt: Description
in acceptance (not current)
navigating directly to compliance/profiles
or refreshing that page once you're there results in a EOF
:+1: Definition of Done
change route to compliance/compliance-profiles
this will need to be updated throughout the docs as well
https://automate.chef.io/docs/asset-store/#using-the-asset-store
https://automate.chef.io/docs/asset-store/#about-the-profile-identifier
https://automate.chef.io/docs/asset-store/#api-calls
:chains: Related Resources
https://github.com/chef/automate/issues/456

The UI route: compliance/profiles was changed to compliance/compliance-profiles because we have a conflicting location route compliance/profiles defined in automate-load-balancer/habitat.
Docs didn't need updating, /profiles is still used to redirect to /compliance/compliance-profiles.


px-dropdown issue after upgrading to version 4.0.0

px-dropdown does not work when link to web-animations in line 7 is included, when I comment out that line everything works fine. Are there any known solutions to that issue? Thanks in advance for support.

I have not seen this before and can't replicate in any of our testing environments. Can you please provide the information requested in the issue template - browser, OS, steps to replicate (is it on page load or after some action), etc?

Thanks for response, my OS is windows 7 professional used with Chrome Version 61.0.3163.100 (Official Build) (64-bit). The issue arises on initial page load. When web-animations-next-lite.min.html is replaced with web-animations.min.html an issue disappears following https://github.com/PredixDev/px-app-nav/issues/29

Interesting. I wasn't involved in that discussion. Updated the import in v4.0.15.

Actually, now that I know what that import is ( 😄 ), we're not actually using neon-animation in dropdown anymore, it must be leftover from an older iteration. Removed completely in v4.0.16.


Fixed issue 5

Fixed the vulnerabilities issue using one of the suggested methods that pulls the latest stable python image.

@WilliamLi10 - To pass the DCO check, can you add your Signed-off-by: to this commit?

I think it should be added now, but I don't know how to check.

@WilliamLi10 - To be honest, this PR is a mess. (I'm chuckling in the most affably way possible)  Good learning experience but not particularly clean.
Now that you have the hang of it (I merged one of your well done PRs over in the OH Docs repo)
let's start over.  Delete your local fork.  Reclone this git repo.  Resubmit a new signed commit in a new PR.
We'll be able to celebrate with much better clarity.


[Enhancement][opensearch] provide example for snapshot

Hi,
I want to make helm chart values.yaml file for using snapshot.
My env is AWS EKS, install using helm chart.
First, make s3 repository using repository-s3 plugin.
there's several ways in your document, but best thing is using IRSA I guess.
following https://opensearch.org/docs/2.4/opensearch/snapshots/snapshot-restore/,
sudo ./bin/opensearch-plugin install repository-s3 -> possible to automate using plugins.installList in helm chart
but I don't know how to handle in values.yaml below command
./bin/opensearch-keystore add s3.client.default.role_arn
./bin/opensearch-keystore add s3.client.default.role_session_name
and we need to run ln -s ${AWS_WEB_IDENTITY_TOKEN_FILE} /usr/share/opensearch/plugins/repository-s3/token
Second, register the repository, can I use in helm chart?
PUT _snapshot/my-s3-repository
{
  "type": "s3",
  "settings": {
    "bucket": "my-s3-bucket",
    "base_path": "my/snapshot/directory"
  }
}

Currently snapshot functionality is not available in helm-charts, you need to start the cluster and then follow the manual steps to create and use snapshots. @prudhvigodithi Please correct me if I am wrong.
See https://github.com/Opster/opensearch-k8s-operator/issues/278 for configuring and using snapshots.

@Hokwang, you are correct with the use of plugins.installList to install the repository-s3 plugin.  Unfortunately the registry is not registered; we wrap this chart in another chart that runs a configuration job to create the registry.  It would be nice if this chart had that functionality for at least AWS, Azure, and GCP - and if the configuration I outline below would be part of the chart.
Despite this documentation, I would not recommend putting your AWS credentials into your Dockerfile and image.  @rishabh6788, performing any manual steps after a Kubernetes deployment is generally considered an anti-pattern.  Manual steps are not necessary with the Helm Chart.  Unfortunately Helm Chart usage is not covered in the docs.

Create a secret using your own method/automation in the same namespace as the opensearch deployment with the necessary entries.  Below I've assumed you use a client named 'default' although you may use other names:

apiVersion: v1
kind: Secret
metadata:
  name: opensearch-keystore
type: Opaque
data:
  s3.client.default.<property>: <value>

Reference the secret in your values.yaml

  keystore:
    - secretName: opensearch-keystore

The script within the opensearch init container loads the values into the keystore: https://github.com/opensearch-project/helm-charts/blob/opensearch-2.12.0/charts/opensearch/templates/statefulset.yaml#L262-L299

Using AWS access_key and secret_key:
The following properties are needed in the keystore secret:
  s3.client.default.access_key: YOUR_BASE64_ENCODED_VALUE
  s3.client.default.secret_key: YOUR_BASE64_ENCODED_VALUE

Using AWS IRSA:
opensearch does use the variables set by the AWS admission controller including AWS_WEB_IDENTITY_TOKEN_FILE.
But if you attempt to use the default configuration you will receive a 500 error during the snapshot verification check, the important detail is:
"access denied (\"java.io.FilePermission\" \"/var/run/secrets/eks.amazonaws.com/serviceaccount/token\" \"read\")"

This is because the location of the file is not permitted by the java security settings (no documentation located). The docs say the identity file should be copied or linked into OPENSEARCH_PATH_CONFIG without defining what that is.
In our configuration we override the AWS_WEB_IDENTITY_TOKEN_FILE location by providing a value in the opensearch configuration:

We remount the aws-iam-token volume that is created by the AWS admission controller to an allowed path.  Note that this volume is added to the Pod upon admission and is not part of the Helm chart.

  extraVolumeMounts:
    - mountPath: /usr/share/opensearch/config/irsa-token
      name: aws-iam-token # volume is created by AWS admission controller
      readOnly: true
      subPath: token

NOTE you cannot mount directly to /usr/share/opensearch/plugins/repository-s3/token (the location from the docs) because this will break the plugin installation within the startup script

Configure the mounted path in opensearch.yml:

  config:
    opensearch.yml: |
      # ... your other configuration
      s3.client.default.identity_token_file: /usr/share/opensearch/config/irsa-token

NOTE if you attempt to set the optional s3.client.default.role_session_name it is considered a secure setting in opensearch despite being part of the non-sensitive ~/.aws/config file.

With this configuration of the Helm Chart you can use AWS static credentials or IRSA for snapshots.

Hey, I tried following the config mentioned on this topic and I am getting this error when starting open search:
[opensearch-cluster-master-2] uncaught exception in thread [main]org.opensearch.bootstrap.StartupException: java.lang.IllegalArgumentException: unknown setting [plugins.s3.client.default.identity_token_file] please check that any required plugins are installed, or check the breaking changes documentation for removed settings	at org.opensearch.bootstrap.OpenSearch.init(OpenSearch.java:184) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.bootstrap.OpenSearch.execute(OpenSearch.java:171) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:104) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.cli.Command.mainWithoutErrorHandling(Command.java:138) ~[opensearch-cli-2.11.1.jar:2.11.1]	at org.opensearch.cli.Command.main(Command.java:101) ~[opensearch-cli-2.11.1.jar:2.11.1]	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:137) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:103) ~[opensearch-2.11.1.jar:2.11.1]Caused by: java.lang.IllegalArgumentException: unknown setting [plugins.s3.client.default.identity_token_file] please check that any required plugins are installed, or check the breaking changes documentation for removed settings	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:608) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:549) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:519) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:489) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.common.settings.SettingsModule.<init>(SettingsModule.java:178) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.node.Node.<init>(Node.java:578) ~[opensearch-2.11.1.jar:2.11.1]uncaught exception in thread [main]	at org.opensearch.node.Node.<init>(Node.java:407) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:242) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.bootstrap.Bootstrap.setup(Bootstrap.java:242) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.bootstrap.Bootstrap.init(Bootstrap.java:404) ~[opensearch-2.11.1.jar:2.11.1]	at org.opensearch.bootstrap.OpenSearch.init(OpenSearch.java:180) ~[opensearch-2.11.1.jar:2.11.1]	... 6 morejava.lang.IllegalArgumentException: unknown setting [plugins.s3.client.default.identity_token_file] please check that any required plugins are installed, or check the breaking changes documentation for removed settings	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:608)	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:549)	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:519)	at org.opensearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:489)	at org.opensearch.common.settings.SettingsModule.<init>(SettingsModule.java:178)	at org.opensearch.node.Node.<init>(Node.java:578)	at org.opensearch.node.Node.<init>(Node.java:407)	at org.opensearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:242)	at org.opensearch.bootstrap.Bootstrap.setup(Bootstrap.java:242)	at org.opensearch.bootstrap.Bootstrap.init(Bootstrap.java:404)	at org.opensearch.bootstrap.OpenSearch.init(OpenSearch.java:180)	at org.opensearch.bootstrap.OpenSearch.execute(OpenSearch.java:171)	at org.opensearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:104)	at org.opensearch.cli.Command.mainWithoutErrorHandling(Command.java:138)	at org.opensearch.cli.Command.main(Command.java:101)	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:137)	at org.opensearch.bootstrap.OpenSearch.main(OpenSearch.java:103)

What am I doing wrong?