fc.yahoo.com on port 443 (https) is not reachable

Describe bug
I had used this library some time ago and everything was fine ,I take it up again today and it doesn't work. What must have changed ? did they put a token ? what are these crumbs ? nothing is documented , search and search but nothing to do. So ,like in the good old days ,I edited the file data.py line 163 and changed fc.yahaoo.com with url='https://finance.yahoo.com/quote/AMD',.
Now it works.
Simple code that reproduces your problem
https://fc.yahoo.com/ on browser
Debug log
DEBUG    Entering download()
DEBUG     Disabling multithreading because DEBUG logging enabled
DEBUG     Entering history()
DEBUG      Entering _fetch_ticker_tz()
DEBUG       Entering get()
DEBUG        url=https://query2.finance.yahoo.com/v8/finance/chart/ACN
DEBUG        params=frozendict.frozendict({'range': '1d', 'interval': '1d'})
DEBUG        Entering _get_cookie_and_crumb()
DEBUG         cookie_mode = 'basic'
DEBUG         Entering _get_cookie_and_crumb_basic()
ERROR       Failed to get ticker 'ACN' reason: HTTPSConnectionPool(host='fc.yahoo.com', port=443): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fb0d6219a10>: Failed to establish a new connection: [Errno 111] Connection refused'))
Bad data proof
No response
yfinance version
0.2.38
Python version
No response
Operating system
No response

Check that the domain isn't blocked by a DNS blocker like PiHole.

Also had this issue, editing the file works
To put the pihole discussion to rest I tried with both my wifi and carrier, same result.
Perhaps the fc domain is not working in some parts of the world?
I am in sweden for example.

In my case it turned out to be related to unifi Ad Blocking. Disabling this feature does the trick in this case.

Thank you for writing that, @smiron ! That fixed it for me.

Closing this issue won't make it disappear. It will remain here (with all its comments), just its state will transition.

I’m closing this issue as I understand that it will remain accessible for others to find. Thank you for the discussion and clarification!

Ideally YF would detect that fc.yahoo.com is blocked and handle gracefully (nice message), not blow up.

I agree with @ValueRaider that that would be ideal, but it might not be technically possible to tell if it is blocked or just lost internet connectivity. The quick and dirty workaround that just popped into my head would be to ping Google should connectivity to fc.yahoo.com fail and, if that worked, suggest to the user that it fc.yahoo.com is blocked...but I am not sure how realistic that implementation might be.

I don't have fc.yahoo.com blocked, yet I can't resolve the name. What am I doing wrong? :)

It seems to me, that something else is at play here. I've encountered the same problem as OP and editing data.py to point to finance.yahoo.com instead of fc.yahoo.com fixed the issue for me too. However, I can ping fc.yahoo.com just fine. I've also tested several (non-blocking) DNS services and stopping firewalld with the same results.


basic_publish mixes up immediate and mandatory

Hello !
I think I found a small bug while reviewing this crate.
In channel.basic_publish we can read:
inner.call_nowait(AmqpBasic::Publish(AmqpPublish {
            ticket: 0,
            exchange: exchange.into(),
            routing_key: publish.routing_key,
            mandatory: publish.mandatory,
            immediate: publish.mandatory,
        }))?;

which should probably be
inner.call_nowait(AmqpBasic::Publish(AmqpPublish {
            ticket: 0,
            exchange: exchange.into(),
            routing_key: publish.routing_key,
            mandatory: publish.mandatory,
            immediate: publish.immediate,
        }))?;

Thanks!


Use CloseableRetryableRefreshListener to drain ongoing after refresh tasks on relocation

Description
RefreshListeners are async in nature and are triggered after segments are refreshed. Today, during relocation handoff, it is possible that the remote segments upload are happening from the older primary while the relocation has happened. Now, we are introducing a CloesableRetryableRefreshListener which will be extended by RemoteStoreRefreshListener and CheckpointRefreshListener. The CloesableRetryableRefreshListener has capabilities to be closed which guarantees that refreshes would not trigger any after refresh operations on these listeners once closed.
Related Issues
Resolves #8345

Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Where are we closing the listeners?

Have added it now.


[FEATURE] Add script for development mode to generate config.json from split yaml

The capability of breaking a large config.json into smaller chucks is awesome.
However while doing local cdk operations i.f from cdk.sh/(ts), it only expects input in form of config.json.
It would be super nice to be able to generate config.json for local run from the original yaml files, or even better in place of config.json, provide the path of config.yaml and it work out of box.
The first option could be little simple since we probably have the same support in pipeline run. Need to figure out how to integrated the same in cdk.ts.
Second option is little trickier, but could be more developer friendly since now we can avoid copy paste.

Understood - let me chat with the team on this.  Sounds like we need to do a better job on some of the developer guidance/optimization.

See see PR#753 as an enhancement in this area.  As we accept multi-part config files, but always internally utilize a single config file, this is not a planned enhancement.


BDD100K: 8M Images?

According to Table 1 (screenshot below), the model was trained on 8 million unlabeled images from BDD100K. However, the downloadable BDD100K dataset contains only 100,000 images.
Therefore, I wonder if the authors sample these 8 million images from video clips. If so, please provide the list of videos and the sampling rate. Thanks!

Yes, we evenly sample 8M images from the raw videos.

Could you please specify the sampling rate (extract 1 frame from how many frames)?

Our sampling rate is one image / 10 frames. We sample them from 70K training videos of BDD100K.

Thanks.


Large File Upload fragment response includes null value for "uploadUrl"

The upload itself is behaving as expected, but every time I upload a fragment, the response looks something like this:
{
<EMAIL_ADDRESS>"https://my-sharepoint-here.com/_api/v2.0/$metadata#oneDrive.uploadSession",
  "expirationDateTime": "2016-04-12T22:41:55.9162251Z",
  "nextExpectedRanges": [
    "4453-4999"
  ],
  "uploadUrl": null
}

Docs suggest that the field shouldn't even be present, and I'm not depending on it, but it still looks like an oversight.

This issue should now be resolved - please let us know if you still see problems.


[release-1.10] conmon: fix incorrect log line on a log refresh

backport of https://github.com/kubernetes-incubator/cri-o/pull/1606

/test all


Help Me: huge docker_data.vhdx

Which self-help guides have you tried to follow? (required):
Please list the guides or resources you've consulted so far.
I tried to solve this problem using Optimize-vhd:
https://gist.github.com/jjmartres/177c68d3f44a4f8a82d9d0bc42a97637
I tried to solve this problem using diskpart:
https://stackoverflow.com/questions/70946140/docker-desktop-wsl-ext4-vhdx-too-large
I tried to solve this problem using wslcompact -c -d:
https://github.com/okibcn/wslcompact
No method has brought any result
Most of the guides pay attention to the problem of large size of ex4.vhdx file, which is the main file in WSL2, but I have a problem with large size of docker_data.vhdx data file. not with ex4.vhdx file and I couldn't find a solution to my problem anywhere.
Describe Your Issue (required):
Hi Phil!!! Please tell me how to solve the problem of huge file size AppData\Local\Docker\wsl\disk\docker_data.vhdx
without deleting or corrupting the data.
Have you checked the FAQ (required):
Yes
Additional Information:
This is the actual size of the container:

but physically it is many times bigger.

Hi @farmdigit ,
Have you tried this solution?

I also faced the same problem , it was because septber 7 the previous version of docker didn't support reclaim storage feature in wsl2. if you can update to latest version now they mentioned it supported reclaim feature. before that I untick "use wsl2 instead of hyper-v" while installing docker. do it and use hyper-v and the problem solved.

I assume you should be able to upgrade the Docker Desktop using hyper-v without losing the data in the container.

Have you tried this solution?

I don't understand what it's supposed to do.
How can I reclaim storage feature in wsl2?

I assume you should be able to upgrade the Docker Desktop using hyper-v without losing the data in the container.

how do I do that?

I've no idea, it was just a previously suggested theory that hyper-v was more efficient on disk space than docker built on WSL2. I use Ubuntu Server as an operating system so I don't have experience with this issue.


Homepage

You can set package homepage from the settings. It is automatically generated with pkgdown.
The result will be like:
https://microbiome.github.io/mia/
@ake123 can advice how it is done if you can't find instructions easily.

The package's homepage is now live and accessible at: https://aliyoussef96.github.io/LimROTS/.


[Feature Request] Include "Plan To Read" for Sync MangaDex to Neko Feature

Why/User Benefit/User Problem
personally i have a lot of manga that i plan to read and this feature will help me track and sync easily, i read from both the website and app.
currently if i want to add some manga's that i plan to read in the website, i have to change its status to reading, then turn it back to plan to read on both website and app

I'm a bit confused.
If you add the manga and you switch the mdlist tracking to planned to read it add it's to the website.
If you have the beta setting enabled adding the manga does this for you.

Yes for the last part,
from the app to the website works great.
But whenever i use the website and mark a new manga "plan to read", it doesnt sync when i choose the option "sync MangaDex to Neko", so i have to mark it "Reading" on the website so it can sync with Neko and add it to the library.

in 2.2.1


Formatted string literals (PEP 498)

