<EMAIL_ADDRESS>

There are several breaking changes on the cards for<EMAIL_ADDRESS>
[x] fantasyland/fantasy-land#146: prefix method names
[x] fantasyland/fantasy-land#145: flip ap argument order
[x] fantasyland/fantasy-land#135: define Traversable in terms of traverse rather than sequence
[ ] fantasyland/fantasy-land#162: remove support for .constructor.empty

I'll keep this pull request up to date as pull requests are merged into the FL repository.

These look good so far.  I'm looking forward to seeing fantasyland/fantasy-land#135.
I'm not as convinced by fantasyland/fantasy-land#162, though.

The ap change is a bit of a PITA. This seems like yet another case of vacillating over which way to convert what is semantically an infix operation to prefix.

The ap change is a bit of a PITA.

It's a good change: it makes ap consistent with map and chain.
Ramda users won't notice anything as R.ap won't change. :)

The ap change has been much needed for a very long time.

FYI: https://github.com/fantasyland/fantasy-land/releases/tag/1.0.0
If you spot anything out of the norm, then let me know so we can get a new release out.

This pull request is now ready for review.
I rewrote the implementations of the Id, Maybe, and Either types which are used in the test suite in various places. As a result, Sanctuary is no longer a dev dependency.
Questions:

Should we support the old method names (e.g. map) in addition to the new names (e.g. fantasy-land/map) for some period of time? I hope the answer is no.

Should we continue to dispatch to sequence for some period of time? Again, I hope the answer is no.

this looks good -- better -- to me. I prefer dispatching to the prefixed names, it is much less ambiguous.
🐪

@CrossEye?

Sorry, will look this evening.

I prefer dispatching to the prefixed names, it is much less ambiguous.

I pushed for this in FL, but now that I see it, I worry about it a bit.  My concern might be mostly a transitional one, but it's real.  Will this break all sorts of existing useful integrations because other libraries are still using, say, map and not fantasy-land/map?
This is a very serious concern.  And I'm not sure what to do about it.
In every other way, I love this change.  But that makes me squeamish about just doing it.

Will this break all sorts of existing useful integrations because other libraries are still using, say, map and not fantasy-land/map?

Would you like to support both for some period of time? It'll be messy, but shouldn't be difficult.
It's worth noting that not supporting prefixed names would break all sorts of useful integrations. ;)

Would you like to support both for some period of time?

No. Tear off that band-aid

Also as argument order of ap has changed it might be problematic.?

Also as argument order of ap has changed it might be problematic.?

This isn't a problem since the ap change was released in the same version of the spec as the prefixes. So we'd check for fantasy-land/ap, and dispatch to it (the new way) if present; otherwise we'd check for ap and dispatch to it (the old way) if present.

My concern is broader, though.
I think I may be alone in this, but I do not think of the dispatching as specific to FantasyLand.  While that's an extremely useful specification, I would like for our dispatching to be broader than that.
We started the dispatching before incorporating FL, and at the time my thoughts were on how it might someday be used to integrate streams and lists -- something similar to what Highland eventually did.  When there were suggestions to integrate with FL, it was a no-brainer to me.  But I never felt as though that was the raison d'être for our dispatching.  I do think that it should have a somewhat privileged place, because it is the only specification out there doing this important work.  However, I would like to be able to work well with other tools, regardless of whether they adhere to the FantasyLand spec.
We haven't been great about this yet, but that doesn't mean that we shouldn't get there.  I think it would be ideal to simply be able to work with libraries like Immutable, like Highland, like Flyd.

I do not think of the dispatching as specific to FantasyLand. While that's an extremely useful specification, I would like for our dispatching to be broader than that.

I am 100% on the other side. I only want to dispatch to "methods" that have well-defined semantics. It's amusing that Highland is in your example list, because it is moving toward FL compatibility. And there's this from Flyd's README: "Complies to the fantasy land applicative specification." So maybe Immutable is out. Oh well. You can always bridge the gap with lenses.

Well, https://github.com/caolan/highland/pull/114 hasn't been updated in 20 months.  I'm not sure that really counts as "moving towards"!  :smile:
But Immutable, Flyd, and Highland were meant to be simply examples.  If you have a data structure with a meaningful method obj.take :: Int -> a then I would love it if Ramda offered to make this a pure function for you with R.take(5, obj); //=> (something of type a).

I only want to dispatch to "methods" that have well-defined semantics.

Well-defined, but unenforceable, doesn't seem all that powerful to me.  I would offer a somewhat privileged place to FantasyLand, mostly because the types there work together to offer additional power (think lift, for instance.)
We've discussed this before (see especially #1173) and it got pretty hot.  But I'm much closer to the view David expressed some time ago:

I'm starting to see that dynamic dispatch is not a nice extra: it's the very core of Ramda (or should be).
Ideally, every Ramda function would simply dispatch: there would be no code to speak of (except perhaps code to derive functions from other functions).

i remain strongly in favor of merging this and moving away from promiscuous dispatching. i would like to get it in and move toward 1.0

Are there any plans to still support the old dispatches?
Or is part of upgrading to 1.x mean you will have to wait until all other FL compliant libs in your project are moved over to 1.x of FL?
So for instance if I am using Ramda to provide some point-free goodness on say most.js for my super 🔥 frontend masterpiece. Does that mean I am expected to wait until most.js decides to update to the new FL before I can update to 1.x of Ramda? and I would have to wait for ALL FL-compatible stuff to make the move before I can upgrade to 1.x.
Am I correct in that assumption?

@evilsoft:
That discussion is part of what's slowing us down here.  I'm in favor of of retaining the old dispatching, either temporarily or permanently, which is a change from what @davidchambers proposed here.  @buzzdecafe is quite opposed.
This is a fairly fundamental disagreement, having to do with what we think our dispatching is about.  @buzzdecafe and I are still trying to schedule the knock-down-drag-out fight over this issue.

HA. @CrossEye gonna get some 🍿 and have a little sit down.

  There was a proposal to have three televised debates on this issue over several weeks.  We had @paldepind, @scott-christopher, and @davidchambers agreeing to be moderators.
But with the threats from my opponent to seat John-David Dalton and Jeremy Ashkenas in the front row, I'm really not sure he's serious about this.

@buzzdecafe

I am 100% on the other side. I only want to dispatch to "methods" that have well-defined semantics.

I very much agree with this.
@CrossEye

I do think that it should have a somewhat privileged place, because it is the only specification out there doing this important work.

Well, it's actually not the only spec. I'm working on a fantasy land replacement called Jabz :smile: It's very much a work in progress but one key aim is to provide a specification that allows for significantly better performance than FL. I.e. its the same abstractions—but at a lower overhead.

While that's an extremely useful specification, I would like for our dispatching to be broader than that.

To me it would be very helpful if you could give a practical real-world example of how our current dispatching is beneficial in ways that is unrelated to FL. Creating useful abstractions is tricky. And in other languages using them typically happens in principled ways using interfaces or type classes.
I'm not at all convinced that ad-hoc dispatching through duck-typing results in integration with 3rd party libraries in a meaningful way. We currently do have dispatching but we still don't integrate with Highland nor Immutable. But I'd love to be proven wrong with some actual code of how our dispatching makes life with other libraries easier. But without that it feels like we're keeping the dispatching based on a vague vision about somehow working with many libraries but without a clear idea about how dispatching actually realizes that dream.

I do think that it should have a somewhat privileged place, because it is the only specification out there doing this important work.

Well, it's actually not the only spec. I'm working on a fantasy land replacement called Jabz :smile: It's very much a work in progress but one key aim is to provide a specification that allows for significantly better performance than FL. I.e. its the same abstractions—but at a lower overhead.

I'm very excited to see it!  Are you going to forgo compatibility with Ramda?

While that's an extremely useful specification, I would like for our dispatching to be broader than that.

To me it would be very helpful if you could give a practical real-world example of how our current dispatching is beneficial in ways that is unrelated to FL.

I will try to do so soon.  Perhaps this evening.

@paldepind: I haven't forgotten this.  I'm just behind on everything.  I'll try again tomorrow.

A bit related ramda-fantasy#131

@CrossEye please either state your case or let this one through. Already over a month old, and i think the only  thing holding it up is you?

I've been talking about this for a long time:

Say we had this tree, tree1:
               A
    +----------^----------+
    |          |          |
    B          C          D
+---^---+  +---^---+  +---^---+
|   |   |  |       |  |   |   |
1   E   4  6       7  8   F   4
  +-^-+                   |
  |   |                   |
  2   3                   6

Then if we wanted to map square over that tree, the result should be pretty obvious:
map(square, tree1); //=>

               A
    +----------^----------+
    |          |          |
    B          C          D
+---^---+  +---^---+  +---^---+
|   |   |  |       |  |   |   |
1   E  16 36      49 64   F  16
  +-^-+                   |
  |   |                   |
  4   9                  36

Similarly if we wanted to run filter over the tree:
filter(odd, tree1); //=>

         A
    +----^-----+
    |          |
    B          C
+---^---+      |
|       |      |
1       E      7
        |
        |
        3

I could add that perhaps we would want to do
take(5, tree1); //=>

        A
    +---^--+
    |      |
    B      C
+---^---+  +
|   |   |  |
1   E   4  6
  +-^-+
  |   |
  2   3

or any of a number of other similar functions.  To me, perhaps the most central point of Ramda is to make it easy to work via functional composition.  If Ramda can take the map method of Array.prototype and of other useful types and turn them into plain functions, it's adding value, because those functions can now be composed.  That's just as true for something that doesn't happen to have exposed fantasy-land/map as for something that has.  The only advantage, to my mind of the prefixing is that it makes it clear that someone is claiming to follow certain laws, and so we and others could take advantage of these laws for certain implementations to create useful abstractions such as lift.
But there is nothing here that says that map is so much more important than filter or take or many others methods we could lift into functions.
I would delegate to FantasyLand if it's available, but if not, I still like delegating to user-supplied functions.  I'm having a hard time because this seems so obviously useful to me that I really don't understand the objection.

this is blocking the chainRec PR, so let's come to a decision timely. I am strongly in favor. @CrossEye is opposed unless old dispatches are kept. @davidchambers says it's messy but possible. so let's do that for now and come back later to clean up

Z.concat knows how to merge string maps:
> Z.concat({concat: Math.sin}, {concat: Math.cos})
{concat: Math.cos}

