How to define arbitrary extensions for recursive datatypes?

Hi,
I'm looking for a way to add arbitrary to types that are recursive, e.g.
struct List {
   let head: Int
   let tail: [Int]
}

Knowing QuickCheck in Haskell, the impulse is to write
extension List {
   public static var arbitrary: Gen<List> {
       return Gen<List>.one(of: [
           Int.arbitrary.map { List(head: $0, tail: []) },
           return List.arbitary.flatMap { (list: List) in
               Int.arbitrary.map { (i: Int) in
                   return List(head: i, tail: list)
               }
           }
       ])
    }
}

knowing that the probability of this sequence ending after some finite number of elements is 1. But obviously, in a strict language like Swift this can't work, since List.arbitrary will just call itself endlessly. Short of having to somehow manage a maximum depth myself, is there anything I can do to emulate this?

Sorry, I probably didn't explain correctly. The problem is that all of the elements of the array passed to one(...) are evaluated strictly before the function is called. That's what causes the endless recursion. That wouldn't be a problem in a lazily evaluated language like Haskell.
I'm currently testing this workaround, which seems to be able to do the job at least for the time being:
extension Gen {
    public static func lazy(_ gen: @escaping () -> Gen) -> Gen {
        return Gen<Bool>.pure(true).flatMap { _ in
            return gen()
        }
    }
}

Ah! Of course. I see, the compiler is trying to unroll the recursion right away.
Thanks for explaining it again ^^
Yes, making a lazy extension to it like you're doing is probably the best approach.
Maybe SwiftCheck needs a LazyGen? 🤔 I don't know enough about its design, so I couldn't say.

I'd love to see such a functionality included in SwiftCheck. Swift in fact includes laziness to some extent with the use of autoclosures.
Unfortunately this seems to be available only with parameters, not as a general modifier, so I guess you can't have something like an [@autoclosure ()-> Gen] so you could change the signature of one(of:) from:
public static func one<S : BidirectionalCollection>(of gs : S) -> Gen
	where S.Iterator.Element == Gen, S.Index : RandomType

to:
public static func one<S : BidirectionalCollection>(of gs : S) -> Gen
	where S.Iterator.Element == @autoclosure () -> Gen, S.Index : RandomType

Maybe they could add a one(of:) method with a variable number of @autoclosure arguments the same way zip methods are generated?

BTW, I think the lazy extension could be as simple as:
extension Gen {
    public static func lazy(_ gen: @autoclosure () -> Gen) -> Gen {
        gen()
    }
}


Element screenshot

This adds screenshot method to WebDriverElement class. Depends on pillow.
Fixes #500 and supersedes #384.
I also updated phantomjs to 2.1.1 on travis since old version hangs.

BTW, is there any way to run only one single test from the test suite?

Not passed all the tests, some things are failing

I tweaked travis config a little, to fix chrome tests, but some tests in the suite still fail:

Firefox - test_simple_type
Phantomjs - cokies-related tests
Python 3 - some type related failures

None of this is caused by my commits.
Tests actually fail on every pullrequest in queue.

@andrewsmedina This (at least by title) also seems to be eclipsed by #617

@abathur  you are right. I will close this.


Load 3rd party script files from jupyter server (if this fails, then fallback to download using internet connection). (2)

Closing for now, not a use case we might want to support (at least not yet), until required.

For first release make sure the error that occurs tells the user we can't load a third party widget without an internet connection. If there is an internet connection, just say the widget is not supported.

@rchiodo I couldn't get this to work

Oh that's likely. For me it happened after execution was complete, so no more messages came through.

Probably have to add a message to send the new output back to the extension side and have it add the cell output.

Note, this is really just if the internet can't find the widget (like azureml), then we show an error to the user.


chore(TypeScript): 🏷 Improve typings and configs

What is the purpose of this Pull Request?
Improve types by adding support for all supported JavaScript runtime environments:

browsers
bun
Deno
Node.js

And add ts-reset to improve the standard library.
Type of this Pull Request

🔧 Configurations changes

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
296

Relevant Lines:
296

💛  - Coveralls


Motorcycle-details

In This PR I :

Create API for Motorcycle
Create API for Reservation
Create API for User

Thanks @jonas-45


