Redesign V2 - Build the Context with WindowBuilder rather than &Window

This is a follow up to the proposal at #897. More specifically, it is an implementation of the idea proposed in this comment.
It is almost entirely the same as #897, but changes the ContextBuilder API slightly to address two primary issues:

X11 seems to require creating the GL context prior to creating the window in order to behave correctly (see this comment).
A user may attempt to create a GL context for a window with some other existing graphics context (e.g. DirectX) resulting in possibly unsafe behaviour.

Rather than building the Context with a borrowed, pre-built winit::Window, this PR proposes building the Context with a winit::WindowBuilder. This gives glutin control over the order of window and context creation solving 1, while also ensuring that the Window cannot already be associated with some other graphics context which solves 2.
Although slightly less flexible than #897, we still get the primary benefit of no longer having to maintain wrappers around the Window and EventsLoop types. This simplifies glutin's role to providing a cross-platform GL Context that is compatible with winit and can work nicely alongside it.
Here's an example of using glutin after this redesign:
let mut events_loop = glutin::winit::EventsLoop::new();
let window_builder = glutin::winit::WindowBuilder::new()
    .with_title("A fantastic window!");
let (window, context) = glutin::ContextBuilder::new()
    .build(window_builder, &events_loop)
    .unwrap();

See the updated examples for more detailed usage.
I'm going to leave #897 open for now in case it turns out to be possible to solve the X11 creation order problem some other way and in case we decide the existing graphics context issue should not be our problem.
cc @tomaka, @jwilm, @LPGhatguy, @kvark, @ebkalderon, @brendanzab

I like that this pull request removes more code than it adds.
It address the issue I run into with trying to test out winit patches using a project I'm working on that uses glutin.

I much prefer this one.

Although slightly less flexible

What flexibility is reduced compared to the other PR? Could you also provide the previously proposed API alongside the V2 one?

What flexibility is reduced compared to the other PR?

By reduced flexibility, I mean that a Context can not be built from an existing winit::Window and instead must control the window building stage.

Could you also provide the previously proposed API alongside the V2 one?

Sure! This is the example from my original comment demonstrating V2:
let mut events_loop = glutin::winit::EventsLoop::new();
let window_builder = glutin::winit::WindowBuilder::new()
    .with_title("A fantastic window!");
let (window, context) = glutin::ContextBuilder::new()
    .build(window_builder, &events_loop)
    .unwrap();

And this is the equivalent using the V1 #897 API (and in turn is also subject to the two problems I mentioned in the original comment):
let mut events_loop = glutin::winit::EventsLoop::new();
let window = glutin::winit::WindowBuilder::new()
    .with_title("A fantastic window!")
    .build(&events_loop)
    .unwrap();
let context = glutin::ContextBuilder::new()
    .build(&window)
    .unwrap();

This looks great! I'm away from my Linux machine until Sunday; I will give it a try once I'm back.

Yeah, awesome work @mitchmindtree in figuring out how to satisfy such a difficult design problem! I'm cool with this approach! 👍

Thanks @burtonageo, I addressed each of your comments!
I also just updated the README and root-level documentation. I think this should be ready to go now as long as everyone is happy.

My review now:

The window and the context should really be in only one struct. If someone destroys the window before the context, everything explodes. That's hugely unsafe.
The window builder, events loop, etc. from winit should be pub-reexported in lib.rs. I repeat this often but for me it is totally wrong to require the user to depend on winit.
I don't understand the motivation for removing the GlContext trait.

The window and the context should really be in only one struct.

How would you feel about something like a Facade or Display type for this (I'm open to a better name if someone has one)? Something simple like:
pub struct Facade {
    context: Context,
    window: winit::Window,
}

impl Facade {
    pub fn context(&self) -> &Context {
        &self.context
    }
    pub fn window(&self) -> &winit::Window {
        &self.window
    }
}

I guess Deref could be impld for the type, but it's not really clear to me which type it should deref to, so I'd probably prefer borrowing the context or window directly, e.g. facade.context().swap_buffers() or facade.window().get_inner_size_points(). I'd prefer not to add wrapper methods for all the methods on both types as this would just recreate the same maintenance burden that this redesign is trying to avoid.

The window builder, events loop, etc. from winit should be pub-reexported in lib.rs. I repeat this often but for me it is totally wrong to require the user to depend on winit.

The user is depending on winit either way when using glutin, but I can understand if you'd prefer the user did not need to know about winit. I'm happy to make this change.

I don't understand the motivation for removing the GlContext trait.

I explained my motivations for removing the GlContex trait here - what don't you understand about this?

I explained my motivations for removing the GlContex trait here - what don't you understand about this?

For me the only valid reason for removing it is the third, and it's pretty minor.

How would you feel about something like a Facade or Display type for this (I'm open to a better name if someone has one)? Something simple like:

Alternatively, make it Deref to winit::Window but also implement GlContext on it as well?

@tomaka I just added some commits that:

Re-exports the public winit API from lib.rs so that the user doesn't need to know about winit.
Adds a GlWindow type which combines the Window and Context (I guess we should look into controlling the order of dropping and how this should be handled for each OS?).
Re-adds the GlContext and provides implementations for Context, HeadlessContext and GlWindow.

I guess we should look into controlling the order of dropping

The drop order has been stabilized recently in Rust, so it's not a problem.

Looks good to me

@tomaka I just bumped the glutin version to 0.9 ready for publishing - just let me know if you want me to change it back.

Have had a chance to test this branch now; everything works as expected. Great work @mitchmindtree! :clap:


Must we split multi-allelic sites in our Genotype model?

Taking a look at https://github.com/ga4gh/schemas/blob/master/src/main/proto/ga4gh/variants.proto
again, @heuermh pointed out to me that indeed despite previously advocating a "one allele per row" model the current GA4GH model in the schema above directly support multi-allelic sites.
Specifically, the genotype_likelihood field here:
https://github.com/ga4gh/schemas/blob/master/src/main/proto/ga4gh/variants.proto#L132
can be a home to Number=G fields like GL, which we currently cannot represent in our "multi-allele splitting" model in ADAM.
@fnothaft and others, can you remind us here of what the history and motivation is for us to require splitting all multi-allelic sites?
IMO, There would be some advantages to using the current GA4GH model, even if represented in avro,  - including making it easier to round-trip a VCF file without data loss - including a home for Number=G fields, as well as better compatibility with GA4GH.
I'm considering making avro schemas like GA4GHVariant and GA4GHCall to explore the idea more concretely.

Here is some interesting documentation about how Hail handles multi-allele splitting
https://hail.is/commands.html#splitmulti

they state: "most analytic methods only support analyzing data represented as biallelics. Therefore, the current recommendation is to split multiallelics using the command splitmulti when importing a VCF"
This would seem to parallel ADAM's current focus on splitting alleles

To deal with INFO fields of number of alelles (R) they say:

"Hail does not split annotations in the info field. This means that if a multiallelic site with info.AC value [10, 2] is split, each split site will contain the same array [10, 2]. The provided allele index annotation va.aIndex can be used to select the value corresponding to the split allele's position"

They do have a "non split" mode when importing VCFs

@fnothaft and others, can you remind us here of what the history and motivation is for us to require splitting all multi-allelic sites?

they state: "most analytic methods only support analyzing data represented as biallelics. Therefore, the current recommendation is to split multiallelics using the command splitmulti when importing a VCF"

The TL;DR is that this was the exact motivation.

There's a variety of other representational issues too. E.g., what do you do for sites where you have a long INDEL/linear SV (e.g., loss of heterozygosity for a whole gene) that covers up all of the point variants on a haplotype?

Yeah - I guess my main interest was in being able to round trip a VCF into parquet/Hbase as a "lossless" archive.  However - this may not be a particularly urgent need, given if the gzipped VCF are on HDFS, they are pretty easy to go back to an scan quickly if the need arose to recover dropped tags or the exact multi-alleleic representation.   Thanks for the comments - I'mm gonna go ahead and keep  this closed this so it doesn't clutter.


Reference to eslint formatter left in webpack config when not including eslint in setup

Hello,
When answering no the question about eslint, an require is left in the webpack.base.conf.js file, making npm run dev fail with:
Error: Cannot find module 'eslint-friendly-formatter'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/???/projects/???/build/webpack.base.conf.js:5:31)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)

PR: #487

Yep. Had to install this '--save-dev' for the build to work.

@kazupon can be closed because of 0b8051f

@posva thanks


fix(apis_metainfo): rename tempatetags

The browsing_extras templatetags were initially merged from the browsing
application to make apis-core not depend on browsing. The webpage
application also has browsing_extras templatetags and therefore the
identical names led to a templates.E003 warning from Django.
This commit renames the templatetags module to apis_metainfo_extras.
It also moves the used templattag templates to the
templates/apis_metainfo/tags folder.
The commit also drops the nav_menu templatetag, because it turned out
that it was not used anywhere.
Closes: #163

Not a review, just wanted to point out a typo in the subject (assuming the subject becomes part of the log when commits are squashed) -> templatetags is missing an L.

Not a review, just wanted to point out a typo in the subject (assuming the subject becomes part of the log when commits are squashed) -> templatetags is missing an L.

Uhm, dunno how, but I seem to have got responsibility for commit & PR subject confused in my head while talking about how they interact -> fixed the typo myself, sry for the noise.


Switch matplotlib viewer to use reversed greys

This makes images shown more like ImageJ/FIJI.

Ready to go.


About Computational Complexity

Hello! Can you share how you calculate the GFLOPs and Params. I used thop to calculate and got your model GFLOPs = 1362.78 and Params = 16.01M.