The problem is that we want to preserve the current Ramda behaviour of dispatching to concat:
> R.concat({concat: Math.sin}, {concat: Math.cos})
NaN

We can't easily use Z.concat as it only respects the fantasy-land/-prefixed property.

I've updated this pull request. Shall we update the documentation to indicate that FL functions dispatch to both prefixed and unprefixed methods? It's particularly confusing in the case of ap because the argument order differs.

I didn't really follow the FL discussion around swapping the order of ap, but I was assuming that we would follow along with this.  Is there any good reason (besides backward compatibility) to keep a different order for our version?
As to the documentation, I think we first need to settle what we want to do with dispatching.  If this is a short way station on the way to removing it, then there is no need.  If we are going to keep something more substantial, then I think we need to figure out how we'd like to document it.

I didn't really follow the FL discussion around swapping the order of ap, but I was assuming that we would follow along with this.  Is there any good reason (besides backward compatibility) to keep a different order for our version?

The order in which a fantasy-land/ap method takes its arguments and the order in which R.ap takes its arguments are unrelated concerns. The change to the FL spec was made to bring ap into line with map and chain.
 This looks like a typo but it reflects the change to the FL spec. Were we to dispatch to ap assuming the new method signature we'd break backwards compatibility for no gain.

Were we to dispatch to ap assuming the new method signature we'd break backwards compatibility for no gain.

Wouldn't that just correct the mistake that's been in one of most confusing functions for far too long?

http://ramdajs.com/docs/#ap

Dispatches to the ap method of the second argument, if present. Also treats curried functions as applicatives.

Well, no, it dispatches to the ap method of the first argument, if present:
ap(
  {ap: (x) => `ap_first(${x})`, toString: () => 'first'},
  {ap: (x) => `ap_second(${x})`, toString: () => 'second'}
); // => "ap_first(second)"

It strikes me that this is an opportunity to correct that mistake in a consistent fashion.

is there any progress with this?

@davidchambers also consider adding bimap, i don't see it here. But, maybe i am wrong. 👍

@syaiful6, #1938 will bring us bimap and all the other functions defined in sanctuary-type-classes. Scott needs to decide what to do with this pull request, though, before we move on to #1938.

I didn't feel that it was particularly waiting on me, although I might be the only one on one side of the discussion.  The main issue is that we need to decide what we're doing with dispatching before we can figure out what to do with this issue, #1938, #1949, #1950.  The last of the discussion seems to have been on #1938.

I'm very excited to see it! Are you going to forgo compatibility with Ramda?

I've been meaning to respond to this. Mostly because it will lead me to a Ramda-related issue that I'd like to discus. But I wanted to get Jabz to a more presentable state before doing so. Now it has a decent readme, API documentation and a blog post describing how and why Jabz differs from Fantasy Land.
To answer the question: Jabz uses non-prefixed method names, so currently it is mostly compatible with Ramda. However, being Ramda compatible is actually not something I care about. Because, to me, our current Fantasy Land integration brings very little value. Actually I consider it somewhat harmful as it sits in an uncanny valley where the little it does brings false expectations that it may do more. I'm sorry for these harsh statements. Allow me to explain myself.
Let's say I'm brand new user of Ramda. I've heard that it integrates with a specification for monads, traversables, etc. I've used these abstractions in some other language so I'm familiar with them.
The first thing I do is I start writing some code that uses maybe. I write something like R.map(myFuntion, myMaybe). It works and I'm happy.
Pretty soon I end up with a maybe value inside a maybe value which I want to flatten. I know that maybe is a monad, I know that a core capability of monads is that they support flattening (the operation is often called join) and I know that Ramda works with monads. So I go looking for a function in Ramda to do this. I look at both R.join and R.flatten but both do something different. Now I'm confused. Flatten/join is a core operation on monads. Why can't I find it?
Later I do some work with a foldable. I know that all foldables support a size/length operation. Again I am disappointed to find out that R.length doesn't work on foldables. This disappointed increases when I realize that only R.reduce works on foldable. None of all the other function that could work on foldables actually does.
My point with the above is this: The abstractions specified by fantasy land are a lot more than just the few methods that are explicitly part of the spec. The many operations that can be derived from these are equally important. To my knowledge R.lift, R.pipeK, R.composeK, R.both and R.either are the only derived operations that we provide. People who actually wants to get the full benefit of the abstractions will be disappointed. To put things into perspective, we have 1 function that works with foldables, Jabz has 15 functions (and counting) and Haskell's Data.Foldable has about 25.
Supporting abstraction in this half-baked way is bad. But fixing this and going "all in" on the abstractions poses several problems as well:

The size and complexity of the library would grow due to the added derived methods.
We would have to include a lot of functions that are only useful with fantasy land abstractions. For instance having toArray for foldables is very useful. Another example, mapTo is useful for many functors but not with arrays. These functions are useless to people who just use Ramba with plain JS objects and arrays. This might alienate them.
Performance for many operations would be bad. For instance R.isEmpty can work for any foldable but with fantasy land it would take O(n) time which is pretty tragic (the Jabz spec support it in constant time).

In my opinion we should tighten the focus of Ramda. It should be a set of utility functions for native JavaScript objects. All dispatching should be removed. People who wants to use fantasy land abstractions may use sanctuary-type-classes which looks very nice.

I don't normally chime in, but this is horseshit!

Because, to me, our current Fantasy Land integration brings very little
value

So without FL you wouldn't have any standardisation for this, it's not
perfect and it's slow moving, but someone moaning about it because it
doesn't fit "their" needs is about as constructive as chocolate fire
guard!!!

Jabz uses non-prefixed method names, so currently it is mostly compatible
with Ramda.

Do you even know why FL has them? Because a LOT of ramda developers wanted
it. They pushed hard for it!
On Sat, 14 Jan 2017, 16:13 Simon Friis Vindum<EMAIL_ADDRESS>wrote:

I'm very excited to see it! Are you going to forgo compatibility with
Ramda?
I've been meaning to respond to this. Mostly because it will lead me to a
Ramda-related issue that I'd like to discus. But I wanted to get Jabz to a
more presentable state before doing so. Now it has a decent readme
https://github.com/Funkia/jabz, API documentation
https://funkia.github.io/jabz/ and a blog post
http://vindum.io/blog/introducing-jabz/ describing how and why Jabz
differs from Fantasy Land.
To answer the question: Jabz uses non-prefixed method names, so currently
it is mostly compatible with Ramda. However, being Ramda compatible is
actually not something I care about. Because, to me, our current Fantasy
Land integration brings very little value. Actually I consider it somewhat
harmful as it sits in an uncanny valley where the little it does brings
false expectations that it may do more. I'm sorry for these harsh
statements. Allow me to explain myself.
Let's say I'm brand new user of Ramda. I've heard that it integrates with
a specification for monads, traversables, etc. I've used these abstractions
in some other language so I'm familiar with them.
The first thing I do is I start writing some code that uses maybe. I write
something like R.map(myFuntion, myMaybe). It works and I'm happy.
Pretty soon I end up with a maybe value inside a maybe value which I want
to flatten. I know that maybe is a monad, I know that a core capability of
monads is that they support flattening (the operation is often called join)
and I know that Ramda works with monads. So I go looking for a function in
Ramda to do this. I look at both R.join and R.flatten but both do
something different. Now I'm confused. Flatten/join is a core operation on
monads. Why can't I find it?
Later I do some work with a foldable. I know that all foldables support a
size/length operation. Again I am disappointed to find out that R.length
doesn't work on foldables. This disappointed increases when I realize that
only R.reduce works on foldable. None of all the other function that
could work on foldables actually does.
My point with the above is this: The abstractions specified by fantasy
land are a lot more than just the few methods that are explicitly part of
the spec. The many operations that can be derived from these are equally
important. To my knowledge R.lift, R.pipeK, R.composeK, R.both and
R.either are the only derived operations that we provide. People who
actually wants to get the full benefit of the abstractions will be
disappointed. To put things into perspective, we have 1 function that works
with foldables, Jabz has 15 functions (and counting) and Haskell's
Data.Foldable has about 25.
Supporting abstraction in this half-baked way is bad. But fixing this and
going "all in" on the abstractions poses several problems as well:

The size and complexity of the library would grow due to the added
derived methods.
We would have to include a lot of functions that are only useful
with fantasy land abstractions. For instance having toArray for
foldables is very useful. Another example, mapTo
https://funkia.github.io/jabz/#mapTo is useful for many functors but
not with arrays. These functions are useless to people who just use Ramba
with plain JS objects and arrays. This might alienate them.
Performance for many operations would be bad. For instance R.isEmpty
can work for any foldable but with fantasy land it would take O(n)
time which is pretty tragic (the Jabz spec support it in constant time).

In my opinion we should tighten the focus of Ramda. It should be a set of
utility functions for native JavaScript objects. All dispatching should be
removed. People who wants to use fantasy land abstractions may use
sanctuary-type-classes
https://github.com/sanctuary-js/sanctuary-type-classes which looks very
nice.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ramda/ramda/pull/1900#issuecomment-272633791, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACcaGLWdxvI8HmNsKkNi2W5eNW48FkGGks5rSPQ-gaJpZM4J7i5W
.

So without FL you wouldn't have any standardisation for this, it's not
perfect and it's slow moving, but someone moaning about it because it
doesn't fit "their" needs is about as constructive as chocolate fire
guard!!!

I think you're misunderstanding what I wrote. I'm not saying that Fantasy Land doesn't add any value. I'm saying that what Ramda is currently doing with the specification adds very little value. We just dispatch to the methods that Fantasy Land compatible structures already provide but forgoes any integration beyond that.

Do you even know why FL has them? Because a LOT of ramda developers wanted
it. They pushed hard for it, in fact I was the one voice against it!

Yes I know. I was part of the discussion back then.

We've asked you to open issues, you haven't and so you're now trying this method.

I don't know what you mean with the statement "you're now trying this method". This is a completely separate issue. I don't know what you think I'm trying. I'm making a case against dispatching in Ramda. I've been arguing for its removal several times in the past.
I will open issues I just haven't gotten around to do it yet. Ideally I want to get every idea from Jabz into Fantasy Land.

