Why not just make it impossible to send values to the first next call in the first place?

This proposal in my mind seems to trying to work around an issue that shouldn't exist in the first place.  Although there may be some small risk of backwards incompatibility, it seems like it would make more sense if gen.next(x) resulted in an error on newly started generators when x is not undefined.  This is the way Python does things with its .send method:  gen.send(x) produces TypeError: can't send non-None value to a just-started generator.
If producing an error is too much, browsers could simply output a warning to the console.  I just don't think it makes sense to completely change the "correct" way to get values from .next calls by introducing new syntax when the value passed to the first .next call really shouldn't be meaningful anyway.

@benburrill
This is an interesting idea.
I am not sure whether this idea was considered in the early days of generators.  The generators of ES was borrowed from Python, and I remember the early generators prototype in JavaScript 1.7 had two methods: send(value) and next(). You need to first call next(), or send(value) will throw "can't call send() on newborn generator" (inaccurate, but something like that). This was very close to your idea.
For some reasons I don't know, these two methods were unified to ES6 next(value). Because only send() throw, I am not sure whether current no throw behavior is intentional or just follow original next().  Consider this proposal was started at Feb 2015 by @allenwb who is the editor of ES6, I guess allen may already decided to leave the room for this proposal.
Whether it was "correct" or not, as @ljharb comment, we can't change the behavior of next() now.
Anyway, I think you have the point that whether this proposal is "meaningful". I will collect and add some use cases.
Thank you.

I don't know anything about the process for making changes to ES, but although raising an exception would be backwards incompatible, I personally don't think that should completely disqualify it.  I doubt all that many people are intentionally passing values to the first call to next, and there could be a long deprecation period where implementations could spit out a warning (which would mostly accomplish the goal of an error without the pain).
But in any case, my main concern with this proposal is that it removes the consistency of the way sending things to generators work.  Although a bit strange to the uninitiated, it is completely consistent and sensible for the first next call never to take a value.  If it is changed so that depending on how the generator is written, generators sometimes get the first value from the first next call and sometimes in the second, it could make the interface more confusing to the caller, and I think as a result one of these conventions would need to become the "wrong" way to write generators.

I will collect and add some use cases.
I'd be interested in seeing those use cases, but the way I see it, if we get along fine without being able to send initial values to generators in Python, what advantage would it really bring to JavaScript?

@benburrill

although raising an exception would be backwards incompatible, I personally don't think that should completely disqualify it.

I also really want a way to deprecate some bad things in ES (for example some legacy syntax and apis in annex B 😅) ! The real problem is ECMAScript is a little bit different than other programming languages, you can never have a long enough deprecation period because there are many unmaintained websites in the internet and we don't want to make them break.
Of coz the boundary line of what is "backwards incompatible" sometimes vague. For example, if the original behavior was throw Error, we could change it to not throw. Strictly speaking this is also a "breaking change", but it's very rare that some code logic rely on the throwing behavior.

I doubt all that many people are intentionally passing values to the first call to next

I agree with you! The problem is how we could know "how many" and evaluate the risk. Browser vendor could do some data analysis, but everything have cost, u need to convince the browser dev team that the cost is worth for the issue. Personally I hope tc39 could improve this part. But in this specific issue, assume we finally find this proposal was not very useful, the best choice may be just withdraw the proposal without change anything which always have zero risk.

my main concern with this proposal is that it removes the consistency of the way sending things to generators work. Although a bit strange to the uninitiated, it is completely consistent and sensible for the first next call never to take a value.

This part is controversial, it's hard to say which one is more consistent.
For example, if u look the api in more static type way, it's impossible to mark the type of next(v) precisely in almost all static type system. Of coz both python and js are dynamic type, though now we have TS.

depending on how the generator is written...

We already depend on it. There are three possible usage of generator:

only use iterator interface, aka. always call next() without param and use yield x as declaration
only use "sender" interface , aka. always call next(v) (after first next()) and use v = (yield); to receive the value
use both

it could make the interface more confusing to the caller

To be honest, I feel mixing bidirectional communication using one interface (let {value:b} = g.next(a) and a = yield b) is the root cause of the confusion. If we could redo everything I would prefer two separate interfaces:

next(void) and yield value (yield as declaration and never return value)
send(value: T):void and function.sent (so has nothing relate to yield)

Unfortunately we do not have the time machine (both for python and js). The best we can do now is something like:

next(void) and yield value
next(value T):void and function.sent

We could introduce linter rules or type inferring rules to help programmers separate the usages:

disallow v = yield value
if there is no function.sent in the generator, infer the type of the generator method as next(void)
if there is function.sent and no yield in the generator, infer the type of generator method as next(value: T): {value: void, done: boolean}
if there are both function.sent and yield value which means we are doing bidirectional communication, then infer the type of generator method as next(value: T_NEXT): {value: T_YIELD, done: boolean}

I believe this is at least better than current next(value: T) follow by next(void) which very hard to be statically analysis if you really want use generator for bidirectional communication.

if we get along fine without being able to send initial values to generators in Python, what advantage would it really bring to JavaScript?

I always believe the real motivation should be the use cases. If there are solid use cases of "only use sender interface" or "use both", then this proposal could bring some advantage.
To be honest, there are not much well known use cases of them both in python and js. In some degree, this is a cycle question, we don't know whether this is because bidirectional communication  is not very useful at all, or it's useful but u don't see many leverage generator just because the weird next() then next(value).


chore: remove experimental flag from run & exec commands

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#222  👈
#221
#220
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @NathanFlurry and the rest of your teammates on  Graphite


Python3.x support?

Hi there
It looks like the following doesn't have Python3.x support.
(1) Could that be more clear in the repo README and in the documentation at http://nucleoatac.readthedocs.io/en/latest/ ?
Perhaps it was there, but I missed it.
(2) Could we get Python3.x support?
It looks like the first catch to modify would be the following:
except Exception, e:
                    ^
SyntaxError: invalid syntax

which is due to comma-separated arguments no longer being the python3.x standard:
http://docs.pythonsprints.com/python3_porting/py-porting.html
One probably needs something like:
except Exception as e:

Agree this is a longstanding problem in academic bioinformatics. I will see if anyone in the lab wants to take over the maintenance of this package. It is a bit of a thankless task…
W
William James Greenleaf, PhD
Associate Professor
Genetics Department
Stanford University School of Medicine
Office:  Beckman 257A
Tel:<PHONE_NUMBER>
Website: http://greenleaf.stanford.edu
Email:  wjg<EMAIL_ADDRESS>On Jan 28, 2018, at 9:09 PM, Alicia Schep <notifications<EMAIL_ADDRESS>wrote:
Yup, lack of incentives for software maintenance & contribution to already published work is definitely a problem in bioinformatics! I'm happy to credit anyone who contributes to NucleoATAC on the README, documentation, etc. Probably can't really help with anything more formal... maybe @wjgreenleafhttps://github.com/wjgreenleaf has ideas?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/GreenleafLab/NucleoATAC/issues/73#issuecomment-361141815, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AII3cg0TcNIzSkp1zuwo4GPTsDDrT5Rwks5tPVKdgaJpZM4Rcv3u.


Fixes several issues with the adaptive line search

will fix a few more things and then this can be merged. we need to make alpha and M parameters though and propagate them through

has been replaced by https://github.com/ZIB-IOL/FrankWolfe.jl/pull/363 and the recent #415


Error: Cannot use 'in' operator to search for 'config' in undefined

I sometimes get the following error when trying to login using the superlogin-client.
Cannot use 'in' operator to search for 'config' in undefined