The thop package may be inaccurate due to the customized network structure. I use the flop_count function here to calculate the model complexity. As for the Params, I sum up all the parameters in the network.
def calculate_model_param(model: nn.Module):
    total_params = 0
    trainable_params = 0
    non_trainable_params = 0

    # traverse model.parameters()
    for param in model.parameters():
        mul_value = np.prod(param.size())
        total_params += mul_value
        if param.requires_grad:
            trainable_params += mul_value  # trainable
        else:
            non_trainable_params += mul_value  # non-trainable

    total_params /= 1e6
    trainable_params /= 1e6
    non_trainable_params /= 1e6

    print(f'Total params: {total_params} M.')
    print(f'Trainable params: {trainable_params} M.')
    print(f'Non-trainable params: {non_trainable_params} M.')

Hope this can help you!


Add response for DELETE on resource that does not exist

So as far as I understand when I run DELETE /resource/1 and this resource does not exists, the correct response is a 204 because the result is the expected one and the same as if the resource would have existed. Is this correct?
If so, I would suggest to add this to the specs to make it explicit.

I'm pretty sure the result should be a simple 404 (or 410). 204 implies success and the operation here definitely didn't succeed, even if the end condition might be the same as if it had. Moreover, a 404 also communicates that the resource doesn't exist, so it's not like you lose communicating that aspect of the current state.
Then, if you go with a 404, the body of the response would be an error object filled out appropriately.

Okay, but maybe this should than be added to the specs.

I think this is currently covered by the spec's "Other Responses" section under Deleting Resources, which says that "A server MAY respond with other HTTP status codes...in accordance with HTTP semantics."
That said, a PR that either documents this case explicitly or includes an example error object for this case on the examples page could be useful. We don't want to list every single status in the main spec, as that would get really long and duplicative of the HTTP spec, but I could maybe be convinced that this case is mentioning directly...

Hey, actually, maybe this is not the right idea. I just found the following in the specs:
http://jsonapi.org/format/#crud-updating-relationship-responses-204

Note: This is the appropriate response to a POST request sent to a URL from a to-many relationship link when that relationship already exists. It is also the appropriate response to a DELETE request sent to a URL from a to-many relationship link when that relationship does not exist.

Reopening so we can figure out what to do about that note. Ping @dgeb. For reference, that note was originally added in https://github.com/json-api/json-api/commit/90d898a0cc141738bce3e4f20a868d4f21751dff and, at the time, there was a question about whether it was appropriate for DELETE requests. It looks like there was a determination that it was, but I'm not sure what the reasoning was. A 404 still seems more appropriate to me

The note addresses a situation where the item intended for deletion is not part of the related resources to begin with. A 404 there would imply a nonexistent relationship URL. This doesn't have to do with the case described by OP, where 404 is indeed the correct response.

To me 404 sounds fine as well, I just think there is a need to specify this in the specs.
Covering more cases (and I would not say this is an edge case) makes it easier to work with the specs.

As far as I know, DELETE methods should (or at least could) be designed as idempotent, but I believe the current proposal would prevent these efforts.
According to the RESTful Web Services Cookbook:

The DELETE method is idempotent. This implies that the server must return response code 200 (OK) even if the server deleted the resource in a previous request. But in practice, implementing DELETE as an idempotent operation requires the server to keep track of all deleted resources. Otherwise, it can return a 404 (Not Found).

That's why I wouldn't make the 404 response code compulsory for a DELETE request if a resource does not exist, including the following sentence (modified from @lukasoppermann 's PR) either in the recommendations or in the specs would be more appropriate in my opinion:

A server MAY return a 404 Not Found status code if a deletion request fails due to the resource not existing.

@kocsismate sounds good to me too, as long as there is a recommended guide. I will happily update if we all can agree upon this wording. 👍

Hey @ethanresnick I updated the PR #1029 as suggested by @kocsismate. What do you think, can this be merged?

Hey @lukasoppermann, thanks for following up on this.
I think the note in the spec that you pointed out earlier is still confusing and, while I understand @bintoro's reading of it, I'm not sure that reading is obvious from the current text. Regardless, I don't think the ambiguity in that note should hold up your PR.
I'll review that now.

Closing in favor of #1029


Future Plans: Link Health Monitoring

Description
Implement a feature that regularly checks if the shortened URLs are still valid and not returning errors like 404 or 500. This will help maintain the integrity of the URL shortening service by identifying and addressing broken links.
Tasks

[ ] Design Monitoring System

Design a system to periodically check the health of shortened URLs.
Ensure the system can handle a large number of URLs efficiently.

[ ] Implement URL Health Check

Implement functionality to check if a URL is returning errors like 404 or 500.
Ensure the health check is accurate and handles various types of errors.

[ ] Schedule Regular Checks

Set up a scheduler to run the URL health checks at regular intervals.
Ensure the scheduler is reliable and does not introduce significant overhead.

[ ] Store Health Status

Update the database schema to store the health status of each URL.
Ensure the health status is updated accurately after each check.

[ ] Notify Users

Implement functionality to notify users if their shortened URLs are found to be broken.
Ensure the notifications are clear and provide actionable information.

[ ] User Interface Updates

Update the user interface to display the health status of each URL.
Ensure the interface is user-friendly and intuitive.

[ ] Testing

Write unit tests to verify the functionality of the URL health checks.
Perform integration tests to ensure the monitoring system works seamlessly with the existing system.
Conduct user acceptance testing to ensure the feature meets user expectations.

[ ] Documentation

Update the documentation to include details about the link health monitoring feature.
Provide instructions on how to interpret the health status and address broken links.

Can I take this up?

Hello @asharan2buff, you can take this issue up, but first please explain your approaches and solutions 😃


Error while Downloading Pre-trained Model Weights

Hi,
Thank you for the code implementation of the nice work! I was encountering an error while trying to download your pre-trained model weights. Here is the error:

Could you please fix it? Thanks in advance!
Best,

I tried this one. It works.
https://github.com/ermongroup/ddim/blob/main/functions/ckpt_util.py#L12
They said they use the model from DDIM.

I tried this one. It works. https://github.com/ermongroup/ddim/blob/main/functions/ckpt_util.py#L12
They said they use the model from DDIM.

Thanks for replying!


Create a Log class, and make the NcLog class a child of that class. Replace all references to the NcLog class with a Log class instead, and have the logging be always correct for whatever the current view is.

Likely gonna have a log for the game that registers with every view, and then updates each view with its logs. The log levels are gonna come in handy, we can have different levels associated with every view so that different views are able to see more or less logs.


Don't force declarations=true

I've notice that gulp-tsb forces declarations compiler options to be true. (https://github.com/jrieken/gulp-tsb/blob/master/src/builder.ts#L68-L69)
Unfortunately, this causes a lot of errors in my app, like:
Parameter 'xxx' of public method from exported class has or is using private name 'xxx'.
Type parameter 'xxx' of exported function has or is using private name 'xxx'.

Since I don't need declarations in my project, I'm fine with them.
But fixing them all in order to migrate to gulp-tsb would be a drag.
Unless it's necessary for some internal workings, please consider not setting declarations to true.

Using declaration files under the hood is what makes gulp-tsb fast. It caches those for each file and when code changes change the shape of it's declaration-file it knows to re-check depended files. It's unfortunate that not all code works with this strategy.


ERROR: Assert `lut_slacks[node] >= 0' failed in passes/techmap/flowmap.cc:1295.

Steps to reproduce the issue
Using
flowmap_1295.tar.gz, run yosys -p "flowmap -maxlut 6 -optarea 4"  flowmap_1295.il.
Expected behavior
flowmap completes successfully.
Actual behavior
2. Executing FLOWMAP pass (pack LUTs with FlowMap-r).
Labeling cells.
Mapped to 1 LUTs with maximum depth 1.

Optimizing area.
Relaxing with depth bound 1.
  Relaxed to 1 (+0) LUTs.
  Slack exhausted.
Relaxing with depth bound 2.
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $procmux$266.B_AND_S [10] (potential 150).
  Relaxed to 2 (+1) LUTs.
  Slack exhausted.
Relaxing with depth bound 3.
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT \o_o [10] (potential 700).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 500).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] (potential 300).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] (potential 300).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT $procmux$266.B_AND_S [10] (potential 150).
  Relaxed to 3 (+1) LUTs.
  Slack exhausted.
Relaxing with depth bound 4.
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT \o_o [10] (potential 700).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 500).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] (potential 300).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] to extract LUT $procmux$266.B_AND_S [10] (potential 150).
  Relaxed to 4 (+1) LUTs.
  Slack exhausted.
Relaxing with depth bound 5.
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] to extract LUT \o_o [10] (potential 700).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 500).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:256:simplemap_eqne$340 (potential 100).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT $procmux$266.B_AND_S [10] (potential 250).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT \o_o [10] (potential 900).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 700).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT $procmux$266.B_AND_S [26] (potential 100).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT \o_o [11] (potential 900).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] to reuse LUT \o_o [11] (potential 450).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to reuse LUT \o_o [11] (potential 500).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] (potential -100).
ERROR: Assert `lut_slacks[node] >= 0' failed in passes/techmap/flowmap.cc:1295.

cc @whitequark

Hm, why is it breaking a LUT with a negative potential? That implies the result would be worse.

Try this patch:
diff --git a/passes/techmap/flowmap.cc b/passes/techmap/flowmap.cc
index 5807178d..dae05a66 100644
--- a/passes/techmap/flowmap.cc
+++ b/passes/techmap/flowmap.cc
@@ -1188,7 +1188,8 @@ struct FlowmapWorker
 				if (debug_relax)
 					log("    Potential for breaking node %s: %d (Rex=%d, Rim=%d, Rslk=%d).\n",
 					    log_signal(lut_gate), p, r_ex, r_im, r_slk);
-				potentials[lut][lut_gate] = p;
+				if (p > 0)
+					potentials[lut][lut_gate] = p;
 			}
 		}
 	}

I'm not sure if it's the right fix though, would need to investigate in depth for that.

Indeed, that fixes this (log below), along with #1405. However, it introduces a new bug (Assert node_origins.count(gate_node)' failed in passes/techmap/flowmap.cc:1369`) in #1475.
2. Executing FLOWMAP pass (pack LUTs with FlowMap-r).
Labeling cells.
Mapped to 1 LUTs with maximum depth 1.

