Is it possible to create value/growth equality constraint?

What are you trying to do?
In the following portfolio optimization, I'd like to add a constraint so that there are equal amounts of value and growth. So, if there is 30% allocated to value, there should also be 30% allocated to growth, and vice-versa. How would I go about doing this? Thanks!
style_mapper = {
    "SPY": "blend",
    "VUG": "growth",
    "VTV": "value"
}

style_lower = {
    "blend": 0.5,
    "growth": 0.5,
    "value": 0.5
}

style_upper = {
    "blend": 0.5,
    "growth": 0.5,
    "value": 0.5
}

mu = expected_returns.capm_return(prices)
S = risk_models.CovarianceShrinkage(prices).ledoit_wolf()

ef = EfficientFrontier(mu, S)  # weight_bounds automatically set to (0, 1)
ef.add_sector_constraints(style_mapper, style_lower, style_upper)

ef.efficient_risk(0.2)
weights = ef.clean_weights()

Hi @x829901,
One way you could do this is to explicitly add the constraint
value_indices = [1, 0, 0, 1 ..., 0, 0, 1]  # 1 if value, 0 if not
growth_indices = [0, 1, 1, 0 ..., 1, 1, 0]  # 1 if growth, 0 if not

ef.add_constraint(lambda w: cp.sum(w[value_indices])
ef.add_constraint(lambda w: w @ growth_indices == w @ value_indices)

Here's an example using the data from MVO cookbook
growth_indices = [1 if i in {"AMZN", "TSLA", "MSFT"} else 0 for i in ef.tickers]
value_indices = [1 if i in {"GILD", "F", "XOM", "LUV"} else 0 for i in ef.tickers]

ef = EfficientFrontier(mu, S)
ef.add_constraint(lambda w: w @ growth_indices == w @ value_indices)
w = ef.min_volatility()
print(w["AMZN"] + w["TSLA"] + w["MSFT"])  # = 0.1404
print(w["GILD"] + w["F"] + w["XOM"] + w["LUV"]) # = 0.1404

Hope this helps!

Hi @x829901,
One way you could do this is to explicitly add the constraint
value_indices = [1, 0, 0, 1 ..., 0, 0, 1]  # 1 if value, 0 if not
growth_indices = [0, 1, 1, 0 ..., 1, 1, 0]  # 1 if growth, 0 if not

ef.add_constraint(lambda w: w @ growth_indices == w @ value_indices)

Here's an example using the data from MVO cookbook
growth_indices = [1 if i in {"AMZN", "TSLA", "MSFT"} else 0 for i in ef.tickers]
value_indices = [1 if i in {"GILD", "F", "XOM", "LUV"} else 0 for i in ef.tickers]

ef = EfficientFrontier(mu, S)
ef.add_constraint(lambda w: w @ growth_indices == w @ value_indices)
w = ef.min_volatility()
print(w["AMZN"] + w["TSLA"] + w["MSFT"])  # = 0.1404
print(w["GILD"] + w["F"] + w["XOM"] + w["LUV"]) # = 0.1404

Hope this helps!

Thanks, this worked.


Usage of calc statement sends F* into a loop

On HACL* branch protz_fstar_loop, running the following command sends F* into a loop... or at least, a computationally-intensive codepath thats sends one core to 100% with no visible CPU usage from any z3 process.
To reproduce, checkout that branch, then: make obj/EverCrypt.Hash.Incremental.fst.checked
Update: after 5 minutes, I think I briefly saw a z3 process.
This behavior can be avoided by removing the last step of the calc statement for split_at_last_small.
Update: F* still at 100% on the same proof obligation (running with --query_stats to see progress) after 10 minutes.
Thanks,
Jonathan

Reproduced on CI:

jonathan@chartreuse:~/Code/hacl-star (fstar-master) $ fstar --version
F* <IP_ADDRESS>~dev
platform=Darwin_x86_64
compiler=OCaml 4.05.0
date=<not set>
commit=ab6c911d046b13eb745b12c372629aae962569bb

I've been looking into this. It's caused by a size explosion on S.slice (S.append b d) 0 (((S.length rest + S.length d + (S.length blocks / l) * l) / l) * l). Each +, * and / points to FStar.Integers, which defines them like so:
[@mark_for_norm]
unfold
let ( + ) #sw
          (x:int_t sw)
          (y:int_t sw{within_bounds sw (v x + v y)})
  : Tot   (z:int_t sw)
  = match sw with
    | Signed Winfinite -> x + y
    | Unsigned W8   -> FStar.UInt8.(x +^ y)
    | Unsigned W16  -> FStar.UInt16.(x +^ y)
    | Unsigned W31  -> FStar.UInt31.(x +^ y)
    | Unsigned W32  -> FStar.UInt32.(x +^ y)
    | Unsigned W63  -> FStar.UInt63.(x +^ y)
    | Unsigned W64  -> FStar.UInt64.(x +^ y)
    | Unsigned W128 -> FStar.UInt128.(x +^ y)
    | Signed W8   -> FStar.Int8.(x +^ y)
    | Signed W16  -> FStar.Int16.(x +^ y)
    | Signed W31  -> FStar.Int31.(x +^ y)
    | Signed W32  -> FStar.Int32.(x +^ y)
    | Signed W63  -> FStar.Int63.(x +^ y)
    | Signed W64  -> FStar.Int64.(x +^ y)
    | Signed W128 -> FStar.Int128.(x +^ y)

That's 15 cases, and due to the unfold there, these definitions are indeed unfolded, and the operands on each side get multiplied 15 times. Of course some of those then get unfolded 15 times each too, and we explode exponentially.
(Your file actually succeeds after 9 hours :) )
Dumping some thoughts:
I guess the problem is that F* is not solving sw to be Unsigned W8 (they are just uvars at the time where this explodes). I found that removing the unfolds from FStar.Integers will fix this, but they might really be needed. Another idea is to change the match to remove the ocurrence of x and y from its body. Something like (match sw with | Unsigned W8 -> FStar.UInt8.(+^) | ...) x y, but not sure that will work.

Is it really just exploding on elaborating S.slice (S.append b d) 0 (((S.length rest + S.length d + (S.length blocks / l) * l) / l) * l)?