There are still some differences related to the SyntaxError messages which I may not fix in the PR (https://github.com/IronLanguages/ironpython3/issues/1346):

f'{lambda x:x}' reports invalid syntax instead of unexpected EOF while parsing. Note that eval('(lambda x)') also reports the wrong message.
eval("f'''{\xa0}'''") reports invalid syntax instead of invalid character in identifier (and the message is again different in 3.9).
eval("fu''") reports invalid syntax instead of unexpected EOF while parsing.
f'\N' reports encoding problem instead of ... malformed \N character escape (should be the same message as '\N').

Other issues:

f'{3.14!s:10.10}' doesn't produce the expected result but that's because the float repr (https://github.com/IronLanguages/ironpython2/issues/102).
The CPython test_fstring comes from 3.6 and expects eval(r"f'\{6*7}'") to raise a DeprecationWarning (https://github.com/IronLanguages/ironpython3/issues/1343).
Support for yield/yield from (https://github.com/IronLanguages/ironpython3/issues/1344).
AST locations are all wrong (https://github.com/IronLanguages/ironpython3/issues/1345).

F-strings? Awesome!
Are you going to support yield/yield from too?

F-strings? Awesome!

Yeah, one of the few 3.5+ features that I use regularly so thought I'd give it a go.

Are you going to support yield/yield from too?

Have not given it any thought (didn't even know it was a thing until I tried running the unit tests😄). Will take a look at what's involved once I get the "basic" stuff working.

@BCSharp No idea if you have any interest in reviewing this - but I'm sure it could use a good look-over. I guess the one open issue that's bugging me the most (and that falls in an area you looked at before) is the one with the bad unicode escapes (e.g. f"\N" or f"\U1234") resulting in encoding problem. So if you have any ideas about that (or anything else) I'd be glad to hear them.

Yes, I will look at it today. I was kind of looking along as you went but not very thoroughly. The remaining outstanding issues seem less consequential (with maybe the exception of AST locations) since they are mostly error messages. I personally never used yield in an f-string, but have used the "="-modifier, though it is from a higher Python version (3.8).

Looks good to me!

I guess the one open issue that's bugging me the most (and that falls in an area you looked at before) is the one with the bad unicode escapes (e.g. f"\N" or f"\U1234") resulting in encoding problem

Well, there are a couple things going on here. First, Parser.BadSourceError handles conversion from DecoderFallbackException to SyntaxError. It is filled with heuristics to match CPython messages as close as possible, though it is not perfect because CPython reports a slightly different message if a Python file is imported rather than run on command line. Discrepancy considered benign. So I would modify this part to detect your f-string decoding exception and handle is as you wish.
The second issue is in LiteralParset.TryParseFString.handleUnicodeError. It uses PythonExceptions.CreatePythonThrowable from UnicodeDecodeError, but when UnicodeDecodeError is converted to a CLR exception it only takes the first argument as the message (while the most informative message is the last argument). Perhaps this is a bug but you do not need to create a Python error here, since the it will be caught in  Parser.BadSourceError and converted to SyntaxError, you can simply throw PythonOps.UnicodeDecodeError.


fix(build.sh): delay so stderr is logged before pod exits

Output for git push with a bad buildpack would sometimes fail to show the relevant buildpack compile output and instead log the json for a Kubernetes pod error, similarly to deis/dockerbuilder#76.
Introducing a small delay before exiting seems to fix the output such that deis/workflow-e2e#258 passes consistently. I ran gingko -untilItFails until neither of us could stand it:
$ GINKGO_NODES=20 FOCUS_TEST="with a bad buildpack" make test-integration
ginkgo -slowSpecThreshold=120.00 -noisyPendings=false -v -untilItFails -nodes=20 --skip="all (buildpack|dockerfile) apps" --focus="with a bad buildpack" tests/
Running Suite: Deis Workflow
============================
Random Seed:<PHONE_NUMBER>
Will run 2 of 304 specs

Running in parallel across 20 nodes

...

Ran 2 of 304 Specs in 19.857 seconds
SUCCESS! -- 2 Passed | 0 Failed | 0 Pending | 302 Skipped

All tests passed...
Will keep running them until they fail.
This was attempt #44
No, seriously... you can probably stop now.
^C

Fixes #93.
Unblocks deis/workflow-e2e#258.

This passed all tests in CI but went red because the job couldn't locate the right pod for JUnit logs. I'm merging it.


[util/topgen,sw]: Add generation of Rust derive to topgen

The main purpose of this change is to allow easier integration of generated Rust chip definitions in end-user projects. The following changes remove some issue inherited from the C source file generator.
Bellow is a list of changes made to topgen scripts:

Add option to generate derive for Rust enum
Add default Copy and Clone implementations to Rust enum generator
Add short type names without TOP_CHIP prefix
Remove Rust memory template file
Replace Rust top_earlgrey_memory with top_earlgrey in SW

The rationale for deleting the top_ealgrey_memory.rs  file is the comment in the C equivalent of that file:
/**
 * @file
 * @brief Assembler-only Top-Specific Definitions.
 *
 * This file contains preprocessor definitions for use within assembly code.
 *
 * These are not shared with C/C++ code because these are only allowed to be
 * preprocessor definitions, no data or type declarations are allowed. The
 * assembler is also stricter about literals (not allowing suffixes for
 * signed/unsigned which are sensible to use for unsigned values in C/C++).
 */

Rust is completely different form C/C++/ASM. Limitations and uses-cases of  C header don't apply to this file.
The second factor in favor of removal is the duplication of the code in relation to the already existing file.

@alphan @timothytrippel can you give this a look also and merge it if you are ok with the change?


istioctl/helm3 installation instructions for upgrades do not work with istio 1.4.x

Bug description
Following the instructions at https://github.com/istio/istio/blob/release-1.6/manifests/charts/README-helm3.md when installing to istio-canary namespace I get the following error
Error: admission webhook "pilot.validation.istio.io" denied the request: configuration is invalid: Envoy filter: unknown message type "udpa.type.v1.TypedStruct"
Expected behavior
helm3 charts would install the istio 1.6 charts into a canary namespace
Steps to reproduce the bug

Install istio 1.4.8 into istio-system
kubectl create namespace istio-canary
helm install istio-base --namespace istio-canary manifests/charts/base
helm install -n istio-canary istio-16 manifests/charts/istio-control/istio-discovery -f manifests/charts/global.yaml --set revision=canary --set clusterResources=false

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
Istio 1.6.0-beta.1
K8s 1.15.11
How was Istio installed?
Helm in 1.4.8
Helm3 in 1.6.0-beta.1 using the following 2 commands
Environment where bug was observed (cloud vendor, OS, etc)
k8s cluster created on AWS using kops

Updated since I ran into this issue following the upgrade instructions using istioctl.

@nrjpoddar Posted a solution which I've verified works with istio-1.6.0-beta.1
See https://github.com/istio/istio/pull/23194#pullrequestreview-399547413


Unify styles of ops

Closes #156. Feel free to ping me if there is anything missing.

Edit: since python2 does not accept this kind of signature:
def foo(*x, name=None):
    pass

while python3 does.
Therefore, I modidy compose_transforms a little bit.


Provide onDidChangeShell event which is fired when default terminal profile changes

Python extension is planning to use environment collection API to activate Python environments for a particular shell. Environment variables to use depends on the shell itself, so when the default shell setting changes, we would like to be notified so we could prepare the new set of environment variables to use the next time terminal opens.
As a workaround we could use onDidOpenTerminal to detect this change with a delay, however that requires the user to relaunch the terminal once environment collection is updated.
cc/ @Tyriar feel free to close this if this is a dup of https://github.com/microsoft/vscode/issues/160694.

It looks like PR #160900 already added that event as proposed API.

/duplicate https://github.com/microsoft/vscode/issues/160694

When I attempt to use the proposal it says:

Can you please clarify on what is needed to done from extension's end to use this?

You have to add the proposed API to your package.json like this

That is where the screenshot is from in the original pic.

Should I create a new issue?

What version of the vscode engine does your extension declare that it uses?

It's 1.75.0-20230123:

This proposal cannot be used because for this extension the product defines a fixed set of API proposals. You can test your extension but before publishing you MUST reach out to the VS Code team.

Does VSCode have a products file internally which declares which extension gets to use the proposal?


Pr Open FGA - replace the  https://github.com/cncf/landscape/pull/2761

Replaces #2761
Signed-off-by: Andres Aguiar<EMAIL_ADDRESS>Pre-submission checklist:
Please check each of these after submitting your pull request:

[X] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[X] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[X] Have you picked the single best (existing) category for your project?
[X] Does it follow the other guidelines from the new entries section?
[X] Have you added your SVG to hosted_logos and referenced it there?
[X] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[X] Does your project/product name match the text on the logo?
[X] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~30 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

@caniszczyk please review

@AndreyKozlov1984 thank you!

@AndreyKozlov1984 can you look at the recent PRs too? I assume that this layout change will fix things

It should just be merged back into those PRs if that is a real reason


NFT should work on desktop too

NFT has to work on desktop too. A matrix scaling issue is probably prevent this to work.

@nicolocarpignoli it works for me but the model is showed at the corner of the pinball.jpg image (see the screenshot above). It seems like the setting for the repositioning of the model has little or no effect.

The same result for me, also the model rotation with the camera is wrong, it rotates around its axis, not with the marker axis.

I have the same problem and I partially solved it by adjusting the position and rotation of the video, but I have a bigger problem, the NFT image recognition system works with the trex image in the example, but when I change this image to a custom one it does not work and the app gets stuck on the "loading, please wait" message and never moves from here. Any ideas how to fix it?


Improve design of the app

What so far we can improve:

In advanced mode when we have many history items , query result overlap pane "Enter MongoDB Query"

Also we don't have an option to clean records from history, or remove separate results from it


Crop after 90/270deg rotation results in "Error: extract_area: bad extract area"

I've verified the resulting image dimensions are correct (width & height are effectively flipped), so it appears the crop operation is not taking into account the new image dimensions.
Error: extract_area: bad extract area

    at Error (native)

Hi Aaron, there is existing logic and test cases to deal with this situation.
The ordering of extract and resize is significant. It's possible to extract two different areas in the same pipeline, before and after resize. Are you able to share some sample code?

I don't have code I can copy/paste, but basically this is happening:
sharp(file200by100).rotate(90).crop(0,0,100,200);

If I use the minimum dimension it'll work, but for whatever reason the error is being thrown when it shouldn't be.

I've been able to reproduce this problem with the following:
sharp('test/fixtures/2569067123_aca715a2ee_o.jpg')
  .resize(200, 100)
  .toBuffer()
  .then(function(data) {
    return sharp(data)
      .rotate(90)
      .extract(0, 0, 100, 200)
      .toBuffer();
  }).catch(function(err) {
    console.log(err);
  });

It occurs when rotating and extracting without (or before) a resize in the same pipeline.
Should be fairly easy to fix and add tests for this combination. Thanks for reporting!

Awesome, thanks!

Commit 58d9e0f should fix this. Are you able to retest using the look branch?
npm install lovell/sharp#look

(This is the work-in-progress branch for what will become the v0.12.0 release.)

Verified working.

Great, thanks for confirming Aaron. This will be included as part of v0.12.0.
If you're able to share details publicly, it's always great to learn about what people are using this module for in the survey at #35.

The look branch has now been merged to the master branch pending release. Thanks again for reporting this.


Support for Application Load Balancers

Only network load balancers are supported.
It's quite common to have an application load balancer acting as endpoint forwarding traffic to the target groups based on rules, that is, path-based targeting:
/s1 --> target group for s1
/s2 --> target group for s2

Right now, even passing an existing pre-configured ALB with x-aws-loadbalancer doesn't work, because the convert tries to create a TCP  listener which is not suitable for an ALB (only HTTP and HTTPS are supported).
If an ALB is specified and a service exposes a port in the compose file, docker should not try to create a listener, just configure the port in the task definition.
Ideally, we could even expand this to have fine-grained control on the ALB and target groups with something like:

x-aws-loadbalancer-type: application or network.
x-aws-loadbalancer: arn for the load balancer. If not specified, create one using the type specified by x-aws-loadbalancer-type.
x-aws-alb-rules: list of rules to attach to the listeners of an ALB.  Required if x-aws-loadbalancer-type is application. Not applicable for NLB.
x-aws-alb-listeners: list of listeners for the ALB.  Required if x-aws-loadbalancer-type is application. Not necessary for NLB as NLB would automatically create a listener for each exposed port (as it's working right now).
x-aws-loadbalancer-target-groups:  list of arn of the target groups to attach to the load balancer. Required if x-aws-loadbalancer-type is application. If it's network and no target groups are specified, they could be created as they are right now.

And so on.

path based routing is something we have in mind but doesn't yet have any mapping in Compose model.
We for sure could introduce custom extensions, to support ECS deployment to expose /s1 and /s2 as you described on ALB. I then assume some other components of the application do access those path (a client-side web UI probably?). Issue doing so is that such an application then can't be ran locally with docker-compose, breaking the portability of the application model.

You might have:
services:
  foo:
    image: "foo"
    ports:
      - 8080:8080

  bar:
    image: "bar"
    ports:
      - 8081:8081

Locally, you access them by using the port, http://localhost:8080.
In AWS, you can have an ALB with rules so that:

https://example.com/foo forwards traffic to a target group attacking the service foo
https://example.com/bar forwards traffic to a target group attacking the service bar

The compose is the same, it should not change. What changes is the config of the application. There might be a third service baz which uses foo:
  baz:
    image: "baz"
    environment:
      - FOO_ENDPOINT: "${FOO_ENDPOINT}"

And then, if you are running the compose locally, you'd set the variable to FOO_ENDPOINT=http://localhost:8080, and if in AWS, FOO_ENDPOINT=https://example.com/foo

An ALB will be created if you use x-aws-protocol: http to inform ECS integration the service is actually layer-7 routable.
My concern is exactly about configuring other services so they get the adequate endpoint URL for sibling services. Within compose model, it is expected you can just reach other services on network by service name, without a specific subpath (which only make sense with URL based protocols). We have to find some way to avoid the need for such a manually managed FOO_ENDPOINT variable.
Note: the legacy links property in compose file format do inject such variables in target container, maybe we could leverage this.
services:
  foo:
    image: "foo"
    ports:
      - 8080:8080

  bar:
    image: "bar"
    links:
      - foo
    ports:
      - 8081:8081

doing so, bar container has environment variable injected:

FOO_PORT=tcp://<IP_ADDRESS>:8008
FOO_PORT_8080_TCP_ADDR=<IP_ADDRESS>
FOO_PORT_8080_TCP_PORT=8080
FOO_PORT_8080_TCP_PROTO=tcp

If we introduce support for application-level protocol declaration in port definition:
  foo:
    image: "foo"
    ports:
      - target: 80
        published: 8080
        protocol: tcp,http // actual syntax to be defined

... then we could extend this mechanism by setting additional env variable if path-based routing is used:

ECS deployment:

- FOO_PORT=http://<IP_ADDRESS>:8008/foo
- FOO_PORT_8080_TCP_PATH=/foo

local deployment:

- FOO_PORT=http://<IP_ADDRESS>:8008/
- FOO_PORT_8080_TCP_PATH=/


Install support for ACR

Summary of the new feature / enhancement
Install support for ACR
Proposed technical implementation details (optional)
No response

Resolved by #1505


Feature association

Changes

Computes features and present them as an association
Computes graph features about the causal graph and the graph version of the final state (using HypergraphToGraph with "StructurePreserving" method)
Changed Feature Vector as Flatten @ Values @ #["FeatureAssociation"]

Comments

Some functions could have a more elegant implementation...

Examples
In[] := WolframModel[{{x, y}, {x, z}} -> {{x, z}, {x, w}, {y, w}, {z, w}}, {{0, 0}, {0, 0}}, 5]["FeatureAssociation"]
Out[] = <| "CausalGraphVertexCount" -> 22, "CausalGraphEdgeCount" -> 42,
 "CausalGraphVertexConnectivity" -> 1,
 "CausalGraphVertexDegreesQuantiles" -> {2, 2, 2, 6, 6},
 "StructurePreservingFinalStateVertexCount" -> 115,
 "StructurePreservingFinalStateEdgeCount" -> 138,
 "StructurePreservingFinalStateVertexConnectivity" -> 2,
 "StructurePreservingFinalStateVertexDegreesQuantiles" -> {2, 2, 2, 2, 8} |>

This change is

We need to compute the evolution objects within the VerificationTest. The output from the failed tests is way too large and makes it very hard to understand what's going on.

I think that what's "failing" are the error messages checks (testUnevaluated)

I think that what's "failing" are the error messages checks (testUnevaluated)

I think it's because the WolframModel has evaluated into WolframModelEvolutionObject, and testUnevaluated expects the input to remain completely unevaluated. A solution would be to generate the evolution object before the test or pass the property to WolframModel directly.

That does not fix the tests, that skips them. You just evaluated the argument of testUnevaluated before it even gets into the test, so of course the test passes because there is nothing left to evaluate.
It does, however, produce messages while pre-evaluating it which is why CI fails (it does not allow messages).

If:

the attribute of testUnevaluated in the .wlt file is set to HoldAllComplete
Evaluate is replaced with With
, then the tests pass:

      Attributes[Global`testUnevaluated] = Attributes[Global`testSymbolLeak] = {HoldAllComplete};

          (* Error Messages check *)
          With[{obj = evolutionObjects[[3]]}, {
            testUnevaluated[obj["FeatureAssociation", 3], {WolframModelEvolutionObject::invalidFeatureSpec}],
            testUnevaluated[obj["FeatureAssociation", "EasterEgg"], {WolframModelEvolutionObject::unknownFeatureGroup}]
          }]


Users management

The riscoss administrator should be able to create/modify/delete users. One user can acces to one/more domains and has assigned one user role. Therefore, we have 3 global lists (no domain dependent), managed by the administrator:

Domains
Users
Roles

And then, the administrator can assign: 1 user - 1 domain - 1 role, as many times as administrator wants. One user cannot be assigned to the same domain using different role. For example:
Lidia - UPC - role 1
Lidia - FBK - role 2
Lidia - FBK - role 1 --> NO!!!!!!
For the user we need the Name/Alias and maybe an email account (optional) to receive notifications (if we have notifications)
Related to:

#53: Domain management
#47: Roles management

Do we allow 1 user assigned to more than 1 domain?
If one user can access to more than 1 domain, the user roles is assigned to the user or to the pair user-domain?


Centralize Executor Setup?

Places where Executor setup info is required
These all handle a mix of Executor object and submit method:

configuration.setup: Record and validate user setting in setup field
configuration.job: Each job may get there own Executor (depending on code type). Default Executor settings are currently stored here. The settings are created here but instantiation is deferred until...
configuration.configuration: Executors instantiation methods live here.  Executors are not allowed and only Configuration can see all Jobs together to determine if a valid set is being requested.
Executor Object
This is all actually used by:
The actual calls to make the Executors run in the "Optimizer" class as it creates the setup for libEnsemble.
The Executor settings (for submission) stored in each Job are used by SimulationFunction.

This mostly might be fine, there is a certain logic to all this setup. However,

The defaults for the Executor object shouldn't live in the Optimizer, they should be stored in Options/Configuration. Whichever makes the most sense. [This is changed in 35e12f5073e2d1446525b5e4b9d0a827587220c0. Defaults are now stored in configuration and all the Executor instantiation takes place in Configuration.create_exector. The Optimizer still actually calls the creation method]
The Executor setup in Jobs doesn't make clear that it is preparation for Executor.submit and not the Executor object proper.

This could maybe still improve but hasn't been a major issue for development. Closing for now.


Removed variant processes on product creation.

Removed spec, spec option, variant generation, etc. on product creation. This process is only required by the seller app as part of the product PUT and is effectively redundant for the seller app.
Happy to have this rejected with the reasoning being that it can be used for other external integrations, not just the seller app, however I would suggest that the intent behind the middleware is only for the buyer and seller apps to keep the code as simple as possible.

That may have been the original intent at some point but I am good removing it with the assumption that it should only be used by the buyer and seller application


Console warning when creating a new report

When going to the report form I get the following error in the console:
Failed prop type: The prop `onChange` is marked as required in `RichTextEditor`, but its value is `undefined`.

Part of #1522


Mixed search modes

Thanks for this great plugin :smile:
I am wondering if it's possible to have mixed search modes. For example, searching for files and grepping at the same time; or looking for lsp references but have grepping as fallback.

Ty @yshui!
Funny meeting you here after a long time since our initial encounter in picom#361 :-)

I am wondering if it's possible to have mixed search modes. For example, searching for files and grepping at the same time; or looking for lsp references but have grepping as fallback.

Not sure if I fully understand the workflow but between writing a small lua extension and using fzf's own ever-expanding tools I'm sure we can craft something to meet your needs.

searching for files and grepping at the same time

I'm assuming you mean selecting file(s) and then switching to grep mode and grep'ing only the selected files?
While not exactly what you're after you can use live_grep_glob to regex search specific file globs, for example input of ^foo -- *.bar will search for lines that start withfoo only in files that have a .bar extension, after that you can press <C-g> to switch to fuzzy search mode and further refine the result set returned from live_grep_glob (the process can continue endlessly).

looking for lsp references but have grepping as fallback

This is pretty easy to do, you can write a small custom action that would take the last search term and feed it into grep, for exmaple, the below starts with lsp_document_symbols and switches to grep when pressing <C-f> (notice that af you can press <C-g> to switch back to live_grep and modify the underlying grep search term).
local fzf_lua = require'fzf-lua'
fzf_lua.lsp_workspace_symbols({
  actions = {
    ['ctrl-f'] = function(selected, opts)
      fzf_lua.grep({ search = fzf_lua.config.__resume_data.last_query })
    end
  }
})

Funny meeting you here after a long time since our initial encounter in https://github.com/yshui/picom/pull/361 :-)

Good memories :laughing:
Thanks for the explanation but I think it's somewhat different from what I had in mind.

I'm assuming you mean selecting file(s) and then switching to grep mode and grep'ing only the selected files?

Maybe this use case is too niche, but sometimes I find myself unsure whether to search for a file name or for a keyword. It's sometimes convenient to do both at the same time, even if I ended up don't need the result of grepping.
Similar reasoning goes for the grepping + lsp use case.
In general, I was wondering if there is a need for doing several different kinds of searches at the same time, not just limited to the examples I gave.

Yeah, being able to switch search type with a key binding is pretty neat. It helps with my problem but I still think mixed search mode would be better.

Maybe this use case is too niche, but sometimes I find myself unsure whether to search for a file name or for a keyword. It's sometimes convenient to do both at the same time, even if I ended up don't need the result of grepping.

TBH, I do think it’s a bit niche, nevertheless, if you’re willing to do a bit of legwork, it’s possible, you’d have to create your own provider (easy using the API) that combines both sources, in your case files using fd or rg --files plus the grep results.
An example of how to combine two result sets together can be seen in #485. If you do choose to go down this road, I’d be more than happy to help.

[...] For example, searching for files and grepping at the same time; or looking for lsp references but have grepping as fallback. (scroll to top)

I used to search for a plugin to achieve the feature like this plugin https://github.com/kevinhwang91/nvim-bqf#filter-items-with-signs-demo, for more details https://github.com/kevinhwang91/nvim-bqf#setup-and-description filter = {...} explains the related command and its effect. I really like this way of further filtering the result items. Maybe this would provide some idea of how your "Mixed search modes" could be implemented.

While not exactly what you're after you can use live_grep_glob to regex search specific file globs, for example input of ^foo -- *.bar will search for lines that start withfoo only in files that have a .bar extension, after that you can press <C-g> to [...] (scroll to top)

This is what I'm currently using and I enjoy it. This resolved my old feature request #270 you might also take a look for reference.

Closing for now, feel free to open if you more help.


Mirror project: wrong path to images

Gitea version (or commit ref): 1.13.4
Git version:
Operating system:

Database (use [x]):

[x] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Description
When I migrate https://github.com/cassiomolin/log-aggregation-spring-boot-elastic-stack then I get in browser

The problem is the brocken url path to the image:

You need to tell us what the file actually links to in the markdown, what it was rendered to, what you expected, what your appurl URL and give us some indication as to how you expect us to be able to guess that this is what it should be.
We could potentially change the base URL for the render but I think we may be screwed at making this work.

Sorry. My gitea config
[server]
SSH_DOMAIN       = nuc-mini-celeron
DOMAIN           = nuc-mini-celeron
HTTP_PORT        = 3000
ROOT_URL         = http://nuc-mini-celeron:3000/

The URL on the GitHub page looks so:
https://github.com/cassiomolin/log-aggregation-spring-boot-elastic-stack/blob/master/misc/img/diagrams/elastic-stack.png
The link in my local Gitea is
http://nuc-mini-celeron:3000/misc/img/diagrams/logstash-pipeline.png
It's not bad, that the image isn't shown. But the basic authentication "sucks".

markdown rendering related

Auth popup is a separate issue where the browser hits the HTTPS endpoint meant for the git client which should never happen. If there are steps to reproduce this popup, please open a separate issue with them.

OK so the actual markdown that is being misrendered is:
![Elastic Stack][img.elastic-stack]

So it's the linked reference paths aren't being handled properly

OK it's actually not that it's with or without preceding slash that makes the difference.

Should this work in 1.14.0?

1.15.0

1.15.0

Thx. Cause I saw

But 1.15.0 is good!


Add new action for Watson Retrieve and Rank

Add new action for Watson Retrieve and Rank
Related to #365
http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/retrieve-rank.html

@csantanapr move to catalog?

Issue moved to openwhisk/openwhisk-catalog #207 via ZenHub


biological regulation

only has 7 direct annotations
http://amigo.geneontology.org/amigo/search/annotation?q=*:*&fq=regulates_closure:"GO:0065007"&sfq=document_category:"annotation"
@pgaudet  can we make this "not for direct annotation"
(manual or annotation transfer), if you don't know more than this you don't really know anything...

Hi Val,
I created a ticket to review annotations (https://github.com/geneontology/go-annotation/issues/1887)
Shouldn't we also add 'do not annotate to
'regulation of biological process' (0 direct)
'negative regulation of biological process' (0 direct)
'positive regulation of biological process' (2 direct)?
Thanks, Pascale

great.
Shouldn't we also add 'do not annotate to
absolutely!

from any source, EXP or inferred....


Add missing postman collections

Is your suggestion related to a missing or misleading document? Please describe.
The following REST API docs are missing postman collections:

[ ] https://is.docs.wso2.com/en/latest/develop/email-templates-rest-api/

[ ] https://is.docs.wso2.com/en/latest/develop/fido-rest-api/

[ ] https://is.docs.wso2.com/en/latest/develop/permission-management-rest-api/

[ ] https://is.docs.wso2.com/en/latest/develop/totp-rest-api/

[ ] https://is.docs.wso2.com/en/latest/develop/authorized-apps-rest-api/

[ ] https://is.docs.wso2.com/en/5.11.0/develop/scim2-rest-apis/

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Issues with TypeScript

Hi, I'm working with TypeScript and installed react-draggable.
As it is said in the doc touse the <Draggable /> component I need to import as default:

The default export is <Draggable>. At the .DraggableCore property is <DraggableCore>. Here's how to use it:
// ES6
import Draggable from 'react-draggable'; // The default

But when I try to import it:
// myComponent.tsx
import Draggable from 'react-draggable';

I get the Module "react-draggable" has no default export. error. Doing:
import * as Draggable from 'react-draggable';

brings me the <Draggable /> component but in TypeScript syntaxis * as also brings all definitions and typings so I can't use it as a component (error: JSX element type 'Draggable' does not have any construct or call signatures.)
I only can use it is:
const Draggable: any = require('react-draggable');

but it's weird since this package already gives typings.
I'm using typescript 2.3.2 and awesome-typescript-loader 3.1.3. Anyone has encountered this issue?
PD: Big thanks to give typings. This is an awesome package!

Please be sure you're on the latest version - there is a default export: https://github.com/mzabriskie/react- draggable/blob/845aaa8658f5939caae4284a9b5941a779ca8353/typings/index.d.ts#L46

Installing it with npm i -S react-draggable gives me version 2.2.5. Viewing node_modules/react-draggable/index.d.ts file I don't see any export default :disappointed:

My mistake, the newest definition wasn't in a release yet. I just released 2.2.6, please try it again and see if it fixes your issue.

Thank you very much, typings issue is gone now :) ! I'll try to figure out now why doing now
import Draggable from 'react-draggable';

gives me undefined. I'lll close this issue for now. Thank's for all :)

Hi, I have the same problem,
I get undefined too when I import Draggable from 'react-draggable';
and when I import * as Draggable from 'react-draggable'; I get JSX element type 'Draggable' does not have any construct or call signatures..
I'm using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

@etienne-dldc The problem was I was using "module": "commonjs" instead of "module": "es6" in my tsconfig.json. After that, it's solved :)

@crsanti What if I need to use commonjs for other libraries I use?

@crsanti typescript doc says that the default value for "module" options is target === "ES6" ? "ES6" : "CommonJS". So why should I set it to "module": "es6" in order to make it work?

Sorry, it was a mistake on my config, I got it working with "module": "es6"

I'm getting this undefined error as well now. It's not an option for me to change my entire module import type from commonjs to es6 as I have many other things depending on it. Are there any other options? This library looks great!
Typescript 2.3.4 and react draggable 2.2.6

There's definitely a problem. If I use "module": "es6" in tsconfig, then I have to create my own typings:
declare module "react-draggable" {
    export default class Draggable extends React.Component<any, any> {

    }
}

And then importing as import Draggable from "react-draggable"; works fine.
If I use  "module": "commonjs", then importing also works but the app crashes in the browser with:
Uncaught Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined.

Same problem here as well. Can use the any construct as suggested, but - yes then typings are gone. I could not get it working as suggested in the #226 case neither.
using package.json: "react-draggable": "^2.2.6",
Any suggestions?

If you guys can figure out what the correct exports should be I'm happy to
cut a major and change it.
On Jul 28, 2017 12:11 PM, "Ronny Hanssen"<EMAIL_ADDRESS>wrote:

Same problem here as well. Can use the any construct as suggested, but -
yes then typings are gone. I could not get it working as suggested in the
#226 https://github.com/mzabriskie/react-draggable/pull/226 case
neither.
using package.json: "react-draggable": "^2.2.6",
Any suggestions?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mzabriskie/react-draggable/issues/246#issuecomment-318710580,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABJFPxSBxZ4IEMLWx8VN7LenwUAz_RtAks5sShZOgaJpZM4NMr4d
.

Since webpack exposes the library for UMD as:
module.exports = factory(/* some dependencies */);

Watching another umd libs like moment.js typings:
exports = moment;

So I think (I'm not 100% sure) that the only way that TypeScript can consume react-draggable for "module": "commonjs" is using:
import * as Draggable from 'draggable'; // not undefined

For "module": "es6" it can be consumed with import as syntax and the ES6 default import:
import Draggable from 'react-draggable';
import * as Draggable from 'react-draggable'; // both are not undefined

But right now using the above syntax will produce typings issues so.. I'll keep researching about this to get the correct typings.

@crsanti

So I think (I'm not 100% sure) that the only way that TypeScript can consume react-draggable for "module": "commonjs" is using:
import  * as Draggable from 'draggable'; // not undefined

You mean react-draggable, right? For the record, that does not work for me (even with react-draggable). On usage of <Draggable... I get
[ts] JSX element type 'Draggable' does not have any construct or call signatures.
in the editor and
ERROR in [at-loader] (...) TS2604: JSX element type 'Draggable' does not have any construct or call signatures.
in the application.
Anyway.
@STRML: There have been discussions in the typescript community that one should avoid the default export option. The reason being first of all that you get no intellisense to help you name the variable. If you instead use a named export then when placing the marker inside the import statement's curly-braces you will get intellisense (for the editors that support intellisense).
It seems to me (at a glance) that the named exports from react-draggable are actually working, oddly enough.
BTW: I am using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>with "module": "commonjs" in tsconfig.json.

Same issue here with "awesome-typescript-loader": "3.2.2",  "typescript": "2.4.2" and "module": "commonjs" using "react-draggable": "^3.0.3":
import * as Draggable from 'react-draggable';
...
render() {
  <Draggable>
    ...
  </Draggable>
}

results in TS2604: JSX element type 'Draggable' does not have any construct or call signatures.


A feature for displaying message before completing successfully

With the yesod init command it displayed a beginner friendly message after completing successfully. This functionality is lost now.
I want to suggest how to implement this in stack new. If you like this approach I hope to find time to implement it.
What about having a {-# START_SUCCESS_MESSAGE #-} to signify where the message starts. It think can be a mustache template like anything else. Good approach?

Since this is a feature that needs to be implemented in Stack itself, can
you reopen against the Stack repo?
On Sat, Jan 16, 2016, 11:29 AM Cies Breijs<EMAIL_ADDRESS>wrote:

With the yesod init command it displayed a beginner friendly message
after completing successfully. This functionality is lost now.
I want to suggest how to implement this in stack new. If you like this
approach I hope to find time to implement it.
What about having a {-# START_SUCCESS_MESSAGE #-} to signify where the
message starts. It think can be a mustache template like anything else.
Good approach?
—
Reply to this email directly or view it on GitHub
https://github.com/commercialhaskell/stack-templates/issues/24.

Seems relevant to https://github.com/commercialhaskell/stack/issues/1571 , perhaps add a comment there?  I agree that this would be cool.  Maybe it'd be enough to display the description after initialization?


dub.json option to force RDMD

Projects may rely on RDMD's behavior of not compiling files that aren't imported (and I don't think it's DUB's place to prohibit this),  but then that causes problems when the project is built with DUB. For example: https://github.com/Abscissa/DAuth/issues/1
It'd be helpful to have an option in dub.json to allow a project to force itself to be compiled with RDMD.

The problem here is actually that dub shouldn't abort compilation on
warnings - at least not in debug mode -. I think that's one of the most
annoying bug I had with dub.
Another problem is that the language is quite unstable. Currently, we have
platform-specific suffixes (system/arch/compiler), maybe it could be useful
to have version matching here as well (so the file could have been excluded
for FE < 2.066).
I think such a thing would be in the scope of "putting as much as possible
informations about the problem in the build tool", @s-ludwig ?
Mathias LANG
Epitech 2015
2015-03-17 17:18 GMT+01:00 Nick Sabalausky<EMAIL_ADDRESS>
Projects may rely on RDMD's behavior of not compiling files that aren't
imported (and I don't think it's DUB's place to prohibit this), but then
that causes problems when the project is built with DUB. For example:
Abscissa/DAuth#1 https://github.com/Abscissa/DAuth/issues/1
It'd be helpful to have an option in dub.json to allow a project to force
itself to be compiled with RDMD.
—
Reply to this email directly or view it on GitHub
https://github.com/D-Programming-Language/dub/issues/529.

The fact that particular issue just happened to be a warning is irrelevant. It could just as easily have been any actual error. Bottom line, a package manager should NOT be getting in the way of something basic and already built-in like static if(whatever) { import someModuleNotIntendedForEverySingleBuild; }
Working around this by adding things like "FE < 2.066" to the dub.json ONLY creates unnecessary redundant work for project authors. It's the wrong way around. D already supports this stuff out-of-the-box. Expecting authors to recreate the logic in a dub.json file in order to prevent an already-available feature from breaking is completely unnecessary.

Working around this by adding things like "FE < 2.066" to the dub.json
ONLY creates unnecessary redundant work for project authors. It's the wrong
way around. D already supports this stuff out-of-the-box. Expecting
authors to recreate the logic in a dub.json file in order to prevent an
already-available feature from breaking is completely unnecessary.

I can hear that argument (though D doesn't support it, a tool build on top
of a specific compiler does). However, providing a way for user to force
RDMD doesn't sound like the right solution to me.
Firstly because it doesn't scale / play well with the environment (dub-ly
speaking). If the user forced rdmd but I'm X compiling for my Raspi, there
is no way for me to use that library, but to go and fix it. And if we can
force RDMD, why not force DMD / GDC / AnyDC ? That would just lead to a
more scattered ecosystem, defeating the purpose of the build tool.
Another concern, which is specific to RDMD, is that it could introduce
bugs. You may have modules in your library that are independants from each
other. You don't want them to be excluded from your library. The worst part
being that your files are not even syntax checked, and you user only
discovers it by the time he tries to use the module.
rdmd is a great tool for some circonstances, having the possibility to
force it into the package file is just working around another problem.

However, providing a way for user to force RDMD doesn't sound like the right solution to me.

For now, I'd settle for a way to tell DUB to only compile the files actually imported by the compiler.
But I think you're misunderstanding some things here.

RDMD is not specific to DMD only. See RDMD's "--compiler=" option, as well as gdmd and ldmd (Granted I'm not familiar with the current state of gdmd/ldmd, but if by any chance they've bitrotted, then that's a separate issue that must be addressed somehow anyway. RDMD is specifically intended to be usable with more than just DMD. If there are issues preventing people from doing so, then those issues must be addressed).

For a library, choice of buildsystem is ONLY relevant to that library's author. It has NO implications to either the package management tool NOR to the library's user. If it ever does affect to the library's user or the package management tool in any way, then something has already gone very, very wrong with the design of the whole system.

When it comes to building, a library user needs exactly two things:
A: A one-line command to build the library.
B: A similarly simple way to obtain the source import path(s) and lib import path(s) for the lib.
Part "A" is provided by the library to the package management tool via the package configuration file (in our case, "dub.json"). Then, parts "A" and "B" can both be provided by the package management tool to the library's user in a consistent, standardized manner. (DUB completely fails at "B" right now, but I concede that's partly my fault, since I've been the biggest proponent of it and still haven't produced an actual pull request) THAT is the only role a package management tool plays in the actual build process (as opposed to a package management tool's non-build-related duties such as downloading, hosting a list of repos, etc).
If the package management tool also wants to provide a built-in buildsystem as well, then fine, as long as it doesn't interfere with packages that are only interested in the package management functionality. But DUB is failing at that: As author and maintainer of several libraries, I currently cannot offer package management support via DUB without also being FORCED to support DUB-based building as well for every single library user that chooses to make THEIR project build via DUB. So do you see now how it's the current DUB that is forcing things and not playing nice with the environment, and NOT this proposal?
I've been very seriously considering just setting up all my project's dub.json files to exclude ALL source files, and use either a custom pre-build or post-build step to invoke whatever buildscript I damn well choose. The only reason I haven't already is that, in the past, there had always been other limitations preventing me from doing so. It may be time to revisit that; hopefully it's become feasible now.

If the user forced rdmd but I'm X compiling for my Raspi, there is no way for me to use that library, but to go and fix it.

No. Absolutely NOTHING is forcing anything of the user whatsoever. This is a setting for a library to force ITSELF to be built with RDMD rather than blindly passing all files directly to the compiler itself. This is not a setting for a library to force everything which imports the library to use RDMD, that would be silly.

And if we can force RDMD, why not force DMD / GDC / AnyDC?

Slippery slope fallacy. I'm not suggesting a setting to force the compiler, only the buildsystem. So the question is irrelevant speculation here. Any idea of forcing a compiler would be a completely separate matter.

You may have modules in your library that are independants from each other. You don't want them to be excluded from your library. The worst part being that your files are not even syntax checked, and you user only discovers it by the time he tries to use the module.

Completely irrelevant. The relative merits of different build approaches have nothing to do with this. As explained above, that's for the library author to decide, it need not have any impact on anyone else.

rdmd is a great tool for some circonstances, having the possibility to force it into the package file is just working around another problem.

I can already force ANY tool or lib to be a forcefully required by my library. That's kinda the whole point of a package manager, innit? ;)

The problem with the library forcing a particular build mode is that it virally affects any direct or indirect dependencies in the sense that now rdmd is part of the build process. For example, the force-rdmd option would basically breakdub generate visuald and similar things. This is especially problematic since indirect dependencies may not be under control of the package author.
IMO, the only really sane way to introduce this option is to extend DUB to always behave like that, meaning that in case of dub generate visuald it would create a snapshot of the current dependencies and puts that in the VisualD project file. This would of course be inconvenient and error prone, since it would require to rerun the generation for any source code change that changes dependencies, but it would enable some neat use cases and would still work universally for all projects.
What might be interesting to know is that DUB initially only supported building using rdmd. This is also the reason why vibe.d could have it's static this magic with an automatic main() function - and it's an annoying ongoing process to switch to a version based manual selection between custom and default main function. Only later it became clear that some more knowledge is necessary in the build file to support various other use cases where rdmd was not an option.
I think that we really should cast a vote or something to get a community consensus on which is the right way to go - stupid build system or rdmd-like dependency tracking system - and then go with that exclusively. Everything else will AFAICS just lead to fragmentation of the eco system. If we had such a direction then the authors of IDEs and other build tools would probably also follow suit, so that the dub generate issues might completely vanish.
BTW, I still think that what rdmd does today should really be integrated into DMD (and any D compiler for that matter) directly. It would be more efficient and we would simply have no reason to even think about other approaches in DUB.

How could we reliably use rdmd to build a library without it's dependencies, so that we can still maintain a performance caching granularity? There is an exclude switch, but we'd need to pass it all modules that don't belong to the current library.

Hmm. Ok, couple thoughts:

Ignoring for the moment the issue of RDMD trying to compile a lib's dependencies along with the lib itself: In the case of a lib that expects to be built via RDMD (or something like it), wouldn't the appropriate dub generate [some big ide like visual studio] behavior be to set up either a custom tool (as supported by just about any decent ide or editor) or pre-/post-build step to invoke rdmd (or dub itself) and then still just blindly toss all the sources into the project as usual and tell the IDE to exclude them all from the IDE-built-in build? Sounds perfectly reasonable to me.

What doesn't sound reasonable is to expect all projects to support and be built around the limitations of any and all random buildsystems that some OTHER package might choose to use. That makes the ecosystem a freaking PITA mess, and there's no reason it should ever be needed anyway. It's a package management tool's JOB to be the intermediary between packages (and often by being the tool that actually triggers the builds, via whatever method each package has told the package manager "this is how you build me"). Packages have no business mucking around with safe interoperating with each other's builds when there's a package manager involved. That's what the package manager's for.
OR, perhaps there's just no need for supporting dub generate visuald on projects that use a buildsystem that Visual Studio just simply cannot handle. BUT projects depending on such a lib can always still support dub generate visuald because DUB can just setup rdmd [whatever the dependency is] as a pre-build step.
 If we're in the situation where projects DO need to be designed around the limitations of all possible buildsystems, then I think that's clearly indicative that there's some other problem going on, because that REALLY shouldn't be necessary at all.

Back to RDMD's viral nature: First off all, I don't think RDMD "infects" upstream projects (ie, the project using a lib that expects to be built with RDMD). If it does, then that sounds like a DMD/RDMD bug. As for infecting the dependencies of a lib that requires RDMD: doesn't DUB already have all the information necessary to solve the "viral" problem by passing all appropriate --exclude= switches to RDMD? If not, then a "--comple-ONLY-these-ones=" could (and should) just be added to RDMD.

(BTW, that second "1."  :/)

A somewhat standardized build system is necessary to enable package sharing. If people started to use arbitrary scons, WAF, cmake, or autotool build systems then we could just bury the packages repository.
Being able to build most packages with a plain DMD installation is also key to make services like Travis-CI work.
Now rdmd is a tool that is distributed with DMD (and should really replace DMD -run), so we could use it for an autodeps build. In fact dub might just track file dependencies itself using DMD. We also have the mainSourceFilein dub.json which could serve as entry point.
    "autoSources": true

My main concern here is that doing this properly is a lot of effort. E.g. compiling with rdmd takes currently twice as long, as you already noticed a whitelist is missing. All of that just so you don't have to specify an excludeSource or put a version (FooOnly) on top of the files.

If people started to use arbitrary scons, WAF, cmake, or autotool build systems then we could just bury the packages repository.

No, I don't see how that's the case at all. As with ANYTHING else, it's just a matter of your project having dependencies, and the dependencies being available through DUB.
Obviously there would need to be a way to get such tools through DUB (either through a local non-systemwide installation or maybe integration with OS-provided package managers, or just however the hell it's decided to be done - but this IS ALREADY a known need that DUB has anyway, I'm pretty sure there's even a ticket for it on github). So people either use a tool that's already available with DUB or they make a DUB package for what they want (RDMD is already available for any DMD users. If it isn't already available for GDC/LDC then we just need to add RDMD to the DUB repo if it isn't already there.)
So no, I don't see any problem here. But here's the problem I DO see: If packages can't choose their own build dependencies and required tools, THEN we truly could "just bury the packages repository."

My main concern here is that doing this properly is a lot of effort.

Bleh, no need to bother. Dub ALREADY supports building with RDMD (well, bugs aside). All that's needed is to expose it to dub.json (instead of CLI-only as it is now), and then, if necessary, toss in some appropriate  "-exclude=" args in the call DUB already makes to RDMD. Sure, DUB could just do it itself bypassing RDMD, but if it IS such a bother, then well, RDMD already exists and is already supported by DUB.

All of that just so you don't have to specify an excludeSource or put a version (FooOnly) on top of the files.

No, that only works in trivial cases. I've hit too damn many cases that CANNOT be solved so trivially JUST trying to make a library support more than one version of more than one compiler. Don't forget: D doesn't compile strictly top-to-bottom. As soon as you start getting into anything more complex than version(Foo) (and again, I've hit such cases plenty) then the whole freaking module starts getting processed and analysed long before your logic at the top of the file has a change to tell the compiler "NO!! STOP!! NOT THIS MODULE!!"

E.g. compiling with rdmd takes currently twice as long, as you already noticed a whitelist is missing.

That's obviously not an issue for all packages, especially considering D compilation speed. Projects can decide for themselves what is or isn't appropriate in their own specific case. DUB has NO freaking business making unilateral decisions like that AND no technical need to anyway! Oh, right, but it IS ok to cause ACTUAL problems for others as long as it's for the sake of letting some  people force every freaking project in the repo into the Visual Studio model. But facing completely imaginary problems for the sake of non-IDE buildsystems, oh well that's just not acceptable.
 If that screws up the ecosystem too terribly then DUB can start deciding it's actually worth playing nice with other tools besides Visual Studio.

Reducing the number of capitals helps to keep the discussion focused.

then the whole freaking module starts getting processed and analysed long before your logic at the top of the file has a change to tell the compiler

Conditional compilation at module scope has to work, otherwise please file a bug report. Rdmd also operates at file granularity, so it can't do more than skipping unused imports, but comes with it's own shortcomings, see below.
You can already add/exclude sources conditionally.
"sourceFiles-windows-x86_64-dmd" : ["win_x86_64_dmd/*.d"]
"excludedSourceFiles-ldc": ["source/*_{dmd,gdc}.d"]

If you combine that with conditional compilation at the top of the module, you can achieve what you need.
static if (__VERSION__ < 2066):

While dub isn't finished and we definitely want better support for custom build tools, we need to carefully chose solutions that are scalable to a complete ecosystem.
Ultimatively rdmd's build model is flawed, it takes longer to compile and it doesn't support shared libraries which have multiple entry points. Also there are some hard to solve inherent issues #7016, #12797, #9948.
The only build model of dmd that reasonably works is compiling sources to a library or executable.
Single file compilation heavily increases compile times and generating multiple object files has been broken ever since.
There has been some work on supporting recursive compilation in dmd itself. That would solve most issues of rdmd but is pretty hard to implement in the compiler and still required an explicit list of modules with entry points for shared libraries.
And finally we can't spent a man year of work on one issue unless we get a lot more developers on board.

Conditional compilation at module scope has to work, otherwise please file a bug report.

I did, three years ago: #7386, #8429. Note Walter's pessimism regarding comment in the second one. But those are merely two examples of a larger issue:
Like I was explaining before, the problem is that module-level scope isn't really defined to be evaluated in any particular order. I speak from experience when I say that leads to unavoidable problems with things being evaluated in a different order than you want, which in turn leads to "stick a version or static if at the top" not always being viable beyond trivial cases. Conditional importing OTOH, gets around all of that by operating at a module-sized granularity.

static if (__VERSION__ < 2066):

Note that __VERSION__ is vendor-specific:
https://github.com/D-Programming-Language/phobos/blob/master/std/compiler.d#L48

You can already add/exclude sources conditionally.
"sourceFiles-windows-x86_64-dmd" : ["win_x86_64_dmd/*.d"]
"excludedSourceFiles-ldc": ["source/*_{dmd,gdc}.d"]

You already know that's considerably more limited that what I'm talking about. Plus, it's redundant logic. Didn't I already cover all of this? (It's possible it may have been in a different ticket though).

And finally we can't spent a man year of work on one issue unless we get a lot more developers on board.

"Man-year of work" is an enormous exaggeration, to the point of hyperbole.


Deprecate auroras TTFZ.apparent_resistivity method - use mt_metadata.TF instead

This is not trivial because many tests use the TTFZ for validation.

[ ] Along the way, we should simplify the way that metadata is passed to the TF object.  Will create a branch to attempt to pack the survey_metadata into the KernelDataset, during initialize_dataframe_for_processing.

Apparent resistivity does not exist in mt_metadata.  The aurora method should move to sandbox until we are integrated with MTPy


[release-v3.20] Auto pick #4868: Version dropdown and searchbox adjustments for OSS

Cherry pick of #4868 on release-v3.20.
#4868: Version dropdown and searchbox adjustments for OSS

Spotted a problem closing this one


Wingtips-to-vendor span lifecycle listeners should not report unsampleable spans

Codecov Report

Merging #122 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master     #122   +/-   ##
=========================================
  Coverage     98.89%   98.90%
- Complexity     1292     1296    +4
=========================================
  Files            74       74
  Lines          3089     3095    +6
  Branches        422      422
=========================================
+ Hits           3055     3061    +6
  Misses           19       19
  Partials         15       15

Impacted Files
Coverage Δ
Complexity Δ

...ightstep/WingtipsToLightStepLifecycleListener.java
93.71% <100.00%> (+0.12%)
65.00 <10.00> (+2.00)

...ips/zipkin2/WingtipsToZipkinLifecycleListener.java
96.96% <100.00%> (+0.30%)
10.00 <3.00> (+2.00)

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 3102c34...e029598. Read the comment docs.


Initial nix development environment. Use Nix for OSX CI instead of homebrew.

This introduces a shell.nix file to be used with nix-shell to set up a complete development environment for Crystal.
This also changes the GitHub Darwin CI to use Nix instead of homebrew. This will allow more stable CI for PR and commits. Checking if things are fine with homebrew can be done in something decoupled of the CI of Crystal itself.
The shell.nix is working on Darwin and Linux 64 gnu bits already. The musl support in nix is not completely flawless it seems. And the support for 32 bits should not be far also. Yet, the shell.nix already has all the pieces there.
In the future, things could evolve a bit and we could stop needed docker -build images for the CI, or at least stop needing to create new images of every release. Yet there is value already to have more stable Darwin builds.
Another bonus of using Nix is the abiliity to check against different llvm version easily.
Since this is the first non-trivial Nix file I am writing, I am probably doing something wrong.
cc: Crystal ∩ Nix = { @manveru, @peterhoeg, @david50407, @KimBurgess, @Infinisil } in case any of you want to take a look.

This makes me inexpressibly happy.
shell.nix functions as advertised under NixOS. There’s some competing ideologies around how that nixpkgs reference should be declared (pass in as arg w/ default vs pinning as you’re doing currently), but the current approach works.
Given this project is just spinning up with Nix, it may be worth keeping an eye on Flakes. It’s still experimental, but may provide a clean pattern to define the dev env for crystal itself, but also ensure the output of this is packaged neatly for consumption by downstream users. There’s a nice intro to it here: https://www.tweag.io/blog/2020-05-25-flakes/.
I’m yet to play with it, but if there’s interest more than happy to have crystal as the focus of that play.

Thanks @KimBurgess I considered pinninig or using niv (or flakes), but for now a single file was enough to keep the complexity small enough.
I think having more files and structure will make sense if we replace how we build the .tar.gz in distribution-scripts. In Linux, we use multi stage docker images to build the compiler with musl so it can be used in alpine and other Linux distros. In Darwin, we use omnibus. In that case, having nix expressions for each dependency will make sense. So yeah, niv and flakes are on my reading list to attempt that :-)
The only controversial package is the GC since 8.0.4 does not have yet the patch needed for fibers in mt. Since it should be a matter of time, I preferred to extract it from the previous .tar.gz
Do you have experience in nix + musl to iterate why $ nix-shell --pure --arg musl true fails with some missing symbols?

The libgc.a that you’re yanking out of the crystal tarball looks to be responsible for those errors. To work around this (and neaten up that dependency) you can use an override point the existing boehmgcexpression to a more recent commit until there’s a new release published:
boehmgc = pkgs.boehmgc.overrideAttrs (oldAttrs: rec {
  version = "fbcdf44c4cbe1eadec9ee4e6ba2c389e72bca155";

  src = builtins.fetchGit {
    url = "https://www.github.com/ivmai/bdwgc.git";
    rev = version;
  };

  preConfigure = ''
    ${oldAttrs.preConfigure}
    ./autogen.sh
  '';

  nativeBuildInputs = oldAttrs.nativeBuildInputs ++ [ pkgs.autoreconfHook ];
});

This can then be added to the buildInputs for the expression that launches this shell.

Right @KimBurgess , I forget the bundled gc only works on debian 🤦 . The current alpine ci runs with a gc without the mt patch. Cool, that will help on the alpine story probably. Now I need to figure how to effectively use nix on alpine and 32 bits to be able to get rid of docker images on the ci... for now I will tweak this nix file to make it work on musl using upstream. Thanks!


Edits are being lost when a second logged-in user happens to be "just looking" at the page

There is an algorithm to detect when content has changed in the browser; content is only supposed to be saved if it is actually different from what was originally loaded.
This algorithm doesn't quite work in all cases. Sometimes it keeps detecting false positives, which generated zillions of page versions. In a bid to resolve this permanently, I added server-side logic to check whether the page has actually changed.
However, this doesn't solve the problem if user "A" is really editing and user "B" is just looking at the page.
User "B"'s area editor keeps trying to submit edits even though user "B" has done nothing. The server detects that these are real differences because user "A" has made changes. User "B" stomps user "A" even though they were never really editing. So sad.
(One variation of this sob story: user "A" might be trying to roll back page versions, and perceive that feature as broken because user "B"'s area editor keeps overruling them.)
One solution is to perfect the difference-detection algorithm in the browser. However we can also address the problem by not starting the "periodic area-saver" logic until user "B" actually touches the editing UI in some way, and resetting that flag after a save operation. This would be very good insurance against problems with the difference detection, and also make Apostrophe more efficient. A catch with that is being 100% sure we don't miss that some kind of contextual editing operation has occurred.
(Another option in principle is to introduce save buttons for areas and/or a hard switch between view and edit modes, with view mode being the default every time you open a page. I don't think we want to do that, it really cuts down on the contextual wow factor.)
More verification should be done that this is the root cause of certain issues impacting PL and other projects.
cc @agilbert @stuartromanek

Is this issue officially solved with the 'take control' features?

Absolutely, and more specifically with the change to not even start trying to autosave areas until certain interactions take place.


/about/guidelines Broken Contributing guideline example link

Hi All,
Thanks for all of your work maintaining various Django packages.
FYI I was reading your guidelines page, I found a broken link.
https://jazzband.co/about/guidelines says:
"See this website’s contributing guideline for how it’d look like. Feel free to add a similar paragraph to your README file."
"contributing guideline" links here, but that link is broken.
https://github.com/jazzband/website/blob/master/CONTRIBUTING.md
I just wanted to let you know in case you wanted to update the link or change the text.
Thanks,
Collin

Good catch, thanks @collinanderson!


Refs #15727 -- Added support for Content-Security-Policy (CSP) to SecurityMiddleware.

Added support for Content Security Policy(CSP) to SecurityMiddleware. It is still a WIP and I haven't added system checks yet. Please provide suggestions. 😄

Hello @Anv3sh. Thank you for this work, below a couple of very high level questions:
1- Did you base your proposal on django-csp? If yes, what parts did you bring up here and why?
2- What kind of (manual?) testing you performed over the proposed code?
3- What's your plan regarding unit tests and documentation?
Thanks!

@adamchainz @ubernostrum Since you were listed as possible GSoC mentors for this feature, I was wondering if you were interested in taking a look at this proposal. Thanks!

Hey @nessita thanks for the quick reply.The proposed changes are based on my GSOC'23 proposal. As for the manual testing I tested it on a sample project where it worked fine.

I would prefer to see a separate CSP middleware. CSP is quite complicated and it would be best to separate the implementation from the other security features.
I think the two setting design, with SECURE_CSP and SECURE_CSP_MULTIPLE, is quite user unfriendly.
I would prefer an approach where we base the design on what's working in django-csp, but try to make it match Django's existing settings more closely. Something like the Clickjacking Protection ( https://docs.djangoproject.com/en/4.2/ref/clickjacking/ ) is what I imagined: a standalone feature with its own middleware, settings, and documentation page.
Another thing I'd like is the ability to specify separate Content-Security-Policy and Content-Security-Policy-Report-Only headers. The idea is that you can test out a new iteration of your security settings by configuring the report-only variant, whilst leaving the existing version deployed in the main header.

I would prefer to see a separate CSP middleware. CSP is quite complicated and it would be best to separate the implementation from the other security features.
I think the two setting design, with SECURE_CSP and SECURE_CSP_MULTIPLE, is quite user unfriendly.
I would prefer an approach where we base the design on what's working in django-csp, but try to make it match Django's existing settings more closely. Something like the Clickjacking Protection ( https://docs.djangoproject.com/en/4.2/ref/clickjacking/ ) is what I imagined: a standalone feature with its own middleware, settings, and documentation page.
Another thing I'd like is the ability to specify separate Content-Security-Policy and Content-Security-Policy-Report-Only headers. The idea is that you can test out a new iteration of your security settings by configuring the report-only variant, whilst leaving the existing version deployed in the main header.

I agree with the provision to have a separate middleware for CSP because of how vastly complicated it is, I went with the current implementation as there were suggestions by Tim Graham and Florian Apolloner.


Fix Issue #5 -- Code is now PEP 396 compliant

__version__ now returns a version string instead of a tuple. Added __version_info__ which returns a version tuple.

This would be an API break, and its just not important enough to do that IMO.


Fix type-limits warning in windows_utils

Info
This fix allows Godot to be compiled for platform=windows dev_mode=true with x86_64-w64-mingw32-g++

scons platform=windows target=editor dev_build=true dev_mode=true

Using MinGW, arch x86_64
Building for platform "windows", architecture "x86_64", target "editor".
NOTE: Developer build, with debug optimization level and debug symbols (unless overridden).

Tested with x86_64-w64-mingw32-g++ (GCC) 13-posix on WSL2 (Win10) + Ubuntu 24.04
Before
In file included from ./core/string/char_utils.h:34,
                 from ./core/string/ustring.h:36,
                 from platform/windows/windows_utils.h:36,
                 from platform/windows/windows_utils.cpp:31:
platform/windows/windows_utils.cpp: In static member function 'static Error WindowsUtils::copy_and_rename_pdb(const String&)':
./core/error/error_macros.h:168:32: error: comparison of unsigned expression in '< 0' is always false [-Werror=type-limits]
  168 |         if (unlikely((m_index) < 0 || (m_index) >= (m_size))) {                                                            \
      |                      ~~~~~~~~~~^~~
./core/typedefs.h:277:41: note: in definition of macro 'unlikely'
  277 | #define unlikely(x) __builtin_expect(!!(x), 0)
      |                                         ^
platform/windows/windows_utils.cpp:223:17: note: in expansion of macro 'ERR_FAIL_INDEX_V_MSG'
  223 |                 ERR_FAIL_INDEX_V_MSG(pdb_info.address + original_path_size, file->get_length(), FAILED, vformat("Failed to write a new PDB path. Probably '%s' has been changed.", p_dll_path));
      |                 ^~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
scons: *** [platform/windows/windows_utils.windows.editor.dev.x86_64.o] Error 1

Notes
I see @Repiteo has this fix in his PR, but it's part of a larger commit and so far in Draft mode, so I thought at least this would go through because it's the only thing that breaks compilation.

Thanks!


activejdbc cannot find activejdbc_models.properties

ActiveJDBC Version: 2.2
Other tested ActiveJDBC Versions: 2.0, 2.1
JDK: 1.8
Build Platform: Maven
pom.xml: https://paste.ubuntu.com/p/697hwfyW8P/
Error Producing Code: https://paste.ubuntu.com/p/TtcSBxwspS/
Inside the jar: http://prntscr.com/m4xzkm

@creatorfromhell I'm a little confused. You said that the results of Util.readResource pulled in another plugin's properties file, but removing the other plugin allows your code to work properly. Are you still using Util.readResource() to somehow load the file? Or is it just working out of the box now?
Also, you initially said that the other project was loaded as a dependency of yours, but then it sounds like you were saying it is a different plugin which has nothing to do with yours. So, I'm just wondering which it is. How are these plugins being added to the program? How was this other conflicting dependency initially defined and then removed?

@creatorfromhell I'm a little confused. You said that the results of Util.readResource pulled in another plugin's properties file, but removing the other plugin allows your code to work properly. Are you still using Util.readResource() to somehow load the file? Or is it just working out of the box now?
Also, you initially said that the other project was loaded as a dependency of yours, but then it sounds like you were saying it is a different plugin which has nothing to do with yours. So, I'm just wondering which it is. How are these plugins being added to the program? How was this other conflicting dependency initially defined and then removed?

I don't recall stating the other project was loaded as a dependency of mine... But to outline the above:

If multiple plugins of the software use ActiveJDBC, they will only get one of the activejdbc_models.properties files as it somehow, maybe intentionally for plugin-dependency purposes(other ways to do this though)?

As for the rest of your questions:

How are these plugins being added to the program?

They are loaded using a classloader

Are you still using Util.readResource() to somehow load the file? Or is it just working out of the box now?

My current fix is to just not release my plugins as of yet, and hope for a patch to ActiveJDBC to correct this (maybe via allowing a custom file name for the .properties file), or, which hopefully not, I'll have to replace my ActiveJDBC code before releasing my plugins that use ActiveJDBC to prevent the aforementioned issue from happening.

@creatorfromhell I believe this was fixed, closing this issue

Finally got around to testing this and it solves the issue I was experiencing. Cheers.


[folding] Opening a large file freezes VSCode due to folding decorations

large.zip

I limited the maximum of folding regions to 10000. The filtering criteria is the size of the indentation.


Question regarding the business layer

Hi Jon
You mention in your GenericServices milestones, that you removed the Action methods, as to make it all about database access. The business logic should go into a seperate library.
Could you briefly explain how you would recommend structuring the project to use a business layer together with GenericServices?
When I download this app, a root folder BizLayer & a class library exist, but is not included in the solution. Would I add this class library to the solution & input any business processes into there? For example if I have a workflow where the user edits the state of DTO object in the UI, which is persisted in the database, how would you recommend I include this workflow process into the existing solution structure?
Thanks

Hi @riffrack,
I took a little while replying to this because I felt it needed a deeper answer. I have written an article on my blog called Architecture of Business Layer working with Entity Framework. The article pulls together my approach to building and accessing the Business Layer. I hope you find that helpful.
For your example, if you have something that needs to set a state based on some rules then the best place is in the BizLayer. In SampleMvcWebAppComplex Orders have a status and I only used Pending and Shipped. I didn't handle the changing of the status as I didn't want to create a BizLayer just for that.
On your specific questions in SampleMvcWebApp and the BizLayer.

Yes, include BizLayer in the project. Its just a class library.
The BizLayer will need to access the DataLayer. Use the Reference Manager-> Solution
The ServiceLayer, if that is where you add your linking/adpater code, will then need to reference the BizLayer.

Hi @JonPSmith
Thanks for your detailed response & the great article describing your view on the business layer. In your implementation example, do I understand this correctly? The controller would pass the DTO to the business layer for some form of action. In case there is any persistence needed, the biz layer would interact with the service layer & the service layer would handle the interaction with the data layer. The response (message or class) would then be handed back all the way up to the controller.
As you mention for the SampleMvcWebAppComplex(https://github.com/JonPSmith/SampleMvcWebAppComplex) you didn't create a BizLayer for a minor status change. For apps with only very little BizLogic this could all be handled in the ServiceLayer. However in most projects with BizLayer probably will grow during development, as these rule are not always aparent from the start of a project.
Would you therefore initialize the BizLayer during the InitialiseThis method of the ServiceLayerInitialise?

One reason I am unsure about the exact implementation is that the diagram would suggest the business layer interacts directly with the data layer, however in the description about The Business Layer does not do the final data save the business layer would let the service layer do the final save.

Answers:
First para: The BizLayer uses EF to add new database classes, or for updates simple read and then update the data, hence the link to the DataLayer. When the Biz logic hands back to the ServiceLayer method that calls SaveChanges and handles any validation errors that are produced.
Second para: Yep, if you only have a small bit of Biz logic I would put it in the Service layer. However because I have my own GenericAction library I would add a BizLayer for even one piece  of Biz logic.
Third para: The InitiaiseThis, and  BizLayerModule for DI, method is my own way of initialising each layer. See Dependency Injection in Wiki for a bit more on DI initialise.


Test Windows App

Run the Windows App with a Firma Digital and check for errors

Hello, id love to take on this


Protocol Changes

Making the two protocol changes discussed in #112.  This will be helpful when creating custom views.

Now that you can make your custom HUD if you want you can add a page in the wiki with an example. It would be very useful and appreciated

Absolutely!

Thanks very much!


feat(jellyfish-api-core): Asymmetric pool swap fee

What this PR does / why we need it:
https://github.com/DeFiCh/ain/pull/1354
Which issue(s) does this PR fixes?:

Fixes #
Additional comments?:

Conflicts on:
packages/jellyfish-api-core/__tests__/category/masternode/setGov.test.ts

heyy.. question... what's the diff of
[`v0/poolpairs/${ppTokenID}/token_a_fee_pct`]: '0.05'

with
[`v0/poolpairs/${ppTokenID}/token_a_fee_direction`]: 'both'

??

token_a_fee_pct  - token a fee %
token_a_fee_direction - direction the fee applies, in/ out/ both

token_a_fee_pct  - token a fee %
token_a_fee_direction - direction the fee applies, in/ out/ both

hmm.. feels like token_a_fee_pct and token_a_fee_direction are same use case..
btw.. the pr looks good to me


Fixed #32664 -- Allowed running makemigrations without a SECRET_KEY.

Django apps initialization to run management command triggers the admin
autodiscovery. The auth admin imports from django.contrib.auth.forms,
which imports the django.contrib.auth.tokens, instantiating a
PasswordResetTokenGenerator that requires a SECRET_KEY.
For several management commands, the token generator is unused. It
should only complain about a missing SECRET_KEY when it is used.

https://code.djangoproject.com/ticket/32664


[BEAM-6181] Unexpected metrics should be non-fatal.

This unbreaks dataflow streaming on Python.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.


prevent stop tapping from hiding the button

This PR aims to prevent the button from hiding if the user taps the screen to stop a ballistic scroll upwards.
The small offset of 10 will prevent the button from hiding immediately,
in cases where the scroll downwards is minimal.
I did not test how well the value 10 works, and I did not include it in a parameter or a constant.
Those things might need to be considered.

This is a good addition, I'll merge this and expose a parameter for this

Had to use a different variable to keep a track of this otherwise it just stayed visible until the point the user started scrolling upwards.
The new version is up