TL;DR: Any progress on this? Its a shame that is blocking other PRs from some time now.
I came here because I'm having problems with ap which is following FL's <v1.0 order. There is #2002 to upgrade to the current order but is blocked by this issue. I'm trying to write js in a functional way which I've really come to appreciate appreciate (using Tasks/Futures for async stuff which is js bread and butter), but now I'm limited to only using the data.task lib which uses the old ap order, the rest of the future libs uses the new ap order (including the new folktale AFAIK) so I need to decide between them or ramda. I know this issue is related to some decisions like the dispatching discussion (I've read a fair share of the issues), so I guess what I'm saying is that maybe no decision is worse than any?

Agree with @rickmed this should be resolved ASAP

Honestly, there's simply not been a lot of work going into Ramda lately.  I hope that's about to change, but no guarantees.

:+1: Can we merge this now @CrossEye ?


Feature: add base fee to the Block object (EIP-1559)

The London hardfork introduces a change to fee markets on Ethereum (EIP-1559). This introduces a new "base fee per gas" per block, which is not currently available. Can we add this to the Block object so it is available to developers in mappings?
Discord request

I created a really simple PR to add baseFee to the Block class here graphprotocol/graph-ts#197
I'm now looking into how this can be populated by the node

We would also need to deal with the outdated data in the block cache for existing DBs. Maybe by having a migration that clears the block cache.

Created a PR (tomusdrw/rust-web3#530) to add the base fee to rust-web3, which I imagine is an upstream prerequisite for this feature

This is available in graph-node:v0.25.0 (PR), graph-ts:v0.24.1 and graph-cli:v0.25.0. Thanks for opening @dmihal!


Meet an issue in testing case.

Here is the main js code I used:
var browserPerf = require('browser-perf');
var wd = require('wd');
var options = {
    selenium: 'http://localhost:4444/wd/hub',
    browsers: ['chrome'],
    actions: 'click'
};

var browser = wd.promiseChainRemote();
browserPerf('http://www.google.com', function(err, res){/*callback*/}, options);

Here we define a customized action "click" in the actions which is
require('colors');
var chai = require("chai");
var chaiAsPromised = require("chai-as-promised");
chai.use(chaiAsPromised);
chai.should();

var fs = require('fs'),
    wd = require('wd'),
    debug = require('debug');

// enables chai assertion chaining
chaiAsPromised.transferPromiseness = wd.transferPromiseness;

module.exports = function() {
    return function(browser) {
        console.log('start click');
        return browser.elementByCss('#lst-ib').click();
    };
};

While in the execution, the program exits with "undefined" exception. If we set a breakpoint at "console.log('start click')", we can see "browser.elementByCss" is indeed a function object. Anything goes wrong? Thanks a lot.

@stormzh Were you able to get this fixed ? You basically should require(./click.js) instead.

@axemclion I had discussion with @stormzh offline on this. It looks we have to use the .then() syntax powered by Q, to avoid running into this sort of issue. Is this a known fact? If it is, we may just edit the document to mention that.

Yes, the actions follow promises and you are right, we should indeed edit the documentation. Can you please change the wiki so that it benefits others too ?

Just add a paragraph in the "actions" section on the page: https://github.com/axemclion/browser-perf/wiki/Node-Module---API

@hy9be Awesome - thanks !!


Maintain focal loss and lazy adam

Hi @seanpmorgan
Just read TF Addons newsletter. Would like to maintain focal loss and lazy adam module if that is ok

Absolutely! There was a PR submitted to TF core related to LazyAdam but I haven't had time to review. Would you mind taking a look when you have some time:
https://github.com/tensorflow/tensorflow/issues/23668
https://github.com/tensorflow/tensorflow/pull/24788


DEAPlotting functions produce inconsistent outputs

The two plotting functions in DEAPlotting produce inconsistent outputs: three_band_image produces a matplotlib "plot" and "figure" objects wrapped in a tuple, while three_band_image_subplots simply plots the image directly without creating plot/figure objects.
For consistency/ease of use, it would be great if these both functioned in the same way.
https://github.com/GeoscienceAustralia/dea-notebooks/blob/master/algorithms/DEAPlotting.py

Superseded by #92


Get status of VM from GCE

#482

@jessicaochen Could you also approve using the robot command as well? I think that's what causes the merge.

/lgtm


tool for loading CommonJS modules lazily

What kind of change does this PR introduce?
refactoring
Did you add tests for your changes?
no
Does this PR introduce a breaking change?
no
What needs to be documented once your changes are merged?
Nothing.
Since webpack 5 support only Node 10 and higher this util function can be used for loading modules asynchronously
I have checked code base using  regex ^(?!const)\s*[a-zA-Z\d]+\s*=\s*require\(.*\) in lib folder for possible usage, maybe there are other places too

@sokra What is the best way to run benchmarks for webpack@5? yarn run benchmark looks like abandoned command or it must be updated =)

The performance suffer when going through a Proxy

Yep, I wanted to run benchmarks, but did not found out how to do it better node benchmark/benchmark or yarn run benchmark ? (second command does not work).
If this is a problem for speculative optimization, I can suggest only to force get

Instead you could try to use memorization instead:

Idea of this approach was to use required modules as is, without any extra function calls: new (getAssetParser())() or const AssetParser = getAssetParser(); new AssetParser()

the require("../util/lazyRequire")(require) construct is hard to understand for webpack. You won't be able to webpack webpack and some tools rely on that. That's a big blocker.

We can mark it with PURE annotation before or on fly, or there is another problem?

We can mark it with PURE annotation before or on fly, or there is another problem?

The problem is that require is used without calling it.

Idea of this approach was to use required modules as is, without any extra function calls: new (getAssetParser())() or const AssetParser = getAssetParser(); new AssetParser()

Yes it would look better, but that doesn't really matter as much as performance matters.

Thanks


feat: add Amazon SageMaker backend dokumentation

This PR adds documentation about Amazon SageMaker backend with example how to deploy Amazon SageMaker and how to configure backend.
✅ Checks

[x] My pull request adheres to the code style of this project
[x] My code requires changes to the documentation
[x] I have updated the documentation as required
[ ] All the tests have passed

Commit signature fixed ready to be merged


[Reproducers] Add a bridging header test

Add a test that ensures we can reproduce Swift programs that use a
bridging header.

@swift-ci please test with https://github.com/apple/swift-lldb/pull/1734

https://github.com/apple/swift-lldb/pull/1734
@swift-ci please test


azcopy don't work in alpine since 10.25.0

Since 10.25.0 the azcopy linux_amd64 binary don't works in alpine.
Which version of the AzCopy was used?
10.25.0 and 10.25.1
Which platform are you using? (ex: Windows, Mac, Linux)
Alpine Linux
What command did you run?
azcopy --version
What problem was encountered?
Any execution fail with this message:
0.104 Error relocating /usr/local/bin/azcopy: __vfprintf_chk: symbol not found
0.104 Error relocating /usr/local/bin/azcopy: __fprintf_chk: symbol not found

In 10.24.0, 10.25.0 and 10.25.1, ldd output was the same:
/ # ldd /usr/local/bin/azcopy
        /lib64/ld-linux-x86-64.so.2 (0x7efd860d0000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7efd860d0000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7efd860d0000)

How can we reproduce the problem in the simplest way?
Using the following Dockerfiles:
:green_circle: This build works fine:
 docker build . -f Dockerfile.10.24.0.txt -t local-azcopy:10.24.0

Dockerfile.10.24.0.txtFROM docker.io/library/alpine:3.17

RUN apk update
RUN apk add --no-cache curl libc6-compat
RUN curl -s -L https://azcopyvnext.azureedge.net/releases/release-10.24.0-20240326/azcopy_linux_amd64_10.24.0.tar.gz | tar xvzf - --strip-components=1 -C /usr/local/bin/ azcopy_linux_amd64_10.24.0/azcopy
RUN chown root:root /usr/local/bin/azcopy
RUN chmod +x /usr/local/bin/azcopy
RUN ldd /usr/local/bin/azcopy
RUN azcopy --version

:red_circle:  This builds don't works:
 docker build . -f Dockerfile.10.25.0.txt -t local-azcopy:10.25.0
 docker build . -f Dockerfile.10.25.1.txt -t local-azcopy:10.25.1

Dockerfile.10.25.0.txtFROM docker.io/library/alpine:3.17

RUN apk update
RUN apk add --no-cache curl libc6-compat
RUN curl -s -L https://azcopyvnext.azureedge.net/releases/release-10.25.0-20240522/azcopy_linux_amd64_10.25.0.tar.gz | tar xvzf - --strip-components=1 -C /usr/local/bin/
RUN chown root:root /usr/local/bin/azcopy
RUN chmod +x /usr/local/bin/azcopy
RUN ldd /usr/local/bin/azcopy
RUN azcopy --version

Dockerfile.10.25.1.txtFROM docker.io/library/alpine:3.17

RUN apk update
RUN apk add --no-cache curl libc6-compat
RUN curl -s -L https://azcopyvnext.azureedge.net/releases/release-10.25.1-20240612/azcopy_linux_amd64_10.25.1.tar.gz | tar xvzf - --strip-components=1 -C /usr/local/bin/
RUN chown root:root /usr/local/bin/azcopy
RUN chmod +x /usr/local/bin/azcopy
RUN ldd /usr/local/bin/azcopy
RUN azcopy --version

Have you found a mitigation/solution?
No. :cry:

You will have to install the dependency that is missing then it should work fine.

Closing this issue as a suggestion has been made and there has been no further activity on this thread. Please reopen if you are still experiencing the same issue.


Add your marker to the HacktoberMap! (round 2)

If this is your first pull request, please read this article: How To Create a Pull Request on GitHub
Step 1
Fork the repo by pressing the "Fork" button on the top right side of the
repository and clone your forked repository.
Step 2
In your forked repository, edit hacktobermap.js and add your name, location,
latitude and longitude to the bottom of the file using this format:
  {
    name: "Your name",
    location: "Your location",
    latitude: 12.34,
    longitude: 56.78
  },

You can get the coordinates of your location from https://latlong.net.
Warning: Do NOT put your exact coordinates for your own safety!
Step 3
Commit your changes and submit a pull request! After your pull request gets accepted, you will be able to see your very own marker on the HacktoberMap!
Step 4
Please star the repo if you like this fun little Hacktoberfest project ❤

Final round: #160


Do we allow attached node operate in promiscuous mode?