This works out easily:
module I
open FStar.Integers
let test (x1 x2 x3 x4 x5 x6 x7 x8 : nat) = x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8```

But, this scales poorly:
open FStar.Integers

let test (x1 x2 x3 x4 x5 x6 x7 x8 : Prims.nat) = x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8

Things are pretty fast until x6, and then it starts to take extremely long as we go to 7 and 8.
Using FStar.Integers.nat, the unification works out easily.
Using Prims.nat, I guess there's a ton of case splits that happen in order to solve it for the implicit sw arguments and that starts to pile up and become expensive.

Ok, I think I have a fix for this.
What's happening is that we have to solve several instances of
nat::Prims.nat <: Tm_app::FStar.Integers.int_t (*?u19*) _)
For this kind of problem, we have a match elimination heuristic. (See try_match_heuristic in FStar.TypeChecker.Rel)
This involves trying to solve
  | FStar.Integers.Unsigned FStar.Integers.W8 -> FStar.UInt8.t
  | FStar.Integers.Unsigned FStar.Integers.W16 -> FStar.UInt16.t
  | FStar.Integers.Unsigned FStar.Integers.W31 -> FStar.UInt31.t
  | FStar.Integers.Unsigned FStar.Integers.W32 -> FStar.UInt32.t
  | FStar.Integers.Unsigned FStar.Integers.W63 -> FStar.UInt63.t
  | FStar.Integers.Unsigned FStar.Integers.W64 -> FStar.UInt64.t
  | FStar.Integers.Unsigned FStar.Integers.W128 -> FStar.UInt128.t
  | FStar.Integers.Signed FStar.Integers.Winfinite -> Prims.int
  | FStar.Integers.Signed FStar.Integers.W8 -> FStar.Int8.t
  | FStar.Integers.Signed FStar.Integers.W16 -> FStar.Int16.t
  | FStar.Integers.Signed FStar.Integers.W31 -> FStar.Int31.t
  | FStar.Integers.Signed FStar.Integers.W32 -> FStar.Int32.t
  | FStar.Integers.Signed FStar.Integers.W63 -> FStar.Int63.t
  | FStar.Integers.Signed FStar.Integers.W64 -> FStar.Int64.t
  | FStar.Integers.Signed FStar.Integers.W128 -> FStar.Int128.t)

by solving for the scrutinee u19 by matching the head types of the branch with the head type of the LHS. In this case, it would be to use this case  | FStar.Integers.Signed FStar.Integers.Winfinite -> Prims.int in the match.
However, since this heuristic breaks generality, we defer applying it until all else fails. So, we accumulate lots of constraints of this form for each of the + nodes in the term. Finally, when we can't defer any more, we solve for u19 as above, and all those constraints collapse easily.
That's fine, but meanwhile, what's happening is that if you look at the type of FStar.Integers.+, it is written like this:
unfold
let ( + ) #sw
          (x:int_t sw)
          (y:int_t sw{within_bounds sw (v x + v y)})
  : Tot   (z:int_t sw)

So, actually, the constraints accumulated for each of the + nodes looks like
nat::Prims.nat <: Tm_app::FStar.Integers.int_t (*?u19*) _) { **large refinement formula **}
and its that large refinement formula that blows up exponentially after unfolding.
There are two potential fixes here.

Revise the type of FStar.Integers.(+) and related operations to be of this form:

unfold
let ( + ) #sw
          (x:int_t sw)
          (y:int_t sw)
  : Pure (z:int_t sw)
    (requires within_bounds sw (v x + v y))
    (ensures fun _ -> True)

In this case, we don't build that large refinement formula during type inference and things go through fast.
This style is also better for other reasons, e.g. it works better when applying + to effectful terms. I was planning to change the library to have this style of type anyway. So, this change will come soon.
But, that's very specific to the FStar.Integers library.

We might also consider changing the priority of the match heuristic rule. Deferring it as we do aims to preserve generality for as long as possible. But that comes at a significant cost. If we applied that rule more eagerly, we would avoid this problem systematically (at the loss of some generality).

is a good fix in the short term; since you've been looking at #1612, I think once we fix these two there should be little blocking a wider adoption of FStar.Integers


CI: Switch WaitforDeamonset/Deploy to shorter poll timeout

Each poll command was given the 4 minute HelperTimeout. This was
excesive since time overall timeouts used could be shorter than this,
resulting in the poll never completing.

This change is

test-me-please

Coverage increased (+0.04%) to 44.108% when pulling c735be594587bbe57227c9c68e28374dc185e6a6 on raybejjani:smaller-waitfor-timeout into c1fb1d0af1ff2e71865fd68f41cc5c28744224a9 on cilium:master.

test-me-please

test-me-please


Wrong status code for pod creation

Describe the bug
When creating a new pod using the endpoint: POST https://fairos.fairdatasociety.org/v1/pod/new .
data: {pod_name: "Consents", password: "..."}
The pod is successfully created, but the response code is 500 and the response is:
{"message":"pod new: error uploading data","code":500}
The status code should be 200.

please follow standard return codes as in ie.

https://umbraco.com/knowledge-base/http-status-codes/
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes


Not possible to combine multiple subreddits

Generally you can have a subreddit combination /r/a+b+c and you will get stories from a, b & c.
Rtv spits out "invalid subreddit" on subreddit combinations.
(great work btw!)

I'm guessing this is an issue with PRAW. Though, looking at the docs, I still feel like this should work. While searching, I did find this
get_multireddit(multi, *args, **kwargs)

    Return a multireddit that belongs to this user.
    Parameters:	multi – The name of the multireddit
    Returns:	Multireddit object with author=Redditor and name=multi

However, that looks like it depends on the users personal multi, not creating it with the actual address.

This doesn't seem to be an issue with PRAW. This can be verified by open a python console and running the following:
In [1]: import praw

In [2]: r = praw.Reddit(user_agent='my_cool_application')

In [3]: submissions = r.get_subreddit('opensource+linux').get_hot(limit=5)

In [4]: [str(x) for x in submissions]
Out[4]:
['573 :: Dell launches Ubuntu loaded machines across 500 stores in Latin America',
 '8 :: Proprietary Scumminess: The Case of Dropbox',
 '14 :: Enormous Changes to Google Summer of Code in 2015. Over 130 projects ou...',
 '18 :: Open-Source Solutions As A Business Model',
 '37 :: PuTTY 0.64 is released']

(Notice that you get results from both /r/opensource and /r/linux. This seems to be some problem with the from_name function in the SubredditContent class (defined in rtv/content.py).

After further investigation, it would appear that this might in fact be a bug with PRAW. It seems that that problem ultimately comes down to the line:
sub = reddit.get_subreddit('linux+opensource', fetch=True)

This returns a 404 error, while setting fetch to False does not return a 404 error. So this can be fixed by bringing that line of code back in line with the rest of code base (which uses lazy objects). This issue is fixed by https://github.com/michael-lazar/rtv/pull/16

Thanks for investigating this, I'll check it out tonight. I put the fetch=True flag to verify that the subreddit actually existed. If you look in from_name(), there's a workaround for /r/all for the same reason. Have you tested your fix out with gibberish or invalid names? I remember having problems with those at the time.

Good point, it looks like this fails silently on gibberish names (due to the lazy loading not actually loading it). Due to that, I would say there are two options:

Wait until the bug is fixed in PRAW (which I might take a look at a bit later tonight)

Simply force PRAW to load it immediately afterwards by acting on the subreddit object before breaking out of the try except block (which works around the PRAW bug).

I don't mind option 2. We just have to make sure not to lose any data in the process of checking the generator. Maybe something like
content = cls('/r/'+sub.display_name, sub.get_hot(limit=None), loader)
content.get(0)  # Validate that content exists before initializing
return content

Yeah that makes sense to me.
On Mar 3, 2015 8:10 PM, "michael-lazar"<EMAIL_ADDRESS>wrote:

I don't mind option 2. We just have to make sure not to lose any data in
the process of checking the generator. Maybe something like
content = cls('/r/'+sub.display_name, sub.get_hot(limit=None), loader)
content.get(0)  # Validate that content exists before initializing
return content
—
Reply to this email directly or view it on GitHub
https://github.com/michael-lazar/rtv/issues/15#issuecomment-77077705.

Implemented via option 2. b992645


Dan/upgrade golangci lint

:nut_and_bolt: Description
Update golangci-lint to make it more usable in the hab studio

golangci-lint 1.15 is affected by a bug that occurs when in a path with
a symlink, which prevents it from properly applying `nolint` directives
in comments. In the studio, we symlink the automate source from /src
into the scaffolding gopath when you run `setup_go_workspace`; the
combination of these factors makes golangci-lint not usable in the
studio. 1.16 is supposed to contain a fix.

:+1: Definition of Done
:athletic_shoe: Demo Script / Repro Steps
:chains: Related Resources
:white_check_mark: Checklist

[ ] Necessary tests added/updated?
[ ] Necessary docs added/updated?
[ ] Code actually executed?
[ ] Vetting performed (unit tests, lint, etc.)?

Thanks for digging into this.  We vendor golangci-lint to avoid constant problems downloading it in CI: https://github.com/chef/automate/tree/master/cache . We may want to update that vendored copy?

@stevendanna done. I also brought back 1.15 for 64bit linux, since the best I could manage for compliance service was to pin. I put some of the failures I was seeing with compliance using 1.16 in the commit message for that.


improvement in @all warnings

Improvements in @all/everyone warnings as mentions in #2257.
Note: I have added stream_data and compose in predef array in ./tools/jshint/check-all.js to make linter stop complaning about their scope.

Automated message from Dropbox CLA bot
@s0nskar, it looks like you've already signed the Dropbox CLA. Thanks!

travis doesn't seem happy

Yep, it looks like the ./tools/test-js-with-node test suite is failing.  Since this is caused by a behavior change, I think you just need to update the test.

See http://zulip.readthedocs.io/en/latest/testing.html for details on Zulip's test suites.

How to get stream size or threshold value in casper tests ??

@timabbott can you help me, why this time build failed everything seems okay to me.

That failure looks like a problem with the Travis CI server that was running that build.  I've triggered a rerun.

@timabbott everything seems good now.

@timabbott reminder to merge this.

@s0nskar just wanted to check in -- have you resolved the "actually send" issue?

Not yet my semester finals are going on. So I am bit inactive during these days. Will do it asap after my finals are over i.e., 1 Dec

OK, sounds good, best of luck with your exams!

Hey @timabbott, fixed "actually send" thing. Tried centring the send button but all in vain. Some backend tests are failing b/c travis is just being travis.

Thanks for cleaning that up @s0nskar!  I merged this as e6beaa27115a099db1fd46fd24bfb309ca0f332a, after making several tweaks:

simplified the casper tests for the new situation (in particular, we ensure it's the more interesting is_warning=True case now).
Squashed the commits together.  Note that the Zulip project doesn't use merge conflicts, so next time you should use git pull --rebase rather than git pull.  Check out our GitHub guide and commit guidelines for more details.
Changed "YES, Send" to "Yes, send".

Huge thanks for implementing this @s0nskar!

Changes looks good. will take care of rebase-orientated workflow from next time @timabbott .


perf(virtual-list): relaxed restrictions for fast path

Short description of what this resolves:
Changes proposed in this pull request:

Ionic Version: 1.x / 2.x / 3.x
Fixes: #

I have also noticed that setting virtualTrackBy has no effect, as when the virtualScroll setter is called, this.virtualTrackBy has not taken a value yet. Triggering the setter again (by setting a new array reference) sets the virtualTrackBy successfully.

Feel free to clone this PR and submit a new one, unfortunately I have to work in some keyboard issues during this cycle, but I will re-evaluate the virtual-list performance in the next cycle.
Another improvement we could make, in slow path we don't need to purge the array of nodes, since we could reuse them. This way we would save the need to recreate all the embedded views each time the slow path is taken.

Read your code again with a clear head and I was mistaken about the earlier comments. The comments confused me, because they state the exactly opposite of what you are actually doing.
// add new record **AFTER** current position
if (pindex === null && (cindex < lastRecord)) {
   console.debug('adding record **BEFORE** current position, slow path');

I guess I should know better. Code never lies, comments... sometimes. 👨💻 Will be now closing #11491
Thanks for the effort Manu, really appreciate you taking the time and dealing with this on the side.
If you ever get virtual scroll into your crosshairs again it would be nice if you could find a way for updates to not cause destroying of the rendered elements at all as you mentioned the other day

Another improvement we could make, in slow path we don't need to purge the array of nodes, since we could reuse them. This way we would save the need to recreate all the embedded views each time the slow path is taken.


Revert "removed redundant check of logger level (#883)"

This reverts commit 25028fbfd1da3846154238d287a8bb22f0ef6ce1.

Codecov Report

Merging #891 into dev will decrease coverage by 1.47%.
The diff coverage is 18.41%.

@@             Coverage Diff              @@
##                dev     #891      +/-   ##
============================================
- Coverage     50.16%   48.69%   -1.48%
- Complexity     2815     2819       +4
============================================
  Files           118      118
  Lines         27027    27877     +850
  Branches       4241     4642     +401
============================================
+ Hits          13559    13574      +15
- Misses        11531    12110     +579
- Partials       1937     2193     +256

Flag
Coverage Δ
Complexity Δ

#JDBC42
48.17% <18.34%> (-1.51%)
2773 <118> (+2)

#JDBC43
48.58% <18.41%> (-1.52%)
2812 <122> (ø)

Impacted Files
Coverage Δ
Complexity Δ

...m/microsoft/sqlserver/jdbc/SQLServerResultSet.java
32.74% <ø> (-2.47%)
256 <0> (+3)

...om/microsoft/sqlserver/jdbc/AuthenticationJNI.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

.../microsoft/sqlserver/jdbc/SQLServerXAResource.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...microsoft/sqlserver/jdbc/FailOverMapSingleton.java
13.79% <0%> (-0.5%)
0 <0> (ø)

...m/microsoft/sqlserver/jdbc/KerbAuthentication.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...icrosoft/sqlserver/jdbc/SQLServerXAConnection.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...microsoft/sqlserver/jdbc/SQLServerADAL4JUtils.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...icrosoft/sqlserver/jdbc/SQLServerXADataSource.java
6.25% <0%> (-2.09%)
2 <0> (ø)

...rc/main/java/com/microsoft/sqlserver/jdbc/DDC.java
45.33% <0%> (+0.89%)
109 <0> (ø)
:arrow_down:

.../com/microsoft/sqlserver/jdbc/SQLServerDriver.java
80.22% <0%> (-0.37%)
25 <0> (ø)

... and 34 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd89a10...9790b66. Read the comment docs.


Update readme.md with webpack example code

Hi there,
added an example for stylus compilation with webpack to the readme. Might be useful for people trying to quickly add jeet to their projects.

@tikiatua Thanks. I'm going to clean this up and add to official integrations (probably tomorrow). Care to keep your branch alive until then?
I'd prefer the main README be as newb-friendly as possible, and plop official integrations into their own docs folder.


LDAP Binding Broken in 0.6.5

The refactored LDAP settings in commit 7d84d4a8f0cb30df04241f528ed74672a485274a has broken authentication for me.
Before
I used the login credentials as bind credentials. Using the Ms Ad SA, attribute, I could format the login credential to match the LDAP logins on my server.
Now
Have the option of :

Specify a bind DN (username) and bind password. The password is displayed in plain text on the configuration page and stored in plaintext in the DB. This is unsafe and not an option for us.
Use an anonymous bind which is not an option for me.

I would like to be able to do as before and use the user's login crendentials as LDAP bind credentials and not use fixed LDAP credentials.

Thanks your feedback!
I would try to see if it's possible to make two types of LDAP exists at same time so users can have more choice, like your case.

Note that this is being tracked on #1524.

@samlcharreyron #1581 should have fixed this.

any updates on this?

Close for now but open for continuing discussion.


Syntax Error in @clr/core when using Jest

Describe the bug
After the @clr/core dependency of @clr/angular was introduced in 3.0, Jest is now throwing a syntax error coming from the new package.
node_modules\@clr\core\fesm2015\clr-core.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){import { __decorate, __metadata, __awaiter } from 'tslib';
                                                                                ^

    SyntaxError: Unexpected token {

      at ScriptTransformer._transformAndBuildScript (node_modules/@jest/transform/build/ScriptTransformer.js:471:17)
      at ScriptTransformer.transform (node_modules/@jest/transform/build/ScriptTransformer.js:513:25)
      at node_modules/@clr/angular/bundles/clr-angular.umd.js:2:156
      at Object.<anonymous> (node_modules/@clr/angular/bundles/clr-angular.umd.js:5:2)

Test Suites: 2 failed, 4 passed, 6 total
Tests:       16 passed, 16 total

How to reproduce
Please provide a link to a reproduction scenario using one of the Clarity Stackblitz templates. Reports without a clear reproduction may not be prioritized until one is provided.
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Versions
App

Angular: [e.g. 6]
Node: [e.g. 8.10.0]
Clarity: [e.g. 0.12.5]

Device:

Type: [e.g. MacBook]
OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional notes
Add any other notes about the problem here.

Hi @whizkidwwe1217
Is it possible to reproduce this on a stackblitz to help us investigate what may be causing it?
Thanks,
Scott

Hi @mathisscott I don't know how to run unit tests in StackBlitz but you can clone https://github.com/whizkidwwe1217/jest-test. It's just very simple Angular app generated using ng new. Removed all karma files and replaced with Jest. To run, simply execute npm install and then npm test. Thank you.
As you can see in the spec, @clr/core is throwing error when the ClarityModule is added to the imports. It was working fine in Clarity v2.
import { TestBed } from "@angular/core/testing";
import { AppComponent } from "./app.component";
import { ClarityModule } from "@clr/angular";
import { HttpClientTestingModule } from "@angular/common/http/testing";
import { APP_BASE_HREF } from "@angular/common";

beforeEach(() => {
  TestBed.configureTestingModule({
    imports: [HttpClientTestingModule, ClarityModule],
    declarations: [AppComponent],
    providers: [
      {
        provide: APP_BASE_HREF,
        useValue: "/"
      }
    ]
  }).compileComponents();
});

test("should create app component", () => {
  expect(true).toBeTruthy();
});

@whizkidwwe1217 what specific version of Clarity in your pacakge.json are you using? It looks like we had a couple of bad npm publishes and I am trying to narrow down the cause.

@coryrylan If I use 2.3.5 you can see that the simple test is passing but when using 2.3.5/6, I got a syntax error from @clr/core package.
v2.3.5 (branch: v2)

v3.0.0-next.5 (branch: master)

Please let me know if it's still feasible to use Jest for the latest Clarity. If not, then I guess I have to switch back to using Karma. Thanks!

It sounds like your configuration isn't handling ES6 syntax, which I'm not familiar with Jest enough but looks like you can add plugins to support this.

@gnomeontherun Thank you! I think I'll just switch back to Karma for now. That will be easier for me than going into crazy Jest configurations. It'll also be better if I just align my workflow with Clarity's since I'm using Clarity packages anyway. I'll close this for now.

@whizkidwwe1217 , @coryrylan : I had the same issue and solved it in the following way:
my package.json (you have to install babel to compile JS down to ES5):
    "jest": "~24.9.0",
    "@babel/preset-env": "~7.8.4",
    "babel-jest": "~24.9.0",

babel.config.js (in the root dir):
// https://babeljs.io/docs/en/babel-preset-env
module.exports = {
  presets: [
    [
      "@babel/preset-env",
      {
        targets: {
          esmodules: true
        }
      }
    ]
  ]
};

jest.config.js (in the root dir; notice -> transform and transformIgnorePatterns):
module.exports = {
  moduleNameMapper: {
    '^@app/(.*)$': '<rootDir>/src/app/$1',
    '^@env/(.*)$': '<rootDir>/src/environments/$1',
  },
  coverageDirectory: 'jest/coverage',
  transform: {
    '^.+\\.js?$': 'babel-jest',
    '^.+\\.ts?$': 'ts-jest'
  },
  transformIgnorePatterns: [
    'node_modules/?!(@clr)'
  ]
};

The initial test run needs some time, but then it (I think is cached) and will run a lot faster.
Hope it works ;-)

@alexej-strelzow Thanks for the workaround suggestion. Unfortunately, we've hit a wall with that approach:
   Cannot find module './base/base.element.css' from 'index.js'

      at Resolver.resolveModule (../../node_modules/jest-resolve/build/index.js:276:11)
      at Object.<anonymous> (../../node_modules/src/clr-core/common/index.ts:26:1)

This is most likely related to the fix not being 100% transferable to using nrwl/nx for multi-project mono-repo management.
I must admit I'm a little irritated by Claritys move to an ESM while one of the two major test runners still has no real support in sight, this effectively shuts down about half of our tests - and we don't have the freedom to arbitrarily switch test runners.

@TekSiDoT which test runner is specifically not working with Clarity? To make sure I understand, you are using nrwl/nx for your project? I do not want this being a blocker issue.

@coryrylan Thank you, I'll get back to you with as many details / a repro repository as soon as I can.

A reproduction repository is now available at https://github.com/TekSiDoT/clarity-jest-nx-repro .

@TekSiDoT hey thank you so much for the repro! I'll take a look at this asap to see if I can narrow it down. I can reach out to nrwl if needed.

We have a functional workaround, but at the cost of 5x testing time (presumably because of down compiling clarity core to es5):
./jest.config.js set transformIgnorePatterns to make sure that clarity core (and a couple others for us) get considered for inclusion in jest:
module.exports = {
  transform: {
    '^.+\\.(ts|js|html)$': 'ts-jest'
  },
  transformIgnorePatterns: ['node_modules/(?!@clr/core|lit-element|lit-html|ramda)'],
  resolver: '@nrwl/jest/plugins/resolver',
  moduleFileExtensions: ['ts', 'js', 'html'],
  collectCoverage: true,
  coverageReporters: ['html']
};

Then, in each project's tsconfig.spec.ts allow js, and force the es5 target:
{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "allowJs": true,
    "target": "ES5",
    "outDir": "../../../dist/out-tsc/apps/analytics-launchpad",
    "module": "commonjs",
    "types": ["jest", "node"]
  },
  "files": ["src/test-setup.ts"],
  "include": ["**/*.spec.ts", "**/*.d.ts"]
}

@RobHelgeson Thank you. Unfortunately your workaround does not seem to work with the reproduction project ...

@RobHelgeson is there anything in your test-setup.ts that may be contributing to the tests running?
I've got a Jest setup via @angular-builders/jest with the Babel changes suggested by https://github.com/thymikee/jest-preset-angular#unexpected-token-importexportother. My setup is pretty much equivalent to what you've got but I'm still seeing the message
Cannot find module '@babel/runtime/helpers/interopRequireDefault' from 'button.base.js'

@TekSiDoT Did you manage to get this fixed? Thanks
@coryrylan Can we not build clr-core through ng-packagr to ship all the bundles? Jest plays nicely with commonjs.

Jest tests with latest Clarity run perfectly for me by just following the instructions in the jest preset angular repo.

@whizkidwwe1217 Thanks, I see that you are using angular-builders/jest, with nx we use @nrwl/jest.
Not sure about the differences, here is my jest config. I have tried babel-jest as well but no luck. I keep getting error at clr-angular/utils/i18n/common-strings.service.ts where CommonStringsServiceInternal is being resolved as null or undefined since it's not being converted to commonjs for some reason.
jest.config.json
"transform": {
    "^.+\\.(ts|js|html)$": "ts-jest"
  },
  "transformIgnorePatterns": ["node_modules/(?!(lodash-es|@swimlane|decode-html-entities|@torque/clr-core|lit-html|lit-element|ramda))"],

@vinayakpatil no, we're currently waiting for @coryrylan investigation into this issue. Until then, we're pushed our Angular 9 / Clarity 3 update schedule.

I am still investigating this. Due to the different Jest packages I am reopening this for tracking.

Thanks @coryrylan , with some tweaks I am now getting the exact same error mentioned by @TekSiDoT
Cannot find module './base/base.element.css' from 'index.js'

      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:230:17)
      at Object.<anonymous> (node_modules/@clr/core/common/index.js:23:1)

@vinayakpatil @coryrylan
I did manage to get my tests running. I had to include a babel.config.js with this content.
module.exports = function(api) {
  api.cache(true);

  const presets = ["@babel/preset-env"];
  const plugins = [
    ["@babel/plugin-transform-runtime", {
        regenerator: true
    }]
  ];

  return {
    presets,
    plugins
  };
};

And this is my Jest config
module.exports = {
  preset: 'jest-preset-angular',
  roots: ['<rootDir>/src/'],
  testMatch: ['**/+(*.)+(spec).+(ts)'],
  setupFilesAfterEnv: ['<rootDir>/src/test.ts'],
  moduleNameMapper: pathsToModuleNameMapper(compilerOptions.paths || {}, {
    prefix: '<rootDir>/'
  }),
  transformIgnorePatterns: [
    'node_modules/(?!(@clr/core/common|lit-html|lit-element|ramda)/)'
  ],
  transform: {
    "^.+\\.(ts|html)$": "ts-jest",
    "^.+\\.js$": "babel-jest"
  },
};

In my tsconfig.spec.json I have
    "module": "commonjs",
    "allowJs": true,
    "target": "ES5"

I had to install the packages
"@babel/plugin-transform-regenerator": "^7.8.3",
"@babel/plugin-transform-runtime": "^7.8.3",
"@babel/runtime": "^7.8.4",
"babel-jest": "^25.1.0",

Thanks @GrahamFord for sharing.
@coryrylan @TekSiDoT temporary workaround via moduleNameMapper
"moduleNameMapper": {
    "base.element.css"<EMAIL_ADDRESS>},

@vinayakpatil That did the trick (at least for the reproduction repository), I'll check with our main one and report back.

@TekSiDoT

Hey there @mathisscott, thanks for chiming in. Yes, ignoring Clarity modules for transform is one of the elements of the current solution, which unfortunately doesnt yet get us all the way to a solution.

@RobHelgeson is there anything in your test-setup.ts that may be contributing to the tests running?
I've got a Jest setup via @angular-builders/jest with the Babel changes suggested by https://github.com/thymikee/jest-preset-angular#unexpected-token-importexportother. My setup is pretty much equivalent to what you've got but I'm still seeing the message
Cannot find module '@babel/runtime/helpers/interopRequireDefault' from 'button.base.js'

I'm using a straight Angular setup without Nx.

@GrahamFord here is my test-setup.ts:
import 'jest-canvas-mock';
import 'jest-preset-angular';`