It only sometimes happens, which makes this quite hard to track down. It seems to be a client side code error from the (transpiled & bundled httpInterceptor function:
{
                key: "_httpInterceptor",
                value: function() {
                    var a = this
                      , b = function(b) {
                        var c = a.getConfig()
                          , d = a.getSession();
                        return d && d.token ? a.checkRefresh().then(function() {
                            return i(b.url, c.endpoints) && (b.headers.Authorization = "Bearer " + d.token + ":" + d.password),
                            b
                        }) : Promise.resolve(b)
                    }
                      , c = function(b) {
                        var c = a.getConfig();
                        return "config"in b ? (i(b.config.url, c.endpoints) && 401 === b.status && a.authenticated() && (p.warn("Not authorized"),
                        a._onLogout("Session expired")),
                        Promise.reject(b)) : Promise.reject(b)
                    }
                    ;
                    this._http.interceptors.request.eject(this._httpRequestInterceptor),
                    this._http.interceptors.response.eject(this._httpResponseInterceptor),
                    this._httpRequestInterceptor = this._http.interceptors.request.use(b.bind(this)),
                    this._httpResponseInterceptor = this._http.interceptors.response.use(null , c.bind(this))
                }
            }

From line:
return "config"in b ? (i(b.config.url, c.endpoints) && 401 === b.status && a.authenticated() && (p.warn("Not authorized"),

I think what happens is that the http error response interceptor is sometimes called with undefined  as response argument. Not sure what could cause this. It might be that we're using basicAuth on our server and it gets an invalid response when trying to do a login request.

The above PR doesn't fix the case where the response is simply a string, I sometimes get the response Unauthorized from the server, this then results in:
Cannot use 'in' operator to search for 'config' in Unauthorized

I've updated the PR to also handle this.

wow, I never seen any of those edge case yet.
might be the way your serve handle the http request.

Oh yeah, if you use basicAuth that's probably a problem.

Fix published with v0.4.2

Thanks for the quick response


DB creates file of 25 GB

Hey. I am always running out of space on my hosting server because there is some file generated in db folder that reaches more than 20 GB in size. What is that?

Yes it's most likely due to checkpoint starvation, you can try the version 1.7.1 beta: UnamWebPanel.zip


DLL_Searching_Audio

Description 📜
It contains an audio presentation on search operation in a doubly linked list.
Fixes #5909

Type of change 📝

[x] Audio (Should be in mp3 format Includes speech clarity, Concise ,Low distortion)

Domain of Contribution 📊

[x] DSA

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

@nimisha-yadav pls review my pr.

@nimisha-yadav applied the changes you suggested .


编译CR6608出包后上传机型提示不匹配

root@OpenWrt:/tmp# sysupgrade openwrt-ramips-mt7621-xiaomi_mi-router-cr6608-squashfs-sysupgrade.bin
Wed Jun 15 17:21:31 CST 2022 upgrade: Device xiaomi,mi-router-cr660x not supported by this image
Wed Jun 15 17:21:31 CST 2022 upgrade: Supported devices: xiaomi,mi-router-cr6608
Image check failed.

不是同一个源码，请从pb-boot刷入


"Controlled Substances" is a myth

Description
I really like the contraband system and how it makes it easier and more clear to players what is and isn't contraband.
However, afterwards space law had its section about controlled substances removed. As a consequence, all chemicals are fair game in the eyes of the law, as the contraband system does not currently work for reagents. Distributing space mirage, meth, arguably vestine (the vial isn't marked as contraband, and even if it was you could just pour it into a different container) is all legal.
Reproduction

produce illegal chemicals
????
profit

Screenshots
Additional context
We should add the controlled substances section back to space law and/or add the ability to account for reagents in containers to the contraband system. (the former is easier)

We could do something similar to the contraband system but the problem is that this would have to only happen if the reagent was scanned with chem goggles.
If not, anyone who right clicks a container will get a flag that says it's a "controlled substance", which means that all gameplay knowledge of knowing the properties and colors of chems is thrown out the window.

We could do something similar to the contraband system but the problem is that this would have to only happen if the reagent was scanned with chem goggles.
If not, anyone who right clicks a container will get a flag that says it's a "controlled substance", which means that all gameplay knowledge of knowing the properties and colors of chems is thrown out the window.

That's a really good point, considering that, making the contraband system work on reagents at all probably isn't worth the effort. Adding the controlled substances page back is probably a better solution in this case.

Thought I'd bring it up here but stealth items interact with this system horribly
Chameleon gear, Epens, explosive pens, turret toolboxes, syndicate sponges, voice masks and more are completely legal. I'm sure some admin has wagered against these in a clarification somewhere but it's not present in the game at all, meaning it's pretty much null
Same issues apply here

Might not be talking about the same thing but those are syndicate stealth items. They're supposed to be unmarked as having them marked as contraband would defeat the stealth of the item.
As far as interaction goes with these items, yeah it might introduce some complications. The medical doctor holding a syringe marked as containing an illegal substance as they're trying to treat the HoS would be interesting to see.

Might not be talking about the same thing but those are syndicate stealth items. They're supposed to be unmarked as having them marked as contraband would defeat the stealth of the item.
As far as interaction goes with these items, yeah it might introduce some complications. The medical doctor holding a syringe marked as containing an illegal substance as they're trying to treat the HoS would be interesting to see.

I know, were talking about the same thing
My point was that them (stealth items) being unmarked means they are technically legal with how the system was implemented and intended to be used

yea honestly I didn't like when the contraband pages were removed from space law for this reason, but it only occured to me just recently that controlled substances are gone too

Security could have some sort of device that can hold like 3 units of a chemical, and it will list whether the chemical inserted is illegal under current NT databases. Like a breathalyzer but for chems

It could say or whisper something like "[ChemName] detected. Class-[LevelOfViolation] violation." if it detects an illegal substance in the sample after a moment of processing. And if there's nothing it can just say like "No illegal substances identified." to prevent science or others from using it to ID random chems on the floor or whatever

It could say or whisper something like "[ChemName] detected. Class-[LevelOfViolation] violation." if it detects an illegal substance in the sample after a moment of processing. And if there's nothing it can just say like "No illegal substances identified." to prevent science or others from using it to ID random chems on the floor or whatever

I mean
People can already free test chems with metamorphic glasses


broken lspconfig

Some language modules that depend on lspconfig are not working at the moment. That has happened with clangd, as well as rust,
When you try to use nyoom with either of the servers mentioned above, you will get the error:
[lspconfig] Cannot access configuration for SERVER. Ensure this server is listed in server_configurations.md or added as a custom server.
I am not really sure how i could help in this, as i really have no idea how to use lisp.

Same problem for rust-analyzer; I performed a "sudo pacman -S neovim-lspconfig" command and the problem somehow magically disappeared, although I have no idea why.
Btw: the error that you got disappeared for me but I still got some other errors for rust-tools which I have to open an issue for


codelst:0.0.1

I am submitting

[x] a new package
[ ] an update for a package

I have read and followed the submission guidelines and, in particular, I

[x] selected a name in conformance with the guidelines
[x] added a typst.toml file with all required keys
[x] added a README.md with documentation for my package
[x] have chosen a license and added a LICENSE file or linked one in my README.md
[x] ensured that my submission does not infringe upon the rights of a third party
[x] tested my package locally on my system and it worked
[x] named this PR as name:version of the submitted package
[x] agree that my package will not be removed without good reason

Description: codelst adds useful features for rendering source code. It can add line numbers, load and show source code from files, highlight lines or add labels to specific lines to make references from other places.
As of now it lacks a comprehensive manual, but the examples should make the usage clear enough.

The sourcefile function doesn't work unfortunately because the read call happens within the package. There is currently no way for a package to read files outside of itself.

Thats unfortunate but understandable. I didn't test that properly.
I will remove that function.

I also noticed that highlighting for some languages (Typst itself in particular) is suboptimal because each line is highlighted individually (might be a deliberate trade-off, but just wanted to mention it in case you are not aware).

I'm aware of that problem and hope to fix it in future releases. I experimented with different solutions, but they weren't as robust and broke for things like page breaks or long lines.

I already did some minor fixes for 0.0.2 and added a manual. With the changes to sourcefile I bumped the version to 0.0.3 and updated the pull request accordingly.
sourcefile now takes the file content instead of the filename and expects the user to call read from the main document:
#sourcefile(read("filename.typ"), lang:"typ")

Thank you!


Updated asgiref dependency.

Matches #14222

@felixxm — I'll take this as the main one and backport with the <4 (if that makes sense.)


V6connect

Nice. Can you also update the accounts example?
On Sat, Feb 9, 2019 at 7:16 AM Tyler Sorensen<EMAIL_ADDRESS>wrote:

Merged #3 https://github.com/makerdao/dai-plugin-trezor-web/pull/3 into
master.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/makerdao/dai-plugin-trezor-web/pull/3#event-2128773806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAL0g8-N1umdOSGaJKQ4VliVVZnZsy4Iks5vLuYwgaJpZM4aylRp
.