opnode: Parameterize deposit contract address

The contract can be deployed to any address. It is set in the rollup config file.

Codecov Report

Merging #361 (e6c5376) into main (0874174) will increase coverage by 0.00%.
The diff coverage is 80.00%.

@@           Coverage Diff           @@
##             main     #361   +/-   ##
=======================================
  Coverage   56.33%   56.34%
=======================================
  Files          46       46
  Lines        4024     4027    +3
=======================================
+ Hits         2267     2269    +2
- Misses       1492     1493    +1
  Partials      265      265

Impacted Files
Coverage Δ

opnode/rollup/types.go
18.18% <0.00%> (-2.88%)
:arrow_down:

opnode/rollup/derive/payload_attributes.go
76.62% <100.00%> (+0.86%)
:arrow_up:

opnode/rollup/driver/step.go
62.37% <100.00%> (ø)

Continue to review full report at Codecov.

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


Support compiling sway-core and forc-pkg to WASM?

This is a bit of a moonshot issue and by no means a priority, but I've been meaning to open it for a while and would likely enable some pretty cool stuff (e.g. in-browser compilation, deploying from the browser, etc).
Some steps that come to mind in enabling this:

Review all I/O throughout sway-core and forc-pkg and consider browser-friendly alternatives. This would likely require support for handling in-memory representation of sway files, seeing if it's possible to compile git/ipfs deps to WASM, etc.
Add a wasm32-unknown-unknown build job to CI. Add one package at a time to avoid having to overhaul the whole repo in one PR.

 Or they support native plugins somehow?

I'm not sure just yet, @sdankel is going to look into this for the current milestone. In-browser compilation certainly sounds juicy though.

Having the same codebase/tooling work as CLI and in browser is pretty great.
We would need to first try ensure crates are no-std compliant.
This may also require a slight restructure of the project such that the CLI code (specifically clap based code) is in a seperate crate to the core lib code.
This way the libraries can transition to no-std compliancy first; then later target the WASM based target (wasm32-unknown-unknown).


Backup Captive Portal DB files. Implements #10868

[X] Redmine Issue: https://redmine.pfsense.org/issues/10868
[X] Ready for review

Backup/Restore Captive Portal DB files /var/db/captiveportal<zone>.db to keep connected users after restore (if "Preserve connected users across reboot" option is enabled)
improved #4431

generic function backup_xmldatafile and restore_xmldatafile are used
they can be used in the future to backup/restore any files (like dhcp leases)

@vktg please rebase your fork and fix conflicts

Fixed


Least common ancestor

I added the start of complex query methods from PedHunter, a basic implementation of finding least common ancestors.
I am not sure it is the best way, but it is functional. If you think it should be done better, I can do some more research. It currently only returns the ancestor, but not the path from the individuals to the least common ancestors as discussed on PedHunter. Once the path is discovered, this can also return how two individuals are related..such as "grandchild", "second-cousin", "first cousin once removed", etc.
I you would rather wait on this request until I can create a system that returns not only the ancestor but also at least the path between the two people, I can do that no problem.

Hi eric
It seems to me a good implementation but I have few things to mention before going to much further.
First of all I wouldn't add the path feature, for the moment at least. Besides being too specific, the output of the method would be inconsistent with other query methods and couldn't be chained. We can think later, if necessary, a way to have it optional.
As you can see, your code is not Rails3 compatible. I use this gem in a Rails3 project but maybe it's time to remove this compatibility..
Lastly I'm going to add some little notes directly on your changes

All good points! Completely forgot about that Rails 3 issue.
As for the 2+ and putting it on the class, I can change that. I like the thought of it being able to handle as much as possible. I can work on these changes no problem


Add CC0 license file using template

As recommended by:
https://github.com/sindresorhus/awesome/blob/main/pull_request_template.md#requirements-for-your-awesome-list
This will allow removing these awesome-lint errors:
README.md:1:1:   License was not detected by GitHub                           remark-lint:awesome-github
README.md:1:1:   Forbidden license section found                              remark-lint:awesome-license

See issue #107

LGTM.

Sorry I have not seen before. Thx! Merging.


TMPDIR redirection can cause absolute UNIX socket paths to be too long

The env TMPDIR redirection can cause absolute UNIX socket paths to be too long.
e.g.
virt-v2v-in-place -i disk disk.qcow2

[  0.0] Setting up the source: -i disk disk.qcow2
stderr:
qemu-nbd: UNIX socket path '/home/lukas/Dokumente/buck2/buck2/examples/remote_execution/test/buck-out/v2/tmp/root/524f8da68ea2a374/vm/__WinDevEval_VirtIO__/genrule/v2v.xUoDfB/in0' is too long
Path must be less than 108 bytes
virt-v2v-in-place: error: qemu-nbd did not start up. There may be errors printed by qemu-nbd above.

For now I am resetting TMPDIR back to /tmp/ from the genrule cmd.
Bazel reverted similar changes because of the socket path length problem. (TMPDIR is set there to /tmp/).

The reason for setting TMPDIR is otherwise some actions tend to behave poorly when running in parallel, or behave non-deterministically when running in parallel. I guess https://github.com/bazelbuild/bazel/issues/11089 is the Bazel issue? FWIW, Buck2 always creates its UNIX sockets in HOMEDIR, because of this very problem.


Add a Runtime configuration where underlying types are abstracted

This depends on:

#204

The Runtime configuration should abstract:

timing
async executor
synchronization primitives
...

This will allow addressing further stuff, especially making tests deterministic (and fast).

I grepped the tokio usage in openraft. Here the traits and packages used that need to be possibly abstracted:
tokio::io::AsyncRead
tokio::io::AsyncReadExt
tokio::io::AsyncSeek
tokio::io::AsyncSeekExt
tokio::io::AsyncWrite
tokio::io::AsyncWriteExt
tokio::runtime::Runtime
tokio::runtime::Runtime::new
tokio::select
tokio::spawn
tokio::sync::Mutex
tokio::sync::RwLock
tokio::sync::broadcast
tokio::sync::mpsc
tokio::sync::oneshot
tokio::sync::watch
tokio::task::JoinError
tokio::task::JoinHandle
tokio::test
tokio::time::Duration
tokio::time::Instant
tokio::time::Interval
tokio::time::interval
tokio::time::sleep
tokio::time::sleep_until
tokio::time::timeout

Likely the Async* trait won't need an abstraction. The rest should be pretty straightforward to abstract for the test runtime with simulated time.

The list can be reduced:

tokio::Runtime seems to be only used in tests.
tokio::time::Duration and other time-related types are just re-export.
tokio::sync::Mutex can be just replaced with std::sync::Mutex. They do not live across any await.

Maybe I should get rid of some tokio dependency while you are building up the runtime:)


Moved duplicated IPlaylistItem attributes to the root interface

It always annoyed me that ever since Podcasts were added, I had to manually cast the IPlaylistItems to either Track or Episode. Even when all I needed was, for example, the ID, which is one of many attributes both Episode and Track share.
This change simply adds the shared attributes to the root interface. Some inconsistencies have been renamed as a result (such as Tracks calling it getIsExplicit while Episodes call it getExplicit).

Codecov Report

Merging #233 (0b40efb) into master (0cbc01a) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master     #233      +/-   ##
============================================
- Coverage     65.19%   65.17%   -0.02%
  Complexity      612      612
============================================
  Files           174      174
  Lines          6754     6756       +2
  Branches       1170     1170
============================================
  Hits           4403     4403
- Misses         1384     1386       +2
  Partials        967      967

Impacted Files
Coverage Δ
Complexity Δ

...n/java/com/wrapper/spotify/SpotifyHttpManager.java
26.84% <0.00%> (-0.37%)
3.00 <0.00> (ø)

...r/spotify/model_objects/specification/Episode.java
75.60% <ø> (ø)
19.00 <0.00> (ø)

...per/spotify/model_objects/specification/Track.java
76.74% <ø> (ø)
17.00 <0.00> (ø)

Continue to review full report at Codecov.

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

Thank you for your contribution! This was already discussed. See https://github.com/thelinmichael/spotify-web-api-java/issues/213 and https://github.com/thelinmichael/spotify-web-api-java/pull/214. Please direct your naming suggestions to Spotify too :)
Thanks again.

If the renaming of method is your concern then I'd be happy to put those back into their individual classes. Really, all I'm asking for is to have getId() in the interface, the rest is just a bonus.

Go for it ;)

There, now it's just the methods that are exactly identical in both Episodes and Tracks. Of course, this is a design philosophy question, but I feel like Spotify slipped up here. There's no reason why they would call it stuff like audioPreviewUrl and also previewUrl, other than somebody doing an oopsie somewhere down the line.
Oh well, IT.


iOS catch exception for unknown keys from hardware keyboard

I have this crash in my logs:
java.lang.IllegalArgumentException: No constant with value 669 (0x29d) found in org.robovm.apple.uikit.UIKeyboardHIDUsage
	at org.robovm.rt.bro.ValuedEnum$AsLongMarshaler.toObject(ValuedEnum.java:142)
	at org.robovm.rt.bro.ValuedEnum$AsMachineSizedSIntMarshaler.toObject(ValuedEnum.java:158)
	at org.robovm.apple.uikit.UIKey.$m$keyCode(Native Method)
	at org.robovm.apple.uikit.UIKey.getKeyCode(UIKey.java)
	at com.badlogic.gdx.backends.iosrobovm.DefaultIOSInput.onKey(DefaultIOSInput.java:660)

A UIKeyboardHIDUsage with value 669 is currently not present in RoboVM bindings. Even if it is added, the IllegalArgumentException might be thrown when Apple adds another newly supported key and the game is compiled with a RoboVM version still not knowing it. To avoid crashes, this PR catches the thrown exception and maps to Keys.UNKNOWN instead.