@vinayakpatil Thank you for the moduleNameMapper tip!
FYI, if you encounter the issue that your tests run a lot longer when you use transformIgnorePatterns and allowJs: true, I have found, that adding:
  globals: {
    'ts-jest': {
      diagnostics: false,
    },
  },

to your jest.config.js file will ease the pain a little.

@vinayakpatil That did the trick (at least for the reproduction repository), I'll check with our main one and report back.
Update:
This workaround works for around 95% of our tests. The remaining 5% now throw TypeError: Class constructor CommonStringsServiceInternal cannot be invoked without 'new'. This is probably related to Babels down-compilation and #4094
Overall test-duration has increased from around 60 seconds to around 80 seconds so far.

@TekSiDoT We ran into the same error like your 5% (CommonStringsServiceInternal), did you find a solution for this?

I'm afraid not, still waiting for a solution

@TekSiDoT ok, that's sad - anyway thx for your quick response
@coryrylan @mathisscott will the resolution: wontfix remain or will there be some investigation around the usage of Clarity in nx workspaces with their recommended unit test runner Jest

@twittwer I did not face such issue since my target is es6, if it helps.
"module": "commonjs",
"target": "es6"

@twittwer
@coryrylan reopened this 8 days ago and didn't remove the resolution: wontfix label. Happy to see that people are paying attention to the labels! 😊
That said, this error is debatably not a Clarity issue. I've gotten @clr/core working in two different versions of Jest. And likely our "fix" is just going to be showing people options to fix this issue in their projects.
The fix from @alexej-strelzow has worked in every instance I've come across with Jest. The crux of the problem appears to be that Jest is compiling things down to commonjs in a sneaky fashion so it needs es6 dependencies to compile down to es5. That means you'll need @clr/core, @clr/angular, and possibly the dependencies of lit-element, lit-html, et al. to likewise get compiled down in Jest's sneaky way of doing things.
It seems that Jest may be working on addressing this but it seems like a fairly big task on their end.
We'll keep working on different examples of configurations to help people out. But please note this is a Jest and a an app configuration issue. It's not a top priority for us because @clr/core isn't actually causing the problem.
I recommend working with transformIgnorePatterns in your config. You may need to include more than just core as Jest may be trying to sneaky compile @clr/core or @clr/angular's dependencies as well.

 There's one minor issue with a core filename that's throwing a wrench in the works.