Is your feature request related to a problem? Please describe.
From https://github.com/openthread/openthread/blob/master/src/core/api/link_api.cpp#L300, we don't allow.
From https://github.com/openthread/openthread/blob/master/src/ncp/ncp_base.cpp#L1356, no check for this at all.
Describe the solution you'd like
I think it makes sense to support this, so that an attached node can still act as sniffer.
Describe alternatives you've considered
None
Additional context
None

@smides-nest

FWIW, many IEEE 802.15.4 radios do not support both promiscuous mode and auto generation of immediate acks.

FWIW, many IEEE 802.15.4 radios do not support both promiscuous mode and auto generation of immediate acks.

We actually had a plan to implement this in the future to support functional Thread stack and sniffing at the same time.

FWIW, many IEEE 802.15.4 radios do not support both promiscuous mode and auto generation of immediate acks.

We actually had a plan to implement this in the future to support functional Thread stack and sniffing at the same time.

@simonlingoogle , what was the plan to support radios that do not support promiscuous mode and auto-generation of immediate acks at the same time?

@simonlingoogle , what was the plan to support radios that do not support promiscuous mode and auto-generation of immediate acks at the same time?

It was actually less of a plan, but more of a thought or idea.
The intention was to have similar user experience to other networks (e.g. Ethernet) in which developers can use wireshark to capture all packets while the network stack is still working. We expected it to be helpful for OT developers to diagnose issues on OTBR.

It was actually less of a plan, but more of a thought or idea.
The intention was to have similar user experience to other networks (e.g. Ethernet) in which developers can use wireshark to capture all packets in promiscuous mode while the network stack is still working. We expected it to be helpful for OT developers to diagnose issues on OTBR.

@simonlingoogle , I agree it can be useful. However, as mentioned previously, many existing radios do not support promiscuous mode and auto-generation of immediate acks at the same time. It may be that newer radios do support this, however.


Break-fix Ruby 2.3.3 not supported

Ruby 2.3.3 is no longer supported on Heroic.  We need to up grade to 2.4.0

upgraded to ruby 2.4.0.


Collecting more info for ProcNModules

Pulling more info from API:

CreationTimeUTC
LastWriteUTC
LastAccessUTC
Process Name, PID to associate with all loaded DLLs
Goal is to use this to build additional analysis modules for DLL Search Order hijack leads.

Thanks, Juan. In general, I favor more smaller commits, it's easier to backout changes that way, so no worries about pushing little changes. I do that all the time, that's why there are so many commits to the project. Commit early, commit often, but always commit working code. :)

Awesome,  good advice.  Contributing to a project like this is new but also fun.
Thanks!Juan
On Thu, Jul 30, 2015 at 8:41 PM -0700, "Dave Hull"<EMAIL_ADDRESS>wrote:
Thanks, Juan. In general, I favor more smaller commits, it's easier to backout changes that way, so no worries about pushing little changes. I do that all the time, that's why there are so many commits to the project. Commit early, commit often, but always commit working code. :)

Reply to this email directly or view it on GitHub:
https://github.com/davehull/Kansa/pull/118#issuecomment-126557744


Extension is difficult & other long term design decisions

I think this is the starting point for a wider conversation. Or just tell me I'm imagining things. Either or.
FWIW I can use and extend this stuff fine now, hence why I will totally accept "nah, it's fine" as an answer.
However, I've found it a bit of an uphill struggle to get to grips with, and am still a little unclear on best practice for extending. I've seen several others taking similar or different approaches to this (on the query and the execute side). Generally, doing roughly what is in:
https://github.com/envoylabs/whoami/blob/main/src/lib.rs#L36 for execute and
https://github.com/CosmWasm/cw-nfts/blob/d79bd6f7803dd366430ade1b77edbeaea74946ca/contracts/cw2981-royalties/src/lib.rs#L79 for query
seems to be kinda how most folk do it (roughly).
I'm not experienced enough at Rust to make a perfect call on this, but my gut feeling is that the way CW721 base is implemented is:

unapproachable for newer rust developers
difficult to extend
results in copy-paste code in new subprojects
not actually saving much duplication

If I didn't have the Rust compiler to help, I'd be relatively lost.
I found myself just now needing to essentially copy-and-paste a big chunk of functionality, and I was thinking "how much of the base am I using and not overriding?" The way it works right now is as a container, and that's fine - because there is base behaviour in there that I am using, but I'm not sure what it is buying me over a module containing functions that I can import as-and-when-needed, if I'm having to implement new functions in a module and dispatch to them, instead of bolting stuff to the side of the container. The default implementations of query, execute etc I suppose?
What I fear is that base behaviour will change but not many contracts will pick it up, because it's being overriden, at which point you have to ask whether this should be a lego-bricks library of helper functions with some enums (closer to how some of the other cw-plus contracts are implemented, I suppose).
I'm sticking my neck out a little bit here, so feel free to say that I'm just not good with traits and I'm missing something, but... yeah. I feel like this is probably difficult to decide via e.g. discord and we need to have a design discussion around this. Even if it's just "the-frey, you're wrong, but X is an issue, let's talk about that."
Usage of these contracts is already exploding and soon we won't have the luxury to radically change base.
Which also brings into focus discussions like #25 - how we extend, what we consider e.g. base and plus and how we want to make a modular code base that is ergonomic to use while still being safe.
I don't think any of these are easy questions, and I certainly don't want to point fingers - everybody has worked hard to get this library to the place it is today (thanks!) but I see the window for foundational design closing, to some degree.
Maybe this also ties into the wider standards conversation that's happening. We're building the plane on the way down, and that's fine, but a few hours and some discussion now could save us some heartache in the future if we're going to be designing and building modular CW contracts for the next few years around NFTs.
Sorry about the essay and apologies if it's unclear what I'm trying to say. It's been a long day of code and possibly I need to revisit and refine this later.

I guess, to sum it up I'm questioning whether the approach of abstraction around contracts vs more of a pure library approach is a more maintainable pattern.
There's also the hybrid approach, where you build up a library of functions that take a context, say, that might be common things that nearly all hooks take - i.e. contract, depsmut, env for example.
It's not quite DI, but this kind of client/env/context injection is v common in large functional systems to have a singular representation of state (which is kind of what the current pattern does too, as it closes over that within the contract wrapper abstraction)

Hey @the-frey thanks for opening this issue. Jumping on this a while after you posted but the difficulty of extension you pointed out is becoming more apparent and forcing developers to extend cw721 in non backwards compatible ways.
Talis for example updated the TokensResponse struct to be a vector of structs rather than a vector of strings (like in the base implementation) so that they could include more information like the metadata_uri in their implementation (example response).
Now when my discord bot interacts with nft contracts I have to do some validation to see which type of response I am getting back... https://github.com/GraviDAO/lunar-assistant-bot/blob/main/src/utils/terraHelpers.ts#L4
If a change is going to be made it would be better sooner rather than later like @the-frey said.
It would be nice to follow the approach of the Open-closed principle which states that "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification". In the case of TokensResponse this could mean making the base version a vector of structs which just define the token id. This would make it so that Talis could extend from it in a backwards compatible way.

Think #42 goes a long way towards closing this.

I think 42 digs us out of the hole we're currently in with extensions (and is a great piece of work given where we were), but does nothing to address the core issue this was opened to discuss (for my 2cs, anyway). I think there's actually also an overlap here with the authz discussion that was had re: x/wasm that essentially reveals there is:

an over-opinionated pattern in code to extend the contracts
an adequately opinionated pattern as best practice in contracts to expose an API/interface
a completely unopinionated API from x/wasm

These things are where the tension lies, I think.

The more I look at the great work @ethanfrey and the Confio folks are doing on the latest mesh-security contracts with Sylvia, the more I'm starting to think that may be our best path forward. Would be a substantial re-write but could also make extension much easier without having to use traits.
Would mean some breaking changes, so not to be taken on lightly, but could be promising? Additionally, may also be worth exploring leveraging the new Cosmos SDK NFT module for much the same reasons as Token Factory (though this is a separate discussion).


fix(style): decorate titles and nav properly

These design decisions are based on the original styles of Even for
hugo.

So if I remember correctly some of the changes I've made to themes I ported was to not use custom fonts. Since the fonts are not loaded in the HTML, I don't think those changes have much effect do they?

They do have great have effect because, e.g. in the case of the decorating font, the browser will ultimately fall back to serif. In addition, I improved the size of the font and titles of posts are no longer colored in $main-colour.
From my point of view, these changes make the design much more coherent. And it does serve the original design much better. (I use these changes on my personal blog notebook.niklaas.eu if you would like to compare them to the current state.)
In addition, if you'd like to, I am happy to submit another PR that deals with bundling the preferred fonts automatically.

I agree for the serif/sans-serif but eg in font-family: Chancery, cursive, LiSu, sans-serif; it's unlikely that the user will have Chancery and LiSu installed so it's effectively font-family: cursive, sans-serif;. Not a huge deal though.

You're right. I added them to be in line with what the original Even specifies only. Shall we bundle these fonts in this implementation of Even? I could add the necessary changes in this PR (instead of creating a separate PR).

Yep, keep it as lean as possible. I would prefer not having any webfont by default and we could mention in the README how to load them if someone wants to.

OK. Since I plan to include the supplementary fonts for my blog, I'll add instructions for the README in another PR as soon as I can. So this can be left as is? This way, users of this theme can decide on their own if they want to bundle the fonts. I they do, their blog visitors will see the fonts, otherwise their visitors' browsers will fall-back to the default fonts.


Support HDP <IP_ADDRESS> and <IP_ADDRESS>

This adds support for the latest HDP 2.3 patches and HDP 2.4 release. It requires https://github.com/caskdata/hadoop_cookbook/pull/250 to be merged and released before this can be used with the hadoop cookbook.

:+1: lgtm, pending travis


chore: include oras in utils image

I'd like to use it to run oras resolve to get the top-level digest of OCI artifacts that are not images.

In particular, I need to update a bunch of skopeo inspect calls in the release-service-catalog to use this.

The commit mentions oras, but not yq. Can you add some details about why we need this other version of yq?

Yeah, you know - I'll just remove the yq change. I think I got carried away.
Long-term, I'd like us to start producing our own builds of all of those tools and move all consumption to this FROM ... pattern. But, we can consider doing that separately, later, rather than cramming it into this change.

I rebased this to resolve a conflict in the Dockerfile. I think this is ready for approval and merge whenever you're ready.

The tasks after the build are timing out in the ITS. Not sure why

This may have been due to the pipeline service outage today. That resolved just now. Let's see.