LGTM.
As discussed, the constant is missing on the Apple class itself (https://developer.apple.com/documentation/uikit/uikeyboardhidusage) so I would make sure with MobiVM guys in Gitter the bindings are correct or if it would make sense to change them so that UIKey.getKeyCode returns a number instead.


[STYLE] Normalized column doesn't seem right when aggregating by squares/hexabins

When trying to style by the normalized resulting column it looks like every polygon has very similar values so it looks like the normalization is not being done correctly.

what dataset are you using?

Try with populated places for example
On Jun 21, 2016 8:56 PM, "javi santana"<EMAIL_ADDRESS>wrote:

what dataset are you using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/CartoDB/cartodb/issues/8029#issuecomment-227537402,
or mute the thread
https://github.com/notifications/unsubscribe/AAIENdyLMSqrX0zBSAqnz8XWiuL-aP8-ks5qODPzgaJpZM4I7AVI
.


Release v1.0.1

cache Laravel version check for 1 hour

looks like this project is abandoned
will continue a fork, happy to merge if needed


Write Question 6

There's a noise in the shed. Hide behind chainsaws? If no: continue. The noise was a little black kitten! If yes: -1 heart.

"You unlock the shed and enter. Upon entering you hear a scraping noise. You quickly look around and see a row of dangling chainsaws. What do you do?
Hide behind the chainsaws -1 heart (it was a kitten ya dummy)
Stand your ground (kitten comes out, proceed to search shed prompt)
/// Flee in terror (restart)


User Groups screen, not showing any Groups

Row count suggests 19 rows, but nothing showing

was data error


add flag: --iree-llvmcpu-link-ukernel-bitcode, default true

@lundong reports that linking to ukernels code as a system plugin (.so) is broken since we added ukernels bitcode, relying on overridable generic weak symbols being linked last, so that the non-weak optimized implementations actually override them. There's no easy fix and no great alternative to weak symbols for what we're doing here, but this flag should unblock this use case...

This currently fails with
lld: error: undefined symbol: iree_uk_mmt4d

How do we tell the compiler that it's OK that ukernel target functions are not defined / treat them as external?

@benvanik @MaheshRavishankar  Can you please kindly review this change? We would need this PR merged to unlock our work.
@hcindyl

(I understand we have done that, but if we're hitting issues we should look to unwind some of that instead of adding more flags/bandaids - I just can't clearly see it today)

Sure - not sure though how the diff ended up obscuring that, but the intent of this PR was "here is something that we're currently doing unconditionally, provide a flag to opt out of it".

Took a while to get all of this back in cache. This is fine for now, but one fix might be that we first link the user-provided bit code file when the flag is specified, and after that look for undefined functions to link from the bit code file. I need to look again, but some LLVM linking flavor should already give us this.

The problem here is that @lundong is relying on runtime-provided system-plugin (.so) providing ukernel symbol definitions --- not bitcode. Because it's at runtime, it can't implicitly influence what the compiler does, so we need some explicit compiler flag to at least say that it's OK to have undefined symbol references.

@lundong notice the renamed flag (see PR title)

A follow-up on this issue:
This PR itself is good, and it did resolve the problem and re-enable the plugin ukernel path when I wrote my last comment two weeks ago.
However, a newer commit broke it again, and the plugin ukernel at ToT is still not working. I was able to nail it down to the specific commit caused the problem: https://github.com/openxla/iree/commit/41a23ade9c5857ec56a70e3cb907ffaa9feb6c5e
@bjacob Can you please help resolve this bug? Thank you.

@lundong sorry that it's broken again and thanks for bisecting it.  I won't have cycles to debug this. I just took a cursory look at the diff in this commit now, and it's not clear to me why it would break this (though it clearly is related). I suspect that having bisected that already, you should be most of the way already to debugging this, so perhaps you can suggest a fix and we can discuss from there.

Sure, I am happy to share more findings based on my own experiments.
Recall that I am compiling targets on riscv32 backend. This issue appears to be related to recent changes on function "enumerateMatmulTileMxNxK" in compiler/src/iree/compiler/Codegen/Common/CPU/CPUMaterializeEncodingPass.cpp.
It starts in https://github.com/openxla/iree/commit/41a23ade9c5857ec56a70e3cb907ffaa9feb6c5e. In that commit, the function enumerateMatmulTileMxNxK returns empty for riscv target, which caused the aforementioned problem. If we return enumerateMatmulTilesGeneric for riscv target, the problem will be gone.
More recently, those piece of code changes on https://github.com/openxla/iree/commit/41a23ade9c5857ec56a70e3cb907ffaa9feb6c5e was replaced by https://github.com/bjacob/iree/commit/e604f9d5f7075545b5e1b1aaa3cadaddd9eecb64. And the problem remains similar: enumerateMatmulTileMxNxK returns empty for all targets other than VMVX, Arch64 and x64.
A workaound/Fix: if we revert the change for enumerateMatmulTilesGeneric in https://github.com/bjacob/iree/commit/e604f9d5f7075545b5e1b1aaa3cadaddd9eecb64, and allow enumerateMatmulTileMxNxK to return enumerateMatmulTilesGeneric for targets other than VMVX, Arch64 and x64, the problem (for plugin ukernel) will be gone. Note that I have not tested whether this would break other things.

@lundong : thanks for the explanation, I get it now.
What https://github.com/openxla/iree/pull/15450 and https://github.com/openxla/iree/pull/15469 did was an important step forward in the design of data-tiling. Before these PRs, we used to unconditionally data-tile even when we didn't know a particularly meaningful tile size for the target, resulting in mediocre performance in these cases. With these new PRs, we are now simply falling back to non-data-tiling when we don't know a useful data-tile size.
The link with microkernels is indirect: it is that we only have a microkernel lowering for data-tiled matmuls ("mmt4d"), so falling back to non-data-tiling also implies falling back to non-microkernel.
Thanks to your explanation, I now understand that this is a regression for your use case, either because the generic (M0=8, N0=8, K0=4) tile size was good enough on your target, or because you perhaps had local patches changing it to fit your target (?)
Either way, the right way to fix this is to edit this CPUMaterializeEncodingPass.cpp file to have a enumerateMatmulTileRiscV32 function, similar to the existing enumerateMatmulTileArm64 and enumerateMatmulTileX86_64, selecting the right tile size for your target. If really the existing generic tile size fallback {8, 8, 4} was what you wanted, you could simply let it return that. In general though, it would check for hasFeature(target, "+xyz") for some RISC-V CPU features +xyz relevant to matmul arithmetic that you want to use in kernels -- like the existing arm64 and x86_64 functions. Let me know if you would like a 30 min meeting to discuss how to decide some meaningful tile shapes based on your ISA spec, if that's public.
If your target isn't publicly documented and you don't want to leak information, then you could either have your own private fork of IREE with that logic in local patches to CPUMaterializeEncodingPass.cpp, or if you don't want to fork, we could potentially discuss extensibility-from-outside hooks around here.


Add WSGI helper methods

Hi,
I tried to integrate the library with flask. It's easy but I had to go through the source code to find out what to do.
With this helper classes I hope to make it even easier for others. Someone can then just create a flask WSGI app and a Prometheus WSGI app and can do the routing in a third app.
Maybe another helper method for that might be nice too?

Could you add a short example to the README?

Added an example to the README

Thanks!


Apply feedback from Reza to aks model in image sample

Supersedes #4621 .

Add step to login OCR.
Create required variables.
Update mii sample directory.
Update WKO version to 4.1.7.

Commits have been copied and merged by Oracle staff, per Oracle open source policy.

Content is live at https://oracle.github.io/weblogic-kubernetes-operator/samples/azure-kubernetes-service/model-in-image/


Request for node v10 Support

Unfortunately this beloved piece of software can't be build with node v10.
I know it hangs on wiringpi-node but this is unmaintained since more than 2 years an so i have more hope that you are able to find a other solution.

Don't hesitate to propose a wiring wrapper under node 10.
Thanks to your contribution.

You can try with the latest version 0.2.5. Works fine under node 10.
You'll have to install wiringPi first. Please have a look to the README to do that.


RecursiveDriftAnalysis - follow up of train_test_split: help to detect the drift on a dataset

Is your feature request related to a problem? Please describe.
As a Data Scientist, I want to know if there is drift in my dataset, and on which columns.
I want to be able to precise on which column the dataset should be read (index? one column in particular?).
Describe the solution you'd like
We could use the solution described in https://github.com/probabl-ai/skore/issues/498, but I think it actually requires more user & market research before that.
Describe alternatives you've considered, if relevant
No response
Additional context
No response

@Vincent-Maladiere convinced us that this is too advanced for now.


fix: isRequired flag for object schemas

Currently required properties are treated as non-required and vice
verca. This PR fixes the behavior.

Sorry I didn't see your PR before fixing few issues, I've fixed here https://github.com/Eywek/oatyp/commit/a24b8b0c2b7d03dc7e679df39cc578e9ce556197.
Thank you


Allow protected members to be accessed within the enclosing class

fixes https://github.com/microsoft/TypeScript/issues/59989

@typescript-bot test it

In a way this feels wrong; I remember on my first checker bugfix that we didn't want to let one spread out private props which feels similar: https://github.com/microsoft/TypeScript/pull/47078#issuecomment-990132945
But, allowing private and not protected seems the oddest of all.

Honestly, I don't really know what are the expectations around private/protected when it comes to closures etc. Private properties are allowed in those positions quite explicitly by the code (and IIRC there are tests for it) so this merely matches the behavior of protected properties with that.
I don't feel anything in the linked comment says strongly this might be wrong:

access to private/protected members is only supposed to be allowed through references of the actual class type from within the class

Those references to this class here are within the class ;p I feel like the linked comment is mainly about object types created by spreads than about other cases like this here.


Allow user to add github team

Closes #226
This allows the user to add a github team in addition to or instead of the existing members and include_repos settings.
I'm planning to follow this up later with a PR adding the forms team to the config, which should make it a bit clearer how this works, but also hoping my documentation changes here are clear enough.

Thanks @ChrisBAshton - good suggestions! I've made those changes now 🙂

Thanks again @ChrisBAshton - I'm afraid I can't merge as I don't have write permissions, please could you do the honours?


Certbot or Lets Encrypt Checkbox in Endpoint Setup

Certbot or Lets Encrypt Checkbox in Endpoint Setup

Can you please elaborate more on how you want to use Lets Encrypt within endpoint creation in Portainer?


Implement Pooch data manager

https://github.com/lincc-frameworks/tdastro/pull/52#discussion_r1700194248

I don't think this should ultimately, be located in the same directory as passbands.py. As part of a later change, we should set up a cached data directory and use that for all the data.


pnpm/action-setup doesn't work with private registry

I'm not sure, if it is a problem with this github action, but somehow my environment variables are ignored, if i use this action. If i install pnpm via npm, it works.
Example of action that is not working:
     - name: Setup PNPM
        uses: pnpm/action-setup@v2
        with:
          version: 7

      - name: Setup NodeJS
        uses: actions/setup-node@v2
        with:
          node-version: 16

      - name: Setup private registry
        run: |
          echo "NPM_CONFIG_//npm.my-company.io/:_authToken=${{ secrets.AUTH_TOKEN}}" >> $GITHUB_ENV

      - name: Install Dependencies
        env:
          NPM_CONFIG_@my-company:registry: 'https://npm.my-company.io'
        run: pnpm install

Result:
ERR_PNPM_FETCH_404  GET<EMAIL_ADDRESS>Not Found - 404
So pnpm is not using the private registry, like ignoring the env config.
But if I run the following code without the action-setup, it works:
      - name: Setup NodeJS
        uses: actions/setup-node@v2
        with:
          node-version: 16

      - name: Setup private registry
        run: |
          echo "NPM_CONFIG_//npm.my-company.io/:_authToken=${{ secrets.AUTH_TOKEN}}" >> $GITHUB_ENV
          npm install -g pnpm@7

      - name: Install Dependencies
        env:
          NPM_CONFIG_@my-company:registry: 'https://npm.my-company.io'
        run: pnpm install

any resolution on this?

up

on Setup NodeJS I added the secrets.PAT and works.
Also my .npmrc has the registry @my-company:registry=https://npm.pkg.github.com
- name: Setup Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '14'
        registry-url: 'https://npm.pkg.github.com'
        check-latest: true
      env:
        NODE_AUTH_TOKEN: ${{ secrets.PAT }}


Unable to put the debugger statement inside the gruntfile.js and socket.io.js.

using grunt debug
this is the error that i am getting
E:\akshay\torrent\Architecture of the MEAN Stack (OReilly 2015)\yo mean\final\fnl\config\lib\socket.
io.js
  18:3  warning  Unexpected 'debugger' statement  no-debugger

? 2 problems (0 errors, 2 warnings)

Running "csslint:all" (csslint) task
>> 3 files lint free.

Running "mkdir:upload" task

Running "copy:localConfig" (copy) task

Running "concurrent:debug" (concurrent) task
    Running "watch" task
    Waiting...
    Running "node-inspector:custom" (node-inspector) task
    Running "nodemon:dev" (nodemon) task
    [nodemon] 1.10.2
    [nodemon] to restart at any time, enter `rs`
    [nodemon] watching: gruntfile.js modules/*/server/views/*.html server.js config/**/*.js modules/
*/server/**/*.js modules/*/server/config/*.js
    [nodemon] starting `node --debug server.js`
    Debugger listening on port 5858
    Node Inspector v0.12.8

    Visit http://localhost:1337/?port=5858 to start debugging.
    >> File "config\lib\socket.io.js" changed.
    Running "eslint:target" (eslint) task
Terminate batch job (Y/N)? y

Is there any other way that i can use breakpoints in these files ?

@Ankur-Marwaha can you please test Gulp instead of Grunt?
We intend to deprecate Grunt pretty soon and it will no longer be part of the project anymore.

Closing as this is almost a year old and Grunt has already been removed from meanjs.


Remove some unused code

@OpenPoGo/maintainers

:+1:

Current coverage is 37.00% (diff: 100%)

Merging #280 into master will decrease coverage by 1.53%

@@             master       #280   diff @@
==========================================
  Files            30         30
  Lines          1391       1427    +36
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits            536        528     -8
- Misses          855        899    +44
  Partials          0          0

Powered by Codecov. Last update 5c681f0...831b764

👍


Can I keep consecutive "-" symbol?

>>> s
'=--comfy-children-s-adult-diaper-skirt-shorts-2-in-1'

>>> slugify(s)
'comfy-children-s-adult-diaper-skirt-shorts-2-in-1'

>>> slugify(s, regex_pattern = r'[^-=a-z0-9_]+')
'=-comfy-children-s-adult-diaper-skirt-shorts-2-in-1'

Some of the content is already slugified, I wanna keep it untouched.

Sorry to bother you. Seems consecutive "-" symbols are invalid in URL in my app.


[BUG] build_ranged providing unexpected results.

The selection of the range in the build_ranged method seems to be changing the values I'm plotting. The next two plots use identical data but simply use different ranges for the chart. Both plot two lines, one from (0,100) to (100,0) in blue, and one from (0,10) to (0,100) in red.
The first chart uses a y-axis 0-100, and the second 0-10. For some reason the plot lines in the second chart align exactly, even though they are using completely different values. This only occurs when setting a range smaller than the given data, not when setting one larger than the data. For example a y-axis of 0-200 works as expected.

Here is the code for production of the charts above:
use plotters::prelude::*;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let root = BitMapBackend::new("plot.png", (640, 480)).into_drawing_area();
    root.fill(&WHITE)?;
    let mut chart = ChartBuilder::on(&root)
        .caption("Test Plot", ("Arial", 16).into_font())
        .margin(15)
        .x_label_area_size(50)
        .y_label_area_size(60)
        .build_ranged(0_f32..100.0_f32, 0_f32..200.0_f32)?;

    chart
        .configure_mesh()
        .x_desc("X Values")
        .y_desc("Y Values")
        .draw()?;

    let data_points: Vec<(f32, f32)> = vec![(0.0_f32, 100.0_f32), (100.0_f32, 0.0_f32)];
    chart.draw_series(LineSeries::new(data_points.into_iter(), &BLUE))?;

    let data_points2: Vec<(f32, f32)> = vec![(0.0_f32, 10.0_f32), (100.0_f32, 0.0_f32)];
    chart.draw_series(LineSeries::new(data_points2.into_iter(), &RED))?;

    chart
        .configure_series_labels()
        .background_style(&WHITE.mix(0.8))
        .border_style(&BLACK)
        .margin(20)
        .draw()?;
    Ok(())
}

This occurs both with the current version on crates.io as well as git master.

This plot may be informative too:

The plot uses the following data:
let data_points: Vec<(f32, f32)> = vec![(0.0_f32, 100.0_f32), (50.0_f32, 50.0_f32), (100.0_f32, 0.0_f32)];
chart.draw_series(LineSeries::new(data_points.into_iter(), &BLUE))?;

let data_points2: Vec<(f32, f32)> = vec![(0.0_f32, 10.0_f32), (50.0_f32, 5.0_f32), (100.0_f32, 0.0_f32)];
chart.draw_series(LineSeries::new(data_points2.into_iter(), &RED))?;

Here there are three points for each line. This indicates that all of the points with y-coordinates that lie outside the range are having their coordinates clamped to the limits of the range.

The issue seems to be the call to truncate here:
/// Draw an high-level element
pub fn draw<'a, E>(&self, element: &'a E) -> Result<(), DrawingAreaError<DB>>
where
    &'a E: PointCollection<'a, CT::From>,
    E: Drawable<DB>,
{
    let backend_coords = element.point_iter().into_iter().map(|p| {
        let b = p.borrow();
        self.rect.truncate(self.coord.translate(b))
    });
    self.backend_ops(move |b| element.draw(backend_coords, b, self.dim_in_pixel()))
}

which clamps the coordinate the element is drawn at to the drawing area.
Removing the truncate fixes the wrong behaviour, but instead draws points and lines outside of the actual plotting area, into the label margins (and possibly all kinds of other unwanted behaviour where DrawingArea's are used).
I guess what should happen instead is that elements outside of the area either don't get drawn at all, or (better) some kind of transparency mask is applied to them to cut them off at the edge of the drawing area. I'm not sure how doable that is across backends, though.
Alternatively, have the ChartContext filter out points and modify lines so they end at the borders of the drawing area. Line caps wouldn't be neat, but that's a much smaller problem than the clamping happening now.

Yep, this behavior is pretty much from the beginning of this project.
One of the reason for not removing this silently is some of the element assume exact number of vertices, which means drop the out of range vertices may not be the right thing to do. I believe having a mask API would be the best way to handle this case in my opinion, but this requires some amount of work.
But actually I think it's more practical fix is handling the out of range data points in the data series. Actually this is why I use truncate at that point, since I once thought the data series is always responsible for validating the data inputs.
Thus, I think the potential would be having a line cap algorithm in LineSeries type https://github.com/38/plotters/blob/b8d115dcf8d0f269de3ebdb56a32b68b5d192895/src/series/line_series.rs#L18. Thoughts?

For my own app I've now implementing a filtering step that removes points entirely for data sent to a PointSeries and for LineSeries splits the data into several lines when it crosses the range bounds, which end exactly at the edge of the range. This was more complicated that I anticipated, and involves an allocation each time a line crosses the range edge.
Making the series types handle this kind of filtering themselves would work, but of course they'd have to know about the ranges (which could probably be taken care of by the ChartContext before the iterator is used). The LineSeries could then just create one PathElement for each visible part of the line as it's iterated over, truncating the paths correctly as it generates them.
Conceptually, however, it feels wrong that the series types have to filter their data to avoid the drawing area messing with it. I feel like it should be the DrawingArea's job to correctly deal with things being drawn (fully or partially) outside of its bounds.
So the most natural (and probably most performant) solution would be to not worry about filtering the data, but to apply a mask for the actual plotting area via the DrawingArea and have the backend sort it out. Unfortunately, this is also the solution involving the most work, as you mentioned.

That's more or less the same conclusion I came to. There are two ways to approach it:

Modify the data series or elements to fit the chart.
Apply clipping in the backend.

I'm a big advocate for the second option, if for nothing else it means implementing it per-backend rather than per-element-type, which reduces the burden on creating new types of chart. Also @Irockasingranite mentioned, modifying the data means calculating intersections and inserting new points. This can get complicated and involve a huger number of edge cases. More importantly, it's different for every element type. There is also the risk of getting misleading results if we modify the data.
For example, if we modified the data:

With simple unconnected point data, we would want to truncate points outside the range. This would be fine.
For line series we would want to add new data points at the intersection of the line and the chart boundary, and also split the line series into chunks so that we don't connect the disparate sections.
For area series we would need to do the same thing line that edges the area, but not the area itself. I don't think area does any clipping at the moment.

We don't want the dark red line in the image below.

We want it to look like this. This means the line has different clipping logic from the shading.

This is a whole lot of clipping logic that could get more and more complex, particularly if we want it to look good. One of the advantages I see in plotters is that you can create fairly aribitrary charts (e.g. the mandelbrot set in the examples). We lose a bit of this flexibility if we have to design new clipping algorithms for each type.
It also allows us to take advantage of the characteristics of each backend. For example, we might want to take advantage of SVG's clipping ability (or not).
I do believe clipping the chart area as it is drawn to be the cleaner abstraction for sure. At first I thought it might be more work to implement, but after considering the implications for different chart types, I'm nearly certain that isn't the case.
The only disdvantage of this solution is that if you were to draw millions of points outside the chart area it might be more efficient to filter the data first, but I don't think this is unreasonable. Users would expect that the rendering cost increases as the number of elements increases, and they always have the option to filter the data themselves first if they have a particularly pathological case.
In my hacky workaround I just commented out that code and use SVG clipping manually.

My biggest concern about having a transparent mask is performance of BitMapBackend, since there's a lot of buffer manipulation code for performance purpose. (And we are actually several times faster than using the image crate to manipulate a bitmap) We need to figure out how to avoid most of the performance penalty - I mean although the performance isn't always a concern, but this is really a big deal when we have an app runs on a mobile device, such as a raspberry pi.
Actually I agree with you guys. I believe this truncate behavior is one of the worst hack in Plotters today. I definitely wants to get rid of it and I like the drawing area clamps the out-of-range pixels. In fact I am working on a 0.3 major release now, which means if we have this done, we can get all these changes could ship with 0.3 release. And I think we are in a good window now.
Combines all those thoughts, I would like to suggest a compromise solution, that introduces an optional clamping flag. If anyone who cares the performance can turn clamping off (And I actually want to leave clamping on by default). And what they could do is 1. fix the data before sending to plotters and 2. turn off clamping.
Really appreciate those thoughts, and please let me know if you guys have any thoughts.
Thank you guys so much!

I hadn't even considered that every shape would need its own workaround. In light of that, I definitely agree with @JakeOShannessy that having the area do the clipping is actually less effort in the long run.
If performance for the bitmap backend is a concern, I would leave the fast clamping behaviour as an opt-in mode for when performance matters, but I would use the proper clipping by default. It's the expected behaviour and shouldn't be much of a performance issue with most backends if the mask is applied correctly (i.e. once for the whole area, not one for each element).

I agree, and would go as far as to say that the act of clipping (especially rectilinearly) is very cheap. There will be bounds checks on the memory buffer when doing bitmap manipulation, so the clipping itself would be free if implemented well. The only exception would be if you had a large number of complex shapes outside the chart area, in which case it would be cheaper not to rasterise them at all. But we could event implement some primitive data filtering by not rasterizing and elements (e.g. line segments) that clearly fall outside the chart area (the pixel level clipping would deal with overlapping elements).
@38 thanks for looking into it. I'm interested that you prefer the clamping behaviour. What's the benefit? It truly hadn't considered that there might be a use case for it, so I'm curious as to how you're taking advantage of it. It seems like it's an ability that needs to be maintained.
Also, just to clarify, I don't think we need to use any transparent masks (where we need to do colour blending etc.) just straight up clipping (in this case a couple of integer comparisons).
I might need to implement something in the short-term for some projects just sticking with simple clipping, so we might event be able to compare some different techniques with benchmarks and pros/cons.

Opps, I am sorry. I think I have just made some confusing use of clipping vs clamping.
To clarify, my idea on this issue is:

(a) If performance isn't a problem, dropping all pixels that out of area is ideal behavior (I agree with both of you guys)
(b) If performance is a concern, even a integer comparison may cause an observable perf regression - Making series do not emit out-of-range elements would be the cheapest choice

But I don't think we are going to alter behavior of elements - And in approach (b) it's the series iterator rather than element take care of the issue. And I believe someone intentionally draws some elements out of the drawing area and approach (b) makes this possible. This is impossible for now.
So I am suggesting to have both and (a) would be default as long as quality is the more important than performance in most use cases. But for use cases power consumption is critical, they should be able to turns to use (b) method.
So my understand is I am agree with @JakeOShannessy  on the clipping behavior and @Irockasingranite  about the opt in and out ability for clipping. - Correct me if I was wrong.
Also I agree with @JakeOShannessy , alpha channels are too expensive in term of performance. Clipping is good enough, but we also needs to be very careful about the performance impact as I mentioned even a comparison may be very expensive.
If @JakeOShannessy can do some simply clipping benchmark that would be pretty awesome!

Well on the upside, it sounds like we're all one the same page!


Remove version: Jackett.Jackett version 0.20.3927

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.20.3927/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


minimum changes to make docker-running happy

Don't merge yet. Investigating alternatives.

Found cleaner solutions. no need for this now


Remove BeanFactoryPostProcessor

Injecting a container into a service is considered a bad practice, thus the BeanFactoryPostProcessor is removed. The general post processor logic is still in place, a custom BeanFactoryPostProcessor implementation can still be used.

Coverage decreased (-0.2%) to 94.268% when pulling b15ea36d54c33645b3c61d3dbfe38ed2146f04a9 on shochdoerfer:feature/remove_beanfactory_postprocessor into ae5c04bee6df6a178c2bd12d1f4097964beda7e0 on bitExpert:master.


[BUG] Performance degradation and dependency bloat

Current Behavior
We just updated to the latest version of nx-dotnet which uses dotnet list reference to get the list of project dependencies. This has the unfortunate downside of increasing the time it takes to generate the dependency graph.
It adds a dependency on dotnet to run commands like nx affected where previously there wasn't this dependency.
Every workload or CI pipeline step that needs to call these nx commands now needs to have dotnet installed on the system, and running the commands appear to take considerably longer than the prior native js version.
Expected Behavior
Performance should continuously improve with new releases, rather than getting worse.
Github Repo
No response
Steps to Reproduce

run nx affected with large monorepo using a version of nx-dotnet from before the move to depending on dotnet and compare run times with the new version.

Nx Report
n/a

nx.json
n/a

Failure Logs
No response
Additional Information
No response

Its true that the native JS version was faster, but it was also quite incomplete. Projects referenced by glob patterns inside files were missed, references coming from Directory.build.props would not be considered, etc. I don't like it getting slower either, but without getting the deps directly from .NET, its going to be a lot lot harder to have confidence in the fact that your graph is correct.
If your graph is not correct, you can easily end up not running tests on affected code, or not deploying things that need to be deployed etc.
We can't just revert that changeset back for these reasons. If you or anyone else is interested in finding a way to speed up the dotnet call execution, or can find a way to identify deps correctly without invoking .NET, I'd love to see it.

I understand the rationale and it makes sense, it's unfortunate that performance has taken a hit in the process.

references coming from Directory.build.props would not be considered

They are still not considered, unfortunately.

They are still not considered, unfortunately.

Really? That doesn't make sense as if that's the case I'd expect that they also aren't included during dotnet build.

What about invoking a .NET program that uses the official Microsoft API to read and extract included projects from all projects (EvaluatedInclude This could be significantly faster, but then a separate .NET app would have to be maintained.

I don't think this would be faster, you'd have to invoke the built all with the dotnet CLI still, and I imagine the .NET team would be better at maintaining the CLI command then anything we shipped

They are still not considered, unfortunately.

Really? That doesn't make sense as if that's the case I'd expect that they also aren't included during dotnet build.

Yes, see example here: https://github.com/mrfelton/nx-dotnet-depgraph-issue-reproducer
It seems that dotnet list reference does not consider dependencies added through Directory.Build.props

Some examples of other standalone projects that attempts to generate dependency information.

https://github.com/bjorkstromm/depends
https://github.com/phmonte/Buildalyzer
https://github.com/dswisher/dotnet-list-refs

They are still not considered, unfortunately.

Really? That doesn't make sense as if that's the case I'd expect that they also aren't included during dotnet build.

I've downloaded @mrfelton's demo repo, and I can confirm his results. The dotnet build command properly recognizes that my-third-lib is a dependency of the root my-lib, but the dotnet list reference command doesn't include it. While that may be a bug in .NET itself, it does mean the Nx graph is inaccurate in that scenario.
I'm also seeing the performance slow down in my .NET monorepo (200+ projects). I was testing Nx as a way to speed up our CI builds, but the slow read of dotnet list reference almost entirely negates the performance gains from Nx itself. At this point, I may need to downgrade to an older version of nx-dotnet that examines the csproj files directly. My repository isn't doing anything unusual with references, so the old approach still works.


Children of a template have no instance to templateInstance like in Polymer.js

This issue was originally filed by @zoechi

What steps will reproduce the problem?
1.
Run the unit test
https://github.com/PolymerLabs/polymer-selector/blob/master/test/html/polymer-selector-basic.html
and check
https://github.com/PolymerLabs/polymer-selector/blob/master/polymer-selector.html#L286
this selectedItem is div#item5.my-selected
2.
I couldn't find anything similar in PolymerDart.
3.
What is the expected output? What do you see instead?
That PolymerDart provides the same or similar functionality.
What version of the product are you using? On what operating system?
Dart VM version: 1.3.0-dev.3.2 (Mon Mar 10 10:15:05 2014) on "linux_x64"
Please provide any additional information below.

This issue has been moved to dart-lang/polymer-dart#133.


docs(upgrade): PhoneCat upgrade tutorial

For review - ping @wardbell and @PascalPrecht :)
Feel free to suggest all kinds of changes. I'm feeling particularly uncertain about the role Angular 1 TypeScript/TSD material, and would appreciate input on that.
The examples directories contain full, runnable copies of the PhoneCat app and are thus quite large.

Huge! Will have a look now.

Uhm.. just realised that the PR says that upgrade.jade doesn't have any changes?

Hmm.. I think it's just GitHub UI giving up because of all that big PhoneCat stuff. Clicking through shows the new content

Wrong repo, closing!


Rewrite publish logic

After numerous issues and reports and pain points of this publish logic, we hit a point after enabling strict versioning on the backend to discover that the original logic completely fails now.
I'll try to update this with more details with more time, but for now, here's an attempt that should resolve our woes.

Posting this feedback from the Discord thread, in case it gets lost otherwise:

ppm publish --tag isn't working with this branch:
% ~/ppm/bin/ppm publish --tag v0.3.0
A version, tag, or new package name is required

Working on master branch:
% ~/ppm/bin/ppm publish --tag v0.3.0
Publishing<EMAIL_ADDRESS>✓

Sadly it's seeming like we might not have any unit tests for this?

Speaking of which, the Discord thread: https://discord.com/channels/992103415163396136/1241217301529886853
And the start of the recent round of discussion around this topic, preceding the formal Discord thread about it by a bit: https://discord.com/channels/992103415163396136/992109539346370661/1240836443299905606

Thanks for the approval, gonna go ahead and merge this one for now, then we just gotta get it updated in pulsar sometime soon


[vue] Menu.Content generates nested div and applies attrs to both

Description
Using Menu.Content I see two nested divs generated and the attrs of the Menu.Content are applied to both. When trying to style the Menu.Content using something like tailwind css this is problematic because the styles are applied to both nested divs.
Link to Reproduction (or Detailed Explanation)
https://codesandbox.io/p/github/tve/ark-vue-dev/menu-nested-divs
Steps to Reproduce

Start the codesandbox
It should build ark-ui/vue and the demo
In a terminal, cd demo; pnpm run dev
Refresh the preview and click the menu button
Observe the double border (the inner may be white instead of red due to focus)

Ark UI Version
main branch https://github.com/chakra-ui/ark/commit/ebc00f3c8b96c38ccff6e5862722f19b5f6e35a0
Framework

[ ] React
[ ] Solid
[X] Vue

Browser
No response
Additional Information
Here's the html/css, notice the class menu-content on the Menu.Content:

Here's what it looks like, notice the double red border due to the two nested divs:

Here's the DOM, notice the two nested divs with class="menu-content"

Your testing branch is behind our main branch. The data-scope="presence" should not be existing there for now. It was changed in #1943.
Please sync and check again

Oops. Checking...

It's interesting to see I accidentally fixed an unknown bug 😅


install script does not download plex binary for darwin chip architecture i386

Running install command on 2020 macbook air with i386 chip ( echo $(arch) ) downloads tools, testdata and config folders but not plex binary. This is due to downloadPlex in install.sh
downloadPlex() {
    if [[ ! -x plex ]]; then
        echo "Downloading Plex..."
        setOSandArch

        LATEST_RELEASE=$(curl -s https://api.github.com/repos/labdao/plex/releases/latest | grep '"tag_name":' | sed -E 's/.*"([^"]+)".*/\1/')
        RELEASE_WITHOUT_V=${LATEST_RELEASE#v}

        if [ "$OS" = "darwin" ]
        then
            if [ "$ARCH" = "amd64" ] || [ "$ARCH" = "x86_64" ]
            then
                curl -sSL https://github.com/labdao/plex/releases/download/$LATEST_RELEASE/plex_${RELEASE_WITHOUT_V}_darwin_amd64.tar.gz | tar xvz
            elif [ "$ARCH" = "arm64" ]
            then
                curl -sSL https://github.com/labdao/plex/releases/download/$LATEST_RELEASE/plex_${RELEASE_WITHOUT_V}_darwin_arm64.tar.gz | tar xvz
            else

                # this is triggering because we don't check for i386 arch
                echo "Cannot install Plex. Unsupported architecture for Darwin OS: $ARCH"
            fi

            ...
}

Solved with #367


[Feature Request] Configurable time window before triggering an alert

It'd be nice to be able to say 'trigger if cpu usage exceeds x% for y seconds' rather than it be an immediate trigger.
Locally this is causing a LOT of flapping notifications because I do backups compressed with xz, and use all the cpu cores which results in 100% usage but only for ~30 seconds to a minute, but that's still enough to trigger the notifications.
It'd be nice to be able to tweak the sensitivity of the notifications to not immediately trigger because CPU spikes are an expected part of a lot of workloads.

See #93
Rather than 'x above y for z seconds,' it will need to be based on average utilization.
Right now it's calculated by one minute average. I should be able to add 10m, 20m, and 2h options. Or possibly just any round value between 1m and 60m.
This is behind some other things currently so I probably won't get to it until next month at the earliest.


Features/java did web

New added:

Create Wallet, Get wallet by BPN, List wallet API
Jacoco setup
Key generation using bouncycastle
name column added in wallet table
active and authority column removed from wallet table

Known issue:

DidDocument to JSON is missing from ssi-lib, so storing dummy data
Valut integration is missing, so storing keys in the database with encryption.

Quality regulations to follow:
https://eclipse-tractusx.github.io/docs/release
First feedback, IMHO:

too few tests & especially unit tests are missing --> even in your repository there are none. In worst case, tests for everything you program now will have to be added later by you then
no information about test coverage >= 80% --> or shall I checkout your code, build it & see if it suits

Result: Rejected.
I will not merge this due to missing tests.
Please, do:

ensure test coverage >= 80%
add unit tests.

After consulting with Max and Oliver, reponed.

Please stick to:
Quality regulations to follow:
https://eclipse-tractusx.github.io/docs/release
And please try to embrace and use:
https://www.conventionalcommits.org/en/v1.0.0/


feat: add experimental lock option with no-op default

Adds an @experimental lock option and uses it in _useSession. This can be used to test out different lock implementations before committing to a default one within this library.
It includes an implementation of a broadcastLock which can be used as a value to lock but is not done by default intentionally. This is an experimental API that is bound to have changes and potentially serious bugs. Once it has been well tested by the team and others it is likely to be promoted to the default option.
broadcastLock
Uses a BroadcastChannel to serialize access to a named critical section. The lock has three states: Acquiring, Backoff and Acquired.
When in the Acquiring state, a message is broadcast I will acquire the lock! and a timeout is started. If any message is received in this state, the lock immediately moves to the Backoff state. If no message is received, the lock moves to the Acquired state. It is assumed that if two messages are posted simultaneously at the channel, that both locks will receive the other's message.
When in the Backoff state, the lock sleeps for random amount of time before moving back in the Acquiring state. Each time it enters this state, it waits exponentially longer than the last time.
When in the Acquired state, the lock broadcasts I have the lock, please wait!. If any message is received on the channel, I have the lock! is broadcast immediately. The sender of the first I will acquire the lock! message received in this state will be sent the Go message after the operation is done which gives it priority over all other competing locks. This helps reduce the time needed for the locks to identify who should go next. Once the operation is done, the lock stops replying with I have the lock, please wait! messages on the channel.

I will actually re-open with the broadcastLock in a new PR and just the locking code here.


bundle install fails to work

Outdated version of github-pages fails to get installed on a modern version of Ruby (running on a fresh Ubuntu 17.04 system).
Gemfile.lock should be updated to the latest versions of the dependencies.

bundle install command fails because Gemfile.lock is depending on ancient version of github-pages gem (33 - January 28, 2015 (5.5 KB)). That fails to get installed on a recent version of Ruby (2.4.1).
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /home/d2s/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/json-1.8.2/ext/json/ext/generator
/home/d2s/.rbenv/versions/2.4.1/bin/ruby -r ./siteconf20170823-25526-5f87r.rb extconf.rb
creating Makefile

current directory: /home/d2s/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/json-1.8.2/ext/json/ext/generator
make "DESTDIR=" clean

current directory: /home/d2s/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/json-1.8.2/ext/json/ext/generator
make "DESTDIR="
compiling generator.c
generator.c: In function ‘generate_json’:
generator.c:867:25: error: ‘rb_cFixnum’ undeclared (first use in this function)
     } else if (klass == rb_cFixnum) {
                         ^~~~~~~~~~
generator.c:867:25: note: each undeclared identifier is reported only once for each function it appears in
generator.c:869:25: error: ‘rb_cBignum’ undeclared (first use in this function)
     } else if (klass == rb_cBignum) {
                         ^~~~~~~~~~
generator.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-self-assign’
cc1: warning: unrecognized command line option ‘-Wno-constant-logical-operand’
cc1: warning: unrecognized command line option ‘-Wno-parentheses-equality’
Makefile:241: recipe for target 'generator.o' failed
make: *** [generator.o] Error 1

make failed, exit code 2

Gem files will remain installed in /home/d2s/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/json-1.8.2 for inspection.
Results logged to
/home/d2s/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/extensions/x86_64-linux/2.4.0-static/json-1.8.2/gem_make.out

An error occurred while installing json (1.8.2), and Bundler cannot continue.
Make sure that `gem install json -v '1.8.2'` succeeds before bundling.

In Gemfile:
  github-pages was resolved to 33, which depends on
    jekyll-mentions was resolved to 0.2.1, which depends on
      html-pipeline was resolved to 1.9.0, which depends on
        activesupport was resolved to 4.2.1, which depends on
          json

Version update was merged with the pull request https://github.com/dotfiles/dotfiles.github.com/pull/163 so this should be now closed.

Thanks!


Bugfix: Allow comments before module docstring noqa codes

#427 allowed for adding noqa comments to module docstrings. However, this was not respected when there where additional comments before the # noqa comment. For example:
# -*- coding: utf-8 -*-
# noqa: D400
"""No period at the end"""

This still warns about D400.
This PR fixes this, effectively by discarding leading comments.
Closes #417

[X] Add unit tests and integration tests where applicable.
[x] Add a line to the release notes (docs/release_notes.rst) under "Current Development Version".
Make sure to include the PR number after you open and get one.

@bsamseth Any updates on this? :)