@mathisscott Thank you! Excited to try your solution out as soon as possible.

 There's one minor issue with a core filename that's throwing a wrench in the works.

@mathisscott Thx for your response
I added a lib to this fork of the repo to reproduce our error in a simple us case. Can you have a look at it?

@twittwer
I spent way too much time on that repo this morning. I have to hop off for now but here's what I ran into.
It seems libraries are more affected by Jest's stealthy CommonJS transpiles and dependency than applications.
This is a well know (dare I say) "problem?" with Jest and there's an entire thread about it here (https://github.com/facebook/jest/issues/4842).
If you can get off of Jest, I would. This is not a Clarity issue but it's Clarity trying to help you work through a Jest issue.
That said, I'll keep plinking away at this problem in hopes that I can find a solution. Unfortunately, I'm out of pocket after today so the earliest I can get back to it is a week and half or two weeks from now. And it's an extra-curricular. Meaning I can't commit to when or if I can find a solution.
As noted above, this is an issue with Jest. It's one they may or may not be addressing in Jest 25 and looks like a peculiar architecture decision in Jest's early days led us all here.
I know Jest is trendy right now. So we'll do our best to help. But my recommendation is to not use Jest, given all the information I've uncovered about the details of the problem with Jest and how we arrived here.
It's entirely likely that you could migrate your entire test suite before we can find out how to make Jest work in your use case. Additionally, if you could put some time towards solving the problem, we'd appreciate you posting back whatever you find.

