Current implementation is unsound. Segfault and double free are possible with out-of-sync maps from a bad PartialEq implementation.

So basically, the current implementation seems to rely on the PartialEq implementation of a value for removing it. This is totally unsafe for the very same reasons why retain is unsafe: You cannot guarantee that the PartialEq implementation gives the same result on two seperate calls with the same arguments.
use std::sync::atomic::{AtomicBool, Ordering::SeqCst};
static SNEAKY: AtomicBool = AtomicBool::new(false);

#[derive(Eq, Hash)]
struct Sneaky(Vec<u8>);
impl PartialEq for Sneaky {
    fn eq(&self, other: &Self) -> bool {
        if SNEAKY.swap(false, SeqCst) {
            false
        } else {
            self.0 == other.0
        }
    }
}

fn main() {
    let (_, mut w) = evmap::new::<u8, Box<Sneaky>>();
    w.insert(0, Box::new(Sneaky(vec![0])));
    w.refresh();
    w.remove(0, Box::new(Sneaky(vec![0])));
    SNEAKY.store(true, SeqCst);
    w.refresh();
    w.refresh();
    w.refresh();
}

$ cargo run
   Compiling evmaptest v0.1.0 (/home/frank/[...]/evmaptest)
    Finished dev [unoptimized + debuginfo] target(s) in 0.78s
     Running `target/debug/evmaptest`
[1]    30645 segmentation fault (core dumped)  cargo run

Change to struct Sneaky(u8); and Box::new(Sneaky(0)) and you get
free(): double free detected in tcache 2
[1]    31123 abort (core dumped)  cargo run

instead.

Since Rust doesn’t have (and won’t have anytime soon) an effects system, we cannot guarantee “pure” implementations for e.g. PartialEq on the values type. I guess the only way to fix this is to make sure that the equality check happens only once, and then e.g. some kind of raw index into the bag is determined and stored into the op-log. That index only is then used for removing the same value from the other map.
I’m not familiar with the implementation details of this crate as to assess if this is possible and how hard of a change this would be but it seems like some nontrivial changes are needed. I’d suspect that PartialEq implementations (and perhaps also the Hash implementation?) of both the keys and the value type might be able to cause problems (I haven’t tested the behavior of the map for bad/sneaky key types yet though).
Also, @jonhoo I wanna say thanks for the great coding streams.

A bit of testing shows that this exact code can produce a segfault on every version starting from version 5. I only tested the latest minor versions, i.e.: 5.1.1, 6.0.1, 7.1.3, 8.0.1, 9.0.1, 10.0.2, 11.0.0-alpha.1; as well as 5.0.0 and the current master and left-right branches.

This code variation
use std::sync::atomic::{AtomicBool, Ordering::SeqCst};
static SNEAKY: AtomicBool = AtomicBool::new(false);

#[derive(Eq, Hash, Debug)]
struct Sneaky(Vec<u8>);
impl PartialEq for Sneaky {
    fn eq(&self, other: &Self) -> bool {
        if SNEAKY.swap(false, SeqCst) {
            false
        } else {
            self.0 == other.0
        }
    }
}

fn main() {
    let (r, mut w) = evmap::new::<u8, Box<Sneaky>>();
    let dbg = || r.get_and(&0, |vs| {
        println!("{:?}", vs);
    });
    w.insert(0, Box::new(Sneaky(vec![0])));
    w.refresh();
    w.remove(0, Box::new(Sneaky(vec![0])));
    SNEAKY.store(true, SeqCst);
    w.refresh();
    r.get_and(&0, |vs| {
        println!("{:?}", vs);
    });
    w.refresh();
    w.refresh();
    r.get_and(&0, |vs| {
        println!("{:?}", vs);
    });
}

leads to segfault on 2.0.0, 2.0.2, 3.0.1, 4.2.3. (and probably every other version 2-4 as well).
Version 1.* didn’t have ShallowCopy yet, so it probably should be fine.

Ouch, yeah, that's quite the bummer. I honestly don't know of a good way to work around that beyond encoding a bunch of additional information in the oplog in apply_first that lets you repeat the exact same operation in apply_second without relying on the determinism of PartialEq. I actually worry more about Hash than I do about PartialEq, since we're going to need raw entry APIs for both HashMap and HashBag to make it work, and even that might not be enough.
I'll have to do some thinking about this... It may be that the "solution" is to make the whole thing unsafe, though that's obviously not great either. Hmm hmm hmm...

One option is to make evmap::new and friends unsafe. It's pretty ugly, but there may be no good way around it...

Another option is to have an unsafe marker trait,
pub unsafe trait ConsistentHashEq: Hash + Eq {}

That way you can keep new safe, and only allow types which provide a nice Hash + Eq implementation. You can also provide a derive so that downstream users don't need to write unsafe in the common case.

@RustyYato Unfortunately that won't quite work. Hash and Eq should already be deterministic. The challenge is if someone doesn't follow that contract, and that's beyond your control or knowledge. The same problem would apply to ConsistentHashEq. It would perhaps push an issue more into the realm of the malicious, but it would be a way to circumvent safety nonetheless.

Hash and Eq should already be deterministic. The challenge is if someone doesn't follow that contract, and that's beyond your control or knowledge.

Yes, ConsistentHashEq is unsafe to implement, so ot puts the burden of proof on the type to ensure that it is correctly implementing Hash and Eq. If they don't follow the contract, then they have written unsound unsafe code, which you don't have to account for.
This has the nice benefit that you can provide a completely safe interface, if you also provide a derive macro, and implementations for std types
Note: using unsafe traits to ensure properties of other traits is something the std does. See TrustedLen for iterators. It enables a variety of optimizations that are only valid if size_of is correct. If size_of is incorrect and you implement TrustedLen, you will get UB.

Hmm, I'm worried about saying "it's up to the implementors of the trait", since the unsafety is then still hard to discover — if someone implements ConsistentHashEq maliciously in their crate, and then someone else relies on that crate, they now have unsound behavior with no unsafe code in their crate. Maybe that's fine, but it feels weird. The precedent from the standard library is good though.
The other downside of this is that it introduces the a trait requirement on keys and values that implementors do not have control over. For example, if someone wants to have their keys or values be bytes::Bytes, they now need to create a newtype and derive the trait for that. It's ShallowCopy all over again, except also for keys. A derive helps, but not a lot, since it doesn't take care of the newtype case (as the inner type would not implement TrustedHashEq).
Ultimately, if users have to either unsafely implement TrustedHashEq or the call to evmap::new is unsafe, I'm inclined to say that having new be unsafe is more ergonomic. It means you only have to check the safety in the place where you instantiate the map, and you don't need any newtypes or additional trait implementations in evmap itself.

if someone implements ConsistentHashEq maliciously in their crate, and then someone else relies on that crate, they now have unsound behavior with no unsafe code in their crate. Maybe that's fine, but it feels weird. The precedent from the standard library is good though.

That’s how unsafe code and inparticular unsafe traits work. If a library author creates an unsafe impl that violates the contract of ConsistentHashEq (i.e. Hash or Eq is not deterministic) then that unsafe code is "unsound". It is not undefined behavior in and by itself but it allows for other, unsafe-free code to trigger undefined behavior. Some also call this "library-UB", as in, the rust-evmap library defines that non-conforming ConsistentHashEq implementations can lead to undefined behavior. "library-UB" in contrast to "compiler-UB" which is when some code directly violates safety contracts that the compiler imposes (e.g. dereferencing an invalid memory address or reading a u8 from uninitialized memory).

if someone wants to have their keys or values be bytes::Bytes, they now need to create a newtype and derive the trait for that. It's ShallowCopy all over again, except also for keys.

True. That’s a general problem with new traits from not super-popular crates (like e.g. serde).

A derive helps, but not a lot

I’m no expert in derive macros, but I guess a derive for ConsistentHashEq would need to both make sure that the same type also derives Eq and Ord (if something like this is possible) and it has to ensure that all the type’s fields are ConsistentHashEq as well (e.g. with generic bounds on generic type parameters). This can mostly only help users of evmap to safely derive ConsistentHashEq for their custom structs made up of standard library types (and perhaps newtypes with unsafe implementations as above). The newtypes are not very ergonomic, as you said:

Ultimately, if users have to either unsafely implement TrustedHashEq or the call to evmap::new is unsafe, I'm inclined to say that having new be unsafe is more ergonomic. It means you only have to check the safety in the place where you instantiate the map, and you don't need any newtypes or additional trait implementations in evmap itself.

But do note that the ConsistentHashEq solution does not preclude the "unsafe new" solution. One can simply offer two functions for constructing, a safe new with a ConsistentHashEq bound and using the DefaultHasher hasher, and another (yet to be named better) new_asserting_consistency function that’s unsafe and only needs Hash + Eq. Furthermore, the with_hasher construction has to be unsafe anyways, since otherwise the Hasher itself (or the BuildHasher) could be non-deterministic. (Unless we want marker traits for something like ConsistentBuildHasher, too.)

Yeah, I agree it meets the requirements, or maybe expectations, for how safety works in Rust. I'm more trying to think about how users may be surprised by unsoundness. And "another crate lied" and now I have a safety error in code that looks like it's completely safe (unless the user specifically thinks to look up the definition of ConsistentHashEq). It just seems less likely to cause surprise to me if new (and with_hasher) are unsafe — "huh, these are unsafe, let me check why, oh, that's easy". Not to mention it allows us to forego a new trait, implementations for a tonne of standard library types, and a derive macro.
To me, the argument for why not to make new unsafe is that it means users do not have to write unsafe { } in their code, and that's more or less it. I agree that in general that's a good thing to reach for, though in this case it feels like a red herring. Sure, they don't have to write unsafe { }, but they still have to think about unsafety in the form of the implementations of TrustedHashEq that they rely on. And that, I think, is easier to miss.
There is perhaps an argument for "library authors are more likely to know if their operations are deterministic than the users of those libraries are", and that's valid, except that it relies on lots of library authors adding dependencies on evmap and adding an implementation of TrustedHashEq, which seems unlikely to happen. Instead, pretty much all users that go outside the standard library for their types will have to use the newtype pattern.

[...] but they still have to think about unsafety in the form of the implementations of TrustedHashEq that they rely on. And that, I think, is easier to miss.

No, only the implementors have to think about the implementations of TrustedHashEq, the users of evmap::new don't.

[...] except that it relies on lots of library authors adding dependencies on evmap and adding an implementation of TrustedHashEq, which seems unlikely to happen. Instead, pretty much all users that go outside the standard library for their types will have to use the newtype pattern.

That's true, a nicer solution would be to have some sort of common crate that would provide traits like these, but I don't think such a crate exists right now. Do you know if your users need to depend on types outside of what they define and std?

[...] but they still have to think about unsafety in the form of the implementations of TrustedHashEq that they rely on. And that, I think, is easier to miss.

No, only the implementors have to think about the implementations of TrustedHashEq, the users of evmap::new don't.