Optimizing area.
Relaxing with depth bound 1.
  Relaxed to 1 (+0) LUTs.
  Slack exhausted.
Relaxing with depth bound 2.
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $procmux$266.B_AND_S [10] (potential 150).
  Relaxed to 2 (+1) LUTs.
  Slack exhausted.
Relaxing with depth bound 3.
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT \o_o [10] (potential 700).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 500).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] (potential 300).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] (potential 300).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT $procmux$266.B_AND_S [10] (potential 150).
  Relaxed to 3 (+1) LUTs.
  Slack exhausted.
Relaxing with depth bound 4.
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT \o_o [10] (potential 700).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 500).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$356 [1] to extract LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] (potential 300).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] to extract LUT $procmux$266.B_AND_S [10] (potential 150).
  Relaxed to 4 (+1) LUTs.
  Slack exhausted.
Relaxing with depth bound 5.
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] to extract LUT \o_o [10] (potential 700).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$351 [2] to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 500).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $auto$simplemap.cc:256:simplemap_eqne$340 (potential 100).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT $procmux$266.B_AND_S [10] (potential 250).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT \o_o [10] (potential 900).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] (potential 700).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT $procmux$266.B_AND_S [26] (potential 100).
  Breaking LUT $auto$simplemap.cc:256:simplemap_eqne$340 to extract LUT \o_o [11] (potential 900).
  Breaking LUT $auto$simplemap.cc:127:simplemap_reduce$342 [5] to reuse LUT \o_o [11] (potential 450).
  Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to reuse LUT \o_o [11] (potential 500).
  Relaxed to 4 (+0) LUTs.
  Slack exhausted.

Packing cells.
Packing alsru.$auto$simplemap.cc:136:simplemap_reduce$731.\Y (\o_o [11]).
  Packing alsru.$auto$simplemap.cc:85:simplemap_bitop$765.\Y ($procmux$266.B_AND_S [27]).
  Packed into a 1-LUT alsru.$auto$flowmap.cc:1411:pack_cells$1310.
Packing alsru.$auto$simplemap.cc:136:simplemap_reduce$348.\Y ($auto$simplemap.cc:127:simplemap_reduce$342 [5]).
  Packing alsru.$auto$simplemap.cc:136:simplemap_reduce$733.\Y (\o_o [10]).
  Packing alsru.$auto$simplemap.cc:85:simplemap_bitop$780.\Y ($procmux$266.B_AND_S [10]).
  Packing alsru.$auto$simplemap.cc:85:simplemap_bitop$764.\Y ($procmux$266.B_AND_S [26]).
  Packing alsru.$auto$simplemap.cc:85:simplemap_bitop$814.\Y (\$10 [10]).
  Packed into a 4-LUT alsru.$auto$flowmap.cc:1411:pack_cells$1311.
Packing alsru.$auto$simplemap.cc:136:simplemap_reduce$360.\Y ($auto$simplemap.cc:256:simplemap_eqne$340).
  Packing alsru.$auto$simplemap.cc:136:simplemap_reduce$358.\Y ($auto$simplemap.cc:127:simplemap_reduce$356 [1]).
  Packing alsru.$auto$simplemap.cc:136:simplemap_reduce$354.\Y ($auto$simplemap.cc:127:simplemap_reduce$351 [2]).
  Packed into a 4-LUT alsru.$auto$flowmap.cc:1411:pack_cells$1312.
Packing alsru.$auto$simplemap.cc:206:simplemap_lognot$362.\Y ($auto$bugpoint.cc:222:simplify_something$247).
  Packing alsru.$auto$simplemap.cc:85:simplemap_bitop$764.\Y ($procmux$266.B_AND_S [26]).
  Packed into a 2-LUT alsru.$auto$flowmap.cc:1411:pack_cells$1313.

Packed 12 cells (1 of them duplicated) into 4 LUTs.
Solution takes 118.8% of original gate area.

Unlike the other two issues you filed which have trivial fixes, this one points to a fundamental limitation of the IR used in the flowmap pass, and fixing it properly is fairly involved. In short, breaking out LUT w from LUT v and then LUT k from LUT v' does not necessarily result in a graph with LUTs v'', k, and w. In fact, if LUT k happens to include LUT w, then the second operation will result in a graph with only LUTs v'' and k. This violates the invariants of this operation and greatly confuses relaxation code. (It has nothing to do with negative potentials.)
This could probably be fixed relatively easily by going through any newly broken out LUT and "replaying" such previous operations. But it seems like there can be a more efficient way, perhaps with an IR that is more directly based on MFFCs? This is an interesting research problem worth maybe a week of work, which I don't have right now.

Incidentally the flowmap pass currently does not implement DF-Map, MP-Pack or Flow-Pack, so right now relaxation will always make the design perform worse.

I understood most of your explanation here except for what an MFFC is in this context.

Minimal fanout-free cone. See the long version of paper.

So, I was examining this a bit further.
Here's the solution before relaxation:

The most important thing to note, in my opinion, is that this solution is area-optimal already, and flowmap should have returned as such: there is no way to relax the design without increasing the critical path.
At depth 2, flowmap decides to break out a gate:
    Considering breaking node $procmux$266.B_AND_S [10].
      Breaking requires a new LUT.
      Breaking eliminates LUT inputs $auto$bugpoint.cc:222:simplify_something$1210.
      Breaking may allow merging $auto$bugpoint.cc:222:simplify_something$1183 and $auto$bugpoint.cc:222:simplify_something$247.
      Breaking may allow merging $auto$bugpoint.cc:222:simplify_something$1190 and $auto$bugpoint.cc:222:simplify_something$247.
      Breaking may allow merging $auto$bugpoint.cc:222:simplify_something$1280 and $auto$bugpoint.cc:222:simplify_something$247.
      Breaking may allow merging $auto$bugpoint.cc:222:simplify_something$1197 and $auto$bugpoint.cc:222:simplify_something$247.
      Breaking may allow merging $auto$bugpoint.cc:222:simplify_something$1199 and $auto$bugpoint.cc:222:simplify_something$247.
      Breaking increases depth of LUT by 1.
      Breaking decreases slack of outputs $auto$bugpoint.cc:222:simplify_something$247.
    Potential for breaking node $procmux$266.B_AND_S [10]: 150 (Rex=-1, Rim=5, Rslk=1).
[snip]
Breaking LUT $auto$bugpoint.cc:222:simplify_something$247 to extract LUT $procmux$266.B_AND_S [10] (potential 150).
    Removing breaking gate $procmux$266.B_AND_S [10] from LUT.
    Removing LUT edge $auto$bugpoint.cc:222:simplify_something$1210 -> $auto$bugpoint.cc:222:simplify_something$247.
    Adding LUT edge $procmux$266.B_AND_S [10] -> $auto$bugpoint.cc:222:simplify_something$247.
  Updating slack and potentials.
    LUT $auto$bugpoint.cc:222:simplify_something$247 now has depth 2 and slack 0.
    LUT $procmux$266.B_AND_S [10] now has depth 1 and slack 0.

Here's the thing: this gate does not have slack, and flowmap knows it, but decides to break it out anyway. This suggests this code is incorrect:
https://github.com/YosysHQ/yosys/blob/89ed34fe55fd6a70b51ff68439e68f9a9e0b9e0f/passes/techmap/flowmap.cc#L1163-L1169
So to me, there are two interplaying bugs here: first that the relaxation code gets confused, as you've described, and second that flowmap should not attempt to relax this in the first place.


Server Startup Crash (Mob Enchantments Config)

Mod Version: dungeons_mobs-1.16.5-2.0.2-beta.jar
Forge Version: 36.2.2
debug.log
Deleting the config file, 'dungeons-mobs-mob-enchantments-common.toml' resolves the issue, but once the server generates the config the next start-up crashes again. Also using the latest dungeons library beta.

Also having this same problem with Forge 36.2.20.

Can also confirm that it's happening with Forge 36.2.33, the most recent version for 1.16.5.

should be fixed on later betas


No levelling up curve implementation yet?

Hi,
I am currently asking NFITC1 for the source code for Wallmarket.  Please join The Reunion Discord:https://thereunion.live/
I'd like to help in any small way to getting this editor to a completion - since Wallmarket (I have v 1.5) looks to have been abandoned.
Dan

As discussed, here is the fully working program in Lazarus - and a basic translation into C
Demonstration_of_kernel_curves.zip
c.txt


Impossible to use siwe library due to issues with ethers v6 and v5.

Trying to use with ethers v6

Trying to use with ethers v5

+1 I just came here to create this exact same issue

Also have the same issue. Seems there is a problem of compatibility for siwe v2 and ethers v6. Had to use siwe v1 and ethers v5 to make it work for me.


error when run composer install

i'm trying to use the FOSMessage with symfony , i've download it and configure it however when trying to run composer install  i got this error
[InvalidArgumentException] Bundle "fos_message" does not exist or it is not enabled.
i know it is not a bundle yet so do i neet to enable in the symfony  appkernel.php ? or what .