@mathisscott thx for the ongoing investigation
Based on my today's investigation I do not think the problem appearance is based on lib or app but which component is used. So I get the error in apps as well if components with a dependency to the CommonStringService, like clr-alert.

@twittwer
So a component that depends on CommonStringService triggers it? That helps. Thanks!
Note that Jest issue I posted has many, many attempts at workarounds (with varying degrees of success). There is one where CommonJS translates an extends into something ES5 dies on. That may be what we are seeing. I have a couple of unrelated PRs to finish up today. If I get extra time, I'll look into that because I know CommonStringsService extends CommonStringsServiceInternal from @clr/core. That at least gets us closer...

Hey guys, just a quick update on my end. I updated to jest 25.1 recently to get rid of performance problems caused by jest 24.9 and babel. ts-jest as explicit devDependency lets you get rid of the warning that ts-jest 24.x is not compatible with jest 25.1. But also with an older version it works normal.
My final configuration looks like this and is working like a charm:
package.json (with Angular 9)
    "@clr/angular": "~3.0.0",
    "@clr/core": "~3.0.0",
    "@clr/ui": "~3.0.0",

    RELEVANT DEV DEPENDENCIES
    "@types/jest": "~25.1.2",
    "@types/node": "~12.12.26",
    "babel-jest": "~25.1.0",
    "jest": "~25.1.0",
    "ts-jest": "~25.2.1",
    "ts-node": "~8.3.0",
    "typescript": "~3.7.5",

