Consider using go's native vendoring mechanism

Hello,
We recognized that starting from that commit:
https://github.com/cznic/ql/commit/f50fc7d29ffc99ce551064ea56bacb92dbf4364c#diff-21ce9dcd10d134f8b0f327ac1ee4aa4dR24
ql started vendoring the go4.org/lock library as well as the github.com/cznic/exp/lldb library in a way that does not play well with other vendoring tools, i.e. glide.
Can you elaborate on the reasoning why you chose "vendored" instead of the go "vendor" directory? I can personally think of many, but I have the impression, that vendor pruning in consuming applications becomes more ubiquitous as vendor tool support improves.
xref https://github.com/coreos/rkt/pull/2875

This being an importable library, it should not vendor at all as far as I understand?

Right, if ql envisions to be a library-only it should strongly consider not to vendor at all.

I have never used any vendoring mechanism, which means I have never had any reason to read anything about how it works. When I was asked to vendor some packages with ql, I used "vendored" in hope to not interfere with any vendoring mechanism I have no knowledge about.
I will appreciate if you can please explain to me in more detail what

does not play well with other vendoring tools, i.e. glide.

means. Thank you.

Right, if ql envisions to be a library-only it should strongly consider not to vendor at all.

That is my opinion as well, but then the Debian guy (hi @onlyjob) asked for, first making releases (#121) and, later, for the vendoring (#122). Note that #121 mentions rkt as well, so I guess you guys might want to coordinate ;-)

Debian usually removes any vendoring in things it packages, so i have no idea what that is about.

Hey @cznic, thanks a lot for the quick response :-) Unfortunately the vendoring situation in the Go ecosystem is not in the best shape right now, I agree :-(
What I meant with:

does not play well with other vendoring tools, i.e. glide.

Tools like https://github.com/Masterminds/glide actually are aware of nested vendored dependencies. So if you import lock and lldb, these tools will "flatten" nested vendored dependencies from:
prj - vendor - ql - vendor - lldb
                          \- lock

to
prj - vendor - ql
            \- lock
            \- lldb

Since in the case of "lock" and "lldb" you put those dependencies in a custom "vendored" folder, consumers of "ql" will automatically get these, which on first eye-sight is great :+1:
But if the sample prj project also uses the lock library for other purposes other than ql, it must vendor it also. But here is the problem: It will  vendor lock directly and transitively from your project, hence it will be vendored twice.
My suggestion in the case of ql is to use a tool like https://github.com/Masterminds/glide to pin the used external libraries, but not check in the vendor directory. This mode of operation is supported by glide as far as I understand.
If help is needed I am more than willing to prepare a PR :-)

@s-urbaniak Thank you for the explanation, appreciated. I even think I understood it ;-)
First two things which jumped to my mind are

Need to know @onlyjob 's opinion first as I don't want to [possibly] break what was made for his earlier request (#122) without him approving such change.
Is there any [good] option to, if at all using vendoring, use the mechanism supported directly be the Go build system, without dependencies on 3rd party tools (glide)?

If help is needed I am more than willing to prepare a PR :-)

I will try to use that offer as much as I can B-)
But we must first find a consensus on the next steps.

Go vendoring should not be done by libraries (I.e., non-main packages), at all, ever. If there's a specific version of a dependency that this package requires I think the only solution today is to state that in the readme and let the consuming project vendor as appropriate.

Go vendoring should not be done by libraries (I.e., non-main packages), at all, ever. If there's a specific version of a dependency that this package requires I think the only solution today is to state that in the readme and let the consuming project vendor as appropriate.

That's what @s-urbaniak proposal's would achieve. Having a glide manifest but no /vendor dir will mean that consumer apps will be pinned to the version specified here, but no actual code would be vendored in this repo. That would be automatic and tool-supported, as opposed to having this human-only info in the README.

@calmh yes, that is exactly the consensus in Go currently, hence my proposal to leave only metadata about dependencies checked in.

Go native vendoring could be applied to everything but github.com/camlistore/go4/lock due to problems described in #122. Unfortunately go4/lock is a part of large and messy code repository with many dependencies. ql uses small portion of go4 and the latter is unstable to package separately. Moreover they strongly encourage vendoring and for re-distribution it is useful when go4/lock is vendored manually without using native vendoring functionality. It is a practical concern -- I hope #122 provides some insights to why it is necessary...

That's a small package, I'd probably just copy it out as github.com/cznic/ql/internal/lock and be done with it.

@calmh That's indeed a good idea, but also lldb is vendored that way, I have some idea around that and will come up with a suggestion PR.

Sorry, @calmh, what do you mean "copy it out"? And why?
Please keep it as it is if you could. How is copying it out should help? We shouldn't ship those libs separately...

@onlyjob "Copying out" means manually copying the source files into this repository, so that it ceases to be a dependency. A good strategy when the dep isn't large; a little copying is better than a little dependency.

As @peterbourgon found github.com/cznic/ql#Options let's  github.com/cznic/ql/vendored/github.com/cznic/exp/lldb#OSFile escape, hence if a consumer pulls in github.com/cznic/ql, this will be of a different type than github.com/cznic/exp/lldb#OSFile.
I therefore suggest not to put lldb in the "vendored" directory, but rather point to it in the readme (, and additionally machine-readable via glide metadata), additionally hide "flock" as an internal package, so consumers are not confused if they vendor it themselves.
I am happy to help out with a PR.
/cc @cznic @onlyjob

I think I would understand term "copying in" but "copying out" in regards to "copying the source files into this repository" is confusing... :)
At the moment those deps are "sub-vendored" i.e. copied in, and imported from "vendored" directory.
What's wrong with that? Is there are any known collisions between "vendored" directory and Golang vendoring tools? I do not understand what problem you are trying to solve here...

@onlyjob The problem is (as explained above) that the vendored github.com/cznic/ql/vendored/github.com/cznic/exp/lldb#OSFile interface escapes the public API of ql, hence consumers won't be able to use github.com/cznic/exp/lldb#OSFile, since they are of different type, and no type coercion is possible.
Also see the https://github.com/peterbourgon/wtf repository for a distilled version of the problem.

One of the types exposed by the API of ql returns a type from the vendored directory. Hence, one has to import the vendored package as a user of ql. This is no sane practice.
Libraries should not vendor and more importantly not expose customly vendored types.

I think I understand all of the problem(s) discussed above. My decision is to not take sides on this and to do whatever all of you guys agree to do (or not to do). I hope there's no hurry, so please discuss and please find a consensus, whatever it will be. Let me explicitly say that it means I don't want to break the #122 changes without @onlyjob feeling comfortable with it, regardless of what I now think about that change.
Meanwhile, it seems to me that adding glide metadata would not break anything #122 brought, so I think this possible partial change may have a consensus already. Is that the case?

Problem originates from special treatment of "vendor" directory by Golang, right? Is "vendored" directory affected as well? If so then renaming it to "external" (or something similar) should address the problem.
I had a look at "wtf" repository and I think it is a typical example of broken/incorrect "inside-out" approach that is so typical to Golang. No, it is not binary's responsibility to "vendor" its libraries dependencies. Libraries can have their own independent dependencies that doesn't have to be exposed to application. In this particular case ql uses its own private 3rd party libraries and we should be fine as long as ql (re-) distribute 3rd party code within its source tree without relying on Golang vendoring functionality. I hope that makes sense.

@onlyjob Hey, thanks for your comments.
Unfortunately in the case of ql your assesment only applies to the vendored lock library, but not to lldb. As I explained above, OSFile leaks, hence it is not a private library used internally. The problem still remains in this case. As for lock, yes, this could be left internally "vendored", as long as no types leak in the ql API.

When "vedoring" lldb, I didn't realize the leaking problem. It was an oversight.
@onlyjob , do you see a chance for correcting this mistake while keeping the Debian package up to standards? If necessary, cznic/exp can be killed (it was always marked as experimental/unstable) and its packages can become standalone with a stable status. It would mean taking care of one more package for the maintainer, probably yourself.

Due to my illiteracy in Goland I don't understand the problem with sub-vendoring "leaky" libraries but I'll take care of "lldb" packaging if it will be split from "cznic/exp" into its own repository. @cznic, thank you very much for your careful and reasonable approach. :)

@onlyjob @cznic thanks!


mockup a landing page for BNBintel so we've got something to send to clients

This is a MOCKUP request only, we're not going to build anything on this gem, I just want a page on BNB.com where I can point people.
We're pitching the BNBintel service to other clients, but/and we don't have anything to show people as a document. I can pull up screenshots and mockups, or demo them how it works for Institute. But would be nice to have a one-page that shows the features and benefits, and make it LOOK like a SaaS product a little bit.
BNBintel is a forked version of https://github.com/ankane/blazer which lists some features/benefits. But that's maybe not a great start.
But thinking through what it should actually communicate:
WHAT: BNBintel is a lightweight business intelligence (BI) platform that sits alongside your app. Admins can use it to peek at their app's data without having to formalize a report. It's fast and dynamic, and it's admin only.
SHOW: screenshots showing that it can do cute things like: make simple graphs, use a time selector, etc.
I think we can use the kind of 'every SaaS ever' template like https://helloquery.com - we don't need a revolutionary design pattern.

Couple of screenshots from institute examples:

This is all probably a writing task first (the primary material a UX designer works with is WORDS!). But I'm open to just copying the structure / outline of a similar project, we don't need to generate this from scratch.