Hello @hero789,
FOSMessage is just a simple library : once you installed it with Composer, no need to install it anywhere else (you don't need to change the AppKernel.php file). You simply need to use the classes provided by the library inside your controllers.
You can check http://fosmessage.readthedocs.org/en/latest/book/getting_started.html#configuration-using-symfony for more details :) .


INI Reload

Is there functionality to reload the ini on some schedule or with a command? For example hourly or daily? Or does the app/docker need to be stopped and restarted to reload?

There isn't.
Redirects are read once and stored as an instance variable:
https://github.com/DannyBen/redirectly/blob/b9a0996854754887f985f1133539f117885a3236/lib/redirectly/app.rb#L66
What I can do easily if it helps, is to have an environment variable, say REDIRECTLY_RELOAD=1, that when set, will avoid storing the INI as a variable, so it will read the INI on each redirect.
Will this help?
Another option is to have a specific URL that resets this instance variable, but then we occupy the namespace that is currently serving the redirects themselves, which I would like to avoid.

Or - a third option, is to have something in the INI to point to "internal commands":
proxy.example.com/reset = :reload

I was thinking something more like a redirrectly --reload command that forced a the ini to reread so that a cron job could send the command. Or a quartz task that could be fed an environment value in minutes that caused a reread of the ini.
Trying to simplify a sharing of the ini so it could be updated by multiple people or processes and the updated ini entries would be processed without having to do a full stop and restart of the app/docker. One thing to give a process the rights to edit a file but another to give it control of a process.

Once you run redirectly, you cannot influence it from the command line (by running rediretly --reload or any other means).
Only the server itself (i.e. by receiving a URL) can reload the INI file, or, as I mentioned, by always forcing the server to reload.
These are the only two options I can think of.

Curling the URL defined via the ini would work well. Thank you

I will probably implement both tomorrow. Will update.

Both features are now implemented if you want to test (:edge).

Always reload:$ redirectly --reload
# or
$ REDIRECTLY_RELOAD=1 redirectly

Add a URL that reloads:test.localhost/reload = :reload

More info in each PR and in the master README

Excellent.
If there are no other changes needed, I will release on the weekend.
Thanks for your support.

Version 0.4.0 is released with this feature. Thanks for the suggestion.


Followup #386: update the ClusterRole for yurt-controller-manager

What type of PR is this?
/kind bug
What this PR does / why we need it:
Followup #386: update the ClusterRole for yurt-controller-manager
Fix the following errors:
yurtcontroller-manager version: projectinfo.Info{GitVersion:"v0.4.0", GitCommit:"131c435", BuildDate:"2021-08-06T05:44:31Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
W0806 07:24:33.917457       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0806 07:24:33.921118       1 controllermanager.go:141] Version: v0.0.0-master+$Format:%h$
I0806 07:24:33.921856       1 leaderelection.go:242] attempting to acquire leader lease  kube-system/yurt-controller-manager...
I0806 07:24:33.941093       1 leaderelection.go:252] successfully acquired lease kube-system/yurt-controller-manager
I0806 07:24:33.941970       1 event.go:278] Event(v1.ObjectReference{Kind:"Lease", Namespace:"kube-system", Name:"yurt-controller-manager", UID:"fb92234f-f1bf-40e5-9b64-cdc28ee8e5e1", APIVersion:"coordination.k8s.io/v1", ResourceVersion:"4869", FieldPath:""}): type: 'Normal' reason: 'LeaderElection' yurt-controller-manager-b856b7f79-2fmbj_026128d6-72a8-49ea-98a5-498de7a7bcac became leader
I0806 07:24:33.970116       1 csrapprover.go:59] starting the crsapprover
I0806 07:24:33.970262       1 controllermanager.go:344] Started "yurthubcsrapprover"
I0806 07:24:33.973253       1 node_lifecycle_controller.go:385] Sending events to api server.
I0806 07:24:33.974898       1 taint_manager.go:168] Sending events to api server.
I0806 07:24:33.975845       1 node_lifecycle_controller.go:513] Controller will reconcile labels.
I0806 07:24:33.975960       1 controllermanager.go:344] Started "nodelifecycle"
I0806 07:24:33.977082       1 node_lifecycle_controller.go:547] Starting node controller
I0806 07:24:33.977104       1 shared_informer.go:223] Waiting for caches to sync for taint
E0806 07:24:33.994306       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
I0806 07:24:34.077866       1 shared_informer.go:230] Caches are synced for taint
I0806 07:24:34.078167       1 node_lifecycle_controller.go:1434] Initializing eviction metric for zone:
W0806 07:24:34.078529       1 node_lifecycle_controller.go:1049] Missing timestamp for Node kind-worker2. Assuming now as a timestamp.
I0806 07:24:34.079197       1 taint_manager.go:192] Starting NoExecuteTaintManager
I0806 07:24:34.079269       1 event.go:278] Event(v1.ObjectReference{Kind:"Node", Namespace:"", Name:"kind-worker2", UID:"dfa9737f-4d50-40dc-8d38-b83482cc6c71", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'RegisteredNode' Node kind-worker2 event: Registered Node kind-worker2 in Controller
I0806 07:24:34.079782       1 event.go:278] Event(v1.ObjectReference{Kind:"Node", Namespace:"", Name:"kind-worker", UID:"f68b44c1-ae67-4416-8b7d-5258d5175d13", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'RegisteredNode' Node kind-worker event: Registered Node kind-worker in Controller
I0806 07:24:34.079812       1 event.go:278] Event(v1.ObjectReference{Kind:"Node", Namespace:"", Name:"kind-control-plane", UID:"80dd6679-cc6b-4fee-9d3c-cd77213bc4c1", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'RegisteredNode' Node kind-control-plane event: Registered Node kind-control-plane in Controller
I0806 07:24:34.079963       1 event.go:278] Event(v1.ObjectReference{Kind:"Node", Namespace:"", Name:"kind-worker3", UID:"d7c3cd96-94b1-44a6-9a85-0f2d78c05574", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'RegisteredNode' Node kind-worker3 event: Registered Node kind-worker3 in Controller
W0806 07:24:34.079439       1 node_lifecycle_controller.go:1049] Missing timestamp for Node kind-control-plane. Assuming now as a timestamp.
W0806 07:24:34.081548       1 node_lifecycle_controller.go:1049] Missing timestamp for Node kind-worker3. Assuming now as a timestamp.
W0806 07:24:34.082856       1 node_lifecycle_controller.go:1049] Missing timestamp for Node kind-worker. Assuming now as a timestamp.
I0806 07:24:34.083261       1 node_lifecycle_controller.go:1250] Controller detected that zone  is now in state Normal.
E0806 07:24:35.085377       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:24:38.220201       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:24:44.298675       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:24:57.051524       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:25:19.600795       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:26:10.152656       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:26:45.418166       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:27:39.678756       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:28:25.111798       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:29:07.067993       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:29:44.372375       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope
E0806 07:30:42.369670       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.8/tools/cache/reflector.go:125: Failed to list *v1beta1.CertificateSigningRequest: certificatesigningrequests.certificates.k8s.io is forbidden: User "system:serviceaccount:kube-system:yurt-controller-manager" cannot list resource "certificatesigningrequests" in API group "certificates.k8s.io" at the cluster scope

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Does this PR introduce a user-facing change?

other Note

/assign @rambohe-ch

/lgtm
/approve


Respect configured host in bindings

When setting ASPNETCORE_URLS env variable in ProcessRunner. This makes it possible to override which interface to bind to and also allow connections from anywhere by using a wildcard.
This is only tested for services configured as projects. Not sure how this affects other aspects of Tye.
Fixes #721

@veloek In general, looks good.  The only thing I've noticed in testing is that, while tye run will now respect the specified host, tye run --docker will not.  That is, the container port will still be mapped to all IP addresses of the host (which is the Docker default for mapped ports).  It appears this happens for similar reasons, where DockerRunner.cs ignores the Host property of the binding.

@philliphoff, I didn't test Docker containers myself, but I see your point. Will try to sort that out as well 🙂

@philliphoff, good catch! Didn't try running my services in Docker containers, but it makes sense to fix that as well while at it 👍

@veloek Take a look at my update to the PR and see if anything looks amiss.
@ravipal Since I've made changes, can you do a quick review as well?

@philliphoff LGTM. If I were to nitpick, I see you use capital S in String which seems inconsistent with the rest of the code.

Ah, the hazards of owning codebases with entirely different style guides. :-)


chore: prep 1.10.0 release

/deploy #persist

You can access the deployment of this PR at https://renku-ci-nb-1218.dev.renku.ch


remove_singletons in ColoredHyperGraph throws error.

What :
remove_singletons() method of CHG does not work, throws error during creating a new CHG using restrict_to_cells() method.
When: (example below)
        CHG = ColoredHyperGraph([[1, 2, 3], [2, 3, 4]], ranks=2)
        CHG.add_cell([9]) #add a singleton cell
        assert CHG.singletons() == [(frozenset({9}), 0)] #works
        CHG.remove_singletons() #Throws error!

KeyError: 'hyperedge (frozenset({1, 2, 3}), 0) is not in the complex'
The above error is thrown during runtime of restrict_to_cells.
How to reproduce:

Create a CHG with singleton cells.
Verify the singleton cells using CHG.singletons()
Try to remove singletons using CHG.remove_singletons()

Places to fix:
restrict_to_cells method of ColoredHyperGraph

This is being addressed with PR #348

Closed with PR #348


chore: add stdlib deploy script

What does this PR do?
adds deploy script for stdlib
deploy stdlib to arbitrum-goerli
Related ticket
Fixes #
Type of change

[x] Chore
[ ] Bug fix
[ ] New feature
[ ] Documentation update

Check list

[ ] Unit tests for any smart contract change
[ ] Contracts and functions are documented

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (a464ff0) 94.24% compared to head (02c006e) 94.24%.

Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #440   +/-   ##
=======================================
  Coverage   94.24%   94.24%
=======================================
  Files          19       19
  Lines         313      313
  Branches       68       68
=======================================
  Hits          295      295
  Misses          9        9
  Partials        9        9

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Blocked until #439 is merged


TypeError: wgs84Sphere.midpoint is not a function

For some reason, default build doesn't include ol.Sphere methods. I tried to make a custom build, listing explicitly all the methods, but they are not exported anyway. Can anybody tell, please, if there any option I should set?

Only ol.Sphere#geodesicArea and ol.Sphere#haversineDistance are exported.
We could export ol.Sphere#midpoint as well.

ol.Sphere.haversineDistance is not a function too (using official v3.2.1 release builds).
I've tried to build my own with
"exports": [
	...,

	"ol.Sphere",
	"ol.Sphere#*",

	...
}