/retest

/retest

It worked, but needs rebase now :slightly_smiling_face:

/retest

It worked, but needs rebase now 🙂

I think we both rebased it at the same time and I may have messed things up.. I see two commits now

/retest

It worked, but needs rebase now 🙂

I think we both rebased it at the same time and I may have messed things up.. I see two commits now

I will just squash when I merge


Any hope of custom effects - ie DIV0 and RTFM equivalants?

The author of those custom ZDL effects did quite a write-up here:
https://github.com/ELynx/zoom-fx-modding/blob/main/howto/RTFM.en.md#capabilities-and-how-to-make-fx-chains
and:
https://github.com/ELynx/zoom-fx-modding/blob/main/library/CH_2.md#audio---the-logic-of-fx
I noted that the ZT2 listing that you had showed the 'line select' effect, any chance of downloading and de-compiling??
Group 7 : SFX
0x07000010 : AUTOPAN.ZD2, (v1.10 1)
0x07000020 : LOOPROLL.ZD2, (v1.10 1)
0x07000030 : HOTSPICE.ZD2, (v1.10 1)
0x07000040 : BOMBER.ZD2, (v1.10 1)
0x07000f00 : LINESEL.ZD2, (v1.00 1)   <----------------
0x07000ff0 : BPM_MDL.ZD2, (v1.00 1)

I'm away for the weekend, but you can use the 'decode_effect' to extract the code/ELF section.
$ python3 decode_effect.py -c LINESEL.ZD2.ELF LINESEL.ZD3
I also started pulling out some tables/shared data with 'decode_bdl', this also works on ZD2... for when you want to change the characteristics of the EQs for example.
Get BlueMail for Android
On May 25, 2024, 9:00 AM, at 9:00 AM, Thomas Hammer @.***> wrote:

I downloaded the Texas Instrument CCSTUDIO-THEIA for disassembly, and
the wxMEdit hex editor, followed the excellent instructions from @ELynx
to extract the ELF portion from the LINESEL.ZD2 file, and ran the dis6x
from CCSTUDIO on the ELF file to disassemble it.
I think the parts of the ZD2 file before the ELF data is
chunk/section-based, just like the MS-50G+ patch data. There are some
four-character hex strings followed by what could be chunk length.
There's the familiar TXJ1 for Japanese description and TXE1 for English
description. The ELF-section is inside a Zoom-style DATA chunk. There's
also a chunk called ICON and a chunk called INFO. I guess you know all
this already from your ventures into the ZD2 file format :-).
As for the ELF part - At first look, the disassembled output looks sane
to me. It contains some assembly code at the start and some data at the
end, with section names that suggest they are images.
I don't speak TI6000 assembly, so I don't know what the code does. The
code labels / function names does tell a story, though, with code
blocks for initialization, editing parameters, and more.
Unfortunately, it looks like @ELynx won't be developing his tools and
effects any more. He has set the repository to read only and posted a
closing statement a couple of months ago:
https://github.com/ELynx/zoom-fx-modding/issues/14.
These MS-Plus series of pedals could be a wonderful platform for
implementing custom effects. But it looks like @ELynx' conclusion is
that there isn't much community interest in actually doing so.
--
Reply to this email directly or view it on GitHub:
https://github.com/thammer/zoom-explorer/issues/1#issuecomment-2131302584
You are receiving this because you authored the thread.
Message ID: @.***>

Well, Linux version looks like it needs Python2... which isn't native on Ubuntu any more. :-(

I'll see if Windows version is any easier, if not I'll have to set up a VM (or something) to work in.

Windows version worked OK. Just selected the 'C200' tools and was able to...
C:\Users\simon\Downloads\zoom-zt2-master-20240527\zoom-zt2-master>"c:\Program Files\Python\Python310\python.exe" decode_effect.py -c ZNR.ZD2.elf ZNR.ZD2

C:\Users\simon\Downloads\zoom-zt2-master-20240527\zoom-zt2-master>c:\ti\ccstheia140\ccs\tools\compiler\ti-cgt-c6000_8.3.12\bin\dis6x.exe ZNR.ZD2.elf | vim -

--
Disassembly of ZNR.ZD2.elf:

TEXT Section .text (Little Endian), 0x18a0 bytes at 0x00000000
00000000            Fx_DYN_ZNR:
00000000   09902266           LDW.D1T2      *+A4[1],B19
00000004       4727           MVK.L2        2,B6
00000006       1192           MVK.S1        16,A3
00000008   071803a2           MVC.S2        B6,RILC

Not that this makes any/much sense to me. :-(

So the most obvious difference between what was written (re ZDL) and the disassembled ZD2 is that there is no contents under the '.audio' segment. All code seems to be in the '.text'.
Just looking at the labels that are given, grep Fx_ ...
00000000            Fx_DYN_ZNR:
00001300            Fx_DYN_ZNR_thr_edit:
00001360            Fx_DYN_ZNR_onf:
000013c8            Fx_DYN_ZNR_depth_edit:
00001404            Fx_DYN_ZNR_EnvIn_edit:
00001428            Fx_DYN_ZNR_decay_edit:
00001474            Fx_DYN_ZNR_Level_edit:
000014b4            Fx_DYN_ZNR_init:
00001512       e01b           CALLP.S2      Fx_DYN_ZNR_thr_edit (PC-512 = 0x00001300),B3
00001518       ec9b           CALLP.S2      Fx_DYN_ZNR_depth_edit (PC-312 = 0x000013c8),B3
00001522       ee5b           CALLP.S2      Fx_DYN_ZNR_EnvIn_edit (PC-284 = 0x00001404),B3
00001528       f09b           CALLP.S2      Fx_DYN_ZNR_decay_edit (PC-248 = 0x00001428),B3
0000152e       f55b           CALLP.S2      Fx_DYN_ZNR_Level_edit (PC-172 = 0x00001474),B3
800002dc            _Fx_DYN_ZNR_Coe:

Does it make sense that Fx_DYN_ZNR_init is called at load time, which then goes on to call each of the _edit functions, and that Fx_DYN_ZNR is the audio processing function, called for every chunk of audio data?
_Fx_DYN_ZNR_Coe is a shared data object, is this the table of coefficients that was mentioned?


Allow teachers to request a leave

[ ] Teachers should be able to request leave and submit their request for approval.

Non prioritaire


Is this repo dead?

Is this repository still maintained? As last issue responses and commits are from months ago. Any status update?

Firebase Queue is not deserted and we actually use it in production here at Firebase. We just haven't had any features or bugs lately that we though warranted new code. Also, the primary author (@drtriumph) has been heads down working on some other projects. Apologies for not getting answers to open issues lately. I'll see if we can get some movement on the open issues in the coming days.


Adds dotted line glyph and font patching tutorial

Closes #86.

@otalpster this is no particular font, it is just an eps of a glyph (of my own creation) that you can inject into your terminal font.


QUESTION: Can I run it locally on my laptop instead of using your server?

Yes, you can :)

https://github.com/MarcoEidinger/SwiftPlantUML?tab=readme-ov-file#large-diagrams


Rename sourceName parameter to objectName in DownloadObject

For what is worth in the API it is referred to as bucket and name, together forming what I guess is the full name of the object.

As Chris pointed out, the "get" request on Object actually uses "object" as the parameter name:
https://cloud.google.com/storage/docs/json_api/v1/objects/get
The idea is that objectName is a good bridge between the two :) If it had just been called name there, I'd have used name too.
(Admittedly we're not directly using that API, we're using the media API, but it's conceptually like that...)

Ah, I was looking at https://cloud.google.com/storage/docs/json_api/v1/objects/insert, which indeed uses name instead. I guess that API is not even consistent with itself. Sight... Ok, then I think it makes sense to call it objectName, my objection is retracted. Ship it, :shipit: :+1:

You folks are the first to point out that oddity. The URL path is shared among other resources, e.g., storage.objectsAccessControls.get, and for homogeneity there, we use object as the parameter. Within the metadata of the object itself, calling the name objectName seemed redundant. Then last, the case where you're trying to upload a raw file but because the URL for the operation is a POST to the collection and thus doesn't have the object name, we chose the metadata name rather than the collection instance name.


multi-day, hierarchical DO simulation

this PR (0.9.27) used for metab_tests commit https://github.com/aappling-usgs/metab_tests/commit/04527d227cf66224921c84e1b4ebadb2262a6794 on 12/24/2016

merging despite test failures because (1) most tests pass and (2) i want to tag this version b/c i ran experiments with it


Support cuTENSOR 1.6.2 which defaults to CUDA 12

cuTENSOR's deb/rpm packages now setup libraries for CUDA 12 by default.
So it is needed to switch to the appropriate binary depending on the current CUDA version.
This was discovered during review of #7235 (https://ci.preferred.jp/cupy.linux.cuda-example/118609/).
00:25:57.151677 STDOUT 1621]	+ python3 cutensor/contraction.py	1.7s
00:25:58.826849 STDOUT 1621]	Traceback (most recent call last):
00:25:58.826859 STDOUT 1621]	  File "cutensor/contraction.py", line 6, in <module>
00:25:58.826866 STDOUT 1621]	    from cupyx import cutensor
00:25:58.826990 STDOUT 1621]	  File "cupyx/cutensor.pyx", line 1, in init cupyx.cutensor
00:25:58.827087 STDOUT 1621]	ImportError: libcublasLt.so.12: cannot open shared object file: No such file or directory

btw we are preparing cutensor-cu11 and cutensor-cu12 1.6.2 wheels. Hoping to get it done by this week.

/test mini

Test failure should be unrelated to this PR, raised #7240 for further investigation.

Hoping to get it done by this week.

Done.


Hypergeometric distribution log survival function

Changed the hypergeometric distribution log survival function so that you integrate using the logpmf instead of just taking the log of the sf
This commit fixes #4982

Could you also add a test please.
Your original example from gh-4892 would do (+ a comment that the number is checked against such-and-such R command).
This should probably go to TestHypergeom class, https://github.com/scipy/scipy/blob/master/scipy/stats/tests/test_distributions.py#L369, which has very similar tests.

Ok added

Squashed and merged in https://github.com/scipy/scipy/commit/53ded2766b2143cc4035c2943dd112ea5cb5ba75. Thank you @joshlk, keep them coming!


Add API key authentication to Swagger UI

Added authentication support to Swagger UI configuration.
Thank you for considering this addition.

