CompileProcess not exposed?

Using TM1Services.processes.create(Process) I can create a syntactic incorrect process on my TM1 server. I wanted to use CompileProcess, but the method does not seem to be mapped, right?

Thanks for the catch!
CompileProcess was introduced in 10.2.2 FP7 I believe. We haven't included it into the library yet.
It will come with the next release.

Fixed with the latest commit.
We release a new version to PYPI in a few days.


Determine and add license

As an architect, I need to know the license we are putting on our new code in order to start working on open source repositories.
We need to set the license file on each repository appropriately.

@GlennPruitt did we agree to use MIT as the license for our repos? Or shall we revisit this topic?

Mike C is going to work with the Assure Alliance with determining the correct licensing.  Right now it is SIL International and MIT


Should the federation API mandate that PDUs are sent on the wire in canonical JSON form?

Doing so means that the receiver doesn't need to re-canonicalise the JSON before checking its signature.  However, it then means that receivers would need to handle the PDU as both string-representation and JSON. @richvdh: what were your other reasons for not mandating that some APIs use canonical JSON form?

mostly that it means that you can include whitespace in your json responses for readabilty.

However, it then means that receivers would need to handle the PDU as both string-representation and JSON.

No? You could still do it the same way as we do today.

The problem here is that hashes and signatures of messages don't actually represent the messages; they only represent a transform of the messages (canonization). This is a ciphertext malleability. The adversary is sending messages which they did not hash and sign. The expectation is that the verifier will "fix" the adversary's message by hashing it according to the transform. The verifier must then only refer to their corrected message as a valid verified message. This has several practical side-effects:

It increases the attack surface before message verification by requiring a potentially expensive transform, rewriting the message on behalf of the attacker. The honest verifier should have to do as little work as possible on an unverified message, reducing the cost of DoS attempts and other potential exploits in the call tree before verification.

It turns the reception of messages off the socket from a simple zero-copy read to a linear buffer, involving read-only parsing of the JSON to a tree of const char * pointers (again, write-free, allocate-free, copy-free view of the data) into a whole complication of either rewriting the message or selectively scanning the message with the hashing and signing contexts to skip regions and characters which aren't canonical (if that's even possible without rewriting the message).

For client-server communication, there are reasonable arguments for being liberal in what the server accepts for compatibility, for friendliness to developers of all levels, and there also aren't the same cryptographic necessities. For server-server (federation) communication, I see no reason to ever send or accept a message which isn't unambiguously canonical and instantly verifiable.

There are a smaller number of server implementations than client implementations. It is easier and more realistic to hold tighter expectations without seeing divergence.

Server implementations have a higher expectation for expertise than client implementations: It is reasonable to except a little more of a difficult threshold for correctness to be met than with a client.

Federation protocol should err with this point on the side of optimization rather than compatibility. A homeserver with many users might spend resources on matters of compatibility with some of its clients some of the time during their occasional interactions; two homeservers with many users each conveying many messages back and forth to each other shouldn't have to over and over for all messages all the time.

@erikjohnston this may be relevant to your interests

This is kind of all true, but it's hard to get worked up over either the cpu overhead of parsing and re-encoding the json (generally I'd expect the cryptographic verification to dominate, though I haven't checked), or the attack surface thereof (if your json parser is insecure, then you're comprehensively stuffed anyway).
In any case, the verification algorithm requires more than reparsing: you also have to strip the existing signatures and redact the event. Which takes zero-copy implementations off the table (or at least requires some very custom parsing).
All that being said: I do see the point. There are good arguments for requiring that the federation APIs use canonical json.

This is kind of all true, but it's hard to get worked up over either the cpu overhead of parsing and re-encoding the json

But these things do get me worked up because ultimately a matrix server is a message passing device and we want to pass as many messages as possible, like any other network router.

I'd expect the cryptographic verification to dominate

Verification is dominated by hashing and io is slowed when you have to stop hashing because you hit some non-canonical sequence like an escaped / in a string which you have to skip and start hashing again after... Something like that will throw a wrench into the pipeline for tight loop of hardware accelerated streaming instructions for SHA which expect aligned 64 byte blocks.

It seems what I really need to know is: how far does a server have to go to correct a non-canonical message before attempting to verify the correction? Is this just limited to the / discrepancy or are there more discrepancies?

As @richvdh says,

In any case, the verification algorithm requires more than reparsing: you also have to strip the existing signatures and redact the event. Which takes zero-copy implementations off the table (or at least requires some very custom parsing).

The full story is at https://matrix.org/docs/spec/server_server/unstable.html#signing-events

The full story is at https://matrix.org/docs/spec/server_server/unstable.html#signing-events

That doesn't answer the question. How far does a server have to go to correct non-canonical JSON? If you send me a message and it's missing a trailing } character, do I correct that for you and then verify the correction?

In any case, the verification algorithm requires more than reparsing: you also have to strip the existing signatures and redact the event. Which takes zero-copy implementations off the table (or at least requires some very custom parsing).

This is not true. I can still do this operation without any writes. The signatures object "removal" isn't a "removal" because this isn't python. I just skip that pointer in my object vector. But this discrepancy now involves deep inspection of string values deep within event content of potentially multi-kilobyte payloads. The JSON parser is made efficient by the fact that it does as little as possible over a payload because a matrix server, again, is like a router and the primary event fields are like the outer headers of a packet.
You guys are obviously using some JSON library or set of JSON libraries and taking some of their internal behaviors for granted to the point where it's becoming your own specification. But that's not your specification and that's not cryptographically sound. Your spec says nothing about signing different messages than what's being transmitted and if it did then your spec would suck. I have never worked with a protocol that requires anything like this. This has to be fixed.

Furthermore, the fix for this doesn't look very difficult. Turn off the escaped / option in synapse's JSON library. All of your data is already signed canonically and doesn't have to be re-signed.

You know what, I'm not done here yet. There are apparently many variations of JSON and when I first read your spec which detailed grammar for a canonical JSON I figured that was your way of coming down unambiguously on one flavor.
If your approach is to treat all JSON with postel's law then I don't even see a reason for canonical JSON in the first place because it really doesn't matter what is signed by another party -- all that matters is whether the party signed it, and whether the verifying party accepted it. If the verifying party adheres to RFC JSON then they will both verify and accept messages that would have been accepted but unverified under canonical JSON. If you think about this for a moment there really isn't a reason for canonical JSON at all. The remote party still has to accept the whole phonebook of variations on JSON either way. Again, all that we care about is whether the signing party actually sent the message and we can do that by simply verifying its bytes.
In reality the choice here is to either dump canonical JSON or enforce it as your specification of JSON.

That doesn't answer the question. How far does a server have to go to correct non-canonical JSON? If you send me a message and it's missing a trailing } character, do I correct that for you and then verify the correction?

Our dialect of canonical-form JSON is very clearly spelt out, complete with BNF, at https://matrix.org/docs/spec/appendices.html#canonical-json.  The point is to express JSON, which is a very ambiguous format, in a single canonical way that can be consistently signed.  It has absolutely nothing to do with fixing syntax errors like missing trailing } characters: if the federation API receives data which is invalid JSON then it should of course reject it.

In any case, the verification algorithm requires more than reparsing: you also have to strip the existing signatures and redact the event. Which takes zero-copy implementations off the table (or at least requires some very custom parsing).
This is not true. I can still do this operation without any writes.

Only because coincidentally Synapse's JSON library happens to output something that is coincidentally quite close to the canonical JSON representation.  If it happened to reorder the keys, change the whitespace, alter numeric field representations etc then you'd be completely out of luck.

You guys are obviously using some JSON library or set of JSON libraries and taking some of their internal behaviors for granted to the point where it's becoming your own specification.

No, we're not; it's the opposite. You're jumping to incorrect conclusions.

Your spec says nothing about signing different messages than what's being transmitted and if it did then your spec would suck.

The spec says "Each PDU is itself a JSON object containing a number of keys, the exact details of which will vary depending on the type of PDU" - i.e. plain old JSON, rather than mandating canonical form on the wire.  As per the original bug, there's certainly an argument for transmitting it in canonical form, but I wholeheartedly agree with @richvdh that this is not remotely a big deal, and whilst we could probably land it in a v2 of the API as a convenience to server implementers and to let the receiver ditch badly signed data as rapidly as possible, there are many many many more significant defects or missing features that we should be focusing on at this point in the project.

This has to be fixed. If I hadn't known to ask about it in #matrix-dev I would've written off your own server as insecure and you'd have a fork in your federation already.

Please feel free to propose stuff like this for a v2 API for federation; we're currently looking at doing a version bump anyway to address some issues in the state resolution consensus algorithm, and it'd be good to get them in.  Another obvious improvement would be to store the signatures & redactable-bits of events in a separate chunk of JSON so one doesn't have to skip fields when signing the event.
Of course, if you want to write a homeserver that only accepts canonical-form JSON over federation, then you are welcome to do so.  It might get a bit lonely out there though.

Furthermore, the fix for this doesn't look very difficult. Turn off the escaped / option in synapse's JSON library. All of your data is already signed canonically and doesn't have to be re-signed. The sooner this gets pushed the better.