or
"exports": [
	...,

	"ol.Sphere#cosineDistance",
	"ol.Sphere#geodesicArea",
	"ol.Sphere#crossTrackDistance",
	"ol.Sphere#equirectangularDistance",
	"ol.Sphere#finalBearing",
	"ol.Sphere#haversineDistance",
	"ol.Sphere#interpolate",
	"ol.Sphere#initialBearing",
	"ol.Sphere#maximumLatitude",
	"ol.Sphere#midpoint",
	"ol.Sphere#offset",

	...
}

Nothing helps, they are not exported.

you'll need to add @api annotation in the source code doc blocks as well

@bartvde, thank You very much, now they are exported (-:
Issue can be closed.


[WIP] Upgrade to py-evm v0.2.0 alpha 43

To-Do

[ ] Add entry to the release notes PR

Cute Animal Picture

Pretty sure the error is unrelated: documented in #638


Functionality to mark an application "on hold" and send an email to the candidate

Targets #1542

@Bahugunajii Sharing a couple of observations:

[ ] Can we adjust the width of the dropdown so that the buttons look a bit presentable in the UI

[ ] Can we have the variables mapping the mail template for putting an application on hold, sharing the mail template below:

Dear |*applicant_name*|,

Thanks for applying to ColoredCow for the position |*job_title*|. We don't have a relevant opening for the position right now. We have kept, your application is kept under waiting and we will reach out to you if there are any possibilities we can explore together.

Thanks,
HR team,
ColoredCow

|applicant_name| and  |job_title| will be mapped in the backend based on the application details. You can see other mail templates for reference.

[ ] On putting an application to hold, the status and label of the application are not changed. Once an application is made on hold, the page should redirect to the application listing page, and the application should be moved to the on-hold section with the on-hold label on it. Currently, it sits in the Open listing with the new application tag.


CASSANDRA-17385 trunk: Guardrails for items per UDT

CI after rebasing and adding those missed annotations:
https://app.circleci.com/pipelines/github/adelapena/cassandra/1419/workflows/e6979419-4281-4104-9d73-bbe1fa7a922c
https://app.circleci.com/pipelines/github/adelapena/cassandra/1419/workflows/af7b27b1-499d-429d-bf98-fbb246c0ea13

It seems the build failed, I guess something happened during the rebase?

Just checked, after rebase we need to acknowledge the change done during the addition of diagnostic events - https://github.com/apache/cassandra/commit/143a5e8b064e442970182cfb349b4f0826683e85#diff-2a4565f85cf8de9d1098e67f5c18af0368a7e826abfccff1a79c067653b61b2eR123

I'd say last CI run looks good.

I don't think we really need upgrade tests or any of the others like compression but I am wondering whether we want to add some of those to the pre-commit workflow. Like those for keyspace directories are not run in Jenkins and every now and then regress as people tend not to run them. I can open a ticket, I was just wondering what you think about this.

Anything added to CI has the downside of increasing the cost, so I think we should be cautious when adding jobs to the pre-commit workflow. I understand that the once-a-week run of CircleCI done by the build lead should include all suites, so we can detect problems with those jobs.
As for the particular case of system keyspace directories, I don't know how easy is to figure out that a change can have an impact on those tests. If they are easy to break with apparently unrelated changes then we should probably include them on pre-commit tests.


feature/credits-page

Create credits page with pictures, names and LinkedIn\Mail.
Create AUTHORS.md (I added some github names at the end of people who didn't give their names)

Names are ordered by alphabetic last name.

Codecov Report

Merging #261 (c93322f) into develop (cff596e) will decrease coverage by 0.09%.
The diff coverage is 85.71%.

@@             Coverage Diff             @@
##           develop     #261      +/-   ##
===========================================
- Coverage    98.77%   98.67%   -0.10%
===========================================
  Files           64       65       +1
  Lines         2849     2872      +23
===========================================
+ Hits          2814     2834      +20
- Misses          35       38       +3

Impacted Files
Coverage Δ

app/main.py
92.85% <ø> (ø)

app/routers/credits.py
85.71% <85.71%> (ø)

app/routers/salary/config.py
100.00% <0.00%> (ø)

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 cff596e...c93322f. Read the comment docs.


[ENH] Table scitype and refactor of convert module

This PR refactors the datatypes module and adds a Table scitype, details below.
This is in anticipation of two things:

refactoring and extension of transformer tests
moving conversions in classifiers to datatypes, my contribution to https://github.com/alan-turing-institute/sktime/pull/1594

The changes to the datatypes module:

the test_convert tests are refactored - the six loops over fixtures (from, to, fixture, etc) are moved to pytest_test_generate where it belongs. This should make the code much easier to read.
similarly, the individual conversions now appear as individual fixture combinations, which should make debugging much easier
a Table scitype is added. The mtypes are pandas DataFrame, numpy1D, and numpy2D. This will be useful for checks and conversions as follows: to check the output of transformers with a Primitives output - this must be DataFrame; to check the output of classifiers - this must be numpy1D; for classifiers to accept the other two mtypes in fitting.
a metadata field has_nans which checks whether the container has any nans

@chrisholder, @MatthewMiddlehurst, @TonyBagnall, would appreciate your review, as this will be a dependency of the classifier conversions.
@Lovkush-A, you might also be happy over how the convert tests have been refactored.

quick question, @TonyBagnall, @chrisholder, @matthewmiddlehusrt:
in #1594, do you have a method that checks whether nested_univ data containers have nans?
If so, kindly point me to it, since I don't want to re-implement this...

If so, kindly point me to it, since I don't want to re-implement this...

Found and added.

Ultimately, we should whether the check functions correctly recover properties of a fixture.
That is, add functionality to the examples modules to specify what properties the fixtuers have, and then write a test to check.
Each mtype/property combination should appear (at least) twice, once with the property positive, and once as a negative.

appveyor timed out, but seems fine. Merging so I can get to work more easily on dependencies.


Title and Icon are not resetting properly after browser refresh and null setting

Current Behavior
Title and icon values are not resetting back to the default after setting the particular dynamic property values to null
Expected Behavior
Widgets should display the original value after settings dynamic properties to null
Steps To Reproduce

Add a text input or gauge node.
Set a title via widget properties.
Update title or icon dynamically using an inject node.
Reload the dashboard 2.0 after the particular value got updated in the UI.
set null to dynamic properties and inject.

Environment

Dashboard version: 1.15.0
Node-RED version: 4.0.2
Node.js version: 20
npm version:
Platform/OS:
Browser:

Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate

Hi @gayanSandamal,
I think this is caused by an unimplemented TODO comment that you can find in the datatracker file.  Let's for example have a look at the UIText widget:

So instead of implementing the onInput function in each widget again (which will contain mostly the same logic for lots of widgets), a lot of widgets (re)use the onInput function which has been implemented in the datatracker.  You can see that because null is passed to the datatracker, instead of passing a custom onInput function.
Suppose you inject an input msg whose payload contains the text:

The input message arrives on the frontend
Since there is no custom onInput specified, you arrive in the default onInput code which stores ALL input messages into the datastore.
Those messages are mapped to the widget
So the computed field value gets that latest stored message.  Since the last msg has a payload, that payload value (containing the text) will be returned.
That way your text from the payload will be binded and displayed in your html.

So far so good.
But afterwards you inject a message without payload, just to set some dynamic property.  All 5 steps are repeated.  However in step 4 there is no payload so an empty string is returned.  That will be binded to your html, and as a result your title disappears.
So I think the datatracker should be fixed.  Until recently it was ok that the datatracker stored ALL messages into the datastore.  But since the mechanism of dynamic properties has been introduced, only (messages with) payloads should be stored.  Because we only use payloads from the input messages via the datastore.  All dynamic properties from those messages are stored in the statestore.  Allthough I am not 100% sure that only payloads are being used.  Perhaps msg.options and (legacy) stuff like that are still stored in messages in datastore.  Not sure, you need to check that!!!
Therefore I 'think' the default onInput code in the datatrackers should only store messages that have a payload:
            socket.on('msg-input:' + widgetId, (msg) => {
                // check for common dynamic properties cross all widget types
                checkDynamicProperties(msg)

                if (onInput) {
                    // sometimes we need to have different behaviour
                    onInput(msg)
                } else {
                    // but most of the time, we just care about the value of msg
                    if (typeof msg.payload !== 'undefined') {
                        store.commit('data/bind', {
                            widgetId,
                            msg // TODO: we should sanitise what is stored in the store?
                            // One way to do this is to permit only keys explicitly listed in the widget's config (default to topic+payload if none are specified)
                            // A smarter? way to do this is to scan the template for msg.? binds and store only those keys
                            // For now, we'll just store the whole msg
                        })
                    }
                }
            })

Imho it is very confusing to store entire messages, if you only need their payload.  I would say it is better to store the payload (which contains the data) in the datastore...
Hopefully it makes sense what I am writing.
Bart

Imho it is very confusing to store entire messages, if you only need their payload. I would say it is better to store the payload (which contains the data) in the datastore...

I agree, there is nothing to warrant third party nodes saving just payloads.
Core widgets are implemented to store msg, but we can correct this in the future. We are have far more pressing issues elsewhere though, which will have more obvious impact to users, whereas this, we can invest 2 weeks of dev time to update all core nodes, and it'll have zero impact on the users interactions with Dashboard

@joepavitt Yes I absolutely agree that you currently have more important things to do.  And enjoy your holidays...

Hi @gayanSandamal,
I think this is caused by an unimplemented TODO comment that you can find in the datatracker file. Let's for example have a look at the UIText widget:

So instead of implementing the onInput function in each widget again (which will contain mostly the same logic for lots of widgets), a lot of widgets (re)use the onInput function which has been implemented in the datatracker. You can see that because null is passed to the datatracker, instead of passing a custom onInput function.
Suppose you inject an input msg whose payload contains the text:

The input message arrives on the frontend
Since there is no custom onInput specified, you arrive in the default onInput code which stores ALL input messages into the datastore.
Those messages are mapped to the widget
So the computed field value gets that latest stored message.  Since the last msg has a payload, that payload value (containing the text) will be returned.
That way your text from the payload will be binded and displayed in your html.

So far so good.
But afterwards you inject a message without payload, just to set some dynamic property. All 5 steps are repeated. However in step 4 there is no payload so an empty string is returned. That will be binded to your html, and as a result your title disappears.
So I think the datatracker should be fixed. Until recently it was ok that the datatracker stored ALL messages into the datastore. But since the mechanism of dynamic properties has been introduced, only (messages with) payloads should be stored. Because we only use payloads from the input messages via the datastore. All dynamic properties from those messages are stored in the statestore. Allthough I am not 100% sure that only payloads are being used. Perhaps msg.options and (legacy) stuff like that are still stored in messages in datastore. Not sure, you need to check that!!!
Therefore I 'think' the default onInput code in the datatrackers should only store messages that have a payload:
            socket.on('msg-input:' + widgetId, (msg) => {
                // check for common dynamic properties cross all widget types
                checkDynamicProperties(msg)

                if (onInput) {
                    // sometimes we need to have different behaviour
                    onInput(msg)
                } else {
                    // but most of the time, we just care about the value of msg
                    if (typeof msg.payload !== 'undefined') {
                        store.commit('data/bind', {
                            widgetId,
                            msg // TODO: we should sanitise what is stored in the store?
                            // One way to do this is to permit only keys explicitly listed in the widget's config (default to topic+payload if none are specified)
                            // A smarter? way to do this is to scan the template for msg.? binds and store only those keys
                            // For now, we'll just store the whole msg
                        })
                    }
                }
            })

Imho it is very confusing to store entire messages, if you only need their payload. I would say it is better to store the payload (which contains the data) in the datastore...
Hopefully it makes sense what I am writing. Bart

Hi @bartbutenaers ,
Thanks so much for digging into this and providing such a detailed explanation! I really appreciate the time and effort you put into breaking it all down.
Your insights are super helpful. We’ll dive into this with the suggestions you made once we started working on this particular issue and see how we can move forward with this.

I spent some time looking into this today and i think it is far simpler.
When emitConfig is called we currently merge any dynamic updates into props this compounds changes when the page is refreshed.
Since we have a design pattern now (with updateDynamicProperty and getProperty) the dynamic overrides are applied client side at render so there really is no need to compound changes.
By simply chaning the line of code from
 widget.props = { ...widget.props, ...state }
to
 widget.props = { ...widget.props }
the real (original) props are sent on config emit and the design patter for dynamic updates are applied as usual
Demo: BEFORE

Demo: AFTER

Hi @Steve-Mcl ,
Thanks for digging into this further!!
Is this somehow related to mapState('data', ['messages', 'properties'])?  Not really sure what kind of magic it all does unfortunately, so a bit difficult to give decent feedback on your comments.  I have already an open issue issue (first task) on my new video player node about the use of mapData.


Where is the objects.inv file in the documentation?

In my documentation, I want references to Skan classes and functions using intersphinx. For that, I need an objects.inv file. (see also here). Related.. Do you have experience on hwo to solve it? If no, don't spend time with it, not that important.

@CsatiZoltan TIL that the objects.inv file for skan can be found at https://jni.github.io/skan/objects.inv! 😂
fyi the way I figured this out is by cd-ing into doc, running make html, then checking _build/html and finding that there is indeed that file right there at the root of the build. =)

Thanks, works perfectly. Now I know how to fetch them for other projects as well!


Did I find a softlock?

Seed Information
https://sotn.io/?12b,1618262658587
Randomizer version:
3.5.6 Safe
Spoilers:
Seed:<PHONE_NUMBER>587
Starting equipment:
Morningstar
Medusa shield
Steel helm
Cloth tunic
Blood cloak
Turquoise
Relic locations:
Soul of Bat at Silver ring
Fire of Bat at Cube of Zoe
Echo of Bat at Fire of Bat
Force of Echo at Eye of Vlad
Soul of Wolf at Crystal cloak
Power of Wolf at Spirit Orb
Skill of Wolf at Soul of Bat
Form of Mist at Gas Cloud
Power of Mist at Demon Card
Gas Cloud at Dark Blade
Cube of Zoe at Merman Statue
Spirit Orb at Trio
Gravity Boots at Soul of Wolf
Leap Stone at Mormegil
Holy Symbol at Ring of Arcana
Faerie Scroll at Echo of Bat
Jewel of Open at Form of Mist
Merman Statue at Power of Mist
Bat Card at Leap Stone
Ghost Card at Ghost Card
Faerie Card at Skill of Wolf
Demon Card at Ring of Vlad
Sword Card at Jewel of Open
Sprite Card at Tooth of Vlad
Nosedevil Card at Force of Echo
Heart of Vlad at Holy glasses
Tooth of Vlad at Heart of Vlad
Rib of Vlad at Rib of Vlad
Ring of Vlad at Faerie Card
Eye of Vlad at Bat Card
Spike Breaker at Power of Wolf
Diamond at Gold ring
Silver Ring at Spike Breaker
Stone mask at Holy Symbol
Solutions:
Stone mask < Merman Statue < Leap Stone
^ Soul of Wolf < Jewel of Open < Gravity Boots
^ Power of Wolf
Heart of Vlad
^ Silver Ring
^ Soul of Bat
^ Form of Mist < Stone mask < Merman Statue < Leap Stone
^ Soul of Wolf < Jewel of Open < Gravity Boots
^ Power of Wolf
^ Spike Breaker < Leap Stone
^ Soul of Wolf < Jewel of Open < Gravity Boots
^ Power of Wolf
^ Echo of Bat < Leap Stone
^ Soul of Wolf < Jewel of Open < Gravity Boots
^ Power of Wolf
^ Diamond < Leap Stone
^ Soul of Wolf < Jewel of Open < Gravity Boots
^ Power of Wolf
Tooth of Vlad < Stone mask < Merman Statue < Leap Stone
^ Soul of Wolf < Jewel of Open < Gravity Boots
^ Power of Wolf
Rib of Vlad < Stone mask < Merman Statue < Leap Stone
^ Soul of Wolf < Jewel of Open < Gravity Boots
^ Power of Wolf
Ring of Vlad < Gravity Boots
Eye of Vlad < Gravity Boots
Complexity: 10
Playthrough information
So... I've been all through both castles, and I have no silver ring or item with it's description text.
I have 196.8% map coverage, which includes all of the relic locations I can reach.  The only areas remaining are holy glasses (I have the Gold Ring description on accessory item Diamond, Silver Ring is missing) location in the regular castle and the Shaft/Dracula area in inverted castle.
I'm still missing Silver Ring (or equivalent with another name - should have been at Spike Breaker as per spoiler), Skill of Wolf (should have been at Soul of Bat as per spoiler), Cube of Zoe (should have been at Merman Statue), Ring of Vlad (should have been at Faerie Card), and Heart of Vlad (should theoretically still be at the holy glasses plot event).
It seems to me like some relics just didn't spawn.

I checked the seed and Silver Ring was exactly where the seed says it is. Are you sure you randomized the original bin and not one that had already been randomized?

That's probably what happened.  I'll try another spin on the seed in a couple of hours.

Closing because this sounds like a classic case of a re-randomized bin. Feel free to open a new ticket if you experience similar issues with a verified vanilla bin.

I'm trying a run off a verified vanilla bin, and none of the item locations or drops seem different - just that some of them are there now.
Is this the behavior we expect from a double randomized seed?
If needed, I can send you the faulty bin file.
Sent from my iPhone

On Apr 16, 2021, at 2:50 PM, 3snowp7im @.***> wrote:

Closing because this sounds like a classic case of a re-randomized bin. Feel free to open a new ticket if you experience similar issues with a verified vanilla bin.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

This is expected, you should use a vanilla non-randomized bin to generate seeds.


Can create a collection with a name length of 0

Related to https://github.com/zooniverse/Panoptes-Front-End/issues/832
Given the only way we offer to reference collection is by name, seems to make sense to require a name. I can enforce it on the front-end, but would be great if the API threw an error too.

I think the front end should just show the subject set id if there's not name. I can think of automated processes where it may not make sense to want to worry about naming a subject set.

@chrissnyder did you mean display_name?
Collection display_names are uniq for owners so there will only be 1 blank collection display_name per owner. A this is used for filtering i think we should enforce a display_name on the collection.

Yes, I mean display_name. I've enforced it in the front-end, because the only way users can add subjects to a collection from a project is by filtering by display_name. Ed's point about automated routines is well taken, so I don't know where that leaves us from an API perspective.

Yeah I was actually thinking this was about Subject Sets, we should definitely enforce something for collections.


Corrected key formatting of AuctionHouseInformation

Hello @macemoth. Will this be merged? Would be nice to know so we can update our repository.. Thanks!


Dentistry Header revamp

Can you please enhance the dentistry site header?

The text next to the logo should be font-weight: normal, should have 32px (2rem) distance from the logo and should be standard blue color (same as the logo).
The text above the phone number should be smaller, should be standard blue color and should be positioned on top of the phone number (4px from the phone number).
The phone number should be in standard blue color.
The buttons should be 24px(1.5rem) from the phone number and the text size should be a bit smaller.

Not a blocker
@bosschaert @sdmcraft

Page : https://main--sunstar-foundation--sunstar-foundation.hlx.live/dentistry


docs(toh-6): Upgraded http tutorial to new router

Builds on top of #1735, which upgrades the routing tutorial

@brandonroberts Shouldn't there be no slashes at the beginning of the router link?

There is a broken test. Please check :)