Ah, I think we've gotten to the crux of the issue. I completely agree that technically that is true. That is, technically the onus is on implementors of the trait to get it right. But, if you run evmap::new and the types you use are foreign, you really ought to go check the implementation to see that it is not malicious, otherwise you will introduce a soundness issue in your code. I suppose it's true in general that you have to trust the unsafety in all of your dependency, but this one just seems particularly egregious. But maybe I'm just overly paranoid?
In some sense, another argument here is that Hash and Eq should always be deterministic. It's sort of in their contract. So why require the unsafe intermediate trait at all? What does it change in terms of the trust model for whether your code is sound? It feels like all the unsafe trait really does is (trivially) satisfy the requirement that you cannot have unsoundness from only safe code, without actually giving any more guarantees than Hash + Eq already should give.
Which then brings me back to: why is this nicer than making new unsafe?

[...] except that it relies on lots of library authors adding dependencies on evmap and adding an implementation of TrustedHashEq, which seems unlikely to happen. Instead, pretty much all users that go outside the standard library for their types will have to use the newtype pattern.

That's true, a nicer solution would be to have some sort of common crate that would provide traits like these, but I don't think such a crate exists right now.

No, such a crate doesn't exist, and even if it did, chances are you'd never want to depend on it. It would have to add every other crate as a dependency to implement the trait for those types, so it would be hugely expensive to have as a part of the build graph.

Do you know if your users need to depend on types outside of what they define and std?

Hard to say, but I'd be inclined to say that this is a common use-case for a collection type. We've seen people in issues on this repository ask for support for both bytes and crossbeam_channel for example, and I'm sure those aren't the only ones. This is especially true for values, which evmap would also need to require this impl for.

Ok, in that case making new unsafe is fine. I thought it would be nice to provide a safe interface, but if that's not tenable, that's ok.

It would have to add every other crate as a dependency to implement the trait for those types, so it would be hugely expensive to have as a part of the build graph.

This is not the case, otherwise crates like serde couldn't work. But, until such a crate hits some critical mass, it wouldn't be useful. Which is an unfortunate chicken-egg problem.

Ok, in that case making new unsafe is fine. I thought it would be nice to provide a safe interface, but if that's not tenable, that's ok.

I also think providing a safe interface would be nice, but only if it is actually safe to use, not if it just seems safe to use. If that makes sense?

It would have to add every other crate as a dependency to implement the trait for those types, so it would be hugely expensive to have as a part of the build graph.

This is not the case, otherwise crates like serde couldn't work. But, until such a crate hits some critical mass, it wouldn't be useful. Which is an unfortunate chicken-egg problem.

I think maybe we're talking past each other. There is no one crate that implements serde::{Serialize,Deserialize} for lots of other crates. Instead, what has happened (luckily) is that almost every crate out there implement serde::* for their own types, which means that taking a requirement of T: Serialize is actually feasible. In our case, it's unlikely that most crates would pick up a dependency on evmap just to implement TrustedHashEq I think :sweat_smile:

I also think providing a safe interface would be nice, but only if it is actually safe to use, not if it just seems safe to use. If that makes sense?

Your argument  almost sounds like a slippery slope argument, because if you  can't trust unsafe code to do the right thing, what can you trust? For a stable example, we have the Send and Sync marker traits, whose sole purposes is to say some property exists. They are unsafe to implement, so if you do it incorrectly you can indroduce unsoundness that's visible only in safe code. So, we should be able to trust the implementors of unsafe traits, otherwise we can't get anything done.
More examples of unsafe traits:

all of lock_api traits
arrayvec/smallvecs Array trait
bytemuck's Pod trait

While unsafe traits aren't common, they are used to enforce guarantees that other unsafe code require. The difference between a normal trait and an unsafe trait is for a normal trait you should follow the api guidelines, and for unsafe traits you must follow the api guidelines. This is enough of a distinction for unsafe code to rely on unsafe traits, but not normal traits.

In our case, it's unlikely that most crates would pick up a dependency on evmap just to implement TrustedHashEq I think

Which is why it would be nice if a separate, smaller crate provides TrustedHashEq, then adding the dep could be easily justified for others. Like so serde splits it's traits from the implementations of the serializer.
But like @steffahn said, this isn't one or the other you can provide both, but if that's too much of a maintenance burden, that's ok, just an unsafe new also works.
I don't think you need to implement this for all std types, only the common ones, integers, slices, references, smart pointers, and applicable collections. Beyond that people can use unsafe new. You only need to cover the common case with the safe version.

I also think providing a safe interface would be nice, but only if it is actually safe to use, not if it just seems safe to use. If that makes sense?

Your argument almost sounds like a slippery slope argument, because if you can't trust unsafe code to do the right thing, what can you trust?

Yup, you're completely right, it is a slippery slope argument. Or rather, it stems from a deep-seated desire to avoid making people write unsafe wherever possible, unless they absolute have to, because I know how easy it is to get wrong. The temptation to just "throw an unsafe impl TrustedHashEq for Foo {} in there" is quite high. And I feel like we're less likely to have users get into a bad spot if we instead say that the unsafety happens when you use a type than when you produce a type. My argument isn't so much that "unsafe traits are bad", as it is "only make people use unsafe if there isn't another way". But I also acknowledge that my argument is more "it feels like the wrong trade-off to me" than "it's objectively better".

I don't think you need to implement this for all std types, only the common ones, integers, slices, references, smart pointers, and applicable collections. Beyond that people can use unsafe new. You only need to cover the common case with the safe version.

Actually, this gave me an idea that I think I would be comfortable with: to make TrustedHashEq (maybe under the name KnownStableHashEq) a sealed trait. We would only implement it inside evmap for common types that we've checked ourselves, and it would enable users that want to use any of those types to use a completely safe interface without any chance of foot-shooting. And if they want to use third-party types, they'll have to use the unsafe constructor to acknowledge that they've checked the type. How does that sound?

And if they want to use third-party types, they'll have to use the unsafe constructor to acknowledge that they've checked the type. How does that sound?

I feel like the option to derive TrustedHashEq for user-defined structs that e.g. only consist of standard-library types has its value too. Having the trait sealed instead of unsafe does take this option away.
But: A sealed trait can always be upgraded into an unsafe trait later (without any breaking changes), so I guess it could be reasonable to just start with the sealed version and see how big the need for some safe derive macros really is.

A relevant point in this discussion is that I'm also planning to extract left-right out of this repository, and then write a separate implementation that's just a straight hash table (so no multi-value), which I think will make the need for custom types much less pressing. Because in that world, all we need is to make sure the key type has a sane Hash + Eq, and I think it's far less likely that people use complex key types.
Relatedly: not sure what'll happen to the multi-value map with that change, especially since I'm not really using it any more. I think I'll probably move it out to its own repository managed by people who are still tinkering with Noria. Stay tuned!


Automated OAS Update

Generated OAS files from platform-api

This contains content related to the Konnect Search beta API, I will make sure it's merged in with that feature (#6655 )


HDDS-9422. Return error response when trying to create a directory under .snapshot path

What changes were proposed in this pull request?
Currently ozone fs -mkdir command doesn't throw an error message is key path starts with .snapshot and create .snapshot dir. .snapshot dir under bucket is reserved for snapshot and should not be allowed to be created using ozone fs -mkdir and ozone sh.
ozone sh throws an exception is key starts with .snapshot dir but ozone fs doesn't because it doesn't share the same code path to create key and file and dir can be create independently.
This change is to check dir name similar to key and file creation.
What is the link to the Apache JIRA
HDDS-9422
How was this patch tested?
Tested it on docker
sh-4.2$ ozone fs -mkdir -p ofs://om/vol1/bucket1/.snapshot/key1
mkdir: Cannot create key under path reserved for snapshot: .snapshot/
sh-4.2$

Thanks for the patch, LGTM. we could also add a small unit test around it.

Added/updated unit test.

Thanks @sadanand48 for the review.


React-router-redux "Module Not Found" Even after clean install

Version
5.0.0-alpha.6
Steps to reproduce
I'm trying to upgrade to the new version of React Router.
I installed the latest version of react-router-redux. Here is my package.json:
{
  "name": "web_client",
  "version": "0.1.0",
  "private": true,
  "homepage": "http://app.usefeed.me",
  "devDependencies": {
    "react-scripts": "^0.9.0",
    "redux-devtools-extension": "^2.13.2"
  },
  "dependencies": {
    "babel-polyfill": "^6.23.0",
    "classnames": "^2.2.5",
    "crypto": "0.0.3",
    "dns": "^0.2.2",
    "history": "^4.6.1",
    "isomorphic-fetch": "^2.2.1",
    "jsonwebtoken": "^7.4.1",
    "jws": "^3.1.4",
    "jwt-simple": "^0.5.1",
    "prop-types": "^15.5.10",
    "react": "^15.5.4",
    "react-dom": "^15.5.4",
    "react-redux": "^5.0.5",
    "react-redux-form": "^1.12.0",
    "react-router-dom": "^4.1.1",
    "react-router-redux": "^5.0.0-alpha.6",
    "redux": "^3.6.0",
    "redux-logger": "^2.10.2",
    "redux-saga": "^0.14.8",
    "semantic-ui-css": "^2.2.10",
    "semantic-ui-react": "^0.67.2",
    "validator": "^7.0.0"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  }
}

and entry point for my app:
import 'babel-polyfill'
import React from 'react'
import ReactDOM from 'react-dom'
import { combineReducers, createStore, applyMiddleware, } from 'redux'
import { Provider } from 'react-redux'
import { Route, } from 'react-router-dom'
import createHistory from 'history/createBrowserHistory';
import {
  ConnectedRouter,
  routerReducer,
  routerMiddleware as createRouterMiddleware,
} from 'react-router-redux'

import createLogger from 'redux-logger'
import createSagaMiddleware from 'redux-saga'
import { composeWithDevTools } from 'redux-devtools-extension';

import reducers from './reducers/'
import IndexSagas from './index-sagas'
import App from './containers/App'

const history = createHistory()
const sagaMiddleware = createSagaMiddleware()
const loggerMiddleware = createLogger()
const routerMiddleware = createRouterMiddleware(history)

/* eslint-disable no-underscore-dangle */
const store = createStore(
  combineReducers({
    ...reducers,
    router: routerReducer,
  }),
  composeWithDevTools(
    applyMiddleware(
      sagaMiddleware,
      routerMiddleware,
      loggerMiddleware,
    )
  ),
)
/* eslint-enable */

sagaMiddleware.run(IndexSagas)

ReactDOM.render(
  <Provider store={store}>
    <ConnectedRouter history={history}>
      <Route path="/" component={App} />
    </ConnectedRouter>
  </Provider>,
  document.getElementById('root')
);

Expected Behavior
I thought this would work, as it is very similar to the example in the repo's Readme.
Actual Behavior
However, I get these error messages in webpack:
Uncaught Error: Cannot find module "react-router-redux"

Module not found: [CaseSensitivePathsPlugin] /Users/steven/feedme/web_client/node_modules/react-router-redux/lib/index.js does not match the corresponding path on disk - File does not exist.

This is after I removed node_modules and did a clean install.
Any suggestions here? Thanks.

This has something to do with your bundler config (webpack, it looks like), not the library. Nothing in the package.json points to a lib/index.js file and we don't have that file in the bundle, so it shouldn't be looking there.

Thanks, I fixed this by upgrading create-react-app.

@sonarforte  I meet same problem, how do you fix that? I use quite latest version of create react app.

@smilexu My best advice is to delete node_modules, reinstall them, upgrade create-react-app, and that should work-- if it doesn't, maybe open a new issue because I'm not sure why that would happen.

I meet same problem, how do you fix that? I use quite latest version of create react app.
use typescript

hi @sonarforte, could you five me example repo like your config (using saga etc) because I am going for it too.

fixed add npm i @types/react-router-redux

if you get this error it means that you are not using version 5.0 of react-router-redux
I don't know why but for some reason some thought that npm should install v4 of create react redux to install you have to manually install the latest version
$ npm install --save react-router-redux@next

I'm having a similar issue, but i'm not using create-react-app. If this helps anyone<EMAIL_ADDRESS>says that it requires<EMAIL_ADDRESS>I was getting an unmet peer dependency when trying to install react-router-redux. Now that I've updated React itself I'm getting:
ERROR in ./node_modules/react-router-redux/lib/index.js
Module build failed: Error: ENOENT: no such file or directory
I noticed @sonarforte was using<EMAIL_ADDRESS>as I was. Thing is, there is no lib directory in<EMAIL_ADDRESS>.. what gives?
Some of these semvers may be out of whack since I just updated React & ReactDOM but here's the notable dependencies:
"react": "^15.6.2",
"react-dom": "^15.6.2",
"react-icons": "^2.2.7",
"react-redux": "^5.0.7",
"react-router": "^4.1.2",
"react-router-dom": "^4.1.2",
"react-router-redux": "5.0.0-alpha.6",
"react-spinkit": "^3.0.0",
"react-transition-group": "^1.2.1",
"redux": "^3.7.2",
"redux-immutable": "^4.0.0",
"redux-saga": "^0.16.0"


Partition healing

This PR includes an implementation of the partition healing algorithm.
When the network is partitioned and a collection of nodes A is unable to communicate with another collection of nodes B the cluster becomes in a partitioned state. A declares nodes from B faulty and B declares nodes from A faulty. If the network partition is becomes fixed, there is still no communication between A and B because faulty nodes shouldn't be pinged according to the swim protocol.
The partition healing algorithm tries to fix this state where the network is restored but the cluster is in the partitioned state described above.
A brief description of the algorithm:

A node from A contacts a node from B and compares their memberships.
If there are members that would cause faulty declarations when merging the two memberships according to the swim rules, the node reincarnates those members (either by declaring them suspect to its own membership, or declaring them suspect by piggybacking this over a ping to a node from B) .
If there are members that need to reincarnate, the node merges the partitions by applying the membership of B to it's own membership and sending its membership piggybacked over a ping to a node of B.

Please grab me to discuss, this is quite a big one.

I especially like the depth of the tests. Great work.

I'm happy with the changes, except:

/admin/healpartition/disco should return errors if the heal fails.
I am not convinced that reaching out to all the nodes which are applicable for healing is the best approach (see inline comments).

Since I'm OOO tomorrow and you might want to merge it before Thursday, please have a chat with the rest of the team about (2). If there is consensus that we indeed want to reach out to all the nodes, then LGTM from me.

LGTM after the /admin/healpartition/disco starts propagating errors.

What a remarkable PR. Now that the suspect transfer issue @thanodnl raised is solved, I think this is ready to land.
Kudos to @Motiejus too. LGT💵


Repeating console errors on 0.218.15

Repro steps:

Valheim 0.218.15
Install Bepinex, Expand_World_Events, Expand_World_Data
Load solo world
Check console - the following is constantly printing making the console difficult to use.

[Error  : Unity Log] MissingMethodException: Method not found: System.Collections.Generic.List`1<RandEventSystem/PlayerEventData> .RandEventSystem.RefreshPlayerEventData()
Stack trace:
(wrapper dynamic-method) RandEventSystem.DMDRandEventSystem::UpdateRandomEvent(RandEventSystem,single)
(wrapper dynamic-method) RandEventSystem.DMDRandEventSystem::FixedUpdate(RandEventSystem)

Still reproducible with today's Expand_World_Data 1.35.0

Fixed in Expand_World_Data 1.37.0, Expand_World_Events 1.8.0
Thanks for the amazing content!

Fixed


Improve Segment Overrides counter in the Project Settings Usage tab

In in the Project Settings Usage tab, the right-hand number should represent project.max_segment_overrides_allowed * len(project.environments). Right now it's just project.max_segment_overrides_allowed, which causes confusion:

I think we should either break this down by environment in this screen, or move this limit to a new screen in the environment settings. To avoid having another screen just dedicated to limits, my preference is the former.


Feature Request: Add latest tag to basic search

It would be nice to have the most recent tag shown within the search results.
This would prevent a secondary query for each result to show the tag that could be used for an image.

We don't have a search API in the distribution repository. For search related discussion in relation to V2 api, please see #206.
This can be much more easily obtained by using the notification API, which will notify on new tag or manifest pushes.

Thanks for the quick reply, indeed this is the V2 api. Notification API means I already had the image bookmarked or created, I'm talking on initial search.
I'll read up on #206 mentioned above


bluez5: modify patches for v5.66 update

Requires https://github.com/balena-os/meta-balena/pull/2982
Changelog-entry: Modify bluez patches for v5.66 update
Signed-off-by: Alex Gonzalez<EMAIL_ADDRESS>

Verified on RPI4 https://github.com/balena-os/balena-raspberrypi/pull/954, basic scanning works

@balena-ci I self-certify!

@balena-ci retest

@balena-ci I self-certify!


Data Science with Python : Naive Bayes Classifier

Description 📜
Included content on Naïve Bayes Classifier and updated the README.md file accordingly. Also uploaded an .ipynb file containing python code for Iris Flower Classification using Naïve Bayes Classifier as an example.
Fixes #396

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Datascience with Python

Checklist ✅

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

Hey @prathimacode-hub please review this PR and let me know if any changes are required.
Thanks!

Yes, thankyou. I will work on the same and get back to you.

Update here when it's done. @GouriRajesh

@prathimacode-hub Sorry for the delay. I have made the necessary changes, please have a look at them.
Thankyou.

@prathimacode-hub Thank you for your support! 😄


Bump Turing version

At the moment, the versions we use of deps in EpiAware are:

[47edcb42] ADTypes v1.7.1
[80f14c24] AbstractMCMC v5.2.0
[0bf59076] AdvancedHMC v0.6.1
[1313f7d8] DataFramesMeta v0.15.3
[31c24e10] Distributions v0.25.110
[ffbed154] DocStringExtensions v0.9.3
⌅ [366bfd00] DynamicPPL v0.27.2
[1a297f60] FillArrays v1.11.0
[2ab3a3ac] LogExpFunctions v0.3.28
[c7f686f2] MCMCChains v6.0.6
[b1d3bc72] Pathfinder v0.8.8
[1fd47b50] QuadGK v2.10.1
[189a3867] Reexport v1.2.2
[bd369af6] Tables v1.12.0
⌅ [fce5fe82] Turing v0.32.3
[37e2e46d] LinearAlgebra
[9a3f8284] Random
[2f01184e] SparseArrays v1.10.0
[10745b16] Statistics v1.10.0

Noting that we are blocked at v0.32.3 we should consider resolving the compat issue here and move to Turing 0.33. My sense is that Turing is improving quite fast at the moment and therefore it might make sense to devote some effort to maintaining compat with the latest version.
For example, the new mode estimation API https://turinglang.org/docs/tutorials/docs-17-mode-estimation/ is not available with our version of Turing.

So I think this brings up a broader issue in that we want our compact ot be minimum versions and not specific versions (as otherwise these need to be rolling updated by us which seems weird). What is standard Julia practice here? If the normal process is to have fixed compats then it seems like a scheduled action not test updated package versions would be a good idea

Unfortunately, I'm not really sure what SOP is here in Juliaworld.
In the TuringLang ecosystem they use CompatHelper.jl

CompatHelper is a Julia package that helps you keep your [compat] entries up-to-date. Whenever one of your package's dependencies releases a new breaking version, CompatHelper opens a pull request on your repository that modifies your [compat] entry to reflect the newly released version. We would like to eventually add Julia support to Dependabot.

CompatHelper is a rolling fixed compat helper so maybe preferable to >= type compat?

I think ours is broken

This might be due to other compat making it unsatisfiable which we should look at.

Nah it is just broke! https://github.com/CDCgov/Rt-without-renewal/actions/runs/10404917186/job/28814468332

See #426. I hotfixed our compat helper action. Something we need to decide is if we want to add new versions or drop old and replace. Its unclear to me how people are testing old package versions to make sure that they don't accidentally introduce functionality that depends on a more recent package version and so break their package on an old version.

In the action output I see a few errors which are I think due to base packages. It isn't clear to me how to handle that either.

Some context for this issue. At the moment Pathfinder 0.8/0.9-DEV is not compatible with Turing 0.33, which blocks updating to 0.33 for this project. But it looks like this is being addressed:
https://github.com/mlcolab/Pathfinder.jl/pull/189
https://github.com/TuringLang/Turing.jl/issues/2268

Pathfinder 0.9 seems to fix the above.


Chef Gem 13

I am following up on https://github.com/chef/chef-dk/issues/1209.  It looks like there have been several releases of chef dk since that comment saying one final release of 12.19 before releasing with 13.
Is there an expected ETA on when chef dk will contain chef gem 13?

Hi, We publish ChefDK on the fourth monday of the month, per https://chef.github.io/chef-rfc/rfc086-chef-oss-project-policies.html#cadence-release . I'd expect this month's release to contain Chef 13.0.

@thommay Thank you for the prompt response.  I will look forward to the new release next Monday the 24th.  Would this be found under Stable Release or Current Release?

You'd probably see the candidate for release in Current earlier but those builds aren't guaranteed to be good, only that they've passed the automated testing. Anytime we "release" something for consumption this would be via the stable channel.

I'm working on this now, and I think the estimation of next Tuesday is probably wildly optimistic, but I haven't seen how bad it looks yet in CI.
I know at least that on windows there's not fat gem for nokogiri which installs on ruby 2.4, so i'll be compiling nokogiri "by hand" on windows -- which might be easy or might not -- we do have a relatively sane build environment and already compile most of the nokogiri deps, so maybe that goes smoothly?  But "nokogiri" and "goes smoothy" are not words usually found together unless there's a "never" in there somewhere...
There's other issues with aws-sdk-v1 still being a dep, that might be mitigated by the fact that an updated json 1.x gem got pushed that has compat fixes so that it installs on ruby 2.4, so maybe that isn't as much of a problem as I think?
I would bet there's other issues waiting for me...
Next Tuesday is the soonest that I think it'd land, but I wouldn't really be shocked if it took 2-4 weeks of grinding through problems.  It may not show up in current for that long as well.

@lamont-granquist I see that we have snapped a 2.x but I don't see it available for download.  Is an artifact available that I could play around with?  I don't mind being an early adopter/tester even if there are still a few things to work through.

Chef does continuous versioning, with each merged pull request generating a version tag. However, we've not currently got builds of chef-dk 2 available, due to nokogiri being problematic with ruby 2.4 and windows currently.

Gotcha, appreciate the prompt reply and I will stay tuned for a build!

Are we still blocked on this release? Any ETA?

Its finally done.  I may bookmark this issue as an example of how pointless it is to ask for ETAs because they're usually a pack of lies and it takes however long it takes...

Understood and I appreciate it getting out regardless.  This did resolve our issue.


Allow to easily install the most recent version of each branch

As pointed by @xabbuh, currently is not easy to install the latest stable version of any supported branch. If you want to install the latest 2.3 version, you have to go to symfony.com website to check which is the latest version or you have to install 2.3.0 version and then upgrade.
We could offer the possibility of not providing the patch version, and this would install the latest version of the given branch:
$ symfony new blog/        # installs 2.5.5
$ symfony new blog/ 2.5.1  # installs 2.5.1
$ symfony new blog/ 2.5    # installs 2.5.5

$ symfony new blog/ 2.3.8  # installs 2.3.8
$ symfony new blog/ 2.3    # installs 2.3.20

@javiereguiluz this is done already thanks to #90, isn't it ?

:+1: I also think it's solved

You are all right. Let's close this issue as fixed by #90.


link to create PR after push is missing after update from 1.8 to 1.9 on existing repos

Gitea version (or commit ref): 1.9.2
Git version: 2.17.1
Operating system: Ubuntu Bionic 18.04
Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Log gist:

This is the server side log when pushing a branch:
Aug 28 09:18:48 gitea gitea[12311]: 2019/08/28 09:18:48 modules/ssh/ssh.go:181:func1() [E] SearchPublicKeyByContent: public key does not exist [id: 0]
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack for <IP_ADDRESS>
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack 200 OK in 46.200043ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 for <IP_ADDRESS>
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 200 OK in 15.310619ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo for <IP_ADDRESS>
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo 200 OK in 166.081004ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started POST /api/internal/ssh/23/update/60351 for <IP_ADDRESS>
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed POST /api/internal/ssh/23/update/60351 200 OK in 21.996506ms

My local shell just gives:
git push --set-upstream origin foo
Total 0 (delta 0), reused 0 (delta 0)
To ssh://git.example.com:2222/repo/test-testproject.git
 * [new branch]      foo -> foo
Branch 'foo' set up to track remote branch 'foo' from 'origin'.

Description
Today i've managed to update Gitea from 1.8.2 to 1.9.2 and after pushing a new branch, i'm missing the remote message to create a new PR introduced in #4716

Created a new org repo, forked into my user and pushed a branch and the beloved magic link is there...will check the repo hook settings...

When deleting a fork of a non-working repo and creating a new fork, the link also appears after pushing a new branch.

From admin settings run Resynchronize pre-receive, update and post-receive hooks of all repositories. task:

Nothing changed. Looking at the filesystem, all projects got the same hooks (the initial bash script which loops over all hooks in .d directory and the gitea hook call in .d directory).
Not sure where the hook gets lost. Will try to enable more debug output and see, if i can find something related.

might be coincidence, but the last commit to hook cmd was 23 days ago...: https://github.com/go-gitea/gitea/commit/def84840dbce6d725618e1aeab4ca1f665600087

Also weird, we still got repos which are working without re-fork (in another organisation).

comparing a fresh fork (user1, where it's working) against a non-working fork (user2):
gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/ user2/repo.git/hooks/post-receive.d/gitea
gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/gitea user2/repo.git/hooks/post-receive.d/gitea

No difference.

Perhaps some users are using VS2019? In my VS2019 I'm not getting the remote messages in the Source Control - Git log, but I do get them if I use git from bash.

Nayh, just using command line ;)

@guillep2k the push link is more efficient than VS2019 I think. You can just click that link and create a PR in seconds.

@morph027 are you sure that the hooks are even running? If your SSH key isn't managed by Gitea i.e. you can log in to the server to a shell then the hooks won't run because the environment won't get set because gitea serv won't get run.
As part of 1.11 I might pop a PR on that enforces pushes to Gitea repos have to be done in such a way that the hooks will run properly.

The SSH key is managed through Gitea Webinterface.

Yeah sorry just reading your logs - I can see that the hooks are running.
OK, so does your test repository have another branch or is that the first commit - because if it is the first commit and you have no other branches it will get set as the default branch after you push it.

This happens on all existing projects which did have the PR message before the update...

OK let's look at the logic.
The create a PR logic is in the post-receive hook and is determined by gitea hook post-receive here:
https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/cmd/hook.go#L175-L181
I.e the result from the pushing of a branch is res["create"] = true.
That's determined by here:
https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L173-L240
The important parts are:
https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L173
I.e. you're pushing the creation of a branch not deleting it.
https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L185
I.e. the user is allowed to create PRs
https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L204
i.e. the branch being pushed to is not the default branch - this is the problem with your testcase.
https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L221
i.e. There is not already a PR for this branch

In 1.8 the logic was determined by:
https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L210-L248
The important parts are:
https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L210

This is the same.

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L217

This is the same

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L226

This is the same

https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L237

This is the same.

The only difference I can see between 1.8 and 1.9 is that your testcase will "work" in 1.8 because 1.8 will not set the default branch to be the first thing that is pushed.

Are there definitely no errors in your logs? That's the only way there could be a difference.

Any logs in particular? Should i set loglevel to trace?

If you look at the code I've put up above for 1.9, all the points that would cause no output log.Error except for the case that you are pushing to the defaultBranch of a non-fork which doesn't log.
If you are pushing a non-default branch that you should either get a create the branch or visit the branch message. Compare the code between 1.8 and 1.9 I can't see how there could be a difference.

Huh, already forgot about ;)
We've upgraded to 1.10.2 recently and the behaviour still exists.

Maybe it's the determination of isPullRequest allowed? As I wrote above the hook change I don't think can be the cause

Now running 1.11.3, even with PULL_REQUEST_PUSH_MESSAGE = true there's no consistent behaviour. Some forks are working, some not.

OK can you tell me anything about the cases where this doesn't work? I'm gonna put a guess out here:

The cases where it doesn't work are all forks from an organisation.
They're limited to a particular organisation or orgs - maybe even a particular team reference in that organisation

Another question are the original forked repos are using an external issue tracker?

Hi!
Yes, both is true, all of our repos are forks of an organisation upstream and the upstreams are limited. Creating a PR through the webinterface works without problems.
At least in my case, i'm in the owners groups of the orgs.
And there are repos within the same organisation, where everything works.
None of the repos is using an external issue tracker.


Need to stop the container using flatpak kill, else Workspace will hang next launch

After you close Workspace/exit the flatpak, the container will still be running. If you re-enter the container/re-launch Workspace, Workspace will hang. To prevent this, you need to use flatpak kill to stop the container after you've closed workspace.
If you do end up running into the bug and Workspace starts hanging, you can fix it by deleting the contents of ~/.var/app/ca.dcloud.ICAClient/.ICAClient/.tmp

Fixed with commit 43047a6a6f651b0abd5b85e3c29a629eef8a1234


Add a unit test for invalid memos

High Level Overview of Change
While reviewing a different pull request I noted that the code coverage of memos is not as good as it could be.  So I wrote a unit test to improve that coverage.
Type of Change

[x] Tests (You added tests for code that already exists, or your new feature included in this PR)

CI failure is 0> #3 failed: NodeToShardRPC_test.cpp(47) which is known to be flaky


Can't install on Windows

Unicode Error with character map.....

Could you provide stack trace including error message?

sry for the late reply .. it was an issue in the setup file .. will fix in the next release ..

okay bro....
I am waiting your update version.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Kaung Htet San<EMAIL_ADDRESS>Sent: Tuesday, August 25, 2020 3:35:26 PM
To: kaunghtetsan275/pyidaungsu<EMAIL_ADDRESS>Cc: Naing Linn Htun<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [kaunghtetsan275/pyidaungsu] Can't install on Windows (#2)
sry for the late reply .. it was an issue in the setup file .. will fix in the next release ..
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/kaunghtetsan275/pyidaungsu/issues/2#issuecomment-679902280, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJYIUWTAOSYX6C6NA2IDDQ3SCN5FNANCNFSM4P73BARA.


Third Sprint Release

:tada: This PR is included in version 0.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


oAuth2client: Callback never called with media upload because of retry logic and readStream

Hello,
When trying to upload a media file to the youtube.videos.insert endpoint using a readStream, when receiving a 401 it will automatically retry the request, unfortunately the readStream has already been read, which result in never getting a callback from mikael/request.
The problem does not lie with the token but the actual service endpoint, youtube in this case, having bad permissions. Which is a problem that is solvable but I still like to have my callback invoked.
Is it possible to turn off the retry functionality in oauth2client.js? Retry logic will never work with readable streams imho.
const google = require('googleapis');
const youtube = google.youtube('v3');

const jwtClient = new google.auth.JWT(
  credentials.client_email,
  null,
  credentials.private_key,
  [
    'https://www.googleapis.com/auth/youtubepartner',
    'https://www.googleapis.com/auth/youtube',
    'https://www.googleapis.com/auth/youtube.force-ssl',
    'https://www.googleapis.com/auth/youtube.upload',
  ],
);

jwtClient.authorize((err) => {
  if(err) throw err;

  youtube.videos.insert({
    auth: jwtClient,
    onBehalfOfContentOwner: ownerId,
    onBehalfOfContentOwnerChannel: data.channelId,
    part: 'snippet, status',
    body: {
      snippet: {
        title: data.title,
        description: data.description,
        tags: '',
        categoryId: '',
      },
      status: {
        privacyStatus: 'private',
      },
    },
    resource: {
      name: 'test',
      mimeType: 'video/mp4',
    },
    media: {
      mimeType: 'video/mp4',
      body: fs.createReadStream(data.videoFilePath),
    },
  }, (err, resp) => {

    // this gets never called

    console.log('err', err);
    console.log('resp', resp);
  });
});

Current very dirty monkey patching solution:
const fs = require('fs');
const Stream = require('stream');
const google = require('googleapis');

google.auth.OAuth2.prototype._makeRequest = function (opts, callback) {
  if (opts.multipart) {
    opts.multipart = opts.multipart.map((params) => {
      if (params.body instanceof Stream.Readable) params.body = fs.createReadStream(params.body.path);
      return params;
    });
  }

  return this.transporter.request(opts, callback);
};

I'm having trouble reproducing this one.  This is the code I am using:
const google = require('googleapis');
const youtube = google.youtube('v3');
const credentials = require('./jwt.keys.json');
const fs = require('fs');

const FILENAME = './video.mov';

const jwtClient = new google.auth.JWT(
  credentials.client_email,
  null,
  credentials.private_key,
  [
    'https://www.googleapis.com/auth/youtubepartner',
    'https://www.googleapis.com/auth/youtube',
    'https://www.googleapis.com/auth/youtube.force-ssl',
    'https://www.googleapis.com/auth/youtube.upload',
  ],
);

jwtClient.authorize((err) => {
  if(err) throw err;

  var req = youtube.videos.insert({
    part: 'id,snippet,status',
    notifySubscribers: false,
    resource: {
      snippet: {
        title: 'Node.js YouTube Upload Test',
        description: 'Testing YouTube upload via Google APIs Node.js Client'
      },
      status: {
        privacyStatus: 'private'
      }
    },
    media: {
      body: fs.createReadStream(FILENAME)
    }
  }, function (err, data) {
    if (err) {
      console.error('ERROR!');
      console.error(err);
    }
    if (data) {
      console.log(util.inspect(data, false, null));
    }
    process.exit();
  });

  var fileSize = fs.statSync(FILENAME).size;

  // show some progress
  var id = setInterval(function () {
    var uploadedBytes = req.req.connection._bytesDispatched;
    var uploadedMBytes = uploadedBytes / 1000000;
    var progress = uploadedBytes > fileSize
      ? 100 : (uploadedBytes / fileSize) * 100;
    process.stdout.clearLine();
    process.stdout.cursorTo(0);
    process.stdout.write(uploadedMBytes.toFixed(2) + ' MBs uploaded. ' +
     progress.toFixed(2) + '% completed.');
    if (progress === 100) {
      process.stdout.write('\nDone uploading, waiting for response...\n');
      clearInterval(id);
    }
  }, 250);
});

And this is the output I get:
beckwith-macbookpro:171 beckwith$ node server.js
3.24 MBs uploaded. 100.00% completed.
Done uploading, waiting for response...
ERROR!
{ Error: Login Required
    at new RequestError (/Users/beckwith/Code/171/node_modules/google-auth-library/lib/transporters.js:34:42)
    at Request._callback (/Users/beckwith/Code/171/node_modules/google-auth-library/lib/transporters.js:96:27)
    at Request.self.callback (/Users/beckwith/Code/171/node_modules/request/request.js:186:22)
    at emitTwo (events.js:126:13)
    at Request.emit (events.js:214:7)
    at Request.<anonymous> (/Users/beckwith/Code/171/node_modules/request/request.js:1163:10)
    at emitOne (events.js:116:13)
    at Request.emit (events.js:211:7)
    at IncomingMessage.<anonymous> (/Users/beckwith/Code/171/node_modules/request/request.js:1085:12)
    at Object.onceWrapper (events.js:313:30)
  code: 401,
  errors:
   [ { domain: 'global',
       reason: 'required',
       message: 'Login Required',
       locationType: 'header',
       location: 'Authorization' } ] }

I'm surprised your callback is never invoked :(  If you can provide a sample that runs entirely (with the exception of the video and the key file), it would be super helpful.

@ofrobots I have an idea for this one, and I want to run it by you before submitting a PR.  I don't think our current retry logic is at all useful.
Before the retry, all we really do is call refreshAccessToken(), which in turn calls refreshToken.  If you look further up in the code, the call to getRequestMetadata made with every request already refreshes the token if needed.
I think the changes made in #242 likely negate the need for this retry logic at all.  The retry only happens on 401/403 errors, which shouldn't happen as frequently with the new expiration window.
TL;DR - I want to get rid of this retry because I don't think it does anything useful, and it's causing problems.
Thoughts?

Yeah, the retry mechanism seems hokey, and unlikely to work for the stream case in general as @Brmm points out. It sounds reasonable to remove it, but isn't that going to be a semver major change? I guess the argument will have to be that the users will see no observable difference, and I am not fully convinced of that.

I guess the argument will have to be that the users will see no observable difference

Except in this case, it's fixing a bug 🤣   I hear what you're saying though. Given the fact that this mostly causing problems with streaming requests - what do you think about just not retrying for those for now? Then I can file a 2.0 bug to eliminate the retry all together. Eh?

Except in this case, it's fixing a bug 🤣

To avoid being semver major we need to fix the bug without breaking other currently working code :smile:.

Given the fact that this mostly causing problems with streaming requests - what do you think about just not retrying for those for now? Then I can file a 2.0 bug to eliminate the retry all together. Eh?

SGTM.


Document ng config examples

📚 Docs or angular.io bug report
Description
The ng config --help clearly states that it allows you to

Retrieves or sets Angular configuration values in the angular.json file for the workspace

and if I wish to add a simple style to existing style file, I can only override the existing styles, but cannot add to it. I could not even find relevant documentation.
I only tried style, but it is applicable to scripts as well.
🔬 Minimal Reproduction
My sample angular.json
projects": {     "samarthya": {       "root": "",       "sourceRoot": "src",       "projectType": "application",       "prefix": "sm",       "schematics": {},       "architect": {         "build": {           "builder": "@angular-devkit/build-angular:browser",           "options": {             "outputPath": "dist/samarthya",             "index": "src/index.html",             "main": "src/main.ts",             "polyfills": "src/polyfills.ts",             "tsConfig": "src/tsconfig.app.json",             "assets": [               "src/favicon.ico",               "src/assets"             ],             "styles": [               "src/styles.css",               "node_modules/bootstrap/dist/css/bootstrap.min.css"             ],
If I execute
ng config projects.samarthya.architect.build.options.styles src/styles1.css
it overrides the existing array but will not append to it.
"styles": "src/style1.css",
is the new value it reflects
I don't think
ng config projects.samarthya.architect.build.options.styles [src/style1.css, src/style2.css]
will also work.
What's the affected URL?**
 https://angular.io/...
Reproduction Steps**

Issue a command to append/add to the styles list
ng config projects.samarthya.architect.build.options.styles src/styles1.css
Expected vs Actual Behavior**

Allow options to add, delete, override the styles if not an option; change the output of the ng config --help command.
📷Screenshot

🔥 Exception or Error

🌍  Your Environment
Browser info

Anything else relevant?

This is now documented in https://angular.io/cli/config


Small typos fixed

This change is

Good catch,  changed cricial to critical. The doc talks about critical rather than crucial pods.

Thanks, LGTM.


Node types for exceptions + tests

New CodeQL Queries

test annotations.
Inheritance from exceptions

New NodeTypes

Tests are harder than initially thought - tests can take many different forms (inheritance from base test class, test annotation, possible others?)


Adding decode ways problem under Dynamic Programming

Hi! Is this issue still open? If so, could you possibly assign it to me?

@BorisHamadej it is still open.

@all-contributors please add @emmagarr for content

@shhossain Is the issue still open ? I would like to work on it if it is

https://github.com/shhossain/computer_science/pull/776


[BUG] OSS文件系统依赖版本更新，出现不兼容现象

[ERROR] [time: 2022-08-03 21:32:20]|[caller: App\Exception\Handler\AppExceptionHandler@handle]|[message: 发生系统异常:Too few arguments to function OSS\OssClient::__initClient(), 0 passed and at least 3 expected;行号为:[127]; 文件为:[/opt/www/vendor/aliyuncs/oss-sdk-php/src/OSS/OssClient.php]; Trace为:[#0 [internal function]: OSS\OssClient->__initClient()
| #1 /opt/www/vendor/aliyuncs/oss-sdk-php/src/OSS/OssClient.php(106): call_user_func_array()
| #2 /opt/www/vendor/hyperf/di/src/Resolver/ObjectResolver.php(99): OSS\OssClient->__construct()
| #3 /opt/www/vendor/hyperf/di/src/Resolver/ObjectResolver.php(66): Hyperf\Di\Resolver\ObjectResolver->createInstance()
| #4 /opt/www/vendor/hyperf/di/src/Resolver/ResolverDispatcher.php(62): Hyperf\Di\Resolver\ObjectResolver->resolve()
| #5 /opt/www/vendor/hyperf/di/src/Resolver/DepthGuard.php(73): Hyperf\Di\Resolver\ResolverDispatcher->Hyperf\Di\Resolver{closure}()
| #6 /opt/www/vendor/hyperf/di/src/Resolver/ResolverDispatcher.php(63): Hyperf\Di\Resolver\DepthGuard->call()
| #7 /opt/www/vendor/hyperf/di/src/Container.php(194): Hyperf\Di\Resolver\ResolverDispatcher->resolve()
| #8 /opt/www/vendor/hyperf/di/src/Container.php(82): Hyperf\Di\Container->resolveDefinition()
# Paste the result here.

Description:
https://github.com/aliyun/aliyun-oss-php-sdk/commits/master
下午OSS-SDK有更新，Hyperf文件组件的OSS出现不兼容现象。希望更新文件系统组件(OSS)
Steps To Reproduce:

嗯，这里看到了。。今天会处理


Cannot run client test on mac osx

When I run command <./MacChatScript client=localhost:1024>, It shows <CommandLine: client=localhost:1024> and then exit.

in the exit or bugs log, it probably tells you something

I had the same issue I think:
$ ./MacChatScript client=localhost:1024
CommandLine: /Users/marcjay/Documents/MacChatScript
    client=localhost:1024

evcalled pid: 64586

For whatever reason, when compiling on a Mac (which has the MACH compiler flag set), the client is discarded:
https://github.com/bwilcox-1234/ChatScript/blob/v7.31/SRC/common.h#L69
#elif __MACH__
#define DISCARDCOUNTER 1
#define DISCARDCLIENT 1    // <-- THIS LINE HERE
#define DISCARDPOSTGRES 1
#define DISCARDMYSQL 1

This looks to me like a bug. To fix, I removed/commented out this line, ran make and then ran the resulting BINARIES/ChatScript binary that gets created. That then has the client code in it and fixes the issue.
@bwilcox-1234 it would be good to know if there's a reason the client is disabled by default in the Mac OS binary?
Many thanks

fixed in master for next deliver. No reason per se, other than copying unnecessarily.

Great, many thanks for the merge


The Light Table mades same connection when i evaluate the code on Instarepl.

I builded latest version of Light table to run and to explore and i got this.

I don't know why.. Plz help me.

Environment
ProductName:	Mac OS X
ProductVersion:	10.10.1
BuildVersion:	14B23

Lein Version and Java Version
Leiningen 2.5.0 on Java 1.6.0_65 Java HotSpot(TM) 64-Bit Server VM

The following thing is What i did.
$ git clone https://github.com/LightTable/LightTable.git
$ cd LightTable
$ sh osx_deps.sh
$ export LT_HOME=$(pwd)/deploy
$ ./deploy/light

I got the below things.

2015-01-29 14:49:04.400 node-webkit[9720:312538] Internals of CFAllocator not known; out-of-memory failures via CFAllocator will not result in termination. http://crbug.com/45650
[9720:0129/144904:ERROR:breakpad_mac.mm(234)] Breakpad initializaiton failed
[MacBook-Air] LightTable $ 2015-01-29 14:49:04.688 node-webkit Helper[9724:312623] Internals of CFAllocator not known; out-of-memory failures via CFAllocator will not result in termination. http://crbug.com/45650
2015-01-29 14:49:04.968 node-webkit Helper[9725:312652] Internals of CFAllocator not known; out-of-memory failures via CFAllocator will not result in termination. http://crbug.com/45650
How to solve this problem.
Thank you for read this.

Hi. Does this behavior also happen when you use the latest binary from lighttable.com? That might indicate if this is a build issue or a connection issue. If you're getting errors from the latest binary, run the command Toggle console and please paste  any errors you see. Without more information, this is not yet reproducible.

Okay, i'll try again.

Closing as I haven't heard back on the above questions. Feel free to provide reproducible steps and we can reopen


[Refused to apply inline style because it violates the following Content Security Policy] Publishing coverage report in Jenkins, got errors in console and few styles are not applied.

After code coverage generation, published this reports as an HTML report in the Jenkins. We couldn't see the progressed chart styles in the report, observed these console errors as follows.
Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-lHXTXVoMUY2/p3pxQI6CRA0n02Rrs2+ZoQFL/rrqCXA='), or a nonce ('nonce-...') is required to enable inline execution.
Same error is not reproduced in my local machine, issue comes only as part of Jenkins Html Report.

This is only a small wrapper around istanbul, you would be better off raising an issue there with a minimal repro: https://github.com/istanbuljs/istanbuljs


Let users disable clean-dashboard

Thanks for contributing! 🍄

LINKED ISSUES: Closes #3816

TEST URLS: Dashboard

SCREENSHOT:

Before
	After

I don't think we should do this. We can provide the css to disable the feature.

I don’t feel super strongly about that anymore, especially if the feature can’t be disabled with a couple of lines. Here for example it makes sense because the CSS applied is substantial so it can’t easily be undone.


Monkey failure

Failed for RandSeed = 11405, ecString, ecSelectionUp, ecCopy, ecTab, ecMoveLineUp, ecDeleteWord, ecBlockIndent, ecMoveCharLeft
   cCommands : array [0..50] of Integer = (
      ecChar, ecString, ecChar, ecString, ecChar, ecString,
      ecTab, ecShiftTab,
      ecInsertLine, ecLineBreak,
      ecDeleteChar, ecBackspace, ecDeleteLine, ecDeleteWord,
      ecLeft, ecRight, ecUp, ecDown, ecPageUp, ecPageDown,
      ecSelectionLeft, ecSelectionRight, ecSelectionUp, ecSelectionDown,
      ecLineStart, ecLineEnd, ecWordLeft, ecWordRight,
      ecSelectionLineStart, ecSelectionLineEnd, ecSelectionWordLeft, ecSelectionWordRight,
      ecPageUp, ecPageDown,
      ecSelectionPageUp, ecSelectionPageDown,
      ecInsertMode, ecOverwriteMode,
      ecLineComment, ecBlockComment,
      ecBlockIndent, ecBlockUnindent,
      ecCopy, ecCut, ecPaste,
      ecUndo, ecRedo,
      ecMoveLineUp, ecMoveLineDown, ecMoveCharLeft, ecMoveCharRight
      );
   cNBActions = 10;

I didn't get this. I try to set the column tab option false...

Hmm, I do not have that line "for j := 1 to cNumberOfActions do", maybe you're on an older monkey runner? Below is my code
const
   cCommands : array [0..50] of Integer = (
      ecChar, ecString, ecChar, ecString, ecChar, ecString,
      ecTab, ecShiftTab,
      ecInsertLine, ecLineBreak,
      ecDeleteChar, ecBackspace, ecDeleteLine, ecDeleteWord,
      ecLeft, ecRight, ecUp, ecDown, ecPageUp, ecPageDown,
      ecSelectionLeft, ecSelectionRight, ecSelectionUp, ecSelectionDown,
      ecLineStart, ecLineEnd, ecWordLeft, ecWordRight,
      ecSelectionLineStart, ecSelectionLineEnd, ecSelectionWordLeft, ecSelectionWordRight,
      ecPageUp, ecPageDown,
      ecSelectionPageUp, ecSelectionPageDown,
      ecInsertMode, ecOverwriteMode,
      ecLineComment, ecBlockComment,
      ecBlockIndent, ecBlockUnindent,
      ecCopy, ecCut, ecPaste,
      ecUndo, ecRedo,
      ecMoveLineUp, ecMoveLineDown, ecMoveCharLeft, ecMoveCharRight
      );
   cNBActions = 10;

   function MonkeyRun(seed : Integer; skip, nbActions : Integer) : String;
   var
      s : TStringStream;
      j, k, cmd : Integer;
      ident : String;
   begin
      Editor.Clear;
      s := TStringStream.Create('1'#13#10'2'#13#10'3'#13#10'4'#13#10'5'#13#10);
      Editor.LoadFromStream(s);
      s.Free;
      Editor.InsertMode:=True;

      TClipboardHack(Clipboard).HardOpen;
      try
         Clipboard.AsText := 'b';
      finally
         TClipboardHack(Clipboard).HardClose;
      end;

      RandSeed := seed;
      for j := 1 to skip+nbActions do begin
         cmd := cCommands[Random(Length(cCommands))];
         if j <= skip then continue;
         case cmd of
            ecCut, ecCopy, ecPaste : begin
               TClipboardHack(Clipboard).HardOpen;
               try
                  Editor.ExecuteCommand(cmd, 'a', nil);
               finally
                  TClipboardHack(Clipboard).HardClose;
               end;
            end;
            ecString :
               for k := 1 to Random(10)+1 do
                  Editor.ExecuteCommand(ecChar, 'c', nil);
         else
            Editor.ExecuteCommand(cmd, 'a', nil);
         end;
      end;

      for j := 1 to nbActions do
         Editor.ExecuteCommand(ecUndo, #0, nil);

      if Editor.Lines.CommaText <> '1,2,3,4,5' then begin
         RandSeed := seed;
         Result := 'Failed for RandSeed = ' + IntToStr(seed);
         for j:=1 to skip+nbActions do begin
            cmd := cCommands[Random(Length(cCommands))];
            if j<=skip then continue;
            EditorCommandToIdent(cmd, ident);
            Result := Result + ', '+ ident;
         end;
      end else Result := '';
   end;

var
   i, len, skip : Integer;
   bestLen, bestSkip : Integer;
   run : String;
begin
   for i:=11400 to 100000 do begin

      Caption := IntToStr(i);

      if (i and 127)=0 then Application.ProcessMessages;

      run := MonkeyRun(i, 0, cNBActions);
      if run <> '' then begin
         bestLen := cNBActions;
         bestSkip := 0;
         for len := cNBActions-1 downto 1 do begin
            Caption := 'Narrowing failure at RandSeed = ' + IntToStr(i)
                     + ', best length = ' + IntToStr(bestLen);
            for skip := 0 to cNBActions-len do begin
               if MonkeyRun(i, skip, len) <> '' then begin
                  bestLen := len;
                  bestSkip := skip;
                  break;
               end;
            end;
         end;

         run := MonkeyRun(i, bestSkip, bestLen);

         BBMonkey.Caption := Editor.Lines.CommaText;
         Clipboard.AsText := run;
         Caption := run;
         break;
      end;

   end;
end;

Ok, I got it. I have to print a "Monkey Runner" t-shirt. :D

https://www.youtube.com/watch?v=FxcWnE4p7H8
could not resist :)

Cool, now I have a logo idea for it.

Fixed. Failed now for RandSeed = 11486.

Fixed.


Tracing tests updates

Proposed Changes

Removes deprecated calls to AddTracing
Removes workaround in tracing tests for improper tracer shutdown (this issue has been fixed)

Release Note

Docs

/retest

/retest

/retest

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/retest-required

/retest

/retest

/test integration-tests_eventing-kafka-broker_main

Failed to create role "eventing-e2e65": an error on the server ("Internal Server Error: \"/apis/rbac.authorization.k8s.io/v1/namespaces/eventing-e2e65/roles\": the server is currently unable to handle the request")

Not sure what we can do about this one specifically... If this happens too often, we should ask productivity WG to increase our CI setup.

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/test reconciler-tests-namespaced-broker_eventing-kafka-broker_main

/test reconciler-tests-namespaced-broker_eventing-kafka-broker_main

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/retest
On Tue 23. Aug 2022 at 12:24, knative-prow[bot] @.***>
wrote:

@mgencur https://github.com/mgencur: The following tests failed, say
/retest to rerun all failed tests or /retest-required to rerun all
mandatory failed tests:
Test name Commit Details Required Rerun command
reconciler-tests-namespaced-broker_eventing-kafka-broker_main 02dd1f7
https://github.com/knative-sandbox/eventing-kafka-broker/commit/02dd1f775847f74eea1885b07f4fb20c30ed3670
link
https://prow.knative.dev/view/gs/knative-prow/pr-logs/pull/knative-sandbox_eventing-kafka-broker/2532/reconciler-tests-namespaced-broker_eventing-kafka-broker_main/1561990967999860736
unknown /test
reconciler-tests-namespaced-broker_eventing-kafka-broker_main
integration-tests-namespaced-broker_eventing-kafka-broker_main 02dd1f7
https://github.com/knative-sandbox/eventing-kafka-broker/commit/02dd1f775847f74eea1885b07f4fb20c30ed3670
link
https://prow.knative.dev/view/gs/knative-prow/pr-logs/pull/knative-sandbox_eventing-kafka-broker/2532/integration-tests-namespaced-broker_eventing-kafka-broker_main/1562014748675936256
true /test integration-tests-namespaced-broker_eventing-kafka-broker_main
Your PR dashboard https://prow.knative.dev/pr.
Instructions for interacting with me using PR comments are available here
https://git.k8s.io/community/contributors/guide/pull-requests.md. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow issue:
repository. I understand the commands that are listed here
https://go.k8s.io/bot-commands.
—
Reply to this email directly, view it on GitHub
https://github.com/knative-sandbox/eventing-kafka-broker/pull/2532#issuecomment-1223870091,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABGPTTLFSHGSSOIR2VN7WLV2SRG3ANCNFSM57GLNBXA
.
You are receiving this because you were assigned.Message ID:
@.***>

--
Sent from Gmail Mobile

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

/test integration-tests-namespaced-broker_eventing-kafka-broker_main

@mgencur again needs a rebase ... man, this all really is sad, the failures

@matzew Hmm. Another rebase? The CI is unusable now. I'd rather wait with the rebase. Maybe till the next week. This PR is not urgent so let's see if it gets better later.

@mgencur wanna give a try now? We merged a few, since :sweat_smile:

@matzew OK, trying it now.

There are some failures in the downstream tests for Kafka like this:
Internal error occurred: failed calling webhook "defaulting.webhook.kafka.eventing.knative.dev": failed to call webhook: Post "[https://kafka-webhook-eventing.knative-eventing.svc:443/defaulting?timeout=2s](https://kafka-webhook-eventing.knative-eventing.svc/defaulting?timeout=2s)": dial tcp <IP_ADDRESS>:443: connect: connection refused

But I don't think it's related to this PR.


this line panic on parsing

https://github.com/swaggo/swag/blob/abf4f7b6b2877ebff42dcef5d7a4d2138ca4e8bc/parser.go#L135
panic: ParseComment panic:Can not find ref type: ...
with a type from another package of the form MyStructs.TheStructToUse
I don't get why ....
Stéphane

@pilere can you provide your sample code?

No really, I just run swag init on my project (gin-gonic API)
where conf.GetMeActifResult is the struct type GetMeActifResult defined in the package conf imported within my code ....
type GetMeActifResult struct {
....
}
c:\mycode>swag init
2017/10/13 09:30:30 Generate swagger docs....
2017/10/13 09:30:30 Generate general API Info
2017/10/13 09:30:30 ParseComment panic:Can not find ref type:"conf.GetMeActifResult".
panic: ParseComment panic:Can not find ref type:"conf.GetMeActifResult".
goroutine 1 [running]:
panic(0x718d40, 0xc04215a760)
C:/Go/src/runtime/panic.go:500 +0x1af
log.Panicf(0x79c700, 0x16, 0xc04246f4b0, 0x1, 0x1)
C:/Go/src/log/log.go:327 +0xea
github.com/swaggo/swag.(*Parser).ParseRouterApiInfo(0xc04232c780, 0xc042338300)
D:/www/src/github.com/swaggo/swag/parser.go:135 +0x61f
github.com/swaggo/swag.(*Parser).ParseApi(0xc04232c780, 0x79587c, 0x2, 0x79743b, 0x9)
D:/www/src/github.com/swaggo/swag/parser.go:67 +0x28d
github.com/swaggo/swag/gen.(*Gen).Build(0xc04246f8d0, 0x79587c, 0x2, 0x79743b, 0x9, 0x0, 0x0)
D:/www/src/github.com/swaggo/swag/gen/gen.go:27 +0x4ad
main.main.func1(0xc04206a9a0, 0x0, 0xc04206a9a0)
D:/www/src/github.com/pilere/swag/cmd/swag/main.go:21 +0x5c
github.com/urfave/cli.HandleAction(0x725c60, 0x7c2da0, 0xc04206a9a0, 0xc0421f2200, 0x0)
D:/www/src/github.com/urfave/cli/app.go:490 +0xdb
github.com/urfave/cli.Command.Run(0x796036, 0x4, 0x0, 0x0, 0xc0423de110, 0x1, 0x1, 0x7994b9, 0xe, 0x0, ...)
D:/www/src/github.com/urfave/cli/command.go:210 +0xbc0
github.com/urfave/cli.(*App).Run(0xc04201c9c0, 0xc04200c700, 0x2, 0x2, 0x0, 0x0)
D:/www/src/github.com/urfave/cli/app.go:255 +0x7b9
main.main()
D:/www/src/github.com/pilere/swag/cmd/swag/main.go:27 +0x143

@pilere You had reference conf.GetMeActifResult struct type in your  main.go which contains https://github.com/swaggo/swag#declarative-comments-format that swag can't find it.
I guess that some declarative comments format have wrong usage.
Can you show your main.go file ?

yes, I do use :
// @Success 200 {array} conf.GetMeActifResult
in the comment of the API
and have a small comment on the struct definition conf.GetMeActifResult :
// GetMeActifResult utilise uniquement comme type de data pour swagger api result
type GetMeActifResult struct {
.......
}
I see no informations on how to set comments for structures here :
https://github.com/swaggo/swag#declarative-comments-format
the sample his :
type Pet3 struct {
ID int json:"id"
}
with no comment and not used within the api sample above ....
Stéphane

@pilere Sorry for my late replay. I had created https://github.com/easonlin404/swag-test and worked for me FYR.
Or maybe you can show your project file structure.

That's exactly like that ... I don't get it, it should work ...
I will try to add some debug of the scan ....
Thanks for your help, I will keep you informed.

After some debugging, I found that the parser itself has some
inconsistency ... in the function "func (parser *Parser) ParseDefinitions() {"
if I add a dump or "parser" I got this :
[DEBUG] parser &{swagger:0xc042034400 files:map[apifile1.go:0xc042273c00 apifile2.go:0xc0423b7900 apifile3.go:0xc042372600 docs\docs.go:0xc042372900 main.go:0xc04233a700 apifile4.go:0xc042272d80 apifile5.go:0xc042273600 apifile6.go:0xc0423b7100 apifile7.go:0xc042272180 apifile8.go:0xc042273e80 apifile9.go:0xc04233a180 apifile10.go:0xc042272280  TypeDefinitions:map[main:map[DB:0xc042237080] docs:map[s:0xc042122630]] registerTypes:map[conf.GetMeActifResult:]}
2017/10/16 11:26:28     [DEBUG DEFINITIONS] refTypeName conf.GetMeActifResult et typeSpec
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x18 pc=0x4d864d]
the API is defined in the main package but the conf.GetMeActifResult is defined in the conf package .. I will try to change your test to match it !
Stéphane

pfff you were right from the beginning ...
I set up my app in multiple folder but with multiple executable.
The API is one
Some Nodes are others
and ALL are sharing the conf.
so I got this kind of folder tree
--> /API
--> main.go
--> file2.go
-->/conf
--> structure.go
-->/nodes
-->blabla.go
so I launch the swag init within API but the /conf is one step under ... so it's not parsed ....
Your example look like the same with the API in one folder and the conf another BUT the main.go is under it and we launch the swag init inside it !
I need to find a way to scan ../conf from within  /API
Stéphane

@pilere ok, I will find a way to support it if main.go is not under root folder.

if you could provide support for time.Time as a structure field, that would be great too :
in your swag-test package : conf.go
package conf
import "time"
// GetMeActifResult utilise uniquement comme type de data pour swagger api result
type GetMeActifResult struct {
	ID        int `json:"id"`
	CreatedAt time.Time
}

you get :
\swag-test-master>swag init
2017/10/18 09:32:10 Generate swagger docs....
2017/10/18 09:32:10 Generate general API Info
panic: not supported 'astSelectorExpr' yet.

goroutine 1 [running]:
panic(0x719040, 0xc042305060)
        C:/Go/src/runtime/panic.go:500 +0x1af
github.com/swaggo/swag.getPropertyName(0xc042270b80, 0xc0422a4c90, 0xc04211f120)
        D:/www/src/github.com/swaggo/swag/property.go:12 +0x9e
github.com/swaggo/swag.(*Parser).ParseDefinitions(0xc04234be00)
        D:/www/src/github.com/swaggo/swag/parser.go:193 +0x390
github.com/swaggo/swag.(*Parser).ParseApi(0xc04234be00, 0x795bfc, 0x2, 0x7977bf, 0x9)
        D:/www/src/github.com/swaggo/swag/parser.go:70 +0x2b6
github.com/swaggo/swag/gen.(*Gen).Build(0xc04211f8c0, 0x795bfc, 0x2, 0x7977bf, 0x9, 0x0, 0x0)
        D:/www/src/github.com/swaggo/swag/gen/gen.go:27 +0x4ad
main.main.func1(0xc042074840, 0x0, 0xc042074840)
        D:/www/src/github.com/swaggo/swag/cmd/swag/main.go:21 +0x5c
github.com/urfave/cli.HandleAction(0x725f60, 0x7c3140, 0xc042074840, 0xc04203cf00, 0x0)
        D:/www/src/github.com/urfave/cli/app.go:502 +0xdb
github.com/urfave/cli.Command.Run(0x7963ba, 0x4, 0x0, 0x0, 0xc04238dce0, 0x1, 0x1, 0x79983d, 0xe, 0x0, ...)
        D:/www/src/github.com/urfave/cli/command.go:210 +0xbd9
github.com/urfave/cli.(*App).Run(0xc042282000, 0xc0420383e0, 0x2, 0x2, 0x0, 0x0)
        D:/www/src/github.com/urfave/cli/app.go:259 +0x801
main.main()
        D:/www/src/github.com/swaggo/swag/cmd/swag/main.go:27 +0x143

That would be great ... for now I am stuck with the fact that I need only one error code by error ... I was using this :

// GetMeActifs
// @Summary GetMeActifs Get the list of actifs
// @Description get all the actifs
// @Accept  json
// @Produce  json
// @Success 200 {array} conf.GetMeActifResult
// @Failure 403 {string} StatusForbidden "Forbiden"
// @Failure 404 {string} StatusNotFound "No User Found"
// @Failure 404 {string} StatusNotFound "No Owner Found"
// @Router /actifs [get]

which is not tolerated by swagger :
// @Failure 404 {string} StatusNotFound "No User Found"
// @Failure 404 {string} StatusNotFound "No Owner Found"
I need to find either a way out or to use another error code but then it's silly as it should be a 404 ....
Stéphane

@pilere Did you still have the issue?

@easonlin404 I didn't try the new version if you changed it ... are your talking of the first one with the conf folder at the same level than the project or the second one with the parsing of the same error code for 2 errors ?
Stéphane

@pilere please reopen it if you still have this issue.

How to generate swag binary file?
As when I run swag init command, an error displaying command: swag not found

Hello @easonlin404 for me still not working, i already download swag by
$ go get -u github.com/swaggo/swag/cmd/swag

Hello @easonlin404 for me still not work, i already download by
go get -u github.com/swaggo/swag/cmd/swag

Please help


Review and update Pipelines.Steps.Data README.md with correct .NET version and links to Pipelines.Core instead of Pipelines.Steps.Core.

See Commit  2bcec48


Replace proper text instead of Lorem Ipsum on the home page

On the home page, there is Lorem Ipsum text that should replace with appropriate sentences

the content of the landing page is under huge refactoring, so this issue is redundant and must be closed.


Obsoletion request: GO:0030685 : nucleolar preribosome]

Please provide as much information as you can:

GO term ID and Label
GO:0030685   nucleolar preribosome

Reason for deprecation Put an x in the appropriate box:

[ ]  The reason for obsoletion is that this term was added in error.

"Replace by" term (ID and label)
If all annotations can safely be moved to that term

preribosome

Are there annotations to this term?

How many EXP:
2 SGD
1 PomBse

Are there mappings and cross references to this term? (InterPro, Keywords; check QuickGO cross-references section)

Is this term in a subset? (check the AmiGO page for that term)

Any other information

I think the preribosome is always nucleolar , so maybe "preribosome". can have the parent "nucleolus" (Need to check this)

Checklist for ontology editor
Check term usage and metadata in Protégé

[ ] check term usage in the ontology
[ ] check internal mappings: RHEA, EC, MetaCyc
[ ] check subset usage
[ ] check taxon constraints

Check annotations

[ ] create Annotation Review spreadsheet

Annotation Review template: https://docs.google.com/spreadsheets/d/1izV3q1jnq_Ybg5MJ53O_b5BCTkGtjl_Fi-cOg3-7eBE/edit#gid=0

Instructions: https://wiki.geneontology.org/Annotation_Review_Request

[ ] create annotation review ticket: https://github.com/geneontology/go-annotation/issues/new?assignees=&labels=annotation+review&template=annotation-review-for-obsoletion.md&title=Review+annotations+to+[INSERT+GO+TERM]
[ ] find external mappings (via IEAS), include in obsoletion notice
[ ] tag curators in Annotation Review ticket. Responsible annotator for each group: https://github.com/geneontology/go-site/blob/master/metadata/group-contacts.csv

Notification

[ ] create obsoletion announcement
[ ] announce to GO friends<EMAIL_ADDRESS>[ ] paste the text in the ontology ticket

pre ribosomes  transit from the nucleolus to the nucleoplasm to the cytoplasm where they mature, so

pre-ribosome can't have a nucleolar parent.

But, we
2) would not normally create location-specific terms for the same complex in different locations, so should obsolete "nucleolar pre ribosome" with
consider:
GO:0030684  preribosome
or more likely
GO:0030686   90S preribosome (the earliest form of the pre ribosome)
and concurrent annotation to "nucleolus"

@pgaudet it seems we can't use "occurs_in" to qualify the location of a complex, is that correct?

add pre-ribosome synonyms

I can leave "nucleolar preribosome"
because preribosomes can also occur in the nucleoeoplasm

Or should

Or  probably i should merge. These aren't different complexes?
@pgaudet  please advise

You can do protein complex is_active in some cellular anatomical entity.
So, if the nucleolar preribosome and the nuclear preribosome are the same complex, you can obsolete, and the localization can be captured with an extension.


TopAppBar is broken

When using the preact-cli template and replacing /Toolbar and /Toolbar/style.css with /TopAppBar, looking at the index.d.ts files in both folders, using the same named exports:
devtools.js?69b5:341 Uncaught (in promise) TypeError: Cannot read property '_renderedComponent' of undefined
    at visitNonCompositeChildren (devtools.js?69b5:341)
    at Object.componentUpdated (devtools.js?69b5:260)
    at Object.preact.options.afterUpdate (devtools.js?69b5:384)
    at renderComponent (preact.js?10a9:316)
    at rerender (preact.js?10a9:38)

Where the source of the error is actually:
Uncaught TypeError: Cannot read property 'addEventListener' of null
    at Object.registerInteractionHandler (index.js?81af:67)
    at eval (foundation.js?1cba:243)
    at Array.forEach (<anonymous>)
    at MDCRippleFoundation.registerRootHandlers_ (foundation.js?1cba:242)
    at MDCRippleFoundation.init (foundation.js?1cba:205)
    at MDCRipple.MDCComponent (component.js?b917:49)
    at new MDCRipple (index.js?81af:28)
    at Function.attachTo (index.js?81af:44)
    at rippleFactory (index.js?27fb:42)
    at eval (index.js?27fb:50)

My guess is that the ripple is simply not set-up correctly for the TopAppBar, but alas.

should be updated in next push

https://material.preactjs.com/component/top-app-bar


Training issue

During training, if testset evaluation is removed, then model returns a different result.  That is if we Remove  lines
print("Expert 1 - Test")
dice_test = eval(test_loader, criterion_seg, model, n_classes=n_classes)
from the below code, training result is different.
        if t % 10 == 0 or t > 45:
        print("Epoch", t, "/", iterations)
        print("Validation")
        dice = eval(val_loader, criterion_seg, model, dice_s=True, n_classes=n_classes)
        print("Expert 1 - Test")
        dice_test = eval(test_loader, criterion_seg, model, n_classes=n_classes)

Is it implies the evaluation affects the model parameters? That's why we are getting a different result?
model.eval()  is given in eval function. But still results are different. Why?

Found same issue. Can anyone clarify on this


phi 3.5 moe usage

The model_downloader.py script doesn't list the recently supported phi 3.5 moe.
I'd like to also know if it's ok to use the v0.3 release from Jul 6 as-is to run it.
Thanks!

microsoft/Phi-3.5-MoE-instruct/??????????????????????????

how to convert microsoft/Phi-3.5-MoE-instruct to gguf?

@GlasslessPizza You can try the latest v0.4 or build it yourself.
You can use -m :phi3.5:moe in Python binding.

@ayttop Sorry, GGUF is not supported. This project uses something like the old GGML file format.

Can the form be converted to ggml     and any body convert it to gguf>?

No.


[i18nIgnore] i18n(fr): Add integrations-guide/solid-js in French language

Description (required)
Add integrations-guide/solid-js in French language + edit the original text for "the the"

Related issues & labels (optional)

Linked to https://github.com/withastro/docs/issues/6052
Suggested label: i18n

Thanks @thomasbnt, could you move the English change out of this PR into its own? i18nIgnore affects all files, and therefore that also means the translation won't be marked as done when we merge this.

Thanks @thomasbnt, could you move the English change out of this PR into its own? i18nIgnore affects all files, and therefore that also means the translation won't be marked as done when we merge this.

Oh yep, I split that!

This is good, @Yan-Thomas, I removed the change on english file. https://github.com/withastro/docs/pull/6268


Add a Contributor License Agreement

Added integrations for CLA Assistant and Travis.

 You should sign our Contributor License Agreement in order to get your pull request merged.

@mnishizawa please look at this.


[zh] Translate kubeadm kubeconfig command reference

This PR renames the kubeadm kubeconfig command reference as did in the
English upstream.

/lgtm

/approve


fix(react-email): Extra rough edges

Fixes a now-and-then issue that would happen with the main page erroring due to the useSearchParams deep inside the Sidebar without a Suspense above it
Adds a Suspense inside of the Preview page to avoid it de-opting into client-side rendering warnings
Fixes tooltip for toggling the Sidebar on the desktop being cut off by the Sidebar
Fixes the background for emails being defaulted to black which caused a blank email with text to have black text on a black background
Upgrade Next to the latest (14.1.0)
Redirects users back to / if the email for the slug is not found
Show only the filename on the title of the preview instead of the path to it
Show only the filename on the Topbar instead of the path to it
Fix the issue with no emails being shown on the Sidebar if the project was inside a folder prefixed with a _
Uses a catch-all route for the preview page to avoid having to encode the slug in
Fixes the build not working properly with subdirectories due to an improper static parameters generation
Fixes missing Sharp dependency on .react-email/package.json when building which caused warnings

To-do list to help break this down into other PRs:

[ ] Fixes a now-and-then issue that would happen with the main page erroring due to the useSearchParams deep inside the Sidebar without a Suspense above it
[ ] Adds a Suspense inside of the Preview page to avoid it de-opting into client-side rendering warnings
[x] Fixes tooltip for toggling the Sidebar on the desktop being cut off by the Sidebar

#1200

[x] Fixes the background for emails being defaulted to black which caused a blank email with text to have black text on a black background

#1200

[x] Upgrade Next to the latest (14.1.0)

#1198

[ ] Redirects users back to / if the email for the slug is not found
[x] Show only the filename on the title of the preview instead of the path to it

#1197

[x] Show only the filename on the Topbar instead of the path to it

#1197

[ ] Fix the issue with no emails being shown on the Sidebar if the project was inside a folder prefixed with a _
[ ] Uses a catch-all route for the preview page to avoid having to encode the slug in
[ ] Fixes the build not working properly with subdirectories due to an improper static parameters generation
[ ] Fixes missing Sharp dependency on .react-email/package.json when building which caused warnings


actionmenu: support nav use cases

[ ] Learn what all the use cases are
[ ] Support arbitrary content
[ ] Support mobile experience ("slide, replace, back" experience)

@sweeting Will you please add the use cases that you think we need to support here?  (Anything beyond current capability to support what is in your most recent designs.)

Team meeting last Fri: This component might be a good place to test some of our more composable component concepts.  We don't want to have to update ActionMenu to support all the many new features that could/should be added.
Possibilities:

"Popover" component?
"ActionMenu" component inside?
Atomic design principles
Name matching with Figma symbols


Plugins Ongoing Improvement Tracking Ticket

Chris and I are making a list of improvements to the plugins commands

[ ] Track if plugins that did not load correctly and don't include them in the `available plugins
[x] Display if a plugin got uninstalled correctly.
[ ] Able to uninstall all plugins from an ape-config.yaml file (this is really helpful for developers testing out plugins lol)
[ ] Iline 96 if display_all could just be else. not sure what we meant.
[ ] Make plugin versions aligned in list output
[ ] Refactor: Move logic that builds up the output to the PluginManager. Then, all the CLI does it call into that and maybe check a few other things regarding edge cases. This will also help the ape console because it can then easily see the same output without having to exit the console first.
[ ] Handle multiword plugin names by converting underscore to hyphen (just use clean_method_name() method).
For example, ape-tq-tezos (doesn't actually exist) should be ape plugins add tq-tezos. The package will be named ape_tq_tezos however.
[x] Fix ape-tokens bug
[ ] Check and update plugins

I would like a way to update plugins via ape commands

There was an issue with installing ape-token via ape plugins add tokens
WARNING: Error loading plugin package 'ape_tokens'.
        ImportError: cannot import name 'SIGNED_INTEGERS' from 'ape.managers.converters' (/home/chris/ape/src/ape/managers/converters.py)
        (Use `--verbosity DEBUG` to see full stack-trace)

This should be fixed now!

yes i confirmed it with jules thank you!

edge case: If you want to install or uninstall a list of plugins and you are in the WRONG Current Working Directory
we should prompt the user that the program tried to find the list of plugins at this current working directory. so they know why the list of installed plugins did not change.

This one is really important!  https://github.com/ApeWorX/ape/issues/269
It has its own ticket but follows the same sentiment

This one is also related: https://github.com/ApeWorX/ape/issues/383


launching in a locale from command line fails

install the French language pack.
Try re-opening in French from command line: code-insiders . --locale=fr. I am following what it says here.
Still in English :bug:

Changing language from the command palette works, so I'm not sure where the failure is.

Weird- I have this new output log:

Oh, I was able to get it in english?

@andreamah can you try this again? There was a bug fix last week around the --locale parameter.
Also, that Expected...... output channel doesn't seem localization related... what does it come from?

I don't see this anymore... I'll just close for now.


screen:// only 1fps

I have an issue / a question (pick one) about Vlc.DotNet.
Generic information

Vlc.DotNet version : (2<IP_ADDRESS>)
Vlc.DotNet project used : (WinForms+WPF+Core)
libvlc version : (x64)
.net version : (2.0)
Project language : (C#)
Project build architecture : (AnyCPU (prefer 32bits))
Operating system : (Windows 10) (x64)

Summary
i'm currently trying to modify VRPlayer so it can capture screen and project it as barrel projection.
in simple command line i just type "vlc screen:// :screen-fps=120 :live-caching=0" and it just working properly 120fps and no delay.
now when i do same thing on vlcdotnet using this code
try
{
ClearPlaylist();
var screen = "screen:// :screen-fps=60 :live-caching=0";
_player.Media = new LocationMedia(screen.ToString());
_player.Play();
IsPlaying = true;
HasChapters = true;
}
i'm getting 1 frame/second whatever i do. can you help me or i do some mistake.. anything appreciated

[x] I confirm that my issue doesn't happen in VLC itself.

Vlc.DotNet 2011 looks like an old version that I never met and that is therefore not supported anymore. Are you really using .net framework 2.0? How could you be using WPF then? You didn't mention the version of libvlc you are using. is it a 3.0.1?
That being said, it sounds weird to me that you pass the media options in the same string as screen:// . In newer versions of Vlc.DotNet, you have a Play method that takes two arguments : the media (screen://) and the media options (the array of the two options). Could you try that? In case it doesn't exist, could you upgrade to latest version of Vlc.DotNet? We still support 2.0 for now, but I'm not sure it will stay like that in the future.

No update for a long time. I'm closing this. Please reopen if help is still wanted.