Confusing error message from json formatter

$ cucumber -t @step_matcher -f json_pretty
Feature file being parsed is https://github.com/flashquartermaster/Cuke4AS3/blob/master/Cuke4AS3/test/features/cuke4as3/step-matcher.feature
only generation of JSON objects or arrays allowed (JSON::GeneratorError)
/Library/Ruby/Gems/1.8/gems/json-1.6.0/lib/json/common.rb:278:in 'generate'
/Library/Ruby/Gems/1.8/gems/json-1.6.0/lib/json/common.rb:278:in 'pretty_generate'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/formatter/json_pretty.rb:8:in 'after_features'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/ast/tree_walker.rb:173:in '__send__'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/ast/tree_walker.rb:173:in 'send_to_all'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/ast/tree_walker.rb:171:in 'each'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/ast/tree_walker.rb:171:in 'send_to_all'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/ast/tree_walker.rb:164:in 'broadcast'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/ast/tree_walker.rb:13:in 'visit_features'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/runtime.rb:45:in 'run!'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/cli/main.rb:43:in 'execute!'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/../lib/cucumber/cli/main.rb:20:in 'execute'
/Library/Ruby/Gems/1.8/gems/cucumber-1.0.5/bin/cucumber:14
/usr/bin/cucumber:19:in 'load'
/usr/bin/cucumber:19

Do you get the same error with the latest versions of cucumber (1.1.3) ?

