LXC: changing feature flags is only allowed for root@pam

I'm trying to create an LXC container using this provider following the example:
resource "proxmox_lxc" "alpine-test" {
    hostname = "alpine-test"
    cores = 1
    memory = "1024"
    swap = "2048"
    network {
        name = "eth0"
        bridge = "vmbr0"
        ip = "<IP_ADDRESS>/24"
        firewall = false
    }
    ostemplate = "local:alpine-3.10-default_20190626_amd64.tar.xz"
    password = "XXXXXXXXXXXXX"
    rootfs = "local-lvm:8"
    storage = "local-lvm"
    target_node = "proxmox"
    unprivileged = true
}

Terraform runs as a pve user.
Running this however results in an error:
proxmox_lxc.alpine-test: Creating...

Error: Error creating LXC container: 403 Permission check failed (changing feature flags is only allowed for root@pam), error status: {"data":null} (params: [123 34 111 115 <snip> 115 101 125])

According to the debug it is passing along &features= with no features.

What does features means, I have the same problem.
Can I create container without features?

I have enabled, 2FA for my root account, and I can't use the root@pam either.

I confirm @syphernl bug. My workaround right now is using root@pam instead.

Also tried to create an additional pam user, but did not manage to assign the correct rights to avoid this issue.

There does not seem to be a way to provide this permission to any pve user. I gave a test user access to / with propagate set to true and the reported error still occurs.

Only root can control features, there is no way to allow others to set them.
I think the correct way here would be to not pass features at all in case nothing was explicitly specified.
https://git.proxmox.com/?p=pve-container.git;a=blob;f=src/PVE/LXC.pm;h=ab15ec09fb3a3fb1e859cb705375ef4bb42b279a;hb=HEAD#l1111