@NejcZdovc no. No leading slashes is only for the route configuration. Leading slashes in the routerLink or navigation means the routerLink is absolute. If you don't lead with a slash, it means you are navigating relative to where you are.

@brandonroberts Sorry, you are right I was too fast :)

This needs rebase.

Rebased

Issues fixed

merged!


Remove option to plot with full precision trajectory

In this pull request, I have removed the option to render the trajectory with the full precision file. After testing, I saw that plotting with either the full precision file or the compressed one does not yield significant differences in the visualization quality.
The full precision file contains velocity, coordinates, and forces data, so to do more in depth analysis is better to use this one. In this file everything is saved with full precision.
The compressed file contains only the coordinates and saves them with only 3 decimal places by default. The size of it is much smaller (around 200 times smaller).
I have chosen to use only the xtc format to render the trajectory. While for the computation of the RMSF uses the full precision file to have a more accurate measure.
Finally, I have made adjustments to the mdp files. I was saving every timestep of the simulation, resulting in a unnecessarily large xtc file. Now I am saving coordinates every 1 ps. I also chose to only save the protein coordinates and discard the water molecules positions. These changes make the  resulting file smaller.

LGTM!
Just a question: How does the compressed file is so much smaller than the regular trajectory? If we have a bunch of parameters N, shouldn't the file be smaller by a factor of 3/N ?


