Add a checks for incorrect note template (prevent it from saving)

Lots of people try to sync with Obsidian but put in an incorrect note template and the sync doesn't work.
So perform to checks to ensure that the sync will always work:

frontmatter is correctly formatted
"id" field is contained within the frontmatter.

When someone makes changes to the note template, AND the lose focus from the text field, THEN the error message comes up below the textfield in red. Telling people that the "id" is not there.
Additional Context
Below is the note template field screenshot, ensure that it is properly formatted.

Closed by #118


Best approach for periodic, but not uniform schedule interval?

I have a DAG I want to run at 10:30am and 3:30pm every day, but I'm not sure what the best way to specify this is in Airflow.  I can't just set the schedule interval on a single DAG, because the interval between jobs is not uniform (alternates between 5 and 19 hours).
Is there an easy way to make a DAG for the 10:30 case, and then duplicate it with a different name and change the start time to 3:30pm?

I'd use a 12 hours schedule_interval anchored on a 00:00 start_date and derive the TimeSensor with your specific logic. Something like:
class CustomTimeSensor(TimeSensor):
    def poke(self, context):
        # pseudocode
        # if the time of context['exectution_date'] is 00:00 and current_time >= 10:30am
        #     return True
        # elif the time of context['exectution_date'] is 12:00 and current_time >= 3:30pm
        #     return True
        # else
        #     return False

Then your processes downstream can just depend on this and should trigger at 10:30 for the morning run and 3:30 for the afternoon one.


Make key-pair directory path argument optional to Lucy

One idea is to group the subcommands for the cloud and abstract environments so that they don't interfere.


Download File Telegram

I can not download file in telegram. The indicator in download icon is finished, however file is not downloaded

Open Telegram via Franz
Open group chat or personal chat
Go to Files in profile
Download file
Wait until download finished, however franz not save the file

Expected behavior, Franz will ask where to save file
Desktop (please complete the following information):

OS: Windows 10
Version 5.7

Additional information, if i directly download file in chat, it will download file and then right click to file to save the file.
It will helpful if we can do this in files in profile if the file is very long time ago

I am closed this issue. If i switched to version Z, i can download directly the file


IntelliJ Platform no longer ships with Apache Commons HttpClient

The plugin uses Apache Commons HttpClient but this is end-of-life and isn't present on the 223 branch of the IntelliJ Platform. A switch to Apache HttpComponents should be made (in preference to bundling the older implementation in the plugin artifact).

Fixed in version 1.10.0


Add fancy css stuff to single page report

right now the multiple hosts report has a text only and a fancy html version.
need to make it so that even a report on just one host works the same way, but then i'll need to rework the way i build the combined report.

pushed to maseter


JavaScript

We are using JIRA instead of GitHub issues to track
our work in order to integrate more effectively with the rest of the Swift
ecosystem.
Before opening a new issue, please search the existing
issues to see if your
issue has already been asked. If it's open, you can Add Vote to request
the issue be prioritized. And you can start watching the issue to receive
updates.
If there are no related issues in JIRA, please file a new ticket by using one
of the links below corresponding to the nature of your issue:

Create a bug
Create a new feature request (Story)
Create a new clean up / internal improvement

I'm sorry, but I don't understand the issue. If you would like to rewrite the boilerplate text to express your concern or question, we can reopen this.


WIP: DO NOT MERGE ES leps  investment project permissions dh 1011

Dependent  on the #633 PR
Not finished

Closing as this will be replaced with a new PR that's been rebased against develop.


fixed 1e100 error

Got the following error a few times:
value cannot be converted to type float without overflow:<PHONE_NUMBER>0000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104.000000
Changing 1e100 to 1e32 seemed to fix it. My guess is that mu.min() is a torch object that overrides > and throws an error when trying to convert 1e100 to float.

Thanks!


Update Bootstrap to 5.2.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.121%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
584

Relevant Lines:
597

💛  - Coveralls


Alex W Pixart

When I did the initial commits, I was not connected to the internet, and so jquery wouldn't load and I couldn't test my script. When I got online, I fixed the changes in a final commit
comfort - 4
complete - 4

👍 Nice Job!


Bioconductor version doesn't match R version

The current bioconductor image seems to have a mismatch between the R version (3.2.0) and Bioconductor (3.0).
I pulled the latest bioconductor image from docker registry and used the following dockerfile to build an image with additional packages installed:
FROM bioconductor/release_core:latest

RUN Rscript -e "BiocInstaller::biocLite('limma')"

The output shows the following warnings:
Bioconductor version 3.0 (BiocInstaller 1.16.4), ?biocLite for help
A new version of Bioconductor is available after installing the most recent
  version of R; see http://bioconductor.org/install
Warning message:
BiocInstaller version 3.0 is too old for R version 3.2.0;
  remove.packages("BiocInstaller") then
  source("http://bioconductor.org/biocLite.R")

The image does build, but the bioconductor version it contains seems out of date (should be 3.1).

This is fixed now, please pull again. Thanks for the report.


[Bug] Fix deassign command error

The wrong error is thrown when
INDEX is 0.
Fix the error to throw the correct
error message when INDEX is 0.
Let's,

Change the error message thrown when
the INDEX of deassign is 0

Codecov Report

Merging #114 (f032a5d) into master (a9b57fe) will decrease coverage by 0.09%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #114      +/-   ##
============================================
- Coverage     60.52%   60.43%   -0.10%
  Complexity      545      545
============================================
  Files           104      104
  Lines          2009     2012       +3
  Branches        232      232
============================================
  Hits           1216     1216
- Misses          721      724       +3
  Partials         72       72

Impacted Files
Coverage Δ

...du/address/logic/parser/DeassignCommandParser.java
64.28% <0.00%> (ø)

.../java/seedu/address/model/util/SampleDataUtil.java
9.67% <0.00%> (-1.04%)
:arrow_down:

Continue to review full report at Codecov.

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


Revert "feat: support modify response when use xhr"

Reverts vvmgev/Inssman#40

Got it. I will fix this issue.


perlPackage.CLIHelpers: init at 1.6

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build perlPackages.CLIHelpers perldevelPackages.CLIHelpers

Can you rerun ofborg? Not sure why it failed. I'm able to build perlPackages.PerlCritic on nixpkgs-unstable.

@GrahamcOfBorg build perlPackages.CLIHelpers perldevelPackages.CLIHelpers

Thanks for the review @stigtsp. Amended and force-pushed. :)

Thanks for catching that. Fixed now.

@invokesus Thx for the contribution!


gofasta snps -> open : no such file or directory

No matter what I do
gofasta snps prints,
open : no such file or directoryv
v0,0.3

Could you provide an example of a command that you did run?
❯ gofasta snps -h
Find snps relative to a reference.

Example usage:
	gofasta snps -r reference.fasta -q alignment.fasta -o snps.csv

The output is a csv-format file with one line per query sequence, and two columns:
'query' and 'SNPs', the second of which is a "|"-delimited list of snps in that query.

If input and output files are not specified, the behaviour is to read the query alignment
from stdin and write the snps file to stdout, e.g. you could do this:
	cat alignment.fasta | gofasta snps -r reference.fasta > snps.csv

Usage:
  gofasta snps [flags]

Flags:
  -h, --help               help for snps
  -o, --outfile string     Output to write (default "stdout")
  -q, --query string       Alignment of sequences to find snps in, in fasta format (default "stdin")
  -r, --reference string   Reference sequence, in fasta format

❯ gofasta snps -r WH04.fa -q small.fasta
query,SNPs
Australia/NT12/2020,C3037T|T8782C|C14408T|C15324T|C20468T|A23403G|C28144T
Australia/NT13/2020,C3037T|T8782C|C14408T|C15324T|C20468T|A23403G|C28144T
Australia/NT14/2020,A2480G|C2558T|A2832G|T8782C|C14805T|C18526T|G26144T|C28144T
Australia/NT16/2020,C3037T|T8782C|C14408T|A23403G|A24862G|C28144T
Australia/NT17/2020,C3037T|T8782C|C14408T|A23403G|A24862G|C28144T

Could you help me? I meet the same problem with you!


NIP-11 request does not use path