Yes
only generation of JSON objects or arrays allowed (JSON::GeneratorError)
/Library/Ruby/Gems/1.8/gems/json-1.6.0/lib/json/common.rb:278:in `generate'
/Library/Ruby/Gems/1.8/gems/json-1.6.0/lib/json/common.rb:278:in `pretty_generate'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/formatter/json_pretty.rb:8:in `after_features'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/ast/tree_walker.rb:173:in `__send__'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/ast/tree_walker.rb:173:in `send_to_all'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/ast/tree_walker.rb:171:in `each'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/ast/tree_walker.rb:171:in `send_to_all'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/ast/tree_walker.rb:164:in `broadcast'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/ast/tree_walker.rb:13:in `visit_features'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/runtime.rb:46:in `run!'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/cli/main.rb:43:in `execute!'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/../lib/cucumber/cli/main.rb:20:in `execute'
/Library/Ruby/Gems/1.8/gems/cucumber-1.1.3/bin/cucumber:14
/usr/bin/cucumber:19:in `load'
/usr/bin/cucumber:19


Adding troubleshooting information about Subresource Integrity digests.

Adding this section to the troubleshooting documentation:
Subresource integrity checks fail
Subresource Integrity digests are added to the build output files. For a particular scenario, these checks may fail when deployed. The files are built using LF characters, but if your deployment uses a Git repository for deployment (like Azure web sites) and the Git repository is set up to translate LF characters into CR/LF characters, then the checked out files will be different and the digests will be invalid.
To fix this, just add a .gitattributes file to your deployment repository that will ensure the build files are not modified when checked out:
*.css text eol=lf
*.js text eol=lf

Can we generate this file by default? Like we generate .gitignore.

The .gitattributes file is for the deployment repository.  Most folks using Git to deploy like this would create a separate repository for the output build files.

Sounds good, thanks!


Add TranslatedDrawTarget

…traits
Hi! Thank you for helping out with Embedded Graphics development! Please:

[ ] Check that you've added passing tests and documentation
[ ] Add a simulator example(s) where applicable
[ ] Add a CHANGELOG.md entry in the Unreleased section under the appropriate heading (Added, Fixed, etc) and appropriate crate (embedded-graphics, simulator, tinytga, tinybmp) if your changes affect the public API
[ ] Run rustfmt on the project
[ ] Run ./build.sh (Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR.

PR description
I've started to experiment with the TranslatedDrawTarget (see #355). The primitives-fill.rs example demonstrates how it can be used. To help with the implementation I've also implemented TranslatedPixelIterator. Both objects can be created using the translate method provided by extension traits for DrawTarget and Iterator<Item = Pixel<C>>.
One feature I'm not sure about is drawable.draw_at(offset, &mut target), which is a shorthand for drawable.draw(&mut target.translate(offset)). This could be used to replace Image::offset and Polyline::translate, but maybe it's better to keep the offset in the drawable itself.
The PR still needs some polish, but I would appreciate some initial feedback.

 I had it in my head that it could be a different size from the parent DrawTarget instead of just an offset of it.
In terms of API, what about flipping it on its head somewhat (excuse the names):
// Get a display instance that impls DrawTarget
let display = Disp::new();

// Sub draw target with an offset of (10, 20) and size (30, 40)
let sub = display.sub_draw_target(Rectangle::new(Point::new(10, 20), Size::new(30, 40)));

let circle = Circle::new(Point::zero(), 10).into_styled(...);

// Draw at display origin
circle.draw(&mut display).unwrap();

// Draw at subtarget origin
circle.draw(&mut sub).unwrap();

This would allow the removal of DrawableExt and keep the same API for DrawTarget and SubDrawTarget.
Here's a pile of questions:
Should we mirror (or implement) the Transform API for SubDrawTarget and use .translate() and .translate_mut()? This would allow sub draw targets to be moved around.
Do we want to keep the shorthand top level display.translate(), or keep the API simpler with a single method to get a sized sub draw target. translate as a name is an odd word when called on a top level display IMO - it feels like it should move the simulator window/physical display around which doesn't make sense for obvious reasons.
Can sub draw targets be larger than their parent? IMO this should be possible. If not, should we convey creation failure with a Result?
Can the subtarget be resized? If so, do we want to make a variant that can't which is just an offset of the parent DrawTarget? I'm not sure this really gives any benefit and just complicates the API so I'd say we just have one that can be resized for now, IMO.
We also might want to allow configuration of subtarget overdraw - some applications may want clipping, others not.
It might help to describe the use cases you have in mind for this API so we can align on a final goal for it. The 2 that come to mind for me are:

Supporting that "footer" on the ST7789 that was discussed a while ago
Features to support layout/windowing engines for something like an oscilloscope interface or embedded-layout.

By the way I like the recursive nature of this feature - I think that could be really useful for more complex layouts/UI.

In general, I don't think resize/extend is a good idea. Even though the TDT is not a clipping area, if there will ever be a clipping implementation, the API will probably be similar to not confuse the users.
The problem is, if something gets a mutable reference, if they can resize it or otherwise modify, they can essentially break out of the clipping rectangle. Even worse (granted, it's subjective), they can in principle assign a different area to the reference and thus modify the area the caller works with. If there can ever exist a situation where the callee is not completely trusted, it can cause weird issues IMO. Maybe there are ways to prevent these kinds of code to compile, though, I'm not fluent enough in Rust to say.
Speaking of confusion, although it's not mean to compile, @jamwaffles's code can't compile because it violates Rust's aliasing rules: as long as the sub drawtarget lives, the main draw target can't be referenced. Assuming, of course, that the sub target holds a mutable reference to the parent draw target.
Just my .02€, feel free to disregard

Didn't we decide to call it SubDrawTarget? I had it in my head that it could be a different size from the parent DrawTarget instead of just an offset of it.

Because this is only implements a part of the functionality of SubDrawTarget I decided to call it TranslatedDrawTarget instead. IMO it's better to keep translation and clipping separate, because there are use case where you only need one of the two. (see https://github.com/jamwaffles/embedded-graphics/issues/355#issuecomment-639554399)

In terms of API, what about flipping it on its head somewhat (excuse the names): [... code ...]

As @bugadani mentioned your code example wouldn't work, but when you reorder the instructions it will already work this way (without the clipping):
let display = Disp::new();

let circle = Circle::new(Point::zero(), 10).into_styled(...);
circle.draw(&mut display).unwrap();

let mut sub = display.translate(Point::new(10, 20));
circle.draw(&mut sub).unwrap();

This is used in the primitives-fill.rs example.

This would allow the removal of DrawableExt and keep the same API for DrawTarget and SubDrawTarget.

DrawableExt wasn't intended to be a replacement for the code in your example, but an alternative implementation of the offset function in Image and Polyline. But I think I'll remove it from this PR to keep it focused.

Should we mirror (or implement) the Transform API for SubDrawTarget and use .translate() and .translate_mut()? This would allow sub draw targets to be moved around.

I consider TranslatedDrawTarget to be a short lived object that gets created while something is drawn and which isn't preserved across multiple draw calls. Because of this I don't think it's necessary to mutate it.

Do we want to keep the shorthand top level display.translate(), or keep the API simpler with a single method to get a sized sub draw target. translate as a name is an odd word when called on a top level display IMO - it feels like it should move the simulator window/physical display around which doesn't make sense for obvious reasons.

I would like to keep the functionality, but I'm open for suggestions on better names.

Can sub draw targets be larger than their parent? IMO this should be possible. If not, should we convey creation failure with a Result?
Can the subtarget be resized? If so, do we want to make a variant that can't which is just an offset of the parent DrawTarget? I'm not sure this really gives any benefit and just complicates the API so I'd say we just have one that can be resized for now, IMO.

Interesting questions, but if this PR only adds translation they aren't not relevant here. Can you move this question to #355?

We also might want to allow configuration of subtarget overdraw - some applications may want clipping, others not.

This would be solved by splitting SubDrawTarget into TranslatedDrawTarget and ClippingDrawTarget.

Supporting that "footer" on the ST7789 that was discussed a while ago

I didn't notice this discussion, can you provide a link to it?

Thanks both for educating me. I should've dug a bit deeper into my suggested code.
@rfuest All those points SGTM so I won't respond to each individually other than:

I didn't notice this discussion, can you provide a link to it?

This happened in Matrix a long time ago IIRC, I don't think I can find a link back to it unfortunately.

Thanks both for educating me. I should've dug a bit deeper into my suggested code.
@rfuest All those points SGTM so I won't respond to each individually other than:

I didn't notice this discussion, can you provide a link to it?

This happened in Matrix a long time ago IIRC, I don't think I can find a link back to it unfortunately.

One feature I'm not sure about is drawable.draw_at(offset, &mut target)

I'd prefer to leave this out, at least for now. If there's a pressing need for it in the future, we can always add it back in.

translate is a common name in canvas APIs: https://www.cairographics.org/manual/cairo-Transformations.html#cairo-translate and https://www.cairographics.org/manual/cairo-Transformations.html#cairo-translate
But because we return an object instead of mutating a context we could use a different name. I would be OK with translated.

But because we return an object instead of mutating a context we could use a different name. I would be OK with translated.

I think the Rust API guidelines say that mutating versions of a certain API should be named *_mut. Just based on this I think translate is fine

translated it is then :)

I've renamed translate to translated and removed the extension trait for Drawables.

I've made the draw_target module public, to have a place to put the new types into. In #330 we moved DrawTarget to the root of the crate, but IMO it would now be better to remove it from the crate root and only export it in the draw_target module, because it breaks the doc links otherwise. And I think that having the trait exported in one place and the prelude should be enough. This is a breaking change, but it won't affect users that have imported DrawTarget via the prelude.

That's fine. It is breaking but it's not a difficult fix to make. Can you add a breaking changelog entry just to help anybody that might get stuck.

Can you add a breaking changelog entry just to help anybody that might get stuck.

Sure, I'll include it when I write the changelog entries for the finished PR.

I've pushed some more changes to this PR, like adding a first version of CroppedDrawTarget.
Having DrawTarget::size() didn't make sense anymore, because the origin of the draw target's bounding box might not be at (0, 0). Instead DrawTargets are now required to implement Dimensions.
OriginDimensions was added to make implementing Dimensions a little easier and to provide a type level way to determine if bounding_box will return a rectangle with top_left == Point::zero(), which could be useful as a replacement for ImageDimensions. Is the name for this trait OK or should we change it?

Maybe my problem comes from my inexperience with drawing apis, but for me, this feels a bit weird. I was always under the assumption that cropping implies clipping. I'm also not sure why a cropped draw target has a size. If it doesn't do clipping, shouldn't it's size be infinite? (But in that case, what would it's position represent?)

If a drawing operation uses the bounding_box returned by the draw target for some drawing operations, CroppedDrawTarget can be used to pass a smaller portion of the base target to that drawing operation. It doesn't imply clipping because there are use cases that benefit from being able to draw outside the actual target. One example would be to implement drawing of shadows similar to box-shadow in CSS, where the shadow is drawn outside the element.

If it doesn't do clipping, shouldn't it's size be infinite? (But in that case, what would it's position represent?)

The bounding_box implementation was broken and should always return top_left == Point::zero() which might have caused some confusion.

... which could be useful as a replacement for ImageDimensions

Very nice. Will you remove ImageDimensions in this PR? Either way, it would close #367 which is a nice bonus.

Is the name for this trait OK or should we change it?

I can't think of a better one, it's descriptive, and most people will include it through the prelude or not at all, so will rarely see the name. I think OriginDimensions is fine :)

Will you remove ImageDimensions in this PR?

No, I will include that change in the SubImage PR.

I think this should be ready for review now. The implementation of Clipped::fill_contiguous still contains a TODO, but I would prefer to fix that in the SubImage PR.

My mental model moves the origin of each sub-target to that target's top-left corner, whilst I think yours might leave it at the top level "true" origin. Is that right?

Both Cropped and Translated shift the origin of drawing operations. But they differ in the rectangle returned by bounding_box. While Cropped returns a new bounding box with the origin at (0, 0), Translated returns a shifted version of the original bounding box.
Cropped doesn't shift the origin and only reports a different bounding_box.

I think you mentioned using Translated<Cropped> or Translated<Clipped> if "windowing" behavior is required.

If the drawing operation can be trusted to not draw outside of the bounding_box Cropped can be used on its own. Otherwise Clipped<Translated> or Translated<Clipped> can be used.

...although an example of combining a couple of the different targets to e.g. produce a window with shifted origin would be useful to add to the DrawTargetExt documentation.

Yes that's a good idea. I think a simulator example should also be added. But can we add this in another PR? I can create an issue to track this.

Ok, thanks for explaining how this works. A compound example would've helped un-confuse me for sure ;) but yeah let's put that in a different PR. Please open an issue to track.

Please open an issue to track.

Done.

Awesome, thanks. I've been reading through the docs a bit and thought parent draw target might be a better name than base draw target. Thoughts?

Thoughts?

Good idea! I've changed the docs and also renamed the target field in the sub draw targets into parent to make the name more descriptive.


Add tests

The extension consists of two parts, the vs code part (simple logic) and the webview app (most logic)

Test communication: vs code <-> app
Test app logic. Are the correct elements shown for a given task (probably use Jest, maybe RTL/enzyme in addition)

tests partly working
Niivue not yet recognized in tests


run-against-trinpod.sh script docs outdated

The run-against-trinpod.sh script assumes that a /tls/server.{key|cert} certificate is available for running a webhook server, but there is no mention of this in the readme. The script seems to give a lot of false failure reports.

I created https://solid-test-panel.trinpod.us/home/ but so far failed to give https://solid-crud-tests-example-1.solidcommunity.net/profile/card#me access to it. Will keep trying.


helm lint and list ignore enabled condition

helmfile list shows enabled while chart is disabled, same issue for helm lint, helm lint would try to lint releases with values for environments that is not enabled for.
helmfile version
helmfile version v0.137.0

helmfile -f helmfile.yaml -e staging list
NAME                        	NAMESPACE   	ENABLED	LABELS
kube-prometheus-stack       	xxxx  	true   	chart:kube-prometheus-stack

bases:
- ../envs/environments.yaml
releases:
- name: kube-prometheus-stack
  labels:
    chart: kube-prometheus-stack
  chart: ../charts/kube-prometheus-stack
  condition: prometheus.enabled

envs
prometheus:
  enabled: false

I have the same issue

The mentioned PR does not handle list command. By the way the column Enabled in list command does not correspond to condition field, but installed field. I propose you to open an issue to use the right word for the output of this command.
https://github.com/roboll/helmfile/blob/2618cfb38b20d867a977f2b295059893d23e507a/pkg/app/app.go#L514


[Event Request] Codeunit 90

We need the publisher analog to the one that exist in the Codeunit 80:
Existing one in the Codeunit 80:
OnFillInvoicePostingBufferOnBeforeSetAccount(SalesHeader: Record "Sales Header"; SalesLine: Record "Sales Line"; var SalesAccount: Code[20])

Desired publisher in the Codeunit 90:
OnFillInvoicePostingBufferOnBeforeSetAccount(PurchaseHeader: Record "Purchase Header"; PurchaseLine: Record "Purchase Line"; var PurchAccount: Code[20])

right before the line:
InvoicePostBuffer.SetAccount(PurchAccount, TotalVAT, TotalVATACY, TotalAmount, TotalAmountACY);

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


updated README

The readme will be fixed by our code generator fix in https://github.com/openai/openai-java/pull/62


how to access connection error

I am using quic directly, not http3. While working on my app I found that there's no way to easily access the error cause when a connection is closed. The only way to get the error is to call conn.AcceptStream(), though some use cases may not need one side of the connection to accept streams. That side would be unable to access the error reason (application error, transport error, etc) to learn why its connection might get closed. I might have missed something, maybe you can give me some pointers?
After some digging I thought it would be great to get these errors as cancel cause on the connection context, which works fine for me. Any thoughts? Only downside I came up with is that cancel causes were introduced in go1.20
My changes: https://github.com/fholzer/quic-go/compare/master...fholzer:quic-go:surface-conn-err
While I am writing this, I realize that it might be nice to do the same for stream errors on stream contexts.

The only way to get the error is to call conn.AcceptStream(), though some use cases may not need one side of the connection to accept streams

That's correct, or OpenStream, or any read / write operation on the stream. This is equivalent to how a net.TCPConn works, you also only get the error when you do something with the connection.
That said, I like your solution :) We already have the context, and since Go 1.20 we can attach an error. I don't see any reason to not do it. Could you send us a PR? We might be able to include it in the v0.37 release, which will probably be released some time next week.
For the stream errors, could you send a separate PR?


Auto-reconnect on PubSub.get_message

What do these changes do?
Fix issue with auto-reconnect in PubSub.get_message.
Are there changes in behavior for the user?
No.
Related issue number
Fixes #1130
Checklist

[x] I think the code is well written
[x] Unit tests for the changes exist  I don't think new tests are necessary
[x] Documentation reflects the changes  No changes in documented behavior
[x] If you provide code modification, please add yourself to CONTRIBUTORS.txt

The format is <Name> <Surname>.
Please keep alphabetical order, the file is sorted by names.

[x] Add a new news fragment into the CHANGES/ folder

name it <issue_id>.<type> (e.g. 588.bugfix)
if you don't have an issue_id change it to the pr id after creating the PR
ensure type is one of the following:

.feature: Signifying a new feature.
.bugfix: Signifying a bug fix.
.doc: Signifying a documentation improvement.
.removal: Signifying a deprecation or removal of public API.
.misc: A ticket has been closed, but it is not of interest to users.

Make sure to use full sentences with correct case and punctuation, for example:
Fix issue with non-ascii contents in doctest text files.

Code coverage is failing, saying coverage decreases slightly in connection.py, but I'm not sure how that's possible since I haven't touched that file.

I wouldn't worry about it; I can never tell where codecov is finding the diffs unless I run coverage on my local machine.


[WIP] [RFC] Make driver user info available

This PR adds the ability to get properties from the underlying user returned from the driver.
This is abstracted under a UserInfo interface to give a consistent method of accessing these properties for each driver:
<?php

$botman->hears('test', function(Botman $botman) {
    $user = $botman->getUser();

    if ($user->getInfo('isAdmin') {
        $botman->reply('Hi, master!');
    } else {
        $botman->reply('Hi there!');
    }
});

If possible, some feedback would be great before I go ahead and implement it on the other drivers. 😄

Codecov Report

Merging #297 into master will decrease coverage by 0.97%.
The diff coverage is 7.69%.

@@             Coverage Diff              @@
##             master     #297      +/-   ##
============================================
- Coverage     84.22%   83.24%   -0.98%
- Complexity      648      655       +7
============================================
  Files            54       55       +1
  Lines          1946     1970      +24
============================================
+ Hits           1639     1640       +1
- Misses          307      330      +23

Impacted Files
Coverage Δ
Complexity Δ

src/Mpociot/BotMan/UserInfo/SlackRTMUserInfo.php
0% <0%> (ø)
5 <5> (?)

src/Mpociot/BotMan/Drivers/SlackRTMDriver.php
50.68% <0%> (-0.71%)
24 <0> (ø)

src/Mpociot/BotMan/User.php
88.23% <50%> (-11.77%)
7 <3> (+2)

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 e01aa5d...0aa943e. Read the comment docs.


refactoring routes and authorization stuff

refactored routes and middleware authorization stuff to make it similar to latest meanjs directory structure. will be making similar changes for angular stuff in public folder. Please let me know if you have concerns or thoughts.

@chaudhryjunaid would you be able to review this?

Yep. I will as soon as I can. Probably, tonight or tomorrow night.


core.umd.js:3462 EXCEPTION: Uncaught (in promise): TransitionRejection(type: 2, message: The transition has been superseded by a different transition, detail: 'app.baz'{})

After clicking to 'buz' link:

I tracked this down to the transition visualizer and "makeCancelablePromise". Should have a fix shortly.

Thanks! Fixed now!


Revert "update package dependencies"

Reverts greenelab/hetmech-frontend#147
Attempt to fix frontend.

This passed CI. I'm going to merge it to see if it gets a fixed frontend (if CI is set to deploy), since a bunch of folks from Rowan yesterday were interested in using it. Worst case scenario is that we can re-apply #147 if this doesn't fix things.

Wrong button on that close 😂

Is it working okay on Firefox now? I don't have access to firefox right now.

It doesn't appear to be. I think it may be broken from https://github.com/hetio/frontend-components/pull/45/files

Are you sure this wasn't a caching issue. That PR was tested and it looked normal on my machine in both browsers. Also those screenshots look very much like the javascript file was updated but the CSS file wasn't. I've run into odd caching issues that I believe are github-pages fault that look just like that, and it just requires time to resolve.

Just ran the app locally (without this revert PR) and it looks normal:

I don't see how anything in the previous PR could've caused the errors I see in the broken screenshots. In those screenshots, global.css from het.io is clearly being loaded, but the hetmech specific css is not. The PR only updates external packages.
I'm almost certain this was some type of caching error. However if you're concerned that other people might be using it soon, it's fine to leave the revert in place for now.

It works for me now in the current live version. I'm pretty confident that it wasn't a caching issue. It didn't work on the machines of a few people I also met with during the afternoon yesterday, and they never would have loaded het.io before.
We can re-apply #147 and see if things keep working!

Caching maybe isn't the best word. I've run into issues with github pages somehow serving the new version of a javascript file but the old version of a css file after a recent merge, and it inexplicably continued until I waited a bit and also re-requested it a bunch of times.
Are you okay with reapplying #147 now, or are more people going to use it this weekend. I will be around to debug when/if the issue returns. And again, things were working fine locally, so if this truly is a non-caching error, it seems we can only see it when it actually gets deployed to github pages.

I told folks I would email them when it was back up - I haven't sent it yet.
If you're around to try things out I'm happy for it to happen this weekend, but I also don't mind waiting to next week.
Let me know what you decide, and I'll either send out the emails or wait for a bit. Thanks!

Let me try it right now because I want to find out what is causing this. If I can't find the source of the issue within an hour, I'd say we'll re-revert (re-re-revert?) and send out the email.

Sounds good!

Also here is a related gh issue where people talk about building CRA apps in a non-split manner:
https://github.com/facebook/create-react-app/issues/5306


Improved project documentation

closes https://github.com/NexesJS/NQL/issues/7

Added use cases and projects that are being combined
Expanded examples

Updated the readme strucrute and removed unrelated installation/running sections :)


Pagination not working properly for Project listing page

Describe the bug
Pagination is applied on the project listing page, When a user tries to access the 2nd page of the pagination, available at the bottom then the page is set to My project page. Similar issue is occurring for Halted and Inactive Projects
Please refer screenshot

Clicking on the second page to view projects

Page is reset to My project

To Reproduce
Steps to reproduce the behavior:

Go to CRM
Click on Projects
Scroll down to the bottom of the page
Click on the 2nd number, next page containing the projects should be available

Expected behavior
On clicking on the 2nd number, the next page containing the projects should be available

Closing as issue of pagination has been fiexd


child compiler cache name unknown question

I am getting the following build message with webpack:
⠦ building for production...[hard-source:util] A child compiler (worker) has a
memory cache but its cache name is unknown.
HardSourceWebpackPlugin will be disabled for this child
NB this is essentially the same issue as here:
https://github.com/mzgoddard/hard-source-webpack-plugin/issues/177
with the issue marked as resolved. I installed nswp this morning (20171124)  via:
npm install hard-source-webpack-plugin

and then added hard-source-webpack-plugin  version 0.4.11 to devDependencies section of package.json.
Has anyone experienced this since the fix?
webpack version: 3.10.10
webpack.prod.conf.js:

var path = require('path')
var utils = require('./utils')
var webpack = require('webpack')
var config = require('../config')
var merge = require('webpack-merge')
var baseWebpackConfig = require('./webpack.base.conf')
var CopyWebpackPlugin = require('copy-webpack-plugin')
var HtmlWebpackPlugin = require('html-webpack-plugin')
var ExtractTextPlugin = require('extract-text-webpack-plugin')
var OptimizeCSSPlugin = require('optimize-css-assets-webpack-plugin')
var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');

var env = process.env.NODE_ENV === 'testing'
  ? require('../config/test.env')
  : config.build.env

var webpackConfig = merge(baseWebpackConfig, {
  module: {
    rules: utils.styleLoaders({
      sourceMap: config.build.productionSourceMap,
      extract: true
    })
  },
  devtool: config.build.productionSourceMap ? '#source-map' : false,
  output: {
    path: config.build.assetsRoot,
    filename: utils.assetsPath('js/[name].[chunkhash].js'),
    chunkFilename: utils.assetsPath('js/[id].[chunkhash].js')
  },
  plugins: [
    // http://vuejs.github.io/vue-loader/en/workflow/production.html
    new webpack.DefinePlugin({
      'process.env': env
    }),
    new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false
      },
      sourceMap: true
    }),
    // extract css into its own file
    new ExtractTextPlugin({
      filename: utils.assetsPath('css/[name].[contenthash].css')
    }),
    // Compress extracted CSS. We are using this plugin so that possible
    // duplicated CSS from different components can be deduped.
    new OptimizeCSSPlugin({
      cssProcessorOptions: {
        safe: true
      }
    }),
    // generate dist index.html with correct asset hash for caching.
    // you can customize output by editing /index.html
    // see https://github.com/ampedandwired/html-webpack-plugin
    new HtmlWebpackPlugin({
      filename: process.env.NODE_ENV === 'testing'
        ? 'index.html'
        : config.build.index,
      template: 'index.html',
      inject: true,
      minify: {
        removeComments: true,
        collapseWhitespace: true,
        removeAttributeQuotes: true
        // more options:
        // https://github.com/kangax/html-minifier#options-quick-reference
      },
      // necessary to consistently work with multiple chunks via CommonsChunkPlugin
      chunksSortMode: 'dependency'
    }),
    // split vendor js into its own file
    new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: function (module, count) {
        // any required modules inside node_modules are extracted to vendor
        return (
          module.resource &&
          /\.js$/.test(module.resource) &&
          module.resource.indexOf(
            path.join(__dirname, '../node_modules')
          ) === 0
        )
      }
    }),
    // extract webpack runtime and module manifest to its own file in order to
    // prevent vendor hash from being updated whenever app bundle is updated
    new webpack.optimize.CommonsChunkPlugin({
      name: 'manifest',
      chunks: ['vendor']
    }),
    // copy custom static assets
    new CopyWebpackPlugin([
      {
        from: path.resolve(__dirname, '../static'),
        to: config.build.assetsSubDirectory,
        ignore: ['.*']
      }
    ]),
    // for faster buils (optional) see https://github.com/mzgoddard/hard-source-webpack-plugin
    new HardSourceWebpackPlugin()
  ]
})

if (config.build.productionGzip) {
  var CompressionWebpackPlugin = require('compression-webpack-plugin')

  webpackConfig.plugins.push(
    new CompressionWebpackPlugin({
      asset: '[path].gz[query]',
      algorithm: 'gzip',
      test: new RegExp(
        '\\.(' +
        config.build.productionGzipExtensions.join('|') +
        ')$'
      ),
      threshold: 10240,
      minRatio: 0.8
    })
  )
}

if (config.build.bundleAnalyzerReport) {
  var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
  webpackConfig.plugins.push(new BundleAnalyzerPlugin())
}

module.exports = webpackConfig

@bb78657 The fix was for hard-source. The same file can be built multiple times for different compilers, with those compilers having different settings, making the output module different. hard-source tries to figure out the name of a child compiler so that it uses the right version of a cached module.
The fix improved support for html-webpack-plugin's child compiler. Another plugin or child compiler is likely storing its compiler cache in a way hard-source doesn't yet support or can not be supported.
Looks like your using webpack-loader which may be the problem for hard-source's child ache detection.
Like the error syas, this will just disable hard-source caching for that child compiler. The root compilation and other child compilers will still be cached by hard-source.

0.5.9 is out, giving broader support for child compiler caches in webpack 3, like the one worker-loader uses.


Allow to change mounter option from an existing PV

Describe the feature you'd like to have
Hello this issue is to discuss the feasibility to change the mounter type of an existing PV.
Over time, due to issues with ceph MDS balancer in active / active mode and kernel hangups, we had to change StorageClass's mounter type to fuse (instead of kernel). We now want to revert this change and use mounter type kernel instead.
In the meantime, all provisioned PVs where provisoned using a volumeAttributes.mounter set to fuse and this property cannot be changed with a kubectl patch, resulting in PVs still being mounted using ceph-fuse, despite the StorageClass was recreated with mounter kernel.
Is there a way to change the mounter type of existing PV? By hacking PV's etcd entry?
If not, can you provide a way to do so?
What is the value to the end user? (why is it a priority?)
Change the mounter type of an existing PV. Avoid having to move all data from a PV to another (with the need to stop the application) just to change the mounter type of a volume and regain  better performances (with kernel mounter type).
How will we know we have a good solution? (acceptance criteria)
PVs previously using volumeAttributes.mounter: fuse and being mounted with ceph-fuse would be remounted with kernel after changing the property to volumeAttributes.mounter: kernel.

https://github.com/ceph/ceph-csi/issues/1887

@FredNass makes sense we can add it to the configmap and make it a dynamic one here
@ceph/ceph-csi-maintainers @ceph/ceph-csi-contributors thoughts?

@Madhu-1 Thank you for considering it. If I understand correctly, you have in mind a new ConfigMap setting that would enforce the mounter to use either FUSE or kernel mounting, regardless of the PV's volumeAttributes.mounter attribute value. Is that correct?
Any reason why the mounter was set to the StorageClass initially?
Was it intentional to allow administrators to decide that some PVs should be mounted with FUSE instead of kernel, depending on the type and structure of the data they contain? (Although I doubt many of us are using two different CephFS StorageClasses in Kubernetes clusters, one with mounter: kernel and another with mounter: fuse.)

I think this is a perfect case for #4662

@Madhu-1 Thank you for considering it. If I understand correctly, you have in mind a new ConfigMap setting that would enforce the mounter to use either FUSE or kernel mounting, regardless of the PV's volumeAttributes.mounter attribute value. Is that correct?
Any reason why the mounter was set to the StorageClass initially?

we didn't had any required for it so it was set in the SC.

Was it intentional to allow administrators to decide that some PVs should be mounted with FUSE instead of kernel, depending on the type and structure of the data they contain? (Although I doubt many of us are using two different CephFS StorageClasses in Kubernetes clusters, one with mounter: kernel and another with mounter: fuse.)

i forgot that i recently opened #4662 for this use-case where admin will be able to dynamically change the options for the existing PVC but for this, we need implementation on the cephcsi to store the details in the omap or the image metadata.
@nixpanic @Rakshith-R what your suggestion of storing options, omap or image/subvolume metadata?

@nixpanic @Rakshith-R what your suggestion of storing options, omap or image/subvolume metadata?

image/subvolume metadata is my preference. That way things are kept easily with the storage. Certain RBD features use keys in the RBD-image metadata (like I/O bandwidth throttling rbd-nbd).

Preventing closure during summer.


nixos/forgejo: work around permissions error on postgresql_15

Description of changes
From postgresql_15's release notes:

PostgreSQL 15 also revokes the CREATE permission from all users except
a database owner from the public (or default) schema.

https://www.postgresql.org/about/news/postgresql-15-released-2526/
This directly affects services.postgresql.ensureUsers in NixOS, leading to

permission denied for schema public

postgresql_15 is now the default for stateVersion 23.11/unstable.
So until this is resolved globally, we work around this issue.
Refs:

https://hydra.nixos.org/build/238878803
#216989
#203474
#252071
#255961
#254268

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@ofborg test forgejo


[MS-207] Loading ProjectID & ModuleID dynamic attributes to use in TEI profiles

ProjectID and ModuleID custom attributes down-synced from the DHIS2 back-end instance to this Android app, to be used with Simprints ID at the next stages of this prototype. Their values are displayed in the TEI (beneficiary) profile when available.
See more detailed description in the README.md updated within these changes.
Example of a profile of a TEI enrolled in a program with ChildProgrammeProjectId ProjectID and belonging to an organisation unit that's part of Bo (ModuleID of which is BoModuleId):

This prototype solution is on standby.


Misc apps fixes [2020-05-28]

make_config_name() is a duplicate of CONF_get1_default_config_file(), so drop it.
apps/progs.pl has strange results when it's running in a national locale.  For example, w isn't matched by the regular expression [a-z] in the Swedish locale (which means passwd_main isn't matched, for example).  To avoid that sort of surprise, we set the "C" locale.

Explicitly running in the "C" locale seems like it will be bad for some users, e.g., @beldmit and @InfoHunter and their countrymen.  Are you sure that's the right thing to do, rather than add a NOTE (sic) in the documentation?

Explicit setting locale to "C" is often a way to find out an understandable (or at least googlable) diagnostic output in Russia :)

In my case, not running under the "C" locale was bad. We are, after all, trying to match ASCII characters, so the "C" locale is the best way to ensure [a-z] matches them all.

I've dropped the locale change in apps/progs.pl, couldn't reproduce what went wrong when I tried again.

Approved 5 days ago by Bernd already.

Merged
e306f83c8cfc7ac970d04a36c90634ab8573a594 APPS: Remove make_config_name, use CONF_get1_default_config_file instead


Make installer more robust (platform AKS)

We ran into the issue that "keptn install" failed on AKS as we did not perform "az login" beforehand. We then had corrupt configurations for kubectl and keptn cli resulting in errors on each retry of keptn-install. Our solution was to make a new connection manually via:
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
Note that the errors occured on the client side before reaching the AKS instance.
Maybe a "keptn reset" command or a sanity check before the actual installation is peformed would help already.

Hi!
This is most likely related to https://github.com/keptn/keptn/issues/1871, where we fixed an issue that we executed the version check of the Kubernetes Cluster before we actually made sure that we are connected to the correct cluster.
That being said, I agree that the installation process needs to be simpler and less error-prone. For me it would make perfect sense to skip anything platform specific (e.g., azure, aws, gcloud) and just use the current Kubernetes context.

This issue can be closed due to https://github.com/keptn/keptn/pull/2005, which will be available with Keptn 0.7.0
Technically, the CLI now only differentiates between kubernetes (requires your kube-config to point to the cluster where Keptn should be installed) and OpenShift but not AKS, GKE, etc.


Upgrade to Jest 28

ts-jest, jest-babel, types/jest, jest-puppeteer and expect all need to be compatible with 28 which is a major version

completed in https://github.com/alphagov/paas-admin/pull/2651


New Drive 1 could not connect: String reference not set to an instance of String. Prameter name: s

Technical data
WinSshFS

[ ] stable
[x] prerelease
[ ] custom build
Version: 1.6.0-rc3

Dokan driver

[x] stable
[ ] prerelease
[ ] custom build
Version: Dokany 1.0.3

Enviroment

Windows version: 10 and 7
Architecture: x64
Related software: Windows Explorer

Support

Usage: personal
Your personal priority to solve this issue: high
Support ability: programming C/C++

When i try to mount a SSH share i get the error:
New Drive 1 could not connect: String reference not set to an instance of String. Prameter name: s
in e message box,
the issue appears on windows 7 and windows 10, tried booth in fresh virtual machines.
Cheers
David X.

For me the issue occurred when I tried to mount a drive that I made changes to or added recently. When I saved the configuration and tried again, it worked.


ORC-779: Upgrade commons-cli to 1.4

What changes were proposed in this pull request?
This PR aims to upgrade commons-cli to 1.4
Why are the changes needed?
This will bring the latest bug fixes and improvements.

http://commons.apache.org/proper/commons-cli/release_1_4.html

How was this patch tested?
Pass the CIs.

Thanks @williamhyun  ! Just merged this

+1, LGTM.
Thank you, @williamhyun and @pgaref .

Thank you @pgaref and @dongjoon-hyun !


Superscalar.cpp--possibility of changing portBusy matrix prematurely?

It appears to be possible in superscalar.cpp, if one were to be in the process of generating a multi-uop instruction (such as imul_rcp), that one could update the portBusy matrix after the first uop, then be forced to discard the instruction altogether due to a failure on the second uop.  This is inconsistent with updates to portBusy when dealing with single uop instructions, so not sure if this is intentional or not.  Perhaps unimportant.
relevant function is line 653, generateSuperscalar
portBusy updates on line 762 in the scheduleMop function

@tevador ^

@tevador I think you should move the check if (cycle1 >= 0) before the second scheduleUop

@Crotchfire I've checked it and this case doesn't happen for 1,000,000 random superscalar programs, but it still needs fixing in the code to be sure.

@Crotchfire This is actually not an issue because portBusy is only updated after both cycle1 and cycle2 were found. First 2 calls to scheduleUop are done with commit == false.

If scheduling on line 762 fails, then the program is completed (portsSaturated == true is a terminating condition) and it doesn't matter that portBusy is inconsistent with the final program (it's a local variable that's deallocated when generateSuperscalar returns).
I don't see a problem here.

@tevador He was talking about this loop: https://github.com/tevador/RandomX/blob/master/src/superscalar.cpp#L635
It could fail to allocate the second uOp on some cycle, continue and succeed on the next cycle. But since scheduleUop is called with commit == false there, it's not an issue because portBusy is not updated until both scheduleUop succeed.


Weird rendering of scatterplot, not align with map

Anyone have any idea why the points are not align with the map?

This is the message from the console:

Which version are you using? Can you try 7.3.2 and 7.2.6?

New version work like magic. Thank you!


Add a todo in zorder that we can do rebalance partitions before local sort of zorder

Why are the changes needed?

Rebalance partitions can resolve data skew issue before writing, so it should be good to do before we do the local sort of zorder, and also we can support dynamic partition insertion with zorder. However Spark only support this after 3.3.0, see PR.
So add a todo first.
How was this patch tested?
not needed

Codecov Report

Merging #1366 (972229e) into master (0f1d4ec) will increase coverage by 0.06%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1366      +/-   ##
============================================
+ Coverage     79.00%   79.07%   +0.06%
  Complexity      110      110
============================================
  Files           179      181       +2
  Lines          7494     7645     +151
  Branches        917      932      +15
============================================
+ Hits           5921     6045     +124
- Misses         1082     1099      +17
- Partials        491      501      +10

Impacted Files
Coverage Δ

...ubi/sql/zorder/InsertZorderBeforeWritingBase.scala
82.27% <ø> (ø)

...mon/src/main/scala/org/apache/kyuubi/Logging.scala
55.10% <0.00%> (-2.05%)
:arrow_down:

...org/apache/kyuubi/operation/ExecuteStatement.scala
87.35% <0.00%> (-1.07%)
:arrow_down:

.../org/apache/kyuubi/operation/KyuubiOperation.scala
54.09% <0.00%> (ø)

...org/apache/kyuubi/server/RestFrontendService.scala

...ache/kyuubi/server/KyuubiRestFrontendService.scala
86.79% <0.00%> (ø)

...che/kyuubi/server/KyuubiMySQLFrontendService.scala
87.71% <0.00%> (ø)

...main/scala/org/apache/kyuubi/util/NettyUtils.scala
37.50% <0.00%> (ø)

...in/scala/org/apache/kyuubi/config/KyuubiConf.scala
95.29% <0.00%> (+0.04%)
:arrow_up:

...rg/apache/kyuubi/events/KyuubiStatementEvent.scala
96.77% <0.00%> (+1.12%)
:arrow_up:

... and 3 more

Continue to review full report at Codecov.

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

thanks for review, merged to master


chore: Merge master into develop

Codecov Report

Merging #878 into develop will increase coverage by 0.7%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           develop     #878     +/-   ##
==========================================
+ Coverage    94.62%   95.32%   +0.7%
==========================================
  Files           69       69
  Lines         2997     3789    +792
  Branches       554      831    +277
==========================================
+ Hits          2836     3612    +776
- Misses          85       96     +11
- Partials        76       81      +5

Impacted Files
Coverage Δ

samtranslator/parser/parser.py
89.65% <0%> (-1.26%)
:arrow_down:

samtranslator/model/apigateway.py
97.03% <0%> (-0.7%)
:arrow_down:

samtranslator/plugins/api/implicit_api_plugin.py
95.92% <0%> (-0.56%)
:arrow_down:

samtranslator/translator/translator.py
98.63% <0%> (-0.34%)
:arrow_down:

samtranslator/plugins/globals/globals.py
100% <0%> (ø)
:arrow_up:

samtranslator/intrinsics/actions.py
98.78% <0%> (+0.07%)
:arrow_up:

samtranslator/model/sam_resources.py
96.34% <0%> (+0.84%)
:arrow_up:

samtranslator/swagger/swagger.py
98.75% <0%> (+1.18%)
:arrow_up:

...lator/plugins/application/serverless_app_plugin.py
83.48% <0%> (+1.36%)
:arrow_up:

samtranslator/model/api/api_generator.py
95.89% <0%> (+1.6%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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


[freerdp/libusb] build failure

Host Environment

OS: x64-linux
latest vcpkg master

To Reproduce
Steps to reproduce the behavior:
./vcpkg install libusb:x64-linux
Failure logs
Building package libusb[core]:x64-linux...
--
737 | CMake Error at ports/libusb/portfile.cmake:2 (message):
738 | Error: the port is unsupported on your platform.  Please open an issue on
739 | github.com/Microsoft/vcpkg to request a fix
740 | Call Stack (most recent call first):
741 | scripts/ports.cmake:90 (include)
742 |
743 |
744 | Error: Building package libusb:x64-linux failed with: BUILD_FAILED
745 | Please ensure you're using the latest portfiles with `.\vcpkg update`, then
746 | submit an issue at https://github.com/Microsoft/vcpkg/issues including:
747 | Package: libusb:x64-linux
748 | Vcpkg version: 2020.02.04-unknownhash-external
749 |
750 | Additionally, attach any relevant sections from the log files above.
751 | The command '/bin/sh -c ./vcpkg install freerdp' returned a non-zero code: 1
752 | time="2020-05-11T07:08:47Z" level=fatal msg="exit status 1"

Additional context
I'm using the freerdp port which depends on libusb. I don't even make use of libusb, so an alternate solution for my case would be to make the libusb dependency optional.
Relevant PR: https://github.com/microsoft/vcpkg/pull/11051 (added the libusb dependency)

Related issue: https://github.com/microsoft/vcpkg/issues/9560
As @VelocityRa mentioned, this causes freerdp:x64-linux to fail as well (since it depends on libusb).


Remove the unnecessary operation of setting the socket to blocking mode.

Motivation:
Netty forcibly set the socket to blocking mode， but I checked the source code of io_uring in Linux 6.1.112 and found that the FAST_POLL mechanism has nothing to do with whether the socket is in blocking mode.
So it is actually unnecessary to forcibly set the socket to blocking mode
First, look at the opdef of IORING_OP_RECVMSG.
  [IORING_OP_RECVMSG] = {
        .needs_file     = 1,
        .unbound_nonreg_file    = 1,
        .pollin         = 1,
        .buffer_select      = 1,
        .ioprio         = 1,
        .manual_alloc       = 1,
        .name           = "RECVMSG",
#if defined(CONFIG_NET)
        .async_size     = sizeof(struct io_async_msghdr),
        .prep           = io_recvmsg_prep,
        .issue          = io_recvmsg,
        .prep_async     = io_recvmsg_prep_async,
        .cleanup        = io_sendmsg_recvmsg_cleanup,
        .fail           = io_sendrecv_fail,

When io_uring processes the sqe for the first time, it will forcibly call io_recvmsg with IO_URING_F_NONBLOCK.
static inline void io_queue_sqe(struct io_kiocb *req)
    __must_hold(&req->ctx->uring_lock)
{
    int ret;

    ret = io_issue_sqe(req, IO_URING_F_NONBLOCK|IO_URING_F_COMPLETE_DEFER);

    /*
     * We async punt it if the file wasn't marked NOWAIT, or if the file
     * doesn't support non-blocking read/write attempts
     */
    if (likely(!ret))
        io_arm_ltimeout(req);
    else
        io_queue_async(req, ret);
}

For the implementation of recv, if IO_URING_F_NONBLOCK is passed in, MSG_DONTWAIT will be put into the flag by default. For the recvmsg system call, this flag will non-blockingly try to see if there is data.
So the first non-blocking attempt has nothing to do with whether the socket is in blocking mode.
int io_recvmsg(struct io_kiocb *req, unsigned int issue_flags)
{
   //....
    bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
   //....
    flags = sr->msg_flags;
    if (force_nonblock)
        flags |= MSG_DONTWAIT;

    //....
    ret = __sys_recvmsg_sock(sock, &kmsg->msg, sr->umsg,
                     kmsg->uaddr, flags);
    //....
 }

If no data can be fetched, then io_queue_async -> io_arm_poll_handler -> __io_arm_poll_handler will be executed.
if (def->pollin) {
//这里的recv op是支持 poll in的
//最后会直接挂载到vfs的poll上去
        mask |= EPOLLIN | EPOLLRDNORM;

        /* If reading from MSG_ERRQUEUE using recvmsg, ignore POLLIN */
        if (req->flags & REQ_F_CLEAR_POLLIN)
            mask &= ~EPOLLIN;
    } else {
        mask |= EPOLLOUT | EPOLLWRNORM;
    }
    if (def->poll_exclusive)
        mask |= EPOLLEXCLUSIVE;

    apoll = io_req_alloc_apoll(req, issue_flags);
    if (!apoll)
        return IO_APOLL_ABORTED;
    req->flags &= ~(REQ_F_SINGLE_POLL | REQ_F_DOUBLE_POLL);
    req->flags |= REQ_F_POLLED;
    ipt.pt._qproc = io_async_queue_proc;

    io_kbuf_recycle(req, issue_flags);
//It Equivalent to ` mask = vfs_poll(req->file, &ipt->pt) & poll->events`;
    ret = __io_arm_poll_handler(req, &apoll->poll, &ipt, mask, issue_flags);

So it is actually not necessary to forcibly set the socket to blocking mod
reference: https://github.com/axboe/liburing/issues/487
Modification:
Remove the unnecessary operation of setting the socket to blocking mode.
Result:
Remove the unnecessary operation of setting the socket to blocking mode.

So strange.
A GLIBC version issue is encountered in the tests of the testsuite_jpms module.


Fix links to Travis CI and wdio-dot-reporter

There are some links that still point to the webdriverio organization instead of the webdriverio-boneyard org. This PR corrects the ones that I can.
It looks like it may also be necessary for someone who has access to CodeClimate and David to update the URLs to the project there and then update them in the README.

@bval once we release v5 we will archive this repo

@christian-bromann thanks for the heads up! I was considering tackling adding attachment support from junit-report-builder as suggested in #2. Should I hold off on that PR until 5.0 is out? I'm probably not hip to the release plan.

@bval you can already work on this here: https://github.com/webdriverio/webdriverio/tree/master/packages/wdio-junit-reporter


Turn off function-paren-newline, introduced in ESLint v4.6.0

Turn off function-paren-newline and upgrade to ESLint 4.6.0.

Thanks! Released in 2.4.0.


Crash when eating food while holding a torch in the offhand (or probably any other item in the slot)

Crash Report
• Backhand 1.2.0
• No BattleGear
• No Offhand Mod

Do I need MysteriumLib?

Please send a new crash report, that one's empty. I'm also not getting this crash on my end running just Backhand. Are there any mods you're running while doing this?

Closing because of the age of the issue, and it doesn't seem to be happening anymore. Feel free to reopen the issue if this crash persists in later versions.


Improve the database.yml.example

Description
This pr is improving the config/database.yml.example, adding the database.yml file to .gitignore. This way everybody can change the database.yml according their needs, and git won't accuse this changes.
Type of change

Improvement

How Has This Been Tested?
Running git status.

Awesome, thanks!


Getting Started Procedure Fails

The getting started steps do not work for Visual Studio 2017.

Create .NET console app targeting x64 .Net Framework 4.7
Change project type to "Windows Application"
Add Chromely.CefSharp.Winapi (67.0.0-pre01) from Nuget-prerelease
=> Fails to load System.IO.Compression.ZipFile and rolls back
Manually install System.IO.Compression.ZipFile from Nuget
Add Chromely.CefSharp.Winapi (67.0.0-pre01) from Nuget-prerelease
=> Fails with multiple errors
=> Rolls back

I just tried it and it was successful. Please see attached.
Please ensure that x64 configuration is selected. It will fail if AnyCPU is selected. Alternative is to set AnyCPU support flag, but not necessary:
https://github.com/mattkol/Chromely/blob/a3a35ff984908880bd41ba7d72cbca1ddc11ef8d/src/Chromely.CefSharp.Winapi/Chromely.CefSharp.Winapi.csproj#L5
Also note that this is while downloading CEF binaries from CefSharp. If this error persist we may have to chat with the CefSharp group. But it works all the time, though.
CefSharpTester.zip

I tried again and got it to work by following these steps:

I created a new blank solution.
Instead of a console app, I created a windows forms app targeting .NET v4.61
Before adding the nuget packages, I changed the platform configuration to x64 for both the solution and the application.
Add the nuget packages as before.
Replaced the code in program.cs with code from the winapi demo.

Well I guess that should work too. But Chromely is not intended to be used/embedded in WinForms. The intention from Readme:
... It is focused on building apps based on Xilium.CefGlue, CefSharp implementations of  embedded Chromium (Cef) without WinForms or WPF.
But if it works for you, all great!
Thanks.


[New Port Request] Zeb

Library name: zep
Library description: Zep is a simple embeddable editor, with a rendering agnostic design and optional Vim mode. Out of the box Zep can draw to a Qt Widget or an an ImGui window - useful for embedding in a game engine.
Source repository URL: https://github.com/Rezonality/zep
Project homepage (if different from the source repository): N/A
Anything else that is useful to know when adding (such as optional features the library may have that should be included):

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now, consider making a pull request instead.


Feature Request for Anime Recommendation System #769

fix #769
Advance Anime Recommendation System
This project implements an Anime Recommendation System using both content-based and collaborative filtering techniques. It provides recommendations based on user preferences and anime content, leveraging deep learning for enhanced collaborative filtering.
Features

Data Preprocessing: Cleans and preprocesses anime.csv and rating.csv datasets.
Exploratory Data Analysis (EDA): Provides an overview of anime types, genres, ratings, and other insights.
Content-Based Filtering: Generates recommendations based on anime genres, type, and average ratings.
Collaborative Filtering: A deep learning-based recommendation model that learns user preferences.
Genre-Based Recommendations: Ensures diverse recommendations by including various genres in top recommendations.
New User and New Anime Recommendations: Customized recommendations for new users and newly added anime.

Recommendation Strategies
Content-Based Filtering

Uses anime metadata (e.g., genre, type, and rating) to recommend similar anime based on a selected anime.

Collaborative Filtering (Deep Learning)

Leverages a neural network to predict user ratings for anime based on user preferences and anime embeddings.
Designed to provide personalized recommendations to each user.

Diverse Genre-Based Recommendations

Recommends a variety of anime by selecting top anime per genre to ensure a diverse list.

Recommendations for New Users and Anime

New Users: Recommends top-rated anime across all users.
New Anime: Recommends to users who have shown interest in similar genres.

Favorite Genre Recommendations

Identifies the top genres preferred by each user and recommends anime from these genres.

Output
Anime Recommendation System v1.ipynb - Colab.pdf

@UppuluriKalyani hey review my pr.
i did content based filtering with nlp and Collaborative Filtering with deep learning also added new user feature too
could please increase the level :)

@UppuluriKalyani can you please increase the level of the issue


Drag 'n drop rubrics reordering doesn't work

with default fictures, on http://localhost:3000/en/assignments/1/rubrics
drag n dropping rubrics for reordering doesn't work.

I will work on this.

Closed with 98573eafe2792c974b1102dcfc24909c9d3f81b3


Tab context menu actions to open a new tab

Context menu on a tab header
Only actions to close, I would expect some actions to open a new tab (new, open) - similar to sublime and chrome

I am not convinced this adds a lot of value...

I think we need some mouse gesture to quickly open a new tab. If you do not like this then I would push more for #7889
I also think the context menu might benefit from this - currently it is just a bunch of close actions. A new and a seperator might actually improve the visuals while making it consistent with what other editors are doing.

@isidorn not true, if you open the context menu on a diff editor, there is a lot more entries. We put all editor actions into the context menu as well.

@bpasero yeah I know, but for the most common case it is just a bunch of close actions as far as I see it

UX meeting topic I guess.

We decided to start with double click besides a tab to open a new untitled first.


Menu: should Alt move focus into the top level menu items?

Refs: #52854
We might need an accessible way to put focus into the menu bar so that it can be explored by a screen reader. The native behaviour seems to be to move focus to the first top level menu entry when you press Alt and release it.

this does not work for me. Using NVDA 2018.2.1, vs code 1.26.1 - made sure use menu key mnemonics setting is set to on. pressing left alt key does not make NVDA to speak anything. using arrow keys to navigate moves me inside the editor.

well, seems it started to work after I changed "window.titleBarStyle": "custom", - there perhaps should be mention in the documentation somewhere about it.

@OSadovy thanks for verifying with the new titlebar style. Currently, the new style is still in preview and disabled by default, but we hope to change that soon :)


Create release workflow

We need to set-up release workflow with generation of changelog based on conventional-commits (would be nice to use git-cliff).
I've published beta-version to testcontainers-modules, so we can configure auto-publishing on github release (I also can add owners of crate).
We will need to add crates.io token to secrets to this repo
Depends on #1

Closed with https://github.com/testcontainers/testcontainers-rs-modules-community/pull/36 & https://github.com/testcontainers/testcontainers-rs-modules-community/commit/1bc5299492913ba43226bc365ba2d0ee6570a5f0


Support "k", "M", "G", "T" and other units

This closes #627

Codecov Report

Merging #657 (b675b33) into develop (27120e4) will increase coverage by 0.04%.
The diff coverage is 27.45%.

@@             Coverage Diff             @@
##           develop     #657      +/-   ##
===========================================
+ Coverage    52.74%   52.78%   +0.04%
===========================================
  Files           52       54       +2
  Lines         3333     3353      +20
===========================================
+ Hits          1758     1770      +12
- Misses        1575     1583       +8

Impacted Files
Coverage Δ

...ipt/ReducerInterface/ReducerInterface_Duration.res
8.33% <ø> (ø)

...cript/ReducerInterface/ReducerInterface_Number.res
7.69% <7.69%> (ø)

...escript/ReducerInterface/ReducerInterface_Date.res
13.33% <13.33%> (ø)

...ucerInterface/ReducerInterface_ExternalLibrary.res
100.00% <100.00%> (ø)

...Interface/ReducerInterface_GenericDistribution.res
51.51% <100.00%> (-1.71%)
:arrow_down:

...ucer/Reducer_Dispatch/Reducer_Dispatch_BuiltIn.res
87.32% <0.00%> (+1.40%)
:arrow_up:

...ucerInterface/ReducerInterface_ExpressionValue.res
46.98% <0.00%> (+14.45%)
:arrow_up:

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 d4f631f...b675b33. Read the comment docs.

I need to merge for Nuno to use soon, but comments still appreciated.


Improved cli, added version integration with cmake

What this pr does:

Made the --help command more understandable
Added version integration with cmake (note: it's on the project() decl in cmakelist)
Shortened include path, no more ../..
Added shorthand cli command like -v and -h
Better error message for invalid commands and lack of cli arguments
Accidentally added newline character at the end of a lot of files

this is actually so cool, didn't know you could do that with cmake

It's actually from the first cmake (official docs) tutorial:
https://cmake.org/cmake/help/latest/guide/tutorial/A Basic Starting Point.html

I think it's to mimic some macro features that gnu make has.
But it's a nice feature, nonetheless


Initialize library filtering by Continent/Country

In timeshape today, there are two methods for initializing the library

with the data for the whole world
with some bounding box only, to reduce memory usage

It would be interesting to have a third option for initializing with the data of a continent or a country because the main scopes of use are political following the patterns:

whole world (international usage)
my country (USA, Brazil, etc...)
my region (European Union, South America, Asia, etc...)

This division could be made according to IANA existing divisions.

I was thinking about something similar as well. These cases, while sounding somewhat similar, have quite different implementation complexity, so let's take them one by one:

Initialize for a given continent/region, like Europe, Asia, etc. This could be done relatively easily, if we could use prefix from the time zone id. E.g. given prefix Europe, time zones like Europe/Berlin or Europe/Stockholm will be included, but e.g. Asia/Tomsk will not.
Initialize based on country. This is a slippery slope. Given the fact that there are a lot of disputed territories in the world (see e.g. https://github.com/RomanIakovlev/timeshape/issues/27), I'd rather avoid making any decision to which country any given timezone belongs. Besides that, it would require adding more dependencies to the Timeshape library, which I'd rather avoid, because I don't want to include any popular dependencies

But I think more ways to limit the loaded time zones would be a useful addition to the Timeshape, and therefore I have a couple of proposals. Firstly, we can introduce one more way to initialize, which would accept Set<java.time.ZoneId>. Only those time zones will be considered for search. The users of Timeshape will obtain the list of interesting time zones in whatever way they find appropriate, e.g. by using Time4j.
Secondly, we can implement an option which accepts a regular expression. Only time zones, id's of which match this regex, will be considered for search. This is a generalization of point 1. mentioned above.
Both of these options are relatively easy to implement. Do you think any of these will be useful?

Instead of limiting, could you provide a lazy loading by splitting into region-specific indexes? As in, if you know the bounding box for a region then you can query determine which Index to delegate to. Then only the sub-indexes being used would be in-memory, reducing the footprint for development and localized application.

@ben-manes right, I've been thinking about implementing some sort of lazy loading as well. I'm not sure what's the best way to implement this, but I think it might be a useful addition to the Timeshape, since, although the lazy loading will always incur some sort of performance penalty, for some use cases it might be negligible. Lazy loading might even be preferable, if initialization time will be cut down. E.g. if you use some FaaS (e.g. AWS Lambda), where you only need to query one position (of unpredictable origin), you shouldn't be paying the price of full initialization.
I guess, I'll just open another issue to keep track of and discuss the lazy loading.

What should be the impact on size/performance when the shapes are simplified?
There are any numbers on this?

Closing due to lack of activity. If there's still interest in working on this, anyone should feel free to pick up this work, and I'll provide support with code reviews and releases.


Empty space bio profile

Describe the bug
Can fill bio with empty space
To Reproduce
Steps to reproduce the behavior:

Go to 'profile page'
Click on 'edit profile'
Fill bio with empty space
Save and voice settings and sound settings go right to the bottom

Expected behavior
Not allow just empty space
Screenshots
https://catgirls-are.sexy/
What device are you on?
windows

Sus link 🤨

Sus link 🤨

Pays.host..?

I've fixed it and raised a PR here: https://github.com/benawad/dogehouse/pull/1624

I've fixed it and raised a PR here: https://github.com/benawad/dogehouse/pull/1624

Should we resolve this then?


Added csh-bootstrap to frontend

The project is now included as a git subtree. (That's where all the @bencentra commits are coming from)
Additionally, the base template was extracted from the haskell source file it was embedded in.

Otherwise the pull request looks good.

The addition of files with the names "Gruntfile.hs" and "package.json" smells a lot like needing Node.JS in the build system. If that's a potential consequence of this PR then I think we should discuss whether or not we want to incur those additional build-time dependencies.
To be clear, by "included as a git subtree" you mean you used git read-tree, right? Are we going to stay in-sync with upstream csh-bootstrap, applying some evals-specific changes? Apologies if this was discussed and I simply missed out, but I'm not clear on what we're trying to accomplish by doing this.

@bencentra can correct me if I'm wrong at any point in this explanation. The package.json is because the csh-bootstrap projects is also an npm package, and that is the packaging metadata. The Gruntfile.js is the build system information for compiling less to css, which also needs some npm packages to do. It won't pull node.js into our project, and the grunt build won't be run by our build, but instead be run as needed if an update to the less files in csh-bootstrap is done.
In theory, we don't need any of the extra scaffolding at all, and can just do with the css file output by the grunt build system. I would generally prefer for us to not put any changes into the csh-bootstrap css/less files, but rather have our own set of css (or rather, lucius) files that contain any of our changes to the style. The csh-bootstrap styles are just for having a consistent style across CSH systems.

@sdemos you're 99% right. It's not an actual npm package (I didn't publish it), package.json is just used to list all dependencies, in this case the various Grunt plugins being used. Otherwise, spot on.
You don't need to have any of the csh-bootstrap source files in your project. Updates will be few and far between, and (to maintain compatibility with Bootstrap) will be non-breaking anyway, so you can just manually update the file whenever an update does happen. (The one update I can think of is when Marc Billow finishes his "CSH Style Guide" and I make the csh-bootstrap colors match the ones he chose.)
If you're gonna use Bootstrap, use csh-bootstrap to keep it CSH-y. Any additional changes will be done in your project's lucius files. Basically: csh-eval CSS > csh-bootstrap CSS > base Bootstrap CSS.


Removing extremes yields different results than manual remove

Hello, although I can't immediately see how anything is wrong with the code, I have found that removing extremes leads to (very) different results than if you run the plugin without removing extremes, and then manually remove the same extremes. The method used is the same, is it not? So I don't know where the issue is, but it's quite substantial.

With plugin

Manual

Consider using:
removeNodeCheckKeepShape_normalizeHandles_(node, True)
This requires a somewhat different iteration structure, not sure why, but it works.


Auto-deploy PRs to some testing server with a running federation

I'd like to be able to take a quick look at things without getting the whole UI dev setup going.

What infra do you want to deploy that on? I can spin one up pretty easy on clovyr and auto deploy one pointing to that but might want something more easily upgradeable.

Made easier with this guy: https://github.com/fedimint/ui/pull/485 , can just auto deploy preview without any config set and point it at whatever guardian you want

I think this kinda happens with vercel now, but I might be holding it wrong:

Can you check if you can make access public @Kodylow?


Two Fields named "Time of Sampling" in Certificate of Type TEST

Describe the bug
There are two fields named "Time of Sampling" shown in the certificate data in certificates of type TEST.

Expected behaviour
One of these two "Time of Sampling" fields contains the value "Detected/Undetected" and should be called "Test Result".

Steps to reproduce the issue
Read a Test Certificate in the wallet app.

Technical details
iPhone 8 plus v. Lutz,  Model MQ8P2ZD/A, iOS 14.4
Possible Fix

Additional context

This is probably related to the wrong core module being built. Please check with Hendrik that you're using the latest build

In latest release, it could be retestet successful.


Diagnostic for additional unannotated properties that are ignored due to @body

Playground Link
Notice how the property a disappears from the output entirely. I believe @body has always had this effect on responses and it can be observed on parameter with nested @body too after #2029. See discussion there.
We have long had a check against having unannotated top-level parameters and @body, but perhaps it should be generalized to find any unannotated property that gets subsumed by a sibling or sibling-descendant @body.

single warning diagnostic for both request and response bodies, emitted from http library

gets fixed as part of #2945


Confused before string

Describe the bug
Sometimes the before string is confused. Some characters missing.
To Reproduce
import wexpect
import time

print(wexpect.__version__)

def testPath():
    # Path of cmd executable:
    cmdPath = 'cmd'
    cmdPrompt = '>'
    referenceOut = None

    while True:
        # Start the child process
        p = wexpect.spawn(cmdPath)

        # Wait for prompt
        p.expect(cmdPrompt)

        # Send a command
        p.sendline('ls')
        # time.sleep(0.6) <= this sleep solve...
        p.expect(cmdPrompt)

        print(cmdPath + " >>" + p.before + '<<')
        if referenceOut:
            if referenceOut != p.before:
                p.interact()
                time.sleep(5)
                raise Exception()
        else:
            referenceOut = p.before

testPath()

Expected behavior
Script above should never stop.
Environment:

OS Name	Microsoft Windows 10 Pro
Version	10.0.18362 Build 18362
Python 3.7.4
wexpect 2.3.6

Additional context

The interact() console shows correct behavior.
Only cmd.exe can reproduce this issue for now. (Any python simulation works correctly)
sleep before the p.expect(cmdPrompt) solve.

I can reproduce with v4.0.0 also...


Update documentdb-partition-data.md

Added missing word to complete the context of the sentence.

Hi @nstjelja, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

@nstjelja : Thanks for your contribution to the Azure documentation! The author, @arramac, has been notified to review your proposed change.

#signoff


[Task]: Pipeline testing framework

What needs to happen?
We already hold some transforms to make assertion like:
https://github.com/laysakura/beam/blob/54b4d233b5c5a07c3f9d406b723d198f60d3c8ef/sdks/rust/tests/primitives_test.rs#L57
But we might lack some test transforms compared to other SDKs, or rather we might be able to develop more sophisticated test framework to test pipelines.
The task should be like:

First, conduct survey on other SDKs and write a design document (in google docs and add to the wiki page) to make aligned image of the next test framework of Rust SDK.
Request a review from other contributors ( @laysakura and/or @sjvanrossum would be happy to review it).
Develop it.

Issue Priority
Priority: 3 (nice-to-have improvement)
Issue Components

[ ] Component: Python SDK
[ ] Component: Java SDK
[ ] Component: Go SDK
[ ] Component: Typescript SDK
[ ] Component: IO connector
[ ] Component: Beam examples
[ ] Component: Beam playground
[ ] Component: Beam katas
[ ] Component: Website
[ ] Component: Spark Runner
[ ] Component: Flink Runner
[ ] Component: Samza Runner
[ ] Component: Twister2 Runner
[ ] Component: Hazelcast Jet Runner
[ ] Component: Google Cloud Dataflow Runner

I skimmed over what the different sdks provide, and personally found the following to seem quite useful

apply a predicate function to each input element and fail if the predicate function returns false:

go https://github.com/apache/beam/blob/f1adfdd7f24b65742bf66292943feba1a1ec94df/sdks/go/pkg/beam/testing/passert/equals.go#L67-L105
java https://github.com/apache/beam/blob/f1adfdd7f24b65742bf66292943feba1a1ec94df/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/PAssert.java#L595-L607
typescript https://github.com/apache/beam/blob/f1adfdd7f24b65742bf66292943feba1a1ec94df/sdks/typescript/src/apache_beam/testing/assert.ts#L69-L108

count number of elements in a collection:

https://github.com/apache/beam/blob/f1adfdd7f24b65742bf66292943feba1a1ec94df/sdks/go/pkg/beam/testing/passert/count.go

materialize pipeline with no intention of running it:

https://github.com/apache/beam/blob/f1adfdd7f24b65742bf66292943feba1a1ec94df/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/CrashingRunner.java

component specifically for testing combinefns:

https://github.com/apache/beam/blob/f1adfdd7f24b65742bf66292943feba1a1ec94df/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/CombineFnTester.java

test pipeline to simplify instantiation of test pipeline to be run against different runners:

https://github.com/apache/beam/blob/f2240ffd9c57a16266b240a116e93ed9a877e623/sdks/java/core/src/main/java/org/apache/beam/sdk/testing/TestPipeline.java
https://github.com/apache/beam/blob/f2240ffd9c57a16266b240a116e93ed9a877e623/sdks/python/apache_beam/testing/test_pipeline.py

On top of those, we will probably want transforms crafted specifically to validate streaming pipelines, but it might not make much sense to attempt to implement such validations before we implement proper window/watermark handling. finally, I wonder if it would be useful with a collection factory that shuffles the provided input for tests rather than emitting the values in a deterministic order 🤔

@dahlbaek Thank you for your wholistic investigation.
Things I feel really useful

apply a predicate function to each input element and fail if the predicate function returns false
count number of elements in a collection
component specifically for testing combinefns
a collection factory that shuffles the provided input for tests rather than emitting the values in a deterministic order

Things I feel interesting (nice to have)

materialize pipeline with no intention of running it
test pipeline to simplify instantiation of test pipeline to be run against different runners

Additionally, I will totally agree with the following opinion.

we will probably want transforms crafted specifically to validate streaming pipelines, but it might not make much sense to attempt to implement such validations before we implement proper window/watermark handling.

Could you start to write a design doc?


Splitter_characters_grouper_search_step Parameter Tuning article header is over the layout

The header of folowing article on the site is over the site layout
http://aif.io/blog/2014/12/27/splitter-characters-grouper-search-step-parameter-tuning/

Closed in 35f673b7
There is no normal fixes for that issue cause browsers can't break words on undescores.
Better to avoid long words like Splitter_characters_grouper_search_step  in titles


Support Shadow Picker

I branded off from your shadows branch and continue my work
Thank for your shadow model logic 🤣
Change logs

Support ShadowList and ShadowPicker (reused from ColorPickerView)
Reflect shadow attribute
Only support for UIView

Screenshots

Looking forward to hearing your thought 👍

All of feedbacks are correct, I will update it soon.
About the clipped shadow, I suppose it' super easy to make the shadow doesn't clip by view. Just set masksToBounds on CALayer, and it's done ;]

Hm, actually, it's hard than I thought. For some reasons, textLayer.layer?.masksToBounds = false & wantLayer = true result in disappearing NSAttributeString 🤔
Maybe I should override CSTextView and draw shadow manually

After investigating carefully, I turn out the problem is the CSTextView clips the contents.
As you can see the screenshot, I only add 1 subview is TextView

However, when I capture the layer, there are 2 views which represent for the textView I added.

Interestingly enough, only CSView's heigh expands when I set fixed height. On the other hand, the CSTextView doesn't expand, it's still small size.
As a result, it clips the shadow.

I tried to hard code the height when rendering the TextView. But it still doesn't work ?
https://github.com/airbnb/Lona/blob/957e893236d5fab84e89d11f7c3754f86b1e6c1f/LonaStudio/Canvas/CanvasView.swift#L106-L111
@dabbott Do you have any idea why CSTextView wasn't expand the height 🤔

@NghiaTranUIT I'm not sure... I'll checkout your branch and take a look now.
PS: I added you to the README. Feel free to change what I put.

I might have to play around with this a bit. Either way, when I'm done I'll merge it :+1:. It looks good and we can always iterate.

Yes, Thank you in advance @dabbott, I spent to the shadow issue for a while, but no clue. Let me know if you'd want a hand 👍

@NghiaTranUIT definitely a tricky problem. I'm going to remove the parent CSView from the view hierarchy, and expand the frame of the text. E.g.
let textLayer = renderTextLayer(layer: layer, width: width, height: height)

if let shadow = getLayoutShadow(layout: layer) {
    let padding = NSSize(
        width: abs(shadow.x) + shadow.blur,
        height: abs(shadow.y) + shadow.blur
    )
    textLayer.textContainerInset = padding
    textLayer.frame.origin.x -= padding.width
    textLayer.frame.origin.y -= padding.height

    // Conceptually it seems like we should multiply by 2,
    // but that doesn't add enough padding.
    textLayer.frame.size.width += padding.width * 4
    textLayer.frame.size.height += padding.height * 4
}

This gives the desired behavior:

It's not an ideal solution, but I think it should be fine. I've been meaning to make a few other tweaks to Text (Text shouldn't be able to have padding/background/border), so I'm going to merge what you have and I'll do all this separately. I'll make a PR and tag you when I'm done.

That's cool @dabbott. Thank for helping me 👍


Outputcache should always vary by scheme to prevent SSL bypass

The Outputcache currently does not differentiate between the scheme (http/https) which will allow a visitor to bypass SSL on pages configured in to be served under https in SecureSocketsLayer module.
Steps to reproduce issue 2:

Enable OutputCache

Enable SecureSocketsLayer

Configure a convenient cache time to reproduce the issue, e.g. 600

Configure a secure URL, e.g. "~/contact-us"

Create a page with the autoroute "contact-us"

Important: LOG OFF

Navigate to the secure URL http://localhost:30321/contact-us

You should be redirected to https://localhost:44300/contact-us

LOG BACK IN

Confirm in Admin/Cache that /contact-us is now cached

Important: LOG OFF

Navigate to the INsecure URL http://localhost:30321/contact-us

Expected result: Redirect to Secure URL
Actual result: No redirect, serving cached INSecure URL
The reason for this, is that in the first request (step 8) OutputCache does not find the page in its cache therefore the filters are executed. The SSL filter returns a 302 redirecting the browser correctly to the secure URL (step 9), which is subsequently cached and rendered back to the browser.
On the second INSecure request (step 15), the OutputCache now finds the page in its cache, and immediately returns the cached version, however this is the Secure version (from step 9) now being served under http.
There are a few solutions, one of which is putting the SSL filter before the OutputCache, but that just adds more processing to every cached request. By far the simplest solution, possibly also the most hardened, is to add the scheme de facto to the cache key.
Will submit the PR right away.

Good catch. I agree - look forward to your PR.

Created PR #6851
Not the most exiting of PR's @DanielStolt but one that automagically does the trick :8ball:

The simplest, cleanest and most surgical PRs are the best ones IMO! :)


We don't have a buildbot for cross-compiled builds

Follow-up from ...:

https://github.com/python/cpython/issues/90039

Technically, I think we do now; between the iOS, Android, and WASI builds.  I'm not sure there's anything else we can reasonably test that those don't cover.


Need to change the color of Cards. #2

Issue: Need to change the color of Cards. #2
Made a dark and light theme for the cards and made it easy to add/create other themes

You only said to make a theme I don't understand what you mean by pinned and the themes seems to work for me

Pinned repository means the below image... width height and border and curved corner for the cards.

gave it a border-radius and border

That issue was fixed and closed. I will close this PR


Checkpointing update

With the compression PR ready on pyrevolve - this becomes necessary because that PR changes the API between devito and pyrevolve.
The direction of this change is to reduce the amount of data that is checkpointed and results in non-trivial speedups.
TODO:

Add test to check numpy flags are set correctly on devito.data objects.

From what I understand, the failure on CI is due to numpy version 1.16 and the changed API. I need to go back into this to figure out what broke compatibility from 1.14 to 1.16 (will explore @tjb900 's change in the above line from earlier).

@navjotk
I see the compression PR has been merged in pyrevolve, so I wonder what's the situation here?

In the new version, pyrevolve uses pyzfp for compression. This is another package I wrote myself - a cython wrapper over the zfp library. Some issues on how pyrevolve should specify the dependency on pyzfp were only revealed on travis here. pip install pyzfp works fine, but pip install pyrevolve, where pyrevolve internally specifies a dependency on pyzfp actually follows a completely different codepath in pip. This is why the tests on the pyzfp repo and the pyrevolve repo didn't catch the issue. Still working on fixing it.

This now passes on travis but fails on Azure pipelines. Any ideas on where the difference in behaviour could come from? @tmbgreaves

Codecov Report

Merging #771 into master will decrease coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #771      +/-   ##
==========================================
- Coverage   88.84%   88.78%   -0.07%
==========================================
  Files         100      100
  Lines       11341    11391      +50
  Branches     2234     2248      +14
==========================================
+ Hits        10076    10113      +37
- Misses        981      995      +14
+ Partials      284      283       -1

Impacted Files
Coverage Δ

devito/tools/utils.py
75% <100%> (ø)
:arrow_up:

devito/data/allocators.py
73.64% <100%> (+0.17%)
:arrow_up:

devito/data/data.py
91.75% <100%> (ø)
:arrow_up:

devito/compiler.py
53.04% <0%> (+4.05%)
:arrow_up:

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 7af7e30...54b9847. Read the comment docs.

@tmbgreaves @ggorman can we please sort this out in person next week? I'll be available Monday/Tuesday/Wednesday

Works for me. Thanks so much for this!

@tmbgreaves I managed to narrow it down to a single line. Commenting the line:
RUN update-alternatives --install /usr/bin/ar ar /usr/bin/gcc-ar-$gccVersion 10

makes everything pass.

I guess it must be a bug in the ubuntu-toolchain-r version of ar, then. It's probably fairly reasonable to stick with the system version of ar, but it sounds like a bug worth tracking down and reporting. I'll have a go at it tonight.

Is it still worth me coming in tomorrow or is this a reasonable enough workaround to go with for now and revert when there's a fixed version of ar?

I'm happy with this if you are.

OK, let's leave it at that for now, and I'll stick on my list to try and make a small test case to report back to the developers for the ar breakage.

This is ready for merge @FabioLuporini

Merged.


Set acquireTimeoutMillis in default configuration

By default a pool created by https://github.com/coopernurse/node-pool#createpool has infinite timeout when acquiring a resource from the pool.
As rascal uses it to "manage" channels when it comes to publishing messages to RMQ, it can happen that calling to publish a message via rascal can stucks for event. It was the case in https://github.com/guidesmiths/rascal/issues/156 and it was quite hard for me to figure out why my application hangs and where.
Note: configuring publications.timeout (see here) doesn't help because timeout starts ticking once you already have a channel acquired from the pool.
Therefore, I suggest to set this timeout to 15 secs. In my eyes it is important to have timeout set to away waiting for ever  (it isn't so important whether it is 15s or 60s).  Having a timeout set allows an error to bubble up and reveal the issue.

Good idea. Thanks @matej-prokop. Will publish later today.

Released as<EMAIL_ADDRESS>Thanks again @matej-prokop


Color Issue with Deer Hunter II

Hey, I recently tried the wrapper with Deer Hunter II and the game itself runs buttery smooth except the menu and user Interface colors are all messed up. As you can see the initial title screen (except for the cursor) and the actual ingame environments look fine but the rest seems to have some kind of pallette problem...
Happens with the latest experimental release as well as the stable ones. I'm running the game on a laptop with Intel HD Graphics.
I'm really enjoying your work, it'd be great if you could take a look at it :)

I can reproduce the problem with the Demo version, but only in Software Renderer mode. You should try playing the game with the hardware renderer while I investigate and try to fix it.
I'm not sure if the full version is set up the same way, but in the demo you can run DH2Config.exe, click "Advanced Configuration Options", "Graphics" tab, and change "Software Rendering" to "display" (or whatever else is there) to enable hardware rendering. It uses 16 bit color instead of 8 bit so it doesn't have any palette issues.

Fixed in latest experimental release.


Q: How do I activate a new journey for old users?

These questions are about a topic that I had with every email automation system:

How do I make sure that users who sign up for one of my SaaS products get a certain journey? This is easy to answer: Make the SaaS product fire a user_signed_up event and make the journey entrance trigger on that event.
But: How do I make sure that all users who signed up in the past (before the new journey even existed) also get the same journey delivered to them? They have a field in their user profile that indicates they have signed up for a certain product.

Is there a way to do the second one correctly?

Create a list that contains your existing users (could either upload manually or create a dynamic one that adds any users created before a certain date) and then add a second entrance to your journey that adds the users from that list. You can have as many entrances to a journey as you want.

Ah, thank you!
Just for clarification: Do you mean a scheduled entrance so that the system checks daily whether there are any new users that satisfy the criteria? It looks like I could let it run once and then remove the additional entrance when it has added the people to the journey, right? 👇

Correct, though definitely confusing given that currently adding from a list is mainly meant for recurring pulls. Just added an additional Once frequency to better handle situations like this. Just pick a date to run all of the users in the list through and it'll stop running that entrance after that single first time

Very cool, thank you Chris! 👍
The resulting journey diagram has simplicity and beauty. Let's keep the fingers crossed, the new "schedule once" entrances should trigger tomorrow:

"Schedule once" worked. Good!


Support for Password Hashing with Basic Authentication

The BasicAuthentication class does not work with hashed passwords. In particular, the design of checkAuth requires that the server store plaintext passwords or be able to decrypt them:
  private def checkAuth(realm: String, store: AuthenticationStore, req: Request): Task[AuthReply] = {
    req.headers.get(Authorization) match {
      case Some(Authorization(BasicCredentials(user, client_pass))) =>
        store(realm, user).map {
          case None => NeedsAuth
          case Some(server_pass) =>
            if (server_pass == client_pass) OK(user, realm)
   ...

(from BasicAuthentication.scala)
Note the test server_pass == client_pass; server_pass comes from the store function (which is fine). client_pass comes from the HTTP client, and there is no way to transform the value before comparing it to server_pass. Therefore, we cannot hash client_pass and compare it with some previously stored value (like the client's hashed, salted password).  Instead, server_pass must either be the plaintext equivalent of client_pass, which means we cannot store it as a hashed value.
I propose extending store so it takes the client_pass value and returns a value indicating if the user is authorized or not, rather than having the password comparison in this class.

Strongly agree.  I brought this up on Gitter while @reactormonk was working on #692.  Being able to recover the secret is necessary in Digest auth, but is bad practice in Basic.  These should not share the same type for the auth store.

BasicAuthentication changed quite a bit in the master branch. My PR supports the previous behavior and adds enough support that you can implement a hashed password comparison too.

#763 extends #739 and solves this.