Tech Debt - Migrate from JS to TS

Working with Javascript is a bit tricky and I think Typescript is much safer. Refer to this and migrate this repo to Typescript.

@thsaravana Once this is done, we can directly merge this to main since there is no change to README.md. This will ensure that other contributors can raise PR against the TS version and not the current JS version.


[FLINK-24780][table-planner] Port time/date/timestamp casts to new structure

What is the purpose of the change
Implement the time/date/timestamp related casts using the CastRules structure
and remove the relevant code from ScalarOperatorGens.
Verifying this change
This change added more tests in CastRulesTest.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): yes
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@slinkydeveloper wanna take another look?

Just one question, what about TIME to TIME and DATE to DATE? No trimming is happening there among precisions?

The fractional seconds for TIME are broken, that's why we didn't have any rule for this, and instead it falls to the identity rule. There is already: https://issues.apache.org/jira/browse/FLINK-17224 and the relevant tests in CastFunctionITCase are marked, to be fixed when the issue is addressed. So it will be done at a later stage.

@twalthr Can you please check again?


NotebookKernel: set outputs on cancel

1) NotebookKernel
       set outputs on cancel:
     TypeError: call.getFileName is not a function
      at getErrMessage (assert.js:279:25)
      at innerOk (assert.js:370:17)
      at Function.ok (assert.js:390:3)
      at Context.<anonymous> (file:///Users/runner/work/vscode/vscode/out/vs/workbench/test/browser/api/extHostNotebookKernel.test.js:202:20)

https://github.com/microsoft/vscode/runs/2801405433?check_suite_focus=true#step:10:8470

https://github.com/microsoft/vscode/issues/126054


Curious code in math.janet

I noticed this line, this line, and these lines in math.janet:
  (def one (+ (- n n) 1))

  (def zero (- n n))

  (var d (- n 1))
  (def one (- n d))

Are these special optimization tricks @primo-ppcg?

Yes, these eliminate the need for polymorphic comparators, because one and n are of the same type.

Thanks for the explanation!

I suppose dynamic coercion might also be something of a lexical gap.
(def one (coerce 1 (type n)))

The intent would be a lot more clear.


IntervalTree error when debugging nRF-52840 using elf built with GCC

PyOCD: 0.21.0
Mbed OS: 5.13.1
OS: MacOS 10.14.5
Compiler: GCC (works fine on AC6)
When debugging blinky, the following error occurs:
> ./pyocd gdbserver --target nrf52840 --elf "/Users/thegecko/Mbed Programs/mbed-os-example-blinky/BUILD/NRF52840_DK/GCC_ARM/mbed-os-example-blinky.elf"

0002303:CRITICAL:__main__:IntervalTree: Null Interval objects not allowed in IntervalTree: Interval(85192, 85192, )
Traceback (most recent call last):
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/__main__.py", line 338, in run
    self._COMMANDS[self._args.cmd](self)
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/__main__.py", line 569, in do_gdbserver
    session.board.target.elf = self._args.elf
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/core/coresight_target.py", line 91, in elf
    self.cores[0].set_target_context(FlashReaderContext(self.cores[0].get_target_context(), self._elf))
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/debug/elf/flash_reader.py", line 31, in __init__
    self._build_regions()
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/debug/elf/flash_reader.py", line 39, in _build_regions
    self._tree.addi(start, start + length, sect)
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/intervaltree/intervaltree.py", line 343, in addi
    return self.add(Interval(begin, end, data))
  File "/Users/thegecko/mbed-studio-tools/python/lib/python2.7/site-packages/intervaltree/intervaltree.py", line 326, in add
    " {0}".format(interval)
ValueError: IntervalTree: Null Interval objects not allowed in IntervalTree: Interval(85192, 85192, )

When the elf file isn't specified, debugging works fine.

Perhaps a guard could be added to ignore elf loading errors so that debugging can continue albeit without the elf context?

The guard is a good idea. Of course, it should also not try to insert null intervals into the interval tree! 😅


[Feature] Polaroid Like Photo Carousel

Description
It animates over a stack like structure
Screenshots
https://github.com/Rakesh9100/Beautiify/assets/142514166/285682a7-df64-459c-96fd-0b57c4aec3ac
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

Proceed @AbhineshJha


Better front screen layout on mobile

The main title of the page is not currently visible when I open up the app - only "with Glance" is visible. The button layout is also not responsive to this size.

Try now, I've updated stable with the actual mobile fixes since they weren't yet merged when the blog was sent out. You may need to purge page cache then reload if things don't look different.


string>255 in length with fast_executemany=True doesn't provide appropriate exception message

Environment

Python: 3.9.1
pyodbc: 4.0.30
OS: Windows 64-bit
DB: SQL Server
driver: ODBC Driver 17 for SQL Server

Issue
I would expect a pyodbc.ProgrammingError of "...Invalid object name..." to always be raised if a table doesn't exist. Instead for string values>255 in length, a pyodbc.ProgrammingError of "...String data, right truncation..." is raised if fast_executemany=True.
The correct exception message is provided if fase_executemany=False or cursor.setinputsize is utilized.
import pyodbc

connection = pyodbc.connect(
    driver='ODBC Driver 17 for SQL Server', server='localhost', database='master',
    autocommit=False, trusted_connection='yes'
)
cursor = connection.cursor()

statement = """
INSERT INTO
##NonExistantTable (
    [ColumnA]
) VALUES (
    ?
)
"""

# expected behavior
cursor.fast_executemany = True
sz = 255
args = [['a'*sz]]
try:
    cursor.executemany(statement, args)
except pyodbc.ProgrammingError as err:
    # True
    print('Invalid object name' in str(err))

# unexpected behavior
cursor.fast_executemany = True
sz = 256
args = [['a'*256]]
try:
    cursor.executemany(statement, args)
except pyodbc.ProgrammingError as err:
    # False, err = ProgrammingError('String data, right truncation: length 512 buffer 510', 'HY000')
    print('Invalid object name' in str(err))

# work-around: fast_executemany=False
cursor.fast_executemany = False
sz = 256
args = [['a'*sz]]
try:
    cursor.executemany(statement, args)
except pyodbc.ProgrammingError as err:
    # True
    print('Invalid object name' in str(err))

# work-around: setinputsize
cursor.fast_executemany = True
sz = 256
args = [['a'*sz]]
cursor.setinputsizes([(pyodbc.SQL_VARCHAR,sz*2,0)])
try:
    cursor.executemany(statement, args)
except pyodbc.ProgrammingError as err:
    # True
    print('Invalid object name' in str(err))

This is because fast_executemany attempts to discover the parameter layout of the query before executing it. The SQLDescribeParam fails (it can fail for other reasons than an invalid query) so it defaults to a varchar(255), and then gives the truncation error when it encounters a column longer than that. This is before the query is executed.
Anyway you should use fast_executemany only when your existing code is already working and you need to improve the performance, as it has some other limitations.

Closing this as the related issue has been closed.
https://github.com/jwcook23/mssql_dataframe/issues/1


[Security][PIP] [Github] Setup  dependabot in the repo

Confirm this is a feature request for the Python library and not the underlying OpenAI API.

[X] This is a feature request for the Python library

Describe the feature or improvement you're requesting
Setup Dependentbot in the repo, to have a daily scan for possible outdated dependencies, which represents a vulnerability risk.
Assignee: @omonimus1
PR presented:
Additional context
No response

As mentioned elsewhere, we use a separate system to perform this. We'll consider doing this more publicly in the future, but I don't expect it to happen soon.


TPU training support

Does this codebase currently support training on a TPU? If so, how would I train on a TPU?

Hi @hsezhiyan,
TPU training is currently not supported. If you implement it, please send us a pull request.

Hi @hsezhiyan,
To close this bug:
(1) This project is much more likely to benefit from simpler changes than switching to TPU if you want to speed up training. For instance, running more actors on the same machine than we did, or running actors on many machines in a distributed fashion is likely to provide good training speedups.
(2) Fully harnessing Cloud TPUs for RL training is multiple levels more challenging than (1). See https://github.com/google-research/seed_rl for a distributed RL framework that will soon run on Cloud TPUs.


[BUG] : Home page logo is not aligned

Describe the bug
I have identified a bug in the "tourism-website" repository related to the positioning of the logo image on the home page. Currently, the "Adventure" logo is not correctly aligned with the vertical center of the header.
Screenshots

Thank you @aulth  ❤


Add ByteArray content type

Would allow for including a variety of data, like upoloading images:
var image = new ByteArrayContent(File.ReadAllBytes(filePath));

var ext = Path.GetExtension(filePath);
var contentType = "image/";
if (ext.ToLower().Contains("png"))
{
    contentType += "png";
}
else if (ext.ToLower().Contains("jpg"))
{
    contentType += "jpg";
}
image.Headers.Add("Content-Type", contentType);

maybe there is already a way to do this?

As we discussed off-screen, this will involve adding a new Create Body component that can read files from disk and convert them to byte arrays. Sounds like a great feature for the next release

@fraguada I pushed a new component to the develop branch. It allows you to read a file from disk and create a request body with byte array contents. I managed to successfully push a PNG to a public S3 bucket. Check it out, let me know if this works for you

I also added components for saving binary and text files. So I've actually been able to download that image back

Done in #9


Encryption Broken with ChromeOS Update

Please describe your issue:
Once again with new ChromeOS updates - this time Version 61.0.3163.120 (Official Build) (64-bit) - my encrypted chroots are failing to start. I run all chroots off my SD card (128 GB), with /mnt/stateful_partition/crouton/ symlinked to a directory there.
Running either of the following for trusty or kali:
$(CROUTON)/bin/startxfce4 -n trusty
$(CROUTON)/bin/enter-chroot -n trusty
Results in (ellipsis added):
mount: mount(2) failed: /run/crouton/media/removable/...../chroots/trusty: No such file or directory
Failed to mount trusty.
Updating chroot does not resolve this, nor does installing a fresh chroot.
Apologies for essentially reopening #3262 - but I didn't see an open issue relating to this, and that one has already been marked resolved.
Output of sudo edit-chroot -all:
$ sudo sh /media/removable/..../bin/edit-chroot -all
name: kali
encrypted: yes, locked
Unmounting /media/removable/..../chroots/kali...
name: trusty
encrypted: yes, locked
Unmounting /media/removable/..../chroots/trusty...

While I do not have an identical problem, the cause of this problem may be similar. I am running Debian "buster". In my case, the encrypted chroot mounts. However, I have another encryptfs file system on an external drive for use within the chroot. When I try to mount that I get the same error message as the OP. This message too started after the update to 61 and continues with 62.
In my case, after trying the "encryptfs-mount-private" command a few times, I did an "sudo encryptfs-recover-private /path/to/encryptfs/dir" and after some trials, it eventually did mount! After that it worked stably until the next time I stopped/started the chroot. Again, it would take a little while and after a few tries it "settled" down and stopped giving the error message.
Bottom line: The error did not seem to be deterministically repeatable! So that would say some sort of delay in starting the "encrypfsd" daemon or its response time.

Perhaps OP could check if the "mount-chroot" command is able to mount his chroot. Something like:
sudo mount-chroot mychroot
This can be followed with:
sudo unmount-chroot mychroot
to unmount the mounted chroot at the end.
If "mount-chroot" works, then one should be able to start crouton after running it.

Unfortunately, mount-chroot results in the same "mount: mount(2) failed:..." error as before

mount: mount(2) failed: /run/crouton/media/removable/drive/chroots/xenial: No such file or directory Failed to mount xenial.
Just here to confirm also the same problem. The problem occurs on multiple different computers.

sudo ecryptfs-mount-private /media/removable/drive/chroots/xenial
results in:
ERROR: Encrypted private directory is not setup properly

@yithump @D0nvt
Is either of you, by any chance, using a directory for storing the files that is already encrypted?
While testing this out, I found that ecryptfs does not like to encrypt directories that have already been encrypted. It generates numerous levels of mysterious messages (on console, in logs) which do not say this but mean this.
As a (only one!) data point, I did a fresh install via crouton of xenial on an SD card and I did not run into this issue after I had diagnosed and fixed the double encryption problem. (Which had me confused for a while...)
Kapil.

I had some encrypted files, but none on trusty if I remember correctly. I finally did a full reinstall on the latest Chrome update though and can confirm encrypted kali-rolling works. Trusty with xfce failed when the http service stopped (the same error I've seen when trying to update trusty before), but I'll try it with some others.


Swap fonts from TT Firs Neue to DM Sans

Closes #2202

note - won't have time to review this today. So could @decentdao/design act as non-technical review on this so its not blocked?


Run local example on GPU

The local example takes hours to predict a simple sequence, because it's not running inference on GPU. How do we make it run on the GPU?

solution:
Change
pipe = pipeline(model=model_to_use, torch_dtype=torch.bfloat16)
to
pipe = pipeline(model=model_to_use, torch_dtype=torch.bfloat16, device=0)


Global Registry - Upgrading workload fails when Backend Storage is PV

Seen on rancher:master
What kind of request is this: Bug
Steps to reproduce:

Login to rancher (HA setup, Global Registry is enabled) as admin.
Global Registry is enabled already with Amazon S3 and Database/Redis - PV internal
Navigate to Global --> Tools --> Global registry
Disable Clair/Notary.
Workloads under Local cluster --> System project should upgrade.

Expected Result:
All the workloads should upgrade and come to Active state
Actual Result:
Harbor Registry related workload is stuck in Unavailable State.
Error seen:

The volume is held by the former pod and is not detached.
Related to https://github.com/goharbor/harbor-helm/issues/224

@gitlawr is there anything we can do? Or how can we workaround or fix it manually?

We need to fix it by updating the chart

I met the same issue when using the EBS storage class.

a workaround is to scale the workload to 0, wait all pods get deleted, then scale up back to the previous value.

The bug fix is validated on Rancher: mater using the updated system-chart:dev
We can re-enable the global registry by using the existing PVCs or EBS class, and the data is consistent.


Improve asserting if branches are synced by checking git log X..Y both ways.

Today, when the script runs git rebase and then runs git log X..Y to check if the branches are identical, the script should also check git log Y..X. Because there is a chance that branch X is behind and ahead in commits compared to branch Y.

I implemented this but then realized that we don't want this change to happen.
The use case of this tool is to make sure that the ahead branch commits are put into the behind branch. There are use cases where the ahead branch being behind the behind branch is OK.
Let's say that you use the beta branch for the latest beta deployment while the default branch is develop.
Let's say that the latest beta deployment was 3 weeks ago and you have been developing features in develop ever since the latest beta which means that develop is ahead of beta (and that's OK!). You then find a bug in beta so you add a bug fix commit into the beta branch. beta is now ahead of develop and you want to put that 1 commit into develop. So, you use this tool to do that. You set beta as the ahead branch and develop as the behind branch. This tool copies over that 1 commit and the job is done. It's OK for beta to remain behind from develop! If you want them to be truly identical, you would run this tool twice:
name: Sync release branches with develop

on: [push]

jobs:
  sync-branches:
    name: Sync branches
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: levibostian/action-sync-branches@v1
        with:
          behind: develop
          ahead: beta
          githubToken: ${{ secrets.BOT_PUSH_TOKEN }}
      - uses: levibostian/action-sync-branches@v1
        with:
          behind: beta
          ahead: develop
          githubToken: ${{ secrets.BOT_PUSH_TOKEN }}


Modified README.md file

Issue Resolved

Issue #363

Feature Description
1) Added animated line separators
Added animated line separators in between sections and also add the GSSoC 2024 Extended & Hacktoberfest accepted image for Contributors to know that this repository is officially accepted for the programs.