@mattkirkland I think the structure would be similar to the website you linked above.
Here is what I came up with in words. Let me know of this alignes with what you are thinking.
Get data about your product at your fingertips
BNBintel provides instant access to your app's real-time data without the hassle of formal reports. Quickly check key metrics like revenue and signups, and stay informed about your app's performance at all times.
[Screenshot of a dashboard]
Build queries and reports
Easily create custom queries and insightful reports, whether you prefer a hands-on approach or delegate to our expert team. Analyze user behavior, feature performance, and market trends effortlessly, without the need for specialized expertise.
[A short video/gif of writing a query / saving a query and seeing the result / video of creating a report]
Customize your dashboard
Tailor your monitoring experience with BNBintel's dynamic dashboard. Curate a comprehensive view of your app's performance metrics, from revenue trends to user engagement, to track progress and identify growth opportunities.
[Short video of adding graphs to dashboard]
View reports on the go
I know our current mobile interface doesn’t look great. But when it does, it would be nice to include this part.
Stay connected to your app's performance with BNBintel's mobile-friendly design. Access critical reports and real-time insights anytime, anywhere, ensuring you're always informed, whether in the office or on the move.
[Screenshot/screen recording of the mobile interface]
Edit and export
Take control of your data with our editing and export capabilities. Fine-tune reports on the fly and export data with ease whenever you need. Seamlessly share insights with stakeholders and team members and integrate data into other platforms for effective collaboration.
[Short video of exporting a report]

I think this is a great start. Let's take this and mock it up in the same format we use for case studies: eg
https://brandnewbox.com/case-studies/neumz/
That uses full-width image stuff, but we aren't limited to that - we can do text-next-to-image, etc. We've got the same grid to work with we use anywhere else on that site.

@mattkirkland here is a quick mockup of the page for BNBIntel.
I need help taking better screenshots or screen recordings since I don't know how some of the functions work.

These seem fine, and it's OK to use placeholder screenshots for now.  But let's make this a little more interesting? We could mix up the layout, show mobile versions (mocked up on a phone, etc), add some additional visual interest.

Threw some notes onto Landing Page 2, Page 1. Let's rework that into a final proposal. I added some copyedit notes and rearranged section ideas.


added card widget

Describe your changes
Added Card Widget
Screenshots [Optional]

Issue ticket number and link
#65
Checklist before requesting a review

[ ] I have performed a self-review of my code
[ ] I have added tests

@evshi i have added a very basic card widget for now, its yaml is similar to what Sana did used for CardComponent except Image property. This is what we can achieve with it. Although i am not sure about current yaml as it is more relevant to web than flutter. What do you suggest  ?
Like for instance -> instead of crossAxis we are using justifyItems here


Android: Compiling ops yields "THIS_TYPE_IS_NOT_SUPPORTED" for cwise_op

Using TF 1.9.0, I cannot build applications for Android due to errors from cwise_op.
Building for ARM v8, the error is THIS_TYPE_IS_NOT_SUPPORTED:
In file included from ./tensorflow/core/kernels/cwise_ops_common.h:29:
In file included from ./tensorflow/core/kernels/cwise_ops.h:23:
In file included from ./third_party/eigen3/unsupported/Eigen/CXX11/Tensor:1:
In file included from external/eigen_archive/unsupported/Eigen/CXX11/Tensor:31:
In file included from external/eigen_archive/unsupported/Eigen/CXX11/../SpecialFunctions:50:
external/eigen_archive/unsupported/Eigen/CXX11/../src/SpecialFunctions/SpecialFunctionsImpl.h:177:5: error: static_assert failed "THIS_TYPE_IS_NOT_SUPPORTED"
    EIGEN_STATIC_ASSERT((internal::is_same<Scalar, Scalar>::value == false),

For ARM v7, the error is no matching function for call to 'acosh':
In file included from ./tensorflow/core/kernels/cwise_ops_common.h:29:
./tensorflow/core/kernels/cwise_ops.h:55:12: error: no matching function for call to 'acosh'
    return std::acosh(a);
           ^~~~~~~~~~

The exact bazel command is quite simple and is provided below.
This is an isolated issue which crops up when trying to build a larger target (which depends on the cwise kernels). I can provide additional information about the larger target, but the error is the same and boils down to being unable to compile cwise_ops. The same error also occurred on TF 1.8.0.
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No (failure occurs when compiling TF target)
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 16.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N/A
TensorFlow installed from (source or binary): Source
TensorFlow version (use command below): 1.9 (git tag v1.9.0)
Python version: (3.5)
Bazel version (if compiling from source): 0.15.2
GCC/Compiler version (if compiling from source): Android NDK r16b
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce:

# For ARM v8
bazel \
  --crosstool_top=//external:android/crosstool \
  --host_crosstool_top=@bazel_tools//tools/cpp:toolchain \
  --config=android \
  --cpu=arm64-v8a \
  --fat_apk_cpu=arm64-v8a \
  --verbose_failures \
  --cxxopt=-std=c++11 \
  --copt=-D__ANDROID_TYPES_SLIM__ \
  --copt=-DIS_MOBILE_PLATFORM \
  //tensorflow/core/kernels:cwise_op

# For ARM v7
bazel \
  --crosstool_top=//external:android/crosstool \
  --host_crosstool_top=@bazel_tools//tools/cpp:toolchain \
  --config=android \
  --cpu=armeabi-v7a \
  --fat_apk_cpu=armeabi-v7a \
  --verbose_failures \
  --cxxopt=-std=c++11 \
  --copt=-D__ANDROID_TYPES_SLIM__ \
  --copt=-DIS_MOBILE_PLATFORM \
  //tensorflow/core/kernels:cwise_op

Updates: Changing the NDK to r17b seems to fix this problem. Tested on master and tag v1.9.0 with both the ARM v7 and ARM v8 versions of the command.
That said, when using NDK r17b, I get the following message from bazel:
The major revision of the Android NDK referenced by android_ndk_repository rule 'androidndk' is 17.
The major revisions supported by Bazel are [10, 11, 12, 13, 14, 15, 16].
Bazel will attempt to treat the NDK as if it was r16.
This may cause compilation and linkage problems.
Please download a supported NDK version.

Is this warning message out of date? Does TensorFlow for Android now expect/depend upon r17b to function?

Nagging Assignee @poxvoculi: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

@petewarden : Is this your issue, or an eigen issue?

Nagging Assignee @petewarden: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @petewarden: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

@poxvoculi which NDK version are support by now, both bazel and makefile

Nagging Assignees @petewarden, @rmlarsen: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignees @petewarden, @rmlarsen: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignees @petewarden, @rmlarsen: It has been 45 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

We're now deprecating mainline TensorFlow Android builds in favor of TensorFlow Lite, so closing this as unlikely to get fixed.

@peterwarden.. so if i need full libtensorflow_cc.so for android which will be last tag ..most of the time model is not comoatible for tensorflow lite so what should be done?


AOI Map - Hold CMD for Mac OS

Purpose
When a User is on a Mac, the AOI Map screen instructs the user to "Hold CMD to select an Area of Interest"
Related Issues
Fix #1096

162/163 Can we future proof it with ^mac.* and macRegex.test(window.navigator.userAgent.toLowerCase());


Open a pdf file

Perhaps, can you help me with a question - how can I handle opening a pdf file?
const CDP = require('chrome-remote-interface');

const url =  'https://dph.georgia.gov/sites/dph.georgia.gov/files/related_files/site_page/Emergency%20Protocols%20and%20Procedures.pdf';

CDP(async (client) => {
    const {Page} = client;
    try {
        await Page.enable();

        await Page.navigate({url: url});
        await Page.loadEventFired();

        console.log('After');

    } catch (err) {
        console.error(err);
    } finally {
        client.close();
    }

})

Script all time wait Page.loadEventFired(); and nothing happens after.
Is it possible?

Maybe using Page.setDownloadBehavior like this:
await Page.setDownloadBehavior({
    behavior: 'allow',
    downloadPath: '/tmp/'
});

But AFAIK this is not implemented yet (tried up to 62.0.3192.0).

I somewhere read that Chrome can open pdf to views. I thought I can make a screenshot for pdf, looks like it is not possible.

Page.setDownloadBehavior might be your solution but we cannot try it yet, I'm afraid we'll have to wait for the next Chrome release.
Anyway, taking PDF screenshots with Chrome is overkill IMHO, that would be merely a file conversion, for example (using ImageMagick):
convert file.pdf file.png

I guess there are a number of libraries that allows you to accomplish this programmatically.
You may also want to ask this in the Google Group.
I'm closing this for now, feel free to add any useful info though.

Thank you for help.
Information for someone, now I open files in the docs.google.com and then take a screenshot:
let url= `https://dph.georgia.gov/sites/dph.georgia.gov/files/related_files/site_page/Emergency%20Protocols%20and%20Procedures.pdf`;

if(/\.(pdf|ppt|doc|docs|excel|dot|wbk|docm|dotx|dotm|docb|xls|xlt|xlm|pot|pps|pptx|pptm|potx|potm|ppam|ppsx|ppsm)($|\W)/.exec(url)){
    url='https://docs.google.com/gview?url='+url.trim()+'&embedded=true&toolbar=hide';
    wait=5000;
}

...


Add SwiftLinter

add Swift Linter in a Xcodeproj file to start cleaning up each rule
disabled all default rules to re-add one by one
other changes in here from Async work, PR will simplify when other PR is merged

Couple of things. first we already have a .swiftlint.yml in the root of the repo, so if we're adding/changing rules it should be done there. Secondly you appear to have several updates to your swiftlint in the form of other PR's that look to be just commits against this PR. Since they are all relative to this one, I suggest combining them to this one, as this one is still 'in progress' until it is merged. You can keep making new commits against this one, and not need to open a new PR for every changed.

the .swiftlint.yml file I currently have in here is for in place cleanup. When I open this PR (no longer draft) I will remove my working copy and update the project one

I see, okay.  That's fine then.
Thank you for removing the 3 redundant PR's from yesterday, but 2 more popped up today. Please update your process, so you are not generating new PR's on what is really just work against PR. The PR will automatically track any commits made to the branch you created it from ([your-repo]/SwiftLint). If you make a branch from that to try something, all you need to do is merge it back into [your-repo]/SwiftLint and push, and the PR will track those changes.

Please close the pr and merge changes made here into #515


BSON serialization spec compliance

https://jira.mongodb.org/browse/PHPC-336
https://jira.mongodb.org/browse/PHPC-329
https://jira.mongodb.org/browse/PHPC-331
https://jira.mongodb.org/browse/PHPC-343
https://jira.mongodb.org/browse/PHPC-344

@derickr: Feel free to take a look at this and my test changes. I was able to get the 5.3 build working (although I still seem some local failures about missing OpenSSL types), so I'll plan to merge this in tomorrow.

I'm not sure why so many unrelated things are in the same PR!
I haven't read the latest and greatest "BSON serialization spec" so I don't know if this does indeed confirm to it, or makes actual sense.
The code itself looks good to me though.

I'm not sure why so many unrelated things are in the same PR!

I created half of the tickets after starting PHPC-329 and most of the code was inter-dependent.


MB-12440: Rename HandlerContext to HandlerConfig

MB-12440 for this change
Summary
In go a context has a very specific meaning. In retrospect, the currently named HandlerContext is not a context, but is really a config that is initialized once at server startup.
Rename HandlerContext -> HandlerConfig (and also rename variables that store the new HandlerConfig)
This was done almost entirely with automation, but a few of the variable names were tweaked by hand.
Setup to Run Your Code
make server_test

Verification Steps for Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

Verification Steps for Reviewers
Because this is a rename, there seems little chance that this would cause a regression if the code compiles.
Backend

[ ] Code follows the guidelines for Logging
[ ] The requirements listed in Querying the Database Safely have been satisfied.

I found some files that still reference HandlerContext:

Most of them are comments, but some are function names that could be confusing if we left them. Otherwise, looks like the change is sound and tests work locally!

I found some files that still reference HandlerContext:
...
Most of them are comments, but some are function names that could be confusing if we left them. Otherwise, looks like the change is sound and tests work locally!

Thank you! I believe I've fixed all of them and rebased onto the latest master


Fix for RTL icons.

@awikkerink, @dlockhart
This change gets RTL icons working again (check demo page).  Basically, the svg was not ready yet when this code was running.  Not entirely sure why test would work while the demo page was not.  Would really like perceptual diff here.  This was previously working - it's possible that a recent change to iron-icon caused this regression.
This fix merely gets this component working again - I am going to pursue updating to the recent RTL support provided by iron-icon in a separate PR.

See #82. iron-icon already did this stuff it seems

Thanks.  Yeah... up to speed on their implementation.  :)
I am not a huge fan of the getComputedStyle perf that comes with it but it's worth trying it.