@bsamseth Any updates on this? :)

I just haven't had time to prioritize this myself. You're more than welcome to add the test if you have time, otherwise, I'll get to it at some point.

@bsamseth Any updates on this? :)

I just haven't had time to prioritize this myself. You're more than welcome to add the test if you have time, otherwise, I'll get to it at some point.

Ok i will look into it. But how would I deliver my changes to this PR?
Do i need to fork your fork and then you can merge my change into your fork and then it will be delivered here?

@bsamseth Any updates on this? :)

I just haven't had time to prioritize this myself. You're more than welcome to add the test if you have time, otherwise, I'll get to it at some point.

Ok i will look into it. But how would I deliver my changes to this PR?
Do i need to fork your fork and then you can merge my change into your fork and then it will be delivered here?

You could if you prefer. I added you as a collaborator to my fork, so you can push to that fork as soon as you accept the invite. Thanks for taking the time!

see above

:tada: It only us 6 months, but it is finally in! Looking forward to integrating pydocstyle in our codebase, finally. Thanks for your time reviewing @samj1912, and thanks @Cielquan for pitching in with the tests.


The included script is added in a place where it affects my site layout

Expected Behavior
Package should not affect overall site layout
Acutal Behavior
The package adds its scripts but also modifies my layout.
Environment