jest.config.js:
module.exports = {
  moduleNameMapper: {
    '^@app/(.*)$': '<rootDir>/src/app/$1',
    '^@env/(.*)$': '<rootDir>/src/environments/$1'
  },
  coverageDirectory: 'jest/coverage',
  transform: {
    '^.+\\.js?$': 'babel-jest',
    '^.+\\.ts?$': 'ts-jest'
  },
  transformIgnorePatterns: [
    '<rootDir>/node_modules/(?!(@clr/core|lit-element|lit-html|ramda)/)'
  ],
  testMatch: ['<rootDir>/src/app/**/*.spec.ts']
};

babel.config.js:
module.exports = {
  presets: [
    [
      "@babel/preset-env"
    ]
  ]
};

I still have some workarounds here and there where I use the ClrTab, e.g. - I overwrite the template with a blank to make the test pass:
    TestBed.configureTestingModule({
      imports: [LucyWebSharedModule.forRoot(), LocaleManagerModule],
      providers: [...TEST_PROVIDER]
    }) // TODO: below workaround for https://github.com/vmware/clarity/issues/4094
      .overrideTemplate(LocaleManagerComponent, '');

Error w.o. this fix:
 FAIL  src/app/features/locale-manager/locale-manager.component.spec.ts (9.925s)
  ● LocaleManagerComponent › should create

    TypeError: Class constructor CommonStringsServiceInternal cannot be invoked without 'new'

      at new ClrCommonStringsService (node_modules/@clr/angular/bundles/clr-angular.umd.js:1425:46)
      at ClrCommonStringsService_Factory (node_modules/@clr/angular/bundles/clr-angular.umd.js:1427:131)
      at _callFactory (../packages/core/src/view/ng_module.ts:196:14)
      at _createProviderInstance (../packages/core/src/view/ng_module.ts:149:20)
      at resolveNgModuleDep (../packages/core/src/view/ng_module.ts:122:15)
      at NgModuleRef_.Object.<anonymous>.NgModuleRef_.get (../packages/core/src/view/refs.ts:390:12)
      at resolveDep (../packages/core/src/view/provider.ts:418:43)
      at createClass (../packages/core/src/view/provider.ts:282:24)
      at createDirectiveInstance (../packages/core/src/view/provider.ts:135:20)
      at createViewNodes (../packages/core/src/view/view.ts:303:28)
      at callViewAction (../packages/core/src/view/view.ts:636:7)
      at execComponentViewsAction (../packages/core/src/view/view.ts:559:7)
      at createViewNodes (../packages/core/src/view/view.ts:331:3)
      at createRootView (../packages/core/src/view/view.ts:210:3)
      at callWithDebugContext (../packages/core/src/view/services.ts:629:23)
      at Object.debugCreateRootView [as createRootView] (../packages/core/src/view/services.ts:121:10)
      at ComponentFactory_.Object.<anonymous>.ComponentFactory_.create (../packages/core/src/view/refs.ts:92:27)
      at initComponent (../../packages/core/testing/src/test_bed.ts:612:28)
      at ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:396:30)
      at ProxyZoneSpec.onInvoke (node_modules/zone.js/dist/proxy.js:117:43)
      at ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:395:36)
      at Object.onInvoke (../packages/core/src/zone/ng_zone.ts:302:25)
      at ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:395:36)
      at Zone.run (node_modules/zone.js/dist/zone.js:153:47)
      at NgZone.Object.<anonymous>.NgZone.run (../packages/core/src/zone/ng_zone.ts:178:50)
      at TestBedViewEngine.Object.<anonymous>.TestBedViewEngine.createComponent (../../packages/core/testing/src/test_bed.ts:616:56)
      at Function.Object.<anonymous>.TestBedViewEngine.createComponent (../../packages/core/testing/src/test_bed.ts:241:36)
      at beforeEach (src/app/features/locale-manager/locale-manager.component.spec.ts:21:23)
      at ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:396:30)
      at ProxyZoneSpec.onInvoke (node_modules/zone.js/dist/proxy.js:117:43)
      at ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:395:36)
      at Zone.run (node_modules/zone.js/dist/zone.js:153:47)

But all in all I am super happy with my current working setup :)

That's awesome, @alexej-strelzow
Thank you so much for sharing!
We'll continue to look into these configurations as time allows but most certainly appreciate the guidance and help.