@krzysztof-magosa With the most recent version (and changes of #77) I'm still getting the same error. I'm using the aforementioned resource where no explicit features are specified. Anything I'm doing wrong?

Hello. I have the same error with following config, what am i doing wrong? Local terraform-provider-proxmox has been updated
resource "proxmox_lxc" "test" {
    hostname = "test"
    cores = 2
    memory = 2048
    swap = 0
    network {
        name = "eth0"
        bridge = "vmbr0"
        ip = "dhcp"
    }
    ssh_public_keys = var.cloud_vars.ssh_key
    ostemplate = "shared:cephfs/ubuntu-20.04-lxc.tar.xz"
    storage = "pool"
    target_node = "server-n4"
    unprivileged = true
}

Error: Error creating LXC container: 403 Permission check failed (changing feature flags is only allowed for root@pam), error status: {"data":null} (params:........

Same thing here, no features in the container, but it's impossible to create one. Could the issue be reopened please ?

@ggongaware Can this issue be reopened?

Unfortunately the changes of https://github.com/Telmate/proxmox-api-go/pull/77 haven't helped and this still seems to be a problem with Terraform 1.0.11 / Provider 2.9.3:
│ Error: error creating LXC container: 403 Permission check failed, error status: {"data":null} (params: {"arch":"amd64","cmode":"tty","console":true,"cores":1,"cpulimit":0,"cpuunits":1024,"features":"","hostname":"alpine-test","memory":1024,"net0":"name=eth0,ip=x.x.x.x/xx,bridge=vmbr0","onboot":false,"ostemplate":"local:alpine-3.10-default_20190626_amd64.tar.xz","password":"xxxxxx","protection":false,"rootfs":"local-lvm:1","start":false,"storage":"local","swap":2048,"tags":"","tty":2,"unprivileged":true,"vmid":117})

This bug isn't fixed. Tested myself and it had to use root@pam or set unpriviliged to true
Terraform 1.1.0 / Provider 2.9.3

This bug isn't fixed. Tested myself and it had to use root@pam or set unpriviliged to true Terraform 1.1.0 / Provider 2.9.3

its not a bug. its a proxmox feature.

bump
pve 7.1-8, feature still here


⚠ Mitsubishi has degraded performance

In 3936b4f, Mitsubishi (https://mitsubishimotorsid-mobileapp.com/app/login) experienced degraded performance:

HTTP code: 200
Response time: 6313 ms

Resolved: Mitsubishi performance has improved in 118c924 after 4 minutes.


nightly doctest builds fail

See latest daily test https://github.com/orion-rs/orion/runs/5133963839?check_suite_focus=true

I can take a look tomorrow afternoon (5ish EST). Seems like it's the io trait impls. I wonder why it's suddenly failing.

Would be very helpful!

Turns out this the issue was temporary. Current nightly builds pass.


Bug: findAll returns parent node in result array

Describe the bug
findAll returns the parent node in the result set if it matches the selector when chained from get
To Reproduce

ParentComponent.vue
<template>

child

child

child

</template>

ParentComponent.spec.js
import { mount } from '@vue/test-utils';

import ParentComponent from '../ParentComponent';

describe('parent', () => {
  test('finds 3 children', () => {
    const wrapper = mount(ParentComponent);

    const parent = wrapper.get('.parent');

    expect(parent.findAll('div').length).toBe(3);
  });
});

result
parent
    ✕ finds 3 children (21 ms)

  ● parent › finds 3 children

    expect(received).toBe(expected) // Object.is equality

    Expected: 3
    Received: 4

Expected behavior
findAll returns only the 3 child nodes in the result array. This is the behaviour of vue-test-utils@1
Related information:

@vue/test-utils version: 2.0.0-rc.18
Vue version: 3.2.26
node version: 16.13.1
npm (or yarn) version<EMAIL_ADDRESS>
Additional context
I'm aware of the open PR reworking find and findAll, as well as a few mentions in other issues relating to findAll of a contributor currently working on changes to findAll. Maybe the open PR or the work in progress fixes this, but I thought it was worth documenting.

Hmmm weird, I remember having some PRs around find and the parent, I wonder if this is a regression.
It looks like this line is checking that the parent is not returned, maybe is doesn't work as expected.

I think this comes from this line https://github.com/vuejs/test-utils/blob/d414157b0640218b6cf073ba78ba30b0c28da593/src/baseWrapper.ts#L48-L50
The origin might come from #897 and after some refactoring it has been implemented into findAll.
But when removing this behavior then this will not work anymore:
const parent = wrapper.get('.parent')

Because wrapper.element is already the parent element. Also some issues when using multiple root nodes.
I think this is more a question on how the intention of find/findAll is. Should it be possible to use find/get to get the exact same wrapper again?
IMO it should not and it would make it more complicated. Only the edge case in #897 makes sense to me, where you have a DOMWrapper and want to get the VueWrapper. Maybe this can be done with a method for example domWrapper.asVueWrapper() and then all find methods will always return child elements

I'm not a react developer but I looked at enzyme to see what they do and it appears that enzyme's find does return the root node: https://github.com/enzymejs/enzyme/blob/57baba5ceaccec7a3ada40d7559f5bf71289cbe7/packages/enzyme-test-suite/test/shared/methods/find.jsx#L32-L36
I suppose in their case, they are making a distinction between the Wrapper itself, and the DOM tree within it, and their find is "find within the DOM tree of this Wrapper".
This approach would make sense for VTU in the case of a multi-root node, ie:
<template>
  <select class="a"><option>Foo</option></select>
  <select class="b"><option>Bar</option></select>
</template>

You might want to:
// findAll needs to operate on the root for select.a to match anything
expect(wrapper.findAll('select.a option')).toHaveLength(1);

Then if you modified the component later to split your selects and you ended up with:
<template>
  <select class="a"><option>Foo</option></select>
</template>

Would the same test still work? If you wanted the behaviour to be the same between single and multi-root nodes, I think the parent would need to be considered part of the search space for the target selector for findAll.
Unfortunately I think this is a more confusing API. I prefer find and findAll to search within the parent element, because if you wanted to test something about the parent element, well you already have the wrapper. Is the nicer, easier to understand API worth making the behaviour different between single and multi root components?

@lmiller1990 I can work on this if you want, but I need your decision. Here are my proposals:
1. find/findAll will not return the parent element

find and findAll will always return the same results
The wrapper will behave the same, no matter if single root or multi root element
The root wrapper is always the "template"-tag of the component

In my opinion the cleanest way to avoid conflicts between find<>findAll and single<>multi root elements. But this will be some work to do and will also lead to a (maybe big) regression
2. find will return the parent element. findAll will not

find will work as before
findAll will not return the parent element except for multi root components

I was able to implement this successfully with the current unit tests, but I am not 100% sure if this will cause some regressions for other users.
https://github.com/freakzlike/vue-test-utils-next/commit/43d2d96422927b993a283a335de6e0a992ce345a

I am conflicted. I do not really want to introduce breaking changes, but the example in the OP just seems completely wrong.
Your (1) proposal seems to make the most sense. I like to think of find and findAll like querySelector and querySelectorAll.
find
With non-fragment:
<template>

</template>

find('div') returns the outer element.
With fragment:
<template>

</template>

find('div') returns the #a element.
findAll
With non-fragment:
<template>

</template>

findAll('div') returns #a and #b.
With fragment:
<template>

</template>

findAll('div') returns all elements.
As per the OP
<template>

child

child

child

</template>

find('.parent').findAll('div') returns the three children.
To confirm my understanding, is find('.parent').find(.'parent').find('.parent') currently working?
I think we should 1:1 match querySelector(All). This seems like the obvious way to handle things. I could be missing context, but why does findAll return the parent node at all? This seems completely wrong.
@xanf maybe has some context? Since he is located in Ukraine, I am not sure can reply soon :(
If not, I say go ahead - we should match the V1 behavior where possible, and make sure the default is intuitive and makes sense.

@lmiller1990 I totally agree with your logic. I will implement it

@xanf I think that's still in line with what is being suggested, extending your example to match the OP's example:
const parent = template.querySelector('div'); // .parent
console.log(parent.querySelectorAll('div').length); // 3

This should be the expected behaviour, and I think your examples are in line with what's being suggested to treat a component wrapper like a fragment made using the <template> element.
When wrapper is a component, if we consider the <template> the top-level element, then template.querySelectorAll('div').length should return 4.
When wrapper is a DOM element (ie, .parent) then find/findAll should only search within the element and not include the element itself in the search space.
Or am I mis-understanding something?

I think we are all on the same page.
const template = `
<template>

child

child

child

</template>
`

wrapper.get('.parent').findAll('div') // should be 3 elements - `.parent` should not return `.parent` when using `findAll`

Right?

Does this happen in rc.17? Was this a regression?
I want to release rc.19 but I think we need to fix regressions from rc.18 first. Namely, this (if regression) and https://github.com/vuejs/test-utils/issues/1173.

@lmiller1990 let's double check if we are on the same page:

wrapper.findAll('div') should return 4 - since we are operating on Vue wrapper, we expect to include root nodes (especially important for multi-root)
wrapper.get('div').findAll('div') should return 3 (obviously).

Am I correct? If so I could fix that and also update docs to reflect this
/cc @cexbrayat

@lmiller1990 let's double check if we are on the same page:

wrapper.findAll('div') should return 4 - since we are operating on Vue wrapper, we expect to include root nodes (especially important for multi-root)
wrapper.get('div').findAll('div') should return 3 (obviously).

Am I correct? If so I could fix that and also update docs to reflect this /cc @cexbrayat

I tested this with rc.16 and both cases are working as you mentioned

@xanf added a patch for this missing edge case: https://github.com/vuejs/test-utils/pull/1377/commits/a9fd8b5cce1897dd514fdd115fd9f3713439c23e
I'm just hacking my way to success, happy to add more edge cases if they exist.


adding oncellclicked event using ipyaggrid

Hi,
I'm trying to add an oncellclicked event to my table where the cell value is returned when user click the cell, I know this is possible using AG grid, just wondering is there a way to add this event using Python. Thanks!

I don't know the answer to this specific question, did you check out the https://github.com/widgetti/ipyaggrid/tree/master/docs/notebooks directory. Maybe that helps you in the right direction

You can add an even by adding a callback for onCellClicked in your grid options:
import ipyaggrid as ipg
import pandas as pd

# Create a sample dataframe
df = pd.DataFrame({
    'name': ['Alice', 'Bob', 'Charlie'],
    'age': [25, 30, 35],
    'salary': [50000, 60000, 70000]
})

# Define the Ag-Grid column definitions
column_defs = [
    {'headerName': 'Name', 'field': 'name'},
    {'headerName': 'Age', 'field': 'age'},
    {'headerName': 'Salary', 'field': 'salary'},
]

# Define the Ag-Grid options
options = {
    'column_defs': column_defs,
    'enableSorting': True,
    'enableFilter': True,
    'enableColResize': True,
    'onCellClicked': 'function(params) {alert(params.value)}'
}

# Create the Ag-Grid widget
grid_widget = ipg.Grid(
    grid_data=df,
    grid_options=options
)

# Display the widget
grid_widget

Thanks @vthemelis
do you know how to trigger a python callback using this? that would be a really nice example I think.

do you know how to trigger a python callback using this? that would be a really nice example I think.
I don't think that this is something that is possible to do right-off-the-box in ipyaggrid. You would probably need some sort of IPC framework for this. Maybe this: https://ipywidgets.readthedocs.io/en/latest/examples/Widget Low Level.html#comms ?

Here's a workaround using ipyvue:
import ipyaggrid as ipg
import pandas as pd
import ipyvue
import traitlets

class MyEvents(ipyvue.VueTemplate):

    @traitlets.default("template")
    def _template(self):
        return """
        <script>
        module.exports = {
          created() {
            window.myNamespace = {
              passEvent: (params) => {
                   this.my_message(params)
              },
            }
          }
        }
        </script>
        """

    def vue_my_message(self, data):
        print("data: ", data)

display(MyEvents())

# Create a sample dataframe
df = pd.DataFrame({
    'name': ['Alice', 'Bob', 'Charlie'],
    'age': [25, 30, 35],
    'salary': [50000, 60000, 70000]
})

# Define the Ag-Grid column definitions
column_defs = [
    {'headerName': 'Name', 'field': 'name'},
    {'headerName': 'Age', 'field': 'age'},
    {'headerName': 'Salary', 'field': 'salary'},
]

# Define the Ag-Grid options
options = {
    'column_defs': column_defs,
    'enableSorting': True,
    'enableFilter': True,
    'enableColResize': True,
    'onCellClicked': '''function(params) {
        console.log("params: ", params);
        const { rowIndex, type, data } = params;
        myNamespace.passEvent({ rowIndex, type, data });
    }'''
}

# Create the Ag-Grid widget
grid_widget = ipg.Grid(
    grid_data=df,
    grid_options=options
)

# grid_widget.on_msg(lambda *args: print("onmsg", args))

# Display the widget
grid_widget


Fixed db test intermittent segment fault

Description
The db test is getting an intermittent segment fault, this change should fix it.
Type of change
What is it?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[x] Tests update
[ ] Refactor

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I run make pre-commit to check fmt/vet/lint/test-no-fdo

Codecov Report
Base: 35.98% // Head: 36.15% // Increases project coverage by +0.17% :tada:

Coverage data is based on head (78c5313) compared to base (f1b3080).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1553      +/-   ##
==========================================
+ Coverage   35.98%   36.15%   +0.17%
==========================================
  Files          67       67
  Lines        9013     9017       +4
==========================================
+ Hits         3243     3260      +17
+ Misses       5356     5347       -9
+ Partials      414      410       -4

Impacted Files
Coverage Δ

pkg/services/images_build/main.go
0.00% <0.00%> (ø)

pkg/services/images.go
30.95% <0.00%> (+1.29%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


From<[T; M]> for CircularBuffer where N < M should panic

I ran into this while setting up a unit test that I expected to panic.  It's fairly simple to reproduce:
let buffer: CircularBuffer<2; u8> = [0x01, 0x02, 0x03].into();

The issue seems to be here https://github.com/andreacorbellini/rust-circular-buffer/blob/master/src/lib.rs#L1686.  I guess this is a design choice, but I don't think I'd ever want to silently discard array elements while constructing a circular buffer.
It's a small (breaking) change, and I'm happy to open the MR for it.  Thanks for the awesome library!

HI Brett, thanks for reporting this. What I think we can do is to have a
From<[T; N]> for CircularBuffer implementation, i.e. allow only
conversion from an array of the same size of the buffer. This would result
in build-time failures rather than runtime panics.
I would avoid introducing fallible behavior in a From implementation:
that's what TryFrom is for.
This could be introduced in a 0.2 release to avoid breaking existing code.
However, I would like to see more data points to be convinced that this is
a desiderabile feature. I see pros and cons on both sides.
On Fri, Jan 5, 2024, 05:27 Brett Lempereur @.***> wrote:

I ran into this while setting up a unit test that I expected to panic.
It's fairly simple to reproduce:
let buffer: CircularBuffer<2; u8> = [0x01, 0x02, 0x03].into();
The issue seems to be here
https://github.com/andreacorbellini/rust-circular-buffer/blob/master/src/lib.rs#L1686.
I guess this is a design choice, but I don't think I'd ever want to
silently discard array elements while constructing a circular buffer.
It's a small (breaking) change, and I'm happy to open the MR for it.
Thanks for the awesome library!
—
Reply to this email directly, view it on GitHub
https://github.com/andreacorbellini/rust-circular-buffer/issues/9, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACOKLTWKZJG6S37RUSY2N3YM4UGZAVCNFSM6AAAAABBNTC3NWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3DMNBSGA2TOMA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Make Components inherit all attributes?

I'm trying to make my image tags tidy by encapsulating my src with a prefix, one thing I find difficult is that the attributes don't "inherit" by default and have to pass all the attributes each one. Is there a cleaner way of doing this? Thanks.
export const Image = (attrs) => (

);

@van-nguyen You could do this.
export const Image = ({ src, ...attrs }) => (

)

Nice @jorgebucaran just what I was looking for. Thanks for the fast reply, cheers.

Glad I could help!


Remove obsolete login hooks

Questions
Answers

Description?
Remove obsolete login hooks

Type?
improvement

BC breaks?
no

Deprecations?
no

Fixed ticket?
~

Sponsor company
~

How to test?
After an upgrade check in the ps_hook table that the hooks related to login and added in this PR are correctly removed

Removed in favor of https://github.com/PrestaShop/autoupgrade/pull/957


[Info] Generated binding available

Hello,
I wrote a kind of generator, and, as I generated sqlite3 bindings to test it, I though you may be interested :
The generated file is here : https://github.com/TechMagister/bindgencr/blob/master/samples/sqlite3/lib_sqlite3.cr
The project : https://github.com/TechMagister/bindgencr/

Hi @TechMagister , thanks. Are you aware of https://github.com/crystal-lang/crystal_lib ? Might be a better place to compare and improve automated bindings.
From what I see on the bindings you are sending, some pointers are declared as Type[0] as in
  struct Sqlite3
    __data : UInt8[0]
  end

Even so, thanks! and we could definitely use some of those binding to improve ours upon need. It's far more comfortable to read that than C declarations :-)


Bug: Focused project does not include source files for rules_ios project

Description
Generating a focused project for a rules_ios project does not bring in source files to Xcode.
Reproduction steps

Checkout this branch: aguardia/repro-focused-no-including-source-files-rules-xcodeproj
Run bazel run //tests/ios/app:foo && open foo.xcodeproj
The Xcode project does contain the expected App.swift source file inside the tests/ios/app directory

Expected behavior

The Xcode project should contain the App.swift source file inside the tests/ios/app directory

rules_xcodeproj version
1.3.3
Xcode version
14.2
Bazel version
6.0.0
rules_apple version
935d5ad80300578f35833db26f124f20aeda9cba
rules_swift version
17e20f7edf27e647f1b45f11ed75d51c17820c3b
Additional information
The source file import seems to be skipped at this point in the code. The condition is met becauserules_ios creates additional //tests/ios/app:foo_swift and //tests/ios/app:foo_objc targets.

cc @mattrobmattrob

7967b372bd1777214ce65c87a82ac0630150b7504b443de0315ea52e45758e0c

I don't see that commit. Can you link to it from GitHub for me?

7967b372bd1777214ce65c87a82ac0630150b7504b443de0315ea52e45758e0c

I don't see that commit. Can you link to it from GitHub for me?

I think that's 1.3.3, cc @AngelaGuardia to confirm

With the latest commit (so essentially 1.4.0), the target is merged properly without any focused targets:

But still doesn't work when focused as in the branch:

The branch's version is 1.3.3:
http_archive(
    name = "rules_xcodeproj",
    sha256 = "7967b372bd1777214ce65c87a82ac0630150b7504b443de0315ea52e45758e0c",
    url = "https://github.com/MobileNativeFoundation/rules_xcodeproj/releases/download/1.3.3/release.tar.gz",
)

Linked version is actually the sha256 value. 👍

Btw @mattrobmattrob random thought: should add all "target merging" related issues to a GH project so we can get a sense of how far we are from a "release candidate" version?
Not meaning to put pressure on this at all, just trying to think of a way for us to organize the remaining work a little bit better

Btw @mattrobmattrob random thought: should add all "target merging" related issues to a GH project so we can get a sense of how far we are from a "release candidate" version?

If you think it's valuable, sure. For me, I'm essentially entirely focused on the ios_unit_test/ios_ui_test merging case since that's what populates the test navigator with the parsing Xcode does. Otherwise, I'm less concerned/focused but my work should also lay some of the foundation for mixed-language-framework (apple_framework_packaging or otherwise) merging as well.


Acceleration data for using only hands/gestures?

I read somewhere that the AVP doesn't allow for transmitting the acceleration data from the Joycons, but would it be possible to send it when using only a hands/gestures setup? Something like calculating direction and differences in hand positions over time? It seems many people cannot play games like Half-Life: Alyx (which require acceleration data from the moment you pick up the "gravitation gloves") due to this data lacking.
Maybe some inspiration can be taken from the following fork of the original, which calculates linearVelocity and angularVelocity as derivative of position and rotation data: https://github.com/dnnkeeper/ALVR/tree/ControllerVelocityFix

Technically we do send this, it's just the streamer that's not actually using it atm

Technically we do send this, it's just the streamer that's not actually using it atm

Seems the guys over at the streamer are pointing back to the client:
https://github.com/alvr-org/ALVR/issues/2212
Do JoyCons send acceleration data (from a "throwing gesture" for example), and is this data passed on by the ALVR-visionos client to the streamer/server? @shinyquagsire23 Do you own a couple of JoyCons and would you be able to check whether you're able to throw objects in Half-Life: Alyx? Seems that the items are dropping straight (vertically) to the ground, as soon as the grip is released. I would like to know if this is a limitation due to the Joy-Cons? If so, it should be possible for the client to calculate force/acceleration based on Vision Pro hand-tracking instead, right? (calculating linearVelocity and angularVelocity as derivative of position and rotation data). Maybe people using Joy-Cons should then be able to tick a box in the client that confirms they are using them (if this cannot be detected automatically), and the client should send acceleration data based on recent hand-tracking position history? Especially with the recent upgrade of hand-tracking to 90 fps, this should be accurate enough for playability.

Technically we do send this, it's just the streamer that's not actually using it atm

Seems sending acceleration data was left as a TODO? https://github.com/alvr-org/alvr-visionos/blob/986eed819753c75884ed5645f46d6444f8a7d5f7/ALVRClient/WorldTracker.swift#L970


HBase Remote/Client Filter Config

Add boolean flag to switch HBase scan plan between remote and client filter modes.

@nagavallia I just merged the PR this stacks on, could you rebase/cherry-pick to get a clean commit? thanks,

@nagavallia can you rebase on master now that the filters PR is merged? thanks


claws-mail: Fix fancy plugin

This fixes the fancy plugin displaying HTML mails as text as suggested by @wedens.
This fixes #10421.

Note that setting XDG_DATA_DIRS there will replace it at build time, which is not good.
I suggest something like:
preFixup = ''
  gappsWrapperArgs+=(--prefix XDG_DATA_DIRS : "${shared_mime_info}/share")
'';

Also that  GIO_EXTRA_MODULES wrapping is already done. Just put glib_networking in buildInputs, but that's another issue.

@lethalman Thanks for the hints!
I've updated the commit with your suggestion and removed the extra GIO_EXTRA_MODULES wrapping. I've also checked the resulting wrapper script that everything is in there and tested the application itself. Everything's fine as far as I can see.

In time it would be nice to create a hook in shared_mime_info to extend gappsWrapperArgs automatically when in build inputs. (It might cause a larger rebuild, though.)


WIP: Implement subcell limiting for non-conservative systems

This PR extends the subcell limiting strategies implemented in #1476 to non-conservative systems.
To do the subcell limiting, the DGSEM is formulated as a flux-differencing formula. For non-conservative systems, this formulation requires expressing non-conservative terms as the product of both local and symmetric components. I have included an example using the GLM-MHD equations, where the Powell and GLM non-conservative terms have been recast in the format of "local * symmetric."

I ran a convergence test with a modified version of examples/tree_2d_dgsem/elixir_mhd_alfven_wave.jl, where I activated the positivity limiter. The l2 and linf errors are equal to the ones produced by VolumeIntegralShockCapturingHG and VolumeIntegralFluxDifferencing to machine precision accuracy. Here are the convergence tables:
l2
rho                 rho_v1              rho_v2              rho_v3              rho_e               B1                  B2                  B3                  psi
error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC
5.51e-03  -         4.77e-04  -         4.77e-04  -         9.35e-04  -         2.84e-04  -         3.73e-04  -         3.73e-04  -         9.33e-04  -         3.80e-04  -
9.09e-04  2.60      5.81e-05  3.04      5.81e-05  3.04      8.11e-05  3.53      2.34e-05  3.60      2.09e-05  4.16      2.09e-05  4.16      4.08e-05  4.51      9.42e-06  5.33
1.11e-04  3.03      5.94e-06  3.29      5.94e-06  3.29      8.54e-06  3.25      1.32e-06  4.15      1.47e-06  3.83      1.47e-06  3.83      2.16e-06  4.24      4.65e-07  4.34
9.46e-06  3.56      4.82e-07  3.62      4.82e-07  3.62      7.11e-07  3.59      8.35e-08  3.98      1.19e-07  3.63      1.19e-07  3.63      1.67e-07  3.69      2.81e-08  4.05
3.17e-07  4.90      2.10e-08  4.52      2.10e-08  4.52      2.85e-08  4.64      4.19e-09  4.32      1.28e-08  3.21      1.28e-08  3.21      1.80e-08  3.22      1.74e-09  4.01

mean      3.52      mean      3.62      mean      3.62      mean      3.75      mean      4.01      mean      3.71      mean      3.71      mean      3.92      mean      4.43
----------------------------------------------------------------------------------------------------
linf
rho                 rho_v1              rho_v2              rho_v3              rho_e               B1                  B2                  B3                  psi
error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC       error     EOC
1.33e-02  -         1.97e-03  -         1.97e-03  -         2.68e-03  -         1.09e-03  -         1.99e-03  -         1.99e-03  -         3.71e-03  -         1.14e-03  -
1.86e-03  2.83      1.80e-04  3.45      1.80e-04  3.45      2.45e-04  3.45      8.61e-05  3.66      1.28e-04  3.95      1.28e-04  3.95      2.31e-04  4.00      3.86e-05  4.88
2.68e-04  2.80      1.73e-05  3.38      1.73e-05  3.38      2.61e-05  3.23      5.46e-06  3.98      9.23e-06  3.80      9.23e-06  3.80      1.40e-05  4.05      2.37e-06  4.02
2.35e-05  3.51      1.39e-06  3.64      1.39e-06  3.64      2.71e-06  3.27      3.56e-07  3.94      6.15e-07  3.91      6.15e-07  3.91      8.90e-07  3.97      1.47e-07  4.01
9.69e-07  4.60      9.39e-08  3.88      9.39e-08  3.88      9.04e-08  4.90      2.40e-08  3.89      4.71e-08  3.71      4.71e-08  3.71      6.77e-08  3.72      9.15e-09  4.00

mean      3.44      mean      3.59      mean      3.59      mean      3.71      mean      3.87      mean      3.84      mean      3.84      mean      3.94      mean      4.23
----------------------------------------------------------------------------------------------------

When running the convergence test documented above, the following performance summary was obtained with the novel subcell limiting for non-conservative systems:
 ─────────────────────────────────────────────────────────────────────────────────────
              Trixi.jl                       Time                    Allocations
                                    ───────────────────────   ────────────────────────
          Tot / % measured:               120s /  97.4%           3.03GiB /  99.9%

 Section                    ncalls     time    %tot     avg     alloc    %tot      avg
 ─────────────────────────────────────────────────────────────────────────────────────
 rhs!                        4.87k    97.2s   83.5%  20.0ms   9.33KiB    0.0%    1.96B
   volume integral           4.87k    78.2s   67.2%  16.1ms     0.00B    0.0%    0.00B
   interface flux            4.87k    11.7s   10.1%  2.41ms     0.00B    0.0%    0.00B
   prolong2interfaces        4.87k    3.30s    2.8%   678μs     0.00B    0.0%    0.00B
   surface integral          4.87k    2.04s    1.8%   420μs     0.00B    0.0%    0.00B
   reset ∂u/∂t               4.87k    1.33s    1.1%   273μs     0.00B    0.0%    0.00B
   Jacobian                  4.87k    604ms    0.5%   124μs     0.00B    0.0%    0.00B
   ~rhs!~                    4.87k   26.3ms    0.0%  5.40μs   9.33KiB    0.0%    1.96B
   prolong2mortars           4.87k   1.80ms    0.0%   370ns     0.00B    0.0%    0.00B
   prolong2boundaries        4.87k   1.60ms    0.0%   329ns     0.00B    0.0%    0.00B
   mortar flux               4.87k   1.18ms    0.0%   242ns     0.00B    0.0%    0.00B
   boundary flux             4.87k    289μs    0.0%  59.4ns     0.00B    0.0%    0.00B
   source terms              4.87k    111μs    0.0%  22.7ns     0.00B    0.0%    0.00B
 a posteriori limiter        4.87k    12.6s   10.8%  2.58ms   1.47KiB    0.0%    0.31B
   blending factors          4.87k    7.36s    6.3%  1.51ms      752B    0.0%    0.15B
     positivity              4.87k    6.76s    5.8%  1.39ms     0.00B    0.0%    0.00B
     ~blending factors~      4.87k    595ms    0.5%   122μs      752B    0.0%    0.15B
   ~a posteriori limiter~    4.87k    5.21s    4.5%  1.07ms      752B    0.0%    0.15B
 I/O                           165    3.55s    3.1%  21.5ms   2.17GiB   71.6%  13.4MiB
   save solution               164    3.54s    3.0%  21.6ms   2.17GiB   71.5%  13.5MiB
   get element variables       164   7.64ms    0.0%  46.6μs   1.44MiB    0.0%  8.98KiB
   ~I/O~                       165   2.12ms    0.0%  12.8μs    379KiB    0.0%  2.30KiB
   save mesh                   164   54.1μs    0.0%   330ns     0.00B    0.0%    0.00B
 calculate dt                1.62k    2.13s    1.8%  1.32ms     0.00B    0.0%    0.00B
 analyze solution               18    924ms    0.8%  51.3ms    880MiB   28.4%  48.9MiB
 ─────────────────────────────────────────────────────────────────────────────────────

The summary obtained with VolumeIntegralShockCapturingHG is:
 ────────────────────────────────────────────────────────────────────────────────────
              Trixi.jl                      Time                    Allocations
                                   ───────────────────────   ────────────────────────
         Tot / % measured:              49.9s /  94.0%           3.03GiB /  99.9%

 Section                   ncalls     time    %tot     avg     alloc    %tot      avg
 ────────────────────────────────────────────────────────────────────────────────────
 rhs!                       4.87k    41.2s   87.8%  8.47ms   11.5KiB    0.0%    2.43B
   volume integral          4.87k    25.2s   53.6%  5.17ms   2.20KiB    0.0%    0.46B
     pure DG                4.87k    21.8s   46.5%  4.48ms     0.00B    0.0%    0.00B
     blending factors       4.87k    3.23s    6.9%   663μs     0.00B    0.0%    0.00B
     ~volume integral~      4.87k    103ms    0.2%  21.1μs   2.20KiB    0.0%    0.46B
     blended DG-FV          4.87k   1.04ms    0.0%   213ns     0.00B    0.0%    0.00B
   interface flux           4.87k    11.3s   24.0%  2.32ms     0.00B    0.0%    0.00B
   prolong2interfaces       4.87k    1.77s    3.8%   364μs     0.00B    0.0%    0.00B
   surface integral         4.87k    1.70s    3.6%   350μs     0.00B    0.0%    0.00B
   reset ∂u/∂t              4.87k    754ms    1.6%   155μs     0.00B    0.0%    0.00B
   Jacobian                 4.87k    556ms    1.2%   114μs     0.00B    0.0%    0.00B
   ~rhs!~                   4.87k   17.1ms    0.0%  3.51μs   9.33KiB    0.0%    1.96B
   prolong2mortars          4.87k   2.41ms    0.0%   496ns     0.00B    0.0%    0.00B
   prolong2boundaries       4.87k   2.28ms    0.0%   468ns     0.00B    0.0%    0.00B
   source terms             4.87k    716μs    0.0%   147ns     0.00B    0.0%    0.00B
   mortar flux              4.87k    687μs    0.0%   141ns     0.00B    0.0%    0.00B
   boundary flux            4.87k    371μs    0.0%  76.3ns     0.00B    0.0%    0.00B
 I/O                          165    2.96s    6.3%  17.9ms   2.17GiB   71.6%  13.4MiB
   save solution              164    2.84s    6.0%  17.3ms   2.17GiB   71.5%  13.5MiB
   get element variables      164    115ms    0.2%   704μs   1.41MiB    0.0%  8.80KiB
   ~I/O~                      165   1.89ms    0.0%  11.5μs    379KiB    0.0%  2.30KiB
   save mesh                  164   77.8μs    0.0%   474ns     0.00B    0.0%    0.00B
 calculate dt               1.62k    2.08s    4.4%  1.28ms     0.00B    0.0%    0.00B
 analyze solution              18    676ms    1.4%  37.5ms    881MiB   28.4%  48.9MiB
 ────────────────────────────────────────────────────────────────────────────────────

It is clear that the volume integral with subcell limiting is significantly more expensive than VolumeIntegralShockCapturingHG. Some extra cost was expected due to the fact that the new volume integral computes two non-conservative terms (Powell and GLM separately) instead of one. However, this seems like an extreme slow down. I tried to improve the performance, but so far this is the best I achieved...

Thanks for your comments, @ranocha! I already applied your suggestions and replied to your questions.
Do you have any clue of what might be making my code slow? (see performance post)
It seems that my problem is in the function calcflux_fhat!, which is taking a total of 45.9s to compute the DG volume integral with non-conservative terms for the test above. This is more than twice the time needed by flux_differencing_kernel!, which takes 21.8s to compute the DG volume integral with non-conservative terms.
As I wrote above,

Some extra cost was expected due to the fact that the new volume integral computes two non-conservative terms (Powell and GLM separately) instead of one. However, this seems like an extreme slow down.

Do you see any performance issues in calcflux_fhat!? or do you have any idea about how I can speed up that function?

Do you have any clue of what might be making my code slow? (see performance post)
It seems that my problem is in the function calcflux_fhat!, which is taking a total of 45.9s to compute the DG volume integral with non-conservative terms for the test above. This is more than twice the time needed by flux_differencing_kernel!, which takes 21.8s to compute the DG volume integral with non-conservative terms.
As I wrote above,

Some extra cost was expected due to the fact that the new volume integral computes two non-conservative terms (Powell and GLM separately) instead of one. However, this seems like an extreme slow down.

Do you see any performance issues in calcflux_fhat!? or do you have any idea about how I can speed up that function?

Did you try starting Julia with the flag --check-bounds=no? It appears to make a significant difference for me in this case.

Did you try starting Julia with the flag --check-bounds=no? It appears to make a significant difference for me in this case.

Yes, the results I reported were obtained with --check-bounds=no.

Yes, the results I reported were obtained with --check-bounds=no.

Could you please push an elixir I can use directly to obtain some meaningful benchmarks like the ones you reported above?

A significant amount of time is just spent in reading from and writing to memory. You have a lot of code like
    for j in 1:(nnodes(dg) - 1), i in eachnode(dg)
        # Conservative part
        for v in eachvariable(equations)
            value = fhat_temp[v, i, j] + weights[j] * flux_temp[v, i, j]
            fhat_temp[v, i, j + 1] = value
            fhat2_L[v, i, j + 1] = value
            fhat2_R[v, i, j + 1] = value
        end
        # Nonconservative part
        for noncons in 1:nnoncons(equations), v in eachvariable(equations)
            value = fhat_noncons_temp[v, noncons, i, j] + weights[j] * flux_noncons_temp[v, noncons, i, j]
            fhat_noncons_temp[v, noncons, i, j + 1] = value

            fhat2_L[v, i, j + 1] = fhat2_L[v, i, j + 1] + phi[v, noncons, i, j] * value
            fhat2_R[v, i, j + 1] = fhat2_R[v, i, j + 1] + phi[v, noncons, i, j + 1] * value
        end
    end

where no expensive computations are performed but a lot of reads and writes. I could improve the performance a bit by avoiding writing the value above to fhat_noncons_temp[v, noncons, i, j + 1] and reading it back from memory directly afterwards when updating fhat2_L[v, i, j + 1] and fhat2_R[v, i, j + 1].
I am sure there is potential to speed this up quite a bit more by avoiding a lot of temporary memory stuff like this but I don't have the time for it right now. I would expect a significant speedup afer something like one day of work (but teaching starts...)

Is it easily possible to merge the changes from my review in the PR to subcell-limiting to this one here as well?
Maybe, I should have requested the changes here:/

Is it easily possible to merge the changes from my review in the PR to subcell-limiting to this one here as well? Maybe, I should have requested the changes here:/

In commit 2b21e6a, I cherry-picked the changes that you proposed in the other PR.

@bennibolm it would be great if you could do the first review (see also the checklist above for reference) and then ping me again 🤗


[Installation with pip] No section: 'params' error

Hi Simon,
I have been trying to use gimmemotifs lately, with little success. With conda create, my installation is stuck forever on 'Solving package specifications' unless I specify the version of gimmemotifs I want, something I took from a post of yours in the bioconda GitHub. Leaving that aside, what I want to report here is an error whenever I try to use gimmemotifs following its installation via pip. Namely, I get the following:

Traceback (most recent call last):
File "/usr/lib/python3.5/configparser.py", line 843, in items
d.update(self._sections[section])
KeyError: 'params'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/data/roger/.local/bin/gimme", line 11, in
from  gimmemotifs import commands
File "/data/roger/.local/lib/python3.5/site-packages/gimmemotifs/commands/init.py", line 14, in
m =  import("{0}.{1}".format(name, cmdname), globals(), locals(), [cmdname], level)
File "/data/roger/.local/lib/python3.5/site-packages/gimmemotifs/commands/location.py", line 14, in
from gimmemotifs.mp import pool
File "/data/roger/.local/lib/python3.5/site-packages/gimmemotifs/mp.py", line 5, in
n_cpus = int(MotifConfig().get_default_params()["ncpus"])
File "/data/roger/.local/lib/python3.5/site-packages/gimmemotifs/config.py", line 66, in get_default_params
d = dict(self.config.items("params"))
File "/usr/lib/python3.5/configparser.py", line 846, in items
raise NoSectionError(section)
configparser.NoSectionError: No section: 'params'

I suspect it may have something to do with the configuration file, but strangely enough, I did not encounter this problem when I installed the program as a part of a conda environment. Am I doing anything wrong or is it really an error? Thanks!

I suspect it's not something you're doing wrong, but an issue with pip that I don't yet understand. Have you tried this command:
pip install<EMAIL_ADDRESS>
Instead of (what used to be in my docs):
pip install https://github.com/simonvh/gimmemotifs/releases/download/0.11.1/gimmemotifs-0.11.1.tar.gz

The last one gives this error, the first pip command should work fine. Let me know if it doesn't!
(And the conda-getting-stuck-problem is also frustrating to me as I don't know how to solve it.)

Hi, I tried the suggested command, but I get the same error. There is apparently no difference between Python3 and Python2.

If I interpret the code correctly you have installed via pip outside of a conda environment, right? Can you give me the exact steps/commands you used for installation? This might help me to solve it. What is the OS?

Yes, that is indeed the case. I tried to install gimmemotifs in different ways, all of them outside a Conda environment, but it made no difference. I simply used pip, as shown in the examples before retrieved from my bash history:

pip3 install --user<EMAIL_ADDRESS>sudo pip3 install<EMAIL_ADDRESS>
On the other hand, I have managed to successfully install this same version (0.11) on a Conda environment following the instructions that you provide in this repository.
As for the OS, I am using Ubuntu 16.04 LTS.

Better late than never, this issue should be fixed now. The conda problem (where it got stuck during dependency calculation) seems to have disappeared, with no apparent involvement from my side. This means that installing gimmemotifs with conda should be a one-step procedure again.
The pip issue was much more complicated and had to do with both how setuptools and pip interact as well as with the way I implemented the config file. This has been completely overhauled, and starting from the next release (or the git develop branch) it should be possible to install with pip resulting in a working config. In any case, thanks for reporting this issue.

Should be fixed in 0.13.0.


Facebook bright - Edit rss output ??

I´m using the Facebook bright by teromene & logmanoriginal and it is working quid well…THANK YOU
Is it possible to edit the rss output?
I don´t like that the title of the post is linked to the FB source and also the line with the FB profile  avatar of the FB account is not that nice… Is there a simple way to get rid of it?

Which line I have to // commend in the file  rss-bridge/bridgesFacebookBridge.php ?
thanks

so in the file rss-bridge/bridges/FacebookBridge.php
so I commented the line //$item['uri'] = htmlspecialchars_decode($uri, ENT_QUOTES);
so the linke to the FB source is gone - ;-)
but how do I get rid of this  line with the FB profile avatar?

Can someone help me? I need a hint
how do I get rid of this line with the FB profile avatar?

Looking for an Solution for the Same Problem :-(
How to Remove the Profil Picture?
Thanks...

Same here, how to remove profile picture

Same here...

@rocky-III  Is this still an issue?


Add useRouter hook

This introduces the useRouter hook alternative to withRouter

We should add a test for it :pray:

Just tried it out, and this only works in the browser environment, not SSR 😥
Really looking forward to this feature; it would eliminate 22 HoCs from my current app!

You're probably using Apollo which uses non-standard SSR to do data fetching.

I'm using next-graphql-react like the example; this might be causing the bug: https://github.com/zeit/next.js/issues/6042

How can I import it?
next js version: 8.1.0
@types/next version: 8.0.3

How to import it is not documented:
import { useRouter } from 'next/router'

Also, there should be proper way to import the RouterContext. Perhaps:
import { RouterContext } from 'next/router'

Thanks for reply. But I mean that @types/next version: 8.0.3 doesn't have such export ;(

Heck, waiting for this :>
HoCs must die

Wait, it IS THERE, but there are typings for that:
Module '"../../../../../../../../Users/jerrygreen/projects/qwe/client-2/node_modules/@types/next/router"' has no exported member 'useRouter'.

Unfortunately, typings are not included in nextjs itself and we need @types/nextjs which does not include it yet ;(

It is experimental, there's one issue with getDataFromTree in Apollo.

@timneutkens  how likely will the API of useRouter() change? Asking after creating https://github.com/DefinitelyTyped/DefinitelyTyped/pull/35058
It'd be also great if you could advise on RouterProps vs SingletonRouter in that conversation.

@kachkaev it's experimental and undocumented so use at your own risk.
Also @types/next will go away very soon:
https://github.com/zeit/next.js/pull/7169

@timneutkens this would be so cool


Fix the crash problem happening during the input method initialization

When we set a instance of OzoneWebUI by calling LinuxUI::SetInstance in ChromeBrowserMainExtraPartsAura::PreEarlyInitialization, the instance should be initialized ahead by calling OzoneWebUI::Initialize(). However we didn't.
As a result, it caused the crash in InputMethodAuraLinux::InputMethodAuraLinux() because  OzoneWebUI::Initialize() was not called ChromeBrowserMainExtraPartsAura::ToolkitInitialized due to the USE_X11 macro.
This CL allows OzoneWebUI::Initialize to be called in ChromeBrowserMainExtraPartsAura::ToolkitInitialized.

Chromium now launches well.

@kalyankondapally  I've updated the comment.

@joone I meant your commit message, not the description here

Updated.


openXC7 - no Bels remaining of type 'BUFR'

The issue is explained in this issue in more detail.

I fixed it a while ago, I will submit the code tomorrow

I have commit the files in prjxray-db and meta repository.
you can fix the pack, place and fasm, then it will work
@hansfbaier


Edit key mapping

User Story
As a user, I'd like to be the key for attack to be different to continue, so that I don't accidentally skip the notifications.
Acceptance Criteria

The attack key will either be permanently mapped to, or have a setting of being mapped to, a different key than continue

@all-contributors please add @KimberleyEvans-Parker  for ideas


Running on Travis-CI fails with No such file or directory: 'init.py'

I am trying to use codeclimate-test-reporter with Travis-CI, but get the following error:
$ codeclimate-test-reporter --debug --token $CODECLIMATE_REPO_TOKEN
codeclimate-test-repoter 0.2.1
Requests 2.13.0
Python 3.6.1 (default, Apr 21 2017, 17:35:24)
[GCC 4.6.3]
/home/travis/virtualenv/python3.6.1/bin/python
Linux 4.8.12-040812-genericProcessing file path=__init__.py
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.6.1/bin/codeclimate-test-reporter", line 11, in <module>
    sys.exit(run())
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/__main__.py", line 11, in run
    sys.exit(runner.run())
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/runner.py", line 49, in run
    exit_status = reporter.run()
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/reporter.py", line 36, in run
    payload = formatter.payload()
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/formatter.py", line 20, in payload
    source_files = self.__source_files()
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/formatter.py", line 58, in __source_files
    payload = file_coverage.payload()
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/file_coverage.py", line 30, in payload
    "blob_id": self.__blob(),
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/file_coverage.py", line 56, in __blob
    contents = self.__file_body()
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/file_coverage.py", line 63, in __file_body
    self.file_body = read_file_content(self.__filename())
  File "/home/travis/virtualenv/python3.6.1/lib/python3.6/site-packages/codeclimate_test_reporter/components/file_coverage.py", line 16, in read_file_content
    return open(path, "r", encoding="utf-8-sig").read()
FileNotFoundError: [Errno 2] No such file or directory: '__init__.py'

If I run the command manually on a local machine, everything works fine:
[MacBook Pro bsym] $ codeclimate-test-reporter --debug
codeclimate-test-repoter 0.2.1
Requests 2.13.0
Python 3.6.1 (default, Mar 25 2017, 21:33:06)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-8<IP_ADDRESS>)]
/Users/bjm42/.pyenv/versions/3.6.1/bin/python3.6
Darwin 16.5.0Processing file path=bsym/__init__.py
Processing file path=bsym/bsym.py
Processing file path=bsym/configuration.py
Processing file path=bsym/permutations.py
Processing file path=bsym/process.py
Processing file path=bsym/pymatgen_interface.py
Processing file path=bsym/sitelist.py
Processing file path=bsym/spacegroup.py
Processing file path=bsym/symmetry_operation.py
Submitting payload to https://codeclimate.com... CODECLIMATE_REPO_TOKEN is required and not set
done!

Having poked around in the code, I think the problem is a change in the XML file produced by coverage going from version 4.3.4 to 4.3.
If I generate a coverage.xml file with 4.3.4 I have entries that look like
<class branch-rate="0" complexity="0" filename="bsym/__init__.py" line-rate="1" name="__init__.py">

Using 4.4, I have entries that look like
<class branch-rate="0" complexity="0" filename="__init__.py" line-rate="1" name="__init__.py">

I haven't figure out yet exactly how the coverage XML file is used in the codeclimate reporter to construct the appropriate file paths, but a temporary work around is to use an earlier version of coverage, via pip install coverage==4.3.4.

This is being discussed on the coverage issues here

Hey @bjmorgan,
Thanks for the issue and context.
Would it make sense to update the requirements.txt file and lock down the requirement to coverage>=4.0,<4.4 ?

I think so. I have a version of codeclimate-test-reporter that now works with coverage==4.4 for my projects (by checking the source element against the current working directory and prepending to the file_node filename attribute), but this a) breaks backwards compatibility with coverage<4.4 and also does not get around the issue discussed here for more than one source directory.
https://github.com/bjmorgan/python-test-reporter/blob/coverage_path/codeclimate_test_reporter/components/formatter.py
The relevant new code is:
    def __source_dir(self):
        source_dir=self.root.find("sources/source").text
        return os.path.relpath(source_dir,os.getcwd())

    def __file_nodes(self):
        source_dir=self.__source_dir()
        file_nodes=self.root.findall("packages/package/classes/class")
        if source_dir:
            [ f.set( "filename", os.path.join( source_dir, f.get("filename") ) ) for f in file_nodes ]
        return file_nodes

Hey @bjmorgan,
I'd recommend checking out our new test reporter: https://github.com/codeclimate/test-reporter
It's decoupled from the coverage tool used to generate the report so you can manage your coverage.py usage separately.

Going to go ahead and close this issue as we now emit an error from the reporter if you're using an incompatible version of coverage.py.


[Ignore this, I need a PR to test this] Simplify diff rendering

What this PR does / why we need it
Checklist

[ ] Update changelog in CHANGELOG.md.

Trigger e2e tests

/no_diffs_printing

blabla


Builder incorrectly sources proxy env vars

Deis Builder appears to incorrectly source proxy environment variables when it starts up.
At deis/builder/rootfs/bin/entry on line 5, the environment_proxy file is sourced:
if [[ -f /etc/environment_proxy ]]; then
	source /etc/environment_proxy
fi

The environment_proxy file is formatted for systemd EnvironmentFile consumption and does not export any variables.
When the docker daemon inside is started it fails to pull down the remote images for it to operate.
Sep 16 04:06:29 ip-10-116-11-55.platform.dev.atl-inf.io sh[2957]: [info] Downloading Docker images. This may take a long time. https://xkcd.com/303/
Sep 16 04:07:39 ip-10-116-11-55.platform.dev.atl-inf.io sh[2957]: [info] Docker: Sending build context to Docker daemon 17.41 kB
Sep 16 04:07:39 ip-10-116-11-55.platform.dev.atl-inf.io sh[2957]: Sending build context to Docker daemon
Sep 16 04:07:39 ip-10-116-11-55.platform.dev.atl-inf.io sh[2957]: Step 0 : FROM heroku/cedar:14
Sep 16 04:07:39 ip-10-116-11-55.platform.dev.atl-inf.io sh[2957]: Pulling repository heroku/cedar
Sep 16 04:07:39 ip-10-116-11-55.platform.dev.atl-inf.io sh[2957]: time="2015-09-16T04:07:39Z" level="info" msg="Get https://index.docker.io/v1/repositories/heroku/cedar/images: dial tcp <IP_ADDRESS>:443: connection timed out"
Sep 16 04:07:39 ip-10-116-11-55.platform.dev.atl-inf.io sh[2957]: [error] Failed to build docker image: exit status 1

If I manually invoke the container, specifying -e HTTP_PROXY=proxyhere the container comes up and successfully pulls down the heroku/cedar image.

Keeping this issue open for the time being since we don't have proxies to test this fix. @benbarclay or @rcreasey if you can confirm #4996 fixed this issue then we can close this one out. Thanks!

Closing due to inactivity since #4996 has been merged. If you cannot get Deis v1.13.0 to work behind a proxy, please feel free to open another ticket. Thanks!


parse_obj return type is SQLModel

First Check

[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the SQLModel documentation, with the integrated search.
[X] I already searched in Google "How to X in SQLModel" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to SQLModel but to Pydantic.
[X] I already checked if it is not related to SQLModel but to SQLAlchemy.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
from sqlmodel import SQLModel

class test(SQLModel):
    attr: int
    desc: str

class real(test, table=True):
    val: float

test_inst: test = test(attr=1, desc='test_inst')
real_inst: real = real.parse_obj(test_inst.dict())
"""
(method) parse_obj: (obj: Any, update: Dict[str, Any] | None = None) -> SQLModel
Expression of type "SQLModel" cannot be assigned to declared type "real"
  "SQLModel" is incompatible with "real"PylancereportGeneralTypeIssues
"""

Description
real.parse_obj return type should be real.
Wanted Solution
# sqlmodel/main.py

from typing import TypeVar
_T = TypeVar("_T", bound="SQLModel")

(...)

# line no.569
    @classmethod
    def parse_obj(
        cls: Type[_T], obj: Any, update: Optional[Dict[str, Any]] = None
    ) -> _T:
        obj = cls._enforce_dict_if_root(obj)
        # SQLModel, support update dict
        if update is not None:
            obj = {**obj, **update}
        # End SQLModel support dict
        return super().parse_obj(obj)

Wanted Code
...
Alternatives
It's being used temporarily like this.
from typing import Any, TypeVar, cast

from sqlmodel import SQLModel

_T = TypeVar("_T", bound=SQLModel)

class fix_parse_obj_model(SQLModel):
    @classmethod
    def parse_obj(cls: type[_T], obj: Any, update: dict[str, Any] | None = None) -> _T:
        return cast(_T, super().parse_obj(obj, update))

Operating System
Linux
Operating System Details
OS: Arch Linux x86_64
Host: 82FX Yoga Slim 7 Pro 14ITL5
Kernel: 5.17.4-arch1-1
Uptime: 3 hours, 32 mins
Packages: 969 (pacman), 23 (flatpak)
Shell: zsh 5.8.1
Resolution: 2240x1400, 2560x1080
DE: GNOME 42.0
WM: Mutter
WM Theme: Adwaita
Theme: Arc [GTK2/3]
Icons: Papirus [GTK2/3]
Terminal: vscode
CPU: 11th Gen Intel i5-1135G7 (8) @ 4.200GHz
GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics]
GPU: NVIDIA GeForce MX450
Memory: 5423MiB / 15785MiB
SQLModel Version
0.0.6
Python Version
Python 3.10.4
Additional Context
I'd like to do a "pull requests"
shame I'm not used to git yet...

you can make a pull request by forking the repo to your own account and committing your improvement to a branch there. then there's a create pull request button.
the creator & maintainer has been busy apparently, but at least we've been pulling useful PRs to our fork by ourselves, not many though as the base version has worked mostly fine.

Thanks for the report and the fix @phi-friday ! :cake:
This was solved in https://github.com/tiangolo/sqlmodel/pull/321, the fix will be available in SQLModel 0.0.7, released in the next hours. :tada:


Chart disappearing during pan

I'm submitting a...

[x] bug
[ ] feature
[ ] chore

What is the current behavior
Now I have same problem like #529. My project is build on Next.js and TypeScript. And I'm using function components. During drag a chart, the chart is disappeared. One more thing is HoverTooltip's showing is too slow when the cursor is over on the chart and sometimes it doesn't work. I guess... maybe.. it could be related with SSR issue. But I don't know how to make it work correct.
What is the expected behavior
The chart doesn't disappeared while dragging the chart.
Please tell us about your environment

Version: 1.3.2
Next.js 12.2.4 with TypeScript
https://github.com/IRONDESK/coin-chart/tree/main/src/components/Chart

Other information

I'm having same issue.

I guess... maybe.. it could be related with SSR issue.

Issue still persists, after I imported it as a dynamic component.

@moogii Hi. Recently I cleared this issue. Would you change the file extension next.config.js in root to next.config.cjs. After I renamed it, the issue had gone. And here is my next.config.cjs file.
const withTM = require("next-transpile-modules")([
  "d3-array",
  "d3-format",
  "d3-time",
  "d3-time-format",
  "react-financial-charts",
  "@react-financial-charts/annotations",
  "@react-financial-charts/axes",
  "@react-financial-charts/coordinates",
  "@react-financial-charts/core",
  "@react-financial-charts/indicators",
  "@react-financial-charts/interactive",
  "@react-financial-charts/scales",
  "@react-financial-charts/series",
  "@react-financial-charts/tooltip",
  "@react-financial-charts/utils",
])

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
}

export default withTM(nextConfig)

I found this solution via the terminal error messages when build the project. The terminal was like it needs CJS file extension not JS. I don't know why it works after renamed it and the difference btw JS and CJS. If you fix the issue, could you share your terminal messages when this issue happened? I wanna see them carefully once again.

@moogii Hi. Recently I cleared this issue. Would you change the file extension next.config.js in root to next.config.cjs. After I renamed it, the issue had gone. And here is my next.config.cjs file.
const withTM = require("next-transpile-modules")([
  "d3-array",
  "d3-format",
  "d3-time",
  "d3-time-format",
  "react-financial-charts",
  "@react-financial-charts/annotations",
  "@react-financial-charts/axes",
  "@react-financial-charts/coordinates",
  "@react-financial-charts/core",
  "@react-financial-charts/indicators",
  "@react-financial-charts/interactive",
  "@react-financial-charts/scales",
  "@react-financial-charts/series",
  "@react-financial-charts/tooltip",
  "@react-financial-charts/utils",
])

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
}

export default withTM(nextConfig)

I found this solution via the terminal error messages when build the project. The terminal was like it needs CJS file extension not JS. I don't know why it works after renamed it and the difference btw JS and CJS. If you fix the issue, could you share your terminal messages when this issue happened? I wanna see them carefully once again.

its not working

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: false,
  swcMinify: true,
}

export default nextConfig;

This will solve your problem


Specify numpy version in requirements.txt

Creating a fresh virtual env from the requirements.txt generates a dependency conflict as there is no numpy version specified. Numpy recently upgraded to v2.0, and required dependencies: pyarrow (required in the requirements.txt to be <12.0) and pandas (required in requirements.txt to be  >=1.1.5, <=2.2.0) have listed versions compiled with Numpy v1. This causes a conflict and a failure of an xarray import.
Current behavior
> source .venv/bin/activate
> python

Python 3.10.12 (main, Jul 29 2024, 16:56:48) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xarray as xr

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.1 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

If you are a user of the module, the easiest solution will be to
downgrade to 'numpy<2' or try to upgrade the affected module.
We expect that some modules will need time to support NumPy 2.

Traceback (most recent call last):  File "<stdin>", line 1, in <module>
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/xarray/__init__.py", line 3, in <module>
    from xarray import testing, tutorial
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/xarray/testing/__init__.py", line 1, in <module>
    from xarray.testing.assertions import (  # noqa: F401
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/xarray/testing/assertions.py", line 8, in <module>
    import pandas as pd
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/pandas/__init__.py", line 23, in <module>
    from pandas.compat import (
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/pandas/compat/__init__.py", line 27, in <module>
    from pandas.compat.pyarrow import (
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/pandas/compat/pyarrow.py", line 8, in <module>
    import pyarrow as pa
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/pyarrow/__init__.py", line 65, in <module>
    import pyarrow.lib as _lib
AttributeError: _ARRAY_API not found
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/xarray/__init__.py", line 3, in <module>
    from xarray import testing, tutorial
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/xarray/testing/__init__.py", line 1, in <module>
    from xarray.testing.assertions import (  # noqa: F401
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/xarray/testing/assertions.py", line 8, in <module>
    import pandas as pd
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/pandas/__init__.py", line 46, in <module>
    from pandas.core.api import (
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/pandas/core/api.py", line 1, in <module>
    from pandas._libs import (
  File "/home/tadd.bindas/projects/t-route-dev/.venv/lib/python3.10/site-packages/pandas/_libs/__init__.py", line 18, in <module>
    from pandas._libs.interval import Interval
  File "interval.pyx", line 1, in init pandas._libs.interval
ValueError: numpy.dtype size changed, may indicate binary incompatibility. Expected 96 from C header, got 88 from PyObject

Expected behavior
you to be able to import xarray without errors
Steps to replicate behavior (include URLs)

pip install -r requirements.txt
python
import xarray as xr

Screenshots
See Current Behavior
Recommended action:
Determine a specific version of numpy for t-route to officially support. I FIXED this problem by downgrading my numpy to v1.24.3, however, using <2.0.0 should suffice. The last v1 version is v1.26.5
I'm leaving this as an issue rather than a PR as it should be up to the maintainers what version of a dependency to support 👍

Thanks for the exploratory work and writing this, @taddyb! Just to stay on the safe side of supporting older versions of dependencies and transitive dependencies, I suggest for now we pin numpy~=1.0.


lampo backend interface re-thinking

I had a conversation with @tnull, (an expert in LDK and Lightning), who was kind enough to review my initial of lampo. It is a little bit hacky had buggy but I am not surprised by the code that I wrote on some hot London night in 2022.
The main issue is that the lampo-bitcoind has several bugs events that ldk can take in the wrong way. I need to think about potential solutions and all the bugs, and one possibility might be found here: https://docs.rs/lightning-transaction-sync/latest/lightning_transaction_sync/#usage-example.
I'm uncertain about how to handle the lampo-nakamoto backend. However, it's clear that incorporating lightning_transaction_sync is important for moving towards a well-tested solution and OFC the important part for me is that it is maintained by ldk people 😄. However, we'll need to consider if this allows us the same level of flexibility.

Ok, I finally deallocated some projects in this way I have more time for lampo.
However, I think the backend interface need a full rewrite, and I start playing with it at https://github.com/vincenzopalazzo/lampo.rs/pull/291


Make it more like vscode with customization and options

This is a good plugin, however still find it not as good the built in one that comes with vscode which is pretty perfect in how it works, looks and handles.. they added some extra options to it this year..

Sorry, my personal abilities are limited and cannot be compared to a vscode team


update common readme badges, kitchen.yml platforms

updating common files with changes that are configured in the profiles: readme badges, kitchen.yml platforms

thanks @arlimus


Seperate client uri from server in with-apollo examples

Separating uri parameter passed to Apollo HttpLink in three with-apollo-* examples. The with-apollo-auth is untouched as it is integrated with graphcool more deeply.

Given a typical setting that we have a graphql server running at localhost:3001 and next server running at localhost:3000/, with requests to https://www.foo.bar/graphql forwarded to localhost:3001 and others to localhost:3000.
In the original code in this case, an unnecessary ssl negotiation will happen in SSR (from next server to the reverse proxy and to graphql server) and will consume more time comparing to posting directly to localhost:3001 as they are in the same protected network.

@heyrict I understand your point of view, but for the sake of the example, don't you think it's weird to use the same uri twice for no real reason ?

Hmm, ok. It sounds weird if an example contains much boilerplate code.
Closed.


Bug: Heap-Buffer-Overflow in _sz_find_3byte_serial

Describe the bug
I have used StringZilla in private project and Address Sanitizer has reported Heap-Buffer-Overflow error in _sz_find_3byte_serial function.
==2509==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000d473 at pc 0x560a2491eac3 bp 0x7fffd97c3a60 sp 0x7fffd97c3a50
READ of size 1 at 0x60200000d473 thread T0
    #0 0x560a2491eac2 in _sz_find_3byte_serial /root/.conan2/p/strin3bc98f8dde580/p/include/stringzilla/stringzilla.h:2132
    #1 0x560a2493cd67 in sz_find_serial /root/.conan2/p/strin3bc98f8dde580/p/include/stringzilla/stringzilla.h:2369
    #2 0x560a2493cd67 in sz_find /root/.conan2/p/strin3bc98f8dde580/p/include/stringzilla/stringzilla.h:6390
...

 But when this string passes to sz_u64_vec_t, the code tries to access to fourth byte:
    // We fetch 12
    sz_u64_vec_t h0_vec, h1_vec, h2_vec, h3_vec, h4_vec;
    sz_u64_vec_t matches0_vec, matches1_vec, matches2_vec, matches3_vec, matches4_vec;
    sz_u64_vec_t n_vec;
    n_vec.u64 = 0;
    n_vec.u8s[0] = n[0], n_vec.u8s[1] = n[1], n_vec.u8s[2] = n[2], n_vec.u8s[3] = n[3];

So if we pass to this function std::string_view with length equals 3, n[3] goes beyond the boundaries of the array.
Steps to reproduce
I tried to reproduce this bug though local unit tests, but get failed. I suppose you can try to allocate memory with length 3 on heap and pass it to the function.
Expected behavior
The solution of this problem is removing the work with fourth byte if three-length string. It have tested it locally and unit tests have finished well:
Hi, dear tester! You look nice today!
- Uses AVX2: no
- Uses AVX512: no
- Uses NEON: no
- Uses SVE: no
All tests passed... Unbelievable!

I suppose the correct code line in this case is:
n_vec.u8s[0] = n[0], n_vec.u8s[1] = n[1], n_vec.u8s[2] = n[2];

StringZilla version
v3.10.0
Operating System
Ubuntu 22.04
Hardware architecture
x86
Which interface are you using?
C implementation
Contact Details
<EMAIL_ADDRESS>Are you open to being tagged as a contributor?

[X] I am open to being mentioned in the project .git history as a contributor

Is there an existing issue for this?

[X] I have searched the existing issues

Code of Conduct

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

Great catch, thank you! Can patch in an hour 🤗


"no module named 'usocket'" on Raspberry Pico W

Hi,
I'm trying to use this package in order to run an HTTP Server (Microdot) concurrently with other tasks on Raspberry Pico W.
It's failing for me with:
Traceback (most recent call last):
  File "<stdin>", line 42, in <module>
  File "microdot_asyncio.py", line 320, in run
  File "asyncio/core.py", line 297, in run
  File "asyncio/core.py", line 261, in run_until_complete
  File "asyncio/core.py", line 246, in run_until_complete
  File "microdot_asyncio.py", line 278, in start_server
  File "asyncio/stream.py", line 226, in start_server
ImportError: no module named 'usocket'

Am I doing something totally unsupported yet, like maybe only some subset of CircuitPython devices have usocket?
I know that sockets generally work if I use socketpool for screating sockets, so maybe I'm really looking after https://github.com/adafruit/Adafruit_CircuitPython_asyncio/issues/4 ?
I'd appreciate any pointers!

CircuitPython doesn't have usocket, but you can use socketpool. It looks like the microdot server is written for MicroPython, not CircuitPython, but you could modify it.

I believe that usocket is called from within Adafruit_CircuitPython_asyncio directly.
From what I can see microdot server is only using asyncio and its start_server method, which doesn't sound like depending on MicroPython.
This is my attempt at minimal repro without using Microdot:
import asyncio

async def main():
    async def serve(reader, writer):
        pass

    await asyncio.start_server(serve, "<IP_ADDRESS>", 80)

asyncio.run(main())

Note that I'm not really initializing wifi in my example, but since I would not be able to pass the initialized socket pool to asyncio anyway, it wouldn't help.
The result:
Traceback (most recent call last):
  File "<stdin>", line 9, in <module>
  File "asyncio/core.py", line 297, in run
  File "asyncio/core.py", line 261, in run_until_complete
  File "asyncio/core.py", line 246, in run_until_complete
  File "<stdin>", line 7, in main
  File "asyncio/stream.py", line 226, in start_server
ImportError: no module named 'usocket'

I'll admit that in the meantime I also tried to make a socketpool.SocketPool object pretend to be the usocket module for the sake of asyncio, but it's currently failing for me onsocket objects from there not having a setsockopt method.

You're right, we should change this line:
https://github.com/adafruit/Adafruit_CircuitPython_asyncio/blob/a044da1e7f0c6900cc50f86ad8a372c1144e7709/asyncio/stream.py#L152

Also true, but in my case I think it's about the server part:
https://github.com/adafruit/Adafruit_CircuitPython_asyncio/blob/a044da1e7f0c6900cc50f86ad8a372c1144e7709/asyncio/stream.py#L226

This bit me tonight with the AdaFruit ESP32 Feather V2 as well, so for anybody new and googling - it's not specific to the Raspberry Pico W at all.
I believe this will also affect open_connection calls.

The same applies to the uerrno import on the line above.

I'm having the same issue here, except that I am trying to use the Wiznet W5500-EVB-Pico.
Now, interestingly, this does have a socket implementation already  (adafruit_wiznet5k.adafruit_wiznet5k_socket) .. but how would I set up asyncio` to use that instead?

This bit me also, which is too bad because the official circuitpython story for not supporing interrupts/multithreading (which I get!) is to use asyncio for applications where you need to do more than one thing at a time. For me, that means going back to micropython as I'm building 'headless' apps that rely on microdot/being able to run an async server.
Not super stoked because the story for not having interrupts in circuitpython is is 'use asyncio' per https://learn.adafruit.com/cooperative-multitasking-in-circuitpython-with-asyncio/overview
But, the circuitpython asyncio doesn't work with microdot because they don't implement start_server. So I'm blocked... Please fix this!

.... this issue is still relevant and affects probably all ports.  I was making a switch from Micropython to Circuitpython, but during testing running:
asyncio.create_task(asyncio.start_server(serve_client, "<IP_ADDRESS>", 80))
crashes with
Traceback (most recent call last):
  File "asyncio/core.py", line 261, in run_until_complete
  File "asyncio/stream.py", line 225, in start_server
ImportError: no module named 'usocket'

Major bummer :disappointed: , given that according to docs start_server should be supported.   Shouldn't this be in test coverage?

I believe it really should be fixed. For me, I wasn’t able to continue with micropython because of it. Which is a double bummer because I’ve had to backport so so many drivers. I hope this can be fixed soon, it will make embedded servers much more viable on micropython.
Thank you!
Regards,
Max Carlson

On May 8, 2024, at 11:10 PM, Jev Kuznetsov @.***> wrote:
.... this issue is still relevant and affects probably all ports. I was making a switch from Micropython to Circuitpython, but during testing running:
asyncio.create_task(asyncio.start_server(serve_client, "<IP_ADDRESS>", 80))
crashes with
Traceback (most recent call last):
File "asyncio/core.py", line 261, in run_until_complete
File "asyncio/stream.py", line 225, in start_server
ImportError: no module named 'usocket'
Major bummer 😞 , given that according to docs start_server should be supported. Shouldn't this be in test coverage?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

I believe it really should be fixed. For me, I wasn’t able to continue with micropython because of it.

Just to clarify, I think you mean CircuitPython here? I've been using microdot on MicroPython for years with no issue whatsoever...

Have any of you tried the source version and just fixed the import names? I started a PR to do that. It's quite simple.

Yes, sorry I misspoke - I meant CircuitPython. I’ve had to stick with Micropython so I have asynchronous http support and my embedded server leaves time for other tasks to run. It’s quite amazing what the pico can do!
Regards,
Max Carlson

On May 9, 2024, at 8:16 AM, Matt Trentini @.***> wrote:
I believe it really should be fixed. For me, I wasn’t able to continue with micropython because of it.
Just to clarify @mcarlson, I think you mean CircuitPython here? I've been using microdot on MicroPython for years with no issue whatsoever...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Have any of you tried the source version and just fixed the import names? I started a PR to do that. There are only a few lines to change. It might still be the case that something doesn't work.

You mean rebuilding CP?  Could you please link to your PR?

Please send a link to the PR/branch/commit and I’d be happy to give this a test! I’d so love to be using CircuitPython… Thank you!
Regards,
Max Carlson

On May 9, 2024, at 5:47 PM, Jev Kuznetsov @.***> wrote:
Have any of you tried the source version and just fixed the import names? I started a PR to do that. There are only a few lines to change. It might still be the case that something doesn't work.
You mean rebuilding CP? Could you please link to your PR?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

You mean rebuilding CP? Could you please link to your PR?

I just mean changing the names in this library. Just get the Python (not .mpy) version of this library and edit it so the import names match. e.g. change import usocket as socket to import socketpool as socket, etc.

@dhalbert - ... couple of hours further it does not seem that simple.
I replaced import usocket as socket in start_server by this:
import wifi
import socketpool

socket = socketpool.SocketPool(wifi.radio)

It helpled a bit - the server could be started. only to crash later with
Traceback (most recent call last):
  File "/lib/asyncio/core.py", line 261, in run_until_complete
  File "webserver.py", line 16, in serve_client
  File "/lib/asyncio/stream.py", line 100, in readline
AttributeError: 'Socket' object has no attribute 'readline'

BTW, there is more smelly stuff in stream.py , like
    from uerrno import EINPROGRESS  # there is no `uerrno` in circuitpython
    import socketpool as socket  # these are not equivalent.

It does not not feel right to keep hacking further without proper test cases in place. That would not be trivial to do, because we'd need descent mocks first on a unix port.

Would https://github.com/micropython/micropython/blob/master/tests/run-tests.py be useful as the basis for a testing framework?
Regards,
Max Carlson

On May 10, 2024, at 6:39 AM, Jev Kuznetsov @.***> wrote:
@dhalbert - ... couple of hours further it does not seem that simple.
I replaced import usocket as socket in start_server by this:
import wifi
import socketpool
socket = socketpool.SocketPool(wifi.radio)
It helpled a bit - the server could be started. only to crash later with
Traceback (most recent call last):
File "/lib/asyncio/core.py", line 261, in run_until_complete
File "webserver.py", line 16, in serve_client
File "/lib/asyncio/stream.py", line 100, in readline
AttributeError: 'Socket' object has no attribute 'readline'
BTW, there is more smelly stuff in stream.py , like
from uerrno import EINPROGRESS # there is no uerrno in circuitpython
import socketpool as socket # these are not equivalent.
It does not not feel right to keep hacking further without proper test cases in place. That would not be trivial to do, because we'd need descent mocks first on a unix port.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Any path forward here?

I think there are two things going on here:

The u prefix needs to be removed in all places where it's used.
microdot uses .readline() on a Socket, which is not standard in CPython and is not implemented in CircuitPython.

If your goal is to just have an HTTP server, then there is https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer, but it is not async.

We are just starting to merge MicroPython v1.21 through v1.23 into CircuitPython. A side effect of this will be updating this asyncio library from the version that is in https://github.com/micropython/micropython/tree/master/extmod/asyncio.
I talked with @tannewt briefly about this in discord. We need start_server() if we don't have it already.
See https://github.com/miguelgrinberg/microdot/issues/214 as well.

I would love it if there was because circuitpython is so appealing in so many ways!
Personally, I’ve had to stick with micropython because of these issues. I need an embedded web server!
Regards,
Max Carlson

On Jul 12, 2024, at 2:19 AM, Sveinung Kval Bakken @.***> wrote:
Any path forward here?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

I need an embedded web server!

Have you looked at https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer, or do you need the async support?

Yes, I need the async support. Otherwise I can’t easily use sensors, control lighting etc. etc.
Regards,
Max Carlson

On Jul 12, 2024, at 11:09 AM, Dan Halbert @.***> wrote:
I need an embedded web server!
Have you looked at https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer, or do you need the async support?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

I'm doing several tasks, for sensors etc, but anything more than a second or so between each check if the socket the web experience seems very bad.
There's async support in the socket itself in MP, but the same doesn't seem present in CP. See the socket callback registered here.
https://github.com/orgs/micropython/discussions/12219#discussioncomment-6713393
The code to register, check and invoke these subscriptions are not present in CP's socket.c as far as I can tell.
I'm getting an exception when trying to run the same code as this only expects integer or buffer as 3rd arguments.
Socket.c:346
If we could register a callback, we could queue the task to process the request was my angle.

I would love it if there was because circuitpython is so appealing in so many ways!

CircuitPython is great - and I'm not trying to convince you otherwise! - but I am interested in why you'd prefer CircuitPython over MicroPython here? Perhaps you've had a bad experience with MicroPython? Which may give us MicroPython folks a chance to learn...
Not to take anything away from CircuitPython, but I'm always interested in improving the experience for MicroPython users.

No bad experience with Micropython, It’s an amazing piece of software! Miles and miles better than the old C++ AVR/arduino days the last time I tuned into this channel…
I think they’re both great for different things. Circuitpython has such a wealth of drivers for different things, e.g. rgb(w) light strip support is far more advanced than what’s available for Micropython, e.g. I had to spend a lot of time and effort improvinghttps://github.com/blaz-r/pi_pico_neopixel/commits/main/  to get it closer to the way I needed it to work - including backporting a bunch of work already done in circuitpython to have better RPI PIO drivers, improve APIs etc. etc.
If I was in the circuitpython universe I would have been there already. The same seems to be true with drivers in general.
I insist on having a good async web server for headless operation and stable bluetooth support for device discovery and federation, so I’ve stuck with micropython. The sticking point for me really has been inadequate support for https://github.com/miguelgrinberg/microdot  ( which has been really, really great.) in circuitpython...
Micropython seems to be more robust and stable for asynchronous ops and ‘low-level’ work, while Circuitpython has much better support for easily and quickly supporting various devices and sensors.
I really wish there’d never been a fork - that was a huge mistake. The Micropython people should have listened to the wisdom of Lady Ada, and now they’re having to do a lot of the same kinds of hardware abstractions she wanted anyway…
Regards,
Max Carlson

On Jul 12, 2024, at 3:36 PM, Matt Trentini @.***> wrote:
I would love it if there was because circuitpython is so appealing in so many ways!
CircuitPython is great - and I'm not trying to convince you otherwise! - but I am interested in why you'd prefer CircuitPython over MicroPython here? Perhaps you've had a bad experience with MicroPython? Which may give us MicroPython folks a chance to learn...
Not to take anything away from CircuitPython, but I'm always interested in improving the experience for MicroPython users.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

That’s been my experience also. It’s very frustrating discovering this several days into a project when everything is working great and you try to go headless...

On Jul 12, 2024, at 3:24 PM, Sveinung Kval Bakken @.***> wrote:
I'm doing several tasks, for sensors etc, but anything more than a second or so between each check if the socket the web experience seems very bad.
There's async support in the socket itself in MP, but the same doesn't seem present in CP. See the socket callback registered here.
https://github.com/orgs/micropython/discussions/12219#discussioncomment-6713393
The code to register, check and invoke these subscriptions are not present in CP's socket.c as far as I can tell.
I'm getting an exception when trying to run the same code as this only expects integer or buffer as 3rd arguments.
Socket.c:346
If we could register a callback, we could queue the task to process the request was my angle.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

I would love it if there was because circuitpython is so appealing in so many ways!

CircuitPython is great - and I'm not trying to convince you otherwise! - but I am interested in why you'd prefer CircuitPython over MicroPython here? Perhaps you've had a bad experience with MicroPython? Which may give us MicroPython folks a chance to learn...
Not to take anything away from CircuitPython, but I'm always interested in improving the experience for MicroPython users.

Please don't ask this in an issue. You can follow up outside of the issue instead if you want. Here it is off-topic.


Script to create a qooxdoo.d.ts and publish to DefinitelyTyped

If we publish a qooxdoo.d.ts to https://github.com/DefinitelyTyped/DefinitelyTyped it will be picked up automatically by IDEs (eg Visual Code); there will still be a place for the target output because contribs and developer's own libraries will need to be output, but by publishing to DefinitelyTyped, new users will find that Qooxdoo is recognised by their IDE by default.
The work in creating a qooxdoo.d.ts is already done as part of target output, so all that remains for this issue is to generate qooxdoo.d.ts for just qx.* (which might require some kind of include/exclude filter in config.json) and a script to create a PR to https://github.com/DefinitelyTyped/DefinitelyTyped

since the qx compiler can generate this on the fly, there might be an even simpler route ... by putting the project.d.ts file into a suitable location in the project it will get picked up by visual code automatically ... one location where this does work is source/class/<project>/ but I guess this is somehow configurable ... I just have not yet figured out how :)

The hybrid approach is the right way to go, because every class has to be compiled in order for type completion to work this is quite an overhead for qx.* because of it's shear size and most users will be using a standard release so precompiling is very helpful.
Not sure how we handle versions, I can see that DT support versions so presumably Visual Code will have a way to select which version to use?

I looked to tech details yesterday but did not find anything ... maybe I was just too tired :(

@oetiker @johnspackman Is this something that should happen before release or should it be postponed?

@oetiker @johnspackman Thoughts?


Move to docs.rs for hosting documentation

See #754 for discussion on this.

[x] spot check what's published at docs.rs matches our API docs
[x] check for broken links on the docs.rs pages for Rusoto
[ ] get feedback if the list of crates on our API docs is helpful or not
[x] update codegen to point at docs.rs for our API docs on published crates https://github.com/rusoto/rusoto/pull/1411
[x] update our READMEs, main landing one, rusoto_core and credentials https://github.com/rusoto/rusoto/pull/1411
[ ] remove our documentation publishing step in travis.yml
[x] https://rusoto.org/ docs link updated https://github.com/rusoto/rusoto.github.io/pull/109

So I'd like to help you guys with this, but I'm a bit of a newbie to all this, including open source contributions. Here are a few of my thoughts and where to go from here:

Regarding broken links: I didn't see any broken external links based on a spot check, but perhaps the real solution to this is a crawler script to go and check that each external link results in a HTTP 200? Internal links within docs.rs all seem OK.
Regarding docs.rs: One major problem, IMO, is that if i just go to docs.rs, and type in "rusoto", the first project on the list is the 0.24.1 deprecated project. When I click it, there is no indication it is outdated. That docs.rs page links to the main Github page, which also has no indication or warning about 0.24.1 vs 0.32.x. Perhaps one TODO item can be to update the 0.24.1 release to include documentation pointing to the newer project, and making it extremely clear this project is no longer in use.
The list of crates on the API docs (https://www.rusoto.org/supported-aws-services.html) is simply a list of links to the corresponding crates.io project and AWS doc page. The crates.io pages aren't super helpful by themselves, since they just point back to the rusoto.github.io or rusoto.org page. Perhaps a TODO can be to update this list with links to each respective docs.rs and crates.io page?
Regarding your fourth checklist item, updating codegen to point at docs.rs, perhaps you can be more specific as to what you're looking for here. Perhaps a TODO here is that individual README.md files within each API (e.g. https://github.com/rusoto/rusoto/tree/master/rusoto/services/acm) could be updated to include docs.rs links, is that what you had in mind?

Sorry if I'm just creating more work for you by posing a bunch of questions, but hopefully if we iron these details out now we can get it right the first time. Let me know if any of these TODOs sound reasonable to you and I can start working on one or two.

Thing I like to have is both release docs and master branch docs. I think there are patterns for having both

It may just be a matter of what you link provide in your cargo.toml files. https://docs.rs/rusoto_s3/0.34.0/rusoto_s3/ works fine if you visit directly.

To me, https://github.com/rust-lang/docs.rs/issues/159 continues to block moving to docs.rs for documentation hosting. It's also not seen any movement for a year. 😢

With documentation builds both taking a long time with the latest version of Rust and docs.rs being where the community is settling on where to put documentation, let's make this happen!

I've release Rusoto 0.24.2 so anyone landing at https://docs.rs/rusoto/ will see the mega-crate is deprecated.
https://www.rusoto.org/supported-aws-services.html 's links to services go to crates.io where all "Documentation" links on crates.io go to the service's docs on https://rusoto.github.io/rusoto/ .
A few spot checks of links on our pages docs.rs all work for me, no broken links

I think working through the checklist in the first comment of this issue will let us get this all done and off TravisCI entirely. 👍

Regarding cross-crate discoverability, I don't recall anyone aside from myself worried about it. It's not something I'm super hung up over: there are multiple ways to find crates, such as searching on crates.io, using https://rusoto.org , search engine of choice, etc...
I'm of the opinion the quicker we can get off TravisCI, the better. 😄

Is there a way I can help?
I tried the docs.rs documentation at it was much better than the current docs. With the current docs I often have the problem that the tabs die and that they load very long. With docs.rs I didn´t have the problem.

Thanks for the offer!
All our documentation links should point to docs.rs after our next release, which will happen in the next week or so. 👍


Check if we have already invited a candidate email id before

So, we don't end up sending them the same quiz twice. However, we should allow resending the link to a candidate who hasn't taken the quiz yet.

Fixed.


Supersonic: Add version 0.9.1

Added Supersonic, a lightweight cross-platform desktop client for Subsonic and Jellyfin music servers.

Closes #12956

[x] I have read the Contributing Guide.

/verify

/verify


elasticsearchERROR Illegal char <:> at index 6: zipkin:span-2019-03-06 windows7 elasticsearch-2.3.1

windows7
elasticsearch-2.3.1
elasticsearchERROR Illegal char <:> at index 6: zipkin:span-2019-03-06
126  https://github.com/openzipkin/zipkin/blob/release-2.12.3/zipkin-storage/elasticsearch/src/main/java/zipkin2/elasticsearch/internal/IndexNameFormatter.java
350-355 https://github.com/openzipkin/zipkin/blob/release-2.12.3/zipkin-storage/elasticsearch/src/main/java/zipkin2/elasticsearch/ElasticsearchStorage.java

can you give the full stack trace or error message? colon isn't disallowed
until elasticsearch 7

@adriancole
elasticsearch.log
Hello

Zipkin + elasticsearch-2.3.1 +WIN7 error
Zipkin + elasticsearch-2.3.1 + centos6.5 success
I don't think it is an elasticsearch error because win7 can't use a colon as a folder name.

Is your Elasticsearch server run on Windows and does it need to be? If it is just to test locally, maybe you can use Docker to run Elasticsearch?

I hope this colon can be specified with a different symbol such as ES_DATE_SEPARATOR so I can specify @

@brightvip this sounds like a bug in ES. let's please verify that first
@openzipkin/elasticsearch does anyone know if ES intentionally has a constraint about colons in index names, or if this was a bug fixed.
I want to separate this from the other issue about ES 7 as we've gone multiple years with no problems reported on colons and need to conserve time as making a change here also implies one in other places.

2.x is really old and I don't have a Windows machine at hand, so I cannot try it out, but I have a hunch: We used the index name as the folder name in Elasticsearch's data directory. I think with 5.0 this was changed to use a UUID to avoid any issues with file systems and special naming patterns in them (like calling an index .., etc). Is : generally not allowed on Windows and you are trying to create a folder with such a name?
From Elasticsearch's point of view the colon will only be disallowed in 7.0 and you can see the current rules for disallowed characters in https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/cluster/metadata/MetaDataCreateIndexService.java#L162-L188.

thanks for the advice @xeraa


How can i build my dotnet core application?

I have the docker standard image. It states that the .NET Core sdk is instaled. But I can not run and dotnet commands...I want to run the dotnet restore and dotnet build. But not sure which VSTS Tasks to use? Using the new VSTS Build views.
Any hints?

Found the issue...if using the new Preview Feature: New Build Editor there might be some issue with the cmd line runner.