PHP Version: 7.4
Laravel Version: ^7.0
LaravelCaffeine Version: 7

Stack Trace
Before

From line 369 where the end of the <main> is.
After

this should no longer be happening.


Performance optimize tests

I profiled our tests and it seems that a substantial amount of time was being spent building the test schema/schema infos for every test. So I wanted to check how much faster tests would run if we just built each schema/schema info once. Here are the results:
Current test times:
37.06 - not-slow
67.79 - total
New test times:
11.63 - not-slow
35.82 - total
This optimization does have the drawback that one test case can modify the data used by another test case. I still think it's worth it. I did want to get some other opinions though before spending any more time on this.

I profiled the code using pytest and did not find any other low-hanging performance optimization fruits other than this one.

Out of curiosity, what's the performance difference between using the exact
same schema object for all tests, vs using deepcopy to make a new one?
Hopefully deepcopy is faster than parsing and building a schema from
scratch, and I'm wondering how much that is / if it's worth considering as
an alternative.
On Sun, Jul 5, 2020, 1:07 AM pmantica1<EMAIL_ADDRESS>wrote:

I profiled the code using pytest and did not find any other low-hanging
performance optimization fruits other than this one.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kensho-technologies/graphql-compiler/pull/873#issuecomment-653843111,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAR5MSUBRJYW5VYDONUZHDLR2ADBVANCNFSM4OQWIPIQ
.