LGTM


Allow deviation from original oref0

First and foremost, important note: I CANNOT currently check what happens in Trio as I just started on U-200 testing (and are thus above 1:3 again) - sorry! I also don't have the logs anymore, its reset. I have solely looked at the code whilst I was working on something else related to U-200 and caught this by coincidence. I have thus NOT been able to gather log output and behavioral analysis interim. Therefore I'm not 100% confident this is an issue in Trio currently, but based on the changes made to the code I believe it is (or will be in 1.0) based on how it caused issues in iAPS in the past and how the algorithm actually wishes to behave when its a 1:1 copy of the original source. The feature request below therefore assumes this is indeed happening.
Is your feature request related to a problem? Please describe.
The original design of oref0 put a hard cap on carb ratios of 1:3 as it was deemed to be "impossibly low". The limitation was introduced to prevent bad conversions from mg/dl to mmol/l leading to issues. However, myself and what I consider a non-negligible amount of other users have an insulin resistance that requires lower carb ratios to be set; its very far from impossibly low. :) Whilst the app allows it, the algorithm won't; which leads to unexpected behavior/issues and wrong interpretation of insulin-profile changes. I remember in iAPS this simply caused oref0 to ignore anything lower than 3 and pretended it to be 3 instead (leading to unexpected behavior in the app) and this was subsequently patched in the local (to iAPS) implementation of oref0.
Trio initially included this "bugfix", but it appears (see disclaimer above) that this has been rolled back.
I gather that from reviewing these particular pieces of code in the Trio repository:
https://github.com/nightscout/Trio/blob/dev/trio-oref/lib/profile/carbs.js#L16-L19
And these in the trio-oref repository of which I assume it may be used in the future:
https://github.com/nightscout/trio-oref/blob/dev/lib/profile/carbs.js#L16-L19
https://github.com/nightscout/trio-oref/blob/dev/bin/oref0-meal.js#L81-L85
https://github.com/nightscout/trio-oref/blob/dev/bin/oref0-autotune-prep.js#L83-L91
Describe the solution you'd like
It'd be nice if Trio offers a way to overrule this limitation, if needs be with a warning, so the system will honor the setting. I think capping the ratio to 1:1 should be fine (no lower fractions) and is reasonable. However, it could be designed in such a way that 1:3 is the default cap and a specific override is required to overcome the limitation. The improvement in experience would be that on U-100, the system actually doses sufficient insulin to cover the carbs.
Describe alternatives you've considered
Change it in oref0. But that's not possible/is dismissed as an option as the developers:
a.) are not quite sure anymore what the issue was that lead up to this implementation (other than the very educated guess about mg/dl -> mmol/l conversion sometimes leading to issues in a past implementation) as it was implemented a long time ago,
b.) note that there are insufficient reports of diabetics that are experiencing complications from this limitation (I was the first to notice and report it) and that there are thus likely only very few diabetics with such a low I:C-ratio. (Though I'm not sure if many people would actually notice that this may be at the core of issues they could be experiencing; in iAPS for example it was just a note in the log that oref0 was capping it to 1:3; you wouldn't notice a thing in the UI, but you would notice inexplicable suggestions. (The bolus calculator I believe was affected by it, until it got... reworked.))
The openaps developers therefore recommend making local changes to the algorithm/implementation as needed instead of modifying oref0 as a whole. Hence why I'm suggesting to have Trio offer a local override to this safety cap in accordance with this suggestion. :)
If there is no desire to cater to people with very high insulin resistance in the default featureset: then another alternative to consider is to at the very least then offer a clear instruction or other (automated) means to patch the code/build Trio with this safety cap lowered to 1:1 or even 1:0.5.
Additional context
Discussion on changing it in oref0: https://github.com/openaps/oref0/issues/1453
Technical Details
oref0 implementation must be modified/have an option to override the values for "impossible" values.
User Impact
The app and algorithm would continue to function as expected even whilst having an I:C lower than 3. This helps people with high insulin resistance. Whilst I understand the vast majority of Type 1 diabetics do not have such a low I:C, there are those of us who do and there is a growing interest in insulin pumps among Type 2 diabetics who may also benefit from accepting high insulin resistance features.
I have not analyzed whether or not there are similar caps for ISF, but I had not directly found any.
Thanks for your consideration.

Sorry I don't have much to add, but I'll just mention that the bare minimum "solution" has been implemented in Trio v1.0, as there is a guardrail that limits carb ratio to a minimum of 3.0 g/U. If oref does get altered to allow a stronger ratio, then that guardrail will of course be lowered to match the new minimum allowed by oref.

@MikePlante1 Good, at least that makes it so people actually know what's happening on that end. :) However, that only remediates the issue of not being able to set values that are incompatible with the default version of oref0. It'd be really nice if there is a feature that can overrule this, which affects both the I:C you can set (like you mentioned) as well as modifying the couple of places where this is enforced by oref0 to be more lenient. Or otherwise at the very very least provide a clear set of instructions in the documentation (and perhaps readme) on how to change this in a personal clone or perhaps make a separate branch that removes this, rather arbitrary, limit and allows for lower values. (Eg 0.5 to 1.0 being no problem). There are several ways to do it, but doing it I think is very important to a group of T1D users with high insulin resistance as well as a significant chunk of T2D's.


support json and yml config files

Coverage increased (+0.5%) to 49.323% when pulling e546f67ec829d92e58e00d9a3b841c456132f484 on nobodyiam:json-yml-support into 8c71054d4726c30f6d6c35b538334d5e3bdc6289 on ctripcorp:master.


[bugfix] './locale' path not found in moment/src/lib/locale/locales.js

seems root of issue was introduced here: https://github.com/moment/moment/commit/9ce89e7fea881b39be23b8c0646f7ef7817985d9
So, this PR reverts it and fixes the following issues:
#4505, #5472, #5497, #5501, #5500, #5378, #5495

Coverage decreased (-0.04%) to 88.425% when pulling 7df7e6b6a38d6974ba49ae24004e2a54b14f7b6b on ApacheEx:patch-1 into 475a1e0603aff05329181e1803d0fb85b0a12bf3 on moment:develop.

also, as possible fix:
replace "module": "./src/moment.js" to "module": "./moment.js"
but don't know exactly if this "module" is really needed and what was the reason to introduce it.

also, as possible fix:
replace "module": "./src/moment.js" to "module": "./moment.js"
but don't know exactly if this "module" is really needed at all and what was the reason to introduce it.

Can confirm this fixes #5495 the issue and you are the MVP here.
Also commit description is not clear  in 9ce89e7

FYI "module" is supposed to be an ecmascript module and "./moment.js" is a commonjs module.

Having the same problem, reverted back to 2.24 until a fix is available

also, as possible fix:
replace "module": "./src/moment.js" to "module": "./moment.js"
but don't know exactly if this "module" is really needed at all and what was the reason to introduce it.

thanks sir, you save my day 👍

Can confirm that this resolves it for us. Can this be merged and released on NPM soon?

ok guys, I see it's fixed in 2.25.2.
So, I'm closing this.