Thx @alexej-strelzow , with the idea of overriding I was able to get around the CommonStringsServiceInternal Error by overriding the problematic ClrCommonStringsService itself.
TestBed.configureTestingModule({
    imports: [ClarityModule],
    declarations: [AlertsComponent],
    providers: [
        {
            provide: ClrCommonStringsService,
            useClass: CommonStringsServiceInternal
        }
    ]
});

I'm not sure it this approach can be problematic regarding test results (bug detection).
Currently, there are some other errors I have to investigate - but so far it felt like a huge step forward

Closing as this dependency was removed from clr/angular. We have verified Jest working with clr/core outside of this dependency.


Add tsv file to test panacus-visualize

Adds a tsv file generated with panacus from the pangenome.smoothxg.gfa graph to have a dataset to test panacus-visualize. Should be used in nf-core/modules#4260

Thanks for the review!


Passing ref to string as object results in "object required" error

Repro

create a pkg w/ a string input defaulted to a valid JSON string
call a pkg which requires an object input
fulfill the object input w/ the string input

Expected
stringified JSON is coerced to a valid object
Actual
Error returned: "Object required"

@psamaan


Throw out bad samples

This PR allows the filtering out of samples in make_mask_and_diff that have too many low coverage sites to happen in the diff-making task, rather than passing the buck to downstream tasks. This is more in line with behavior of other filtering tasks in myco.
As before, sites are considered low coverage if they are below min_coverage_per_sitex coverage, and a report file is created that keeps track of how much of the sample gets masked for being below that coverage. What changed is that the user can now throw out the sample immediately, returning an "error" message, based on that report file. The cutoff is set by max_ratio_low_coverage_sites_per_sample.
Input changes

diffs is removed -- now diff files will always be created (but may not be output)
added max_ratio_low_coverage_sites_per_sample as explained above
added force_diffs, which will force the output of diffs the sample gets thrown out for having too many low coverage sites
added a parameter meta section

Other

That old make_diff task is now named make_diff_legacy

Tested and passes on Terra, on both pass and fail conditions.


How to enable strict ordering by default ?

How to default to strict ordering ?

I always end up enabling strict ordering but I couldn't find a MCFLY_ variable that does it.
sry if that's the wrong repo, was not sure wether to report here or mcfly

Hi @teto, this is definitely the right repo for your issue. Now that you mention it I also have this problem since strict ordering is often what I want too. The rough solution will be to add the --no-sort option to the fzf call, which should cause it to start with strict ordering enabled.
I think you a can do this from the existing setup directly by setting export FZF_CTRL_R_OPTS="--no-sort" in your current shell or in your .bashrc or .zshrc file as appropriate.
I might add a more dedicated way to have this default to strict in the future, but this should tide you over for now.

With release 0.1.3, I've now set this so strict ordering is the default (can be disabled by setting MCFLY_FZF_NO_STRICT_ORDERING), and the strict ordering toggle will be remembered

ty !


Add a Dockerfile linter (Hadolint) to this repo

Hadolint is a Dockerfile linter that also bundles shellcheck.
I've seen it used in other open source projects with Dockerfiles, and it was mentioned as a thing in one of the GOV.UK replatforming ideas docs. So I thought I'd see how it performed here.

So far I've only linted Dockerfile.govuk-base. But if people like this (that's why it's a draft - comments welcome) then I'll extend CI to lint everything and fix all the failures. The other ones are pretty much the same as the Dockerfile.govuk-base ones as they're copies with extra stuff per-app.

I've had to globally ignore some lints here:

DL3008 - pinning versions in apt-get install - feels like quite a lot of maintenance overhead for every patch version that we'd need to update in Dockerfile.govuk-base and all its downstream consumers. I'm going to wager that we don't want the dependency management of having to check each of these Dockerfiles periodically for the latest version numbers of packages and have to update them.

However, I can see that for some, this would be useful. We've had several times recently in local dev where docker build has failed because of updated dependency versions that other things we use can't cope with.
If someone wants to volunteer to keep all of these up-to-date - and, indeed, find a known-good state in the first place - feel free to suggest to unignore this one!

DL3006 is a little less controversial. We don't tag versions of these Dockerfiles, so we can't satisfy this lint.

In light of the above thread of "why does this need to happen", maybe it doesn't.


can not use gcc compiler

i have installed gcc in bash with apt-get install gcc
i want to use it in codeblocks can i use it?
can not find gcc in code blocks

Hi @hishamwaleed -- Thanks for posting, this sounds like an interesting use case.  But I'm not sure that the WSL bugtracker is the best place to ask about codeblocks features?  You might want to ask the codeblocks folks.
I would guess that they would say that codeblocks will recognize the Linux version of gcc if you also use the Linux version of codeblocks.  Note that graphical applications aren't officially supported, though; you'll need to do a little more setup to get them working.

Note: for now the WSL and Windows programs can't interact much.

thank you

Closing this thread out.


Provide a constant method to getPrice() to know how much Oraclize is going to charge

I want to know how much is the fee oraclize is going to charge me before I send a transaction or Oraclize API.
For example I want to know How much Oraclize would charge me for "URL" with specific gasLimit and gasPrice.
getPrice("URL", gasLimit, gasPrice) public constant
If I know this before making the actual request on platform. I can send that specific ETH into my transaction. Also we can charge that much of ETH from our customers.

We agree this is a change we'll add in in a coming update, it's really not more than an annoyance at this point, in that you get that warning message from the compiler. The functionality is still the same.

I have the same issue with @jchittoda (the only difference is that I am using view instead of constant) but in compiler version 0.5.4 is a TypeError and I can't compile my contract.
TypeError: Function declared as view, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
Could you suggest any workaround until a fix is implemented?

We have a new connector we'll be deploying very soon, that has the view specifier applied to it.
Once we have it deployed, we'll in tandem update the oraclizeAPI interface.
You can already update that part of the oraclizeAPI @chris-chr to overcome the compilation error you've encountered.
Change
https://github.com/oraclize/ethereum-api/blob/master/oraclizeAPI_0.5.sol#L42
to
function getPrice(string memory _datasource, uint _gasLimit) public view returns (uint _dsprice);
by adding the view specifier to that interface definition. That is the change we'll be doing ourselves to the api upon deployment.

We have a new connector we'll be deploying very soon, that has the view specifier applied to it.
Once we have it deployed, we'll in tandem update the oraclizeAPI interface.
You can already update that part of the oraclizeAPI @chris-chr to overcome the compilation error you've encountered.
Change
https://github.com/oraclize/ethereum-api/blob/master/oraclizeAPI_0.5.sol#L42
to
function getPrice(string memory _datasource, uint _gasLimit) public view returns (uint _dsprice);
by adding the view specifier to that interface definition. That is the change we'll be doing ourselves to the api upon deployment.

Hi,
I just noticed this thread. I also would be interested in something to easily get the price of a datasource. I am not interested in a function though just a public variable on a library or something I could call would do for me.
uint public randomPrice;  uint public URLPrice;  //et cetera...
I can do my own math on gas limit and gas price .
Thanks for all the work you are doing.


scorecard shouldn't complain about actions in the same repository