It seems that you can't deepcopy a GraphQLSchema. See https://github.com/kensho-technologies/graphql-compiler/pull/874

Another alternative that I tested was building the schema with assume_valid=True.
This reduced test times to:
24.24 seconds - not-slow
59.63 seconds - total
When doing this we have less performance benefits than we just use one copy and we lose test schema validation, which will probably help us pinpoint bug us in the future. So I still prefer the using one-copy approach. Thoughts?

I think building a schema with validation once (as a test case on its own),
and then building it without repeated validation, is a good idea we should
definitely pursue.
For using a single schema object, I'm quite a bit more wary. It's not clear
to me that the extra 10s is worth the long-term risk on our test suite.
My recommendation would be to see what's up with the deepcopy approach, and
use that to help guide our ultimate decision. If it can be rectified and
deepcopy ends up being fast, that'd be ideal. If not, perhaps we can have
Travis stay maximally conservative and rebuild the schema, and have some
flag for local tests that allows tests to use a single schema copy. I
wouldn't add either of these until we have clarity on what's up with
deepcopy and (assuming the problem can be resolved) what the performance of
deepcopy would be.
On Sun, Jul 5, 2020, 1:58 PM pmantica1<EMAIL_ADDRESS>wrote:

Another alternative that I tested was building the schema with
assume_valid=True.
This reduced test times to:
24.24 seconds - not-slow
59.63 seconds - total
When doing this we have less performance benefits than we just use one
copy and we lose test schema validation, which will probably help us
pinpoint bug us in the future. So I still prefer the using one-copy
approach. Thoughts?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kensho-technologies/graphql-compiler/pull/873#issuecomment-653919235,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAR5MSQO6OVAJFT7ODRYMZDR2C5LPANCNFSM4OQWIPIQ
.