Describe the bug
When checking a relay that provides the data at a non-root path (e.g. wss://ftp.halifax.rwth-aachen.de/nostr), the NIP-11 check fails. It seems the root URL (https://ftp.halifax.rwth-aachen.de/) is used instead of the correct URL (https://ftp.halifax.rwth-aachen.de/nostr).
To Reproduce
Go to https://nostr.watch/relay/ftp.halifax.rwth-aachen.de/nostr
Expected behavior
NIP-11 info document should be OK.

Good catch, easy patch.

Hit some bumps when updating the package in the app, will reattempt today.

Fixed: https://deploy-preview-647--nostrwatch.netlify.app/relay/ftp.halifax.rwth-aachen.de/nostr
Deploying, will be on production in ~5 minutes.


Docker file is added

Related Issue
Closes #538
Proposed Changes

I have successfully added docker file

Additional Info

Any additional information or context

Checklist

[x] ✅ My code follows the code style of this project.
[x] 📝 My change requires a change to the documentation.
[x] 🎀 I have updated the documentation accordingly.
[x] 🌟 ed the repo

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Output Screenshots

Screenshot #1
Screenshot #2

Title goes here
Title goes here

Image goes here
Image goes here

@agamjotsingh18 Will you please review my pr

Please fetch the latest code


Add modal to compare weapons in generated builds in the optimize tab and disable individual swapping/locations

Describe your changes

Added CompareWeaponModal to BuildDisplayItem.tsx that functions identically to the existing CompareArtifactModal
Removed the ability to swap artifacts from CompareArtifactModal
Disabled the location dropdowns for both comparison modals

Issue or discord link

Resolves #1591
Addresses first item in #1616
https://discord.com/channels/785153694478893126/1200154094476734556/1214119792999403591

Testing/validation
Comparison weapon matches optimized weapon

Comparison weapon does not match optimized weapon

Modified artifact comparison

Checklist before requesting a review (leave this PR as draft if any part of this list is not done.)

[x] I have commented my code in hard-to understand areas.
[x] I have made corresponding changes to README or wiki.
[x] For front-end changes, I have updated the corresponding English translations.
[x] I have run yarn run mini-ci locally to validate format and lint.
[x] If I have added a new library or app, I have updated the deployment scripts to ignore changes as needed

Looks like the revert I did after accidentally merging in master when I meant to update my own master branch undid those changes. Should be fixed now.

Fixed, I've manually checked it locally but can add validation images/recordings later.
Looks like this bug was already present in top of tree master so I've also added the fix to the PR description

LGTM, thanks for addressing the fix as well.


Dispaly links as list

this fixes #6449

@bashimoha looks like there are ton of conflicts, can you please resolve them?

Please revert the master change back to main, I pointed to some of the places that had this issue but it looks like all links need to be revisited.
sorry I am having trouble understanding "revert the master change back to main" do you mean I should change the word from master to main? if so then the URL is changing itself  to main when I paste the link to the url bar

if so then the URL is changing itself to main when I paste the link to the url bar

Yes, but why do you want to rely on this behavior? why changing the word main to master again? we removed the word master for a reason so we do not want to see it again in our READMEs. Thanks.

if so then the URL is changing itself to main when I paste the link to the url bar

Yes, but why do you want to rely on this behavior? why changing the word main to master again? we removed the word master for a reason so we do not want to see it again in our READMEs. Thanks.

I see what you mean. I didn't have idea that I changed it, maybe when I was trying to resolve the conflict? I will try to change it the way it was.

if so then the URL is changing itself to main when I paste the link to the url bar

Yes, but why do you want to rely on this behavior? why changing the word main to master again? we removed the word master for a reason so we do not want to see it again in our READMEs. Thanks.

I try to changed it to the way it was, are those okay?

@bashimoha Thanks! I merged the PR.


Star dashboard

I still think its not very intuitive to have dashboardItems inside the dashboards prop. But I'm not going to demand it.
Could you add a good title to the PR, suffixed with DHIS2-3299 so that the PR is linked to the jira issue?
In the description, could you go into a little detail about what has been done, including the purpose of the styling change to the spacer item?

Would PageContainerTopMargin be a more explanatory component name than PageContainerSpacer?


Implement stack using array

Hello! I would like to work on this using Java under GSSoC'21. Could you please assign it to me? Thanks.

Please assign me this under GSSOC'21.

Please assign this issue to me.


Odd intermittent CI build failures

Periodically having CI runs fail with errors like:
  Failed SerilogTracing.Tests.ActivityListenerConfigurationTests.TracingConfigurationMethodsAreCallable [33 ms]
  Error Message:
   System.MissingMethodException : Method not found: SerilogTracing.ActivityListenerConfiguration SerilogTracing.Configuration.ActivityListenerSamplingConfiguration.Using(System.Diagnostics.SampleActivity`1<System.Diagnostics.ActivityContext>)
  Stack Trace:
    at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
  at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in <d636f104d58046fd9b195699bcb1a744>:0

MissingMethodException is unusual to see in this kind of context; may be a build/test concurrency issue?
https://github.com/serilog-tracing/serilog-tracing/actions/runs/8164097507

This seems to have resolved itself.


EAA KBC: Remove hardcode 'tdx' field

The rats-tls relied on by EAA KBC adds the function of automatic detection platform and selecting appropriate attester (rats-tls PR#1452: https://github.com/alibaba/inclavare-containers/pull/1452 ）Therefore, we no longer need to hard code the parameter ‘tdx’ attester in EAA KBC.

@fitzthum  Right now, RATS_TLS supports  sgx_la, sgx_ecdsa, tdx_ecdsa three types of attesters. Please see the link for detail. In addition, SEV(-ES) attester will be supported as soon as possible.


Refactor sample test files & driver

Sample json, csv, tsv, xml files in (/test)
Preliminary test driver (/test.py)

Done in #10


Added more benchmarks and moved them to their own directory

Current coverage is 100.00%

Merging #6 into master will not affect coverage as of 2c39df1

@@            master      #6   diff @@
======================================
  Files            2       2
  Stmts           68      68
  Branches         0       0
  Methods          0       0
======================================
  Hit             68      68
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of 2c39df1

Powered by Codecov. Updated on successful CI builds.


Replace skype by Teams?

the graphic shows skype as proposed service to integrate with dynamics, shouldnt it be replaced by teams ?

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

ID: fe101898-1e9c-e55c-5dd8-58345be38232
Version Independent ID: 604928b2-9fe0-486f-7622-76ef818866f0
Content: Add Microsoft 365 Online services - Power Platform
Content Source: power-platform/admin/add-office-365-online-services.md
Service: power-platform
Sub-service: admin
GitHub Login: @jimholtz
Microsoft Alias: jimholtz

@jeffangama
Thanks for the suggestion. This change will go live today.


Exclude failed tests for jdk_security3

Exclude failed tests for jdk_security3
Related Issue: https://github.com/adoptium/aqa-tests/issues/2123 https://github.com/eclipse-openj9/openj9/issues/15106

Signed-off-by Longyu Zhang<EMAIL_ADDRESS>

https://github.com/eclipse-openj9/openj9/issues/15106 is closed. Should we link to https://github.com/adoptium/aqa-tests/issues/2123 in the problem list?

https://github.com/eclipse-openj9/openj9/issues/15106 is closed. Should we link to https://github.com/adoptium/aqa-tests/issues/2123 in the problem list?

@llxia The links have been updated in problem list. Thanks.


Let jQuery serialize form data

This change addresses a bug in which interesting values for secret for
instance can cause serialization failures. In my case, my application
secret contained an ampersand, &. Which caused the form to fail to
correctly encode the value resulting in errors.
Rather than just wrapping client_secret in encodeURIComponent, I opted
to migrate all the parameters to a simple object and let jQuery handle
it.

I tested these updates with the OIDC Authorization Code Flow and AWS Cognito. It worked.


Why is file size so big?

I'm using RxJS6 in Undux, via typed-rx-emitter. I use it by importing Observable, and calling Observable.create. I don't use any other Rx methods.
Bundling Undux (+typed-rx-emitter, +rxjs) in as part of undux-todomvc, I see all sorts of things included in the bundle that I'm not using. Eg:

CombineLatestOperator
MergeMapOperator
MapOperator
RaceOperator
ZipOperator
AsyncSubject
BehaviorSubject
Subject
ReplayEvent
AsapScheduler
VirtualTimeScheduler
ForkJoinSubscriber
ZipBufferIterator

All in all, that's ~80kb (unmangled). Even after running the code through Uglify's tree shaker, these are included. Are they core parts of Rx.Observable.create? Is there a way to remove them? Am I doing something wrong when bundling?
 It's compiled away by TSC before it reaches Webpack. Confirmed by avoiding the wildcard import.

if it's v6 follow guide for optimization

Those instructions only cover operators and don't talk about Observable.create. No change in file size (code).

You have incorrect understanding of subpath import.
import {Observable} from 'rxjs';

is nothing more than
import * as rx from 'rxjs';
const ({Observable} = rx);

ends up importing all surface as same as before.
Try create simple test.ts as below
import { Observable } from 'rxjs';

console.log(Observable);

and transpile it: you'll get
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var rxjs_1 = require("rxjs");
console.log(rxjs_1.Observable);
//# sourceMappingURL=index.js.map

CJS will import whole rxjs still.
contray, if you import subpath
import { Observable } from 'rxjs/Observable';

console.log(Observable);

transpiliation limits import path
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var Observable_1 = require("rxjs/Observable");
console.log(Observable_1.Observable);
//# sourceMappingURL=index.js.map

in short, impot path is bit different between v5 and v6, but do not import everything is key.

No, I'm only importing the type. It's compiled away by TSC

also, this is very true and if you only use types, it should have zero actual codes. But also, you have specified package as peerdep - how do you actually confirm it's type only, especially you mentioned you do call Observable.create? it's runtime call, so there must be imported code somewhere.

@kwonoj import {Observable} from 'rxjs/Observable' doesn't seem to point to anything with RxJS6. Also, it seems to be at odds with the docs:

import { Observable, Subject, ReplaySubject, from, of, range } from 'rxjs';
https://github.com/ReactiveX/rxjs#es6-via-npm

And

Import paths
If you're a TypeScript developer, it's recommended that you use rxjs-tslint to refactor your import paths.
For JavaScript developers, the general rule is as follows:

rxjs: Creation methods, types, schedulers and utilities
import { Observable, Subject, asapScheduler, pipe, of, from, interval, merge, fromEvent, SubscriptionLike, PartialObserver } from 'rxjs';

https://github.com/ReactiveX/rxjs/blob/master/docs_app/content/guide/v6/migration.md#import-paths

Also this?

import {Observable} from<EMAIL_ADDRESS>http://reactivex.io/rxjs/class/es6/Observable.js~Observable.html

And to be clear, my actual import is in typed-rx-emitter:

import { Observable, Observer } from 'rxjs'
https://github.com/bcherny/typed-rx-emitter/blob/0b94942/index.ts#L1

above snippet written through v5, as your package peerdep specifies rx >=5 is allowed.
As mentioned  impot path is bit different between v5 and v6,, per version it may vary and migration documentation describes way to enable treeshaking for those. If you think there is an issue with rx, please create repo with webpack config / import code allows to reproduces in single repo, instead of multiple packages involved.

Figured out my issue - in TS, you have to compile to es2015 modules, not commonjs. Here's the repro.
tl;dr-
With "module": "commonjs" vs "module": "es2015" in tsconfig.json:

"module": "commonjs"
"module": "es2015"

rxjs
79.6 KiB
14.7 KiB

rxjs-compat
80 KiB
80.1 KiB

That means if my package A depends on rxjs, and some package Z indirectly depends on A (maybe A -> B -> C -> Z), then every intermediate package (A, B, and C) has to ship with ES2015 exports, otherwise it will unintentionally bloat Z's file size.
That seems wrong. Since file size is Z's concern, we shouldn't expect A, B, and C to make sure they ship special ES2015 builds specifically for consumers like Z. Shipping both a CommonJS and an ES2015 build in a single NPM package is still super unusual, and it seems bad to put the burden on A, B, and C to do it.
An alternative solution is to fix RxJS6's re-exports in compat mode, so that even if you or one of your dependencies compiled rxjs to CommonJS, you can still tree-shake. I put up a PR to make this change here: https://github.com/ReactiveX/rxjs/pull/3974.
The results seem to be clear:
Before patch

"module": "commonjs"
"module": "es2015"

rxjs
79.6 KiB
14.7 KiB

rxjs-compat
80 KiB
80.1 KiB

After patch

"module": "commonjs"
"module": "es2015"

rxjs
79.6 KiB
14.7 KiB

rxjs-compat
18.6 KiB
18.7 KiB

That said, I'm not familiar with RxJS's codebase, and this kind of module and bundling stuff can be tricky. Please let me know if I missed something.


btoa() and atob() are not working

Description
btoa() and atob() methods are not working despite they're declared here WindowBase64.cs
Steps to Reproduce

Create a console application (.NET Framework 4.6.2)
Run this code (from AngleSharp.Samples)

// We require a custom configuration with JavaScript
var config = Configuration.Default.WithJs();

// This is our sample source, we will set the title and write on the document
var source = @"<!doctype html>

<title>Sample</title>

";

var document = BrowsingContext.New(config).OpenAsync(m => m.Content(source)).Result;

// Modified HTML will be output
Console.WriteLine(document.DocumentElement.OuterHtml);

Expected behavior:
Oputput: (in browser)
<title>Simple manipulation...</title>

dGVzdA==

Actual behavior:
Output:
<title>Simple manipulation...</title>

Environment details: [Win 10, .NET Framework 4.6.2]
It maybe an obvious question as I don't know the way the library works till now, or just don't know the right way to use it.
Note

To get the javascript error append these lines:

var service = new JsScriptingService();
var result = service.EvaluateScript(document, "btoa('test')");
Console.WriteLine(result);

Exception: System.Reflection.TargetException: 'Object does not match target type.'
generated in EngineExtensions (Call method).

When appending these lines:

var service = new JsScriptingService();
var result = service.EvaluateScript(document, "btoa");
Console.WriteLine(result);

Appended output:
function btoa() { [native code] }

So, it exists but I can't call it, maybe I'm using it the wrong way.

Thanks for the report - I'll look into it!

Landed in devel.


Notifications should use websockets

 Issue by atz
Thursday Apr 21, 2016 at 00:41 GMT
Originally opened as https://github.com/projecthydra/sufia/issues/1909

The repetitive AJAX polling of every open page is a costly and distinctly unmodern approach to the notification problem.  A better fit for today's web (well, recent years' web, anyway) would be websockets.

 Comment by mjgiarlo
Sunday Aug 28, 2016 at 17:10 GMT

Yes, we should re-implement notifications using Rails 5's Action Cable framework, if others are comfy making that jump. @cbeer is this something you'd be interested in?

 Comment by mjgiarlo
Sunday Aug 28, 2016 at 17:10 GMT

(sorry, closed by accident on mobile.)

 Comment by mjgiarlo
Tuesday Dec 20, 2016 at 22:52 GMT

Let's do this in Hyrax.

Blocked by that https://github.com/projecthydra-labs/hyrax/issues/679.

This is now unblocked. @atz, are you interested? (Perhaps building on https://github.com/projecthydra-labs/hyku/pull/408 ?)


waitForNonceToUpdate -> waitForOneConfirmation

Issue link
#175

Auto-close the issue?

Closes #175
Types of changes

Breaking change (fix or feature that would cause existing functionality not to work as expected)
Technical debt (a code change that doesn't fix a bug or add a feature but makes something clearer for devs)

We can still just increment patch version for this release since we're not in 1.0 yet


Adopt omniqueue as a queue backend and remove our own in-memory queue implementation

Depends on #1185 (merged), https://github.com/svix/omniqueue-rs/pull/24.
I have deleted low-level tests for the in-memory queue since its basic functionality should be tested inside omniqueue, not here. Do we have tests for higher-level functionality that uses the in-memory queue backend in some scenarios?
The redis and SQS implementation should probably be replaced by the implementations found in Omniqueue in a follow-up PR, to keep this one reasonably small.

LGTM, but somebody who was a bit more invested in the development of omniqueue than me should probably chime in.

Hm, even with the unbounded mpsc channel that the builtin in-memory queue used now adopted in omniqueue, some tests are still failing consistently, and with a super weird error message:
thread 'test_uid_across_users' panicked at library/alloc/src/raw_vec.rs:570:5:
capacity overflow

Plus a connection reset that I assume comes from the panic propagating up to hyper, which subsequently terminates the connection that the panicked task was serving.

Hm, even with the unbounded mpsc channel that the builtin in-memory queue used now adopted in omniqueue, some tests are still failing consistently, and with a super weird error message:
thread 'test_uid_across_users' panicked at library/alloc/src/raw_vec.rs:570:5:
capacity overflow

Plus a connection reset that I assume comes from the panic propagating up to hyper, which subsequently terminates the connection that the panicked task was serving.

@svix-jplatte did this get solved somehow?

Yes, there was one place where usize::MAX was passed as a buffer / channel capacity. I just put in a 128 instead, I doubt the exact number matters much since the in-memory queue isn't supposed to be optimized right?

in-memory queue isn't supposed to be optimized right?

Correct. It's more of a stub than anything else. Like a dummy (no-op) cache implementation.


ANTD v3

Hi, first of all, what a great tool, this helped me a lot with antd components and the redux-form implementation I am working on.
I just wanted to know if there are plans to change the antd dependency version to the latest ( I think is 3.1.6 at the moment)

Yeah, it is possible, but currently I don't have a lot of time for working on this project. Could you made such changes and publish them to gh-pages, smth like that 'https://zhdmitry.github.io/redux-form-antd/' if all components will be ok I will release new version of this component.

I placed it here https://luispeerez.github.io/redux-form-antd/ if you think they work correctly I think it will be ok to do the upgrade.
It is using
antd: 3.2.0
redux-form: 7.2.3

Looks nice.  Please make your pull request.

#18


always run in non-dev mode

End-user friendly description of the problem this fixes or functionality that this introduces

[ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below
no changelog needed

Give a summary of what the PR does, explaining any non-trivial design decisions
@amanape is working making this more configurable, but default should be that we use the real backend IMO

Link of any specific issues this addresses

Duplicate of https://github.com/All-Hands-AI/OpenHands/pull/4326


Let tasks in subdags use parent dag_run

Tasks in subDAGs are unable to access the dag_run of their parent DAG, and are therefore unable to access dag_run.conf. I have set tasks in subDAGs to use the dag_run of their top-level parent.

@Vanslashington, merging here to master-bombora, however, let's also submit a PR to apache upstream, and reference issue at: https://issues.apache.org/jira/browse/AIRFLOW-637


Client Crash  OTGv2 (BBv6.1) - World Pregeneration

Local Server Crash withException ticking world whilst standing still, looking at JourneyMap whilst the world pre-generated in SP, using BBv6.1
@PG85 This error does not happen with every seed I try, some seeds cause this to happen sooner than later so I am thinking there is an issue with a biome config.
https://pastebin.com/aSF45J8t

Hey thanks for reporting this, unfortunately this appears to be a threading/concurrency issue that occurs only rarely. I have not been able to find a cause for it yet. If you find a way to reliably reproduce this problem, please let me know.

Hoping this has already been fixed for v7, if not, feel free to open a new ticket.


SVGElement is not implemented

Hi,
I'm new with using jsdom and I did not find an answer in the documentation. In a old example from 2014 someone used this code to support svg features:
doc.implementation.addFeature(
'http://www.w3.org/TR/SVG11/feature#BasicStructure', '1.1'
)
In the latest versions of jsdom this does not work because addFeature is not a function. Is there a way to enable SVG 1.1?

Such code would never have worked in jsdom. I'm not sure where you found it. (It would have done nothing, whereas now it throws.)
What do you mean by "enable SVG 1.1?" What is some example code that works in browsers but not in jsdom?

I try to use a library called svg.js in Node.js and it doesn't work because SVGElement is not defined. Here is my code:
`var jsdom = require("jsdom").jsdom;`
`var document = jsdom("<div id='drawing'></div>");`
`var window = document.defaultView;`
`var doc = window.document;`

`var svgjs = require('svg.js')(window)`

Yes, SVGElement is not yet implemented in jsdom. Pull request welcome!

Okay, thanks for your fast answer

I'm interested in helping out here if I can. What is the status of https://github.com/tmpvar/jsdom/pull/1445?

It seems pretty stalled to me :(

No worries.
@Fuzzyma Where do you stand with https://github.com/tmpvar/jsdom/pull/1445? Anything I can to do help, or pick up the work?

All the code available is in the PR I think. Atm I do not have time to follow that path further. But I am still interested in this feature. Feel free to pick up the work. I hard trouble digging in the, a it peculiar, code of jsdom :)

Feel free to push em up :). It'll take me a while to familiarize myself with JSDOM anyway.

Done - hope it helps more than it creates confusion^^

Guys, what is the status on this? Is there any way this can be moved forward? How can I help? It seems that PR is there with some conflicts

A pull request is still welcome. That one was abandoned.

if you are using svg.js and need this PR only for using svg.js on node you can tale a look at svgdom which aims to make svg.js usable on node.

I'll try to add some svg support, because I need jsdom for SVGO, for using and adding tests on https://github.com/jarek-foksa/path-data-polyfill.js/ too
SVGElement    (not really needed, maybe it's helpful to allow to put getElementById on it)
SVGPathElement   (needed for path-data polyfill)
It just need to be very basic so, just those class should exist and be associated to the right elements.
is it bad if it's partial? because indeed implemented the full SVG spec would be horrible

It's not bad if it's partial, but the parts that are there, need to be implemented according to the SVG spec. (SVG 2, to be precise.)
Be sure to read Contributing.md to get an introduction to how we generate a lot of code from IDL files and such.

Yes thanks, I did something a bit ridiculous for now https://github.com/tmpvar/jsdom/pull/1946
I can add get/setPathData SVG2 polyfill I linked, I'll first make tests

@Tpower36 , I made following changes
Version using<EMAIL_ADDRESS>doc.implementation.addFeature(
'http://www.w3.org/TR/SVG11/feature#BasicStructure', '1.1'
)
to
doc.implementation._addFeature(
'http://www.w3.org/TR/SVG11/feature#BasicStructure', '1.1'
)
Mainly, I changed addFeature to _addFeature
It is working for me..

Is this fixed? This doesn't necessarily need SVG support for at least minimal XML support. It doesn't really need to be fancy. As far as I can tell by default you're just disappearing unrecognised attributes. Simply not doing that could potentially be enough.


Set the bundle target to ES6 for ESM, and ES5 for UMD

Pull request for @Cloudinary/Base
What does this PR solve?

Set the bundle target to ES6 for ESM, and ES5 for UMD
Dropped babel (we weren't using it anyway)

The PR fails due to code coverage, but the other open PRs should fix that, so this can be merged last.

The PR fails due to code coverage, but the other open PRs should fix that, so this can be merged last.


feat: experimental plugins registry; logger and metrics recorder plugins

Overview
High level architecture

Components
High level description of each components:

AppKit - see IoT AppKit
[NEW] PluginsRegistry - a basic / stand-in registry to register and provide plugins - an initial plugin system until we have a better design
[NEW] StorageLogger - a plugin to handle received log and metric emissions and send to Storage; not yet implemented;
[NEW] Storage - a log and metric storage; not yet implemented;
Client - extra; please ignore;

Legal
This project is available under the Apache 2.0 License.

Is there a difference between logger and metrics? Should they both rollup to just one logger?

Is there a difference between logger and metrics? Should they both rollup to just one logger?

the interfaces are also different, most likely have very different implementations between them; split to comply with single-responsibility principle (SRP);


ImportError: cannot import name 'CRS' from 'pyproj' (/opt/conda/lib/python3.7/site-packages/pyproj/init.py)

This issue tracker is for reporting bugs or proposing new features. Please ask "how-to" questions on https://stackoverflow.com/ instead. Before you proceed, please read the contributing guidelines in this repo's CONTRIBUTING.md.
If you installed OSMnx via conda and are experiencing installation problems, please open an issue at https://github.com/conda-forge/osmnx-feedstock/issues
If you're having trouble with OSMnx, first search the previously opened issues (and Stack Overflow) to see if the problem has already been noted. If not, fill in the template below:
Problem description (what did you do, what did you expect to happen, and what actually happened)
What operating system, architecture, Python version, and OSMnx version are you using?
Complete list of your environment's packages and their versions (for example, run conda list or pip list then paste the output below, between the two "details" tags)

# Paste the output of your Python packages and their versions here, between these two "details" tags

Code snippet that independently and completely reproduces the issue
# your code goes here

conda install osmnx
python version: 3.7.3
osmnx version: 0.11.4
ubuntu 18.0.4

If you fill out the issue template, we can re-open and take a look.

@gboeing
I installed OSMnx on anaconda from the shell using this command:
conda install -c conda-forge/label/gcc7 osmnx as available here.
The installation completed without any error.
Have been using OSMnx for quite some time now. But in a fresh Anaconda installation, when I try to import the module in Spyder using:
import osmnx as ox
it throws the following error:
File "", line 1, in
import osmnx as ox
File "C:\ProgramData\Anaconda3\lib\site-packages\osmnx_init_.py", line 9, in
from .core import *
File "C:\ProgramData\Anaconda3\lib\site-packages\osmnx\core.py", line 25, in
from .projection import project_geometry
File "C:\ProgramData\Anaconda3\lib\site-packages\osmnx\projection.py", line 12, in
from pyproj import CRS
ImportError: cannot import name 'CRS' from 'pyproj' (C:\ProgramData\Anaconda3\lib\site-packages\pyproj_init_.py)`

@PratyushTripathy don't use the gcc7 label... that hasn't been built or published in probably over a year. Stick with the latest version and you should be fine.

I had to install psutil for CSR to be there.
!pip3 install -U pyproj psutil

Good luck!

@gboeing
How are you. l have been doing one of your courses which is python geospatial analysis and mapping on planetizen. l installed the necessary modules for the course but when l try to run the code they are throwing me an error.
My machine:
Apple MacBook Pro (Retina, 13-inch, Early 2015)
Processor 2.7 GHz Intel Core i5
Memory    8 GB 1867 MHz DDR3
Python 3.7.6
the below is the code which I'm trying to execute:
magic command to display matplotlib plots inline within the ipython notebook
%matplotlib inline
import necessary modules
import numpy as np, matplotlib.pyplot as plt, pandas as pd, geopandas as gpd
from mpl_toolkits.basemap import Basemap
from shapely.geometry import Point
from geopy.distance import great_circle
When I try to execute the above code its giving me the error below:
ImportError                               Traceback (most recent call last)
 in
3
4 # import necessary modules
----> 5 import numpy as np, matplotlib.pyplot as plt, pandas as pd, geopandas as gpd
6 from mpl_toolkits.basemap import Basemap
7 from shapely.geometry import Point
~/anaconda3/lib/python3.7/site-packages/geopandas/init.py in
1 from geopandas._config import options  # noqa
2
----> 3 from geopandas.geoseries import GeoSeries  # noqa
4 from geopandas.geodataframe import GeoDataFrame  # noqa
5 from geopandas.array import points_from_xy  # noqa
~/anaconda3/lib/python3.7/site-packages/geopandas/geoseries.py in
7 from pandas.core.internals import SingleBlockManager
8
----> 9 from pyproj import CRS, Transformer
10 from shapely.geometry.base import BaseGeometry
11
ImportError: cannot import name 'CRS' from 'pyproj' (/Users/TINMPO/anaconda3/lib/python3.7/site-packages/pyproj/init.py)
Please find  attached the conda list output as text file.
kind regards
InstalledPackages.txt

I had to install psutil for CRS to be there.
!pip3 install -U pyproj psutil

Good luck!

worked for me! Thanks!

I had to install psutil for CRS to be there.
!pip3 install -U pyproj psutil

Good luck!

worked for me! Thanks!

ok, the funny thing is when l try to install psutil it is saying requirements already satisfied and l have the 5.7.0 version of psutil

I think this shall be reopened, same happens for me.
I installed from fresh conda environment and pyproj CRS causes those issues, basically this: https://stackoverflow.com/questions/59658167/cannot-import-name-crs-from-pyproj-for-using-the-osmnx-library
Downgrading to osmnx 0.11 made a job, but there is a lot of other inconsistencies (filename -> filepath, node -> nodes, osmnx.distances, etc. etc. ) between 0.15 and 0.11.
pyproj from conda froge is already up to date (1.9.6) yet pyproj on pip is 2.6.4 so maybe there is some issue.

@RafalKucharskiPK if you installed OSMnx using conda + conda-forge, can you please open an issue at the feedstock, providing a detailed step by step account of how you installed it? If you did not install using conda + conda-forge, can you please provide a detailed step by step account of how you installed it here?

If someone in this issue thread can provide a step by step account of how they're installing it (without success), I can try to reproduce the problem.
Just make sure you follow the installation instructions to install the latest release of OSMnx accordingly. If you install an old version of pyproj + a new version of OSMnx, or an old version of OSMnx + a new version of pyproj, you will get package conflicts such as the ImportError above. Required dependency versions can be seen here.
To summarize:

don't run conda install osmnx
don't run conda install -c conda-forge/label/gcc7 osmnx
do follow the installation instructions in the documentation
if you follow the installation instructions in the documentation and still have trouble, please report what you did step by step with full details at the feedstock so we can reproduce it

Again, the installation instructions are in the documentation. I just ran the two commands in the instructions tonight, and we can see their successful output below. Importantly, note the versions of pyproj, geopandas, and OSMnx: everything appears to be working properly as expected.
C:\>conda config --prepend channels conda-forge
Warning: 'conda-forge' already in 'channels' list, moving to the top

C:\>conda create -n osmnx --strict-channel-priority osmnx
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: C:\Anaconda\envs\osmnx

  added / updated specs:
    - osmnx

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    blas-1.0                   |              mkl           1 KB  conda-forge
    geopandas-0.8.1            |             py_0         925 KB  conda-forge
    intel-openmp-2019.4        |              245         1.4 MB  defaults
    libblas-3.8.0              |           14_mkl         3.5 MB  conda-forge
    libcblas-3.8.0             |           14_mkl         3.5 MB  conda-forge
    liblapack-3.8.0            |           14_mkl         3.5 MB  conda-forge
    libpq-12.3                 |       hd9aa61d_0         3.7 MB  conda-forge
    matplotlib-base-3.2.2      |   py38hbe5506b_1         7.1 MB  conda-forge
    mkl-2019.4                 |              245        99.2 MB  defaults
    mkl-service-2.3.0          |   py38hfa6e2cd_0          54 KB  conda-forge
    numpy-1.19.0               |   py38h72c728b_0         4.9 MB  conda-forge
    osmnx-0.15.1               |     pyh9f0ad1d_0          65 KB  conda-forge
    postgresql-12.3            |       he14cc48_0        21.0 MB  conda-forge
    scipy-1.5.0                |   py38h9439919_0        12.0 MB  defaults
    ------------------------------------------------------------
                                           Total:       160.9 MB

The following NEW packages will be INSTALLED:

  attrs              conda-forge/noarch::attrs-19.3.0-py_0
  blas               conda-forge/win-64::blas-1.0-mkl
  boost-cpp          conda-forge/win-64::boost-cpp-1.72.0-h89d28cc_2
  branca             conda-forge/noarch::branca-0.4.1-py_0
  brotlipy           conda-forge/win-64::brotlipy-0.7.0-py38h1e8a9f7_1000
  bzip2              conda-forge/win-64::bzip2-1.0.8-hfa6e2cd_2
  ca-certificates    conda-forge/win-64::ca-certificates-2020.6.20-hecda079_0
  certifi            conda-forge/win-64::certifi-2020.6.20-py38h32f6830_0
  cffi               conda-forge/win-64::cffi-1.14.0-py38ha419a9e_0
  cfitsio            conda-forge/win-64::cfitsio-3.470-he774522_5
  chardet            conda-forge/win-64::chardet-3.0.4-py38h32f6830_1006
  click              conda-forge/noarch::click-7.1.2-pyh9f0ad1d_0
  click-plugins      conda-forge/noarch::click-plugins-1.1.1-py_0
  cligj              conda-forge/noarch::cligj-0.5.0-py_0
  cryptography       conda-forge/win-64::cryptography-2.9.2-py38hba49e27_0
  curl               conda-forge/win-64::curl-7.71.1-h4b64cdc_1
  cycler             conda-forge/noarch::cycler-0.10.0-py_2
  decorator          conda-forge/noarch::decorator-4.4.2-py_0
  descartes          conda-forge/noarch::descartes-1.1.0-py_4
  expat              conda-forge/win-64::expat-2.2.9-he025d50_2
  fiona              conda-forge/win-64::fiona-1.8.13-py38h41bf4fa_1
  folium             conda-forge/noarch::folium-0.11.0-py_0
  freetype           conda-forge/win-64::freetype-2.10.2-hd328e21_0
  freexl             conda-forge/win-64::freexl-1.0.5-hd288d7e_1002
  gdal               conda-forge/win-64::gdal-3.0.4-py38h3ba59e7_9
  geopandas          conda-forge/noarch::geopandas-0.8.1-py_0
  geos               conda-forge/win-64::geos-3.8.1-he025d50_0
  geotiff            conda-forge/win-64::geotiff-1.5.1-h3d29ae3_10
  gettext            conda-forge/win-64::gettext-<IP_ADDRESS>-hb01d8f6_1002
  glib               conda-forge/win-64::glib-2.65.0-he4de6d7_0
  hdf4               conda-forge/win-64::hdf4-4.2.13-hf8e6fe8_1003
  hdf5               conda-forge/win-64::hdf5-1.10.6-nompi_ha405e13_100
  icc_rt             pkgs/main/win-64::icc_rt-2019.0.0-h0cc432a_1
  icu                conda-forge/win-64::icu-64.2-he025d50_1
  idna               conda-forge/noarch::idna-2.10-pyh9f0ad1d_0
  intel-openmp       pkgs/main/win-64::intel-openmp-2019.4-245
  jinja2             conda-forge/noarch::jinja2-2.11.2-pyh9f0ad1d_0
  joblib             conda-forge/noarch::joblib-0.16.0-py_0
  jpeg               conda-forge/win-64::jpeg-9d-he774522_0
  kealib             conda-forge/win-64::kealib-1.4.13-h3b59ab9_1
  kiwisolver         conda-forge/win-64::kiwisolver-1.2.0-py38heaebd3c_0
  krb5               conda-forge/win-64::krb5-1.17.1-hc04afaa_1
  libblas            conda-forge/win-64::libblas-3.8.0-14_mkl
  libcblas           conda-forge/win-64::libcblas-3.8.0-14_mkl
  libcurl            conda-forge/win-64::libcurl-7.71.1-h4b64cdc_1
  libffi             conda-forge/win-64::libffi-3.2.1-h6538335_1007
  libgdal            conda-forge/win-64::libgdal-3.0.4-h6f60a84_9
  libiconv           conda-forge/win-64::libiconv-1.15-hfa6e2cd_1006
  libkml             conda-forge/win-64::libkml-1.3.0-h7e985d0_1011
  liblapack          conda-forge/win-64::liblapack-3.8.0-14_mkl
  libnetcdf          conda-forge/win-64::libnetcdf-4.7.4-nompi_h256d12c_104
  libpng             conda-forge/win-64::libpng-1.6.37-hfe6a214_1
  libpq              conda-forge/win-64::libpq-12.3-hd9aa61d_0
  libspatialindex    conda-forge/win-64::libspatialindex-1.9.3-he025d50_3
  libspatialite      conda-forge/win-64::libspatialite-4.3.0a-h51df0ed_1038
  libssh2            conda-forge/win-64::libssh2-1.9.0-hb06d900_3
  libtiff            conda-forge/win-64::libtiff-4.1.0-h885aae3_6
  libwebp-base       conda-forge/win-64::libwebp-base-1.1.0-hfa6e2cd_3
  libxml2            conda-forge/win-64::libxml2-2.9.10-h5d81f1c_1
  lz4-c              conda-forge/win-64::lz4-c-1.9.2-h62dcd97_1
  m2w64-expat        pkgs/msys2/win-64::m2w64-expat-2.1.1-2
  m2w64-gcc-libgfor~ pkgs/msys2/win-64::m2w64-gcc-libgfortran-5.3.0-6
  m2w64-gcc-libs     pkgs/msys2/win-64::m2w64-gcc-libs-5.3.0-7
  m2w64-gcc-libs-co~ pkgs/msys2/win-64::m2w64-gcc-libs-core-5.3.0-7
  m2w64-gettext      pkgs/msys2/win-64::m2w64-gettext-0.19.7-2
  m2w64-gmp          pkgs/msys2/win-64::m2w64-gmp-6.1.0-2
  m2w64-libiconv     pkgs/msys2/win-64::m2w64-libiconv-1.14-6
  m2w64-libwinpthre~ pkgs/msys2/win-64::m2w64-libwinpthread-git-<IP_ADDRESS>34.697f757-2
  m2w64-xz           pkgs/msys2/win-64::m2w64-xz-5.2.2-2
  markupsafe         conda-forge/win-64::markupsafe-1.1.1-py38h9de7a3e_1
  matplotlib-base    conda-forge/win-64::matplotlib-base-3.2.2-py38hbe5506b_1
  mkl                pkgs/main/win-64::mkl-2019.4-245
  mkl-service        conda-forge/win-64::mkl-service-2.3.0-py38hfa6e2cd_0
  msys2-conda-epoch  pkgs/msys2/win-64::msys2-conda-epoch-20160418-1
  munch              conda-forge/noarch::munch-2.5.0-py_0
  networkx           conda-forge/noarch::networkx-2.4-py_1
  numpy              conda-forge/win-64::numpy-1.19.0-py38h72c728b_0
  openjpeg           conda-forge/win-64::openjpeg-2.3.1-h57dd2e7_3
  openssl            conda-forge/win-64::openssl-1.1.1g-he774522_0
  osmnx              conda-forge/noarch::osmnx-0.15.1-pyh9f0ad1d_0
  pandas             conda-forge/win-64::pandas-1.0.5-py38he6e81aa_0
  pcre               conda-forge/win-64::pcre-8.44-h6538335_0
  pip                conda-forge/noarch::pip-20.1.1-py_1
  poppler            conda-forge/win-64::poppler-0.87.0-h0cd1227_1
  poppler-data       conda-forge/noarch::poppler-data-0.4.9-1
  postgresql         conda-forge/win-64::postgresql-12.3-he14cc48_0
  proj               conda-forge/win-64::proj-7.0.0-haa36216_3
  pycparser          conda-forge/noarch::pycparser-2.20-pyh9f0ad1d_2
  pyopenssl          conda-forge/noarch::pyopenssl-19.1.0-py_1
  pyparsing          conda-forge/noarch::pyparsing-2.4.7-pyh9f0ad1d_0
  pyproj             conda-forge/win-64::pyproj-2.6.1.post1-py38h1dd9442_0
  pysocks            conda-forge/win-64::pysocks-1.7.1-py38h32f6830_1
  python             conda-forge/win-64::python-3.8.3-cpython_h5fd99cc_0
  python-dateutil    conda-forge/noarch::python-dateutil-2.8.1-py_0
  python_abi         conda-forge/win-64::python_abi-3.8-1_cp38
  pytz               conda-forge/noarch::pytz-2020.1-pyh9f0ad1d_0
  requests           conda-forge/noarch::requests-2.24.0-pyh9f0ad1d_0
  rtree              conda-forge/win-64::rtree-0.9.4-py38h7ad75cc_1
  scikit-learn       conda-forge/win-64::scikit-learn-0.23.1-py38ha1d60b4_0
  scipy              pkgs/main/win-64::scipy-1.5.0-py38h9439919_0
  setuptools         conda-forge/win-64::setuptools-49.2.0-py38h32f6830_0
  shapely            conda-forge/win-64::shapely-1.7.0-py38hbf43935_3
  six                conda-forge/noarch::six-1.15.0-pyh9f0ad1d_0
  sqlite             conda-forge/win-64::sqlite-3.32.3-he774522_1
  tbb                conda-forge/win-64::tbb-2020.1-he980bc4_0
  threadpoolctl      conda-forge/noarch::threadpoolctl-2.1.0-pyh5ca1d4c_0
  tiledb             conda-forge/win-64::tiledb-1.7.7-h0b90766_3
  tk                 conda-forge/win-64::tk-8.6.10-hfa6e2cd_0
  tornado            conda-forge/win-64::tornado-6.0.4-py38hfa6e2cd_0
  urllib3            conda-forge/noarch::urllib3-1.25.9-py_0
  vc                 conda-forge/win-64::vc-14.1-h869be7e_1
  vs2015_runtime     conda-forge/win-64::vs2015_runtime-14.16.27012-h30e32a0_2
  wheel              conda-forge/noarch::wheel-0.34.2-py_1
  win_inet_pton      conda-forge/win-64::win_inet_pton-1.1.0-py38_0
  wincertstore       conda-forge/win-64::wincertstore-0.2-py38_1003
  xerces-c           conda-forge/win-64::xerces-c-3.2.2-h6538335_1004
  xz                 conda-forge/win-64::xz-5.2.5-h62dcd97_1
  zlib               conda-forge/win-64::zlib-1.2.11-h2fa13f4_1006
  zstd               conda-forge/win-64::zstd-1.4.4-h9f78265_3

Proceed ([y]/n)? y

Downloading and Extracting Packages
postgresql-12.3      | 21.0 MB   | ############################################################################ | 100%
libblas-3.8.0        | 3.5 MB    | ############################################################################ | 100%
mkl-service-2.3.0    | 54 KB     | ############################################################################ | 100%
osmnx-0.15.1         | 65 KB     | ############################################################################ | 100%
blas-1.0             | 1 KB      | ############################################################################ | 100%
scipy-1.5.0          | 12.0 MB   | ############################################################################ | 100%
libpq-12.3           | 3.7 MB    | ############################################################################ | 100%
numpy-1.19.0         | 4.9 MB    | ############################################################################ | 100%
intel-openmp-2019.4  | 1.4 MB    | ############################################################################ | 100%
matplotlib-base-3.2. | 7.1 MB    | ############################################################################ | 100%
geopandas-0.8.1      | 925 KB    | ############################################################################ | 100%
mkl-2019.4           | 99.2 MB   | ############################################################################ | 100%
libcblas-3.8.0       | 3.5 MB    | ############################################################################ | 100%
liblapack-3.8.0      | 3.5 MB    | ############################################################################ | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
#
# To activate this environment, use
#
#     $ conda activate osmnx
#
# To deactivate an active environment, use
#
#     $ conda deactivate

C:\>conda activate osmnx

(osmnx) C:\>python
Python 3.8.3 | packaged by conda-forge | (default, Jun  1 2020, 16:59:10) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import osmnx as ox
>>> ox.__version__
'0.15.1'
>>> ox
<module 'osmnx' from 'C:\\Anaconda\\envs\\osmnx\\lib\\site-packages\\osmnx\\__init__.py'>
>>>

So it seems that the issue was only with 32 bit anaconda (I couldn't run 64bit anaconda on windows server due to some other issues),
when I unistalled anaconda 32bit, installed anaconda 64bit it all went from well your commands.
Unfortunately, I removed the environment where we had errors, so I cannot reproduce.
Yet it was with referencing to older pyproj version.

@rafaeelaudibert via conda-forge, pyproj >= 2 is only available for 64-bit. OSMnx depends on geopandas, and geopandas depends on pyproj >= 2.x.

I have provided an answer on StackOverflow to the related question there.


Testing advice needs to be extended to show how to test external script

http://click.pocoo.org/5/testing/ shows external SUTs. (System Under Test).
Also list compatibility with Pytest as well as Unittest

I actually think this is a bit out of scope for the click documentation. Happy to review a PR against the version 7.x docs though.


Fake issue to test bot automation

Feature Description

One-line feature description (can be used as a release note):
Primary contact (assignee):
Responsible SIGs:
Design proposal link (community repo):
Link to e2e and/or unit tests:
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
Approver (likely from SIG/area to which feature belongs):
Feature target (which target equals to which milestone):

Alpha release target (x.y)
Beta release target (x.y)
Stable release target (x.y)

/stage alpha

/stage alpha

/stage alpha

@nikhita -- you can test over here :)

@justaugustus let's close this for now and reopen when prow is bumped. I'm not sure when the next prow bump is going to occur and IMO it would be better to not leave a fake issue open for too long...especially in a repo that is all about issues. :)
/close

/reopen

/unassign @nikhita
/assign

/kind feature
/lifecycle frozen


Need to output HTML as 'web archive" so that CSS and JS get embedded inline

...otherwise, the CSS files will not be referenced correctly, and the page does not render.

Done. New config option.


Fix orphaned node delete order

Closes https://github.com/mui/mui-toolpad/issues/2033
When some nested elements were moved out of a parent or deleted, the parent 2 levels above was being adjusted before the parent 1 level above, which could result in moving the non-deleted elements to a parent that ended up being deleted. Not easy to explain.

Would it be complex to add this case to a test? Can this be added to an existing test file?

Would it be complex to add this case to a test? Can this be added to an existing test file?

This seems to be a rare case, I'm not sure how to reproduce it yet but I can try, it should be possible.
We can include some nested deletes in the test for deleting nodes, I'll give it a look.
We should probably merge this already and then I can add the tests separately just to get the fix in?


Feedback for “Migrations”

Hey Just looking for some help.
I am noticing an error when I migrate. I remember deleting the migrations folder and I know that it was mentioned not to do so. But this is the error I see.
🟠 Migrating client... {   severity_local: "NOTICE",   severity: "NOTICE",   code: "42P06",   message: "schema \"drizzle\" already exists, skipping",   file: "schemacmds.c",   line: "128",   routine: "CreateSchemaCommand" } {   severity_local: "NOTICE",   severity: "NOTICE",   code: "42P07",   message: "relation \"__drizzle_migrations\" already exists, skipping",   file: "parse_utilcmd.c",   line: "209",   routine: "transformCreateStmt" }
I tried unistalling drizzle-kit and reinstalling it but this issue is still persisting. Im not able to migrate anything because of this. /
This is my migration.ts file
`import { migrate } from 'drizzle-orm/postgres-js/migrator';
import db from './db';
const migrateDb = async () => {
console.log('🟠 Migrating client...');
await migrate(db, {
migrationsFolder: 'migrations',
});
console.log('🟢 Successfully Migrated!');
};
migrateDb().finally(() => {
process.exit();
});`

This is what I did, but note that the push may delete other tables that might not have been created by the original migration file.
I'm using my configuration with neon.tech's db.
File: ./drizzle.config.ts
// Imports
// ========================================================
import type { Config } from "drizzle-kit";

// Exports
// ========================================================
export default {
  dbCredentials: {
    connectionString: process.env.DATABASE_URL!,
  },
  schema: "./path/to/schema.ts",
  out: "./drizzle",
  driver: "pg",
} satisfies Config;

Make sure your DATABASE_URL has ?sslmode=require appended to it in you .env file.
Using dotenv-cli export the environment variables (pnpm add -D dotenv-cli), I modified my package.json with the following:
File: ./package.json
{
  "scripts": {
    "push": "dotenv -e .env.local ./node_modules/.bin/drizzle-kit push:pg --config=./drizzle.config.ts"
  },
}

Then you can run:

⚠ If there are other tables that were created without the migrations, they will be dropped.

# FROM: ./

pnpm run push;

# [Expected Output]:
# drizzle-kit: v0.19.13
# drizzle-orm: v0.28.6
#
# No config path provided, using default path
# Reading config file '/path/to/repo/drizzle.config.ts'
# [✓] Changes applied

@Angelelz is there a way to disable these notifications? they show up every time and are quite noisy


After windows restore, some of the shims seem to not work

I've noticed this a few times and its popped up in various different manners.  After running a system restore in Windows 10 some of the shims will just not work.  In some instances, the shims will just not display anything and then return to the console and in others they will work perfectly fine.  For instance, my Elixir installation has no iex shim anymore after the restore.  Also, git didn't work and it caused scoop to throw a ton of errors when I tried to run scoop update *.  Is there anyway that I can repopulate the shims without individually reinstalling all of the programs (I have quite a few installed).

Please try scoop reset *

Alright, will give it a shot.


What are the pre-requisites required for installing redoc on Windows

I am trying to install redoc on my windows 10 machine. On trying to execute the npm command, I get the below error
Error: Can't find Python executable "C:\Program Files\Python3\python.exe", you can set the PYTHON env variable
The complete log file is pasted here.
I have the latest python installed (version - 3.6.5) with both the PYTHON & PATH variables updated. Despite it I get the above error.
Could some one please guide me through the installation?
Thanks!

Looks like this should be fixed on the latest version since it has been fixed in the dependency: https://github.com/siddharthkp/bundlesize/pull/214/files
Please, feel free to reopen in case the error still happens


[Bug]: Pipeline force-download fails to find local path of repo

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior

With VPN disabled & the pipeline repo at local, run in python: p = pipeline('author/repo', force_download = True)
--> It returns connection error: "ConnectionRefusedError: [Errno 61] Connection refused"

Then enable VPN & re-run in python: p = pipeline('author/repo', force_download = True)
--> It returns error: failed to find local path of repo

Expected Behavior

Option 1: print out message that the local repo has been deleted after step 1, before error out.
Option 2: pipeline force_download can cover the case of no local repo.

Steps To Reproduce
No response
Environment
- Towhee version: 0.3.1.dev2
- OS(Ubuntu or CentOS):
- CPU/Memory:
- GPU:
- Others:

Anything else?
No response

/close


[BUG] Mixin crashing Transpose By Steps on every other invocation

Describe the bug
Each time the Transpose By Steps dialog box opens, the next time it opens the plugin crashes.
To Reproduce
Steps to reproduce the behavior:

Go to 'Transpose By Steps'
Click on 'Cancel'
Go to 'Transpose By Steps' again
See error: bad argument 1 to SetLeft_ (number expected got nil)

Expected behavior
The dialog box should open.
I can proved more context if needed, but I am wondering if this is not related to the recent merge of mixin changes.

I've got a rough idea of what's gone wrong, I'll look into it.

My older version of the script didn't produce the error on 0.66 or 0.67b4, but a more recent version (with the new mixins) did.


Allow wrapping any error code, not just Internal errors

And support the Unwrap() method in addition to Cause()
Issue #228
Description of changes:
Add a function WrapError(ErrorCode, error) Error, which allows wrapping an error with any error code, not just Internal errors.
And add the Unwrap() method to the wrappedErr type, to be compatible with Go 1.13's new error unwrapping.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

It would also be nice to unwrap errors returned by the Twirp server (and possibly client, though this doesn't affect me personally).
In other words, it would be nice for a function to, do something like:
    err := twirp.NewError(twirp.NotFound, "it's missing")
   /* some time later */
   return errors.WithStack(err)

I think this change would belong here, in errors.go:
// writeError writes Twirp errors in the response.
func writeError(resp http.ResponseWriter, err error) error {
	// Non-twirp errors are wrapped as Internal (default)
	twerr, ok := err.(Error)
	if !ok {
		twerr = InternalErrorWith(err)
	}

But there are many subtleties to consider, so I'd rather get some feedback that this is desired before I work on a PR.

Our use case for WriteError, which calls writeError under the hood, is exclusively in the middleware portion, where we return Twirp-structured errors to frontend clients.
And if inside Twirp handlers one would call some variant that returns a twirp Error.
Maybe you can describe what changes you'd make to writeError? Is the proposal to call pkg/errors.WithStack by default to include a stack trace for every request?

Our ultimate goal is to log errors in a meaningful way, including additional context, such as (but not limited to) stack traces.
This could be done with the server Error hook, except that there is no way to pass error context through the twirp layer,  except with InternalErrorWith, which of course only works for internal errors.
So my suggestion with respect to writeError would be something like:
func writeError(resp http.ResponseWriter, err error) error {
	twerr = new(Error)
	// Non-twirp errors are wrapped as Internal (default)
	if !errors.As(err, twerr) {
		twerr = InternalErrorWith(err)
	}

As I mentioned above, though, there are many subtleties to consider here:

errors.As only works with Unwrap(), not Cause(). It's a trivial matter to write a version that handles both, though.
More important, simply using errors.As (or even github.com/pkg/errors#Cause()) will alter the result of err.Error(), by stripping some of its context.  What may be desired is something more equivalent to:

func writeError(resp http.ResponseWriter, err error) error {
	twerr = new(Error)
	// Non-twirp errors are wrapped as Internal (default)
	if !errors.As(err, twerr) {
		twerr = &wrappedErr{
			wrapper: NewError(twerr.Code(), err.Error()), // Code from the unwrapped, error, but err.Error() from the original
			cause: err,
		}
	}

I think there's a lot of subtlety here, so I hope my explanation of both the problem, and proposal, make sense.

twirp.Error is meant to be a value sent through the network, not an actual error to be passed around in the service. The case for internal errors is different because that is the "default" wrapper when any other error is returned, in the service, or when a network issue happens on the client, in which case it is important to unwrap to inspect the reason for that error.
I'm curious about what other use cases you think may be solved by allowing to wrap errors with codes other than internal. Or maybe there's anything that could be explained better on the docs?

The main case we care about is logging error details. This is why we want the complete error to be accessible in the Error hook. This can be useful for virtually any error, not just "internal" errors.
The alternative is to ensure that we log all details before converting to a twirp.Error, which is cumbersome, and error-prone.
Example:
func SomeHandler(...) (..., error) {
    data, err := ProcessData(/* ... */)
    if err != nil {
        return twirp.NewError(twirp.Malformed, err.Error())
    }
}

If ProcessData adds additional context to the error, such as a stack trace,  or any other arbitrary data about the context of the error, the twirp.NewError method discards it.  By wrapping, it would be possible to extract that info within the Error hook for logging purposes.
The only other options are:

To handle all logging before returning a twirp error. As alluded to above, this is cumbersome and error prone, because it's so easy to forget to do. It also requires code that appears to violate the handle errors once principle, by both logging and returning the same error.

func SomeHandler(...) (..., error) {
    data, err := ProcessData(/* ... */)
    if err != nil {
        logErrorWithContext(err)
        return twirp.NewError(twirp.Malformed, err.Error())
    }
}

Stop using twirp.NewError entirely, and use a custom error type that handles the error wrapping for us.  This solves the handle-errors-once problem, but is still error prone, because it's so easy to use twirp.NewError instead.

Gotcha. I see how this can be useful.
I would suggest using a slightly different implementation if that makes sense. Instead of adding the meta "cause" to all wrapped errors (which could be surprising behavior in the client), we should just allow to wrap any twirp error with an original error:
// WrapError allows Twirp errors to wrap other errors.
// The wrapped error can be extracted later with (github.com/pkg/errors).Unwrap
// or errors.Is from the standard errors package on Go 1.13+.
func WrapError(twerr Error, err error) Error {
	return &wrappedErr{
		wrapper: twerr,
		cause:   err,
	}
}

// InternalErrorWith makes an internal error, wrapping the original error and using it for the
// error message. It adds the wrapped error's type as metadata with the key: "cause".
// This function is used by Twirp services to wrap non-Twirp errors as internal errors.
// The wrapped error can be extracted later, usually on middleware, with
// (github.com/pkg/errors).Unwrap or errors.Is from the standard errors package on Go 1.13+.
func InternalErrorWith(err error) Error {
  twerr := NewError(Internal, err.Error())
  twerr = twerr.WithMeta("cause", fmt.Sprintf("%T", err)) // to easily tell apart wrapped internal errors from explicit ones
  return WrapError(twerr, err)
}

The way to use is by making the Twirp error first, and then wrapping the original:
if err != nil {
  twerr := twirp.NewError(twirp.Malformed, "msg that is visible on the public")
  return nil, twirp.WrapError(twerr, err)
}

Note: unwraping with Go 1.13+ errors package was implemented on #235

Your proposal would solve my problem. Would you like me to adjust this PR to follow that pattern?

Let's wait until I can get another review from the team

@flimzy I consulted and it looks good. Please, update the PR with the code that was proposed on the previous comment, that simply adds a new helper WrapError(twerr Error, err error) Error and refactors the existing helper InternalErrorWith(err error) Error with comments. And then it will be ready to merge and be released. Thank you so much for the suggestion!

@marioizquierdo I have rebased, and made the requested changes. Should I add some tests to cover the new functionality, as well?

@flimzy Thanks for the tests. It looks good to merge!


Wrap XAResource with XAResourceWrapper interface to avoid logging warnings like "Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord" during periodic recovery

Hi @gytis ,
just send a few PRs. Plz have a look. I think this could be interesting to avoid ugly logging warnings!
Regards
Benjamin

Seems to not work as expected and mentioned in Narayana blog :(


mam2: sig and mac tests

Replicate https://github.com/iotaledger/mam-specification/commit/727a74a8c03373dbd9267dbbdc63898c74609163

Already included in the existing tests.


Notes for Django

Probably should try to find an earlier entry point other than settings.py (but I'm out of touch w/ Django's load process)
sentry_sdk.init is better than init on our suggest import process

Test Plan:

[ ] catches wsgi error?
[ ] catches manage.py error?
[x] catches sys.except_hook (non manage.py) error?
[x] catches middleware error?
[x] catches view error?

Also a note that it 100% doesnt work with native graphene integration (as they hijack error handling in a not-so-great kind of way).

manage.py is not handled by excepthook, django catches exceptions. Need to patch django again

raw wsgi errors are not caught at all. I think this needs more thought, especially wrt how to deduplicate code between Flask and Django. I'd like to attach parts of the environ but then I duplicate already existing functionality that operates on request objects.
In the long term I suspect we will have to convert everything to a WSGI middleware and do our own request parsing.

Follow-up issues have been created


[Question]: How to insert TextNode into VectorStore

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
Hi I am using delta medallion architecture. Where my gold table is chunked text. I want to insert the chunked text into my persisted Vector Store but problem is that insert method only accepts Document object. How can I achieve this?

So it does not matter if its Document object but my text is chunked text which logically should be TextNode?


Provide alternate request ticket behaviours

Currently the async-support branch installs a HttpOutput.Interceptor  that clears the request ticket as the response is committed.
This behaviour should be made configurable, as the request ticket may remain valid while the response is being written.
Furthermore, an configuration option could be provided to mimic the buffering behaviour of the master branch by buffer content here and only flushing when the full request lifecycle is complete.

For synchronous calls is it guaranteed that the Interceptor.write callback is only going to be called once at the end of the method? Otherwise shouldn't it consider the complete param or is that the reason you were suggesting to mimic the buffering behavior of the master branch?
Do we still think that using the request ticket performs better than using the global ticket?
Speaking with the VM people they think they should have the same performance characteristics and if
that is true. /cc @ludoch

The interceptor write method will be called every time the application does a flush OR writes enough data to fill up the aggregation buffer inside our HttpOutput class.   Thus the first write is seen as the commit.      A write with complete==true will always be done, even if it is with an empty buffer (used by a close), so that can indicate the end of writing, but as that could be an explicit close done by either a synchronous or async servlet, it is still possible for API calls to be made after the complete==true write.
API calls can theoretically continue to be made for sync calls until the request destroyed listener callback or for async calls until the AsyncContext.onComplete callback.
Even if performance is the same between global and request ticket, it is desirable if we can use the request ticket so that trace and logging show the APIs correctly associated with a request.


Remove styled-components styling from table-query

And use MuiPaper instead of div with box-shadow.

Does this also center the progress bar inside the table while loading?

Yes, it does the same as before.


docs(file): file upload/input docs update

Description
Docs update to reflect the updated outputs from the last NG update
What's included?

Updating file upload output
Updating file input output

Test Steps

[ ] npm run start
[ ] then this
[ ] finally this

General Tests for Every PR

[ ] npm run start still works.
[ ] npm run lint passes.
[ ] npm run stylelint passes.
[ ] npm test passes and code coverage is not lower.
[ ] npm run build still works.

Screenshots or link to StackBlitz/Plunker

:tada: This PR is included in version 4.6.1 :tada:
The release is available on:

v4.6.1
GitHub release

Your semantic-release bot :package::rocket:


Updating date and ics for community call

Description
Updating the date for the next community call and adding a new .ics calendar invite for it.

/azp run


zone level SAML signatureAlgorithm

Provide functionality to set SAML signatureAlgorithm in Zone config

When UAA is SP, this algorithm will be used to sign the SAML Authentication request.
When UAA is IdP, this algorithm will be used to sign the SAML Assertion.
yaml properties follow the global notation used by ClientSecretPolicy, PasswordPolicy etc.

Note: Even if this value is updated to a different signatureAlgorithm, it does not need a metadata update. Existing SP-IdP integrations will continue to work

Coverage increased (+0.03%) to 86.476% when pulling bfd9a8d514fd065de0e53bd44950f2b1c8c05677 on GESoftware-CF:feature/zonify_saml_sig_alg into 749b2c6e78a33892ebfa614b242512c4b7fcf4c3 on cloudfoundry:develop.

@bsekar Can you please update the PR not to introduce a new policy for a global setting for the signature algorithm. We can re-use the existing one under SAML Settings as a global setting

@sreetummidi The reason for keeping two settings is for consistency with other configurations like password policy, lockout, or token validity. Just wanted to confirm that this kind of separation is no longer needed.

added extra commit to use zone saml signature method when signing saml metadata as well.

We don't plan on supporting this.


Rework BREAK and CONTINUE opcode handling to avoid longjmp entirely

The compiler emits a "fast break/continue", which is just a plain JUMP, in common situations but falls back to a "slow break/continue" in other situations. A slow break/continue means emitting a BREAK or CONTINUE opcode, and the executor then using a longjmp() to propagate the break/continue outwards. Note that a finally block may capture and even cancel a break/continue - uncommon, but required functionality.
At the moment a slow break is emitted when there are any try-catch sites between the break/continue source and target, but also if the break/continue breaks out more than one level. See the compiler source for the exact conditions.
Implement changes to avoid longjmp() entirely in BREAK and CONTINUE (= slow break/continue) handling. While longjmp() is slower than ordinary code in desktop platforms, there's an enormous different for Emscripten-compiled Duktape executed using e.g. Chrome or Firefox.

[ ] Refactor current DUK_LJ_TYPE_BREAK and DUK_LJ_TYPE_CONTINUE handler into a non-longjmp-bound handler.
[ ] Use the new handler from BREAK/CONTINUE directly.
[ ] Also use the new handler from ENDFIN, in case a break/continue will propagate outwards after a finally block finishes without affecting the completion being propagated.
[ ] Check debug log levels, resolve FIXMEs
[ ] Documentation updates
[ ] Test case updates, add a test case covering all direct and ENDFIN control paths
[ ] Add perf testcase for fast and slow break/continue
[ ] Check Github issues for fast/slow break/continue references and update
[ ] Performance measurement, both desktop and Emscripten
[ ] Assert and torture runs
[ ] Release notes

This will be merged after #345 (rebase after merging).

Nothing here yet except FIXME notes.

Draft of implementation now in branch (on top of unfinished RETURN rework branch). API and Ecmascript test cases pass without assertions at least.

Ok, we really don't have much usage of break/continue in any current examples, this is probably a result of the component model :)

A quick performance test for tests/perf/test-break-slow.js:

Native: master 15.8 sec, this branch 11.0 sec
Emduk (Emscripten+Node.js): master ~49900 sec, this branch ~330 sec

The value for emduk+master is a rough estimate: had to drop loopcount to 1/1000 and multiply result by 1000 to run the test reasonably quickly.

Very nice!  Glad to see it speeds native up too, would be interesting to see how longjmp affects Android/iOS

I would love to try to compile minisphere for Android, it already compiles on Linux and I have a GS5 laying around somewhere, but everything I've read the build process is so involved...

The improvement in this branch is limited to "slow" break/continue which are not that common in practical code, so this is probably not a significant change for usual applications.  But it does reduce longjmp usage for Emscripten (which is critical for Emscripten performance) and overall it's better to rely less on setjmp/longjmp because it has a lot of downsides.
After this only actual throws, yield, and resume will use longjmps. It should be possible to convert yield/resume to be longjmp free too (this might actually matter to @JoshEngebretson?) but since they're currently ordinary function calls it needs a bit of thought.

What exactly is the criteria for a "slow" break/continue?

It's decided by the compiler: a "fast" break/continue is just a JUMP, a "slow" break/continue needs to check if there are catchers to unwind, finally blocks to execute, etc.
Here's the current check: https://github.com/svaarala/duktape/blob/master/src/duk_js_compiler.c#L5547-L5566

@JoshEngebretson The difference between an ordinary unwind and a longjmp-based unwind is measurable but not dramatic in native platforms, so I'd guess it'd be around 10-30% for a microbenchmark exercising that specifically.
Easiest improvements to call handling will probably come from reworking value stack handling, refcount handling for value stack "wipes", etc; these are quite inefficient now. I'll be looking into these shortly.

Right, guess I was thinking of the MacOSX  _setjmp and _longjmp kerfuffle which yielded nearly a 2x speedup

I probably won't do more longjmp rework in 1.4 release, remaining possible future work is in #373 and #374.

After all this is through I'm going to have to reacquaint myself with the Duktape codebase, I probably won't recognize it! :)


Exclude monorepo package from config file

Search terms

exclude
monorepo
package

Expected Behavior
typedoc config should be consistent between typedoc.json and CLI arguments.
Actual Behavior
Excluding a monorepo package works on the CLI:
$ typedoc --exclude packages/undocumented-package
// packages/undocumented-package is not in the generated docs

If I configure the same thing via a typedoc.json in the root of the monorepo and just run typedoc (without the --exclude) it no longer excludes the package:
{
  "exclude": [
    "packages/undocumented-package"
  ]
}

$ typedoc
// packages/undocumented-package *is* in the generated docs

Steps to reproduce the bug
See above.
Environment

Typedoc version: 0.25.2
TypeScript version: 5.2.2
Node.js version: 20.8.0
OS: Mac OS X 13.5.1

Going to have to ask for a reproduction here, this seems to work correctly for me. I made the following change to https://github.com/Gerrit0/typedoc-packages-example, and TypeDoc excludes foo exactly as expected.
diff --git a/typedoc.json b/typedoc.json
index 55d96f8..ef4407e 100644
--- a/typedoc.json
+++ b/typedoc.json
@@ -2,7 +2,8 @@
   "entryPoints": ["packages/*"],
   "name": "Packages Example",
   "entryPointStrategy": "packages",
-  "includeVersion": false
+  "includeVersion": false,
+  "exclude": ["packages/foo"]

   // Potentially useful for debugging
   // "logLevel": "Verbose"

Ah, sorry for opening this, it was user error.  I was passing a different --exclude tag to typedoc elsewhere.


Improve I/O with EEGLAB

I have to work a bit with EEGLAB, and I'm not very familiar with it (yet) but I already noticed a couple of improvements that could be made to the I/O in my opinion.
Reader
Channel type is hard-coded to 'eeg' here while EEGLAB seems to support a larger variety of channel types.
From the documentation:

‘EEG’, ‘MEG’, ‘EMG’, ‘ECG’, ‘Events’, etc.

Proposition: Try to retrieve the channel types saved by EEGLAB and convert it to one of MNE channel types (e.g. 'EEG' -> 'eeg', 'Events' -> 'stim').
Writer / Export
Looking at export_set in eeglabio, it has an argument ref_channels that is not used by the export code. If I'm not mistaken, the referencing information is present in Info, so it could be passed to the .set file via this argument.
eeglabio.raw.export_set(
        fname, data=raw.get_data(picks=ch_names), sfreq=raw.info['sfreq'],
        ch_names=ch_names, ch_locs=cart_coords, annotations=annotations)

Support for channel type is not included in eeglabio, I would like to add it https://github.com/jackz314/eeglabio/pull/4
Once added to eeglabio, the exporter could make use of this additional argument.

TODO:

[x] Add support for MNE channel types in the reader (#9990)
[ ] Add a warning when exporting with unapplied projectors + warning in documentation ()
[ ] Add support to export MNE channel types (depends on jackz314/eeglabio#4)

Sounds good! However, MNE does not keep track of the reference channel so unfortunately this won't work automatically.

@cbrnr Arf! Too bad for that, but to be honest my main priority is the channel types :)
Now that I think about it, what about projectors that are not yet applied? I think, for now, the export is not applying them.. maybe we could add a proj argument also to add the possibility to apply them prior to export.
If so, we could also check for the presence of a common average reference projector, in which case we could set ref_channels='average' during the export. If MNE is not keeping track of the reference channel(s), then I think this is the only case in which ref_channels can be define.

True, but I'd rather leave it to the user to define what they want to export. That way, we don't have to add another parameter (which as you correctly say only works for that single case).

But projectors may contain other types of projectors that the user may want to set. I think the method .apply_proj() is not very well known because of the argument proj present in many MNE functions. At the very least, I think the export should not silently get rid of the projectors without any warning for the user in the docstring / notes section.

EEGLAB is mostly used for EEG analysis, and setting an average reference in MNE does not use a projector by default. The other popular projector in MNE is SSP, which is used in MEG analysis. I think if someone uses one of these two projectors in EEG analysis (or some other custom projector), they probably know what they are doing and should be able to apply_proj() before exporting. But yes, feel free to mention this explicitly in the docs (and also issue a warning if there are unapplied projectors).

Sounds good! However, MNE does not keep track of the reference channel so
unfortunately this won't work automatically.

what do you mean?

I think he meant that if you reference to a specific channel, e.g. CPz, this information is lost and all you know is that a custom reference has been applied, but not which one.

@cbnr what was the reason for this? we have no fif constant tag to store
this?
note that the info['chs'][0]['loc'][3:6] should contain the location of the
reference for EEG channel of index 0
but this is still  not done properly. I was not aware of this FIF
requirement when this was written years ago...

what was the reason for this? we have no fif constant tag to store this?

Yes. And my opinion is still that we should move beyond FIFF when it is holding us back. EEG data is not stored in FIFF very often, and I believe other formats such as EDF or BrainVision do support storing the reference name.

@cbrnr @agramfort Related to this, mne.io.proj._needs_eeg_average_ref_proj is not doing what it's supposed to.
# ANT Neuro dataset referenced to 'CPz' by the amplifier
raw= mne.io.read_raw_fif(fname,  preload=True)

_needs_eeg_average_ref_proj(raw.info)
Out: True

raw.set_eeg_reference(ref_channels=['M1', 'M2'])
_needs_eeg_average_ref_proj(raw.info)
Out: False

@agramfort @cbrnr

what was the reason for this? we have no fif constant tag to store this?

Yes. And my opinion is still that we should move beyond FIFF when it is holding us back.

We discussed this before, and yes, I too believe this is a massive lack we need to resolve for EEG users.
Here's the discussion thread, in which we discussed some concrete ideas how to best address this:
https://github.com/mne-tools/mne-python/issues/8962

I would phrase it as "we should extend the FIF spec when it's holding us back." So far the times we've done it I think it has forced us to really think about and distill what's necessary about the new information. Without this constraint (e.g., if we adopted a looser approach for example based on HDF5) I imagine things would have been messier long term.

... and I think #8962 is good example actually, even though we haven't settled on a solution there

... and I think #8962 is good example actually, even though we haven't settled on a solution there

I'd like to second that

can we discuss this tomorrow during the MNE office hours?


expireMaxSize vs expireStoreSize

I'm using the HTreeMapMaker and not clear on
MaxSize of Map vs StoreSize.
I think the DB is store - why is this method on a single collection, since I could be using a Q or such.
What is different btwn 2?

It is in javadoc.


ArduPilot - Problem identified that may be causing the mission module to fail (fly_mission example)

Hello, I have found a possible cause of this issue of the mission module failing in ArduPilot.
Using Wireshark, I analyzed the network traffic between my ArduPilot SITL (running inside a WSL2 Docker container that runs the latest ArduPilot Docker image) and the MAVSDK example (running inside WSL2 as I was having issues running it in Windows 10). My MAVSDK library and my fly_mission binary were built in debug mode using CMake through CMake Tools in VSCode (using VSCode WSL Remote session).
Here is my terminal output:

There is a debug message saying the gimbal version is v1, and that the mission is unsupported.
Examining Wireshark, the last message sent before the MISSION_ACK message containing the MAV_MISSION_UNSUPPORTED payload was MAV_CMD_DO_MOUNT_CONFIGURE (204).
When gimbal angles are defined in a mission_item, the gimbal version is verified: https://github.com/mavlink/MAVSDK/blob/fadfe22e7c053945107201e2638be9a7f8b8ee5c/src/mavsdk/plugins/mission/mission_impl.cpp#L460
We then use the version above and send a version specific message containing the gimbal configuration. Below, we see that the unsupported message is sent if the gimbal version is assumed to be v1, as is the case in my console output:
https://github.com/mavlink/MAVSDK/blob/fadfe22e7c053945107201e2638be9a7f8b8ee5c/src/mavsdk/plugins/mission/mission_impl.cpp#L1188-L1221
It appears that MAVSDK is not finding out the supported gimbal version. Gimbal v1 is deprecated in ArduPilot as of version 4.3. Wireshark shows that no GIMBAL_MANAGER_INFORMATION (280) messages were sent from the AP and no MAV_CMD_REQUEST_MESSAGE (512) message from MAVSDK requesting the gimbal version was sent. The GIMBAL_MANAGER_INFORMATION message is what the gimbal module uses to set the gimbal version.
I propose the following two solutions. I think the latter is more inclusive to more ArduPilot versions but the former could be implemented quicker:

default to v2 if ArduPilot is detected
send a request for GIMBAL_MANAGER_INFORMATION if ArduPilot is detected

What do you all think?

Thanks @trolledbypro for looking into this! :rocket:
I think I would be in favour of a third version: drop gimbal v1 entirely and always assume v2. There are many problems with the detection anyway.
One that I learn here is that the mission module needs to know about the gimbal protocol, so either we need to duplicate the detection that we already have in the gimbal module, or we need the mission module to depend on the gimbal one somehow (which we have never done with any plugin before).
But on top of that, the detection we have in the gimbal module is fundamentally flawed (and the root cause is in the MAVLink design): MAVLink does not offer a mechanism to differentiate between a timeout and an unsupported message (many modules just ignore commands they don't support, and the MAVLink specs allow a broadcast command which require this behavior). So we can be sure that a drone supports Gimbal v2 when everything works ("yay I received a v2 message, I know it supports v2"), but we can never be sure that it does not support v2 ("I did not receive a v2 message, is it because the drone does not support v2, or is it because the messages were lost?"). We could probably do more convoluted heuristics (like "I got 3 timeouts for the gimbal v2 requests while I received X messages from the drone, so I will say that I am reasonably confident that it was not a timeout"), but... well is it worth it?
I don't know of a single drone that uses Gimbal v1, and v2 has been out there for years. Maybe it is time to drop v1 entirely.
@julianoes what do you think?

Hey @JonasVautherin,
By looking into the Gimbal module code and at my debugging, it seems that the Gimbal module init and enable methods are not being called: https://github.com/mavlink/MAVSDK/blob/fadfe22e7c053945107201e2638be9a7f8b8ee5c/src/mavsdk/plugins/gimbal/gimbal_impl.cpp#L29-L49
These methods establish the gimbal version. The absence of these methods being called is causing a timeout which creates an assumption that gimbal v1 is present:
Here is the code that makes the thread wait for the version https://github.com/mavlink/MAVSDK/blob/fadfe22e7c053945107201e2638be9a7f8b8ee5c/src/mavsdk/plugins/gimbal/gimbal_impl.cpp#L197-L208
Here is the timeout code that sets it to v1
https://github.com/mavlink/MAVSDK/blob/fadfe22e7c053945107201e2638be9a7f8b8ee5c/src/mavsdk/plugins/gimbal/gimbal_impl.cpp#L56-L63

Hmm even if you instantiate a Gimbal object in your code? The plugins are initialized lazily, maybe you need to call one of the gimbal functions for it to start :thinking:

I edited set_mission example to instantiate a Gimbal object and run set_mode and it still failed. Both the gimbal and mission modules experienced a gimbal mode timeout and defaulted to gimbal v1:

Both the gimbal and mission modules experienced a gimbal mode timeout and defaulted to gimbal v1

Hmm, so the way we currently detect gimbal v2 is maybe not working with Ardupilot?
But that brings be back to my question above: no need to fix the detection for Ardupilot if we just default to v2 and drop v1 entirely. @julianoes what do you say?

I talked with Julian, and he agrees that we should drop gimbal v1. I won't be able to do that before 2 weeks because I am going on holidays, so... @trolledbypro if you want to do it before then, feel free! Just remove the detection and default to v2, and you can also remove the v1 implementation files. Really it shouldn't be very hard.
Otherwise I'll give it a shot when I'm back. Does that work for you @trolledbypro?

@JonasVautherin I'll make a branch in my fork and get to work, should be doable for me (especially within 2 weeks)

Amazing, keep me posted!

First I want to investigate why the GIMBAL_MANAGER_INFORMATION ( #280 ) command is not being sent. I am seeing the MAV_CMD_REQUEST_MASSAGE from MAVSDK being sent and the MESSAGE_ACK from ArduPilot accepting the request. I'll step into ArduPilot and see what is up.
While stepping through ArduPilot source code I am seeing that a condition is not being met to allow for the command to be sent back.
I want to see if this is a big or if this is an incompatibility with the way MAVSDK is trying to determine the version. I will contact work with the ArduPilot devs to figure that part out.

Another update: MAV_CMD_DO_GIMBAL_MANAGER_CONFIGURE (1001) is not implemented in ArduPilot. This command is used here https://github.com/mavlink/MAVSDK/blob/e7657c2d87917df739186981f34f98a14c898893/src/mavsdk/plugins/mission/mission_impl.cpp#L1288-L1312 and is called here https://github.com/mavlink/MAVSDK/blob/e7657c2d87917df739186981f34f98a14c898893/src/mavsdk/plugins/mission/mission_impl.cpp#L459-L480

These are two issues I made in ArduPilot that should make gimbal control work with MAVSDK:
https://github.com/ArduPilot/ardupilot/issues/24691
https://github.com/ArduPilot/ardupilot/issues/24691
ArduPilot has yet to implement acquiring and removing gimbal control as defined in gimbal v2 protocol, so my solution is to accept MAV_CMD_DO_GIMBAL_MANAGER_CONFIGURE as a mission_item and have it do nothing until gimbal control is implemented or I get the time to have it modify the gimbal control struct added by the ArduPilot PR mentioned in my previous comment (that is presently being unused).


Add "Support" section to README

I like the template but I'm skipping it for this one

@PatrickCleary yes there's a PR template for the Data Dashboard, I just didn't do it here for this one :wink:


admin: Replace "deactivate" and "make admin" on /organization/user-list-admin with something nicer

Right now, our "user list" view in the admin settings doesn't look that good, in large part because the "actions" buttons on the right are quite large.
There are 2 approaches we could consider:

Replace the buttons with icons, making "actions" take up less space, and then increasing the size of "name".
Probably a better long-term solution would be to just move these into the "edit" widget that lets you change names as well, and just indicate whether the user is an admin or not via a little crown icon next to their name in the view.

I could imagine doing the first piece as a quick solution, since it's probably very little work, and then doing the second longer-term.

@zulipbot claim

@zulipbot claim

@zulipbot  claim