It's possible to reference actions that are kept in the same repository using ./path/to/dir: https://docs.github.com/en/actions/learn-github-actions/finding-and-customizing-actions#referencing-an-action-in-the-same-repository-where-a-workflow-file-uses-the-action. I don't think scorecard should complain about them.

Great catch, thanks! Feel free to send a PR and cc me on it for approval.

see https://github.com/ossf/scorecard/pull/1357


Remove newline instead of using \ for continuation

Description

Development notes

Checklist

[x] Read the contributing guidelines
[ ] Opened this PR as a 'Draft Pull Request' if it is work-in-progress
[ ] Updated the documentation to reflect the code changes
[ ] Added a description of this change and added my name to the list of supporting contributions in the RELEASE.md file
[ ] Added tests to cover my changes

Notice

[x] I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":

I submit this contribution under the Apache 2.0 license and represent that I am entitled to do so on behalf of myself, my employer, or relevant third parties, as applicable.

I certify that (a) this contribution is my original creation and / or (b) to the extent it is not my original creation, I am authorised to submit this contribution on behalf of the original creator(s) or their licensees.

I certify that the use of this contribution as authorised by the Apache 2.0 license does not violate the intellectual property rights of anyone else.

@921kiyo Re https://github.com/quantumblacklabs/kedro/pull/312#issuecomment-609850328, I deleted my fork and recreated a fork several times, and tried with various changelists, committing locally and pushing up vs. directly on GitHub... nothing's working. :(

Due to the issues with running CI for the fork, I've pushed it to a regular branch and created a new PR #319. Will close this for now.


Handle common CBMC flags via RMC

Description of changes:
Common CBMC flags (--object-bits and --unwind) can be passed to rmc instead of being specified after --cbmc-args. The default value for object bits is 16, and a new flag has been added to turn off default values for these flags.
Resolved issues:
Resolves #595
Call-outs:

Note that --unwind 0 has not been considered a default for this PR. For more details, read the discussion in #595
Note that this does not work with cargo-rmc. I think #600 is a better solution in the case of cargo-rmc.

Testing:

How is this change tested? Existing regression + a new dry-run has been added.

Is this a refactor change? No.

Checklist

[x] Each commit message has a non-empty body, explaining why the change was made
[x] Methods or procedures are documented
[x] Regression or unit tests are included, or existing tests cover the modified code
[x] My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

Please check the new proposal and let me know what you think. Some comments:

The same behavior can be added to cargo-rmc if you think it is a good idea.
Missed @zhassan-aws comments about the help message, will add it now.
If conflicting flags are given, we raise an exception. Other cases use the expected choice.
If we want to have a special flag for --unwind that is fine with me, but we need to agree first on the behavior for --object-bits and --unwind separately. Here I attempted to find something that works for both.

--malloc-may-fail fits better with the other single-word flags, but I feel is out of scope for this PR.

The new proposal LGTM. I still think we don't need a default values flag though. I see your point on the plan for adding a default value for unwind, but I think that unwind is a special case that should be handled via its own flag (as opposed to a single flag that turns off all the RMC default values for CBMC flags. For instance, we can add an --auto-unwind or something similar if we decide on passing --unwind 0 by default. But, it should not be tied to --object-bits.

Makes sense. We can specialize this code for --object-bits and remove the --default-values option.
The main question now is: Do we want --unwind 0 by default or not?

Do we want --unwind 0 by default or not?

I'm in favor of doing that, but we can keep this discussion for a separate PR.

Pushed a new version that adds the --auto-unwind flag, removes the --default-values flag and uses the same case-based method that we had in the last version to decide on common flags. There is also a special case for conflicting --unwind flags with --auto-unwind, which results in an exception.
I am happy with the present version, which is actually compatible with our regression. The breaking will come later if we decide to replace DEFAULT_UNWIND_VALUE from None to "0".

Moved default values to rmc_flags.py, which we now print as part of the help message (both for --object-bits and --unwind).

Thanks to you @zhassan-aws for the quick reviews! :)


add option to re-encrypt a file

After many moons :moon:
header reencryption for a known key and list of recipients
go run main.go encrypt -f sample.txt -s test/sender-C.sec.pem -p test/recipient-A.pub
go run main.go reencrypt -f sample.txt.c4gh -s test/recipient-A.sec.pem -p test/recipient-B.pub  -p test/recipient-A.pub -o cool.c4gh
go run main.go decrypt -f cool.c4gh -s test/recipient-A.sec.pem
go run main.go decrypt -f cool.c4gh -s test/recipient-B.sec.pem

draft for now, as tests pending.
thanks for @sampsa for the implementation in another project and @teemukataja for the idea to do this

Codecov Report

Merging #42 (963d91a) into master (394551b) will decrease coverage by 4.18%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #42      +/-   ##
==========================================
- Coverage   57.71%   53.53%   -4.19%
==========================================
  Files           6        6
  Lines         998     1076      +78
==========================================
  Hits          576      576
- Misses        303      381      +78
  Partials      119      119

Flag
Coverage Δ

unittests
53.53% <0.00%> (-4.19%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

model/headers/headers.go
36.75% <0.00%> (-7.69%)
:arrow_down:

streaming/out.go
57.42% <0.00%> (-9.25%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Syscall is done success and the Fodhelper exploit done in registery but KasperSky terminat process

Hi iam new in reverse engineering iam
using the sys calls and while debugging my exe .
the sys call is done success and the registery manpulated success but after theas things is done .
the KasperSky still kill my process ,
can some one help

Solved .
Kaspersky and microsoft AV using minifilters and kernal call backs to monitor process
So to bypass them you need install driver and run in kernal mode to unpatch minifilters hook


bv: check pyparsing install check

Describe the bug
repeated calls to build_visit seem to re-install pyparsing and its deps.
Not sure if pyparsing failed to install, or if our check is bad.
checking if python is installed
python module pyparsing is not installed
Installing certifi ...
Installing toml ...
Installing tomlI ...
Installing pathspec ...

Also poodle:
checking if python is installed
python module pyparsing is not installed

pyparsing was not being installed by build_visit, but we were checking for it.
I am not sure if we need it, trying a toss4 build without

resolved in #9331


[did-configuration] Company vs Customer / Account DIDs

Its possible to use the .well-known/did-configuration to expose DIDs for the domain, that are "Company" DIDs, but its also possible for it to be "Customer" DIDs, or user DIDs...
The question here is about providing guidance on what kinds of DIDs should be associated with a domain.
It seems like we should take an authoritative stance, that this uri is not to be used for customer or user account/ user agent / wallet DIDs.
For an analogy, if we're talking about twitter:
https://twitter.example.com/.well-known/did-configuration
Would hold DIDs for the company twitter, but NOT twitter users.

I suggest we add some specific language to the spec advising domain controllers to not automatically register DIDs on behalf of domain users here.
If that is a desirable feature, I believe it should be exposed using webfinger instead, since that is a well known uri that is built for discovering users of a domain.

+1 domain controllers must not automatically register DIDs on behalf of domain users.
The spec can still be used for person DIDs if you "own" (=rent) your own (sub-)domain name, e.g. alice.name or alice.company.com.

I agree with this, and will add a note to the spec for guidance.

This has been added several places in the spec. Closing, but feel free to add a PR if further text additions are desired.