use first frame as thumbnail for review (quadproduction/issues#240)

Changelog Description
Add thumbnail to Houdini review.
Additional info
If the thumbnail is not already set, use first frame for the thumbnail.
Testing notes:

Checkout to this branch and tun Openpype.
Open Houdini and publish a review. (example: Project=TEST_OP2_PUB_23_7, Asset: chair, Task: model)

Merged into 3.16.9-quad-1.2.1


PK badge is unstyled?

That doesn't look quite right to me x)

came in here to check if someone had reported this already. it broke with a recent discord update

Discord broke this again. Thank you, Discord, for making more work for our devs.

Can we reopen this?


Update Rust API (async / .await)

Update Rust API:

to utilize async / .await

request v.10

Update example to include scanning and alerts

The following files were manually updated, and assistance/guidance may be needed to auto-generate plugins (@thc202)

ajax_spider
alert_filter
import_log_files
importurls
openapi
replacer
reveal
selenium
soap
websocket

PR to main ZAP repo for Rust API generation: https://github.com/zaproxy/zaproxy/pull/6227

Once the other PR is merged we can use it in the add-ons, to generate the other files.
@cak are you available to set up CI (with GitHub Action)? It would be great to have that check.


Capstone Project Review

Used colors, typography and layout from Cindy Shin's template.
Used mobile-first approach.
Added 'Featured Speakers' sections dynamically using JavaScript DOM.

Adjusted the 'More and Less' button.
The walkthrough video was already included in the README.md file.


Imports

This is a proposed system to support safer imports of java classes.  Unfortunately it only works for Python 3.6 as the support hooks for 2.7 are not good enough.   It prevents accidental use of non-imported classes which improves type safety and makes python code more robust to code refactors of the java code.  We have been using this in module for a month, but have not used it on many alternative platforms.  It supports some slight exotic features such as placing python code into netbeans projects.  We are working on directly being able to store a python package to support the use of java classes in the jar, but that support is not ready for distribution.   I have included the basic imports system with hooks and the corresponding documentation.  Testing scripts will still need to be developed.

thanks this looks really useful. Can you add a simple test as well? eg. the examples you've given in the documentation (great!) would be absolutely sufficient.

Ah alright :+1:
I also can not spot any Py-3.6 exclusive feature usage. Maybe we can
make it compatible easily?

Working on the test cases now.   Just need to figure out the assertion system.   The 3.x dependency is on the importlib.  I tried for a day to figure out a similar hook, but couldn't find anything similar without a monkey patch.   I can't be sure if it really requires 3.6 as the hooks appear at different times during 3.  I suspect that after 3.4 it will work.

I have merged my local production copy back into this branch and added tests.  Currently the 5 new test show as pass on the jpype.imports system.  Unfortunately, my production system is cygwin, so I am having to back port changes to keep a clean copy until we get a clean cygwin test pattern.  If you have some way to get importlib functionality on 2.7 (barring a monkey patch), I can backport the jpype.imports code.

As suspected it passes checks on 3.4 on.  I had to remove nightly as it has crash that is not related to my patches.  Please review and advise.  I can remove any functionality that you find too exotic to support long term.

LGTM 👍


THREAT - A user can vote multiple times (count as multiple votes) in an election.

Scenario
Whenever the frontend sends an encrypted ballot to the backend to sign, the backend will include the userID of the user in the ballot and sign the msg. This design will allow every user to vote at most once. However, since we are using Tequila as our login server, thus it is hard to create multiple valid users in Tequila during backend testing. A workaround was created. Backend implements a function called “makeID” to create a random ID and sign it along with the encrypted ballot. This will allow a user to vote multiple times which counts as multiple votes. And this function is not yet removed until now. Thus an adversary can vote as many times as he wants to manipulate the election results.
Source
In the file “web/backend/Server.ts” function app.use(‘/api/evoting/*’)
app.use('/api/evoting/*', (req, res) => {
. . .
// special case for voting
  const regex = /\/api\/evoting\/elections\/.*\/vote/;
  if (req.baseUrl.match(regex)) {
    // We must set the UserID to know who this ballot is associated to. This is
    // only needed to allow users to cast multiple ballots, where only the last
    // ballot is taken into account. To preserve anonymity the web-backend could
    // translate UserIDs to another random ID.
    // bodyData.UserID = req.session.userid.toString();
    bodyData.UserID = makeid(10);
  }

function makeid(length: number) {
  let result = '';
  const characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
  const charactersLength = characters.length;
  for (let i = 0; i < length; i += 1) {
    result += characters.charAt(Math.floor(Math.random() * charactersLength));
  }
  return result;
}

Breaking Property
Availability, Auditability
Risk
CVSS score:  6.5/10
Mitigation
Remove the makeId function. If the developer prefers to keep the function for testing, we can set an env variable in config.env to determine this environment, which production environment would use User Id and the Dev environment would use Fake Id.

Perhaps we can put something like https://create-react-app.dev/docs/adding-custom-environment-variables/ in the code so it automatically chooses the debugging feature or not. Even though I did not completely understand whether NODE_ENV would serve our needs here.

I think indeed NODE_ENV could be the right approach here. That's what I've used in other projects and it makes things rather simple.

I think indeed NODE_ENV could be the right approach here.

Currently we took the even simpler approach of adding a console.warn("DEBUG code")


Policing storage requirements

From my understanding of the storage requirements for policing the network it should be
54000 * 300000 * 328 bytes per attestation ~5.4 Tb
54000 * 2344 committees per epoch * 328 bytes ~ 41gb using aggregated attestations
8 months of proposals and validation data
if those are the requirements I guess we at Prysmatic labs will go with this design https://docs.google.com/presentation/d/1MkLraDsZJCX3k62bBtt8ziUdw308U2bW_w0lUmV-0YQ/edit?usp=sharing

See https://github.com/ethereum/eth2.0-pm/issues/63 for a discussion on the expectation that normal validating nodes will shard policing responsibility

Going to close this issue. I suggest taking the discussion to the issue linked above


Allow players to simultaneously request the battle timer

This allows both players to request that the timer be turned on, which helps prevent one of them from timer-stalling by repeatedly toggling the timer on and off. It also allows staff to stop such a thing by turning the timer on themselves.

npm test
failute

Unrelated, but: another problem with battles is when a player sets modchat, voices their friend and they're toxic so the other player devoices them, and then all of a sudden there's a re-voice war going on.

I feel like /ignore is the proper use for that situation.

I get what he's saying, but I'm wondering is whether he actually is going
to do the refactor first or not.
On Sun, Apr 9, 2017 at 11:17 PM, panpawn<EMAIL_ADDRESS>wrote:

@panpawn commented on this pull request.
In rooms.js
https://github.com/Zarel/Pokemon-Showdown/pull/3438#discussion_r110569349
:

@@ -933,16 +933,34 @@ class BattleRoom extends Room {
}
requestKickInactive(user, force) {
if (this.resetTimer) {

	if (user) this.sendUser(user, '|inactive|The inactivity timer is already counting down.');

	return false;

	let timerSetByUser = user && (this.resetUser === user.userid || (user in this.game.players && this.resetUser === '+'));

@MacChaeger https://github.com/MacChaeger - Zarel is saying that he'd
probably want to do the refactor first, and then have you rebase this with
the master branch after his refactor so that it doesn't further
complicate the rewrite.
When he does, it will say on here that there are conflicts that need to be
resolved, and at that point, you can then rebase it, and if you need help,
then ask me. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Zarel/Pokemon-Showdown/pull/3438#discussion_r110569349,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AULj4FrtjyMclQARCQjkze8hU_siPu6Fks5rua0_gaJpZM4M3H-A
.

Yeah... not all players are that smart or responsible

whoops


Item creation very verbose

If you create a lot of items at ones in a shop, you get massive amounts of notifications.

Fixed in: https://github.com/jopeek/fvtt-loot-sheet-npc-5e/pull/122


Add caller to token.send call

Description
This commit adds an optional caller input argument to the token.send call. By setting caller to the accountUpdate that's being used to authorize a token transfer, we let the token contract be callable by other zkApps.
If one zkApp calls on a token contract to authorize a transfer, the caller field of the token contract AccountUpdate must be set to the token id of the calling zkApp.
This is an initial stab at fixing https://github.com/o1-labs/snarkyjs/issues/431
Code Example Changes
The code for a transfer method on a token contract would now look like:
@method transfer(
    from: PublicKey,
    to: PublicKey,
    value: UInt64,
    caller: Field
  ) {
    this.experimental.token.send({ from, to, amount: value, caller });
  }

The code for a zkApp to call into the token contract would look like:
@method supplyLiquidity(user: PublicKey, dx: UInt64) {
  let tokenX = new TokenContract(this.tokenX);
  tokenX.transfer(user, this.address, dx, this.experimental.token.id);
}

This was a draft PR to unblock some features. This is no longer needed.


Keep expanded items open after rename.

@isidorn i think its ok, if you want to move the implementation on treeModel i can do it but not before sunday.
#44230
ps: maybe there is some formating issues. i did this from my phone. :)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: ntovas sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@ntovas you should not touch the treeModel for this.
Tree should have some api to get all expanded.
I will review this PR next week as we are currently in the endgame and are wrapping up our milestone

@isidorn I will create an api for this until next week.
I am thinking to take a parameter to return the expended childrens and if no parameter was passed to return all the expended for the workspace.

@ntovas probably not the best idea, we take only limited changes in the tree area.
fyi @joaomoreno as the tree owner

@isidorn So i should leave it as is and let someone more experienced contributor to refactor it?

The tree doesn't need new API for this. The explorer knows about the rename operation. It knows about expansion states of all elements. It should easily be able to reset those expansions.

@joaomoreno as far as i checked the code, there is no method to get all the expanded items.
The current implementation is hidden inside the method onFileOperation() of explorerView, i believe thet it will be better to be implemented as stand alone method in order to be used in other cases and keep the DRY principle.
@isidorn do you think that there should be some limitation to recursion in order to avoid edge cases ex symlink loop?

There is a getNavigator method and a isExpanded one.

@isidorn  is it ok now?

@ntovas thanks for your work. However a proper way to do this is as @joaomoreno already specified by using the tree navigator. That will make the code much less complex and no need for an additional helper method. Please try that approach

Closing as outdated


Buttons for AutoReconnect and AutoPlay

We need to add buttons for this two features.

Good job, Pyro. Closing this now as it's already in the client.


Fix Server.attached_sessions return type

Server.attached_sessions was documented to return a tmux session object or None but was returning a list of session dicts or None.

It's not clear to me what the right fix is (the note in the docs makes it sound like maybe the list will only every be length 1?) but was going to raise an issue and thought I'd take a whack at it instead.

@thomasballinger Greetings!
Nice, I'm taking a look!  Can you rebase this so the tests run? I want to be sure it doesn't cause any regressions on older tmux versions.

I made a change at https://github.com/tony/tmuxp/commit/150fd9c9b921b4a941de71ed560ea1058a4073ad to fix travis tests.

Nice @thomasballinger, you're becoming the tmuxp master


feat(AUTH-CPC-213): add read and delete to user

Added get, getAll and delete for Users.
Added test.

LGTM


Azure Event Grid: New features for 2023-12-15-preview API version

ARM (Control Plane) API Specification Update Pull Request
Add new features for Azure Event Grid API version 2023-12-15-preview. These features include:

Push functionality with EventHub as destination
Deadletter support.
Monitor Alert Event Subscription as destination.
Namespace Topic as destination.
New property (additionalEnforcedPermissions) for TopicTypeProperties.
Network Security Perimeter.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

[1] ARM review queue (for merge queues, see [4])
The PRs are processed by time opened, ascending. Your PR may show up on 2nd or later page.
If you addressed Step 1 from the diagram and your PR is not showing up in the queue, ensure the label ARMChangesRequested
is removed from your PR. This should cause the label WaitForARMFeedback to be added.
[2] https://aka.ms/azsdk/support/specreview-channel
[3] List of SDK breaking changes approvers in pinned Teams announcement
[4] public repo merge queue, private repo merge queue (for ARM review queue, [1])
If you need further help with anything, see Getting help section below.
Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

[X] New API version. (Such PR should have been generated with OpenAPI Hub).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix swagger quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[X] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[X] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to Step 2, "ARM Review", for this PR.

Breaking changes review (Step 1)

If the automation determines you have breaking changes, i.e. Step 1 from the diagram applies to you,
you must follow the breaking changes process.
IMPORTANT This applies even if:

The tool fails while it shouldn't, e.g. due to runtime exception, or incorrect detection of breaking changes.
You believe there is no need for you to request breaking change approval, for any reason.
Such claims must be reviewed, and the process is the same.

ARM API changes review (Step 2)

If this PR is in purview of ARM review then automation will add the ARMReview label.
If you want to force ARM review, add the label yourself.
Proceed according to the diagram at the top of this comment.

Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.
Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
Getting help

For general PR approval workflow, see the diagram at the top of this comment.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

@rkmanda
Can you please help review the PR and sign off from ARM side?

@tadelesh
Can you please help review this PR. We addressed most of the lindiff issue and remaining ones seems to be infra/tools issues and false positive.
Also, please help us mark this PR for ARM review as the label is reset and I am not able to set it back to Wait for ARM feedback.

@a-hamad please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree company="Microsoft"

Hi @a-hamad,
There're some false positives detected in the lint diff check because the url is
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.EventGrid/{resourceType}/{resourceName}/networkSecurityPerimeterConfigurations/{perimeterGuid}.{associationName}, please follow the Swagger-Suppression-Processto get approval.

Hi @a-hamad, There're some false positives detected in the lint diff check because the url is /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.EventGrid/{resourceType}/{resourceName}/networkSecurityPerimeterConfigurations/{perimeterGuid}.{associationName}, please follow the Swagger-Suppression-Processto get approval.

hello @ms-henglu, the suppression for the LintDiff is added in the readme for 2023-12-15-preview swagger and the check is passing now. Somehow, I am not able to change labels to "SuppressionReviewRequired". Can you please help getting right settings access to get label control and please review the suppression?
@Kishp01,
Can you please help setting the label to "SuppressionReviewRequired" here for now?

/pr RequestMerge


How to create new fairseq dictionary for Custom InfoXLM training?

I'm training an InfoXLM model on a custom dataset.
To do this, I'm first training a sentencepiece tokenizer and then converting this tokenizer to huggingface format to make the tokenizer compatible with python unilm/tools/txt2bin.py  (I'm following the instructions from here).
I am now confused about how to generate the fairseq dictionary dict.txt to place in the data_dir.
One possible solution would be
cut -f1 sentencepiece.vocab | tail -n +5 | sed "s/$/ 100/g" > dict.txt

^ creating a new fairseq dictionary with a dummy frequency (say 100) and removing <unk>, <s>, <pad> and </s>  tokens from the sentencepiece dictionary as fairseq dictionary seems to automatically add these tokens.
Do you foresee any problems with this approach or do you recommend creating the fairseq dictionary in any other manner?

@CZWin32768 @donglixp
Please let me know if this method of dictionary creation would directly work.
My main concern is if there could be a mismatch between the mapping of sentencepiece tokenizer (during tokenizer.encode method in txt2bin or para2bin) and fairseq dict.txt during training.


When autoplay on, the app should add songs to the end of the queue

    Not an issue on youtube music. When autoplay on, the app should add songs to the end of the queue.

On youtube music, when the queue ends and autoplay is on, a song is added to the queue:

On the desktop app, the song doesn't get added and the queue restarts:

Originally posted by @tasawe in https://github.com/Venipa/ytmdesktop2/issues/43#issuecomment-1325777354
This is an issue only on the desktop app.

can you show me the full vertical on the playlist?

if autoplay is on there should be a list on the bottom which gets added, if there isnt than its not a eligible playlist for autoplay

just realized i had the replay option on, not really an issue


Update validations.py

Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

ggg


feat: Implement new Android 12 splashscreen

GitHub Issue: #
PR Type
What kind of change does this PR introduce?

Feature

Description

Implement new Android 12 splashscreen for all Android OS versions.
PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Interface members are XML documented
[ ] Documentation (XML or comments) has been added and/or existing documentation has been updated
[ ] Architecture documents have been updated
[x] Tested on all relevant platforms

Other information

Internal Issue (If applicable):

https://dev.azure.com/nventive/Practice committees/_backlogs/backlog/Mobile (.Net)/Features/?workitem=260066

New Android as Android 12 right ? Worth mentionning it I think, we may have other update for other Android version spalshscreen changes :)

@jeanplevesque @carlh98 is this PR still relevant, or should we abandon it, since I believe this is outdated for .NET 6 support soon merged ?

@jeanplevesque @carlh98 is this PR still relevant, or should we abandon it, since I believe this is outdated for .NET 6 support soon merged ?

@vincentcastagna It's outdated and will need to be re-done after the dotnet-6 merge.

@vincentcastagna @jeanplevesque Yes this PR will be redone in the net6 branch


⚠ LPDM Handbook (hosted on Divio) has degraded performance

In 74bd341, LPDM Handbook (hosted on Divio) (https://repohubdev.tk) experienced degraded performance:

HTTP code: 500
Response time: 5155 ms

Resolved: LPDM Handbook (hosted on Divio) performance has improved in 97e329b.


Aqua + typos CI

Aqua found possible type piracy.
Should those methods be upstreamed?
total_degree, vars

I don't think so. Why wouldn't those two methods get upstreamed? They seem like generally useful functions for the package that defines the algebraic types?

@ArnoStrouwen Thanks!

In addition, I suggest beautiful_generating_set instead of beautifully_generators/beautifuly_generators.
@pogudingleb

I also like this better. Another option would be to simplify_generators

Why wouldn't those two methods get upstreamed?
They seem like generally useful functions for the package that defines the algebraic types?

I agree with Chris, at least for vars, I have created an issue for this.

Superseded by #274


Certificate

Hey,
if i run my coffeescript there aren't any errors, but i can't find this folder ".http-mitm-proxy/certs/ca.pem".
It's not even shown when unhiding hidden folders.
The example scripts don't generate a certificate, too.
Do you have any idea? Thanks in advance.

Please take a look at the readme, there are instructions given for this situation - Cheers!


Supported python versions

Python Version
n/a
Django Version
n/a
Package Version
1.0.0
Description
Hi!
Thanks for creating this!
I just had a quick question about your supported Python versions:
    Programming Language :: Python :: 3.6
    Programming Language :: Python :: 3.7

Since you utilize end_lineno, here, I think you'll have troubles on Python versions earlier than 3.8, since I believe 3.8 was when end_lineno was added (see this).
Just wanted to open this in case you were not aware of this yet - or even better, that you are aware of some backport that enables you to use end_lineno with earlier Python versions, that I don't know about; If that exists please let me know!

I already know this, I just released this project yesterday to PyPI to secure the name. Fixing Python 3.8 compat in #5. Will consider whether 3.6 and 3.7 support is worth it, because it makes the fixers significantly harder to write without the end_lineno attr.


[FEATURE] Badge maker styles

Description
All the user to choose which style he want his badge to be in
Screenshots
No response
Additional information
I would like to work on this

This is a good suggestion, but I think for now, until we have more users, I am going to close this for now


Enable altitude as an input

I'd love to use try out this library for a satellite application, but I can't figure out how I would modify it accept an input altitude. Any advice on how I could do that?

The algorithm is based on work done by NOAA, and is documented on their website at: https://www.ngdc.noaa.gov/geomag/WMM/
The stated purpose of the algorithms developed by NOAA is specifically to provide a predicted value of magnetic variation at the Earth's surface.  I'm sure someone, somewhere has a more comprehensive, and complex model, for the environs in low earth orbit as well.  (JPL? GSFC? NASA? DoD?)  Offhand, I don't know where such a thing lives though.  It's a very special use case.

I'm pretty sure the WMM is intended for satellite applications as well. I've read several satellite attitude determination papers that use it. Also see page 6 of the state of the magnetic field report linked on the website you gave that discusses the models inclusion of altitudes up to either 490 or 700 km.
On Sat, Feb 05, 2022 at 9:07 PM, Dave Armstrong < @.*** > wrote:

The algorithm is based on work done by NOAA, and is documented on their
website at: https:/ / www. ngdc. noaa. gov/ geomag/ WMM/ (
https://www.ngdc.noaa.gov/geomag/WMM/ )
The stated purpose of the algorithms developed by NOAA is specifically to
provide a predicted value of magnetic variation at the Earth's surface.
I'm sure someone, somewhere has a more comprehensive, and complex model,
for the environs in low earth orbit as well. (JPL? GSFC? NASA? DoD?)
Offhand, I don't know where such a thing lives though. It's a very special
use case.
—
Reply to this email directly, view it on GitHub (
https://github.com/DavidArmstrong/WMM_Tinier/issues/1#issuecomment-1030747741
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AC4ANHYRZTUBNTOJGNEKF63UZXXZLANCNFSM5NUYETKA
).
You are receiving this because you authored the thread. Message ID: <DavidArmstrong/WMM_Tinier/issues/1/1030747741
@ github. com>

Yep. I chose to use that WMM Tiny library as the baseline code for this library, simply to keep the code size down as small as possible. Most Arduino platforms have a memory constraint that one has to work in when designing a sketch. Even this library won't go into a standard Uno board. A Teensy 4.0 board probably has enough space for a more complete implementation, but that leaves out a lot of other platforms.

Closing since no further comments after more than six months.

I have a more complete implementation that can run on the Uno board here: https://github.com/nhz2/XYZgeomag
Unlike WMM Tiny, where:

The intention of this project is to reduce the code space as much as possible at the expense of RAM. This makes it suitable for small embedded processors short on code memory but with 4.2 kBytes of RAM available. The coefficients are compressed in code but are expanded back into their normal format in RAM when the code runs.

I store the coefficients uncompressed in flash, so more flash is used, but less RAM is used. The Uno has 32 KB of Flash and 2 KB of RAM, so this works out better on that board.

Very cool! I've starred it and taken note for when we revisit this!
On Tue, Mar 21, 2023 at 9:56 AM, Nathan Zimmerberg < @.*** > wrote:

I have a more complete implementation that can run on the Uno board here: https:/
/ github. com/ nhz2/ XYZgeomag ( https://github.com/nhz2/XYZgeomag )
Unlike WMM Tiny, where:

The intention of this project is to reduce the code space as much as
possible at the expense of RAM. This makes it suitable for small embedded
processors short on code memory but with 4.2 kBytes of RAM available. The
coefficients are compressed in code but are expanded back into their
normal format in RAM when the code runs.

I store the coefficients uncompressed in flash, so more flash is used, but
less RAM is used. The Uno has 32 KB of Flash and 2 KB of RAM, so this
works out better on that board.
—
Reply to this email directly, view it on GitHub (
https://github.com/DavidArmstrong/WMM_Tinier/issues/1#issuecomment-1478096837
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AC4ANH25PBCQ726M23HSUD3W5HFRDANCNFSM5NUYETKA
).
You are receiving this because you authored the thread. Message ID: <DavidArmstrong/WMM_Tinier/issues/1/1478096837
@ github. com>


Interpreting malformed chemical formulas as substances

Hi, thanks for the ChemPy package! As I was using Substance.from_formula, I noticed  that one could easily make a mistake in the formula string and not be notified about it. For example, if I wanted to add methanol, if I don't make any mistakes it works great:
>>> from chempy import Substance
>>> methanol = Substance.from_formula('CH3OH')
>>> methanol.name
'CH3OH'
>>> methanol.composition
{6: 1, 1: 4, 8: 1}

If I make a minor mistake, for example forgetting to capitalize the first H for hydrogen, ChemPy gives no warning and simply stops at the last valid element. So the formula string is interpreted as simply C for carbon, even though the name is the entire supplied formula string Ch3OH:
>>> c = Substance.from_formula('Ch3OH')
>>> c.name
'Ch3OH'
>>> c.composition
{6: 1}

Is there something like a strict flag (option) to throw a warning or even exception (error) if the entire formula string cannot be interpreted as a substance? If the entire formula string cannot be interpreted as a substance, should the substance's name have only the part that was interpreted as a substance?

Hi @bertiewooster, glad to hear you're finding ChemPy useful, and thanks for this report!
No unfortunately, there's currently no such strict flag. But I agree that we really should have one, and perhaps the default should even be "strict" mode. And I agree that any partial parsing of substance name as a formula should not be accepted by default.
Currently my time available for ChemPy is somewhat limited, but we have a few interested parties so hopefully someone will find the time to implement this soon (you're of course welcome to submit a patch yourself if you wish/can but just reporting issues is already much appreciated!).

Hi @bjodah thanks for the response! If no one else expresses interest in taking this on, I can try.
Regardless, I thought it'd be useful to establish the parameters of a chemical formula that ChemPy is designed to interpret. Is there an existing standard for chemical formulas (I couldn't find one easily from IUPAC)? If not, here's my understanding:
ElaqElbq(ElcqEldq)r...Elnqsc
where

Ela, Elb,...Eln is the symbol (for example, C or Ni) for an element in the periodic table

The first letter of an element symbol is always capitalized
No subsequent letter of an element symbol is capitalized

(ElcqEldq)r indicates that the quantity of the component inside parentheses, ElcqEldq, is r

r must be a positive integer
instead of parentheses, square brackets may be used, for example [ElcqEldq]r

Square brackets are not currently supported, for example [CN]6 is ignored:

>>> f = Substance.from_formula('Fe[CN]6-3')
>>> f.composition
{26: 1, 0: -3}

whereas parentheses are supported, for example
>>> ferricyanide = Substance.from_formula('Fe(CN)6-3')
>>> ferricyanide.composition
{26: 1, 6: 6, 7: 6, 0: -3}

    - Are there any other alternatives to parentheses or brackets?

q is the quantity of of that element in the substance

q can be any floating-point number greater than zero, for example 0.003, 1, 2, 2.3, etc.

optional: sc are the sign and charge, expressing that the substance is not electrically neutral

s is either + (for positive, fewer electrons than the neutral substance) or - (negative, more electrons than the neutral substance)
c is the charge, which must be an integer--or are there any instances of non-integer charge?

Expanded formulas
Should we support any of the following?

⋅ Dot notation for other molecules in a crystalline framework, for example CuSO4⋅5H2O? Supporting the dot per se would be easy--we'd just ignore it--but allowing a quantity (5) before a molecule (H2O) would be an addition to the framework and parsing.
@ At notation for one substance encaged within another, for example Li@C60 indicates Li in caged within C60. I suggest yes because we would simply ignore the @ symbol.

Are there other symbols for related concepts?

I think I actually have a version of the formula parser (or at least the grammar) in chempy that handles dot notation and brackets for complexes.  As I recall it actually broke a fair amount of the current tests and time constraints stopped my inquiries in that direction.
While writing parsers for other situations I have used pyparsing's parse exceptions to signal errors so it can be done (easily).  I suppose the questions are what features are desirable in the formula parser (dot notation for hydrated crystals, square brackets for complexes, @ caged symbol, etc.), what behavior is desired for the strict parser flag, and whether these are separate issues.
If I can get some clarity on these issues, I will patch the relevant bits of my parser onto the current version and investigate further.

[square brackets] and {curly braces}: Accept, with same meaning as (parentheses)

I have this in a local parser, but I intended to treat brackets as complexes.  PyParsing lets you treat matches individually, so I think in general you could treat brackets as grouping symbols and also have the complex information available.  Is there a special meaning for braces or are they simply a grouping alternative?

charge: must be an integer

This is part of the grammar already.

@ at notation for one caged symbol

This should be easy to add.

⋅ dot notation for hydrated crystals

This is already in the parser and tests.  I can't remember if it is documented.

strict parser flag

I think this is easily doable.  I believe it would reduce the number of errors as well because it does seem unexpected that anything else would run after a failed parse.
Let me work on my local branch some and I'll report back with some details.

Is there a special meaning for braces or are they simply a grouping alternative?

IUPAC provisional recommendation (see IR-2.2.1 at bottom of page 3) simply lists braces as a grouping alternative, to be used alternately with parentheses to help avoid confusion:

In formulae, square brackets, parentheses and braces are used in the following nesting order: [], [( )], [{( )}], [({( )})], [{({( )})}], etc. Square brackets are normally used only to enclose formulae; parentheses and braces are then used alternately (see also Sections IR- 4.2.3 and IR-<IP_ADDRESS>).

By the way, how would treating square brackets as complexes (rather than simply a grouping alternative) affect the resulting substance?

IUPAC provisional recommendation (see IR-2.2.1 at bottom of page 3) lists braces as a grouping alternative, to be used alternately with parentheses to help avoid confusion:

I assumed that was the case.  But nomenclature is such a wide and specialized area, sometimes it's hard to keep track of it all.

By the way, how would treating square brackets as complexes (rather than simply a grouping alternative) affect the resulting substance?

Hopefully, it wouldn't.  I was looking more to add information as opposed to treating them differently.  Things that depend on elemental composition should never know the difference.  But, if something is in square brackets, then code could (optionally) treat it as a coordination complex (as opposed to a polyatomic ion or other group) and do appropriate stuff with it like deducing oxidation states, naming, decomposing the group into ligands, etc.  I think my goal at the time was to use the parser with some additional nomenclature code to be able to interconvert formulas and names.

But nomenclature is such a wide and specialized area, sometimes it's hard to keep track of it all.

I haven't been able to find an approved IUPAC standard for formula nomenclature. The closest thing I found is this story, Nomenclature Notes:

The principal enclosing marks are parentheses, ( ), sometimes simply called brackets or round brackets, curly brackets, { }, also often called braces in U.S. texts, and square brackets, [ ]. These are the principal marks used, and though some others may be found in specialized literature, these are those used by chemists. However, the order in which they are used depends upon the specific context.

I haven't been able to find an approved IUPAC standard for formula nomenclature.

I'm sure there is one since they have a standard for everything, but I haven't looked.  I have looked at the one for organic nomenclature and it makes an excellent doorstop.
Regardless, I've done a little work and hacked in everything except the @ and strict parsing (and decimal subscripts from another issue), with some tests and some other things.  All the grouping symbols are working, but the brackets don't yet have the metadata indicating they are complexes and the braces had to have a hack in the latex formatter to work.
I'll try to finish the remaining two (or three) in the next few days in the above referenced branch.  I have a feeling that avoiding formatter hacks and adding metadata will require more extensive use of PyParsing's parse actions and some (hopefully internal only) reformatting of the parsing functions.

My branch should have everything provisionally implemented now, so have a look.  I think it should have more tests probably some more reorganization of the tests.
I really think the choice of operators bears some thought and discussion.  In this branch, I'm using .. for hydrates, . for decimal subscripts/coefficients, [*']+ for primes/excited states, and a prefix @ for caged species.  It makes more sense to me to use * as the hydrate operator than as an excited state indicator, but that's a typical use in typeset equations and it's already in one of the existing tests.  I didn't see an easy way to use . as both the hydrate indicator and the decimal point without it only working for water.  I suppose we could go Romance language style and use a comma for the decimal point as well.  I really just like the * as the text version of the hydrate dot.
These changes don't affect most of the other tests, but accomodating rational subscripts did require some additional sympy.nsimplify() calls in balance_stoichiometry() in chemistry.py.

@jeremyagray Thanks. Could you create a (draft) pull request to highlight the changes?

How about using a raised dot • for hydrates?

Suggest a couple additional tests that the following parse to substances correctly, unless I missed you already adding similar tests:

Ag[NH3]+2

Checking ] sign charge

Fe[CN]6-3

Checking ] quantity sign charge

[Ni(NH3)6]+2[PtCl6]-2

I believe people sometimes keep the charge on each coordination compound even when paired to form a neutral compound

How about using a raised dot • for hydrates?

I was thinking in ASCII only.  I know everything is in utf-8 now, but the parser and tests are still written as if they expect ASCII.  I don't know when that paradigm shift should be made.  If the switch is made to parse utf-8, then it doesn't matter as the subscripts, coefficients, and charges are all different characters and become easy to parse.

Ag[NH3]+2:  Added; passing.
Fe[CN]6-3:  Already passing.
[Ni(NH3)6]+2[PtCl6]-2:  This fails by design, raising ValueError; try with Na+Cl- (which I added as a negative test).  This happens in the charge string post processing and is something that could be changed, but since the correct charges can be inferred from the correct formula I feel this would also need validation to ensure the user added the correct charges.  This may also have an overall charge that would have to be parsed.

Both of those decisions seem fine:

using .. for hydrate to stick with ASCII rather than needing utf-8
disallowing []+[]-

Just to check, there's no currently-supported symbol for hydrates, correct?

Just to check, there's no currently-supported symbol for hydrates, correct?

Right now it is ..  I don't know if it's documented or not, but it's built into the parser post-processing functions and it's tested in the tests.  I forget it's there all the time because it's not explicitly in the parser grammar.

While it would be nice to keep the hydrate symbol as the period . it seems like that could make parsing ambiguous, for example 'X3.6H2O' could mean X3.6H2O or X3•6H2O. So that makes sense to use two periods .. as the hydrate symbol.
How about tests to verify that capitalization is being taken into account, for example

NI = nitrogen iodine
Ni = nickel

I checked the NI/Ni examples and they passed without modification.  PyParsing is case-sensitive by default so it handles cases like that.
As for the latter example, the parser will not handle that as it is currently constructed since the actual parser is only handling formula groups and their subscripts and helper functions are processing the rest in _get_charge() and friends.  So even something like Li+Cl fails as it tries to convert Cl to an integer and Li+Cl- throws and exception for both signs being present.  Even once I coded around the former case,  the positive charge appeared in the composition and broke tests there.  So, trying to parse Li+@C60 resulted in trying to convert @C60 to an integer, working around and parsing Li+Cl fails the composition, Li+Cl- fails with both signs.  (Li@C60)+ works as a workaround with the current parser and isn't too ambiguous.
To actually allow flexibility like this, the parser itself needs to generate a useful data structure that holds all this information and the helper functions need to just query this data structure and not do any text processing at all.  That way, parsing Li+@C60 returns something like
{
  "composition": {0: 1, 3: 1, 6: 60},
  "charge": 1,
  "cage": True,
  "cations": ("Li+",),
  "terms": ("Li+", "@C60",),
  ...
}

instead of ("Li", "+@C60") and then trying to grab the charges from each item.  But this would be a wide ranging, breaking change because everything that depends on reactions or formulas depends on the parser.  Once you have a good data structure to represent a term (I'm thinking a class with methods or dict with helper functions), the terms can be organized in nested lists much like how the current parser is recursively finding terms in a formula.

Thanks for all your work on this as I throw edge cases at you :-)

(Li@C60)+ works as a workaround with the current parser and isn't too ambiguous.

That works for me--I think it's best to merge in (and perhaps release?) your much-improved parser with its current capabilities, and leave that Li+@C60 edge case for the future because addressing it would cause a wide ranging, breaking change.
Where should we document the symbols such as .. and @ -- in the README.md file, or elsewhere?
Other than that, unless you have any more little improvements in the works, recommend you create a pull request so it can be reviewed and merged.

The documentation is in the README, the example Jupyter notebooks, and in autogenerated API documentation.  I have to look at the autogen setup to see where and how to document these changes for the API docs, but some documentation will need to be added to the README as well.
The only other things to do are to decide what to do about the break caused by changing from . to .. as the hydrate indicator (major or minor version bump, split and wait, etc.) and to run a full set of tests with the numerical tests included, but I need to do some work on a separate issue first to sort that.

Would you like me to try updating the Parsing formulae section of README.rst?

Great work guys! And thank you @jeremyagray for making this happen. I agree with your direction, and I too think we should mint a new release once we've merged the changes to the parser. I'm fine with breaking backwards compatibility if needed (unless we can do a deprecation cycle with very little extra work).

Sure, @bertiewooster, just let me get things together and push out the pull request, probably later this week or this weekend.
As for the breaking change on the hydrate operator, it would probably be nice to the users to warn them about the change.  I'll look at it some more to see if there is a less hacky way to integrate rational subscripts that avoids the breaking change.

The breaking change is that . used to be the hydrate operator, but we're changing it to .. correct?
The parser did not previously support rational subscripts, for example Al0.02Cr0.5, correct? (I can't get the released version of ChemPy to correctly parse something like that.) The parser will support rational subscripts after this change, correct? So for example Substance.from_formula('Al0.02Cr0.5').composition should be {13: 0.02, 24: 0.5}? Do we have tests for that?

Yes, this does add rational subscripts, with some tests, and changes the operators as you describe.  This was requested back in issue #176.  But I am still trying to avoid the new operator so as to not break anything.
I've got my installation issues sorted and have found some more parsing induced test failures in some skipped tests in test_chemistry.py that I need to investigate, so my PR is pending that fix.

I've finally got the PR finished for those interested.  I found no good way to avoid using the new hydrate operator without presupposing some knowledge of the formula and structure so that will still be a breaking change.  There are alternatives, such as requiring unicode input, that would vastly simplify parsing.
I did need to make a few more modifications to the parser internals, but I don't think there are any external changes other than the intended ones and the added tests seem to support this conclusion as far as they go.

@bjodah I'm happy to work on updating the README for the new . hydrate .. and caged @. Does the README use doctests?
Side note: I was thinking of updating the format to demonstrate what ChemPy produces to clarify a new user doesn't need to create a dictionary, for example instead of
>>> ferricyanide.composition == {0: -3, 26: 1, 6: 6, 7: 6}  # 0 for charge
True

using
>>> ferricyanide.composition
>>> # Composition dictionary keys: 0 for charge, positive integers for atomic numbers
>>> # Composition dictionary values: Quantities of charge or atoms
{0: -3, 26: 1, 6: 6, 7: 6}

Hi @bertiewooster, sorry for the delay. Sure those updates look great!
Yes, I believe theres a doctest for the README, but if it's causing troubles we can always disable it.

I have t tried the doctest yet. How do I run it?

Let's see if I remember:
$ git grep doctest
...
scripts/run_tests.sh:MPLBACKEND=Agg ${PYTHON:-python3} -m doctest README.rst

So python -m doctest README.rst might be enough?

@bjodah That doctest command ran as it should! I asked partly because one can't run doctest directly in SymPy, which is the only other project I've used doctest in.
I got all the doctests to pass except the known issue that @jeremyagray is coding a fix for:
    Substance.from_formula("Ca2.832Fe0.6285Mg5.395(CO3)6").composition
    Traceback (most recent call last):
    ...
    KeyError: '.'

So as soon as he pushes that fix, I should be able to pull it and get all the README.rst doctests passing.
P.S. Minor annoyance: For some reason, when I run python -m doctest README.rst, git claims that an image file, examples/kinetics.png, got changed. (I undid the "changes" so they won't be committed to the repo.) Wondering if this is a known issue, or maybe for some reason now occurring because I added the following lines to .gitignore?
.vscode/
.vs/

(.vscode/ is to exclude config files for Visual Studio Code, which I'm using. I figured I might as well add .vs/ in case any contributor uses Visual Studio Pro or perhaps Community Edition).

I can't replicate the image getting changed on running the readme doctests, so it may be environment dependent.
I didn't know those tests were there and not running with the rest.  When I did run them on my branch for #209, the redox tests around line 225 had to be reversed to work.  I think that this reversal doesn't really matter since there is no implication that the reaction is spontaneous as produced since we're not using any equilibrium constant or reaction potential data to produce the reaction.  If this is the case, we probably need to document that the reaction is balanced but not necessarily spontaneous as written.


text_ansi not reporting correct size with WINDOW_ALWAYS_AUTO_RESIZE

Code to reproduce:
        def test_fn1():
            imgui.begin('Test1', flags=imgui.WINDOW_ALWAYS_AUTO_RESIZE)
            imgui.text_ansi('TEST\033[31m TEXT1')
            imgui.end()
        def test_fn2():
            imgui.begin('Test2', flags=imgui.WINDOW_ALWAYS_AUTO_RESIZE)
            imgui.text('TEST TEXT2')
            imgui.end()

Result:

Yeah, I knew those ansi sequence coloring will be problematic. I suppose Imgui simply takes the length of whole string including escape characters.

Yeah, I knew those ansi sequence coloring will be problematic. I suppose Imgui simply takes the length of whole string including escape characters.

I looked briefly at this, and this were my notes:

One option is to move the first few parsing loops from ImFont_RenderAnsiText to a new CalcTextSizeAnsi, that does the first pass of filling the global static arrays, but some state inbetween would have to be duplicated.
Another option is to Parse the entire text twice, one while rendering it, and one while calculating the text size

Another (unrelated) thing I noticed:
char_buf in AnsiTextColored.cpp is updated but never used.


Default to development in dev

Fixes https://github.com/jekyll/github-metadata/issues/43.
Also fixes the domain to use the Pages hostname, not the GitHub hostname, when custom domains are disabled in order to get tests to pass.

@benbalter Isn't that supposed to be JEKYLL_ENV? PAGES_ENV is used to determine the target to request from, I think.

PAGES_ENV is used to determine the target to request from, I think.

That doesn't make much sense to me. The idea behind PAGES_ENV was (A) so that we could know if we were in enterprise or dotcom internally, and (B) so that the user could know if they were in dotcom (or enterprise) or locally. I believe it predates JEKYLL_ENV. Additionally, is JEKYLL_ENV exposed to liquid where the user can access it?
If we thought of using PAGES_ENV as a flag/toggle, it'd really only be useful, if I could set PAGES_ENV to the enterprise instance, and everything else just worked. Otherwise, I can't see when a user would want to actively toggle back and forth. Even if pushing to both remotes, they'd want to render things differently locally (e.g., changing the URL, not including discuss, etc.).
In my mind:

PAGES_ENV: should be dotcom, enterprise, or development (default)
JEKYLL_ENV: should be productionordevelopment`

The two are similar, but PAGES_ENV is exposed to liquid, and can be used to differentiate between GitHub environments.

@benbalter jekyll.environment exposes JEKYLL_ENV. It too defaults to development. The only difference I see is that PAGES_ENV differentiates between dotcom and enterprise, which are both production for JEKYLL_ENV.
What should PAGES_ENV=development do about changing the octokit API calls? https://github.dev?

What should PAGES_ENV=development do about changing the octokit API calls? https://github.dev?

I think nothing? As someone previewing my Pages-hosted site locally, I'd want the metadata (save the URL) to be the live metadata, no?

I think nothing? As someone previewing my Pages-hosted site locally, I'd want the metadata (save the URL) to be the live metadata, no?

What if it's an Enterprise repo? Wouldn't that affect this? Would we have development and development-enterprise?

What if it's an Enterprise repo?

That's what I was asking about in https://github.com/jekyll/github-metadata/issues/48. (and suggested ENDPOINT)

@parkr got tests passing, if you're able to :eyes: once more. :smile: Would be good to finally get this out.

LGTM.

LGTM.

@jekyllbot: merge +major


Why is reading very slow?

I found a problem when using tikv. read very slowly.
this is my tikv config
log-level = "info"
log-file = "/data01/tikv/logs/tikv.log"

[server]
addr = "<IP_ADDRESS>:20160"

[storage]
data-dir = "/data01/tikv/data"

[pd]
endpoints = ["<IP_ADDRESS>:2379","<IP_ADDRESS>:2379","<IP_ADDRESS>:2379"]

[metric]
interval = "15s"
address = ""
job = "tikv"

[raftstore]
sync-log = false

region-max-size = "384MB"
region-split-size = "256MB"
region-split-check-diff = "32MB"

[rocksdb]
max-manifest-file-size = "20MB"
wal-dir = "/data01/tikv/data"

[rocksdb.defaultcf]
block-size = "64KB"
compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]

write-buffer-size = "128MB"

max-write-buffer-number = 5

level0-slowdown-writes-trigger = 20

level0-stop-writes-trigger = 36

max-bytes-for-level-base = "512MB"

target-file-size-base = "32MB"

[rocksdb.writecf]
compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]

write-buffer-size = "128MB"
max-write-buffer-number = 5
min-write-buffer-number-to-merge = 1

max-bytes-for-level-base = "512MB"
target-file-size-base = "32MB"

[raftdb]
compaction-readahead-size = "2MB"

[raftdb.defaultcf]
compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]

write-buffer-size = "128MB"
max-write-buffer-number = 5
min-write-buffer-number-to-merge = 1

max-bytes-for-level-base = "512MB"
target-file-size-base = "32MB"

block-cache-size = "256MB"

and  this is pd server
/data01/tidb-latest-linux-amd64/bin/pd-server --name=pd1 \
--data-dir=/data01/pdserver/data \
--client-urls="http://<IP_ADDRESS>:2379" \
--peer-urls="http://<IP_ADDRESS>:2380" \
--initial-cluster="pd1=http://<IP_ADDRESS>:2380,pd2=http://<IP_ADDRESS>:2380,pd3=http://<IP_ADDRESS>:2380" \
-L "info" \
--log-file=/data01/pdserver/logs/pd.log
use 20 go goroutines and chan send 1000000 key read  need  about 12 minutes  .
In the same situation  20 go goroutines and chan send 1000000 key  value  , writing only takes 1 minute.
reading

what is causing this problem?
thank you .

@breeswish
it is caused by the network problem. Thank you.


Cannot open plugin in Unity 2021.2.3f1

Plugin Version or Commit ID
Current version
Unity Version
Unity 2021.2.3f1
Your Host OS
MacOS
Target Platform
UnityEditor
Description
I get a whole range of errors:

Code to Reproduce the issue
No response
Additional Context
No response

Please read https://github.com/homuler/MediaPipeUnityPlugin#hammer_and_wrench-installation


Use io.open instead of codecs.open

I'm not familiar with io.open. What benefit does this provide?

io.open is builtin open on Python 3.
io.open is recommended way to open file since Python 2.6.
Since Python 2.7, io.open returns C implementation TextIOWrapper, which is faster than codecs.open.
codecs.open is required for projects only supporting Python 2.5.

and it supports encoding

✨🍰✨


Added Binary Indexed Tree / Fenwick Tree Implementation

Issue #41
Added under data-structures/tree

Codecov Report

Merging #51 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #51   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          83     84    +1
  Lines        1830   1843   +13
  Branches      323    326    +3
=====================================
+ Hits         1830   1843   +13

Impacted Files
Coverage Δ

...c/data-structures/tree/fenwick-tree/FenwickTree.js
100% <100%> (ø)

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 beb8501...457188f. Read the comment docs.


work with mp4

first time coding in php, not sure about syntax. dont' have time to test it locally now.

Closing this since spee.ch is now in a different language and framework.


Feature Request: Load Image with Metadata

Can you please make a corresponding load image node? That would be hugely useful, because it would allow us to generate a load of candidate images with randomized prompts or other metadata, save them all (with metadata), manually select the ones that we like and then batch process the good ones in a new workflow that starts with retrieving the metadata of the original image.

there is already (but separate): https://github.com/tkoenig89/ComfyUI_Load_Image_With_Metadata
Someone reported an issue, that there seems to be an issue reading images saved with this node here. I will look into this one soon.

Wanted to request the same and found this. Yes there are already nodes that do that but they don't include model name. Would be nice to also have vae both ways, just for consistency sake.

As there seems to be not much development happening here: You all might want to have a look at this repository.
This combines save and load into a single node collection: https://github.com/receyuki/comfyui-prompt-reader-node


AmebaZ2: Add soc src code

Add soc src code for rtl8720c
Signed-off-by: Jerry_tang<EMAIL_ADDRESS>Summary
add soc-rtl8720c src code
Impact
no
Testing
ok

This code derive from GPL code, see PR #4066. Please get the approval (SGA) from Realtek, otherwise we cannot include it on NuttX.

I’m sorry but I don’t understand what the approval should be.
Could you please show me what the approval is? Is there any example?
发件人: Alan Carvalho de Assis @.***
发送时间: 2021年7月6日 19:33
收件人: apache/incubator-nuttx @.>
抄送: 唐帅帅 @.>; Author @.***>
主题: Re: [apache/incubator-nuttx] AmebaZ2: Add soc src code (#4076)
This code derive from GPL code, see PR #4066https://github.com/apache/incubator-nuttx/pull/4066. Please get the approval (SGA) from Realtek, otherwise we cannot include it on NuttX.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/apache/incubator-nuttx/pull/4076#issuecomment-874683612, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2FFPESUJSIRWN4FXVMUTTTWLSXJANCNFSM473V3NFA.
------Please consider the environment before printing this e-mail.

@jerry-tang-realsil
Please see https://www.apache.org/licenses/contributor-agreements.html
once Realtek submits a CCLA: Corporate Contributor License Agreement then the code can come in.

I added a wrong license before.
Below license is from our release code.
So does it still need to sign a SGA?
/ ******************************************************************************
*

Copyright(c) 2007 - 2017 Realtek Corporation. All rights reserved.

SPDX-License-Identifier: Apache-2.0

Licensed under the Apache License, Version 2.0 (the License); you may
not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

******************************************************************************/

I added a wrong license before.
Below license is from our release code.
So does it still need to sign a SGA?
/ ******************************************************************************
*
* Copyright(c) 2007 - 2017 Realtek Corporation. All rights reserved.

* SPDX-License-Identifier: Apache-2.0

* Licensed under the Apache License, Version 2.0 (the License); you may

* not use this file except in compliance with the License.

* You may obtain a copy of the License at

* http://www.apache.org/licenses/LICENSE-2.0

* Unless required by applicable law or agreed to in writing, software

* distributed under the License is distributed on an AS IS BASIS, WITHOUT

* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

* See the License for the specific language governing permissions and

* limitations under the License.

******************************************************************************/

Yes, it is a protection for this project. It will avoid someone claiming in the future that we are stealing code from Realtek. If you work for Realtek it should be fast to get this approach, we get it here at Espressif in less than 3 days. Please ask some Realtek director to submit the documents.

Please keep is as Draft to avoid someone accidentally merging it.

First, Realtek has ever signed Apache License, so we still need to submit relative documents?
Then, these code's license was added by mistake. It need not add realtek licnese actually.
Above all, I don't think there is need to discuss the problem of license.

First, Realtek has ever signed Apache License, so we still need to submit relative documents?
Then, these code's license was added by mistake. It need not add realtek licnese actually.
Above all, I don't think there is need to discuss the problem of license.

@justinmclean what do you think in this case? jerry-tang-realsil submitted a code as GPL, then he said it was a mistake, now he says Realtek already has signed a SGA with Apache (I suppose for other project) and he thinks we don't need to discuss the problem of the license. The issue is not the license "per se", but the fact he brought existent code that seams to come from other project and/or company (including code from Xiaomi that he removed the Copyright). I don't see someone in the future saying we are stealing code from other project and adding on NuttX. So, do you think we can ignore these facts and just let it in?

Yeah, some code is from xiaomi. But xiaomi has told us that license just refer to others, such as esp32. And not all of the code added xiaomi's license. So I modified it but made a mistake that  I added an extra wrong license. It's because I misunderstand the requirement of license.
发自我的iPhone
在 2021年7月9日，下午8:07，Alan Carvalho de Assis @.***> 写道：

First, Realtek has ever signed Apache License, so we still need to submit relative documents?
Then, these code's license was added by mistake. It need not add realtek licnese actually.
Above all, I don't think there is need to discuss the problem of license.
@justinmcleanhttps://github.com/justinmclean what do you think in this case? jerry-tang-realsil submitted a code as GPL, then he said it was a mistake, now he says Realtek already has signed a SGA with Apache (I suppose for other project) and he thinks we don't need to discuss the problem of the license. The issue is not the license "per se", but the fact he brought existent code that seams to come from other project and/or company (including code from Xiaomi that he removed the Copyright). I don't see someone in the future saying we are stealing code from other project and adding on NuttX. So, do you think we can ignore these facts and just let it in?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/apache/incubator-nuttx/pull/4076#issuecomment-877138682, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2FFPASXGGZBGFXEGKJHDTTW3Q7LANCNFSM473V3NFA.
------Please consider the environment before printing this e-mail.

yes @jerry-tang-realsil I understand your point, but we cannot take the risk. Because we don't know for sure from where this code came, the right thing to do now is get approval from Realtek since the original GPL code had their Copyright. I hope you understand it.

Do you mean that I should add realtek apache license?
发自我的iPhone
在 2021年7月9日，下午9:52，Alan Carvalho de Assis @.***> 写道：

yes @jerry-tang-realsilhttps://github.com/jerry-tang-realsil I understand your point, but we cannot take the risk. Because we don't know for sure from where this code came, the right thing to do now is get approval from Realtek since the original GPL code had their Copyright. I hope you understand it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/apache/incubator-nuttx/pull/4076#issuecomment-877205342, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2FFPEPTVB45POTFGDZWNDTW35IDANCNFSM473V3NFA.
------Please consider the environment before printing this e-mail.

A SGA only covers code that has been donated in that SGA it doesn't cover all code from a company. So first question is has this exact piece of code being donated by a software grant? If that is not the case what license is the code under? If the code is under GPL then we can't accept it as GPL is not compatible with the Apace license.

I'll also add that any code where the header has been altered or the copyright removed without the permission of the owner should be rejected.

@justinmclean Mr. @jerry-tang-realsil works for Realtek, but the original code was submitted here as GPL. I think Realtek as owner of the original code could donate that code to be released under Apache License. Do you think the CCLA is enough in this case or should we ask Realtek the SGA to grant permission of this code?

I may explain again:
These code is based on realtek's code. Xiaomi transplanted it with realtek's help. It's still realtek's duty to maintain in future.
So, xiaomi require realtek to donate these code to nuttx, and realtek agreed.
Realtek 's code is not relative to GPL.
I also think it's ok to add Apache License. Xiaomi also advised us to modify the license, refer to others that have donated to nuttx.

发件人: Alan Carvalho de Assis @.***>
发送时间: 2021年7月9日 22:51:44
收件人: apache/incubator-nuttx
抄送: 唐帅帅; Mention
主题: Re: [apache/incubator-nuttx] AmebaZ2: Add soc src code (#4076)
@justinmcleanhttps://github.com/justinmclean Mr. @jerry-tang-realsilhttps://github.com/jerry-tang-realsil works for Realtek, but the original code was submitted here as GPL. I think Realtek as owner of the original code could donate that code to be released under Apache License. Do you think the CCLA is enough in this case or should we ask Realtek the SGA to grant permission of this code?
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/apache/incubator-nuttx/pull/4076#issuecomment-877245362, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2FFPHQYCY6VRZZYLPB7SLTW4EIBANCNFSM473V3NFA.
------Please consider the environment before printing this e-mail.

I may explain again: These code is based on realtek's code. Xiaomi transplanted it with realtek's help. It's still realtek's duty to maintain in future. So, xiaomi require realtek to donate these code to nuttx, and realtek agreed. Realtek 's code is not relative to GPL. I also think it's ok to add Apache License. Xiaomi also advised us to modify the license, refer to others that have donated to nuttx.
…
________________________________ 发件人: Alan Carvalho de Assis @.***> 发送时间: 2021年7月9日 22:51:44 收件人: apache/incubator-nuttx 抄送: 唐帅帅; Mention 主题: Re: [apache/incubator-nuttx] AmebaZ2: Add soc src code (#4076) @justinmcleanhttps://github.com/justinmclean Mr. @jerry-tang-realsilhttps://github.com/jerry-tang-realsil works for Realtek, but the original code was submitted here as GPL. I think Realtek as owner of the original code could donate that code to be released under Apache License. Do you think the CCLA is enough in this case or should we ask Realtek the SGA to grant permission of this code? ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#4076 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2FFPHQYCY6VRZZYLPB7SLTW4EIBANCNFSM473V3NFA.
------Please consider the environment before printing this e-mail.

Thank you @jerry-tang-realsil for this explanation. I think we are reaching a better understanding of this situation. Is the original code from Realtek available publicly under Apache or other compatible license? Is so, could you give us the link to it? Case it is just internal code inside Realtek company, then I think the SGA is needed, because we cannot prove that original code license was compatible with Apache license.

Is the original code from Realtek available publicly under Apache or other compatible license? Is so, could you give us the link to it? Case it is just internal code inside Realtek company, then I think the SGA is needed, because we cannot prove that original code license was compatible with Apache license.

If Realtek owns of code and legitimately holds the copyright, then they may change the license as they see fit.  Right?    If that condition is true that I cannot imagine what the issue with licensing could possibly be.
With regard to the SGA, my understanding is that this depends on a subjective understanding of the scope of the change.  Is that right?  This is beyond my ability to suggest anything credible.  SGAs are problematic for some businesses (or at the very least, time consuming).  I suppose that you could argue either way that architecture support is broad or narrow scope.  I would end to go with narrow scope since it does not reflect any core technology that is critical to the integrity of the OS; it simply extends existing support to the Realtek products.
If the Realtek support will continue to develop over time, like ESP32 and Spresense, then we would need an SGA.

Is the original code from Realtek available publicly under Apache or other compatible license? Is so, could you give us the link to it? Case it is just internal code inside Realtek company, then I think the SGA is needed, because we cannot prove that original code license was compatible with Apache license.

If Realtek owns of code and legitimately holds the copyright, then they may change the license as they see fit. Right? If that condition is true that I cannot imagine what the issue with licensing could possibly be.
With regard to the SGA, my understanding is that this depends on a subjective understanding of the scope of the change. Is that right? This is beyond my ability to suggest anything credible. SGAs are problematic for some businesses (or at the very least, time consuming). I suppose that you could argue either way that architecture support is broad or narrow scope. I would end to go with narrow scope since it does not reflect any core technology that is critical to the integrity of the OS; it simply extends existing support to the Realtek products.
If the Realtek support will continue to develop over time, like ESP32 and Spresense, then we would need an SGA.

Ok Greg, makes sense! If in the future Realtek assign the SGA it will be ok, otherwise if someone complaint about the origin of this code we could remove it, although I think this is not the best option.

Whether an SGA is signed or not, Realtek needs to be cognizant of the fact that they are granting the code the Apache Software Foundation.  The ASF now owns the code; the ASF now holds the copyright.  Other uses of this code by Realtek in the future could not violate the ASF's copyright.  I hope that we do not encounter such a legal dilemma.

Whether an SGA is signed or not, Realtek needs to be cognizant of the fact that they are granting the code the Apache Software Foundation. The ASF now owns the code; the ASF now holds the copyright. Other uses of this code by Realtek in the future could not violate the ASF's copyright. I hope that we do not encounter such a legal dilemma. Signing the SGA would make this gift to the ASF much more explicit.

I might have that wrong.  I sometimes think I know more than I really do.  The actual test of the file header is:
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.  The
 * ASF licenses this file to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance with the
 * License.  You may obtain a copy of the License at ....

This is probably why it is important to sign the contributor agreement (SGA and ICLA).  Nothing was added to the NOTICE file, right?  The alternative that Realtek probably really wanted was to release this as third party code.

https://www.apache.org/legal/resolved.html
https://www.apache.org/foundation/license-faq.html#Apply-My-Software

Yes, that was my worrying. It is difficult to track back this code's origin and nobody from Realtek submitted an ICLA, CCLA or SGA to the Apache related to the NuttX. But Ok, let believe they will submit it soon, maybe Xiaomi could ask them to do so.

Sure, I will talk with Realtek.

@ Xiang Xiao
All right, we would like to discuss the issue and modify according to your requirement.
Sorry for the mistake.
Please email us or WeChat the date if need a meeting.

发件人: Xiang Xiao @.***>
发送时间: 2021年7月10日 16:38:23
收件人: apache/incubator-nuttx
抄送: 唐帅帅; Mention
主题: Re: [apache/incubator-nuttx] AmebaZ2: Add soc src code (#4076)
Sure, I will talk with Realtek.
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/apache/incubator-nuttx/pull/4076#issuecomment-877597629, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2FFPCAN34C46IIZY72PZTTXABH7ANCNFSM473V3NFA.
------Please consider the environment before printing this e-mail.


Type tests

Purpose
Since this is a TS heavy library I think it is time for us to introduce type-level tests and avoid breaking type inference on our releases.
Tech details

I added 2 new type utilities to help doing type-level testing: Expect and Equal
I started by testing the types.ts file using namespaces (to repeat types and consts) as if they were describe blocks.
The files that only have type tests must have a dummy runtime test at the bottom.
I'm using // @ts-expect-error whenever I feel it makes sense to expect something to break
on the domain-functions.test file I'm testing every composition inference as we've seen code refactorings that would only mess with one or two inferences

I caught a type bug 🐞
The newly introduced trace function kills the type inference of the composition applied to it.
Any DF given to trace will be inferred as DomainFunction<unknown>.
That was introduced in favor of typing the result of the trace callback.
I'm gonna do a PR on top of this one to return the inference to the composition. It'll kill the inference of the result but I think the value of having the composition strongly typed is far superior.

Great PR :tada:
I just merged the fix in the trace function and tweaked the result type to Result<unknown> instead of just unknown.


Webhook room_update not working

The php-library doesn't have room_update as  a possible Webhook type but room_instance_update
-> eyeson-php/src/Resources/Webhook.php:9
Moreover when replacing the webhook room_instance_update with room_update in the list you get an error message, because there is a typo at eyeson-php/src/Resources/Webhook.php:33
The API seems to expect parameter "types" not "type"!
I setup the script which gets triggered by the webhook to dump everything what I receive in a logfile in the following order:
print_r(array(file_get_contents('php://input'), $_POST, $_GET, $_SERVER)
After someone disconnects from the room the logfile gets created with the following output, which does NOT include  started_at, ended_at and the participants as stated in the documentation at https://eyeson-team.github.io/api/api-reference/#register-webhooks
{"api_key":"...","type":"room_update","room":{"id":"Testraum","name":"Therapie","ready":true,"shutdown":false,"sip":{"uri":"...","domain":"...","authorizationUser":"..."},"guest_token":"..."}}
Is this a bug, is there something still not implemented or am I doing something completely wrong here?

You can use recent version of the library to register webhooks, the typos have been fixed. The process is totally right, it seems that I've mixed up some other service in the documentation. You receive a webhook with the boolean attribute shutdown, that represents if the meeting has ended. You can simply record this event on your side to get the meeting time.

Thanks, but I just discovered that room_update gets only triggered when someone joins a room. After someone disconnects from a room nothing happens automatically. It seems I have to send a request for example another join request, without really joining the room in order to get the desired output with shutdown:true.
Is this intended like this? It would be a lot better if it just automatically triggers on disconnect as well without me having to send periodically a request to check if the room meeting already ended.

The room update webhook is send whenever the room changes, in case of user disconnects, those users are not removed as participants, therefore you don't receive a new event.
I just checked the shutdown attribute, it works as expected. Did you wait for the two-minute timeout that the meeting is waiting for reconnects until a meeting is closed?

Thanks, that's why it worked first time as expected and made me wonder. Still this means we can only estimate a end time. That's not really a clean solution.
If I understand it right, the event gets triggered when someone joins and when everyone has left the room after a 2 minute timeout. But if someone rejoined the room during the 2 minute delay the end time gets delayed again which makes the overall duration of the room session longer even if there are no 2 active partners in the room.
Moreover we have to subtract 2 minutes from the duration to get the actual session time.
I know its rare that this could happen but still a possibility. For now I am content with the process. Thanks for your support.

We always focus on having "clean solutions". Having a timeout is essential, otherwise a session will always cut if a single participant leaves the room by reconnecting or has network issues. We have elaborated a timeout over a long time and many meetings and came to the best result with around two minutes.
You don't have to estimate any meeting, the exact session time is the timestamp of shutdown - timeout.


Remove support for targets without libc

@japaric correctly pointed out in #375 that the libc crate is for linking against libc.
We currently have a lot of hacks and workarounds to "support" a variety of targets that do not have a libc, are often only interested in c types and would be better served by using the cty crate, and that actually we don't really "support" because we don't even test that we build for these targets and technically we can't test that the ABI specified here matches that of the target's libc because... there isn't any.
In particular, for some targets without a libc, currently libc is empty. That's the approach that the winapi crate follows on linux but is not the approach that mach follows on osx.
cc @alexcrichton @malbarbo I think we should clean up libc from supporting these targets and make clear in the README what libc is for.

@gnzlbg given our discussion on IRC, would you be ok closing this?

Yes, to summarize the discussion: libc should always compile. In targets that are not supported (e.g. because they haven't been implemented yet, have no libc, etc.), the crate should just be empty.  This is also what winapi-rs does.
I discussed this with @retep998 as well, and this approach has pros and cons.
The big pro is that if code that uses libc gets compiled to an unsupported platform, it might just work as long as the dependencies don't use libc for that platform. This is particularly important for libc because many targets have a libc of some sorts.
The downsides are that libc and winapi are then downloaded and compiled on platforms in which they are not used, and their presence in tree can affect dependency resolution (e.g. libc pulls in std by default). And also, that when people do try to use them in unsupported platforms, the compilation errors are suboptimal (e.g. function not found).
I don't think that these downsides are worth fixing in these crates TBH, they are definitely don't add enough value in my opinion to justify the breakage they would cause. libc in particular is a very small crate, downloading it and not using it isn't a big deal, and if it is, upstream crates can fix that.
The mach crate, however, already fails to compile / link on non apple targets, so I'll release a new version that chooses the "opposite" approach: explicitly failing to compile on unsupported platforms. That pretty much forces users to include mach as a target-dependent dependency, but this is already what all users are doing.


removing committed Intl.js and HTML import as it's being moved to a s…

…eparate project

Coverage remained the same at 100.0% when pulling 286a23ef025e150442195a0a0bff9993a7eded60 on remove-import into 5c1f2ae831be24f566cb0eff97462bc750b59cb8 on master.


ENH: support complex functions in integrate.quad

This introduces support for complex valued integrands in the integreate.quad method.  The integrand is
treated as real or complex based on the value of
a boolean flag introduced to the method's call
signature.
This enhancement is motivated by the need to support complex functions in the expectation of circular
distributions in scipy.stats, See #16907.

Reference issue

What does this implement/fix?

Additional information

Yes, this is much better.
Please click the "Details" of the failing test. Follow the links (you have to click a few deep, unfortunately) until you can see the issues. They are just PEP8/style things, but we need to follow the standard.
I'd also suggest that the argument be complex_func or just complex instead of real_func, partially because it will stand out more as an option, and also because I prefer to turn options like this "on" by setting them True instead of setting them False. You might also want to note some essentially theory about complex integration (e.g. components are integrated separately, the integral of path-dependent unless the function is analytic, etc...) and add a reference.
I will try to take a closer look this weekend.

Ooh something to check - does this solve gh-12662?

w.r.t. gh-12662
There are three cases I've checked
1.
a = np.float64(0.5)
quad(lambda x: x**a, -np.inf, 0, weight='cos', wvar=1, limlst=10**3, complex_func=True)

still seg faults.

a=np.float64(0.5)
quad(lambda x: x**a * np.cos(1*x), -np.inf, 0, limlst=10**3, complex_func=True)

results in NaN (nan + 0j)

a = 0.5
quad(lambda x: x**a, -np.inf, 0, weight='cos', wvar=1, limlst=10**3, complex_func=True)

((-4.2844039257283295e-17-0.6266570686378315j)
The complex argument to quad seems to solve a small part of the issue raised. It looks like the real solution is divided between numpy and scipy.    For instance, consider the difference of behavior shown here:
In [1]: import numpy as np

In [2]: (-1000)**np.float64(0.5)
<ipython-input-2-d168515c5639>:1: RuntimeWarning: invalid value encountered in double_scalars
  (-1000)**np.float64(0.5)
Out[2]: nan

In [3]: (-1000)**0.5
Out[3]: (1.9363366072701934e-15+31.622776601683793j)

Would you prefer to make those changes in a separate PR,

Separate. This has no obligation to fix gh-12662.

@mdhaber It appears there is a test failing in the optimize module that is not related to this change.  Otherwise, this is ready for another review.

When we discussed the complex opt-in policy, I didn't look carefully enough at the mailing list discussion you mentioned. I ran across it recently, and I don't think there was a decisive resolution there. One contributor proposed automatic detection, and one argued against it. There have been other requests to detect complex output in solve_ivp, so I think this would be worth another look. Would you be interested in implementing a complex integrand detection if I were to revive that thread in the mailing list?

@mdhaber Yes, I'm game for that.

Thanks for replying. Actually, I've decided against reviving that discussion at this time, personally. I am working on too many things!


Update harness-variables.md

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663cafa7f811c8a77b027865--harness-developer.netlify.app


top-level/aliases: Clean up outdated Nix aliases

Description of changes

Nix 2.6 was removed on 2022-12-28: 172347745ffb457e47cf5386f2ae3ff6678c2b02
Nix 2.4 and 2.5 were removed on 2022-07-14: b2eea05b06baa2886039d61485d37c338ad3d578
nixVersions.unstable throws but it does not mention the alias: 2b4e18f3d4a7b80af21b640c0970f83b34efceff

https://discourse.nixos.org/t/rant-finding-errors-in-module-configs-after-incompatible-upgrades-is-dreadful/46375

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rant-finding-errors-in-module-configs-after-incompatible-upgrades-is-dreadful/46375/3

Ideally, we would also convert nixFlakes, nixStable and nix_2_3 to throw but that is not backportable.


Infinite Fluid Glitch with Unending Bowl

General Information
Hello! I'm one of the moderators for Divine Journey 2 and there seems to be a bug with the Unending Bowl that allows you to generate infinite amounts of any fluid fairly early-game.
Describe the bug:
By using an Unending Bowl on a EnderIO Fluid Tank, you can create infinite amounts of any fluid. This also works with the Meat Feeder from Industrial Foregoing, constantly refilling the feeder if you have a Bowl in your inventory
To Reproduce:

Place an EnderIO Fluid Tank
Put any amount of any fluid into the tank
Right-click the tank with an Unending Bowl

Expected behavior:
The expected behavior would be that the Bowl would only be able to provide water.

Environment Versions

Mystic Mods Versions

MysticalLib: 1.12.2-1.13.0
Mystical World: 1.12.2-1.11.0
Roots: 1.12.2-3.1.4

Other Versions:

Conflicting mod (if regarding mod integration): EnderIO, but there could be others
Other mods you think could cause issues: No other mods conflicts are currently known
Forge: <IP_ADDRESS>55
Minecraft: 1.12.2
Modpack (if available): Divine Journey 2

Logging Information
Please Use gist, paste.ee, pastebin or some other log sharing service
Crash Report (if available):
No crash report
Latest Log (if necessary):
No log necessary

Additional Information
Screenshots (if available):

Additional context (optional):
I set up a Mechanical User to see if it was possible to automate using the bug and it turns out it is. I chose to use Liquid Starlight as an example because late-game uses a lot of it, along with some other fluids (including one that is used for Chaos Shards)

Unfortunately, I'm not able to build this mod any more, let alone get a development environment working for 1.12. I think the only option for you would be to disable the recipe for the Unending Bowl.

Okay, someone's managed to get the build environment to function again, so I'm going to try looking into this.

I've got this fixed on git. I'll see what else I can fix before making a new release.


Crash

Description
When I click on a button RenderDock do not respond.
I try different HDD and SSD and USB key and different version of RenderDock but all do not respond when I click on a button.
Steps to reproduce
1 - Start RenderDock
2 - Click on a button
Environment

RenderDoc version: 1.13
Operating System: Windows 10
Graphics API: OpenGL
GPU: RTX 2060

If what you describe is accurate and clicking any button at all crashes RenderDoc, I can only guess that this is a system issue and not a RenderDoc bug. There's no way I can reproduce this accurately as I do so accidentally any time I run the program, and I've not heard any similar issues reported from anyone.
I'd suggest that you investigate your own system and make sure you have drivers up to date, no anti-virus/graphics overlay/shell extensions or other system-wide software installed and enabled that might be breaking. If that doesn't work you could either try on a different system or else compile RenderDoc from source and see what the crash is and report an issue with a more specific problem.
I'm closing this issue because the reproduction steps provided suggest a system problem as I say above, and there's no way for more information to even clarify the problem as "any button press will crash RenderDoc" is technically enough information but not a bug I can realistically investigate without access to the system where this is happening.


profile MET code and look for time & memory bottlenecks

Turn on code profiling to get a sense of where in the code the speed or memory bottlenecks are.  Examples could be allocating and re-allocating memory repeatedly, repeated unnecessary range checking in buffers, reading data several times, inefficient algorithms (mode is bad for this one) ... others?
[MET-775] created by bullock

During a telecon with NOAA/MDL, John Wagner offered that we can use their Grid-Stat use case to profile the code and look for bottlenecks.  They use many, many masking regions and it runs pretty slowly.  So this would be a good thing test for debugging.