@lahuman
I will change base branch from main to dev as it is our policy.
When your PR is merged to dev, we will test it in our internal environment and if there is no problem, it would be merged to main branch and released.


Video is stretched when the resolution is 10801920 instead of 19201080

I want to render manim videos so that they are 1080px wide and 1920px high.
By default, when I run the following command:
python -m manim manimation.py myScene -pm -r 1080

It creates a video with resolution 1920*1080.
When I run the following command:
python -m manim manimation.py myScene -pm -r 1920,1080

It creates a video with resolution 1080*1920. However, the text and everything else in the video is stretched. How can I keep the video contents normal while just changing the aspect ratio of the video?
Thanks.

Could you send the code for the scene you're trying to render so we can try to reproduce this issue?

Hi @kilacoda :)
This is the code I am running:
class WriteStuff(Scene):

    CONFIG={
        "camera_config":{"background_color": '#f90', "pixel_width": '1080', "pixel_height": '1920'}
    }

    def construct(self):
        example_text = TextMobject(
            "This is a some % text",
            tex_to_color_map={"text": YELLOW}
        )
        example_tex = TexMobject(
            "\\sum_{k=1}^\\infty % {1 \\over k^2} = {\\pi^2 \\over 6}",
        )
        group = VGroup(example_text, example_tex)
        group.arrange(DOWN)
        group.set_width(FRAME_WIDTH - 2 * LARGE_BUFF)

        self.play(Write(example_text))
        self.play(Write(example_tex))
        self.wait()

Thanks. :)

Hi,
Your code uses some conventions that no longer work in ManimCE, such as CONFIG and the FRAME_WIDTH constant. I've rewritten your code so it's compatible with the latest version of ManimCE:
from manim import *

config["tex_template"] = TexTemplateLibrary.simple ## There's an issue with some TeX glyphs for which this is a workaround

class WriteStuff(Scene):

    # CONFIG = {
    #     "camera_config": {
    #         "background_color": "#f90",
    #         "pixel_width": "1080",
    #         "pixel_height": "1920",
    #     }
    # }

    def setup(self):
        self.camera.background_color = "#ff9900"
        config["pixel_height"] = 1920
        config["pixel_width"] = 1080

    def construct(self):
        example_text = TextMobject(
            "This is a some % text", tex_to_color_map={"text": YELLOW}
        )
        example_tex = TexMobject(
            "\\sum_{k=1}^\\infty % {1 \\over k^2} = {\\pi^2 \\over 6}",
        )
        group = VGroup(example_text, example_tex)
        group.arrange(DOWN)
        group.set_width(config["frame_width"] - 2 * LARGE_BUFF)

        self.play(Write(example_text))
        self.play(Write(example_tex))
        self.wait()

Here's the output:
https://user-images.githubusercontent.com/65204531/106573767-0e882000-6560-11eb-8a6d-de8a53276438.mp4
Is this what you were expecting/getting? To me, there doesn't seem to be any issues here.

Thanks @kilacoda :)
I got it to work now. There was incompatibility between different versions.


Use exponential backoff for pollController

introduce github.com/cenkalti/backoff
replace time.Ticker with  backoff.Ticker

Signed-off-by: lastchiliarch<EMAIL_ADDRESS>
Which problem is this PR solving?

Use exponential backoff for pollController, see #392

Short description of the changes

introduce github.com/cenkalti/backoff
replace time.Ticker with  backoff.Ticker

I would very strongly prefer to do this without an additional dependency. The fact that OTEL collector uses this library is not a good argument, because collector is a backend component, but this SDK runs in user code.
I believe the ticket already has a 20-line approximate solution.

I have two higher level questions:

why do we need exponential backoff? The current PR sets max interval to 5min, and default polling is 1min, so there isn't that much difference, why not just continue polling at 1min?
why do we need jitter at every iteration? I can think of two simpler options: one-time random delay or a one-time random mutation of the polling interval (e.g. +- 10%)

I have two higher level questions:

why do we need exponential backoff? The current PR sets max interval to 5min, and default polling is 1min, so there isn't that much difference, why not just continue polling at 1min?
why do we need jitter at every iteration? I can think of two simpler options: one-time random delay or a one-time random mutation of the polling interval (e.g. +- 10%)

Agree the first point,  exponential backoff it's no a good idea when the interval is too bigger like 1min.
Maybe the simplest way to avoid a larer number of refreshing at the same time is to add a random value when create the time.NewTicker(),  if we don't really need the exponential backoff.

Closing this. This can be achieved much simpler with a one-time jitter offset.


'{"errors":[{"message":"Sorry, that page does not exist","code":34}]}'

Anyone getting this trying to use scrapper.getTweets ?

The scheduled CI task last ran 3 days ago and passed successfully, so this is either a new issue or it's something that the tests aren't catching. Can you share a brief repro with the failing parameters?

(async ()=> {
    const { Scraper } = await import("@the-convocation/twitter-scraper");
    const scraper = new Scraper();
    const tweets = scraper.getTweets("uecaiu", 10, false);
    for await (const tweet of tweets) {
      console.log(tweet);
      }
})()

can you try run the CI again ?
in my fork it fails
https://github.com/isrmicha/twitter-scraper/actions/runs/5425921982/jobs/9867323086

I'm not able test at the current moment, but theoretically using login() in TwitterUserAuth should fix this?

Upon inspection, it seems necessary for all functions to require auth similar to search, at least temporarily.

This would also be fixed once https://github.com/n0madic/twitter-scraper/commit/fb8ae789bd973266ca2b36b624b3f67124758ce8 is ported over, whichever comes first.

I think this latest problem with adaptive.json no longer in use needs the fix here that implements the GraphQL endpoint for searches: https://github.com/n0madic/twitter-scraper/issues/116

This is fixed as of v0.3.0.


Add to/Remove from a NodeBB when user enter/leave a specific level

It would be great if users could be added to a NodeBB group (and vice versa) after reaching a certain level. This would allow members with higher prestige to gain higher privileges through the group permissions system.

You should be able to do this with the core rewards system, see screenshot below.


Docs for how to start a sandbox node and run e2e test on it

Do not merge until https://github.com/near/nearcore/pull/4287 and https://github.com/near/near-api-js/pull/603 is merged. Add a doc on how to start a sandbox node and how to run e2e test on it. It's going to supersede end-to-end test sections once our tooling is fully ready that support  run test on both sandbox and testnet with one cli command.
TODO:

[x] add a subsection of how to use sandbox-only feature (right now there's only one feature: patch_state)

cc @DiscRiskandBisque (am I correct that you do want to be cc'ed for such design/UX aspects of this work?)

cc @DiscRiskandBisque (am I correct that you do want to be cc'ed for such design/UX aspects of this work?)

Yes and thank you! Apologies for the delay, I need to set up better GitHub notifications.

Finally got to reviewing this, sorry that it took me so long.
This looks good to me overall.
However, I am not sure what are concrete next steps here. The current state is very a proof-of-concept. It works, but the UX is pretty horrible in itself, and we don't give any explicit guidance for contract authors about the interactions between this new style of testing, and existing simulatior/unit-test.
As such, I don't think we should be publishing this as a user-visible documentation, as it seems that that'll just create confusion over currently supported testing approaches.
It seems like this is the point where the work should be taken over by someone from the devx team, but I don't know who that would be, cc @mikedotexe.

@matklad 's point makes sense too. My opinion is present both manual, low level way and a high level, automatic way to the user, with advanced user might be interested to learn when high level way doesn't work, e.g. when the automatic way has a bug or a special case that automatic way doesn't cover. Right now we don't have truffle equivalent so this doc only has the low level way. Once we have, then the high level way should be add to the first part as of this document so user can see the short way first.
The other PR that documents repro testnet transaction with sandbox have applied this approach: https://github.com/near/docs/pull/724/files. First sections give the instructions on how to use a automatic script to fetch state for reproduce. The later section describes which parts of blockchain information will affect the transaction result and may help curious user to understand the low level and troubleshoot if it there's still difference in transaction repro.

Seems latest master d894e828737ff06d74a7dcf3403a0d2019de31c8 broke CI / test-links, let me see if i can make a fix to master

This one is now blocked by near/near-sdk-rs#433

@thisisjoshford would need your or Mike's approval on near-examples/rust-status-message#64, thanks


fix deprecation warning

With matplotlib 3.8.3 I get an error trying to run the example from the README
Traceback (most recent call last):
  File "/Users/g/git/tmp/july-patch/july-example.py", line 9, in <module>
  File "/Users/g/git/tmp/july-patch/july/src/july/plot.py", line 72, in heatmap
  File "/Users/g/git/tmp/july-patch/july/src/july/rcmod.py", line 54, in update_rcparams
    warnings.simplefilter("ignore", mpl.cbook.MatplotlibDeprecationWarning)
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'matplotlib.cbook' has no attribute 'MatplotlibDeprecationWarning'. Did you m
ean: 'VisibleDeprecationWarning'?

This fixes that problem.
Not sure if you depend on a specific older version of matplotlib but couldn't find that in the docs and cloning the repo and installing directly seems to pull in 3.8.3 (currently latest)

@e-hulten Is it possible to get a new release with this fix included? Thanks a lot and with best regards, Joshy


Ionic 1 does not run CLI commands such as ionic info or ionic build ios

Short description of the problem:
Not sure if me updating to Node 6 is causing all this.. but I am working on an Ionic 1 app with a remote team and lately our versions have not liked each other. I was wondering if the fact that I have also been working on Ionic 2 projects for whatever reason my CLI "thinks" these apps are also Ionic 2 and there for is shooting me the error below? (i know it makes no sense but I have no clue)
What behavior are you expecting?
I want to be able to run ionic commands like ionic info , ionic build ios etc.. and not get this error.. or message..
issue in detail
insert any relevant code between the above and below backticks

mymac ~/code/92_AAC/newApp on master[!]
$ ionic build ios
WARN: ionic.project has been renamed to ionic.config.json, please rename it.
Uh oh! Looks like you're missing a module in your gulpfile:
Cannot find module 'gulp'

Do you need to run `npm install`?

Other information: (e.g. stacktraces, related issues, suggestions how to fix, stackoverflow links, forum links, etc)
Which Ionic Version? 1.x or 2.x
Plunker that shows an example of your issue
For Ionic 1 issues - http://plnkr.co/edit/Xo1QyAUx35ny1Xf9ODHx?p=preview
For Ionic 2 issues - http://plnkr.co/edit/L8JN6w5mqwbMY2E14dbk?p=preview
Run ionic info from terminal/cmd prompt: (paste output below)

Hey! Thanks for opening an issue with us! Most likely, this is related to node 6, as those commands should work, and do work for me (im on node 5.10.1). Would you mind downgrading to node 5 and testing? Also, since this issue is an issue related to the cli and not the framework im going to move this issue over to the ionic-cli repo. Ill continue the conversation with you over there. Thanks!

This issue was moved to driftyco/ionic-cli#987


Add ColoLocation to ExpressRoutePort result

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[x] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following appy to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

/azp run

@jianqizhao1992, please fix the tool check error.  Thanks

I ran "autorest readme.md --powershell" locally,
I think the current failure in check "SDK azure-powershell" is because the following error:
error   | circular reference | Note: during processing of 'PublicIPAddress' a circular reference has been discovered.
Which has nothing to do with my PR.
This is the first time I'm working in this repo, can you help confirm? @lirenhe

I ran "autorest readme.md --powershell" locally, I think the current failure in check "SDK azure-powershell" is because the following error:
error | circular reference | Note: during processing of 'PublicIPAddress' a circular reference has been discovered.
Which has nothing to do with my PR. This is the first time I'm working in this repo, can you help confirm? @lirenhe

Not a blocker.  Approved.


Improve release notes for ESP32 support

This PR tries to include the subminor number of ESP-IDF supported versions because it is sensitive to build firmware for the ESP32 family. Also, v5.2 (v5.2.1) is covered at this time, so this has been added.
Moreover, I added link to target idf-version on esp32-build.yaml. As future development progresses, the information in this table may diverge from the CI build target numbers, but I expect that users can follow this link to the latest status.
This will close #1168

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).
SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

I deeply understand your concern, keeping documents fresh is always tough work ;(
So I removed the subminor numbers (rebase my changes) in the table and modified the guidance so that users can refer to the current target versions in esp32-build.yaml. I expect that there is no need to update the table and users can catch up on the proper information.


nc_inq_dimlen reports incorrect length of unlimited dimension after variable data modified

See https://github.com/Unidata/netcdf4-python/issues/1166 which includes a simple test program reproduced here
#include <netcdf.h>
#include <stdio.h>
int main() {
    int i, iret, dimidx, dimidt, varid, ncid;
    int dimids[2];
    size_t start[2], count[2], dimlen;
    int data[10];
    iret = nc_create("test_issue1166.nc", NC_NETCDF4, &ncid);
    iret = nc_def_dim(ncid, "x", 10, &dimidx);
    iret = nc_def_dim(ncid, "t", NC_UNLIMITED, &dimidt);
    dimids[0] = dimidt;
    dimids[1] = dimidx;
    iret = nc_def_var(ncid, "v", NC_INT, 2, dimids, &varid);
    start[0]=0;
    start[1]=0;
    count[0]=1;
    count[1]=10;
    for (i = 0; i < 10; i++)
        data[i] = 1;
    iret = nc_put_vara_int(ncid, varid, start, count, data);
    start[0]=1;
    start[1]=0;
    count[0]=1;
    count[1]=10;
    for (i = 0; i < 10; i++)
        data[i] = 2;
    iret = nc_put_vara_int(ncid, varid, start, count, data);
    iret = nc_close(ncid);
    iret = nc_open("test_issue1166.nc", NC_WRITE | NC_NOCLOBBER, &ncid);
    iret = nc_inq_varid(ncid, "v", &varid);
    iret = nc_inq_dimid(ncid, "t", &dimidt);
    start[0]=0;
    start[1]=0;
    count[0]=1;
    count[1]=10;
    for (i = 0; i < 10; i++)
        data[i] = 0;
    iret = nc_put_vara_int(ncid, varid, start, count, data);
    iret = nc_inq_dimlen(ncid, dimidt, &dimlen);
    printf("dim length after write=%lu\n", dimlen);
    iret = nc_close(ncid);
}

with netcdf-c 4.8.1 the dimension length printed is 1, but with netcdf-c 4.7.4 the correct value of 2 is reported.  Note that if the last nc_put_vara is commented out (the variable data is not modified), the correct value of 2 is printed.

OK, I have found the problem here, and there are two.
Firstly, in hdf5var.c we have:
                if (!zero_count && endindex >= dim->len)
                {
                    dim->len = endindex + 1;
                    dim->extended = NC_TRUE;
                }

This is incorrect because dim->len is always 0 for unlimited dimensions. Not until nc4_find_dim_len() is called can we know the length of an unlimited dimension. So instead of dim->len we need to use fdims[d2] which is the actual length of the variable's extent in the unlimited dimension.
Secondly we have this in hdf5internal.c:
#ifndef USE_PARALLEL
/* Shortcut for non-parallel operation: if the dim->len is
* non-zero, it will be set to the correct size. */
if (dim->len)
*lenp = dim->len;
#endif
This shortcut only works in simple cases. In more complex cases it will be wrong. For example, in the test code in this issue, the problem is we re-open the file, and write along the unlimited dimension, but we re-write the very first element, rather than adding to the end of the array. If we added to the end, this works, but when we re-write an existing element which is not the last element, then this will be wrong. There are also other cases in which this is wrong, for example if we write one var to 10 along the unlimited dim, then write a different var to 2 along the unlimited dimension, the dim->len will equal 2 not 10.
In fact, I don't think we can take this shortcut at all. We simply always have to check the actual extent of each var along the unlimited dimension, in order to find the max value.
I have a PR to put up shortly. @WardF this probably should go in the 4.9.0 release.
Thanks very much to @jswhit for finding this, reporting it, and providing test code! As so many times in the past, your efforts benefit the entire netCDF scientific community!


how to create a big amount of accounts?

for this bot to work we need a big amount of accounts, do you guys have ways to auto create them?

sadly nope, just make yourself one using this with an extension called "Buster: Captcha Solver for Humans" for solving captchas

wow! thank you very much i didnt know that!

uuummm when i finnaly able to run the program it says that the accounts from that web are getting banned from r/place... do you have any alternatives?


Possible issues with SelectedSelectionKeySet in non-linux operating systems

SelectedSelectionKeySet doesn't implement contains() method. Or at least it returns always false. This may create issues in non-linux operating systems.
To give you more context, in my work, like you do, we try to not produce garbage by replacing HashSet with something similar to SelectedSelectionKeySet. Actually this trick is something we learned from netty.
So while investigating a recent bug, I realized lack of correct implementation of contains() method creates problems in macos (and very possibly windows as well). I tried to summarize my finding in here: https://github.com/hazelcast/hazelcast/pull/24267
I do think this issue effects netty as well.

Good find, we'll take a look.


Fix nullptr_t to std::nullptr_t and add missing include to enable compilation with clang

BTW you can easily test using godbolt:
https://godbolt.org/z/G95Pj6nxe

Thanks a lot!


Pass extraFlags to prometheus systemd exporter

Motivation for this change
Pass the missing extraFlags parameter that all prometheus exporters have to the systemd exporter. Specifically, it can take the following extra flags at the current stable version of the exporter:  https://github.com/povilasv/systemd_exporter/tree/v0.4.0#systemd-versions
Things done
Haven't tested, but the change is simple (copied from the node exporter's config).
PS: Sorry for the noise in the old PR. I created the change through GitHub and then changed the base branch, which did very unexpected things.

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.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.

I tested it like this:
let
  nixpkgsSrc = fetchTarball {
    url = "https://github.com/ratorx/nixpkgs/archive/patch-2.tar.gz";
    sha256 = "0xvh0jk7adha0zj9zaq7mjxwzwlp9avwpqqdxr3yszlg1i4nwp7i";
  };

  module = "services/monitoring/prometheus/exporters.nix";
in
{
  disabledModules = [ module ];
  imports = [ "${nixpkgsSrc}/nixos/modules/${module}" ];

  services.prometheus = {
    exporters = {
      systemd = {
        enable = true;
        listenAddress = "<IP_ADDRESS>";
        extraFlags = [ "--collector.enable-restart-count" "--collector.enable-ip-accounting" ];
      };
    };
  };
}

Works for me, I see restart count and ip metrics on the prometheus endpoint.
Thanks a lot, can we get this in any maybe even backported to 21.11?

Already done by 4bfe837a586c8ecc1bc577207faf15c152dd1e22.


VM password problem with Access helpers

Description

During the VM creation password save selected but when access VM is clicked, the password is "Not Set".
Steps to reproduce

Create VM, when created click to save the password.
In the final dialog click "Access VM", it shows that the password is not set.
In tags, the password is set. When "Access VM" dialog is selected from the context menu, it shows that the password exists.
Actual result

No password exist when Access helper is called at the end of VM creation.
Expected result

If the password is saved, then it must be accessible.
Environment
Template: VestaCP Nginx+PHP-FPM
Browser: Chrome / Linux
Test Acct: cloud2test15569

Browser:
- [x] Chrome version 69.0.3497.100
- [ ] Firefox version XX
- [ ] Safari version XX
- [ ] Opera version XX
- [ ] IE version XX
- [ ] Edge version XX

Others:

Connected requirement IDs
REQ_VM_CREATE_021, REQ_VM_CREATE_028, REQ_VM_LIST_017
Screenshots

@ershovaelena @Nadya913 important

TO TEST:
REQ_VM_CREATE_021,
REQ_VM_CREATE_028,
REQ_VM_LIST_017


Buttons for Dank memer

I was wondering if the farm works with the buttons on Dank Memer?

For now? no,
But Maybe we can achieve this in the future.


Adelaide Crows team being read in as Port Adelaide for season stats

Thanks for this code, it's really useful for my project. However, when I attempt to read in Adelaide Crows season stats using this command
ADE.season_stats(2022)
I get stats for Port Adelaide players. Is this a known issue and is there a way to fix this?
Thank you

Hi @cheese-egg, yes it's a known issue - someone else started writing a fix, but didn't merge it into the master branch.
But this is a good reminder for me to have another look. I'll see if I can quickly fix it now.

Indeed I was able to quickly fix it :)
I've merged the fix into the master branch of this repo, and I've released a new version to PIP (v0.4.2).
Please let me know if you have any further issues.
Closing this issue now. Thanks

Thank you so much for the quick fix Ram.
I will check it later and let you know if there are any issues, but I'm
sure it will be fine.
Cheers
Dennis
On Wed, 17 Jan 2024 at 04:56, Ram Parameswaran @.***>
wrote:

Closed #23 https://github.com/RamParameswaran/pyAFL/issues/23 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/RamParameswaran/pyAFL/issues/23#event-11502434533,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFL4LJFUUCKNNCWL2YWTJ2TYO3A4TAVCNFSM6AAAAABB4HNIUOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGUYDENBTGQ2TGMY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi Ram
I'm not sure if I've missed something here but I can't seem to pip install
the latest version you just created. I only seem to be able to get version
0.3.1. Do you have any idea why this might be?
[image: image.png]
Thanks again for your help!
Dennis
On Wed, 17 Jan 2024 at 10:34, Dennis Horton @.***> wrote:

Thank you so much for the quick fix Ram.
I will check it later and let you know if there are any issues, but I'm
sure it will be fine.
Cheers
Dennis
On Wed, 17 Jan 2024 at 04:56, Ram Parameswaran @.***>
wrote:

Closed #23 https://github.com/RamParameswaran/pyAFL/issues/23 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/RamParameswaran/pyAFL/issues/23#event-11502434533,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFL4LJFUUCKNNCWL2YWTJ2TYO3A4TAVCNFSM6AAAAABB4HNIUOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGUYDENBTGQ2TGMY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hey Dennis. Hmm have you tried specifying the version number? See this link https://towardsdatascience.com/pip-install-specific-version-how-to-install-a-specific-python-package-version-with-pip-1f97e1002f31
If that doesn't work, it should at least give an error message why it failed. Let me know how it goes.

Hi Ram
Thanks so much for your help in the past with your pyAFL package, it's
really a great package.
I was wondering if you will be updating it to include the games from 2024?
At the moment it seems to be the end of 2023.
[image: image.png]
Thanks again for your help!
Dennis
On Thu, 18 Jan 2024 at 09:11, Ram Parameswaran @.***>
wrote:

Hey Dennis. Hmm have you tried specifying the version number? See this
link
https://towardsdatascience.com/pip-install-specific-version-how-to-install-a-specific-python-package-version-with-pip-1f97e1002f31
If that doesn't work, it should at least give an error message why it
failed. Let me know how it goes.
—
Reply to this email directly, view it on GitHub
https://github.com/RamParameswaran/pyAFL/issues/23#issuecomment-1897218126,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFL4LJEJRHZ7YVYONADF5A3YPBHRBAVCNFSM6AAAAABB4HNIUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXGIYTQMJSGY
.
You are receiving this because you were mentioned.Message ID:
@.***>


pixi: 0.13.0 -> 0.14.0

Release note:
https://github.com/prefix-dev/pixi/releases/tag/v0.14.0
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[x] sandbox = true

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 289845 run on aarch64-darwin 1

1 package built:

pixi

CI is failing on aarch64-linux and x86_64-darwin...


[Suggestion] Use hosted.weblate.org as translation system

You can add your project for free to weblate https://hosted.weblate.org/ and get translations and verification of translations in many languages from contributors all over the world. Making fixes and/or adding new languages is automated by weblate. Please consider doing it :)

We use Launchpad right now because it has a community of translators (especially from Ubuntu).
Is there a change to get translations for languages we don't have yet ?
I guess we could do a double sync if that is the case.

translations.launchpad.net/openfoodfacts

I have very good experience with weblate, a few times happened that people came to my projects and just translated it into some languages. I didn't have to create a file for language or anything, they just opened the project and added missing language for them, did translations and left.
weblate is generic for opensource projects, not related to any community or project.

I've started a migration to Crowdin

The README.md still mentions Launchpad, I reckon that is obsolete now (maybe also a2po?).


maxinmempool ambiguous

The description of  maxinmempool  in --help and in the example.conf is ambiguous because it is not clear if it is tracking just your tickets in the mempool or anyones tickets in the mempool. I actually thought it meant all tickets, but after reviewing the debug logs, it appears its only your own tickets.
Related to this is the  dontwaitfortickets  option which says "Don't wait until your last round of tickets have entered the blockchain to attempt to purchase more" but its not clear what a round is. What if only half of your tickets get mined? Will it send more tickets or wait till all of your tickets get mined?

sorry for the delay on responding to issues here... been busy with getting dcr* release out.  we will be responding to and cleaning up these for next release.
but yes, maxinmempool refers to how many tickets you currently have waiting to be mined.  So this will limit the ticketbuyer from just piling up tickets which may never get mined.

we'll add text to make sure that his is clarified


Update argument text message

Update argument text message. Fixes GitHub Issue - 24172
Please make sure the code is following contribution guidelines in CONTRIBUTING.md

[x] : This PR has a corresponding issue open in the Repository.
[ ] : Approach is signed off on the issue.

Hi @SaurabhSharma-MSFT, we have encountered the pipeline run failure due to below file change. could you please check the below file.
azure-devops/azext_devops/dev/repos/arguments.py


[QUESTION] How is Falcon, Japronto, and Vibora so much faster than FastAPI?

I know that FastAPI uses uvloop like other frameworks, but others are considerably faster:
https://github.com/the-benchmarker/web-frameworks#requests-per-seconds
Even Falcon, which is currently only WSGI and not ASGI

I'm no pro of the benchmark internals and just briefly looked at the benchmarks provided by the-benchmarker but it seems it tests only for a PlainTextResponse.
Should you look at benchmarks advertised by @tiangolo in the docs, FastAPI is definitely faster than Falcon you mentioned for the majority of scenarios, however if you look at the plaintext section of techempower tests, then you'll find more or less a similar ranking than the one you linked.

Exactly what @euri10 says. The benchmarks you are citing are not very realistic, only plain responses. You could write a C program that only returns a single plaintext response all the time, not doing any serialization, any DB communication, etc. And it would beat them all. But it's not realistic.
Even the tests from TechEmpower are not necessarily the best way to compare things, as they don't take into account several things about data validation, serialization, etc.
To compare these features that FastAPI adds on top, for data validation, annotation, serialization, documentation, etc. You would probably want to compare some of those frameworks with extensions for handling those things.

Also, have in mind that some of those frameworks are marked as not for production use, more as a proof of concept.

For more details, check here: https://fastapi.tiangolo.com/benchmarks/

I guess that answers the question, so I'll close this issue now, but feel free to add more comments or create new issues.


ConfigurationResolverService should support cancelationTokens

Hello there 👋
In the Python extension for VS Code we are implementing an attach-to-local process debugging scenario using a QuickPick item (https://github.com/microsoft/vscode-python/issues/8701), however clicking the stop button before selecting a process doesn't dismiss the picker (despite ignoreFocusOut being at its default false value):

The session is being dismissed after the resolveDebugConfiguration call but before the createDebugAdapterDescriptor one, so the debugService.onDidStartDebugSession and debugService.onDidTerminateDebugSession events are not being fired.
Is there an event the extension can listen to or API it could register to in order to dismiss the picker when debugging is cancelled early?
Thank you 😊
Note: The picker is dismissed correctly when pressing the escape key or clicking anywhere else in the editor.

Is your QuickPick triggered from the resolveDebugConfiguration hook or is it triggered as part of a (command) variable substitution?

Yup, the QuickPick is triggered as part of the command variable substitution.

@isidorn is there a way to cancel the Quickpick (or any other UI command) either

automatically (behind the scenes) or
manually, by passing a CancellationToken into the UI command?

Extensions can also close the quick picks which they created, so in this particular case Python can not hide the quick pick.
Idealy the configurationResovlerService would introduce support for cancelationTokens.
And the debugService would simply pass an already existing cancelationToken.
I am open and can review a PR which fixes this.
Code pointer for configuration resovler service https://github.com/microsoft/vscode/blob/3ddf7a874a11993e2fb74f9f35dd7dae2d8984c8/src/vs/workbench/services/configurationResolver/browser/configurationResolverService.ts#L26
Code pointer for debug service calling into configuratoin resovler service
https://github.com/microsoft/vscode/blob/3ddf7a874a11993e2fb74f9f35dd7dae2d8984c8/src/vs/workbench/contrib/debug/browser/debugService.ts#L671

I do not think this will happen in June, pushing out to On-Deck.
If there are enthusiasts feel free to assign back.

After investigating this, I found that it does not help if the ConfigurationResolverService propagates a CancellationToken. The reason is that commands implemented in an extension have no access to a CancellationToken and are not cancellable.
As an alternative I've tried @isidorn's suggestion to hide the QuickPick myself. This doesn't work either because the extension API doesn't provide an event for "Debugging stopped" and the vscode.debug.onDidTerminateDebugSession does not help because there is no debug session yet...
@isidorn any other ideas how to tackle this?

@weinand thanks for trying it out. Yes, I see the issue that the commands in general are not cancelable and there is no way for vscode to tell the extension "Stop executing the command".
I also see the other issue, that we are in a state where the debug session is not yet fully started and stopping it does not send out an event.
To take another approach: I suggest we solve this by solving this https://github.com/microsoft/vscode/issues/84228
Thus we would not show the debug toolbar, and the user would not be able to do this so prominently.
If you like that approach let me know and I can assign that issue to August so I investigate more.

@isidorn great suggestion,
I like that and will close this issue as a duplicate.
/duplicate #84228

Great, let ma assign #84228 to August then..

@kimadeline your issue has been fixed now: stopping the debug session will dismiss QuickPicks.

Thank you for the fix and heads up!


Update the code to be compatible with different versions of pyparsing

Closes #85

Codecov Report

Merging #87 (aabcd16) into master (e0cfef6) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #87   +/-   ##
=======================================
  Coverage   94.27%   94.27%
=======================================
  Files          74       74
  Lines        8521     8521
=======================================
  Hits         8033     8033
  Misses        488      488

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 e0cfef6...aabcd16. Read the comment docs.

@alvalentini maybe we can follow @onjen suggestion and make a conditional import instead of forcing pyparsing >= 3.0.0.
I also saw that old names are still supported but they will be eventually removed, so importing the old names is not a great idea.
Something like:
import pyparsing
if pyparsing.__version__ < '3.0.0':
    from pyparsing import OneOf as one_of
else:
  from pyparsing import one_of

@alvalentini Did you manage to test with pyparsing < 3.0.0? Once done, you can go ahead and merge

@mikand I tested it and it works.