I am going to close this PR since obi1kenobi and I agreed that it is not worth it to keep working on this. (In other words, there are items higher on the priority list).


log run time

print run time before each asset

Just adding a few more details to this request.  Basically, we want someone to know how long the socrata-dump process has been running towards the top of the "for loop" here: https://github.com/officeofperformancemanagement/socrata-dump/blob/main/socrata_dump/init.py#L67, to provide some context and give a feel to the user for how long this process is taking.


[CSL-55] Do not start alternative chain if block is already in another alternative chain

@gromak

@gromak
I decided that block shouldn't start alternative chain only if it's head of another alternative chain.


Is it possible to shifting traffic between different hosts

Describe the feature request
I created three svc for different versions:
[root@m-0 ~]# kubectl get svc -n stage
NAME          TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
details       NodePort   <IP_ADDRESS>     <none>        9080:32399/TCP   137m
productpage   NodePort   <IP_ADDRESS>    <none>        9080:31454/TCP   118m
ratings       NodePort   <IP_ADDRESS>    <none>        9080:30752/TCP   136m
reviews       NodePort   <IP_ADDRESS>      <none>        9080:30141/TCP   41m
reviews-1     NodePort   <IP_ADDRESS>    <none>        9080:32072/TCP   129m
reviews-2     NodePort   <IP_ADDRESS>    <none>        9080:32163/TCP   127m
reviews-3     NodePort   <IP_ADDRESS>   <none>        9080:30278/TCP   126m

and can I use vs like the following?
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: supposedly-pleased-stag
  namespace: notably-distinct-ocelot
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews-1.stage.svc.cluster.local
        port:
          number: 9080
      weight: 30
    - destination:
        host: reviews-2.stage.svc.cluster.local
        port:
          number: 9080
      weight: 30
    - destination:
        host: reviews-3.stage.svc.cluster.local
        port:
          number: 9080
      weight: 40

Describe alternatives you've considered
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Additional context

This should be possible.

@howardjohn thanks for your comment. can you tell me what should I do, the above rules have no effect?
if I delete the reviews svc, product page will say "Sorry, product reviews are currently unavailable for this book."

See the note in host about FQDN: https://istio.io/latest/docs/reference/config/networking/virtual-service/#VirtualService. Looks like the namespace is wrong

