Implement clone_tree() using overloaded BaseClass::DeepClone() (and fixing a bug ?)

The original implementation used a gigantic switch/case
statement with lots of C-style casts.
C++ offers an opportunity to do that type-safe and more readably.
Impelement a BaseClass::DeepClone() method instead, essentially
with the same implementation, but for each class separately.
Using covariant return types, this is now also type-safe and
avoids most of the casts (except the dynamic casts).
Compilation time for clone_tree.cpp went down from many minutes
in -O3 to < 30 seconds.
So it could be removed from the optimization excempt list in
cmake.
I expect clone_tree() to go away in favor of directly calling
DeepClone(), but left it in for now for backward compatibility.
(... with a one-line implementation).

As an example how it looks, here is a snippet from the previous switch/case statement in clone_tree() with lots of forced C-style casts:
 // ... somewhere in middle of switch/case
  case vpiTchkTerm: {
    tchk_term* clone_obj = s.MakeTchk_term();
    unsigned long id = clone_obj->UhdmId();
    *clone_obj =  *((tchk_term*)root);
    clone_obj->UhdmId(id);
    clone = clone_obj;
    clone_obj->Expr((expr*) clone_tree(((tchk_term*)root)->Expr(), s, elaborator));
    clone_obj->Condition((expr*) clone_tree(((tchk_term*)root)->Condition(), s, elaborator));
    break;
  }
  case vpiNetBit: {
    net_bit* clone_obj = dynamic_cast<net_bit*>(elaborator->bindNet(((net_bit*)root)->VpiName()));
    if (clone_obj == nullptr) {
      clone_obj = s.MakeNet_bit();
    }
    unsigned long id = clone_obj->UhdmId();
    *clone_obj =  *((net_bit*)root);
    clone_obj->UhdmId(id);
    clone = clone_obj;
    if (auto vec = ((net_bit*)root)->Exprs()) {
      auto clone_vec = s.MakeExprVec();
      clone_obj->Exprs(clone_vec);
      for (auto obj : *vec) {
        clone_vec->push_back((expr*) clone_tree(obj, s, elaborator));
      }
    }
    if (auto vec = ((nets*)root)->Ports()) { // ...
   // ... and so on

In the new implementation, each of these parts is now created as an implementation of
virtual BaseClass* DeepClone(Serializer* serializer, ElaboratorListener* elab_listener) const;

... of which the overriding methods use a narrower covariant return type; so tchk_term::DeepClone() actually returns a tchk_term*
The equivalent snippet from above is now looking like this:
tchk_term* tchk_term::DeepClone(Serializer* serializer, ElaboratorListener* elaborator) const {
  tchk_term* const clone = serializer->MakeTchk_term();
  const unsigned long id = clone->UhdmId();
  *clone = *this;
  clone->UhdmId(id);
  if (auto obj = Expr()) clone->Expr(obj->DeepClone(serializer, elaborator));
  if (auto obj = Condition()) clone->Condition(obj->DeepClone(serializer, elaborator));

  return clone;
}

net_bit* net_bit::DeepClone(Serializer* serializer, ElaboratorListener* elaborator) const {
  net_bit* clone = dynamic_cast<net_bit*>(elaborator->bindNet(VpiName()));
  if (clone == nullptr) {
    clone = serializer->MakeNet_bit();
  }
  const unsigned long id = clone->UhdmId();
  *clone = *this;
  clone->UhdmId(id);
  if (auto vec = Exprs()) {
    auto clone_vec = serializer->MakeExprVec();
    clone->Exprs(clone_vec);
    for (auto obj : *vec) {
      clone_vec->push_back(obj->DeepClone(serializer, elaborator));
    }
  }
  if (auto vec = Ports()) { // ...

Not only is this now using the C++ features, it is also clear that we don't have to use C-style casts anymore, as we actually get the correct type back. Thus we can also be more sure that things are correct.
CAVE: difference in Surelog tests; a fixed bug ?
Running this with Surelog shows actually four differences. I have not drilled down entirely yet why the difference is there, but I believe it actually is fixing a bug from the previous version.
Difference in logs are for

tests/JKFlipflop/JKFlipflop.log
tests/StructVar/StructVar.log
tests/WildConn/WildConn.log
tests/FSMBsp13/FSMBsp13.log

In all these cases, a vpiInstance appears in the UHDM dump where it wasn't before.
So the JKFlipFlop test has the following diff for instance

Maybe there was a bad type-cast in the version before which made this not show up before ? If this looks correct, then we're ready to merge.
If this is unexpected, so a vpiInstance should not be there, then don't merge - and I'd be happy about suggestions how to further drill this down because I think this new implementation is the way to go and we should fix if there are any bugs.

The top level modules seems to have inherited a new relation, their vpiInstance points to themselves for these cases.
Strange that it does not happen systematically. If there is a bug, there is still a bug even in the new implementation. All top level modules in all tests should see this new relation.
Seems harmless enough, although clients need to make sure they don't run into infinite loops (It is a back-pointer pointing upward in the tree).
After merging I'll know more.

I can see now, it's not at the top level, but actually one level of instantiation below.
The 4 tests are the only tests that have sub instances, so the new data is systematic it seems.

So is it as expected and correcxt ? Or did the change uncover something that was hidden before ?

@hzeller This was a very good change. Each class specific implementation of DeepClone is still implementing the cloning for what belongs to the base class. Shouldn't the subclass implementation call something in the base class to do the job.
void Base::DeepCopy(Base *const instance) const {
...
}

void Derived::DeepCopy(Derived *const instance) const {
    Base::DeepCopy(instance);
    ....
}

Derived* Derived::DeepClone() const {
    Derived *const instance = MakeInstance();
    DeepCopy(instance);
    return instance;
}

That way each class implementation is dealing with its own members rather than every member hierarchically up.

I remember I was in a big string of various changes in this regard, but then my attention got focused on something else, so it might well be that not all fruit is picked yet.


maud_lints panics when using a Fn, FnOne or FnMut argument

On branch better-lints:
Consider this:
#[test]
fn lint_closure() {
    fn notice<F>(note_fn: F)
        where F: FnOnce() -> String
    {
        let to_log = note_fn();
        println!("Notice: {}", to_log);
    }

    notice(|| html! { event "Started" }.into_string());
}

with #![plugin(maud_lints)], causes:
error: internal compiler error: /checkout/src/librustc/hir/def.rs:166: attempted .def_id() on invalid def: Local(NodeId(115)).
This is due to https://github.com/lfairy/maud/blob/1cf6a13966667739cc03b7df167ee294ec51f8c2/maud_lints/src/maud_lint.rs#L29 trying to call def_id() on a Fn argument, which is a NodeId.
I really don't know much about Rust HIR, so I may be missing something ?

My best guess is it's trying to find the definition of the closure's type, which fails because closure types are anonymous.
I admit I don't know much about HIR either. Most of that code was copied from Clippy a while ago.
If you have the time, can you please check how Clippy finds the definition for a type? It's likely that Clippy has fixed this issue themselves already.

I can't reproduce this with the current master. Closing as fixed.


Active Negotiation | Design Architectural Change - Outlet and Overlay

Post Message is not permitted on many browsers including; Safari (MAC, IOS), Brave, Chrome (IOS).
As a work around to this problem, the use of Access API & Cookies can be used.
See branch; https://github.com/TokenScript/token-negotiator-examples/tree/wip-access-storage
Technical Requirements:
Fab Button

Re-work how the Fab button is added to a client window. E.g. Scrape the HTML from Iframe and inject it into client html container.

Tokens through Iframe

Inject the Overlay module into the Outlet (library itself can be left un-touched to do this step)
Apply Access Storage API to allow Safari to read cookies (click button from within the Iframe, e.g. activate Negotiation)
When user clicks fab button, the Iframe is injected as before / or shown, hidden if this can be done.
Add Iframe button listener inside top window to read tokens, this via cookies.
Finding the tokens within the cookie, store them in the top windows local storage (attestations)
Utilise existing logic to update the client e.g. Hotel Bogota to re-learn the tokens on each user change.
Ensure that the passive negotiation is not impacted by such design changes.

https://www.adoclib.com/blog/local-storage-cross-domain-safari-disables-it-by-default.html

Links to test postMessages

Add value to localStorage https://testshop.antopolbus.rv.ua/iframe/init.html
Open https://antopolbus.rv.ua/test/iframe_postMessage.html and click "Open Popup"

lines like 'received postMessage from child: {"iframeCommand":"ttt2","iframeData":"data from child"}' should appear every 5 sec
how it works:

https://testshop.antopolbus.rv.ua/iframe/init.html adds record to the localStorage.
https://antopolbus.rv.ua/test/iframe_postMessage.html opens https://testshop.antopolbus.rv.ua/iframe/ in the new tab
https://testshop.antopolbus.rv.ua/iframe/  reads data from localstorage and postMessage it to the parent
https://antopolbus.rv.ua/test/iframe_postMessage.html display value.
in 7 seconds parent tab will close child tab.

@nicktaras , can you test it in your devices to know if it works?

Closing this issue where the fix has now been implemented.
Thanks for your demo to show how tokens can be stored via a tab Oleh.


Unknown Provider error when using minified ui-codemirror.js

Hi,
When using the ui-codemirror directive in production (bundled and minified using ASP.NET MVC) I get the following error:
Unknown provider: nProvider <- n <- uiCodemirrorDirective
This is caused by the dependency uiCodemirrorDirective (on line 13 of  ui-codemirror.js) is minified to the character 'n' and of course AngularJS does not know what to inject in.
The fix is very simple.
on line 8 of ui-codemirror.js simply provide an array which states the required dependencies as strings:
.directive('uiCodemirror', ['$timeout', 'uiCodemirrorConfig', uiCodemirrorDirective]);
Cheers

:+1:

@patrix2001 would you please make a pull request?

It is really helpful! Thank you!

Still not fixed (?)

FWIW, I forked the repo and added the fix mentioned in this issue. See above referenced commits for how to point to the fork instead of the official repo, if you'd like.

@mikecrittenden you saved my day.
Is there a chance this added line was in the official repo?

@daohodac I don't think so - the official repo hasn't had a commit in almost 3 years.

Having the same problem


Separate components to sc cc.

Separate components to Server Component and Client Component, if I can.

Abandon to change Listing Component to Server Component.
Because of pagination needs event handling and state changes disabled on Server Components.
But I could apart large components into smaller ones.


Clean up HotBar references, add discovered fields

Add HotBars as a FixedSizeArray to replace HotBar.
Add friendly fields StandardHotBars and CrossHotBars. These don't exist in the game's code (probably), but exist to make devs happy.
Add PetHotBar and PetCrossHotBar for pet actions, roleplay, and similar.
Add ScratchSlot, used for temporary memory operations.
Add docs to HotBarSlot#Set to prevent future confusion for people

I'm also going to try to sneak in a couple changes to Program.cs that I've had locally for a while. If these are undesired (a script reads from the output, perhaps?), let me know - more than happy to remove 'em.


Python 3 support

Adds Python 3 support to nanshe. This is still very much a WIP, but this should be rebased to include only the necessary changes to nanshe without the scikit-learn or other changes once ready.

Now at least conda can install the needed dependencies for Travis CI to run. Looks like docstring-coverage didn't want to build on Python 3. I don't know if it is compatible so we have skipped it for now and added a workaround on Travis CI. Also, we need a package for python-coveralls for Python 3. However, we have skipped this for now as it doesn't build cleanly and we won't need it until the tests actually pass.

Have fixed nearly all of the doctest issues. There are still two failures, but they are representation of object issues and not failures of any real merit. For now they will be ignored and focus will be placed on fixing up the test suite to run. These doctest issues will be revisited when we are done with that work.

We have now made the minimum changes required to get the test suite to run on Python 3. However, we still have not fixed the errors that it raises. This will require a bit more work to get straightened out.

So, this appears to fix the bulk of the Python 3 errors. There are still some remaining ones.

The aforementioned doctest issues.
[].sort() doesn't take a cmp argument.
Some string matching issues with the logger. (should just turn all of these back to doctests)
Unicode issues with filenames saved to HDF5. (coverter)
The class and method wrapping appears to be broken.

Also, this appears to be the last working commit on Python 2.x. ( https://github.com/nanshe-org/nanshe/commit/cea8fbfff4165287786279d9f6eb5df359087c52 ) So, will need to figure out how this was broken and fix it.

Fixed the Python 2 import issue.

Appears Travis CI now can't install SGE. Also, appears that wercker/git/versioneer are not playing nice either.

At this point, this works. However, it needs some cleaning up before it can be merged.

Separate out unrelated changes into other PRs (merge first if acceptable).
Remove changes that were only relevant for testing (turning off the logger, removing the viewer, CI for Python 3 (requires scikit-learn fixes), etc.)
Squash any intermediate changes that were reverted or later changed.

Once these are completed and back in this PR, it can be merged.

Simply waiting for it to test out at this point. Once it does all the commits related to CI, scikit-learn, making SPAMS optional, etc will be removed.

All of the unnecessary portions have been removed. This is ready to go once it passes.

Only coveralls is failing due to a small drop in code coverage. This is likely due to the Python 3 code cases that we have added that don't run on Python 2 and are not being tested in this PR. They can safely be ignored as the CI testing code is in this PR ( https://github.com/nanshe-org/nanshe/pull/373 ), which demonstrates that this code works and the code coverage is not decreasing.
Testing on the cluster for the 3D cases on both Python 2 and Python 3. Assuming all goes well we can merge this.

Pass the full (including 3D) test suite on the cluster using Python 2 and Python 3. This is ready to merge.

...and its in. Of course, to actually support Python 3.x we will need some changes to be accepted in scikit-learn.


DS Test - Icons are not working

Added Header and Footer.
Social media icons and search icons not showing up.
It can be fixed by adding this code to the head:

<script
      src="https://kit.fontawesome.com/d8a8ced9a9.js"
      crossorigin="anonymous"
    ></script>

Link to the preview: link
Before(icons not shown):

After adding code to fix it:

Aaaah, that's a mean bug! Thanks for reporting it :)
I ran @pmor80  through what I think may be the cause may well be. If that's the case, the solution is likely an adjustment to our Webpack bundling so our CSS and JS files reference assets in a way that works on any domain, and any URL path.

I ended up posting a question on SO: https://stackoverflow.com/questions/76859218/webpack-to-output-non-root-relative-urls


Inverse Trignometric Identities resolved

Related Issuse
#298
Closes: #298
Describe the changes you've made
Removed the disappearance of Inverse trigonometric identities
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.

Screenshots

@sairish2001 please review it!


Add "enable_nested_fields" configuration flag to enable nested fields

Thank you @tbressington, it is now merged and available in tag v0.7.7 of the bundle


CASMINST-4552: Linting

More MitchLint. No content changes.
csm-1.2 backport:
https://github.com/Cray-HPE/docs-csm/pull/1524
csm-1.0 backport:
https://github.com/Cray-HPE/docs-csm/pull/1533

The force pushes this afternoon and evening were just rebases to make sure there was no further linting needed


Support ES6 syntax

CommonJS syntax works
Currently I have the following karma config:
var webpack = require('webpack');
var RewirePlugin = require('rewire-webpack');
var rewirePlugin = new RewirePlugin();

module.exports = function (config) {

  config.set({
    files: ['mjs/my_test_rewire.js'],

    browsers: ['PhantomJS'],
    frameworks: ['jasmine'],

    preprocessors: {
      'mjs/my_test_rewire.js': ['webpack', 'sourcemap']
    },

    webpack: {
      resolve: {
        extensions: ['', '.js', '.jsx']
      },
      module: {
        loaders: [
          { test: /\.(js|jsx)$/, exclude: /node_modules/,
            loader: require.resolve('babel-loader') + '?optional=runtime' },
        ]
      },
      devtool: 'inline-source-map',
      plugins: [ rewirePlugin ]
    }
  });
};

Running the following karma test:
// my_test_rewire.js
var foo = require('./foo');
var rewire = require('rewire');

var fooRewired = rewire('./foo');
fooRewired.__set__('barText', 'dong!');

describe('Rewire test', function() {
  it('should say bar!', function() {
    expect(fooRewired.doBar()).toEqual('dong!');
  });
});

The test pulls in the following dependency:
// foo.js

var barText = require('./bar');

var foo = {
  doBar:function(){
    return barText;
  }
}

module.exports = foo;

Which pulls in another dependency to be mocked:
// bar.js
module.exports = 'bar!';

Which all works like a charm.
ES6 syntax does not
The problem is our source code is all transpiled using ES6 and ES6 modules. So the following does not work and causes an error:
//my_test_rewire.js

import 'es5-shim';
import 'jasmine-jquery/lib/jasmine-jquery';

import foo from './foo';
import rewire from 'rewire';

var fooRewired = rewire('./foo');
fooRewired.__set__('barText', 'dong!');

describe('Rewire test', function() {
  it('should say bar!', function() {
    expect(fooRewired.doBar()).toEqual('dong!');
  });
});

// foo.js
import barText from './bar';

var foo = {
  doBar:function(){
    return barText;
  }
}

export default foo;

// bar.js
export default 'bar!';

The error returned is:
PhantomJS 1.9.8 (Mac OS X) ERROR
  TypeError: 'undefined' is not an object (evaluating '__webpack_require__.m[module].call')
  at /Users/rudi/teg/teg-site/mjs/my_test_rewire.js:125:0 <- webpack:///~/rewire-webpack/lib/rewire.web.js:10:0
PhantomJS 1.9.8 (Mac OS X): Executed 0 of 0 ERROR (0.142 secs / 0 secs)

Even if the test remains in commonJS syntax the test runs but the rewiring fails. Are there any work arounds here at all until the point at which rewire will work with ES6?

Just wanted to chime in here, experiencing the same issue. ES6 was working just fine with<EMAIL_ADDRESS>However upgrading to<EMAIL_ADDRESS>broke this functionality.

Also experiencing the same issue, with the same setup. Does anyone have any workarounds outside of downgrading babel? Seems like not using import statements works, and other ES6 syntax is fine.

Mhmm ... I don't know much about babel, but rewire is using the given module loader to inject these setters, so as long as they don't mess with the module loader there should be no problem. Could you find out which variable is undefined?

From my debugging, the problem comes from this line:
https://github.com/jhnns/rewire-webpack/blob/master/lib/rewire.web.js#L10
In older versions of Babel, the value of module is the corresponding Webpack module id (i.e., if you import jquery, and Webpack maps that to an id of 5, then module = 5, and __webpack_modules__[module] becomes __webpack_modules__[5].
In Babel 5, the value of module is jquery, and __webpack_modules__[module] becomes __webpack_modules__["jquery"], which is undefined:
'undefined' is not an object (evaluating '__webpack_require__.m[module].call')

Best guess is that somewhere import statements are no longer being converted to Webpack ids. Not sure if this is a Babel thing, a Webpack thing, or a Rewire thing. But I'm not seeing this issue with any other plugin.

So, does it work if you deactivate the babel compiler for all modules within rewire-webpack? They're plain old ES5 anyway :)

Babel doesn't touch node_modules or rewire-webpack. Not in my environment anyway.

See https://github.com/jhnns/rewire/issues/55 as well.

Welp, what I'm experiencing is exactly same as what people saying. I just switched most of my codebase to ES6 module syntax and a few tests using rewire are failin' ... Is there anyone have duktape'd this problem?

I found where the problem comes from. babel and rewire-webpack both actually causing the issue...
rewire-webpack assumes modules to be declared within module scope as same varname (if import foomodule from 'foomodule' then rewire-webpack expects foomodule to be available in module)
When rewiring, rewire-webpack prints module and rewiring declaration (__set__, __get__)into another module. However, (I assume this behavior comes from Babel > 5) transforms module names get prefixed. like _foomodule, _foomodule2, etc. So foomodule won't be available in module level in this case.
Well, this is what I've found out, but not sure who's responsible to fix this. ;)

Thanks for tracking that down @sairion!  Yeah, I just started noticing how Babel 5 is rewriting quite a bit of stuff.

Awesome, @sairion :+1:. I'm looking forward to any progress. Will see if I can help out too :smile:.

Wow, that's tricky. Thx for investigating @sairion, that's really a big help!

rewire and rewire-webpack are both affected. We could probably do something about the first problem (e.g. parsing the module when the rewire-loader is applied), but the second one is imho impossible to solve on my side.

If it helps, I've also set up a small repository demoing the conflict. Just run webpack and load the resulting bundle in a script tag to see the issue.

:+1: What the latest on this? Encountering the same thing with webpack/karma/webpack-rewire

@bradbarrow, this is the suggested alternative:  https://github.com/speedskater/babel-plugin-rewire

The suggested alternative is not working for me. See https://github.com/speedskater/babel-plugin-rewire/issues/28. Did any of you encounter this before?

+1

Any news on this so far?
I'm having the same issue with babel-plugin-rewire.
A possible workaround is assigning the imported module to a variable:
import React from 'react';
import { defineMessages, injectIntl } from 'react-intl';

import LinkListPopover from 'elements/LinkListPopover';
...js

const LinkListPopoveR = LinkListPopover;

class NotificationPopover extends Component {
    static propTypes = propTypes;

    render() {
        const { formatMessage } = this.props.intl;

        const unread = filterTruthyValues(this.props.items, 'unread');

        const emptyState = {
            icon: 'check',
            text: formatMessage({ id: 'notificationPopoverEmpty' })
        };

        return (
            <LinkListPopoveR
...

Here my deps:
    "babel-loader": "6.2.1",
    "babel-plugin-add-module-exports": "0.1.2",
    "babel-plugin-rewire": "1.0.0-beta-2",
    "babel-plugin-react-intl": "2.1.1",
    "babel-plugin-transform-class-properties": "6.4.0",
    "babel-plugin-transform-object-rest-spread": "6.3.13",
    "babel-polyfill": "6.3.14",
    "babel-preset-es2015": "6.3.13",
    "babel-preset-react": "6.3.13",
    "babel-register": "6.4.3",
    "webpack": "1.12.12",
    "webpack-dev-server": "1.14.1"
...

I'm sorry, I don't know. ES2015 module have some new challenges, like immutable live-bindings, and since rewire is tightly coupled to the module system, it's not easy to find a good solution for this. The situation gets even more complicated since there is no JS engine yet that implements native ES2015 modules. So, a possible solution would be a workaround for the babel transpiler only. But I would like to find a solution, that will also work with native ES2015 modules.

I'm experiencing the same issue using TypeScript as a loader in webpack:
TypeError: undefined is not an object (evaluating '__webpack_require__.m[module].call')

It does not work with either ES6 or require syntax (using import xyz = require('./xyz')).
Any progress? I'm unsure how else I can mock my dependencies. I'm using webpack+karma+mocha+typescript (ts-loader), all the latest versions available in npm as of today.


[runtime-security] make sure arm64 is not interpreted a ia32

What does this PR do?
When the system is not x64, we assume that it's an intel 32 bits system. But it could be something else like arm64 now that we have arm builds.
I suppose we could also add a case like, but I wasn't too sure about the specifics so I didn't do it
	case "armv7l":
		RuntimeArch = "arm" // Not sure which value to put here

It should be a no-op because we only do something if RuntimeArch == "x64", but I think it's worth adding another case here in case ia32 is used for something
It also updates ebpf dependency to the lastest version, that include a fix for a panic
Motivation
I was running the agent agent on arm64 (image datadog/agent-arm64:7.24.0-rc.5-jmx on a raspberry pi, with ubuntu 64bits) and got into this issue https://github.com/DataDog/datadog-agent/issues/6418.
I've seen the code has been moved to our eBPF repo so I made a PR https://github.com/DataDog/ebpf/pull/25
I went a bit up on the call stack to see if there was any obvious things that would broke and notice this potential problem
Additional Notes
Sorry I couldn't put up labels and milestone and all, it looks like I lost my rights on the repo (also why I had to fork it on my own github account)
Describe your test plan
Does the CI generates a binary ? i'd be happy to test it on my RPi

@achntrl Can you run go mod tidy on your PR? That should get rid of the duplicate in go.sum.


Modify staging release buildspec to support batch builds

This PR modifies the staging release buildspec to support Codebuild batch builds.
/hold
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I have included projecs in the buildspec that correspond to non-production-ready providers, like cloudstack and all of the Tinkerbell ones. Do we still need to build them? If not I can remove them.

/unhold


Updating vip doesn't remove session persistence

Updating a vip to have 'session_persistence': None doesn't remove the session persistence from the virtual server port.
The update should include (for an api v21 device) "source_ip_persistence_template":""
The lbaas v1 persistence handler (in a10_neutron_lbaas/v1/handler_vip.py) does nothing if the session persistence is none, and None is passed to the acos client (in acos_client/v21/slb/virtual_port.py) for both s_pers_name=None, c_pers_name=None.
class PersistHandler(object):

    def __init__(self, c, context, vip, vip_name):
        self.c = c
        self.context = context
        self.vip = vip
        self.c_pers = None
        self.s_pers = None
        self.name = vip_name

        if vip.get('session_persistence', None) is not None:
            self.sp = vip['session_persistence']
            if self.sp['type'] == 'HTTP_COOKIE':
                self.c_pers = self.name
            elif self.sp['type'] == 'SOURCE_IP':
                self.s_pers = self.name
            else:
                raise a10_ex.UnsupportedFeature()
        else:
            self.sp = None

The api v21 acos client doesn’t submit anything when s_pers_name=None, c_pers_name=None. minimal_dict removes the Nones, which would probably be JSON nils instead of empty strings.
     def _set(self, action, virtual_server_name, name, protocol, port,
             service_group_name,
             s_pers_name=None, c_pers_name=None, status=1, **kwargs):
        params = {
            "name": virtual_server_name,
            "vport": self.minimal_dict({
                "name": name,
                "service_group": service_group_name,
                "protocol": protocol,
                "port": int(port),
                "source_ip_persistence_template": s_pers_name,
                "cookie_persistence_template": c_pers_name,
                "status": status
            })
        }

This needs to be fixed in both 1.3 and 1.4 series drivers. We should check to see if the same issue exists in lbaasv2.

[ ] Updating a vip (lbaasv1) to have no session persistence should remove the session persistence
[ ] Needs to be backported to the 1.3 driver. Branch off of b6fc71a7 for easy backporting
[ ] Needs to be fixed for the 1.4 driver
[ ] Check to see if the issue also exists in lbaasv2
[ ] Check to see what happens with the api v30 acos client

Fixed in #220


doesn't seem to be working with android ?

anything I could try to get it to run on android ?
it works perfectly on IOS.
thank you.

seems that it doesn't work on android in debug mode.
works well in release mode.

Any solution to make it work with debug mode as well?

+1


DLP: Transcriptomics landing page

Here are some issues I am having with the transcriptomic data set landing page:
How many transcriptomic data sets are there?
How to I get to all transcriptomic data sets from this page?
How do I get to the transcriptomic data sets for other organisms (besides the top 5) from this page?
The rationale for the "featured experiments" is not immediately obvious unless you are going to allow people to browse all experiments.  Maybe we need "more" buttons at the ends of these lists?

All of the data landing pages are now outdated or obsolete.
I am in favor of revamping them to make them more relevant to the current data and content, or getting rid of them.
-Maulik

We could check Google Analytics on those pages and see if they are getting any significant traffic.  If not, maybe we can retire them.
Ron
From: Maulik Shukla<EMAIL_ADDRESS>Reply-To: PATRIC3/patric3_website<EMAIL_ADDRESS>Date: Wednesday, February 20, 2019 at 1:08 PM
To: PATRIC3/patric3_website<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [PATRIC3/patric3_website] transcriptomics landing page (#2163)
All of the data landing pages are now outdated or obsolete.
I am in favor of revamping them to make them more relevant to the current data and content, or getting rid of them.
-Maulik
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/PATRIC3/patric3_website/issues/2163#issuecomment-465691483, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADCnWg-KCDSUOUfSHSWRo_6UpuAJc-yGks5vPY8WgaJpZM4ZJqrJ.

Would it make sense to revamp the landing pages within Patric Docs?

The information could be put there.  I suppose the links back into the website could as well, but the dynamic content is probably more challenging.
Ron
From: Chris Thomas<EMAIL_ADDRESS>Reply-To: PATRIC3/patric3_website<EMAIL_ADDRESS>Date: Thursday, February 21, 2019 at 11:21 AM
To: PATRIC3/patric3_website<EMAIL_ADDRESS>Cc: rkenyon<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [PATRIC3/patric3_website] transcriptomics landing page (#2163)
Would it make sense to revamp the landing pages within Patric Docs?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/PATRIC3/patric3_website/issues/2163#issuecomment-466063375, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADCnWr8AyW1i27peuZqtH_o4CSyZf6f0ks5vPsdqgaJpZM4ZJqrJ.

I am leaning toward having easy to maintain user guides for data types, instead of having
obsolete data landing pages.
We have major data types currently listed here.
https://docs.patricbrc.org//user_guides/data.html
This list is limited because those are the Only data types we currently have
available from the Top Nav, which is again because those are the only ones for
which we have DLPs.
With document site, we can expand the list to include more relevant data types, i.e.
subsystems, PPI, etc.
Them, for each of the data types, we can provide link to a dedicated data type user guide,
Which can describe

what is that data type
source of data in PATRIC
how data is processed / curated
what services we have for the data type
what analysis / viz tools we have
relevant CLI functions for downloading the data
link to FTP

We do not need to repeat the content of the tutorial or user guides for services/tools etc,
Just need to provide context and pointer.
I think this will be much more manageable that the current DLPs.
Thoughts?
-Maulik
On Feb 21, 2019, at 10:22 AM, rkenyon <notifications<EMAIL_ADDRESS>wrote:
The information could be put there. I suppose the links back into the website could as well, but the dynamic content is probably more challenging.
Ron
From: Chris Thomas <notifications<EMAIL_ADDRESS>Reply-To: PATRIC3/patric3_website <reply<EMAIL_ADDRESS>Date: Thursday, February 21, 2019 at 11:21 AM
To: PATRIC3/patric3_website <patric3_website<EMAIL_ADDRESS>Cc: rkenyon <rkenyon<EMAIL_ADDRESS>Comment <comment<EMAIL_ADDRESS>Subject: Re: [PATRIC3/patric3_website] transcriptomics landing page (#2163)
Would it make sense to revamp the landing pages within Patric Docs?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/PATRIC3/patric3_website/issues/2163#issuecomment-466063375, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADCnWr8AyW1i27peuZqtH_o4CSyZf6f0ks5vPsdqgaJpZM4ZJqrJ.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/PATRIC3/patric3_website/issues/2163#issuecomment-466064159, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABLd7-sGDQErSVDGsSCefOA3u-77g2Qpks5vPsfbgaJpZM4ZJqrJ.

Just to add, I like them not to have any dynamic content, which hard to maintain and update with continuous data releases.

I think maintaining through the docs site then is definitely the easiest approach. Update through GitHub whenever needed and commit the changes, then reflected automatically once it rebuilds.

I agree with Maulik's suggestion too.  Let's move forward that way.  Chris do you want to take the lead?

Yes, I'll begin to convert and we can update the content with current information.

I have added links to all bacterial and host response datasets and services and tools.


New wrap: Eigen3

I've wrapped Eigen3 in https://github.com/barcharcraz/meson-eigen3
branches and tags are already created.

https://github.com/mesonbuild/eigen
Please make pull request, we added LICENSE.build recently, so you will have to rebase your code. Thanks.


Fix ethers.WebSocketProvider tests

Definition of Done
Fix ethers.WebSocketProvider tests and move file from test-edr-failing to test

I looked into this a little. The only failing test is "contract events work".
I confirmed that the contract is created and that the contract.modifiesState(1) call has the same transaction response between EthereumJS and EDR (the only difference being the block hash, but that's expected). For some reason, the Promise onContractEvent that is returned is never triggered though, causing a timeout.


BrowserslistError: Unknown version 66 of android

I just upgraded my version of browserslist to 3.2.8, and now I have this error in my tests:
Error {
    browserslist: true,
    message: 'Unknown version 66 of android',
    name: 'BrowserslistError',
  }

  Function.select (node_modules/caniuse-api/node_modules/browserslist/index.js:622:17)
  node_modules/caniuse-api/node_modules/browserslist/index.js:151:33
  resolve (node_modules/caniuse-api/node_modules/browserslist/index.js:132:18)
  browserslist (node_modules/caniuse-api/node_modules/browserslist/index.js:224:16)
  Object.isSupported (node_modules/caniuse-api/dist/index.js:62:37)
  module.exports (dist/main.js:49:34)

from this code:
const browsers = browserslist(options.browsers);
let isFallbackNeeded = !caniuse.isSupported("css-grid", browsers);

This already happened before. I think it is due to the browserslist version used by caniuse-api being out of date, possibly because of the package-lock.json file: https://github.com/Nyalab/caniuse-api/blob/master/package-lock.json#L862
If I rollback to the same version of browserslist, the problem is gone. But I would like to be up to date if possible. Do you know how to always use the latest version of browserslist by caniuse-api ?

I note that you upgraded to browserslist v3 in the last commits: https://github.com/Nyalab/caniuse-api/commit/7e57b2d0b4ac749e1a5c74c2d1c1b78518262ec3 ; but it doesn't seem there was a new release since. Do you plan to release it in a new version ?

This is a pretty high impact bug. Everyone who upgrades to css-loader 1.0 and still wants CSS minification needs to install the latest version of cssnano; and if you install these package, then you hit the error "BrowserslistError: Unknown version 67 of android".
I'm no expert, but I believe these errors happen because the caniuse-api package is using and old version of "browserslist" and has not set the ignoreUnknownVersions flag.
See details here:
https://github.com/cssnano/cssnano/issues/537

ok, i am looking into it

this should be fixed with the 3.0.0 release, let me know if the bug is still there now


Critical setup issue Chrome/FF to OWR

There is connection setup issue on latest OWR, seems to be related to ICE and/or DTLS.
Chrome -> Bowser
0:00:20.257369000  9033    0x13da57bb0 INFO     owrlocalmediasource owr_local_media_source.c:409:on_caps:<video-source:src> Front Camera - configured with caps: video/x-raw, width=(int)640, height=(int)480, format=(string)NV12, framerate=(fraction)15/1
0:00:20.259605000  9033    0x13e31e210 INFO        owrmediarenderer owr_media_renderer.c:307:on_caps:<OwrImageRenderer@0x13d9d7200> Unknown renderer - configured with caps: video/x-raw, width=(int)640, height=(int)480, format=(string)BGRA, framerate=(fraction)15/1
0:00:24.520430000  9033    0x13db565d0 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:24.587873000  9033    0x13db565d0 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:24.665161000  9033    0x13db56a30 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:24.665210000  9033    0x13db56a30 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:24.666120000  9033    0x13db56a30 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:24.666200000  9033    0x13db565d0 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:24.718817000  9033    0x13db56a30 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:24.725035000  9033    0x13db565d0 WARN           dtlssrtpdemux gstdtlssrtpdemux.c:137:sink_chain:<dtls-srtp-demux> received invalid buffer: 1
0:00:26.692050000  9033    0x13d928000 INFO              owrsession owr_session.c:768:_owr_session_emit_ice_state_changed:<OwrMediaSession@0x13d8ccda0> Session 2, ICE state changed from connecting to ready
0:00:29.900019000  9033    0x13d928000 INFO              owrsession owr_session.c:768:_owr_session_emit_ice_state_changed:<OwrMediaSession@0x13d8ccc50> Session 1, ICE state changed from connecting to ready

Firefox Nigthly -> Bowser
0:00:09.513940000  9026    0x12d223390 INFO     owrlocalmediasource owr_local_media_source.c:409:on_caps:<video-source:src> Front Camera - configured with caps: video/x-raw, width=(int)640, height=(int)480, format=(string)NV12, framerate=(fraction)15/1
0:00:09.515728000  9026    0x12d309810 INFO        owrmediarenderer owr_media_renderer.c:307:on_caps:<OwrImageRenderer@0x12d9df200> Unknown renderer - configured with caps: video/x-raw, width=(int)640, height=(int)480, format=(string)BGRA, framerate=(fraction)15/1
0:00:28.468840000  9026    0x12d118000 ERROR             owrsession owr_session.c:765:_owr_session_emit_ice_state_changed:<OwrMediaSession@0x12d240c50> Session 1, ICE failed to establish a connection!
ICE state changed from connecting to failed
0:00:28.468891000  9026    0x12d118000 ERROR             owrsession owr_session.c:765:_owr_session_emit_ice_state_changed:<OwrMediaSession@0x12d240da0> Session 2, ICE failed to establish a connection!
ICE state changed from connecting to failed

Same problem when running Chrome -> iOS NativeDemo.

Seems to have been a problem with my build.


First cut at an ansible version of secure.sh

It doesn't create the initial user like secure.sh does, but does do the other stuff.
Also installs chkrootkit because why not.

Hmm...I think I forgot to configure unattended-upgrades. I'll add that later when I'm less tired.


skaffold dev failed with Error: uninstall: Release not loaded: frontend-org-1: release: not found

I set frontend-org-1 and frontend-org-2 to <IP_ADDRESS> (I use microk8s), and ran skaffold dev.
The error is
Release not loaded: frontend-org-1: release: not found
Build Failed. No push access to specified image repository. Try running with --default-repo flag. Otherwise start a local kubernetes cluster like minikube
I don't see any instructions on how to create this "release". Please provide a hint.

probably due to my old mac with broken repo information.


Fix deadlock regression in GL resource preview generation

An additional patch to #87229 + #88391.
Bear in mind this is brittle, as it's tailored to the current usage of the semaphore by the importers, namely, wait until rendering has happened so the preview can be captured from some viewport. Anyway, there's also the notion that all this set of PRs may be not needed anymore at some point (see #87229, where that was originally stated). EDIT: Let me add that, in case this had to stay for longer, it could be abstracted out a bit more in a way the preview generators have an API to wait for rendering to happen, leaving the sync/async details to the helpers.
Fixes #88576.
Worked well in my tests,. Please give it a try.

I don't seem to reproduce the deadlock on Linux with my test project https://github.com/team-godog/NGJ2023_Godog (running with --rendering-driver opengl3).

ERROR: Expected Image data size of 161x130x1 (DXT5 RGBA8 with 7 mipmaps) = 28848 bytes, got 29424 bytes instead.
   at: initialize_data (./core/io/image.cpp:2220)
ERROR: Condition "image->is_empty()" is true. Returning: Ref<Image>()
   at: texture_2d_get (drivers/gles3/storage/texture_storage.cpp:1045)
ERROR: Expected Image data size of 69x47x1 (DXT5 RGBA8 with 6 mipmaps) = 4672 bytes, got 4704 bytes instead.
   at: initialize_data (./core/io/image.cpp:2220)
ERROR: Condition "image->is_empty()" is true. Returning: Ref<Image>()
   at: texture_2d_get (drivers/gles3/storage/texture_storage.cpp:1045)
ERROR: Expected Image data size of 126x70x1 (DXT5 RGBA8 with 6 mipmaps) = 12352 bytes, got 12432 bytes instead.
   at: initialize_data (./core/io/image.cpp:2220)
ERROR: Condition "image->is_empty()" is true. Returning: Ref<Image>()
   at: texture_2d_get (drivers/gles3/storage/texture_storage.cpp:1045)
ERROR: Expected Image data size of 61x46x1 (DXT5 RGBA8 with 5 mipmaps) = 4128 bytes, got 4144 bytes instead.
   at: initialize_data (./core/io/image.cpp:2220)
ERROR: Condition "image->is_empty()" is true. Returning: Ref<Image>()
   at: texture_2d_get (drivers/gles3/storage/texture_storage.cpp:1045)

These errors don't happen in current master.

I've been able to repro. This is puzzling. I can't get why that happens because of this change. However, I can understand why there's a mismatch between the expected size and the passed size. The function at https://github.com/godotengine/godot/blob/b7145638d5b235e8e1b2fe039a0cee48a4bbb26d/drivers/gles3/storage/texture_storage.cpp#L999 computes the size needed to hold the obtained texture data based on alloc_width-height. Later, Image::create_from_data() is called with the real width-height, which in turns invokes the same algorithm to compute the size of the data. It's worth mentioning that the sizes of the mips that those two calls obtain are different, which leads to the mismatch.
Using alloc_width-height seems to be done to account for the size of the compressed block size. However, the function that computes the data size already takes that into account, but per mipmap. I think that's where the difference lies. Pre-compensating leads to different mipmap sizes being considered.
So, it seems there's a bug there. However, again, I don't get what that all has to do with the changes in this PR and, moreover, I don't get why such mismatch hadn't been an issue until now. I need someone lucid to help me.

This PR solves my deadlock problem on the godot_xr_template project.
While the PreviewSemaphore/wait/post works, it seems a little weird. Usually you want some result, and you internally use a semaphore to implement it. Here you're overriding a semaphore to trigger some result you want.
Would it be possible to hide:
https://github.com/RandomShaper/godot/blob/77cbbf4963fbb1181ed3f424fdf652c3d452533b/editor/plugins/editor_preview_plugins.cpp#L317-L319
inside some well-named function such as _generate_frame_draw().
That function could then do something like:
void EditorMaterialPreviewPlugin::_generate_frame_draw() const {
    // One-shot subscribe to RenderServer frame_pre_draw to detect start of next frame.
    RS::get_singleton()->connect(SNAME("frame_pre_draw"), callable_mp(const_cast<EditorMaterialPreviewPlugin *>(this), &EditorMaterialPreviewPlugin::_generate_frame_started), Object::CONNECT_ONE_SHOT);

    if (EditorResourcePreview::get_singleton()->is_threaded()) {
        // Preview is multi-threaded - wait for the preview_done notification.
        preview_done.wait();
    } else {
        // Preview is single-threaded - directly call draw.
        RS::get_singleton()->draw(false);
    }
}

void EditorMaterialPreviewPlugin::_generate_frame_started() {
    RS::get_singleton()->viewport_set_update_mode(viewport, RS::VIEWPORT_UPDATE_ONCE); //once used for capture

    // If threaded then request a callback when the frame-draw completes.
    if (EditorResourcePreview::get_singleton()->is_threaded()) {
        RS::get_singleton()->request_frame_drawn_callback(callable_mp(const_cast<EditorMaterialPreviewPlugin *>(this), &EditorMaterialPreviewPlugin::_preview_done));
    }
}

void EditorMaterialPreviewPlugin::_preview_done() {
    preview_done.post();
}

void EditorMaterialPreviewPlugin::abort() {
    if (EditorResourcePreview::get_singleton()->is_threaded()) {
        preview_done.post();
    }
}

Something like this would use the semaphore only when necessary, rather than overriding the semaphore to achieve non-semaphore side-effects.

@Malcolmnixon, I was considering doing a full abstraction in a future iteration if this turned out to have to stay for long. However, you've given me enough boost to do it now. I've gone even a bit further than what you suggested.
The texture data size mismatch issue persits, though.

For me, on a fresh project, adding a MeshInstance3D and creating a new BoxMesh is enough to completely deadlock the editor.
I haven't evaluated the code, but the changes in this PR fix the issue for me!

This is working fine for me on the test project. Many thanks!

Thanks!


Thread id should be validated to only allow supported ids.

.json uses an id to 'name' each walkthrough
We've now got a walkthrough 1A, and it seems to work as per #49
However, I note that tutorial.js seems to test whether id is a number (for localization?), so am wondering if this is right approach?

Passing in 1A will work.   We should decide on what we want to allow for checks for an ID and only allow those.

@dlabaj  closing - reopen if you see any value in it.


chore(deps): upgrade runtime dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-runtime-dependencies-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2048

Questions ?
Please refer to the Backport tool documentation


Add Openshift SCC and Install Provider

Description
This pr includes:

some security context permission fix for the Liqo pods
OpenShift SCC bindings for privileged pods
new openshift provider in the liqoctl install command

How Has This Been Tested?

[x] add unit test
[x] on an OpenShift (on Azure) Liqo peering to an external k3s cluster

/build

/test

/test

/test

Ref. #909

/rebase test=true

/merge


Trigger notification only when a change affects a filter

Describe the bug
I set up a filter on a web page monitor and the preview correctly shows me the part triggered by the filter in blue.
Every time the page has some part changed (even outside the filter) I receive a notification.
Version
v0.39.10
To Reproduce

Create a monitor for a web page
Create a filter

Expected behavior
Receive a notification only when the change affects the filter
Desktop (please complete the following information):

Debian docker

Additional context
Some days ago I set up the same page and the same filter, but the behaviour was correct and only changes falling into the filter rule triggered the notification.

not information information

Sorry, can you explain to me what information do you need (screenshot maybe?)
Thanks