"module" property was removed in 2.25.3 (https://github.com/moment/moment/commit/0c709ba7e463c12c68d7bf217fbdff4ed3b46f2c)
So, it was the right solution.


File selection dialog shows up in Japanese instead

Windows Terminal version
1.11.3471.0
Windows build number
10.0.19042.0
Other Software
N/A
Steps to reproduce

Open up settings for Windows Terminal
Go to any profile, click on Browse for anything (can be Command Line, Starting Directory, Icon or even Appearance > Background Image).
Dialog box shows up in Japanese instead of English.

Expected Behavior
Dialog box is supposed to appear according to the system language (en-SG in my case).
Actual Behavior
See the following screenshot:

Yes, I have the Japanese language pack installed as well as the Chinese language pack.
Here's the screenshot of the language list in settings:

Ok, so after posting the screenshot, I realised that I didn't actually have the en-sg language pack installed so I went ahead and installed that.
It seems to be working properly after installing the language pack:

I assume Windows Terminal was defaulting to Japanese because it's the next one in the list with a language pack installed, but I didn't have similar issues with other applications.

@axelandrejs any ideas what's going on in this one?
I suppose it makes sense that the picker would show up in Japanese if the first language in the list didn't actually have the language pack installed. That being said, I would have expected the rest of the OS to be in Japanese too, so idk.
This does seem like it's got a known resolution, so I'm tempted to close it. I think I'll leave this open for a while longer to see if anyone's got any ideas why this works the way it does, but I'm not sure there's much else for the Terminal to do here.

We do support partial localization for high-value strings without the need for a full language pack being installed. Though it is odd that this UI wouldn't fall under that bucket. I can see about finding out, but yes without the language pack installed the experience is going to be torn.

Huh. Well, sounds like enough of an answer to me. Thanks Axel!


Added overview to Basic OOP in README.md

All the curriculum for OOP has been added as a table in the README.md.

All good. @mhaidarh: However we need to finish 'TBA' part

@kishore-narendran Thank you again for migrating them.
@sigit-prayoga Definitely, we probably can do that in Sunday or next week.

Almost forgot. Should we omit the Duration?

Okay, we should omit them. I actually planned to edit them tonight, but I should have a rest right now.


CLOUDP-64100: Implementing e2e test for metrics disk - atlas

Proposed changes

Jira ticket: CLOUDP-64100

Checklist

[x] I have signed the MongoDB CLA
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added any necessary documentation (if appropriate)
[x] I have run make fmt and formatted my code

Further comments

TestAtlasAlerts/List_with_status_OPEN: alerts_test.go is failing because I add a new alert in cloud-dev for testing the ack/unack


Add convert toml to json command

thanks

I assume you mean the CLI, the language server already has such commands.

This is now possible in the new CLI by running taplo get -f foo.toml -o json.


Add a ClusterSet deletion webhook on the leader cluster

Add a ClusterSet deletion webhook to fail the ClusterSet deletion request
in the leader cluster when any MemberClusterResource exists.

/test-multicluster-e2e

In commit message MemberClusterResource -> MemberClusterAnnounce

/test-multicluster-e2e

/skip-all


At the end of the application process, few understood that they would be able to re-use their identity account in other services

Impact: Without understanding the broader utility of their identity account, users are more likely to see verification as an unnecessary burden.
Evidence: When discussing the process at the end of the session, most thought the identity verification was ‘only for the bus pass’.


libp2p v1.2.1

This PR updates the project to use js-libp2p v1.2.1. This has been verified to fix downloading of files between peers.

:tada: This PR is included in version 5.2.2 :tada:
Your semantic-release bot :package::rocket:


[AmazonEC2 driver] -- make "Autoassign Public IP address" configurable

see issue #581
"Autoassign Public IP address" (https://github.com/docker/machine/blob/master/drivers/amazonec2/amz/ec2.go#L189) should be configurabile in order to create a new host into a VPC's private subnet, like
--auto-public-ip = "true" >> a public Elastic IP Address is assigned and port 22 is checked against it for monitoring when the new host come up
--auto-public-ip = "false" >> do not set any public IP address and check port 22 of the new instance's private IP address (retrieved via EC2's APIs)
AS

Mine! I'll look into this tomorrow morning.

:+1:
I would love to see this!

@CivJ / @andrea-spoldi: I've added this in #1063, mind testing to see if it's what you guys wanted?

I was about to test this when I noticed the [build failure] (https://travis-ci.org/docker/machine/builds/60405134). I'll hold off until that's resolved. @sthulb thanks for getting this in so quickly, I'm pretty excited to see it in action.

Fixed locally.

Creation and SSH are working for me:
$ ./docker-machine_darwin-amd64 create -d amazonec2 --amazonec2-access-key=$AWS_ACCESS_KEY_ID --amazonec2-secret-key=$AWS_SECRET_ACCESS_KEY --amazonec2-vpc-id=$AWS_VPC_ID --amazonec2-private-address-only  dm-03-poc
Private: %#v true
INFO[0000] Launching instance...
INFO[0182] "dm-03-poc" has been created and is now the active machine.
INFO[0182] To point your Docker client at it, run this in your shell: eval "$(docker-machine_darwin-amd64 env dm-03-poc)"

However, I may have encountered a bug (possibly in the docker client):
$ docker -v
Docker version 1.6.0, build 4749651
$ ./docker-machine_darwin-amd64 ls

I cannot list my machines, and we hang here for at least 10 minutes. I suspect we're hanging on the API call to AWS that fetches the status. As you can see, I'm running the OXS docker-machine build.

This is working for me now! Maybe it was a problem on Amazon's side?
$ ./docker-machine_darwin-amd64 ls
NAME             ACTIVE   DRIVER       STATE     URL                      SWARM
clean                     virtualbox   Stopped
dev                       virtualbox   Stopped
dm-03-poc        *        amazonec2    Running   tcp://<IP_ADDRESS>:2376
ec2-docker-poc            amazonec2    Running   tcp://<IP_ADDRESS>:2376

I think we're good to go here.

Closing as #1063 is merged.


/dist folder js files are not working

Please fix /dist folder js files as they are not working.

These will be deleted


feat: added payout methods section

PR Fixes:

Added payout methods section

Features :

User can add their upi and solana addresses
Validation of upi and solana address format using regex
Success and error messages
Only 2 upi and 2 solana addresses can be added for a user
Avoided duplicate values
User can delete a particular address
Cross device compatability

Resolves #873
Take-your-development-skills-from-0-to-100-and-join-the-100xdevs-community.webm
Checklist before requesting a review

[x] I have performed a self-review of my code
[ ] I assure there is no similar/duplicate pull request regarding same issue

@hkirat Could you please review the PR when you have a moment? Thanks!

@ajeeshRS fix yarn lock

@ajeeshRS why only two upi/solana wallets?

@siinghd just to make it simple and manageable for now

@siinghd sounds good,thanks!


Build nightly end-to-end scenario test set to better find regressions

We need a system way to assure quality for each release tag.

Requirements:
end to end test. Which means we should cover all use cases a normal user may encounter.

support gearpump to yarn cluster.
read/write data from/to kafka.
Submit/kill/query all built-in examples from command line shell.
Submit/kill examples all built-in example from UI.
message loss. Machine crash, High availability test.
performance regression test.
able to run storm-benchmark over gearpump.
The conf is effective.
all commands under bin/ can run correctly.

Here is a proposal


Create wireframes for review process

The review process has been documented in the 0009_review_process ADR. It would be useful to have this visualised as a set of wireframes, to create a visual blueprint of how the process works, and what the various pages are going to look like. This should be stored in an appropriate place in the docs folder.
AC's:

[ ] The entire review process, as documented in the ADR, has been turned into clear wireframes and flow diagrams, illustrating the workflow from start to finish, with wireframe designs of how the pages etc will look. This is stored in an appropriate place in the docs folder (linked in a comment on this story)

I have updated the ADR for the review process - https://github.com/icipe-official/vectoratlas-software-code/blob/main/docs/architecture/ADRs/0009_review_process.md


Envbuilder does not run in a sysbox container

Envbuilder fails if it runs using the sysbox container runtime. This is unfortunate because sysbox is neccessary to run k3s or docker within a workspace.
The issue is described already in the kaniko project: https://github.com/GoogleContainerTools/kaniko/issues/2144 and the sysbox project: https://github.com/nestybox/sysbox/issues/564
There are also workarounds proposed (like unmounting the offending mountpoint or mounting something empty over it). As envbuilder uses kaniko internally, but the image lacks the userland for the workarounds I think, it should also implement the workaround for convenience.
Another option is to attach an empty volume from the outside to the container, but this is difficult to implement in a terraform manifest as the target of the mountpoint is dependend on the running kernel of the host - and the provisioner does not have this information available.

Fixed by https://github.com/coder/envbuilder/pull/183 and https://github.com/coder/envbuilder/pull/51


Simple page with a password field = Phishing Content???

Simple page like this:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body style="background:#161616">
<link<EMAIL_ADDRESS>rel="stylesheet" integrity="sha384-gH2yIJqKdNHPEq0n4Mqa/HGKIhSkIHeL5AyhkYV8i59U5AR6csBvApHHNl/vI1Bx" crossorigin="anonymous">
<script<EMAIL_ADDRESS>integrity="sha384-A3rJD856KowSb7dwlZdYEkO39Gagi7vIsF0jrRAoQmDKKtQBHUuLZ9AsSv4jD4Xa" crossorigin="anonymous"></script>
<input class="password h-100" type="password" placeholder="Your Password" id="password">
</body>
</html>

Uploaded to Pinata Gateway: https://gateway.pinata.cloud/ipfs/QmcPwXPe222TduXhTKcitNY3PrYxcYctLTQv4jfeTyW4Gp
If you only pass the mouse over the password field, the page is reloaded and it shows a page like this:
https://www.pinatapreventsphishing.com/
The same page, but using IPFS Gateway, is working as expected:
https://ipfs.io/ipfs/QmcPwXPe222TduXhTKcitNY3PrYxcYctLTQv4jfeTyW4Gp
Guys, what's the problem about a page asking a password in the web3? Is this always a phishing?

Hello @EscassoProtocol I will try it out this issue. then double check why is flagged as phishing


Properly format the wrong credentials warning

This is all there is right now:
      loginFailed =
Ouch! credentials not valid
;

🤷🏻♂

Issue solved.


Creation of New Definitions Adds new Elements to the Wrong Repo in MultiRepo Mode

When I create a new Defintion in a specific namespace, it is always saved to the workspace and not the correct repository.

The issue cannot be reproduced


modules: TF-M: memory layout from devicetree

My biggest frustration with Trusted-Firmware-M is its model of hardcoding its memory layout in {module}/platform/ext/target/{family}/board where it is very annoying to modify. The alternative is copying the board directory out to a git repository we control and modifying the values there, but that results in duplicated code everywhere. Furthermore, editing the flash_layout.h by hand is error prone, and doesn't really scale past a few boards.
It is hopefully obvious that having only a single TF-M memory layout for a part number is not workable in practice. Some boards may be a SoC + a LED (and therefore primary + secondary fits in onboard flash), while others may have LTE modems and WiFI co-processors hanging off the side and therefore need every byte of ROM for the application they can get. Even within a single board, different applications may desire a different memory split between secure and non-secure applications.
Nordic recognized this limitation and worked around it with the Partition Manager, which consumes a yaml file of the following form and generates a file that is injected into the TF-M flash_layout.h:
mcuboot:
    address: 0x0
    size: 0x7000
    region: flash_primary
mcuboot_pad:
    address: 0x7000
    size: 0x200
...

At some point in the past Nordic proposed integrating the Partition Manager into Zephyr but it didn't go ahead, presumably because of the duplication of information with Devicetree.
Speaking of Devicetree, it has mechanisms to store every piece of information required by TF-M, but because TF-M has been hardcoding everything there has been no motivation for pulling this information together into a usable state. Boards define slot0_partition, slot_0_ns_partition, etc, but they are ignored by TF-M. Boards define sram0_s and sram0_ns but again they are ignored by TF-M. The non-secure image uses (some) of these values for generating the non-secure image, but changing these values to anything other than the TF-M hardcoded values will result in unbootable images.
As Zephyr is obviously the superior project, this PR is an attempt to force our view of the world on TF-M, instead of the other way around :). All information required by TF-M is pulled together into a simple devicetree binding, which generally just points back out to flash partitions or memory regions. This binding is then processed by a python script to generate a header that the TF-M build system understands.
Input:
	tfm_config {
		compatible = "arm,trusted-firmware-m";
		sram = <&sram0>;
		sram-secure = <&sram0_s>;
		sram-nonsecure = <&sram0_ns>;
		spu-flash-region-size = <0x00004000>;
		spu-sram-region-size = <0x00002000>;

		onboard_flash {
			driver = "Driver_FLASH0";
			complete = <&flash0>;
			img-bl2 = <&boot_partition>;
			img-primary-secure = <&slot0_partition>;
			img-primary-nonsecure = <&slot0_ns_partition>;
			img-secondary-secure = <&slot1_partition>;
			img-secondary-nonsecure = <&slot1_ns_partition>;
			partition-ps = <&tfm_ps_partition>;
			partition-its = <&tfm_its_partition>;
			partition-otp = <&tfm_otp_partition>;
			partition-nonsecure-storage = <&storage_partition>;
		};
	};

Output:
/*
 * Generated by gen_tfm_defines.py
 *
 * DTS pickle file:
 *   /home/jordan/code/zephyr/build/zephyr/edt.pickle
 */

/* /soc/memory@20000000 */
#define SRAM_BASE_ADDRESS                        0x20000000
#define TOTAL_RAM_SIZE                           0x00080000 /* 512kB */

/* /reserved-memory/image_s@20000000 */
#define S_DATA_START                             0x20000000
#define S_DATA_SIZE                              0x00040000 /* 256kB */
#define S_DATA_LIMIT                             0x2003ffff
...

This initial proof-of-concept is only enabled for Nordic hardware, mostly because this solution depends on swapping out the partition folder which needs to happen where the TF-M platform is defined and only Nordic platforms are currently defined in tree (although most of the functionality refers back to the TF-M repo). As a result there are a few Nordic specific values in the headers and generated files, mostly related to the storage partition.
There is also some awkwardness around the flash drivers themselves, which TF-M refers to by names Driver_FLASH{N}, as TF-M has its own flash driver implementation that implement the CMSIS Flash API (for example).
This PR contains 4 examples for the nRF5340dk, showing builds with:

Standard TF-M memory layout, using this infrastructure
TF-M build with no BL2
TF-M build with the secondary images on external flash
TF-M build with CONFIG_TFM_MCUBOOT_IMAGE_NUMBER=1

Each have been tested to compile and run the basic application.

This is very interesting, would it be possible for you to use an521 as a generic (/non-vendor specific) target?

I had a look at doing this, the biggest obstacle is that the QEMU platforms are defined entirely in the TF-M repo, meaning I can't override the partition folder the same way I have with Nordic. I agree that an521 support would be ideal so that this is properly exercised in CI. This is an initial draft to gather feedback before spending time on rough edges.

Also, this PR contains changes to the partitions' sizes. Is this related to/required for the addition of the generator?

Some boards only have the PS, ITS and OTP partitions explicitly added where previously they were just holes in DT. The platforms where the images changed size it because the "empty" space was (incorrectly) filled by larger applications in #62199. Of course this had no actual effect because TFM ignores the actual layouts, but has to be reverted to make space for PS, ITS and OTP with this PR. I only added full support for the nRF5340dk because again, this is only a draft.

My biggest frustration with Trusted-Firmware-M is its model of hardcoding its memory layout in {module}/platform/ext/target/{family}/board where it is very annoying to modify. The alternative is copying the board directory out to a git repository we control and modifying the values there, but that results in duplicated code everywhere. Furthermore, editing the flash_layout.h by hand is error prone, and doesn't really scale past a few boards.

There is a whole lot more than just the flash partitions than are hardcoded in the TF-M board support, honestly I have no clue how this was intended to be used by SDKs or by the users who define their own boards.
TF-M adds board support for a few DKs, and then anything custom past that appears to be needed to be completely redone.
The nordic boards have been organized in a way where you can re-use the core parts of it, and then define the board specifics outside of the TF-M repository.
This is now done in both zephyr and NCS. Note that these exists completely separately, and any changes to the zephyr board support would be discarded and redone again in NCS.
Because of that nordic never did what this PR does because it would be a duplicated effort, and the zephyr variant is not what is recommended to use. Here is only the bare minimum to add generic board support for all nordic boards defined in zephyr.
What this PR suggest has already been done in NCS, except that it takes the defines from the output of the partition manager definitions, instead of the devicetree definitions.
The same approach can be done by just including devictree instead of partition_manager and replacing the TF-M provided hardcoded partition headers with the zephyr specific ones.
I don't see why the script is needed to generate it though, is there a specific reason for scripting it?
In the way the nordic boards are included you can use both devictree and autoconf directly in the files defined there.
flash_layout.h:
#ifndef __FLASH_LAYOUT_H__
#define __FLASH_LAYOUT_H__

#include <devicetree.h>
#include <autoconf.h>

#define S_DATA_START                  FIXED_PARTITION_OFFSET(sram0_s)
#define S_DATA_SIZE                   FIXED_PARTITION_SIZE(sram0_s0)

/*...*/

#endif

For comparison, this is how it is taken from partition manager defines:
https://github.com/nrfconnect/sdk-nrf/blob/main/modules/trusted-firmware-m/tfm_boards/partition/
An example on devicetree already being used:
https://github.com/zephyrproject-rtos/zephyr/blob/main/modules/trusted-firmware-m/nordic/include/RTE_Device.h
Which takes the UART pins from devicetree for the TF-M logging.

This is very interesting, would it be possible for you to use an521 as a generic (/non-vendor specific) target?

Probably not without doing the same changes to the board layout that the nordic boards have done.
Otherwise it is very hard to replace the files needed in the build.

There is a whole lot more than just the flash partitions than are hardcoded in the TF-M board support, honestly I have no clue how this was intended to be used by SDKs or by the users who define their own boards.

Agreed, it is a general mess, but it is the mess we have.

What this PR suggest has already been done in NCS, except that it takes the defines from the output of the partition manager definitions, instead of the devicetree definitions.

Correct, the NCS implementation was inspiration in the sense that it proved that it is possible to inject some sanity.

I don't see why the script is needed to generate it though, is there a specific reason for scripting it?

Some defines could certainly come directly from the devicetree macros, the challenge is with the potential multiple flash nodes, as shown in the tfm_ext_secondary sample. As far as I know there is no neat way to generate defines for those intermediate nodes. Although that is more a problem for the drivers that consume the values than the system as a whole. The same thing applies to the extra-defines property, which is a hack that in an ideal world wouldn't need to exist.
I could make the argument that since this is going into the build system for an external project, there is value in the defines all existing in a common file without 4 layers of indirection, just for the sake of clarity.

An example on devicetree already being used:
Which takes the UART pins from devicetree for the TF-M logging.

Yes, but those values are not going into the linker scripts, and require modifications to TF-M driver code to enable that. It's probably the right way to go long term, but I don't have the time to update all the relevant drivers.

I don't see why the script is needed to generate it though, is there a specific reason for scripting it?

It's also not quite as simple as throwing in #include <zephyr/devicetree.h> and calling it a day, the flash_layout.h file is included by a large portion of the TF-M build system, including the linker, which doesn't work out of the box. I played around for a while and couldn't get the simplest use case to compile:
#include <zephyr/autoconf.h>
#undef ARRAY_SIZE
#include <zephyr/devicetree.h>

#define TFM_CONFIG DT_COMPAT_GET_ANY_STATUS_OKAY(arm_trusted_firmware_m)

#define SPU_FLASH_REGION_SIZE DT_PROP(TFM_CONFIG, spu_flash_region_size)
#define SPU_SRAM_REGION_SIZE  DT_PROP(TFM_CONFIG, spu_sram_region_size)

I don't see why the script is needed to generate it though, is there a specific reason for scripting it?

It's also not quite as simple as throwing in #include <zephyr/devicetree.h> and calling it a day, the flash_layout.h file is included by a large portion of the TF-M build system, including the linker, which doesn't work out of the box. I played around for a while and couldn't get the simplest use case to compile:

Yeah, that might ring a bell actually, I think I may have tried to do this before, and when seeing those errors just aborted.
So creating a clean file from a script may be required then.
I'm just thinking a universal script for all boards may be hard to get right, since I think there is a lot of variation between the different TF-M supported platforms and their header files.
Depends what is your ambition for this? Adding support for nordic is one thing, as that one has been adapted for this approach.
Getting the rest of the boards supported probably needs involvment to the TF-M project, and I think their co-operation. At least from the platform maintainers that you want to include.

I'm just thinking a universal script for all boards may be hard to get right, since I think there is a lot of variation between the different TF-M supported platforms and their header files.

At a certain level its not hard at all, because TF-M has its guide of the defines that need to be present, and they are all pretty trivially generated from devicetree flash partitions or reserved memory nodes.
Configuring the various platform specific extensions (The QSPI flash driver in this example) can be worked around through the extra-defines escape hatch. Over time I would like to see any need for that removed, but I don't think it's the end of the world if it is present initially. It's not feasible to solve this whole problem in one PR.

Depends what is your ambition for this? Adding support for nordic is one thing, as that one has been adapted for this approach.
Getting the rest of the boards supported probably needs involvment to the TF-M project, and I think their co-operation. At least from the platform maintainers that you want to include.

I would like to see the situation improve for all the TF-M platforms supported in-tree, but I have nowhere near enough time to make that a reality. Whether it is acceptable to merge some initial version that only supports Nordic with a clear path for other vendors to transition would probably be a question for the TSC.
The lowest level of effort required for the TF-M repo would be to provide a define such as PLATFORM_PARTITION_FOLDER_OVERRIDE that would allow us to inject our own generated headers instead of the hardcoded ones. Everything else could be done through the extra-defines escape hatch at the board layer. Reducing extra-defines usage would require driver changes in the TF-M tree.

Depends what is your ambition for this?

I'm not throwing this into the wind and letting someone else solve all the problems, but I am hoping that some of the SoC vendors see value in this and can help contribute towards a solution that works for everyone :)

Depends what is your ambition for this?

I'm not throwing this into the wind and letting someone else solve all the problems, but I am hoping that some of the SoC vendors see value in this and can help contribute towards a solution that works for everyone :)

Hi, we appreciate this proposal. For better visibility for other platform vendors, I'd recommend to have a discussion on the TF-M mailing list<EMAIL_ADDRESS>and port this on the TF-M's Gerrit. If this patch stack can be reviewed directly upstream, maintainers can get a better understanding of what is missing and still left to do. Thanks, Antonio

Depends what is your ambition for this?

I'm not throwing this into the wind and letting someone else solve all the problems, but I am hoping that some of the SoC vendors see value in this and can help contribute towards a solution that works for everyone :)

Hi, we appreciate this proposal. For better visibility for other platform vendors, I'd recommend to have a discussion on the TF-M mailing list<EMAIL_ADDRESS>and port this on the TF-M's Gerrit. If this patch stack can be reviewed directly upstream, maintainers can get a better understanding of what is missing and still left to do. Thanks, Antonio

Hi Antonio, who is "we" in this context? The PR as it stands is independent of the TF-M repository and extremely Zephyr-centric.  I'm not sure what discussion can take place on the TF-M mailing list that can't occur here.
I don't believe porting this to TF-M is even possible, unless TF-M transitions to a devicetree description itself, as the whole point of this PR is a devicetree to TF-M config generator.

Depends what is your ambition for this?

I'm not throwing this into the wind and letting someone else solve all the problems, but I am hoping that some of the SoC vendors see value in this and can help contribute towards a solution that works for everyone :)

Hi, we appreciate this proposal. For better visibility for other platform vendors, I'd recommend to have a discussion on the TF-M mailing list<EMAIL_ADDRESS>and port this on the TF-M's Gerrit. If this patch stack can be reviewed directly upstream, maintainers can get a better understanding of what is missing and still left to do. Thanks, Antonio

Hi Antonio, who is "we" in this context? The PR as it stands is independent of the TF-M repository and extremely Zephyr-centric. I'm not sure what discussion can take place on the TF-M mailing list that can't occur here.
I don't believe porting this to TF-M is even possible, unless TF-M transitions to a devicetree description itself, as the whole point of this PR is a devicetree to TF-M config generator.

Who: The TF-M project :) I am not a Zephyr expert and looking closer now to the files changed in this particular PR, I see it does not change TF-M source, as I originally thought. The enthusiasm came from the fact that we considered in the past having devicetree based generator for header defines but never implemented it due to bandwidth. Well, I guess we will just keep an eye on this discussion. Thanks!

The enthusiasm came from the fact that we considered in the past having devicetree based generator for header defines but never implemented it due to bandwidth. Well, I guess we will just keep an eye on this discussion. Thanks!

It's nice to hear that the TF-M project is open to improvements (or is at least listening) to the challenges that the current model imposes. Honestly there are a few simple things that could be done to improve the situation and make solutions like this a lot easier for external projects.
As I think I mentioned somewhere above, having the option to override the partition directory (holder of flash_layout.h and region_defs.h) from the command line would go a long way towards supporting these external memory layouts. This PR is only possible because Nordic added a core platform folder into Zephyr, instead of using the TF-M platform directly.

I see it does not change TF-M source, as I originally thought.

@adeaarm That is because the change have already been done earlier, it has always been maintained in this way by nordic to support this use-case. Other vendors most likely will have to do similar changes.
The strategy allows certain files in the build to be replaced, by code that is aligned with the zephyr project, and the core files exists in zephyr, as you can see.
That is because TF-M project does not have devicetree support, so they have to be different solutions.


helm secrets with age

Fixes #293
Tasks:

[x] Updated design documents in docs/design directory or not applicable
[x] Updated user-facing documentation in docs directory or not applicable
[x] Ran tests (e.g. make test) or not applicable
[x] Updated changelog or not applicable

first commit with changes on the Dockerfile.helm file -> helm-secrets to latest version, add sops and age explicitly
missing: docs update (followup from https://github.com/opendevstack/ods-pipeline/pull/292), change wherever pgp is used to age (secrets in tests, etc)

Yep, that looks about right. Keep in mind that this commit should also update https://github.com/opendevstack/ods-pipeline/blob/master/docs/design/software-design-specification.adoc. That document tracks what gets installed and in which version.

@michaelsauter from what I have understood, until now we had kinda not mandatory having the helm-private-key-secret in place in the tests and so on, but it looks that anyhow it is required by design, or am I wrong? Do we make it required so the tests do not fail in the case it is not existing (by making it always to exist)? or we should keep it being not mandatory?

@gerardcl See https://github.com/opendevstack/ods-pipeline/blob/master/test/tasks/ods-deploy-helm_test.go#L62. That sets up the private key. I think you need to exchange that for age.

@michaelsauter I thought about that but was not sure, so in this case I understand instead of importing via executing gpg import I will need to make it available in the context env when executing helm command. ok! let's see!

@renedupont  I updated user docs from your update (added multiple recipients note) and updated related part on admin installation too 👍

@michaelsauter ready for review 👍


[BC Idea]: Enhancing Shopify Connector for Accurate Price Synchronization with Business Central based on Customer

BC Idea Link
https://experience.dynamics.com/ideas/idea/?ideaid=34dcafc6-5c57-ef11-b4ac-6045bd8476a6
Description
Currently, there is a need to synchronize prices between Business Central and Shopify, where prices are determined by the lowest pricing logic applied in Business Central. This involves complex pricing scenarios like customer-specific discounts, item discount groups, and other discount mechanisms. However, the existing Shopify Connector does not account for these complexities, leading to potential discrepancies between the prices in Business Central and those displayed in Shopify.
I will provide the implementation for this BC Idea

[X] I will provide the implementation for this BC Idea

@AndreiPanko, could you triage this idea?


Allow adding custom buttons

Would be nice if we could augment the buttons with custom links (e.g. to code coverage, or deploy preview, etc)

Hi @hammadj, I have added your request to version 3.1.2. Thanks for the suggestion.


"Westchester County" label showing up in the Bronx

Reported via email:  An errant label for "Westchester County" is showing up on Bronx 11.

Need to investigate whether it's a point feature or a labeled polygon (I think it's the former) in the Mapbox Vector Tiles.  If the point is misplaced, may need to make the correction in OSM.

In the ID editor, I see a point feature in this location labeled "Westchester" (a neighborhood in the Bronx).
Either the point was incorrectly labeled as "Westchester County" previously in OSM, and we are looking at stale data, or somewhere in the pipeline Mapbox is appending "county" in error.

This twitter user noticed that the wikipedia node for Westchester was pointing to the wikidata entry for westchester county.
https://twitter.com/kgjenkins/status/928752201874501633
I just edited openstreetmap and deleted the erroneous reference.  Hopefully we should see the label change soon. https://www.openstreetmap.org/changeset/53656143

I checked this morning, and the data has been updated in Mapbox's vector tile service!  The label now correctly reads "Westchester".


https://github.com/samdark/sitemap/issues/57

https://github.com/samdark/sitemap/issues/57

Going to remove validation overall soon.


Minor optimizations / fixes

@lettergram please reference the issue regarding this PR so we can close it.

THe commit message links to it

Interesting, didn't see that.


Issue with Experiment.amplitude()

Try this:
import refl1d
from refl1d.names import *
import numpy as np

q = np.logspace(np.log10(0.005), np.log10(0.2), num=180)
dq =  0.025 * q
zeros = np.zeros(len(q))

probe = QProbe(q, dq, data=(zeros, zeros))

sample = Slab(material=SLD(name='back', rho=2.07), interface=5) | Slab(material=SLD(name='front', rho=0.0))

expt = Experiment(probe=probe, sample=sample)

_, r = expt.reflectivity()
_, a = expt.amplitude()

and obtain this:
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-bf7efa6451a0> in <module>
     14
     15 _, r = expt.reflectivity()
---> 16 _, a = expt.amplitude()

~/miniconda3/envs/playground/lib/python3.7/site-packages/refl1d/experiment.py in amplitude(self, resolution)
    474             r_real = self.probe.apply_beam(calc_q, calc_r.real, resolution=resolution)
    475             r_imag = self.probe.apply_beam(calc_q, calc_r.imag, resolution=resolution)
--> 476             r = r_real + 1j*r_imag
    477             self._cache[key] = self.probe.Q, r
    478         return self._cache[key]

TypeError: can't multiply sequence by non-int of type 'complex'

Okay, fixed and available soon.
Note that Res(|r|^2) != |Res(r)|^2, which is why I have resolution=False as the default for the amplitude calculation.
Expanding the resolution convolution, G*|r|² = ∫G(q'-q) |r(q)|² dq  != |∫G(q'-q)r(q)dq|² = |G*r|², so kind of obvious even if r were purely real.
I think you will need to deconvolute your data prior to recovering r. I don't have any code for doing that.
Here's a script which shows what happens when resolution is applied to the amplitude. Run it using refl1d -p model.py:
import refl1d
from refl1d.names import *
import numpy as np

sample = (
    Slab(material=SLD(name='back', rho=2.07), interface=5)
    | Slab(material=SLD(name='film', rho=5.6), thickness=800, interface=5)
    | Slab(material=SLD(name='front', rho=0.0))
    )

q = np.linspace(0.005, 0.2, num=500)
dq = 0.025*q
probe = QProbe(q, dq)
expt = Experiment(probe=probe, sample=sample)

q, r_wt = expt.reflectivity(resolution=True)
q, a_wt = expt.amplitude(resolution=True)
q, r_wo = expt.reflectivity(resolution=False)
q, a_wo = expt.amplitude(resolution=False)

import matplotlib.pyplot as plt
plt.semilogy(q, r_wt, label='G*R')
plt.semilogy(q, abs(a_wt)**2, label='|G*r|^2')
plt.semilogy(q, abs(a_wo)**2, label='|r|^2')
plt.legend()

plt.show()

@pkienzle Thanks for pointing this out. I haven't looked into the resolution yet. This becomes interesting when trying to extract the amplitude for phase-sensitive measurements (I'v recently independently validated your direfl code as I was looking into these types of measurements).


CDN link on language page is broken, version is missing

This is the output:
<script src="//cdnjs.cloudflare.com/ajax/libs/numbro//min/languages.min.js"></script>

Here is the source code for it: https://github.com/foretagsplatsen/numbro/commit/6487f3a73826d3ababaa412fbd5da8b1143901c6#diff-1c9501c42c99607777a290d798f3b4e0R19

👍

done, thanks


Update ssm to 2.25.49 in scala-steward-dependencies

About this PR
📦 Updates software.amazon.awssdk:ssm from 2.23.21 to 2.25.49
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk", artifactId = "ssm" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "software.amazon.awssdk", artifactId = "ssm" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #48.


Flake: added IDTime; chasing intermitted bug in tests failures

Coverage: 82.642% (+0.003%) from 82.639% when pulling e77c4e79bdf68141d8e5d8f7daa1045633a451e9 on dissoupov into ede0d53d9f2cde83ea71cf3ad567680868c5b359 on main.


New version: DoubleFloats v1.1.22

Registering package: DoubleFloats
Repository: https://github.com/JuliaMath/DoubleFloats.jl
Created by: @JeffreySarnoff
Version: v1.1.22
Commit: ca0ac0cc9f202ffa8838b20d212ba1dd2eaabfb0
Reviewed by: @JeffreySarnoff
Reference: https://github.com/JuliaMath/DoubleFloats.jl/commit/ca0ac0cc9f202ffa8838b20d212ba1dd2eaabfb0#commitcomment-51574523

@admin Please wait for a second @admin message before merging .. other adjustments are required.


[Bug] Commit Graph: pagination sometimes drop last

repo wich has this problem: https://gitea.com/gitnex/GitNex/graph
"Last" go to https://gitea.com/gitnex/GitNex/graph?page=3
but in realety it is https://gitea.com/gitnex/GitNex/graph?page=4
so affected versions are: current, 1.10?

There is 249 commits.
gitea.com shows 100 commit in each page
Can not be 4 pages.
You can see older commits if it did not start from new repository

@jaqra you mean gitea takes the number of commits on default branch to calculate the pagesbwichvare needed?

Here is the code to get commit count
https://github.com/go-gitea/gitea/blob/cf2fc22b1cacc6621a1c91af118490510d366f76/routers/repo/commit.go#L49

notevpagination was addet at #8360

@jaqra I don't look deep into this particular code jet ...
this is a note wich I/someone can pic up to fix :)
but you got the problem or shuld i describe it better?

@6543 i did


chore: Update links to solutions on the project readme

The current links on the readme aren't resolving to the desired solutions page, returning a 404 page not found.
SOLUTION:
Update the current links to reflect the new project structure.

Let me know if this is something you would want assistance with.

Thank you for bringing that to my attention. I made a few changes that may have caused the issue. Some references may not be available because this is an ongoing project. If you would like to contribute to some topics, please feel free to open a pull request for the same

Welcome, most of the links have been resolved, I'll close this as resolved
Cheers.


Tab completion doesn't recognize line breaks in usage strings

The follwing docstring is perfectly parsed by docopt:
Usage:
  example.py ( cmd1 | cmd2 |
     cmd3 )

But docopt_wortlist has problems in bash shell
confus@confusion:~$ example.py Expected pattern but reached end of usage pattern.

Seems like a bug in the implementation proper. I wonder if that type of syntax should even be allowed by Docopt.

It is parsed correctly and cmd3 is recognized as a command. Multiline usage strings are allowed too.
See:
https://github.com/docopt/docopt/issues/130
Btw. depending on whether the | character is before or after the linebreak I get another error message:
confus@confusion:~$ example.py Unclosed group. Expected ')'.


Lineplot: handle ordinal x variables

Fixes #963

Binning is completely disabled (even the binning on/off button) for these variables.

Github's convert to draft button is broken, but it looks like more work is needed. The order of ordinal variables will need correcting (using the xVariable.vocabulary)

There aren't many ordinal variables to test. Here's one that works!
India ICEMR Fever Surveillance

Also sorted a new/related issue with error bars breaking for date y-vars.
Ready for review now (but no need to push out before the demos)


How to set Z index for panel

I am working with navigation bar and sliding panel in same activity. problem is when navigation bar is open my sliding panel is on top of that, i want to show sliding panel below to navigation bar.
I could not find any kind of property to set same. please help.

Simply place the sliding layout as the first child in your main layout and the navigation toolbar as the second.

can u give me the example?


Fix scan broadcast issue

broadcast variables were re-computed during init in each iterations causing excessive slow down.

Codecov Report

Merging #474 into master will decrease coverage by 0.22%.
The diff coverage is 86.95%.

@@            Coverage Diff             @@
##           master     #474      +/-   ##
==========================================
- Coverage   74.53%   74.31%   -0.23%
==========================================
  Files          54       54
  Lines        3955     3971      +16
==========================================
+ Hits         2948     2951       +3
- Misses       1007     1020      +13

Impacted Files
Coverage Δ

flax/linen/transforms.py
93.81% <ø> (-0.07%)
:arrow_down:

flax/core/unified_transforms.py
77.61% <68.42%> (-17.71%)
:arrow_down:

flax/core/lift.py
76.19% <100.00%> (+1.03%)
:arrow_up:

flax/linen/__init__.py
100.00% <100.00%> (ø)

flax/core/scope.py
83.57% <0.00%> (-0.49%)
:arrow_down:

Continue to review full report at Codecov.

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


Remove unused source set

Pretty sure this is a remnant from an older version of this project. The current test structure looks very different from 08502ad358751cd56304c9e7a4b2264db3ed65fe when this source set was added.

Current coverage is 81.42%

Merging #128 into master will not affect coverage as of da599f8

@@            master    #128   diff @@
======================================
  Files           37      37
  Stmts          549     549
  Branches        47      47
  Methods          0       0
======================================
  Hit            447     447
  Partial         29      29
  Missed          73      73

Review entire Coverage Diff as of da599f8

Powered by Codecov. Updated on successful CI builds.

Well, yeah, looks like we can remove it now.
@vanniktech PTAL too

:+1:

Thanks, @Plastix!


Sometimes embedded terminal crashes

Type: Bug
Sometimes terminal crashes... after long text output mixed with ctrl-c requests.
VS Code version: Code 1.75.1 (441438abd1ac652551dbe4d408dfcec8a499b8bf, 2023-02-08T21:32:34.589Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No

It looks like your report is missing some important information, See this wiki page for more info on how to report actionable terminal issues.
/label info-needed terminal

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


shuffle, repeat, do no disturb toggle with area

Describe the bug
After putting the various Echo devices into the correct rooms, announcements stopped, but only when the lights were turned on.  This is because the device "do not disturb" option is showing up as a switch device. Same for shuffle and repeat.
To Reproduce
Steps to reproduce the behavior:
0. Give your echo device a non-null area

Go to any area panel with an echo device in it
Toggle the area room switch
See the echo option switches toggle along with the lights

Expected behavior
Area-wide toggles should not adjust echo device options
System details

Home-assistant (version): 0.113.2
Hassio (Yes/No): No
alexa_media  (version from const.py or HA startup): v2.10.1
alexapy (version from pip show alexapy or HA startup):1.12.1

This is likely a HA issue where it needs to provide an option so that area level on and off only impact lights or some other defined class. Short of removing the switches, there's nothing we can do no the component level to change this behavior in HA.

Closing as this is an HA issue. You can also remove the device from an area since it doesn't actually do anything for the component. We don't magically link to other devices in HA just because you put it in the same area.


Review: Running EMG Example

Using the instructions on the repository I could not view the figures without first importing pyplot from matplotlib. Not sure if this was only a problem for me. System/Anaconda spec : Python 3.6.10, Windows 10 Enterprise, 64-bit

Hello @BKillen05 and thanks for the issue.
pyomeca's documentation uses Jupyter notebooks to show code and instructions.
If you use the server we provide here, the figures appear correctly.
This process is quite standard and other libraries use it in their documentation: scikit-learn (42k stars on GitHub), pandas (26k stars on GitHub) or xarray (1.7k stars on GitHub).
Under the hood, pyomeca uses matplotlib.
To show a figure in a non notebook environment, the user just has to add plt.show().

Hello @romainmartinez
Thank you for your reply.  I was running the example on a standalone anaconda environment not the Jupyter notebook you indicated. This is likely the problem as you say. It's possible I missed this but it is worth double checking this is documented


HandyControls Change ThemeManager.ApplicationTheme not effects NotifyIcon context menu

Reproduce

Start app, then click the notify icon to show context menu.
Change theme at runtime ThemeManager.Current.ApplicationTheme = XXX.
Click the notify icon to show context menu, its theme not change.

Environment (please complete the following information):

.net: 5
IDE vs2019
Version HandyControls 3.1.1

Additional context
Add any other context about the problem here.

Thank you @GF-Huang
I tested and there is no problem in ContextContent mode, but there is a problem in ContextMenu Mode.
I will try to solve the problem

BTW, why not open the issues or discussions feature of HandyControls repository?

@GF-Huang  I opened it 12 days ago😁
https://github.com/ghost1372/HandyControls/issues

@GF-Huang i fixed this bug😁
I released a new version on Nuget yesterday, but unfortunately I fixed this bug today, So this fix will be available in the next version, which will be at least a month away
Therefore, you can use the following solution to solve the problem until the next version is released
set a name for ContextMenu:
<hc:NotifyIcon.ContextMenu>
    <ContextMenu Name="context">

    </ContextMenu>
</hc:NotifyIcon.ContextMenu>

Create ActualApplicationThemeChanged event:
public MainWindow()
        {
            InitializeComponent();
            ThemeManager.Current.ActualApplicationThemeChanged += ActualApplicationThemeChanged;
        }

and finally set the context theme:
private void ActualApplicationThemeChanged(ThemeManager sender, object args)
        {
            if (sender.ApplicationTheme == ApplicationTheme.Light)
            {
                ThemeManager.SetRequestedTheme(context, ElementTheme.Light);
            }
            else
            {
                ThemeManager.SetRequestedTheme(context, ElementTheme.Dark);
            }
        }

Great! Thank you!


Howto: display emoji

how to display the selected emoji into div?

add (emojiClick)="addEmoji($event)" event to your html binding.
and then in your add emoji function.
(HTMLInputElement).value += event.emoji.native
I think it's already listed in the README.md file

Sorry for bothering, if use emoji native like 😍,
it will show up accordingly to the platform, like iphone showing apple version.
How to apply theme to it, let say if i want to change to twitter version, what should i do?
one more question, is it possible to convert html into
<ngx-emoji=':smiley" size="16"> by regex
and display it using [innerHtml] or sth like that .
Cheers

@wilson0506

innerHTML doesn't render html components....

should be easier with the new function added to emoji service https://github.com/TypeCtrl/ngx-emoji-mart#display-emoji-as-custom-element
closing in favor of #89


DJNZ preserves flags

For the following code, the optimiser suggests:  "replace ld a, c; bit 7, b with ld a, c (2 bytes, 8 t-states saved)"
As DJNZ does not affect the Z flag/preserves flags, the suggestion is not ideal.
    LD      A,C             ; fetch 'mic on and yellow' which is
                            ; held permanently in C.
    BIT     7,B             ; set the zero flag. B holds $3E.

    ;   The entry point to save 1 entire bit. For first bit B holds $3B(*).
    ;   Carry is set if saved bit is 1. zero is reset NZ on entry.

    SA_BIT_1:
    DJNZ    SA_BIT_1        ; self loop for delay to SA-BIT-1

Oh, thanks for letting me know of this! DJNZ is already defined as not affecting the Z flag, but it seems there is a bug in detecting its use afterwards! I'm creating a test case for this and will try to post a fix asap, and update this issue. Thanks again!

But wait, wait. I was mistaken before, I have actually not been able to reproduce this bug. Of course if you give this piece of code as is, it will remove both "ld a,c" and "bit 7,b", since nothing uses neither a not z after the djnz. But in my experiments whatever I insert afterwards that uses "z" prevents the "bit 7,b" optimization. Could you share the lines of code after the DJNZ that use the Z flag to see if I can reproduce the issue?

Also, just to confirm, this is the with the search-based optimizer, right? "-so"

Hi,
The command used is:
java -jar mdl.jar Rui/my/QtSpecem/Z80tests/turboloader.asm  -dialect pasmo
-asm t.asm -so -cpu z80
File is at
https://github.com/ruyrybeyro/QtSpecem/blob/master/Z80tests/turboloader.asm
Output is:
INFO: Search-based optimization in
Rui/my/QtSpecem/Z80tests/turboloader.asm#177: replace dec de; ex af, af'
with dec de (1 bytes, 4 t-states saved)
INFO: Search-based optimization in
Rui/my/QtSpecem/Z80tests/turboloader.asm#312: replace ex af, af'; inc de
with inc de (1 bytes, 4 t-states saved)
INFO: Search-based optimization in
Rui/my/QtSpecem/Z80tests/turboloader.asm#413: replace ld a, c; bit 7, b
with ld a, c (2 bytes, 8 t-states saved)
The code bellow, Z ends up being used at SA8
SA_BIT_2:
LD A,C ; fetch 'mic on and yellow' which is
; held permanently in C.
BIT 7,B ; set the zero flag. B holds $3E.
; The entry point to save 1 entire bit. For first bit B holds $3B().
; Carry is set if saved bit is 1. zero is reset NZ on entry.
SA_BIT_1:
DJNZ SA_BIT_1 ; self loop for delay to SA-BIT-1
JR NC,SA_OUT ; forward to SA-OUT if bit is 0.
; but if bit is 1 then the mic state is held for longer.
SA7: LD B,$21 ; set timed delay. (66 decimal)
; Non-turbo: $42
; However if saving a '1' then add 855 T states.
SA_SET:
DJNZ SA_SET ; self loop to SA-SET
; (roughly an extra 6613 clock cycles)
SA_OUT:
OUT ($FE),A ; blue and mic on OR yellow and mic off.
SA8: LD B,$1F ; set up delay non-turbo: $3E
JR NZ,SA_BIT_2 ; back to SA-BIT-2 if zero reset NZ (first pass)
On Sat, 24 Sept 2022 at 23:54, Santi Ontañón Villar <
@.***> wrote:

Also, just to confirm, this is the with the search-based optimizer, right?
"-so"
—
Reply to this email directly, view it on GitHub
https://github.com/santiontanon/mdlz80optimizer/issues/44#issuecomment-1257078592,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPDBP57QHOLAVVWCMJK7H3V76BB7ANCNFSM6AAAAAAQSUHQUM
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Regards,
--
Rui Ribeiro
https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

Ah! Thanks!! That was very useful, and I found the bug! The problem was that I incorrectly had set that the "out(n),a" instruction overwrote some flags (probably copy/paste error). Once that was corrected, MDL does not produce that optimization any more. I just pushed a commit that fixes it, and this fix will be in the next release.
You can always compile from sources, but I have a precompiled version with this change here: https://braingames.santiontanon.dev/uploads/tmp/mdl.jar
I'll close this issue, but if it still produces strange behavior, by all means feel free to reopen, thanks again! :D


[Feature] Implementing Duplicate File Recovery System

Currently, when duplicate files are detected and deleted, they are permanently removed from the user's system. Users may want to recover mistakenly deleted files, but there is no existing mechanism for this recovery, leading to data loss.
The solution I am considering for the TwinTrim application is to implement a duplicate file recovery system that moves deleted files to a temporary "bin" folder, allowing users to restore them within 30 days.
Additionally, implementing an "Undo" feature after deletion could be a good choice; however, one drawback is that it may not be practical for users who want to delete multiple duplicates at once.
I want to work on this issue and Implementing this feature would greatly enhance the usability and safety of the TwinTrim application

Add Fuzzy Matching Feature to Enhance Duplicate Detection
I would like to propose a new feature to enhance the duplicate detection capabilities of TwinTrim by introducing fuzzy matching technique. Currently, the tool relies on strict hashing to identify duplicate files, which works well for exact duplicates. However, many users might encounter near-duplicate files—files that are not identical but share high content similarity (e.g., different versions of documents, edited images).
The fuzzy matching feature would:

Use similarity metrics (such as Jaccard index or Levenshtein distance) to detect files with slight differences.
Help identify near-duplicates, reducing redundancy and improving storage efficiency.
Allow users to set a similarity threshold to control the sensitivity of the fuzzy matching.

I have already implemented an initial version of this feature by creating a new fuzzy.py file. This includes a method find_fuzzy_duplicates that uses fuzzy matching to detect near-duplicates.

This is a CLI based python package, not an app.

This is a python package, so if you can somehow explain an approach where the deleted fil


Fix Integration tests for Problem Index functionality

Fix integration tests for Problem Index page.

@evulins

where now we should component inputWithTags?
What do you mean? Where should we test it? :)

What I meant is that I wrote two tests in the previous test file for the pseudo inputWithTags component.  And because of our mechanism structure they didn't work properly. Right now they are missing :D And I wonder if it's on purpose and if yes should we test it somewhere else?

@evulins oh, sure, I just forgot, I will paste them here, as because of the mechanics the also belong here. :)

👌 Nice!


Background: Deprecation of AWS Lambda support

In the last months we collected experience in the usage of AWS Lambda for the execution of untrusted code in the context of coding exercises. We could collect several advantages of Serverless Functions and our AWS implementation against our current Nomad solution, like its...

Massive scalability! From no costs in the idle state to stable responding in peak loads. #148
Presumably better energy efficiency.

Also we could find several disadvantages:

Language-specific handler code of the Serverless function.
AWS environment-reuse. Multiple invocations of the function share the same environment / microVM. For all invocation the tmp-directory is read and writable.
Unprivileged. The AWS Lambda function handler are executed non privileged. Therefore we can not use the concept of different users to hide Environment-Variables or use the file system permissions to secure files. Even the AWS Lambda Container Images are manipulated to only contain AWS-specified users and execute unprivileged. (PoC: 47dbeba)

These disadvantages result in our requirement for isolation of the user code not being met. We were not able to resolve this in a secure and maintainable way.
The advantages of serverless functions still appear attractive to us. In the future we will try to find another implementation that does not contain these structural disadvantages. To resolve the complexity of language-specific function handler we may shift our focus to serverless container.

We checked the options in AWS again and, unfortunately, cannot identify a suitable mechanism to address the aforementioned disadvantages. As there are also no new disadvantages we discovered, we're closing this issue and will keep it to document our decision and analysis.