Yup, we could try to cheat and retrospectively change the v1 API in a backwards incompatible manner, exploiting the fact that synapse is the only actively federating server implementation currently and that disabling / escaping looks superficially like canonical JSON.  I'd be concerned that even then the library isn't actually necessarily outputting canonical JSON, however (e.g. for representing floating point numbers in the right format, or whatever).
This is then a problem in that: a homeserver implementation which skips the redacted fields by cherrypicking the string buffer will pass the signature (despite the JSON not being in canonical form).  But a homeserver implementation (like today's Synapse) which skips the redacted fields by parsing the JSON, deleting the fields, encoding it as canonical JSON and calculating a signature, will fail the signature.  This is obviously a problem.

I don't even see a reason for canonical JSON in the first place

Okay, I see where you're coming from: ideally the sender could use whatever non-canonical form they liked, sign it, and the receiver would just look at the string and check the signature and move on.
However, this doesn't currently work because we have to skip the fields which aren't covered by the signature - and have to define the operation of skipping them in a manner that both sender & receiver can consistently perform.  This is what we're using canonical JSON for.  The problem is complicated further in that the fields covered by the signature vary from event type to event type.
So yes, this could be solved potentially by ditching canonical JSON entirely, and changing the formats of PDUs and events such that the fields not covered by the signature are always stored outside the signed block of JSON.  Or alternatively, we could mandate canonical JSON throughout.
@richvdh: wdyt about just outputting federation PDUs as canonical JSON (i.e. switching from ujson to the plain python json library, which the spec implies can create canonical JSON if you pass it the right options)?  I don't believe it should break anything, as this is just the format it uses on the wire?  Or is synapse pulling pre-rendered JSON out of the DB?

if the federation API receives data which is invalid JSON then it should of course reject it.

What is invalid JSON if not invalid relative to canonical JSON? Because if it's invalid relative to RFC 7159 JSON then the spec is indeed clearly defining a deterministic transform from RFC JSON to canonical JSON and that's the answer to my question. It's not ideal, but if it is deterministic then I can write a satisfying workaround.

Only because coincidentally Synapse's JSON library happens to output something that is coincidentally quite close to the canonical JSON representation. If it happened to reorder the keys, change the whitespace, alter numeric field representations etc then you'd be completely out of luck.

There's good reason for the federation specification to have routers outright reject frames that are formatted that way. Note my word choices here: "frames," "routers" -- I'm going to sound patronizing but I just want all the federation protocol contributors to keep in mind you're in the internet message passing business here. The elegant protocol should be conscious of what makes things tick in that realm. Those needs really aren't the same as the client-server realm.

I wholeheartedly agree with @richvdh that this is not remotely a big deal

This is a big deal. The efficient network device is so because it's able to reuse large portions of the exact same data it receives as the exact same data it sends. The server never has to take a (valid) content field in an event and copy it into a string buffer removing all of the escapes because it's just going to have to add the same escapes when it sends that same content out to destinations. So we don't do that.  That's what makes network servers fast. And the parser is customized specifically for this. What's a big deal here is that this issue involves discrepancies deep within payload content, and that's something which, beyond its validity, a router should be agnostic to.

However, this doesn't currently work because we have to skip the fields which aren't covered by the signature - and have to define the operation of skipping them in a manner that both sender & receiver can consistently perform. This is what we're using canonical JSON for. The problem is complicated further in that the fields covered by the signature vary from event type to event type.

I think you could accomplish what you need in the specification without specifying a JSON grammar. You can specify the signature field gets removed -- that's fine. You can specify the what event content fields can be included -- that's fine. None of that needs a strict custom canonical grammar. My personal opinion though is that even though you can accomplish those goals with canonical JSON you should force strict adherence to what you have and ultimately it's a better choice.
@ara4n I'd also like to thank you for your kind reception here even though I'm probably being read as a bit animated on this subject. I know that you're dealing with a lot of issues higher up in the stack but I'm trying to convey how this little tiff over this single little / character way down here is what determines the characteristics of that whole stack. How's the expensive parser going to take to when I add m.char message types to the protocol so you can watch another party actually type text or pair-edit a live file in a room? Are you going to wish your messages were passed just a little faster then?

I'm not a core team member but let me give my 2 ct. I guess you cannot indicate how much time per event can be saved on skipping JSON canonicalization and how much this is close to being a bottleneck in the whole chain or not; so the argument about "faster" is a bit too theoretical so far. I agree with the core team members - as of right now, it's looks rather a matter of convenience, than a critical NFR, that the thing on the wire should or need not match bit-by-bit the payload that's been signed. If you wish, applying such restriction now is premature optimization which I, if I were in the core team, wouldn't spend time on yet. From the performance perspective, it might be reasonable to first find out bottlenecks.

Just had a quick RL chat with @erikjohnston about this.
The benefits of canonical JSON basically boil down to a trade-off between:

forcing implementors in different languages to have to find/write a JSON compiler which follows the canonical JSON dialect.  This means that implementations are free to parse the JSON on the wire into RAM and before compiling to canonical form to check the signature if they want, rather than being forced into doing a low-level parse of the JSON to try to find the chunk(s) of the input buffer whose signature needs to be checked.
forcing implementors to find/write a JSON parser which can cough up the byte offsets of the underlying string buffer to let you go and calculate signatures over chunks of the buffer (which could then be canonical or non-canonical form - assuming we separated the data not covered by a signature elsewhere).

I'm not aware of any language (other than possibly perl6?) whose common JSON parsers decorate the parsed datastructure with the byte offsets of the source string - unless you're using a custom low-level JSON parser in C/C++ like the one @jevolk is describing.  Which makes me feel that option 1 above (i.e. keeping canonical json) is the wiser choice for now, and we should consider mandating canonical JSON for the PDU to make life easy for @jevolk and similar (especially if it's just changing the forward-slash escaping).
However, the more I think about this, the more it feels like that rather than bodging around JSON's idiosyncrasies we'd be much much better off solving the problem properly and jumping ahead to a compact format which already has a canonical form, and over whom signatures can be calculated without messing around doing a semi-parse for curly brackets.  Like CBOR. Or protobufs. Or capnproto. Or whatever.
TL;DR: we should consider making synapse spit out canonical JSON as a hack onto the v1 spec.  For v2 spec let's just jump to a sensible efficient format and encoding and never speak of this bug again...

gah, github was showing me a cached copy of the page. @jevolk: i totally see where you are coming from, by asking us to focus on the performance and efficiency of the lowest level of the stack to provide a solid basis for everything else. And you're right that from a network routing/framing perspective this is all hilariously inefficient. However, our aethos is not to prematurely optimise, but to get something working (which it isn't yet, at some levels of the stack), and then make it work fast.  We can ratchet the federation protocol to entirely different transports/formats/encodings as needed (my personal preference would be to use CBOR over WebRTC data channels) as desired, and I can't wait to get there.  But prioritising that over P1 critical bugs like https://github.com/vector-im/riot-web/issues/2996 would be misguided at best.
Now, if you want to help us out and propose a super-efficient well-designed v2 federation transport, please go for it :)

@richvdh points out that if we ditch canonical JSON, we'd be forcing everyone to store events in their raw string representation (as well as their parsed datastructure form) everywhere, so that they can be passed around whilst preserving the signature validity.  Which feels nonideal, and a clear reason to keep calculate signatures over a canonical form.

@ara4n

implementations are free to parse the JSON on the wire into RAM and before compiling to canonical form to check the signature if they want

I just want to highlight something from my original post for consideration here:

The verifier must then only refer to their corrected message as a valid verified message.

Once you compile the canonical JSON from your whatever other JSON library, and then verify that canonical JSON, you can no longer refer to the other JSON library's message in any way. Because the other library's message doesn't contain the signer's message, it's contains the adversary's exploit of your reduction to canonical verification to inject their own information. Data first loaded into any other JSON library, especially in higher level languages with significant amounts of hidden state behind the values exposed in the language, is a message you didn't actually receive.
This means on platforms where there's a non-canonical JSON library used for the HTTP stack and then a canonical JSON library used for verification, you have to stringify the canonical representation and then parse it back through the non-canonical.

I think the conclusion of this epic was that we should use canonical form.

Thanks for summarizing, I wasn't about to take a day out to read all that.


No range checks in NativeCurrency

There are to loops in NativeCurrency where there are no range checks on the size indicators of dynamically-sized structs. These size indicators are, AFAICT, used to find the next element in a list, and should thus be range-checked.

Hi @elielnfinic! Sorry to inform that this issue has already been fixed by 9368dd7f1c48ef1e20bcb01cf513205157d7fab1. The reason why this issue is still open is because that commit lives on a branch that has not been merged into master yet, but soon will be.
If you are eager to contribute, here are some high-priority open issues:

#282 (and possibly related: #286) involving application programming, concurrency, write/read locks
#287 involving application programming, concurrency
#285 involving application programming
#288 involving consensus-critical logic, tasm code, proptests
#283 Note that branch asz/negative-fees already changed the inner type but we still need and want a very strong test suite for NeptuneCoins

Alright, I will pick some tasks. Btw, it would be good to also share these tasks on the Telegram group(maybe??).


WebVR: can we start tracking the state of support now?

It may be early, but they've been working on it for a few years and we're soon to get consumer releases of VR headsets
https://developer.mozilla.org/en-US/docs/Web/API/WebVR_API
http://blog.tojicode.com/2014/07/bringing-vr-to-chrome.html
http://mozvr.com/

Indeed it would be great, it's precisely now that it's not yet widely adopted that it would be the most useful!

:+1:

:+1:

+1

Until it does get accepted (despite the 1.0 specs from major player, namely Google and Mozilla) there is https://iswebvrready.org

👍

:+1:

The WebVR 1.0 spec is out, and here it is!
https://w3c.github.io/webvr/
Right now, no browser supports it, except in experimental Chromium and Nightly builds. However, there is a very complete polyfill at https://github.com/borismus/webvr-polyfill
However, it is important to note that the current webvr-polyfill is supporting the OLD API - there is a WebVR 1.0 branch, but it is not the main branch yet. Make sure you grab the 1.0 version for experiments. Also, make sure you have the correct Firefox Nightly build supporting 1.0 - older FF is still supporting the old API. (VRDevice instead of VRDisplay).
The feature test could be really simple:
navigator.getVRDisplays().then(function (displays) {
  if (!displays.length) {
    // WebVR is supported, no VRDisplays are found.
    return;
  }

This page describes feature-detecting and using WebVR 1.0. Promise support required, since .getVRScreens returns a Promise.
https://hacks.mozilla.org/2016/03/introducing-the-webvr-1-0-api-proposal/
The Slack channel where you can find all the usual suspects developing and using WebVR is:
https://webvr.slack.com
Finally, there is a lot of work using the a-frame JS library, which creates VRML like static markup in HTML to create simple VR scenes.
http://aframe.io

+1

Since this earlier post, webvr-polyfill supports both the WebVR 1.0 spec and the older, Mozilla-specific versions.

Here's a caniuse style test suite for the webvr 1.0 spec.
webvr-caniuse-tests.zip
More sub-tests can be added as it solidifies. For now, the tests all work with webvr-polyfill and should work with Chromium experimental, which supports WebVR.
REFERENCES:
WebVR 1.0 Spec
https://w3c.github.io/webvr/
Slack Channel
http://webvr.slack.com
Chromium builds:
https://webvr.info/get-chrome/
More information on Firefox and Samsung Gear VR
https://iswebvrready.org/faq.html
This site details related APIs (e.g. gamepad)
https://iswebvrready.org/
Tests based on:
https://w3c.github.io/webvr/

👍

Yes! Awesome!

FYI, the chromium issue has been assigned the M55 milestone: https://bugs.chromium.org/p/chromium/issues/detail?id=389343#c53
btw, @pindiespace, the link in your comment above, to https://github.com/borismus/webvr-polyfill, somehow points to https://github.com/Fyrd/caniuse/issues/url instead. Please take a look.

Corrected and checked all polyfill links, are there any others? I should also note that BabylonJS supports WebVR, but it puts it inside special-purpose cameras (WebVRFreeCamera).

👍

Now available at http://caniuse.com/#feat=webvr

Great! Note that Google Chrome Canary is supporting, if you turn on with chrome://flags. Support from Chrome, Firefox, Edge, and mobile Chrome and FF in the next month or so.
Samsung Internet browser is now supporting (they had it in beta from Spring 2016).
Also, Oculus Carmel will be a dedicated WebVR web browser - developer previews from Oculus.
The laggard - Safari - horrible, and tends to break even with WebVR-Polyfill https://github.com/googlevr/webvr-polyfill
Plenty of updates on the Slack channel - http://webvr.slack.com

Plenty of updates on the Slack channel - http://webvr.slack.com

That page says: "If you have an @mozilla.com, @google.com or @vizor.io email address, you can create an account." -- is this meant to be a channel for internal discussion only?

No, you have to go to the Heroku signup:
http://webvr-slack.herokuapp.com/
On Sun, Feb 12, 2017 at 6:27 PM, Waldir Pimenta<EMAIL_ADDRESS>wrote:

Plenty of updates on the Slack channel - http://webvr.slack.com
That page says: "If you have an @mozilla.com, @google.com or @vizor.io
email address, you can create an account." -- is this meant to be a channel
for internal discussion only?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Fyrd/caniuse/issues/2091#issuecomment-279279939, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAOuanh_2LhGqkDqeN0dgcUzF6fnCTbUks5rb7-WgaJpZM4Gj3zF
.

--
=================
Dr. Pete Markiewicz
Email<EMAIL_ADDRESS>Sustainable virtual design blog:
http://sustainablevirtualdesign.wordpress.com
Sustainability template: http://greenboilerplate.com
*Sustainable Ux in Virtual Reality for Sustainable Ux 2017 (narrated): *
*https://youtu.be/bU0tz05lcBw https://youtu.be/bU0tz05lcBw*My "Ux in VR"
presentations on Google Docs (note you can comment)
WebVR 1.0 API
https://docs.google.com/presentation/d/13a29m0SbpTeItFP8fjrSoKNb7nsjAd4DC9lWnokWEfg/edit?usp=sharing
Sustainable Ux in VR
https://docs.google.com/presentation/d/1OTXaz3RuV0HWgM754PRMUC7d2KYVHH974s5hnAt53wk/edit?usp=sharing
*Teaching site: *http://plyojump.com http://www.plyojump.com/
*Buy my book! *- Millennials and the Popular Culture
Lifecourse: http://www.lifecourse.com/store/catalog/lca/mpc.html
Amazon Author Page:
http://www.amazon.com/Pete-Markiewicz/e/B0069VZ7BG/ref=ntt_athr_dp_pel_pop_2
On that page, see my DARPA Grand Challenge 2005 entry video, "Team
Robomonster":
*Team Robomonster *(DARPA 2005 Grand Challenge):
http://robotsthatjump.wordpress.com/category/team-robomonster/
*Indiespace *(1st to sell downloaded music, March 1994):
http://www.indiespace.com. Also see http://archive.org under
"Kspace.com" 1996 for our original site.
=================


TypeError: _enzyme.default.configure is not a function

Current behavior
Hi, I'm new into all this enzyme/jest stuff and having next problem while trying to implement it on a NextJs project.
When running simple jest configuration next error is show

    TypeError: _enzyme.default.configure is not a function

      4 | import Enzyme from 'enzyme';
      5 | import Adapter from 'enzyme-adapter-react-16';
    > 6 | Enzyme.configure({ adapter: new Adapter() });
        |        ^
      7 |
      8 | describe('Home screen', () => {

Expected behavior
Run tests
Your environment
Enzyme.js file
import Enzyme from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
Enzyme.configure({ adapter: new Adapter() });

.babelrc file
{
  "presets": ["next/babel"],
  "plugins": [
    [
      "module-resolver",
      {
        "root": ["./"],
        "alias": {
                <directory_aliases>
        }
      }
    ]
  ]
}

jest.config.js file
module.exports = {
  moduleFileExtensions: [
    "ts",
    "tsx",
    "js"
  ],
  transform: {
    "^.+\\.jsx?$": "babel-jest"
  },
  testMatch: [
    "**/*.(test|spec).(js|jsx)"
  ],
  globals: {
    "babel-jest": {
      useBabelrc: true,
      tsConfigFile: "jest.tsconfig.json"
    }
  },
  coveragePathIgnorePatterns: [
    "/node_modules/",
    "enzyme.js"
  ],
  setupFilesAfterEnv: ["<rootDir>/enzyme.js"],
  coverageReporters: [
    "json",
    "lcov",
    "text",
    "text-summary"
  ],
  moduleNameMapper: {
    "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga|graphql)$": "identity-obj-proxy",
    "\\.(css|less|scss)$": "identity-obj-proxy"
  }
};

Same thing happens with mount and shallow methods
API

[X] shallow
[X] mount
[ ] render

Version

library
version

enzyme
3.11.0

react
16.12.0

react-dom
16.12.0

react-test-renderer
16.12.0

adapter (below)
16

Adapter

[X] enzyme-adapter-react-16
[ ] enzyme-adapter-react-16.3
[ ] enzyme-adapter-react-16.2
[ ] enzyme-adapter-react-16.1
[ ] enzyme-adapter-react-15
[ ] enzyme-adapter-react-15.4
[ ] enzyme-adapter-react-14
[ ] enzyme-adapter-react-13
[ ] enzyme-adapter-react-helper
[ ] others ( )

Don't use import Enzyme from 'enzyme'; use import { configure } from 'enzyme'.
Additionally, TypeScript's module system is broken unless you enable synthetic imports and esModuleInterop.


Simon 4.1.1

Thank you for the contribution. It was merged directly as c9584d8730e8e78014362e71e99b052e00dbc5d9 to keep commit history cleaner. Your contribution is still credited to you.


Redesign of Translational (support)

Reported by AHaumer on 22 Nov 2007 14:26 UTC
Redesign of Translational according to new design of Rotational (55357acf3d50b529cdc3fd1c96b29c767d2fc796, 75553227fd2bf6556174178397cf8a7ff8c7d676) with conditional support.

Migrated-From: https://trac.modelica.org/Modelica/ticket/22

Comment by AHaumer on 22 Nov 2007 18:41 UTC
fixed by 46bed254e1a94f6c2c8373b598c1b557e59a1ca5, 7547c35b01e0f41182e11ce87a05a6238d51999a redesign of Translational with conditional support according to new design of Rotational (55357acf3d50b529cdc3fd1c96b29c767d2fc796, 75553227fd2bf6556174178397cf8a7ff8c7d676); default value of useSupport = false (since this was the behavior up to now); adaption of conversion script


WIP: need consistent interface for obtaining claims through wallet

There's a bunch of different ways to obtain a claim through the wallet, all returning differently formatted dictionary outputs.
Need to unify this, so that at the very least the output from Daemon API commands are consistent.

          1 Error

:no_entry_sign:
Please include a CHANGELOG entry.

          1 Message

:book:
See http://keepachangelog.com/en/0.3.0/ for details on good changelog guidelines

  Generated by :no_entry_sign: Danger

Closing for now to make seperate pull request for the smaller stuff


add feature https_allow_http

allow tcp port to support both http and https

Resubmit to tengine-3.1.0 branch


[Add] Loading shimmer/skeleton while new buttons get fetched

Details
On the main landing page, if we use the pagination on the below to go to different pages, there is a layout shift and it breaks the UX . A skeleton or loader or shimmer can be added to show the async nature which will go well with the design.
Screenshots
landing page

time b/w the click event and the retrieval of new data

Type of Contribution

[ ] Update to an existing Animated Button
[ ] Adding a new Button
[ ] Resolving a bug
[X] Proposal to the Repository
[ ] Changes related to documentation or README.md
[ ] Other Changes

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue
[ ] I am a GSSoC'23 contributor

@Spyware007 Kindly assign this issue to me


Update sangria to 3.0.0

Updates org.sangria-graphql:sangria from 2.1.6 to 3.0.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.sangria-graphql", artifactId = "sangria" } ]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #153.


[IOS] Not receiving incoming call for IOS

Issue Summary
I am able to perform outgoing calls but not able to receive incoming call for iOS
Logs:
Successfully registered for VoIP push notifications.

Hi @tanmoy27112000,
Have you been able to receive atleast one working call?

Yes we use to get incoming calls earlier but now only outgoing calls are working

Yes we use to get incoming calls earlier but now only outgoing calls are working

I see, so it did work but now doesn't.
Please provide more information with regards to:

Did you update twilio_voice package, and when roughly?
If yes to the above, from which package version did you upgrade from, and which package version did you upgrade to? i.e. 0.0.9 -> 0.1.0

current version is:
twilio_voice:
    dependency: "direct main"
    description:
      name: twilio_voice
      sha256: c9b0396a1b3d6ed08998da8299a4e7be16d4862c6e3b74cf2c9d901a8a2c190e
      url: "https://pub.dev"
    source: hosted
    version: "0.1.1"

the older version was 0.1.0 according to by GitHub commits

@tanmoy27112000
Feel free to review these changes (via releases / tags) for the corresponding versions here.
No code change has been made to iOS package with exception of a twilio-voice library update (I've updated the release notes to reflect this change), feel free to review Twilio's iOS changelog here aswel.

@tanmoy27112000 I am unable to do so at the moment.
If you can step into the iOS swift code and check if push notifications are infact being received on physical iOS devices - that would be a start.

I have checked with older version, the app is not receiving call

Have you checked the twilio logs? When calling, It should gove error as eg Error 51324 for apn something.

During outgoing call it is working perfectly, but no logs or event is getting triggered for incoming calls

@tanmoy27112000 if you aren't receiving calls on older versions, I suspect something else might be wrong outside of the twilio_voice package.

If there is certificate or token issue can we log them as error?

@cybex-dev Basically we have three things, iOS mobile app, Android mobile app and Desktop mac app(Electron) and when we are trying to make an inbound call to Twilio number then our call is successfully ringing on Android Flutter App (your flutter voice package) and our desktop app but the same call is not ringing in iOS device. If we do force close desktop app and uninstall android app then we are not receiving the call in iOS again but we are able to outbound call successfully from iOS mobile app.
Could you please check this, or if you want to connect with us on google meet then we can explain more briefly like what's exactly the happening.
@Erchil66 I have checked the backend route and logs of every call in Twilio's dashboard and in case of iOS mobile app( uninstall android app, force closed desktop app but open in iOS) the call is going to unanswered state because no one is picking or answering the call.

@cybex-dev Basically we have three things, iOS mobile app, Android mobile app and Desktop mac app(Electron) and when we are trying to make an inbound call to Twilio number then our call is successfully ringing on Android Flutter App (your flutter voice package) and our desktop app but the same call is not ringing in iOS device. If we do force close desktop app and uninstall android app then we are not receiving the call in iOS again but we are able to outbound call successfully from iOS mobile app.

I understand your meaning - having experienced this in the past, it seemed to be a configuration / sandbox issue in my particular case.
I will take a look at the current implementation, since I did an upgrade of Twilio Voice iOS SDK in the second last version 3 weeks ago, see Release 0.1.1.

@cybex-dev seems like there was a issue with the credential creation we were able to solve it, still trying to understand the root cause of the issue, closing the ticket, will update if we are able to pinpoint the exact bug


Reformat headings on choose video/aerial image screen

More reasonable headings maybe: Add project video, Add project image, Connect to server

Fixed in #77


Add Rocky Linux 9 support

Description
Checklist/ToDo's

[x] Added documentation? N/A, behaviour not changed
[x] Added release note entry? (  docs/release-notes.md )
[x] Tested? Yes, on a Scaleway bare metal server

How do you instal Rocky 9?  Looks like basis image is not available from hetzner:
root@rescue ~ # ls -1 images/{CentOS,Rocky}*
images/CentOS-79-64-minimal.tar.gz
images/CentOS-79-64-minimal.tar.gz.sig
images/CentOS-80-stream-amd64-base.tar.gz
images/CentOS-80-stream-amd64-base.tar.gz.sig
images/CentOS-85-64-minimal.tar.gz
images/CentOS-85-64-minimal.tar.gz.sig
images/Rocky-85-amd64-base.tar.gz
images/Rocky-85-amd64-base.tar.gz.sig

I used this repository to create an OCP cluster on an already provisioned bare metal server running Rocky 9 (on Scaleway btw, not Hetzner).
Maybe this repository should be renamed libvirt-ocp4 and leave the 00-provision-hetzner.yml playbook optional ?

Good point, I have already thought about renaming it, but I am not clear about the impact.

@debovema  Let's move the renaming discussion into an own Issue #232

@debovema Can you be so kind and update (rebase) to the latest devel tree version?

@debovema Can you be so kind and update (rebase) to the latest devel tree version?

Done

/test

/test


RCTConvert.h not found

thanks for the great component, but on my RN app have an issue...
im using react native 0.38.0
how can i solve this issue..
Thanks

You'll have to user version 0.2.0 and below.
0.3.0 is for React Native versions >= 0.40.0


New version: DelayEmbeddings v1.18.0

Registering package: DelayEmbeddings
Repository: https://github.com/JuliaDynamics/DelayEmbeddings.jl
Created by: @Datseris
Version: v1.18.0
Commit: 9659f46a6409fcbfd7c109a36c90943d02466808
Git reference: master

sorry for the mistake, please close this :)


[localization] Rig localization using generic camera

Implements the rig localization using the generic PnP, which uses the 2d-3d associations collected from each camera of the rig.

[X] add opengv dependency
[X] create the function remapping the input parameters
[x] unit test
[x] modify the rig localizer method for

[X] CCTAG
[x] SIFT

ops, same as poparteu/openMVG#63


Publishing "Access to private apps without having to deploy client agents"

New Ref. Architecture Diagram for SASE.
Correcting capitalization of the words "WARP connector" to "WARP Connector"

Simon Thorpe is working on Diagram, please do not publish until he is done.

Ready to push to production


GitHub website

@crwallace This is a big PR due to the public folder. I have a build script that makes it easy to deploy the built files to the gh-pages branch. The website can be accessed here:
https://department-of-veterans-affairs.github.io/vets.gov-patterns/
Take a look at 8971f71 for the build script

@bshyong -- Should the public folder be getting checked-in? I thought there was a way for gh-pages to build and deploy pages without needed to check them in.

Hm I'll see if I can do it without checking it into master. i might have to
modify my script. AFAIK you can't push something to a branch without
checking it in somewhere - so maybe I remove the public folder from master
but have it checked in on gh-pages.
It's currently checked into master and pushed with git subtree
On Wednesday, October 5, 2016, Courtney Eimerman-Wallace <
<EMAIL_ADDRESS>wrote:

@bshyong https://github.com/bshyong -- Should the public folder be
getting checked-in? I thought there was a way for gh-pages to build and
deploy pages without needed to check them in.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/department-of-veterans-affairs/vets.gov-patterns/pull/20#issuecomment-251773811,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASguXNho9Dj9VdxtkWvwvTLxphUxbabks5qw_nsgaJpZM4KN7f3
.

--
Ben Shyong
Senior Software Engineer, AdHoc LLC
909-274-9664


Karma + Gulp4: FormatError

var karmaConfig = {
        configFile: __dirname + '/' + config.karma,
        singleRun: true,
        autoWatch: false
    };

gulp.task('test', gulp.series('compile:build', function testing(done) {
    var karma = new plugins.karma.Server(karmaConfig, done);
    karma.start();
}));

[14:52:25] Error: 1
    at formatError (C:\Program Files\nodejs\node_modules\gulp-cli\lib\versioned\^4.0.0-alpha.1\formatError.js:20:10)
    at Gulp.<anonymous> (C:\Program Files\nodejs\node_modules\gulp-cli\lib\versioned\^4.0.0-alpha.1\log\events.js:26:15)
    at emitOne (events.js:77:13)
    at Gulp.emit (events.js:169:7)
    at Object.error (c:\git\pos\node_modules\undertaker\lib\helpers\createExtensions.js:58:10)
    at handler (c:\git\pos\node_modules\now-and-later\lib\map.js:46:14)
    at f (c:\git\pos\node_modules\once\once.js:17:25)
    at f (c:\git\pos\node_modules\once\once.js:17:25)
    at done (c:\git\pos\node_modules\async-done\index.js:24:15)
    at f (c:\git\pos\node_modules\once\once.js:17:25)
    at handler (c:\git\pos\node_modules\now-and-later\lib\mapSeries.js:44:16)
    at f (c:\git\pos\node_modules\once\once.js:17:25)
    at f (c:\git\pos\node_modules\once\once.js:17:25)
    at done (c:\git\pos\node_modules\async-done\index.js:24:15)
    at removeAllListeners (c:\git\pos\node_modules\karma\lib\server.js:332:7)
    at Server.<anonymous> (c:\git\pos\node_modules\karma\lib\server.js:343:9)

I have no idea what you are even doing here.  This issue tracker isn't the place to open issues related to external modules you are bringing in.  If you can actually write up what the issue is, we can better guide you.

It's a gulp 4 format error. It happens when using karma and done. Using the done callback throws the format error. It's something with gulp4 not liking how karma exits.
I seen similar issues related to gulp 4 and mentioning of gulp4 error handling and reporting needs to be improved.
If it's karma that needs updated to handle gulp4 error handling, then I will post an issue there. But signs point to this being a gulp4 issue.
Sometimes I also get a 'Did you forget to call async?' message.

@robertbaker if you are getting the async message you aren't using gulp 4 correctly.  I can't tell anything from your stack trace and it looks like you are getting a non-error object passed as the 1st argument to a callback function.  If you aren't able to find the root cause of this issue in karma then we don't have anything to do here.


404 at /engine/userguide/networking/default_network/container-communication/

URL: /engine/userguide/networking/default_network/container-communication/

cc @mistyhacks


Unable to send escape sequences to the terminal

While searching for a solution yesterday, I stumbled upon this cached StackOverflow answer. The guy suggests that I do:
execute "silent !echo -ne " . ESCAPE_SEQUENCE

I therefore tried the following combinations:
!echo -ne "\\033]11;#404040\\007" (changes the background color)

Says E194: No alternate file substitute for "#".
I tested with a different sequence which doesn't include '#'.
!printf '\033[2J' (clears the screen)

This doesn't error but it also doesn't do anything. The command just displays the character sequence escaped, like so:

Going back to the first sequence, I tried to manually escape all characters myself.
!printf '\x5C\x5Ce\x5C\x5C033]11;\x23555555\x5C\x5C007'

This doesn't output the characters escaped, but also doesn't do anything.

I've tried pretty much every combination I know with

execute
bash -c
sh
using system()

It doesn't matter the medium, the escape sequences don't seem to reach the underlying shell.
If this can't be feasibly solved, is there a way to get the process info from a running Vim instance from within it?

Fixed by 8.2.0258.  Instead of using :! which – in your first command – required the # to be escaped, run this:
:call echoraw("\033]11;#404040\007")

This correctly changes the background color of the terminal (provided that it understands the sequence, I guess).  Tested on xterm(362).


Update Arch package

Is your feature request related to a problem? Please describe.
arch package is still 11.0.3 while the most recent is 11.2
Describe the solution you'd like
update the arch package
Describe alternatives you've considered
update the arch package ;-;

Go contact the package maintainer then:
https://archlinux.org/packages/extra/x86_64/ghidra/
https://archlinux.org/packages/?maintainer=anthraxx

This project doesn't not maintain the Arch package.  You will have to follow the links that @gemesa has provided.


Change background color of child window

Hello all.
I would like to know how can I approach this problem using Python. This question - how to change the background color of a newly created window - has been commented in cpp https://github.com/ocornut/imgui/issues/2700 ; https://github.com/ocornut/imgui/issues/1289. Example:
imgui.set_next_window_bg_alpha(1.0)
imgui.core.set_next_window_position(x,y) # hardcoded
imgui.core.set_next_window_size((loop_window_width/2)-149,315)
imgui.begin("side2", True, flags=imgui.WINDOW_NO_SCROLLBAR|imgui.WINDOW_NO_RESIZE|imgui.WINDOW_NO_TITLE_BAR)
[maybe here?]
imgui.end()

Since this is a port I think it should be able to do. Although I cannot find anything related to this in the readthedocs.
Best

have you tried push_style_color?

 imgui.core.push_style_color(ImGuiCol variable, float r, float g, float b, float a=1.)
What would be the variable?

Hello,
Here, variable would be a flag of type cimgui.ImGuiCol, i.e. one of COLOR_*:
COLOR_TEXT
COLOR_TEXT_DISABLED
COLOR_WINDOW_BACKGROUND
COLOR_CHILD_BACKGROUND
COLOR_POPUP_BACKGROUND
COLOR_BORDER
COLOR_BORDER_SHADOW
COLOR_FRAME_BACKGROUND
COLOR_FRAME_BACKGROUND_HOVERED
COLOR_FRAME_BACKGROUND_ACTIVE
COLOR_TITLE_BACKGROUND
COLOR_TITLE_BACKGROUND_ACTIVE
COLOR_TITLE_BACKGROUND_COLLAPSED
COLOR_MENUBAR_BACKGROUND
COLOR_SCROLLBAR_BACKGROUND
COLOR_SCROLLBAR_GRAB
COLOR_SCROLLBAR_GRAB_HOVERED
COLOR_SCROLLBAR_GRAB_ACTIVE
COLOR_CHECK_MARK
COLOR_SLIDER_GRAB
COLOR_SLIDER_GRAB_ACTIVE
COLOR_BUTTON
COLOR_BUTTON_HOVERED
COLOR_BUTTON_ACTIVE
COLOR_HEADER
COLOR_HEADER_HOVERED
COLOR_HEADER_ACTIVE
COLOR_SEPARATOR
COLOR_SEPARATOR_HOVERED
COLOR_SEPARATOR_ACTIVE
COLOR_RESIZE_GRIP
COLOR_RESIZE_GRIP_HOVERED
COLOR_RESIZE_GRIP_ACTIVE
COLOR_PLOT_LINES
COLOR_PLOT_LINES_HOVERED
COLOR_PLOT_HISTOGRAM
COLOR_PLOT_HISTOGRAM_HOVERED
COLOR_TEXT_SELECTED_BACKGROUND
COLOR_DRAG_DROP_TARGET
COLOR_NAV_HIGHLIGHT
COLOR_NAV_WINDOWING_HIGHLIGHT
COLOR_NAV_WINDOWING_DIM_BACKGROUND
COLOR_MODAL_WINDOW_DIM_BACKGROUND

Changing bg color would be COLOR_WINDOW_BACKGROUND:
imgui.set_next_window_bg_alpha(1.0)
imgui.core.set_next_window_position(200,200) # hardcoded
imgui.core.set_next_window_size((loop_window_width/2)-149,315)
imgui.push_style_color(imgui.COLOR_WINDOW_BACKGROUND, 200, 0, 0)
imgui.begin("side2", True, flags=imgui.WINDOW_NO_SCROLLBAR|imgui.WINDOW_NO_RESIZE|imgui.WINDOW_NO_TITLE_BAR)
imgui.end()
imgui.pop_style_color()

Note that the current release of pyimgui is based on an old version of dear imgui and that recent functionalities may not be present or work as expected. We are working on an upgrade to catch up with dear imgui.

Dear @KinoxKlark, thank you for the clarification. It works perfectly.


feat: full tx flow in debugger

Change Summary

Adds full end to end flow for testing frame transactions in the debugger
Some considerations

Quite unreliable when testing with rainbow desktop extension. Works fine with metamask
Could be simplified by just posting a dummy transaction hash instead of executing transaction
Recommended use is to use anvil or hardhat to fork the chain you are testing e.g. for optimism: anvil --fork-url https://mainnet.optimism.io --chain-id 31337. Then connect to anvil in the debugger
Perhaps write a guide?

Merge Checklist

[x] PR has a Changeset
[x] PR includes documentation if necessary
[x] PR updates the boilerplates if necessary

@stephancill why is my commit in here? it makes it little bit confusing to review as it is already merged in main.

whats the status here @stephancill ?

Ready to merge @davidfurlong


Regex match methods do not accept negative position

A negative index into a string usually means to start counting from the end ("foo"[-2..] == "oo"). This does not work for Regex's match methods though: /oo/.match("foo", -2) == nil.
I think it makes sense to add this to the implementation for consistency.

Regex#match depends on String#char_index_to_byte_index which doesn't support negative arguments. Not sure about the rest of Regex though

Btw. this works in Ruby: /oo/.match?("foo", -2) # => true

There are actually two notions of an index; character indices depend on String as mentioned above, byte indices should only require single-line additions to Regex#match_at_byte_index and #matches_at_byte_index?.


NPM repo not found

While following your install instructions I got this error:
npm ERR! 404  '@geospoc/v-mapbox-geocoder@latest' is not in the npm registry.
Here is the list of errors fired:
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@geospoc%2Fv-mapbox-geocoder - Not found
npm ERR! 404
npm ERR! 404  '@geospoc/v-mapbox-geocoder@latest' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

Solved: What happened was that on your page you have some wrong instructions at the beginning.
In order to install this package one should: npm i @mapbox/mapbox-gl-geocoder vue-mapbox vue-mapbox-geocoder

@matias2018 What you are doing is installing a different repository than the current one.


the program freezes when uploading.

When uploading a screenshot the program freezes.
possibly add threading to solve this.

TODO: Research STAThread


On forcefully deletion of a driver, the driver is not getting restarted.

I have a spark streaming job that I am trying to submit by a spark-k8-operator. I have kept the restart policy as Always. However, on the manual deletion of the driver the driver is not getting restarted.
My yaml:
apiVersion: "sparkoperator.k8s.io/v1beta2" kind: SparkApplication metadata:   name: test-v2   namespace: default spec:   type: Scala   mode: cluster   image: "com/test:v1.0"   imagePullPolicy: Never   mainClass: com.test.TestStreamingJob   mainApplicationFile: "local:///opt/spark-2.4.5/work-dir/target/scala-2.12/test-0.1.jar"   sparkVersion: "2.4.5"   **restartPolicy:     type: Always**   volumes:     - name: "test-volume"       hostPath:         path: "/tmp"         type: Directory   driver:     cores: 1     coreLimit: "1200m"     memory: "512m"     labels:       version: 2.4.5     serviceAccount: spark     volumeMounts:       - name: "test-volume"         mountPath: "/tmp"     terminationGracePeriodSeconds: 60   executor:     cores: 1     instances: 2     memory: "512m"     labels:       version: 2.4.5     volumeMounts:       - name: "test-volume"         mountPath: "/tmp"
Spark version: 2.4.5
apiVersion: "sparkoperator.k8s.io/v1beta2"
Steps which I followed:

Create resource via kubectl apply -f examples/spark-test.yaml . Pod created successfully.
Delete the driver manually.

Expected behavior:
A new driver pod would be restarted as per the restart policy.
Actual behavior:
Driver and executor pods got deleted.
Environment:
Testing out this with Docker On Mac. With 4 CPUs and 8 GB Memory
Logs from spark -operator
{FAILING driver pod failed with ExitCode: 143, Reason: Error}

Can you check the status of your SparkApplication by doing kubectl get sparkapplication <name> -o=yaml?

@liyinan926
`
apiVersion: sparkoperator.k8s.io/v1beta2
kind: SparkApplication
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"sparkoperator.k8s.io/v1beta2","kind":"SparkApplication","metadata":{"annotations":{},"name":"test-v2","namespace":"default"},"spec":{"driver":{"coreLimit":"1200m","cores":1,"labels":{"version":"2.4.5"},"memory":"512m","serviceAccount":"spark","terminationGracePeriodSeconds":60,"volumeMounts":[{"mountPath":"/tmp","name":"test-volume"}]},"executor":{"cores":1,"instances":2,"labels":{"version":"2.4.5"},"memory":"512m","volumeMounts":[{"mountPath":"/tmp","name":"test-volume"}]},"image":"com/test:v1.0","imagePullPolicy":"Never","mainApplicationFile":"local:///opt/spark-2.4.5/work-dir/target/scala-2.12/test-0.1.jar","mainClass":"com.test.TestStreamingJob","mode":"cluster","restartPolicy":{"type":"Always"},"sparkVersion":"2.4.5","type":"Scala","volumes":[{"hostPath":{"path":"/tmp","type":"Directory"},"name":"test-volume"}]}}
creationTimestamp: "2020-05-01T08:12:09Z"
generation: 4
name: test-v2
namespace: default
resourceVersion: "37484"
selfLink: /apis/sparkoperator.k8s.io/v1beta2/namespaces/default/sparkapplications/test-v2
uid: 6eb1e6cc-4009-41e1-9dcc-f02fbf26baca
spec:
driver:
coreLimit: 1200m
cores: 1
labels:
version: 2.4.5
memory: 512m
serviceAccount: spark
terminationGracePeriodSeconds: 60
volumeMounts:
- mountPath: /tmp
name: test-volume
executor:
cores: 1
instances: 2
labels:
version: 2.4.5
memory: 512m
volumeMounts:
- mountPath: /tmp
name: test-volume
image: com/test:v1.0
imagePullPolicy: Never
mainApplicationFile: local:///opt/spark-2.4.5/work-dir/target/scala-2.12/test-0.1.jar
mainClass: com.test.TestStreamingJob
mode: cluster
restartPolicy:
type: Always
sparkVersion: 2.4.5
type: Scala
volumes:

hostPath:
path: /tmp
type: Directory
name: test-volume
status:
applicationState:
errorMessage: 'driver pod failed with ExitCode: 143, Reason: Error'
state: FAILING
driverInfo:
podName: test-v2-driver
webUIAddress: <IP_ADDRESS>:4040
webUIPort: 4040
webUIServiceName: test-v2-ui-svc
executionAttempts: 1
executorState:
test-v2-1588402847814-exec-1: FAILED
test-v2-1588402847814-exec-2: FAILED
lastSubmissionAttemptTime: "2020-05-02T07:00:49Z"
sparkApplicationId: spark-58491973c21f4585ae054b286c4d2c9f
submissionAttempts: 1
submissionID: 896d5184-ae44-4e87-bf05-45158f811640
terminationTime: "2020-05-02T07:07:39Z"
`

I think the problem is that you don't have retry limits and intervals defined under restartPolicy. There seems a bug in how default values of those get applied, causing the limits to be zeros if not specified. If you follow the following example, the operator should be able to restart the job automatically:
spec:
  restartPolicy:
    type: OnFailure
    onFailureRetries: 3
    onFailureRetryInterval: 10
    onSubmissionFailureRetries: 3
    onSubmissionFailureRetryInterval: 10

In the meantime, I created #898 to fix the but with default values.

@liyinan926 thanks!!
BTW what are the default values?
Also, is it possible to keep the value of onFailureRetryInterval dynamic and let the code based on the exception set it?
I have a requirement where the target database might have a maintenance window and during that period I want to keep onFailureRetryInterval at a higher value. OR Can have a new flag which gets triggered based on application exit code? I want to handle database downtime with a higher retry interval.

@suchitgupta01  Would using the Always policy with an exponential backoff to some maximum also fit your use case?
@liyinan926 Is there a way with the existing operator release to use Always and have it retry?

@suchitgupta01 the default values are as follow:
restartPolicy:
  type: Never
  onFailureRetryInterval: 5 # seconds
  onSubmissionFailureRetryInterval: 5 # seconds

@jkleckner you can use Always to request retries with a linear backoff mechanism.

@liyinan926 But the OP was already using Always and the retry didn't happen, true?
I guess my question is more clear as "Is there a workaround with the currently released operator to  retry on failure?"

Yes, see https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/issues/897#issuecomment-623042026.

Sorry to be so imprecise.
I want something to always restart on success or failure.
This is what Always means, true?  And that didn't work for the OP.
So would something like this accomplish that?
restartPolicy:
  type: Always
  onFailureRetries: 1000000
  onFailureRetryInterval: 10
  onSubmissionFailureRetries: 3
  onSubmissionFailureRetryInterval: 10

Yes, that's supposed to work.

@jkleckner @liyinan926 'exponential backoff' won't fit in my case.
Use Case: If the database is down for maintenance, I was looking for a higher "onFailureRetryInterval" say 1 hour and in the normal case, it would be 30 seconds.
Can we set the onFailureRetryInterval, on the basis of exit code like if System.exit(1) then we set a different value?

@suchitgupta01 no, the operator doesn't setting onFailureRetryInterval adaptively at runtime.

BTW: @suchitgupta01 have you tried the workaround above? If so, did it solve the issue of no auto restart?

@liyinan926 thanks for the help. Tested both workaround and the fix. Working fine

OK, closing this. As I said, the operator doesn't support setting onFailureRetryInterval adaptively at runtime.

Hey @liyinan926
Im using v1beta2-1.1.2-2.4.5 version  with those values for my streaming job :
  Restart Policy:
    On Failure Retries:                    1000000
    On Failure Retry Interval:             10
    On Submission Failure Retries:         1000000
    On Submission Failure Retry Interval:  10
    Type:                                  Always

Also I have this cronjob which delete the driver every hour - just to test how it deals with failure recovery and such.
and it works fine at the first , it takes it a few seconds to raise up again .
however after a few hours (12 h) I noticed that the raising up process isn't anymore a few seconds but a few minutes (5m), and it will keep increasing .
If I look at the operator logs Ill see the 143 error over there.
Do you know something about it ?


Critical security vulnerabilities

I'm not an expert on JS but it is the case of every programming language, that Math.random() is not a cryptographically secure pseudorandom number generator (CSPRNG).
Your encryption key generator is completely insecure.
Once that's fixed, the charset you're using is missing the 'm' and the length is only 16 chars. The current encryption keys have theoretical maximum strength of 61^16 = 94 bits. This is not enough; While it's secure against many crackers, it's not secure against nation states that break crypto. Ensure that the length of key generated by a CSPRNG is at least 43.

Good call. Switching to RFC4122 UUIDS.

I'm not entirely sure the issue is fixed. Your code is now using uuid.v4().
It is said here that uuidv4 also uses math.random().
Please consider using crypto.randomBytes.

The key generation is ran on the client side so we do not have access to the node api without exposing the method. We do not want to transmit the generated passphrase to the server at any point- whether that is creating the key or receiving the key.
The actually uuid.v4 method uses window.crypto.getRandomValues and only falls back to math.random if the client does not support the crypto api.
For v1.1.0 release- we are in works of disabling client browsers who do not support the crypto method.

See this commit for new updates.
We now use the Crypto web API to handle key generation, encryption and decryption. Browsers that don't support this API are prevented from using the app.


Multi-core not being utilized?

I have a 8 vCPUs 30GB Debian instance on the Google Cloud Platform, running the TensorFlow implementation of the WaveNet from https://github.com/ibab/tensorflow-wavenet
I noticed that CPU usage stays around 13%, as if only one of the 8 vCPUs is being used. I have found this issue https://github.com/tensorflow/tensorflow/issues/583 which seems to indicate that such problem should have been fixed.
Any advice on what I need to do in order for all of the vCPUs on my instance to be full utilized in such a case? Thanks!

Is this a TensorFlow problem or a Google Cloud problem? You can tell by
trying to run this model locally and seeing the CPU usage
On Tue, Oct 18, 2016 at 11:08 AM, kaihuchen<EMAIL_ADDRESS>wrote:

I have a 8 vCPUs 30GB Debian instance on the Google Cloud Platform,
running the TensorFlow implementation of the WaveNet from
https://github.com/ibab/tensorflow-wavenet
I noticed that CPU usage stays around 13%, as if only one of the 8 vCPUs
is being used. I have found this issue #583
https://github.com/tensorflow/tensorflow/issues/583 which seems to
indicate that such problem should have been fixed.
Any advice on what I need to do in order for all of the vCPUs on my
instance to be full utilized in such a case? Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/5046, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABaHEUiOQecHfEn_gVDry0gTva65uCFks5q1Qs0gaJpZM4KaHMk
.

You can try the timelines profiler e.g.
http://stackoverflow.com/questions/34293714/tensorflow-can-i-measure-the-execution-time-of-individual-operations/37774470#37774470
Closing for now since it is not clear that it is a bug. You might try asking on StackOverflow since this question is more "how to get good performance on TensorFlow" rather than "TensorFlow is broken." Please reopen if you find that a bug is causing performance to be worse than it should be.


get ui elements from the API rather than hardcoded

some of these are found in config.sample.yml, it might be better to expose them and get them so we don't need to hardcode them in vue

you can put a hold on this for awhile, need to discuss some things related to internal dns

done


Randomize default useragent

https://github.com/Anorov/cloudflare-scrape/blob/master/cfscrape/__init__.py#L17-L27
DEFAULT_USER_AGENTS = [
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36",
    "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36",
    "Mozilla/5.0 (Linux; Android 7.0; Moto G (5) Build/NPPS25.137-93-8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.137 Mobile Safari/537.36",
    "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53",
    "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0",
    "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
]

DEFAULT_USER_AGENT = random.choice(DEFAULT_USER_AGENTS)

A note about adding this: https://github.com/Anorov/cloudflare-scrape/commit/2c9934ad071ffff3333db6153b3083227c65b01c

@pro-src  very good idea!

@codemanki, have you started work on this or can I take it?

To what benefit? Perhaps it would cause cloudflare to identify you as a suspicious actor (and trigger recaptcha)

@Revadike, are you assuming this is done on a per request basis? As this package grows in popularity, using the same user agent for every user could potentially cause cloudflare to identify our users as suspicious actors just because they're using the user agent of this package. It's not uncommon to have a few different devices from the same IP address. If anybody wanted to use a specific user agent string, they could always set the header themselves. Simply said, there aren't any drawbacks of adding this.

Could we maybe put this feature as off by default? I imagine that cloudflare receives so many requests per second, that they won't be blocking the UA that is by default right now.
And sending multiple UA from the same IP might potentially cause some troubles, especially if this behaviour is not explicitly described in the readme which no one would read. I sort of agree with @Revadike  that it might be dangerous to rotate UA at each session

I definitely agree with holding off on it until we get v3.0.0 sorted. This is a library. If you don't want to read the docs then you shouldn't do a major version upgrade. It's the very reason why you perform a major version bump in the first place. I don't have any sympathy for people who neglect to read the docs in this particular case.
About whether or not this would cause problems. This is a fork of Anorov/cloudflare-scrape which is more popular. They introduced this feature 3 years ago in this commit and there has been zero issues regarding this feature. What potential problems are there? I can't think of any. Whether on or off by default. I'm absolutely for this and can't think of a single reason not to be.

@codemanki, so that a +1 for off by default but thats only because I don't want to delay v3.0.0.

@Anorov, do you have any thoughts on this?

@codemanki, the UA blocking is a configuration option for Cloudflare site owners. It's only done on a per-site basis by the site owner. If Cloudflare detects an actual DDOS attack, things might be different. That said, if I happen to suspect that people are using cloudscraper on my cloudflare enabled site (I own one) without my permission, I'd personally configure Cloudflare to block the user agent. Now cloudscraper is completely unusable on my site but my legitimate users (a minority of them) can't access the site either. So rather than blocking them completely, I set the captcha option on by default for that particular agent. However, I won't bother trying to block cloudflare-scrape as I'd have to block more than a few popular user agents. Wait a second... I can use Cloudflare's API to send those UA's captchas whenever my server load is unbalanced. It's highly unlikely that I would ever do any of that because all I really want is the fast CDN + DDOS protection. Then again, maybe I'm cheap and need to cut down on server bills. Who knows... The point is that this isn't going to be a real problem for 99% of the people that are going to use cloudscraper and if user agent related blocking is enabled, it's going to be worse if tied to a single UA.

https://github.com/codemanki/cloudscraper/issues/62

This comment by @Anorov is relevant. Who seems to have unsubscribed... Maybe he is jelly? :laughing:


chore: degen frame fix

PR-Codex overview
This PR updates the redirection URL in the useEffect hook from /mint to /degen in the mint.tsx file.
Detailed summary

Updated the redirection URL in the useEffect hook from "/mint" to "/degen" in mint.tsx

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

📝 Changed routes:

/frame/degen/mint

(view full size)

Commit 8379a23c4915c9211496ec640c8496348a6cc594 (https://thirdweb-26dnhw996.thirdweb-preview.com).


CRAYSAT-1587: Document sat jobstat command

Add sat jobstat to "sat dependencies" table.
Add sat jobstat to table describing sat authentication types.

Summary and Scope
See commit message
Issues and Related PRs

Part of CRAYSAT-1587

Pull Request Checklist

[X] Version number(s) incremented, if applicable
[X] Copyrights updated
[X] License file intact
[X] Target branch correct
[X] CHANGELOG.md updated
[X] Testing is appropriate and complete, if applicable
[X] HPC Product Announcement prepared, if applicable

Looks good to me, it seems the link checker is failing for reasons irrelevant to the contents of this PR. It might be good to patch that on integration and then merge this, IMO.

I think that issue might be going away on its own very soon, actually. It's failing to reach the URL for the getting started guide: https://www.hpe.com/support/ex-S-8000
As I understand it the GSG will be getting published any day now.

Looks good to me, it seems the link checker is failing for reasons irrelevant to the contents of this PR. It might be good to patch that on integration and then merge this, IMO.

I think that issue might be going away on its own very soon, actually. It's failing to reach the URL for the getting started guide: https://www.hpe.com/support/ex-S-8000
As I understand it the GSG will be getting published any day now.

@ekamin-hpe, yes, I expect to update that URL likely tomorrow.


Unable to connect to Arduino Nano 33 IOT

Hello,

I am trying to connect my Arduino Nano 33 IOT to the console, but I am unable to do so. Please provide exact instruction + code.
I have connected ESP32 without any problem.
I would like to connect by IOT devices to my mobile phone via BLE. Are you supporting this option?

Please follow the README instructions, this repository contains the full code example.
BLE is used for device provisioning/activation only. After that, the device connects to the cloud directlyover WiFi (or Ethernet, Cellular in some cases)

I am using Arduino IDE 2.1.1 and can not replace it.
I have installed BlynkMcpDriver and used the only example. I have replaced Template ID and name that I generated from the Console, but it is not working.
Do you have specific example for Arduino Nano 33 IOT using Arduino IDE?

There is no direct example for BlynkNcpDriver on  Arduino Nano 33 IOT, and probably it's not what you need.
Please install the latest Blynk library from Arduino Library Manager (v1.3.0), and you will be able to use the
Blynk -> Blynk.Edgent -> Edgent_NCP example.
However, you will have to figure out a way to flash the NINA module on Arduino Nano 33 IOT with Blynk.NCP.
This is not trivial, and this PlatformIO example automates it for you.

Was this resolved?

No it was not.
I was surprised that the NCP is not working for Nano IOT. I thought that
this was its purpose.
However, working with ESP32 seems to be working fine.
My next generation PCB will be with ESP32 and I will give it another try
then
On Mon, Jul 31, 2023 at 2:33 PM Volodymyr Shymanskyy <
@.***> wrote:

Was this resolved?
—
Reply to this email directly, view it on GitHub
https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1658193912,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAPVPKEJPLLBFKIC54LIDYTXS6JYNANCNFSM6AAAAAA2XTCLO4
.
You are receiving this because you authored the thread.Message ID:
@.***>

It is verified to work on Nano 33 Iot.

the example on the Arduino IDE does not work for me
On Tue, Aug 1, 2023 at 9:31 AM Volodymyr Shymanskyy <
@.***> wrote:

It is verified to work on Nano 33 Iot.
—
Reply to this email directly, view it on GitHub
https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1659653222,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAPVPKGFGYGG4VXVCGQJF5LXTCPEPANCNFSM6AAAAAA2XTCLO4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Sorry, but "the example doesn't work" description is not enough to
understand.
On Tue, 1 Aug 2023, 09:38 Tal-Mo, @.***> wrote:

the example on the Arduino IDE does not work for me
On Tue, Aug 1, 2023 at 9:31 AM Volodymyr Shymanskyy <
@.***> wrote:

It is verified to work on Nano 33 Iot.
—
Reply to this email directly, view it on GitHub
<
https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1659653222>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/BAPVPKGFGYGG4VXVCGQJF5LXTCPEPANCNFSM6AAAAAA2XTCLO4>

.
You are receiving this because you authored the thread.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1659661418,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALP3FA5AT6SCYOQTVRMJVDXTCP77ANCNFSM6AAAAAA2XTCLO4
.
You are receiving this because you commented.Message ID:
@.***>

"However, you will have to figure out a way to flash the NINA module on
Arduino Nano 33 IOT with Blynk.NCP.
This is not trivial, and this PlatformIO example automates it for you."
I am working with Arduino IDE, not PlatformIO, and the example in Arduino
does not provide connection.
On Tue, Aug 1, 2023 at 9:43 AM Volodymyr Shymanskyy <
@.***> wrote:

Sorry, but "the example doesn't work" description is not enough to
understand.
On Tue, 1 Aug 2023, 09:38 Tal-Mo, @.***> wrote:

the example on the Arduino IDE does not work for me
On Tue, Aug 1, 2023 at 9:31 AM Volodymyr Shymanskyy <
@.***> wrote:

It is verified to work on Nano 33 Iot.
—
Reply to this email directly, view it on GitHub
<

https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1659653222>,

or unsubscribe
<

https://github.com/notifications/unsubscribe-auth/BAPVPKGFGYGG4VXVCGQJF5LXTCPEPANCNFSM6AAAAAA2XTCLO4>

.
You are receiving this because you authored the thread.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
<
https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1659661418>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AALP3FA5AT6SCYOQTVRMJVDXTCP77ANCNFSM6AAAAAA2XTCLO4>

.
You are receiving this because you commented.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1659667178,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAPVPKFW2RY65HR5VO3XE2DXTCQS5ANCNFSM6AAAAAA2XTCLO4
.
You are receiving this because you authored the thread.Message ID:
@.***>

So, this PlatformIO example allows you to run NCP on Nano 33 IoT in 2 simple steps:

Flash NCP: pio run -e nano33iot -t upload_ncp
Flash main MCU: pio run -e nano33iot -t upload -t monitor

There are currently no instructions on how to do that without PlataformIO.

I understand.
Since I am not going to change my IDE for this issue, I will check how we
can work in the future with ESP32.
On Tue, Aug 1, 2023 at 1:40 PM Volodymyr Shymanskyy <
@.***> wrote:

So, this PlatformIO example allows you to run NCP on Nano 33 IoT in 2
simple steps:

Flash NCP: pio run -e nano33iot -t upload_ncp
Flash main MCU: pio run -e nano33iot -t upload -t monitor

There are currently no instructions on how to do that without PlataformIO.
—
Reply to this email directly, view it on GitHub
https://github.com/blynkkk/BlynkNcpExample/issues/6#issuecomment-1660047805,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAPVPKBFRAI3GZQUODI6J2TXTDMI5ANCNFSM6AAAAAA2XTCLO4
.
You are receiving this because you authored the thread.Message ID:
@.***>


Fix target embedding?

Hi, I want continue training on a trained model with the target embedding fixed. I drop this parameter /decoder/sequencegenerator/readout/lookupfeedbackwmt15/lookuptable.W from the parameters passed to GradientDescent. I wonder if this is correct please? Thanks!

It is correct, assuming that you means the embeddings if output words that are fed back to the network.


Great utility, just have a question on how to exclude PropTypes from react?

With the latest versions of React, {PropTypes} from 'react' is deprecated and should be pulled from the prop-types package, eg: import PropTypes from 'prop-types'.
Any ideas on how to get around this?  I didn't see any of the config options that could address this?
Willing to help as well 👍

Handle deprecated package is difficult for this extension. And I think how to import PropTypes from 'prop-types' is more useful. Actually you can add prop-types in package.json, so the extension will find  two packages of 'PropTypes'. (be care of the version of prop-types when you install 'prop-types'). See config node_modules-support

Yep this helps thanks so much!


fix: chunk history desyncing from actual state of loaded chunks

This PR fixes an issue with the player auto chunk loader where chunks would be marked as loaded but never marked as unloaded.
This bug can be reproduced by:

Enabling automatic chunk loading
Adding code to unload chunks within the events provided by the Player class

Expected behaviour (should also be provided by this patch):

A chunk that has been unloaded due to exiting a player's view distance is able to be reloaded when the player goes near it again.

Actual behaviour:

Loading, unloading, and then attempting to load again any given chunk with a player will fail when trying to reload the chunk after an unload.

Upon further inspection it seems like the system causing this issue is entirely unnecessary (at least in my opinion) so I've removed all of the code related to it.
If anyone still believes there is a use for delaying chunk reloading after unloading chunks, it should be replaced with a better implementation as the current one would have worked strangely with low render distances (and doesn't work as intended currently).


I got 'float point exception: core dumped' transforming pics of short cols.

Setting the width to 12 still works.  If you want to further decrease the width, please use Augment.GenerateDistort(im, 2) instead of Augment.GenerateDistort(im, 4). But I recommend larger size of images. You may have better transform results. @Cancerce1l


Stub method being overshadowed by module

With the new PyTorch type stubs (https://github.com/pytorch/pytorch/pull/12500),  the stub for the tensor method seems to not be utilized by intellisense (example below). I think this is related to the existence of a module called tensor.py in the PyTorch package - if I delete that file, then the stub is utilized. Maybe the language server is somehow getting confused between whether torch.tensor should be inferred to refer to the module or the method defined in the stub. In this case, it should refer to the stub.
The stub for tensor indicates it has a Tensor return type, but we see vscode not showing Tensor methods here:

Meanwhile the similar as_tensor method, which has the same return type, is working:

Here are the stub definitions:
def tensor(data: Any, dtype: Optional[_dtype]=None, device: Union[_device, str, None]=None, requires_grad: bool=False) -> Tensor: ...

def as_tensor(data: Any, dtype: _dtype=None, device: Optional[_device]=None) -> Tensor: ...

I don't have a minimal example at the moment. PyTorch is a big package and in my simple attempts to reduce the problem to a minimal version, VSCode did the right thing, so it's hard for me to tell what exactly is going wrong.
This is with Python 3.7, extension version 2019.5.5433 and VSCode 1.31.1.

I'm checking this against the LS in master (very different than the released one) which does a much better job with stubs, and can at least do:

However, neither torch.tensor nor torch.as_tensor are things which appear in the tensor module's __all__ list, which means that they aren't being exposed:
__all__ = [
    'typename', 'is_tensor', 'is_storage', 'set_default_tensor_type',
    'set_rng_state', 'get_rng_state', 'manual_seed', 'initial_seed',
    'save', 'load', 'set_printoptions', 'chunk', 'split', 'stack', 'matmul',
    'no_grad', 'enable_grad', 'rand', 'randn',
    'DoubleStorage', 'FloatStorage', 'LongStorage', 'IntStorage',
    'ShortStorage', 'CharStorage', 'ByteStorage',
    'DoubleTensor', 'FloatTensor', 'LongTensor', 'IntTensor',
    'ShortTensor', 'CharTensor', 'ByteTensor', 'Tensor',
]

https://github.com/pytorch/pytorch/blob/master/torch/__init__.py#L19
Are you on a different version of Torch which exposes those functions? I'm testing with:

Python 3.7, venv
pip installed Torch 1.0 non-CUDA version from: https://pytorch.org/get-started/locally/

Oh. Gross.
from torch._C import *

__all__ += [name for name in dir(_C)
            if name[0] != '_' and
            not name.endswith('Base')]

Thanks for looking into this!
Ya, it's because of dynamic code like that that a type stub was added to aid code completion. You'll see a __init__.pyi in the 'torch' package folder, and that stub explicitly declares a def tensor(...).
I opened this issue because I thought the language server would use the information in the stub, and it does seem to with the exception of the tensor method. It's on the nightly pytorch that I see as_tensor is being suggested as a completion while tensor is not, despite them both being in the stub file.
I installed the nightly with pip install torch_nightly -f https://download.pytorch.org/whl/nightly/cpu/torch_nightly.html.

The version of torch I have installed doesn't have those two functions in the stub, so I'll have to switch up and see. With some __all__ filtering removed, I can see loads of Torch functions already.
Just to say so, the visual difference between -> Torch and -> 'Torch' is visual only; the tooltips in the new language server are essentially copies from the declaration to the output, but the analysis itself parses out the string and does something with it.

Alright, testing with the nightly build of torch:

I'm going to close this issue, as it's working as expected in the new LS (which should be released into daily and beta soon).

Perfect, thanks.
On Wed, Mar 6, 2019 at 1:41 PM Jake Bailey<EMAIL_ADDRESS>wrote:

Closed #690
https://github.com/Microsoft/python-language-server/issues/690.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/python-language-server/issues/690#event-2185484857,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA8Svalw-rMq8ib89vt27h5GV-nVYyFqks5vUDYQgaJpZM4bapYE
.

0.2.16 is now available on beta channel. You can set this in your VS Code settings.json to get it:
"python.analysis.downloadChannel": "beta"

Confirmed that switching to the beta channel fixes things on my end too.


[WIP] solaris/illumos support.

:umbrella: The latest upstream changes (presumably #3260) made this pull request unmergeable. Please resolve the merge conflicts.

@devnexen what is the status of this PR? You opened it as a draft, so I assume you are not currently looking for feedback. If you don't plan to work on it in the near future, it'd be better to close the PR -- this way the open PRs reflect things that people are actively working on. We can always reopen when you have time to get back to this!

:umbrella: The latest upstream changes (presumably #3436) made this pull request unmergeable. Please resolve the merge conflicts.

marked this pull request as ready for review

Was this meant to ask for review? Github doesn't seem to send notifications on this event, so I missed this -- sorry. In the future, please just post a comment when a PR is ready. You can write @rustbot ready to automatically update the labels as well.

Also, after rebasing, please add solaris/illumos to the unofficial target list in the README and set yourself as maintainer.

Looks like something changed in std, and pthread_condattr_init is now required to make it into main.

Looks like something changed in std, and pthread_condattr_init is now required to make it into main.

Or, rather, previously only no_std was tested so the pre-main code was not even executed.
I think the PR should be adjusted to add only what is needed for main. getentropy, getrandom, threadname... those are all nice things to have eventually, but we have to walk before we can run.
The goal should be for MIRI_TEST_TARGET=x86_64-unknown-illumos ./miri test vec to pass.

Looks like something changed in std, and pthread_condattr_init is now required to make it into main.

Do I need to implement something in particular to fix the out-of-bounds issue ?

That looks like the pthread offsets don't work for Solarish.
This seems to be a mutex, so this is the relevant comment:
https://github.com/rust-lang/miri/blob/baf32fd5c019785c26836145a4b0eca54326217c/src/shims/unix/sync.rs#L61-L68
It looks like something else is writing to the field that Miri uses to store the MutexId, and then Miri doesn't deal well with the invalid MutexId.

Ah no, it's not something else writing... the problem is the layout needs to be compatible with the PTHREAD_MUTEX_INITIALIZER. For Solarish that's defined here. This is the type declaration:
    pub struct pthread_mutex_t {
        __pthread_mutex_flag1: u16,
        __pthread_mutex_flag2: u8,
        __pthread_mutex_ceiling: u8,
        __pthread_mutex_type: u16,
        __pthread_mutex_magic: u16,
        __pthread_mutex_lock: u64,
        __pthread_mutex_data: u64
    }

All of the fields Miri needs need to be initialized to 0. However, bytes 4-7 (where we store the Mutex ID) contains this __pthread_mutex_magic field that is not zero-initialized.
So we'll need to pick a different offset for the Mutex ID on solarish. The offset is currently duplicated in mutex_get_id and mutex_reset_id; the 4 there needs to become something else on solarish. It looks like 0 should work.

cool with your suggestion changes vec tests pass now.

Almost there. :)  There's something wrong with the signature of pthread_join... I assume pthread_t has a different size on this platform than on others. We usually assume it is usize, but on Solarish it is u32.
So here
https://github.com/rust-lang/miri/blob/af37aca6c05e13afa0acfbed53bda24dea8b7526/src/shims/unix/thread.rs#L45
you need to us something like this instead
let thread_id = this.read_scalar(thread)?.to_int(this.libc_ty_layout("pthread_t").size)?;

Also, is it possible there's something wrong with your system clock? Your commits show up as coming 20-50minutes from the future...^^

Ah, Solaris in std has support for the stack guard, which seems to be disabled on illumos. That calls a bunch of very platform-specific functions (see this file).
This can be quite the rabbit hole of little functions that need to be added -- usually with stubs like this that don't actually do anything.
It's up to you whether you want to add that, or restrict the PR to illumos.

You will probably have to extend this hack to also allow solaris, not just macos:
https://github.com/rust-lang/miri/blob/10e8bb87fe416bc190426789032594aa1aa311f2/src/shims/unix/mem.rs#L47-L49

Great, thanks!
@bors r+

:pushpin: Commit de5464233a0e430943a9e886817efefe81f72e90 has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit de5464233a0e430943a9e886817efefe81f72e90 with merge 8528cc6dd0ee5ea6712eb46778e305096acc09ea...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing 8528cc6dd0ee5ea6712eb46778e305096acc09ea to master...


Content report popup doesn't close

Description
If you open the content report popup for an image and send a mature content report, you can sometimes close the popup once, but if you reopen it it doesn't reset back to the original state of the popup and you can now no longer close it.
Reproduction

Go to an image (like /openverse/photos/03917307-e9d9-4a7d-9607-955230e19a87)
Click the "Report this content" link underneath it
Select the option to report mature content and hit next until you see the thank you notice
Click the X in the upper corner to close the popup

Expectation
Clicking the X in the corner or elsewhere on the page outside the popup should close it always. When it is closed, it should also reset back to the original state.
Additional context
There are no console errors
Resolution

[ ] 🙋 I would be interested in resolving this bug.

Fixed in #561


Create ByteBuffer from existing ArrayBuffer?

This is probably a silly question, but how can I initialise a ByteBuffer instance from an existing ArrayBuffer? Thanks

Seems you are looking for: https://github.com/protobufjs/bytebuffer.js/wiki/API#bytebufferwrapbuffer-encoding-littleendian-noassert

Thanks - I tried that but I couldn't get it to work. Let me try again.

I tried this:
a = new Uint8Array([0,1,2,3,4,5,6,7])
b = new dcodeIO.ByteBuffer(a.buffer)
b.readByte()
bytebuffer.js:568 Uncaught RangeError: Illegal offset: 0 <= 0 (+1) <= 0

b = new dcodeIO.ByteBuffer(a)
b.readByte()
bytebuffer.js:568 Uncaught RangeError: Illegal offset: 0 <= 0 (+1) <= 0

I'm just starting out with working with binary data in JS, so my understanding may be lacking.
Thanks


Alternatives to Google Activity recognition

Since Google Activity Recognition causes (for the moment) unresolvable errors, we investigate alternatives to it.

[ ] Try and evaluate Pathsense Awsome Activity

Test app configured, on the first look it looks fine.


Use ament_target_dependencies to link boost_program_options

find_package(Boost) may pass file paths for Boost libraries which may not be present in the default search locations at link time, so target_link_libraries(... boost_program_options) may not always work.
Since FindBoost.cmake sets Boost_<C>_FOUND and Boost_<C>_LIBRARIES for each requested component, we can let ament_target_dependencies() discover the component as if it were a standalone package.
https://github.com/Kitware/CMake/blob/efa30023b4056a4c17e80d7a86bc2506660c68a7/Modules/FindBoost.cmake#L30-L32

LGTM, thanks!


Company Details | View Company Details |5|

https://trello.com/c/8BgShHzt/651-company-details-view-company-details-5
Information:
This card is for the development of the company details page for the v0.3.0 release.
Please see the attached screenshot for proposed content & layout.
If possible, set the default number of rows to 5 for the Users table.
Need to find out how we can get their corporate address. Siteminder preferred, but Branch has this info as well.
Demo:
Show the company details page for at least two companies (TFRS BCeID accounts)
Show that the company details page is not visible to IDIR users

 Company Details | View Company Details |5|


Copy not working in chrome version 72

Nothing is getting copied to the clipboard in the latest version of chrome. Silent error.

same here

Same here

Fixed and released as 3.0.0.


Fix Issue 21869 - Invalid hyperlink to doxygen

Python link was also dead, linked to rust instead.

Please retitle the commit message "Fix issue 21869: Invalid hyperlink to doxygen" as I'm assuming this fixes that issue


feat: Add dig function

What

Add a dig function that can be used to verify DNS resultion inside a
cluster. The function is implemented as a small bash script that
invokes dig and then returns the result as JSON or text, depending
on an ENV configuration. This function can also be used to demonstrate
how to lightly wrap the CLI tool and provide some logging to stderr

To test
$ faas-cli build --filter dig
$ docker run --name digtest --rm -p 8080:8080 ghcr.io/openfaas/dig:latest
$ curl localhost:8080 -d "google.com"
{"ip_address": "<IP_ADDRESS>"}
$ docker kill digtest

Signed-off-by: Lucas Roesler<EMAIL_ADDRESS>

@alexellis i think i need a little to understand why the Docker login is failing?


GNOME is their official project name and all lowercase seemed ugly in its own way...

We're capitalizing all the words in these cases ("The ... Project Developers") to make it look super important :). In a usual text it might just be 'rust-gnome'.

I don't have any preference on that so let's say we'll keep it that way. Thanks for the "making it look super important" ! ;-)


updated test audit events

This change is no longer required. Alias should not exist for this type of engagement.


Is Torque3D dead?

Sorry to ask this, out of nowhere, but we all can see that there's no active development for long time and that makes me suspect that the project has been abandoned.
I want to give TGE a try, but things are kinda awkward.

The community moved the repository to https://github.com/TorqueGameEngines/Torque3D because we couldn't get full rights to this repository, as in couldn't add more maintainers, as GarageGames is effectively dead.

dead  vs. popular
UltraBurstXD,   with game engines such as Unreal, Unity, and Godot that can publish to the consoles, it would seem that  T3D is abandoned.  However it still has merit, especially if you like programming FPS games.  Early in its development cycle, Garagegames did support console and Apple iphone development, of which I hope someone can bring back.  (The capabilities are beyond my expertise).   Like you, I prefer the TGE engine over the later T3D. I am currently producing YouTube videos about my experience with it at Crazy Scorpion GameDev Diaries.  Let me know what you need to know about TGE  at<EMAIL_ADDRESS>for now until YouTube allows comments on my channel.  Mention this github chat so I'll respond.


Windows binary

Dear @rofl0r, could you be so kind to compile *.exe for Windows 7 x64? I assume it's easier for you, the developer, to do this than it is for me, the user, who simply wants to learn more about comparing binaries, not about the intricacies of compiling.

have fun: https://github.com/rofl0r/haxdiff/releases/download/v1.1/haxdiff-1.1-win32.zip
it's win32, but there's no point in having different 32 vs 64 bit builds for such a simple program.

oh. ouch. actually there's one reason. 64 bit offsets, and the compiler i use (PellesC) in its last 32bit version supported only 32 bit off_t, meaning only 2 gb files are supported at a max. and i just noticed the binary has a bug in this regard. will upload a fixed version in a few moments...

ok, issue found, was unrelated to 64 bit off_t.: https://github.com/rofl0r/haxdiff/compare/v1.1...master
i updated the zip in the above link with the fixed exe

so, let me know if you encounter any issues. if you need support for files > 2GB, it just requires a recompile with another compiler (cygwin, pellesc 64, openwatcom, mingw should all work). but i guess this version should be sufficient for your evaluation purpose. note that you will need stdin/out redirection to apply and create patches, respectively (haxdiff d a.rom b.rom > rom.diff ; haxdiff p a.rom b.rom < rom.diff

@rofl0r, thank you for a quick reply.
I immediately rushed to test this app with small (1 MB) and relatively large binary files (200 MB). I have not the most modern laptop, nevertheless the program works fast and does not give problems to other apps.
Being spoiled by the convenience of other patch generators such as Courgette, Hdiffz, JojoDiff, Xdelta and Zstandard, which use three arguments (source, target, patch), it took me a while to get used to the fact that the output should be done via ... > my.patch, and the input via type my.patch | ... It might be worth adding a mention to the help screen, since not everyone is familiar with stdin and stdout.
I also noticed that the highlighting doesn't work with some apps such as delta, because diff the format is not fully respected, namely the trailing @@ is missing.

readme.md says, '…can optionally verify that the file to be patched matches the patch`, but I see no switch to do that or to know more about that. What does it mean?

p option verifies, P option ignores difference.

It might be worth adding a mention to the help screen, since not everyone is familiar with stdin and stdout.

yeah, i didn't think about windows users so far, but i should - this program was designed to replace IPS and similar patches on sites like romhacking.net.

I also noticed that the highlighting doesn't work with some pager apps like Delta, because diff the format is not fully respected, namely the trailing @@ is missing.

yeah, i'm aware that not at all editors/pagers have syntax highlighting for diffs/patches, especially windows-centric ones. but there's nothing i can do about it. it's dead simple though. put - lines in red, + ones in green, and voila.

type my.patch | ...

wait, windows doesn't support < operator ?

but there's nothing i can do about it.

You can add a missing @@.
At present we have
haxdiff/1.0
@@ b02,-4,+4
- 0f851f03
+ e9200300

But it is expected to be as follows (according to Wikipedia and those pagers):
haxdiff/1.0
@@ b02,-4,+4 @@
- 0f851f03
+ e9200300

But it is expected to be as follows (according to Wikipedia and those pagers):

ah, i understand now. can be added easily, but i need to think about whether it needs a format revision.

@sergeevabc i updated the binary in the above link with one compiled with mingw and proper 64 bit offset support, so it should work with any files you throw at it. the @@ issue will be adressed promptly, but not today.

Wow, you managed not only to make it better, but to reduce the binary size by 50% as well (42496 vs 20992 bytes). A high-energy delight that is unlikely to be understood by zoomers with their Electron-based monsters.