2) Replaced the Contact section  with a Team section

Before

After

3) Modified the Contributors mention section:

Before

After

Reference Video
https://github.com/user-attachments/assets/18439e01-7973-4ced-9568-e89a9933cdd7

Please review the PR and assign it to me with the necessary labels.

@rajdeepchakraborty-rc  okay looks good 👍

@rajdeepchakraborty-rc okay looks good 👍

Thanks for reviewing the PR.

@Luson045 Will you close the issue #363 since the PR has been merged?


Update Windows library versions

Updates Boehm GC, PCRE2, zlib, libxml2, and LLVM to their most recent versions.
OpenSSL is skipped, since it appears to be unsupported (#14168).

Oh nice, so LLVM 18.1 is released 🎉
I guess we can start dropping libllvm_ext then 😏


How to setup this website?

Hello. How to setup this website?  Which script I should run then visit this website through 'losthost:5000'?

Do you mean a custom flask app? Or one of the example apps flask contains?
Either way, the issue tracker is not the right place for support questions; oleasey use IRC or Stack Overflow instead.

@ThiefMaster  Can you tell me the url about flask's issue in stack Overflow?

@ThiefMaster  Can you tell me the url about flask's issue in stack Overflow?

Tag your question with "flask". Be sure to include a Minimal, Complete, and Verifiable Example when asking a question.

Tag your question with "flask". Be sure to include a Minimal, Complete, and Verifiable Example when asking a question.

@davidism thank you very much!


Add new string methods

PR Checklist
Please check if your PR fulfills the following requirements:

[X] The commit message follows our guidelines: https://github.com/sinuoslabs/support/blob/main/CONTRIBUTING.md
[X] Tests for the changes have been added (for bug fixes / features)
[X] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[X] No

Other information

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


Add support for RegressionTest as a more comprehensive extension of ExtractionTest

This adds a more comprehensive extraction test, aka RegressionTest, to emissary.
See RegressionTest javadoc for more in-depth instructions, but to use with an existing ExtractionTest child, just extend RegressionTest instead, prepare the files in the format described (INITIAL_FORM.FINAL_FORM.OPTIONAL_COMMENT.dat) and remove existing XML files. Then override the generateAnswers() method to return true, and run the test class. This will generate new XML files in the correct location. Once you are happy with the XML files, just remove the generateAnswers() override and you're all set.

Current revision now defaults to not serialising the dat file into the answer file, and being slightly clearer about what is open for overriding.

Looking through this. I want to try and use RegressionTest before giving approval.

Looking through this. I want to try and use RegressionTest before giving approval.

Sure - it was designed against one specific case so also interested to see how you find using it with something else.

Newest commit now works on my environment!

Github claims there are conflicts but I don't see them when I test locally. I've verified that I have all 9 commits.

Rebased against latest master.


Move the org readme to the profile folder for public viewing.

Signed-off-by: Steve Lasker<EMAIL_ADDRESS>

Closing as @yogeshbdeshpande beat me to it :)