[root@m-0 tmp]# istioctl pc route certainly-hip-muskox-7bdbcc9c64-z6jxx.stage | grep reviews
80                                                                                reviews.notably-distinct-ocelot.svc.cluster.local             /*                     supposedly-pleased-stag.notably-distinct-ocelot
80                                                                                reviews.stage.svc.cluster.local                               /*                     reviews.stage
9080                                                                                reviews-1                                                     /*
9080                                                                                reviews-2                                                     /*
9080                                                                                reviews-3                                                     /*

Route info

I think I got it, You gave me a deeper understanding of the hosts field，thanks a lot. @howardjohn


python310Packages.async-lru: 2.0.0 -> 2.0.2

Description of changes
Diff: https://github.com/aio-libs/async-lru/compare/v2.0.0...v2.0.2

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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.05 Release Notes (or backporting 22.11 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.

Result of nixpkgs-review pr 217616 run on x86_64-linux 1

1 package failed to build:

python311Packages.pyalgotrade

8 packages built:

ioccheck
python310Packages.async-lru
python310Packages.pyalgotrade
python310Packages.tweepy
python311Packages.async-lru
python311Packages.tweepy
semiphemeral
turses


Anyone volunteering to make a new UV Unwrapper?

Godot is currently using Thekla Atlas for unwrapping UVs on mesh import. Unfortunately, this implementation is very slow and quite buggy. We need a replacement, otherwise the current light mapping workflow (which is needed for pretty graphics on low end) will continue to be a hassle.
The only other open source unwrapper is Microsoft's UVAtlas, but it's windows-only so it needs porting. Also, it does not support specifying a texel size, which makes it no so useful.
There are a few papers on implementing this algorithm:

LSCM (2002)
SLIM (2016, more modern)

Would anyone be interested in giving a try of implementing one of these algorithms in Godot, make it work with a texel size parameter, and make it as optimal as possible?

I'll have a week holiday from work. I'll give it a shot. Where can I get any help if needed? Do we have Gitter channel for GodotEngine?

IRC
chat.freenode.net
#godotengine-devel
#godotengine-doc
#godotengine

We can team up, I know the computation of injective maps quite well. I just don't really where to start within godot...

and Godot has most of the math types and container types in core:
https://github.com/godotengine/godot/tree/master/core/math
so no need to write your own

I can't find support for sparse matrix and sparse linear solver, I can
write my own in the library. Should they be kept separate?
Le ven. 22 juin 2018 à 14:30, Juan Linietsky<EMAIL_ADDRESS>a
écrit :

and Godot has most of the math types and container types in core:
https://github.com/godotengine/godot/tree/master/core/math
so no need to write your own
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19710#issuecomment-399426326,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1nWa9yCsUhw88DKmCSDefRulztz80Oks5t_ONRgaJpZM4UzCVj
.

yeah, godot only has basic linear algebra types, as sparse matrix/linear solvers are not that common or difficult to make generic. If you want to write your own for this and put it within the unwrapper code, it's fine

Well that's seam feasible. Still, I have few questions.
1)What I intent to do is create a new thirdparty lib as theakla and then
wrap it into a module as you sent? Or shoudl I develop everything inside
the module (in that case I guess I can have access to godot classes, such
as meshes)?
2)Is it ok to depend from stl, because for the sparse matrices it would
make my life easier if i can have std::vectors. If I am in the module I'll
depend on godot' vector implementation
3) I'm not sure to understand 100% the use case. Is for uv unwrapping a
single mesh or do we have also to unwrap several patches (seamless
parameterization section6 of the latest article reference you sent)?
4) YOu said Theakla was slow. What's the expected speed ? On which size of
meshes? Would you have one or two testcases (meshes)?
Thank you very much Juan and all
Le ven. 22 juin 2018 à 16:21, Juan Linietsky<EMAIL_ADDRESS>a
écrit :

yeah, godot only has basic linear algebra types, as sparse matrix/linear
solvers are not that common or difficult to make generic. If you want to
write your own for this and put it within the unwrapper code, it's fine
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19710#issuecomment-399459130,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1nWSQN_RFOblWqVlLdgeZfZUtHkvepks5t_P2AgaJpZM4UzCVj
.

For an initiative like this it might make sense to attempt to validate + profile against a large database of potential input models. One possibility is https://ten-thousand-models.appspot.com/ and another here: http://cvgl.stanford.edu/projects/objectnet3d/. The 10k dataset has many degenerate cases so it's very helpful. What these datasets lack is geometry that is more game-specific (like terrain), but likely to be used for target lightmaps.

About UVAtlas,

The only other open source unwrapper is Microsoft's UVAtlas, but it's windows-only so it needs porting. Also, it does not support specifying a texel size, which makes it no so useful.

@reduz Do you need texel size to specify padding/distance between charts ? I saw in UVAtlas.h the gutter argument for this case. I may miss something as I don't use Godot or UVAtlas :}
//  gutter - The minimum distance, in texels between two charts on the atlas.
//           this gets scaled by the width, so if gutter is 2.5, and it is
//           used on a 512x512 texture, then the minimum distance will be
//           2.5 / 512 in u-v space.

@rotoglup No.. unless there is something I misunderstood, texel size is needed to compute the actual texture size. When you call the unwrapper, you have to feed it a mesh and a texel size (in the same units as the mesh). As a result, the unwrapper needs to figure out the final texture size.
In UVAtlas, you have to supply texture size beforehand, so it's not possible. Otherwise, I'm not sure how gutter could be of use for that (without having to call unwrap twice)..

The BFF linked by @ddiakopoulos looks very promising and uses the MIT license. So it might be better to try integrating it into godot  (just a part of it) instead of reinventing the wheel.

@reduz also, the texel size is only used when generating and packing a texture. Thekla seems to be using nvidia-texture-tools for that, so it should be possible to integrate a different UV mapping algorithm with this texture packer.

I don't know if that's a problem but BFF uses Cholmod (from eigen) which is
under GPL 2.1 licence for fast performance.
Moreover it only produces conformal maps, whereas the SLIM approach can
also produce isometric map, and other different maps depending on the
choice of energy. It's still up to the community to decide what's best,
just a heads up :-)!
Le sam. 23 juin 2018 à 15:16, JFonS<EMAIL_ADDRESS>a écrit :

@reduz https://github.com/reduz also, the texel size is only used when
generating and packing a texture. Thekla seems to be using
nvidia-texture-tools for that, so it should be possible to integrate a
different UV mapping algorithm with this texture packer.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19710#issuecomment-399677836,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1nWd55S-FyPih9f7pm1SlguJrABivMks5t_j-rgaJpZM4UzCVj
.

@laverneth whathever we use needs to be MIT compatible, else it forces the whole engine to use a more restrictive license. It may seem that BFF is also restricted to manifold with no holes, which is likely a problem. From what I understand, the only two algorithms I know that actually work well are LSCM and SLIM.

Slim example is under GPLv3.. I wish people would stop using this license for academic stuf.. :(
https://github.com/MichaelRabinovich/Scalable-Locally-Injective-Mappings

Do we have access somewhere to a svd decomposition, line eigen? I need it
for decomposing the jacobian. Otherwise I will include the TNT but it will
make the module fatter...
Le 23 juin 2018 4:51 PM, "Juan Linietsky"<EMAIL_ADDRESS>a
écrit :
Slim example is under GPLv3.. I wish people would stop using this license
for academic stuf.. :(
https://github.com/MichaelRabinovich/Scalable-Locally-Injective-Mappings
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19710#issuecomment-399684063,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1nWdnVKJIsCyDR60P6QZgviWlK1c7hks5t_lYCgaJpZM4UzCVj
.

Do we have access somewhere to a svd decomposition, line eigen? I need it
for decomposing the jacobian. Otherwise I will include the TNT but it will
make the module fatter...

No, in general these are implemented per each algorithm depending on the needs. Bullet has code for this, but it's meant mostly for solving physics constraint for a 3D physics engine. Here I imagine you need it for 2D to relax the edge constraints, so i don't think it can be reused.  Worst case, does not seem like it should be too much code to copy from an existing MIT licensed library, if you need that.

The TNT has no particular license, they juste want to be credited. I will.

If any code is copied, it should be permissivelyy-licensed license with no ambiguity; please contact its author(s) to ask for permission to use the code under the MIT license.

* This software was developed at the National Institute of Standards and
* Technology (NIST) by employees of the Federal Government in the course
* of their official duties. Pursuant to title 17 Section 105 of the
* United States Code, this software is not subject to copyright protection
* and is in the public domain. NIST assumes no responsibility whatsoever for
* its use by other parties, and makes no guarantees, expressed or implied,
* about its quality, reliability, or any other characteristic.

according to the header files. I don't think anyone needs to be contacted, or legally speaking credited.

That looks like a license to me, remember a license is just some text, it doesn't actually have to be one of the know ones, eg. MIT or whatever, it just needs to be some text compatible with whatever you're using. The above seems pretty compatible

Can someone explain me when the call to thekla is effectively done? I see
it's done in the lightmap_unwrap, what should I do to trigger this
functions?
Many thanks!
Le dim. 24 juin 2018 à 07:42, Răzvan C. Rădulescu<EMAIL_ADDRESS>a écrit :

That looks like a license to me, remember a license is just some text, it
doesn't actually have to be one of the know ones, eg. MIT or whatever, it
just needs to be some text compatible with whatever you're using. The above
seems pretty compatible
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19710#issuecomment-399731234,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1nWTwkqbxCS2Y8GBYy0m1Rd71moFYPks5t_ybNgaJpZM4UzCVj
.

Here in the documentation of light mapping you can see the two use cases (manual and on import), basically the most common use case is as an import flag, but the manual method allows you to debug it more easily

sorry, forgot link - http://docs.godotengine.org/en/3.0/tutorials/3d/baked_lightmaps.html

If you want to iterate faster, remember you can run Godot editor from the command line with a test scene like:
godot -e test_unwrap.scn

What about this implementation http://alice.loria.fr/index.php/software/4-library/23-opennl.html it's under the 3-Clause BSD License, is very compact (4 files) and static linked.

I had pretty much have been facing the same dilemma for my own project. Thekla was way too crashy for my liking but UVAtlas seemed to be pretty robust but being Windows only was a bit of a downer.
UVAtlas allows you to run Partitioning and Packing as different steps. The partitioner is resolution independent and I am quite happy with its output, its the packer that needs work. As you point out it doesn't let you set a target density, but its pretty easy to compute surface area before packing and calculate your own scale to target a specific density.
The bigger problem IMHO is that the tetris-style packer does a rather poor job compared to Thekla in my experience. Leaves lots of dead space, specially when there is a large ratio between the biggest charts and smallest charts.
The other nice thing about UVAtlas is its actually under active development and tested in production.
My recommendation after taking a quick glance at feasibility is instead of forking it and porting it, someone should build a compatibility layer that re-defines the macros and types it uses so that its easy to take updates from the mainline and push changes upstream (guessing MS wouldn't take a pull request that de-microsofts it). That is my long-term plan, but not sure when I would get to it... so if someone else does it, even better! :p

@reduz may I ask what bugs are you facing with Thekla Atlas? Are you getting charts with too much distortion, or worse, that self-overlap?

I did some work removing unused code from thekla_atlas a while back here. Got it down from about 18kloc to 8kloc.

@jpcy oh wow, amazing work! definitely need to give it a check. Are you up for merging fixes? ( think i did a few to thekla that resulted in crashes in bad input geometry )

@reduz After looking through the Godot changes, I added checks for zero length edges and zero area triangles. Zero length edges were definitely causing crashes.

I have been making some progress about implementing the SLIM paper. For the
moment I'm focusing into initializing the (u,v) property by minimizing the
dirichlet energy on the surface by constraining the longest boundary loop
to be immersed one a circle. However I do have some trouble to make a
proper test. I am importing a .obj as a mesh instance but I have some
inconsistent number of vertices and faces. I was wondering if the .obj
import of godot was'nt broken OR the way I have created this file. I have
imported the stanford bunny (file format .ply) inside blender and exported
it as .obj before reimporting it. Does anyone knows anything about similar
issue?
I've checked the .obj file and the number of vertices and facets seems to
be consistent.
Cheers
Le sam. 14 juil. 2018 à 12:51, Jonathan Young<EMAIL_ADDRESS>a
écrit :

@reduz https://github.com/reduz After looking through the Godot
changes, I added checks for zero length edges and zero area triangles. Zero
length edges were definitely causing crashes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19710#issuecomment-405015381,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1nWSHZuvxvYvFCS46bwX9ft-B-4epnks5uGc0sgaJpZM4UzCVj
.

I used the default, which is "Apply Modifiers". I'll check with the
triangulate faces. Thanks! 😀
Le lun. 16 juil. 2018 à 16:26, Hugo Locurcio<EMAIL_ADDRESS>a
écrit :

Have you tried triangulating faces while exporting in Blender, either by
adding a Triangulate modifier and checking Apply Modifiers in the OBJ
export dialog, or by checking Triangulate Faces in the same dialog?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19710#issuecomment-405265338,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE1nWYR5HCH2OcnJeD5OrLrCCF1Y636jks5uHKKGgaJpZM4UzCVj
.

Hi, how is the progress on this? I used Thekla Atlas for unwrapping UVs also, but cannot bear it with the crash on bad meshes. Actually, I looked this issue about two months ago when I was trying to find an alternative, finally I decided write it on my own, I use the MPL2 licensed libigl’s parameterization implementation (ARAP and LSCM). It works well on my project.
Here is my UV unwrapping library, here is how it’s been used,
And here is the screen shoot of unwrapping:

If you are interested, I’d like to integrate it into godot.
BTW, I saw you @reduz request an alternative for cork, currently, I use CGAL, it works quite well on mesh boolean operations, but I have decided try to write it on my own also, because I cannot go with the CGAL license, here is the project, although, empty yet, because I just start it by today :-)

Wow that looks good! On my side I tried to have a look into godot' code to see what was needed to do it inside. My conclusion is the following: we need a proper mesh boundary description to initialize the mapping with the Tutte method and a proper linear solver. Both of those represent a big amount of code (in particular a good linear solver) and I doubt that the godot' community would like to see its codebase grow so much for parametrization code. However, we should ask to Juan, maybe?

Has anything changed? What is the status of this?

Thanks @laverneth for the update. And I didn't got any reply from godot since I posted here, so I don't know what's the status of this, and I am quite busy at the moment, so I am out on this issue.

Thekla Atlas was replaced by Xatlas, but I don't know any more details.

I've noticed XA_RECOMPUTE_CHARTS enabled in xatlas usually results in a lot of small and unnecessary charts. Both original and Godot's modified version suffers from this problem.
It would be great if someone could take a look and discuss ideas to improve: https://github.com/jpcy/xatlas/issues/84


libuv -- integration & planning

Node.js uses libuv to provide OS IO interop and multithreading capabilities. I want to have that!

Will fill in this issue more as I investigate further

I have added basic functionality in the form of get total and free memory

After reviewing Cloudflare Worker's security model, I wonder if I need to include the libuv event loop that Node.js has. Intention is to have a runtime that can be a drop-in for embedding JS Scripting into Java applications, so arbitrary code execution hardening is a high priority to address.


[VL] Fix VeloxStringFunctionsSuite for null input

What changes were proposed in this pull request?
@PHILO-HE  reminds me that I should disable static evaluation rules when testing null inputs. (https://github.com/oap-project/gluten/pull/985#discussion_r1111410458)
config("spark.sql.optimizer.excludedRules", ConstantFolding.ruleName + ","  +
            NullPropagation.ruleName)

After I added the conf, many ut failed, such as
select l_orderkey, md5(null) from ...

WARNING: Logging before InitGoogleLogging() is written to STDERR
Exceptions.h:68] Line: ../../velox/substrait/SubstraitParser.cpp:122, Function:parseType, Expression:  Parsing for Substrait type not supported: nothing {
}
, Source: RUNTIME, ErrorCode: NOT_IMPLEMENTED
Validation failed for expression in ProjectRel due to:Parsing for Substrait type not supported: nothing {
}

This is due to the fact that null literals in SparkSQL are parsed as NullType types.
md5(null)  =>  md5(cast(Literal(null, NullType) as BinaryType))

How was this patch tested?

Thanks for your work! Since only doc update is involved in the latest commits, no need to re-run the CI checking. Will commit the patch soon.

@PHILO-HE Thank you for review!


:Prettier make cursor history wrong when navigating with

After I run :Prettier, and then press <C-o> to navigate to the last position of cursor, it always point to the beginning of the file. It's annoying. Please fix this.

Hi @trungdq88 thanks for reporting this issue.
Will investigate this soon, otherwise feel free to submit a PR.

I wish I could, but I have no knowledge of vim script :(

I tested this issue with other similar formatting plugins and they all have similar problems. :( In the meantime will merge a PR that will at least mitigate this issue.
You will still have to do the  2 times but the first time it wont take you to the top of the file (as the current described behavior) it will instead keep you on the same place.

@trungdq88 closed this issue since at this stage I am not sure that I can edit vim jump history to delete the duplicate same line entry.
I did however merge a PR that at least makes sure that when doing a  you do not jump to the beginning of the file anymore

That's good enough for me 👍  Thanks a lot!

FYI: vim-go has format but it keeps the cursor position and history. You might take a look on how it achieves that.

@mortyccp  great finding!
managed to find where they achieve that:
https://github.com/fatih/vim-go/blob/86834ce79a00325d15a27f74733980d98ef06ad7/autoload/go/asmfmt.vim#L40
and on
https://github.com/fatih/vim-go/blob/5730b71ea57c3db0972968889a1d098139cb6031/autoload/go/fmt.vim#L53
Are examples of them deleting history, if you want to send a PR to vim-prettier you just need to adapt that similar logic to: https://github.com/prettier/vim-prettier/blob/master/autoload/prettier.vim#L176
Otherwise will see if I can squeeze sometime in to do that over the weekend

@mitermayer Sorry, I am not familiar with VimL


StaticContentConventionBuilder.AddDirectory broken in 1.0.0?

Steps to reproduce:

Added a file image.jpg to an assets folder in my project, set to CopyAlways -> copied to Debug/assets/image.jpg on build
Added the following in my bootstrapper:

protected override void ConfigureConventions(Nancy.Conventions.NancyConventions nancyConventions)
{
	base.ConfigureConventions(nancyConventions);
	nancyConventions.StaticContentsConventions.Add(Nancy.Conventions.StaticContentConventionBuilder.AddDirectory("test", "assets"));
}

Ran the project in self-hosting on port 8080
Browsed to http://localhost:8080/test/image.jpg
Neither Chrome or IE can display the result (connection reset IIRC)
Switched back to 0.23.2
Works like a charm! :)

I looked at the history of the StaticContentConventionBuilder, and it seems unchanged recently. Could the bug be somewhere else?

Sounds like #1789 which seems to have to do with the self host.

Nice catch, that's it!


Add {LevelExpr,Constraint}SetOrdProp, LevelExprSetDecide

Needed for Gallina quotation functions

What's up with
Error: Action failed with error: Error: Unable to locate executable file: cachix. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

?

Let's try again and see what happens

I've rebased, hopefully the CI passes now and this can be merged shortly

CI passes!


Fix colors in Dark mode

Pull Request Template

Please provide all of the details below. Pull requests missing any of the information below will be closed!
Providing the issue number/url helps us identify the problem being solved and keep the issues tab clean and tidy

What issue does this fix?
Fix colors for the dark mode to align with color variables
What issue is it attached to?
Fixes #372
Checklist
(Add an x between the brackets to check the items)

[ ] I have summarize what this PR fixes above
[ ] I have provided the issue ID/URL above
[ ] I have not added Bootstrap or jQuery and used correct styling guide.
[ ] This PR fixes only the issue mentioned above (create separate PRs for separate issues)
[ ] I was the first one to claim the issue or I created the issue

Looks better, remember to complete the checklist next time.


Create a contributing guideline document

Some bits to consider are:

How best to share common guidelines across the multiple toolkits.
How best to split out the toolkit specific parts (would this be best in multiple documents?)
As per this comment for the .NET MAUI Community Toolkit

it should always be .NET MAUI. Never just MAUI. Then, on first use on every page it should always be .NET Multi-platform App UI (.NET MAUI).

Other points? please feel free to comment

One good suggestion from @brminnick is to create a simple guidelines document that effectively acts as a TOC linking to the specific guidelines documents for each toolkit.
e.g.
CONTRIBUTING.md
Thank you for considering contributing....

Which toolkit are you contributing too?
- [.NET Community Toolkit](docs/dotnet/CONTRIBUTING.md)
- [Windows Community Toolkit](docs/windows/CONTRIBUTING.md)
- [.NET MAUI Community Toolkit](docs/maui/CONTRIBUTING.md)


Unreasonable faded lines

Environment data

Language Server version: 20222.08.31
OS and version: Windows 10 Pro, 21H2
Python version (& distribution if applicable, e.g. Anaconda): 3.9.4
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Python venv

Code Snippet

#numpy version: 1.23.2
import numpy as np
ey = np.array((0, 1, 0))

def coorsys_director( xi1, xi2):
    if xi1<-1 and xi1>1 and xi2<-1 and xi2>1:
        raise ValueError('-1<=xi1<=+1, -1<=xi2<=+1 must be followed')
    else:
        vdir =np.array((xi1, xi2, 0))
        v1 = (np.cross(ey, vdir))
        v1_unit= v1 / np.linalg.norm(v1)
        v2_unit = np.cross(vdir, v1_unit)
        return np.array([v1_unit, v2_unit, vdir])

vectors = coorsys_director(0.5, 0.2)
print(vectors)

Repro Steps

I give an example of an issue that occurred several times in my code. When I indent some commands or variables correctly, which are in the example:
v1_unit= v1 / np.linalg.norm(v1)
v2_unit = np.cross(vdir, v1_unit)
return np.array([v1_unit, v2_unit, vdir])
They got faded.  If I change the indentation to the wrong one then everything highlighted correctly then Why does this happen? (is it really connected with indentation?)
The hover says: "The code is unreachable: Pylance and there is no solution available" But the code is executable and the results are correct.

Expected behavior
No Faded lines
Actual behavior
Faded line
Logs

[Info  - 12:04:50 PM] (26276) Pylance language server 2022.8.31 (pyright f444ffa5) starting
[Info  - 12:04:50 PM] (26276) Server root directory: c:\Users\privateuser\.vscode\extensions\ms-python.vscode-pylance-2022.8.31\dist
[Info  - 12:04:50 PM] (26276) Starting service instance "Issue"
[Info  - 12:04:50 PM] (26276) Notebook support: LSP
[Info  - 12:04:50 PM] (26276) Interactive window support: LSP
[Info  - 12:04:50 PM] (26276) No configuration file found.
[Info  - 12:04:50 PM] (26276) No pyproject.toml file found.
[Info  - 12:04:50 PM] (26276) Setting pythonPath for service "Issue": "c:\Issue\394\Scripts\python.exe"
[Warn  - 12:04:50 PM] (26276) stubPath c:\Issue\typings is not a valid directory.
[Info  - 12:04:50 PM] (26276) Assuming Python version 3.9
[Info  - 12:04:50 PM] (26276) Assuming Python platform Windows
[Info  - 12:04:50 PM] (26276) Search paths for c:\Issue
[Info  - 12:04:50 PM] (26276)   c:\Users\privateuser\.vscode\extensions\ms-python.vscode-pylance-2022.8.31\dist\typeshed-fallback\stdlib
[Info  - 12:04:50 PM] (26276)   c:\Issue
[Info  - 12:04:50 PM] (26276)   c:\Issue\typings
[Info  - 12:04:50 PM] (26276)   c:\Users\privateuser\.vscode\extensions\ms-python.vscode-pylance-2022.8.31\dist\typeshed-fallback\stubs\...
[Info  - 12:04:50 PM] (26276)   c:\Users\privateuser\.vscode\extensions\ms-python.vscode-pylance-2022.8.31\dist\bundled\stubs
[Info  - 12:04:50 PM] (26276)   c:\Users\privateuser\AppData\Local\Programs\Python\Python39\DLLs
[Info  - 12:04:50 PM] (26276)   c:\Users\privateuser\AppData\Local\Programs\Python\Python39\Lib
[Info  - 12:04:50 PM] (26276)   c:\Users\privateuser\AppData\Local\Programs\Python\Python39
[Info  - 12:04:50 PM] (26276)   c:\Issue\394
[Info  - 12:04:50 PM] (26276)   c:\Issue\394\Lib\site-packages
[Info  - 12:04:50 PM] (26276) Adding fs watcher for library directories:
 C:\Users\privateuser\AppData\Local\Programs\Python\Python39\DLLs
C:\Users\privateuser\AppData\Local\Programs\Python\Python39\lib
C:\Users\privateuser\AppData\Local\Programs\Python\Python39
c:\Issue\394
c:\Issue\394\lib\site-packages
[Info  - 12:04:50 PM] (26276) Adding fs watcher for directories:
 c:\Issue
 .
 .
 .
 .
 It is too long and the error message appears while submitting the issue.

Similar issue here, pylance claims the line after the np.cross is unreachable. I hover over the faded np.cross function and pylance pops
(function)
cross(a: _ArrayLikeBool_co, b: _ArrayLikeBool_co, axisa: int = ..., axisb: int = ..., axisc: int = ..., axis: int | None = ...) -> NoReturn
...

I think the NoReturn type is the cause of this. It seems this bug was reported quite a few times, and for a while it was fixed, but now it appears again.

Thanks for your help. So, you mean the issue is more connected to numpy rather than Pylance? By the way, your remedy works perfectly.

Yup, more related to numpy api


With offset = 39, and seqPos = 40, and isReverseStrand = true, the line of code is  walking off the start of this 40bp long sequence.
This seems to be because the backtrace has a length of 41:
(gdb) print bt
$6 = (const std::__1::string &) @0x7fffffff2c70: {
  static __endian_factor = 2,
  __r_ = {<std::__1::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false>> = {__value_ = {{__s = {{__is_long_ = 1 '\001',
              __size_ = 24 '\030'}, __padding_ = 0x7fffffff2c71 "",
            __data_ = "\000\000\000\000\000\000\000)\000\000\000\000\000\000\000\340E\350VUU\000"}, __l = {{__is_long_ = 1, __cap_ = 24},
            __size_ = 41,
            __data_ = 0x555556e845e0 'M' <repeats 27 times>, "I", 'M' <repeats 12 times>, "D"}, __r = {__words = {49, 41,
<PHONE_NUMBER>3936}}}}}, <std::__1::__compressed_pair_elem<std::__1::allocator<char>, 1, true>> = {<std::__1::allocator<char>> = {<std::__1::__non_trivial_if<true, std::__1::allocator<char> >> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>},
  static npos =<PHONE_NUMBER>3709551615}

I have not yet been able to figure out what the target sequence is to make a minimal reproducible example, but I wanted to see if you had any ideas on what would be causing this walk off the edge behavior.

The offending alignment is this:
113676  45      0.829   6.410E-05       39      0       40      527     566     585     39      0       0       584     27M1I12M1D
Which does appear to be walking off the end to me.

Could you please post the mmseqs command line and terminal output too? Ideally also the sequences with which to reproduce the crash

I am having a hard time creating a minimal reference sequence to reproduce the crash. If I reduce the target database down to only the aligned sequence, it doesn't happen.
The command line in question is
mmseqs convertali querydb targetdb --format-output query,target,qstart,qend,tstart,tend,raw,cigar,qaln,taln,qlen --search-type 3
I will continue to try and make a minimal reproducible example. I did notice that adding a N to the start of my query sequence solves the issue.

I was unable to make a minimal ref, so I uploaded the ref to Box. It is a human transcriptome. I had to break it into three parts, just concatenate them.
Here is the query:
>GRCh38_ENSG00000103042.3491.40
TATTTTATTTTGTGTAGAGATGGGGTCTCACTAGGTTGCC

You should be able to reproduce the crash with
mmseqs easy-search tmp.fasta  full_ref.fa aln.out $TMPDIR  --format-output query,target,qstart,qend,tstart,tend,raw,qaln,taln,qlen --search-type 3

https://app.box.com/s/bx5y7s5gpa7ybyc6xera4hujwojagphe
https://app.box.com/s/w86ynfly4gi2zt09wb0adqc3g05ox7ok
https://app.box.com/s/g50mq3skkaimb8ggunwlqwgbdz5psb6t


chore(main): release 1.16.6

:robot: I have created a release beep boop
1.16.6 (2023-12-19)
Miscellaneous Chores

release 1.16.6 (6d7778a)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/viarotel-org/escrcpy/releases/tag/v1.16.6 :sunflower: