Inspector doesn't display exported properties of custom resource written in C#

Godot version:
master / 7be49849
OS/device including version:
Manjaro Linux 18.0.4
Issue description:
I made the following simple custom resource for a test in C#, but the inspector doesn't show its exported properties when I built the project and attached the source to a blank resource file:
namespace AlleyCat.Morph
{
    public class RangeddMorphDefinition : Resource
    {
        [Export]
        public string Key { get; set; }

        [Export]
        public string DisplayName { get; set; }

        [Export]
        public float Default { get; set; }

        [Export]
        public bool Hidden { get; set; }
    }
}

How it is displayed in the inspector:

I can't reproduce this. It does show up for me. Can you provide an example project?

@neikeq It used to work before, so there's a chance that there is something wrong on my end.
I'll try to create a minimal project soon as requested, and let you know if it's still reproducible. Thanks!

Today I tried it again with a minimal project but could not reproduce the issue. I suppose there are some specific things in my project that prevent it from working correctly.
I'll reopen the issue with more details later, if I find an actual problem on the Godot's end. Sorry for the confusion!


2020 demo participation not yet published

Hi Tim,
could you have a look why the merged PR from @ChrisSchoe did not get published to the result website?
https://github.com/bpmn-miwg/bpmn-miwg-test-suite/pull/857
Cheers,
Falko

Seems like this has been resolved, probably some time ago.


Bootstrap tweaks (on master)

This applies the tweaks from #243 on master to both the bootstrap script and the go boostrap. It also includes custom refspecs from #237 which are related.
Here are some examples:

/cc @keithpitt

:+1:


Merge German translation docs.

Merge the German translation docs 'general-notes.md' and
'special-terms.md' into one translation guide 'german.md'.

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

@derAnfaenger can you fix the linter failures?

@derAnfaenger you should post a comment once you've fixed things; otherwise I don't know it's ready for review again :)

Merged, thanks @derAnfaenger!  I think now we're in a good position for German to join Spanish on the list of languages at 100% :).

@timabbott my bad, I planned on doing so but went to sleep after Travis tests hadn't started after over an hour of fixing the PR. Do you know if this is common/some process delayed Travis?

Basically Travis CI's free open source plan gives you 5 worker jobs, and it works through a queue of all PRs.  So during periods when a ton of people are doing stuff (e.g. end of GCI), it can fall behind.
There are 3 ways we can make it better:

Make our Travis CI build faster through optimizations like #3620.
Decrease the number of builds by dropping Python 2 support (probably going to happen in the next few months).
Paying Travis CI a bunch of money to give us more workers (going up to 10 jobs would cost about $3K/year).


UI: fix segment status color remains same in different table page

What does this PR do?

fix segment status color remains same in different table page

Screenshot
before
https://user-images.githubusercontent.com/41536903/205152186-65e4441e-0d89-4107-8521-5c5938cdb40c.mp4
after
https://user-images.githubusercontent.com/41536903/205152206-343924f4-5dc1-442c-9246-40c9424241f8.mp4

Codecov Report

Merging #9891 (5da3b9e) into master (9690b2d) will decrease coverage by 9.19%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #9891      +/-   ##
============================================
- Coverage     24.99%   15.79%   -9.20%
- Complexity       44      175     +131
============================================
  Files          1966     1925      -41
  Lines        105835   103763    -2072
  Branches      16056    15806     -250
============================================
- Hits          26451    16390   -10061
- Misses        76709    86178    +9469
+ Partials       2675     1195    -1480

Flag
Coverage Δ

integration1
?

unittests2
15.79% <ø> (?)

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

Impacted Files
Coverage Δ

...src/main/java/org/apache/pinot/sql/FilterKind.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ain/java/org/apache/pinot/core/data/table/Key.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/java/org/apache/pinot/core/data/table/Table.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../java/org/apache/pinot/core/data/table/Record.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../java/org/apache/pinot/core/util/GroupByUtils.java
0.00% <0.00%> (-100.00%)
:arrow_down:

.../java/org/apache/pinot/common/auth/AuthConfig.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...va/org/apache/pinot/core/routing/RoutingTable.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ava/org/apache/pinot/sql/parsers/PinotSqlType.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...a/org/apache/pinot/core/operator/BaseOperator.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...va/org/apache/pinot/common/config/NettyConfig.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 961 more

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


Modify: Python.Python.3.6 version 3.6.7

This pull request is automatically generated by 🥟 Dumplings
Microsoft Reviewers: Open in CodeFlow

/AzurePipelines run


Allow GraphiQL apps control over closing tabs

Allow GraphiQL apps control over closing tabs
This feature is about closing tabs.
Current functionality:

When closing a tab, it just happens, the tab is removed and all state is gone

Requested functionality

Grant possibility to give control to the user (i.e. the app that mounts the GraphiQL component) if they are OK with closing a particular tab
This could for instance be an dialogue "Are you sure you want to close the tab?"

In our case, we are working on a Collection plugin that you can click to read saved queries / variables / headers from a DB, and this opens it in a new tab. So we need to sync tabState with the list of Collection items. And if a user starts to change a Collection item, we want to warn the user that changes will be lost.
It is the same as if the user selected a file in a code editor, started to change it, and then tries to close the tab.
Mock screenshots

this is awesome, and makes a lot of sense! i'm glad you're able to achieve this with your app. just the one change,,I hope that's ok!

Absolutely, I don't mind a little boy scouting, looks much cleaner now overall. I think this looks good to go now.
PS:

i'm glad you're able to achieve this with your app.

Yea, it totally works - but... Since the plugin is handling its own state management and its own data fetching, it is a bit tricky, since I need the top level component that mounts  to essentially get the confirmation from a component further down the component tree. I got it to work using event emitters and listeners, which I think is not React-kosher but still fine, since I don't want to lift state further up, that price is much higher to pay since I want my plugin to manage its own state.

Just sharing my solution FYI, like I said I am fine with this.

@acao Are we good to go?

@thomasheyenbrock can you take a look at this as well? 🙏


Qn: tailwind usage

Hi. sorry for raising it as an issue; but curious how the below work.
  &:hover {
    @apply bg-gray-300;
  }

https://github.com/taigabrew/dashboad-demo/blob/master/assets/css/editors.css#L8
the tailwind doc say, it doesn't work
Note that variants like hover:, focus:, and {screen}: can't be applied directly, so instead apply the plain version of the utility to the appropriate pseudo-selector or media query.

I see it is working for you. Please let me know how.
thanks.
bsr

https://github.com/postcss/postcss-nested
looks like this is the answer. thanks


RP2040 timer interrupt for application use?

I have a basic Raspberry Pi Pico project that uses embassy-time for most timing, but I would like to have access to a periodic timer interrupt for a non-embassy chunk of code.  Does the embassy-rp HAL offer another timer that can be used when the TIMER peripheral is being used by embassy-time?  I haven't found anything in the documentation along these lines, which may mean I'm misunderstanding something fundamental. Thanks.

Can you post a sample of your code or what you're trying to do?

Because it depends on what you mean by non-embassy, if this "non-embassy" needs to not take a dependency on embassy-rs's timer, you'll probably have to expose some sort of trait from that code to be implemented by your embassy code.

Thank you for responding.
It is not easy to post example code.  But a little background may clarify things.
There is an existing embedded application running on custom hardware.  It is C based and runs on a preemptive RTOS somewhat similar to Xinu.  The ultimate goal would be to port it all to Rust/Embassy.
However, before committing to that effort, several proof of concepts need to be done.  The first was rewriting the bare bones of the RTOS in Rust.  This was done on QEMU x86-64.  Here it uses the periodic interrupt timer to drive its preemptive scheduler.
The next step that I'm trying is to demo this running this on real hardware, a Raspberry Pi Pico.  Using the Embassy-rp HAL could save a lot of driver work for me.  I would also like to show Embassy async code running side by side with the legacy RTOS code.  Maybe this can be done by running the Embassy async code in one of the RTOS managed threads. I have not got that far yet.
The RTOS needs some sort of periodic interrupt.  The TIMER is an option, but I don't immediately see how to share it with the embassy-time option enabled.  That is, somehow provide a callback from the RTOS that the timer driver can call in addition to what does for embassy-time.
Is there some other interrupt source the RTOS could use?
Another option is to not enable embassy-time, but I prefer not to do that if at all possible.

Is the ultimate goal to rewrite the application or rewrite the RTOS and application?
If your goal is to rewrite the RTOS, it sounds like your RTOS needs to expose a Timer trait that you implement using using embassy, something like Timer::after_xxx(duration). Pass in a callback into this timer function to be invoked after the delay is over. Again, hard to give advice unless there's some sort of details regarding how you expect this callback to be invoke.
If your goal is to rewrite the application... do you even need this RTOS? If "The ultimate goal would be to port it all to Rust/Embassy" then why even write an RTOS, you don't need an RTOS with embassy, it replaces the need for one.. If you need to do some form of scheduling for the application, then you can do something like channels which lets you basically enqueue work to be consumed by listeners. I'm using this in my project to schedule periodic work to do things like take readouts from sensors and send messages back to the main program via usb without polling.

Yes, ultimately the RTOS will hopefully go away.  But there will be a period of time where both will need to coexist.
If I understand correctly, I should take the "time-driver" option off of embassy-rp.  Then have the RTOS implement its own time-driver and expose that to embassy. Basically copy what embassy-rp does?

Well, an unexpected hang on my first attempt. Learning is fun, often only after the fact. :)
For testing I simplified things, but maybe too simple?  Here's main.rs (san 'use,' 'extern', etc.):
#![no_std]
#![no_main]

#[entry]
fn main() -> ! {
   let p = embassy_rp::init(Default::default());
   unsafe {
       mos_time_driver::init();
   }
   loop {}
}

It is spinning inside embassy_rp::init(), at the call to Peripherals::take(). It never makes it to my new mos_time_driver::init() call.
compiler_fence (\rustc\129f3b9964af4d4a709d1383930ade12dfe7c081\library\core\src\sync:3726)
__cpsie #[inline] (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\cortex-m-0.7.7\asm\inline.rs:52)
enable (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\cortex-m-0.7.7\src\call_asm.rs:11)
acquire (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\embassy-rp-0.1.0\src\critical_section_impl.rs:66)
acquire (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\embassy-rp-0.1.0\src\critical_section_impl.rs:29)
_critical_section_1_0_acquire (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\critical-section-1.1.2\src\lib.rs:283)
acquire #[inline] (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\critical-section-1.1.2\src\lib.rs:183)
with<embassy_rp::Peripherals, fn(critical_section::CriticalSection) -> embassy_rp::Peripherals> (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\critical-section-1.1.2\src\lib.rs:226)
take (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\embassy-hal-internal-0.1.0\src\macros.rs:54)
init (d:\packages\cargo\registry\src\index.crates.io-6f17d22bba15001f\embassy-rp-0.1.0\src\lib.rs:342)
__cortex_m_rt_main (d:\Projects\mos\src\main.rs:46)
__cortex_m_rt_main (d:\Projects\mos\src\main.rs:42)

mos_time_driver.rs is embassy-rp/src/time_driver.rs with TimerDriver changed to MosTimeDriver.  No code added yet to drive the RTOS.
I had to add a few things to the toml file. And there's stuff I don't need yet for the simplified code.
[package]
name = "mos"
version = "0.1.0"
edition = "2021"

[dependencies]
embassy-rp = { version = "0.1.0", features = [
    "defmt",
    "unstable-pac",
    "critical-section-impl",
] }

embassy-time-driver = { version = "0.1", features = ["tick-hz-100"] }
embassy-sync = "0.6"
atomic-polyfill = "1.0.1"
critical-section = "1.1"

embassy-time = { version = "0.3.1", features = [
    "defmt",
    "defmt-timestamp-uptime",
] }

defmt = "0.3"
defmt-rtt = "0.4"
cortex-m = { version = "0.7.6", features = ["inline-asm"] }
cortex-m-rt = "0.7.0"
panic-probe = { version = "0.3", features = ["print-defmt"] }

[profile.release]
debug = 2

Looks like I was hitting #1736. I changed "embassy-rp::critical-section-impl" to "cortex-m::critical-section-single-core" and it no longer hangs.

Looks like the sys tick may be better option to drive the RTOS timer. It does not look like it is being used by other embassy features.
    let core_periph = Peripherals::take().unwrap();
    let mut syst = core_periph.SYST;
    syst.set_reload(SYST::get_ticks_per_10ms());
    syst.clear_current();
    syst.enable_counter();
    syst.enable_interrupt();
...

#[exception]
fn SysTick() {
    println!("SysTick\r");
}


make logger

Currently, the predicted expression of many genes are NaN.  The code produces NaNs when the genotypes do not match one of a set of specified criteria.  I need to make a logger that records which criteria a gene does not pass.  I should also make a summary logger which summarizes the findings of the logging.

logger is in working order


Web client is unable to detect screen resizing

I enabled browser console during loading, after disabling it I have permament reduction of screen space used by web version of AB.
Not sure is it fixable from within AB or it it an upstream limitation.

I set dump_raw_events = true in widgetry/src/runner.rs and manually fiddled with window size. winit doesn't fire any events at all for resizing, opening/closing the developer console, etc. There may be a way to check for screen size changes manually -- https://github.com/rust-windowing/winit/issues/1491. I'll experiment with this later.

I can take a look at this!


new wish - resizable columns

Hi,
the plugin is so good that i don't want to use any other table plugin. One feature and that will make the table all usable: 'resizable colmns'. can you shed some light on this feature, or give some hints on this?
thanks..

@ssjogus, thanks for using this component. In addition, the resizable columns is a nice feature for table component. I will implement it but not in near future cause of the implementation is not easy and I'm busy on work. Anyway, if this feature supported, I'll mention you :)


Including durability in data reader/writer fastrtps

Changes look good to me! Thanks for the contribution @ahcorde. I'm going to run our CI job on this branch to make sure it passes the tests:
CI:

Linux:

OS X:

Looks like this change introduced an internal FastRTPS test failure on OSX:
http://ci.ros2.org/job/ci_osx/1226/testReport/projectroot.test.unittest/transport/UDPv6Tests/
@ahcorde, do you know what's going on there?

@gerkey I doubt the test failure is related to this patch since the same test failure is also present in the nightly builds on OS X (http://ci.ros2.org/view/nightly/job/nightly_osx_debug/138/testReport/projectroot.test.unittest/transport/UDPv6Tests/) since Jun 23rd. Btw it is also ticketed: eProsima/Fast-RTPS#55

By the way http://ci.ros2.org/job/ci_osx/1228/ is the osx job run again with the same parameters and those connext issues are gone

Well, that's two pieces of great news!
Shall we merge this change, then?

if we can leave it for a few hours longer it will help me show that the fix I have underway for https://github.com/eProsima/ROS-RMW-Fast-RTPS-cpp/issues/48 works independently

Works for me, @dhood.

good to merge thanks


Version upgrade for Flutter & Android Build Tools

Version upgrade in beta, dev and stable.

No hope to upgrade to the latest versions?

Seems like no. But you can always submit a PR or do in your own Fork as I did:
https://github.com/jjrbfi/docker-flutter
I haven't use that repository for a while. I ended using my own Dockerfile + X11 forwarding + Shared directories. Is more user friendly to me.


[model] AddRelPositionMultiHeadedAttention

FILL IN THE PR DESCRIPTION HERE
FIX #4736
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

@cillinzhang can you guide me a bit regarding this issue?

@cillinzhang can you guide me a bit regarding this issue?

Sorry, I have been too busy lately to pay attention. And Because RelPositionMultiHeadedAttention is a bit complicated, we are trying rotary_emb attention install of RelPositionMultiHeadedAttention. Thank you very much and this issue can take a break.


⚠ 한경주요지수-코스피200 has degraded performance

In 2c9c9d0, 한경주요지수-코스피200 (https://markets.hankyung.com/indices/kospi200) experienced degraded performance:

HTTP code: 200
Response time: 8263 ms

Resolved: 신규상장 performance has improved in 9a9a173.


Document Deployment 'Tracks'

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2941
Originally created by @kgpayne on 2021-09-16 18:50:29

Meltano is incredibly versatile by design, meaning it can be used and deployed using a very broad range of tools and techniques. This breadth is clearly advantageous, but it can also mislead newcomers. We would therefore like to create 'tracks' in our marketing materials and documentation to reflect the archetypal usage scenarios:

Personal Use; deploying Meltano locally and on free or low-cost hosting platforms.
Commercial Use, Alongside Existing Data Estate; deploying Meltano to extend an existing platform, including to replace another ELT tool.
Commercial Use, Greenfield; deploying a data platform from scratch using Meltano.

Both commercial use cases carry production level expectations for operational excellence (incl. logging, monitoring, alerting), reliability, performance, security and cost optimisation.

View 7 previous comments from the original issue on GitLab


Add extend-add-pairwise instructions x64

This is a refactoring based on comments. The lowering remains intact it is just that now the clif instruction operands are more instructions. Matching in lowering is now different to properly match on the WASM instruction we are intending to lower.
The CI failures appear to be from an unrelated issue. Wish I new how to resolve but I can see a stoppage on a dead code warning.
This should be the last PR for full x64 Wasm SIMD support. Of course there are some refactoring and clean-up TODOs that should be done as follow-up.

I personally wouldn't rely only on the conformance test suite, we've already had problems with it. Pretty sure you've got some bugs here and I guess the existing test suite isn't exercising them.

Hi @sparker-arm .. I was planning to check/compare the lowering after comments from this first update, but do you see something specifically in case I miss it? I agree, the spec tests have shown to sometimes be cut-n-paste exercises that aren't thoughtful for the specific instructions. Not sure the best way to provide an answer key though for this lowering sequence. The lowering is not derived by me, but it's based on the discussion during instruction proposal and cross checked against what v8 appears to be doing, and finally of course spec tests which is there to catch errors though it is not fool-proof.

This is intended to be ready. If there is anything else let me know.


Requires ACC on latest release

콤마3 이슈 외에 제보를 받고있지 않습니다.
please post only comma3 issues.
*Describe the bug
Previous release worked great on 2020 Premier. Now pressing set or speed control on wheel gives "enable adaptive cruise to engage". There also is no enable comma pedal setting in the UI.
To Reproduce
Steps to reproduce the behavior:

Go to set-
Click on set-
Scroll down to comma screen
See error

**Expected behavior
As in prior release, expect LKAS to function
Additional context
Add any other context about the problem here.

Thx for report.  I will update the procedure to run(which Toggles need in ui settings, or make default set toggles, ... ) Openpilot.
Anywa, this repository still keeps "Previous release" that you've mentioned. Named v0819-c3

Thanks!
Sent from my iPhone

On Jul 23, 2023, at 4:38 PM, jc01rho @.***> wrote:

Thx for report. I will update the procedure to run(which Toggles need in ui settings, or make default set toggles, ... ) Openpilot.
Anywa, this repository still keeps "Previous release" that you've mentioned. Named v0819-c3
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

Will be happy to test - just pop me an email
Sent from my iPhone

On Jul 23, 2023, at 5:58 PM, andy turudic @.***> wrote:
Thanks!
Sent from my iPhone

On Jul 23, 2023, at 4:38 PM, jc01rho @.***> wrote:

Thx for report. I will update the procedure to run(which Toggles need in ui settings, or make default set toggles, ... ) Openpilot.
Anywa, this repository still keeps "Previous release" that you've mentioned. Named v0819-c3
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

Here is settings-Toggle page in comma 3,
Written in Korean.

OK. Thanks.
I did have OpenPilot enabled, but your second screenshot shows many settings I did not.
I'm traveling in an hour, so am reverting to v0819-c3 for now, but will try it out later this week.
Sent from my iPhone

On Jul 23, 2023, at 6:41 PM, jc01rho @.***> wrote:

Here is settings-Toggle page in comma 3,
Written in Korean.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

Hi,
0.0819-c3 Reversion is working again with autosteer on the 2020.
Do you have a test checklist or plan I can do so we can add the '20 as tested?
Sent from my iPhone

On Jul 23, 2023, at 7:00 PM, andy turudic @.***> wrote:
OK. Thanks.
I did have OpenPilot enabled, but your second screenshot shows many settings I did not.
I'm traveling in an hour, so am reverting to v0819-c3 for now, but will try it out later this week.
Sent from my iPhone

On Jul 23, 2023, at 6:41 PM, jc01rho @.***> wrote:

Here is settings-Toggle page in comma 3,
Written in Korean.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

before the checklist, please tell me that you are using comma3 without CommaPedal? So only steer.

Hi,
I have a fairly new Comma3.
Pedal Interceptor board
GM harness from Comma.ai
2020 Premier with LKAS, brake alert, and cruise control (no radar).
Steer still works. I prefer "Torque" vs PID.
Visual ACC also now works (it didn't before...would try to run over cars being followed). It's a bit annoying in its conservatism, so am on the fence on its utility with default settings.
Ran it for 100km just now, probably 80km on highway (100km/h) and 20km city, with final leg of 10km climbing 400m elevation with sharp mountain curves that overwhelm it (as they did before).
https://m.youtube.com/watch?v=_E2WvCHFMuM
The lane identifier/tracker works very well, just that the steer is too timid to follow it faithfully.
Fake ACC is also a bit dangerous, even though poor drivers would assume it's safer with longer follow distance. Other cars cut in because of the excessive follow distance, forcing an unexpected regen brake (with brake lights) for following cars to react to (a 100km/h to 80km/h aggressive slowing with nothing visible ahead that would have triggered it), in order to maintain that crazy distance. I would cut it by half to 2/3 of present values.
Anyway, I am very happy to have it back working again with the reversion after a few days of it being dead with the update. I'm city driving to/from school to my mountain home, so will take another try at the new release when I get some time in the next week or two.
Meanwhile, I think a good idea to add the 2020 as "tested", assuming I can check off all items on your "go" list. Can do same on the new release in a week or two.
Thank you for the crazy amount of investigation and work you guys put in on this. I'm an EE, so I understand the effort put into this.
cheers,
andy
ps do you know of any comprehensive CAN bus deciphering documentation for the Bolt EV? I'd like to build some hardware for the inverter and charger/battery at some point. An incomplete list is better than the one I don't have.
Sent from my iPhone

On Jul 23, 2023, at 8:08 PM, jc01rho @.***> wrote:

before the checklist, please tell me that you are using comma3 without CommaPedal? So only steer.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

thx for detail review.
Embarrassingly, there is no perfect checklist.
But if the speed control and steering control work well, I think that's a test, so we've added BoltEV 2020 to our list of tested vehicles.
The CAN bus deciphering documentation I have does not exist, all CAN stuff is inspired by opgm (https://github.com/opgm/openpilot).

BoltEV 2020 added to "Tested" with commit
https://github.com/jc01rho-openpilot-BoltEV2019-KoKr/boltpilot/commit/8466f37d4eafbc456503319f32611a38e8e9fcfe

Hi,
I forgot to mention (sorry), imperial units works fine in your fork, so you can remove the metric restriction.
cheers,
-andy
Sent from my iPhone

On Jul 23, 2023, at 10:51 PM, jc01rho @.***> wrote:

BoltEV 2020 added to "Tested" with commit
8466f37
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.


Lock objc to 0.1.7. Fix remaining libc pointer errors with casts. Fix warnings in cursor example.

This fixes #654

Build was successful on nightly osx, stable linux and two of the windows builds. Each of the others seem to have either timed out due to cargo hanging on an update or crashed in some unrelated process :tada:

Ahhhh, despite this change working for glutin, users will likely still run into problems downstream as the cocoa crate also depends on objc, in turn creating an objc version conflict. For example, when I try to build conrod (with the local working glutin version) I get:
failed to select a version for `objc` (required by `glutin`):
all possible versions conflict with previously selected versions of `objc`
  version 0.1.8 in use by objc v0.1.8
  possible versions to select: 0.1.7, 0.1.6, 0.1.5, 0.1.4, 0.1.3, 0.1.2, 0.1.1, 0.1.0

Which doesn't seem to get fixed no matter how many times I cargo update or cargo clean.

@mitchmindtree, sorry again that the objc update has contributed to this mess :/
It's not the most elegant, but one way to sidestep this issue would be to replace all uses of *mut libc::c_void with usize, like:
diff --git a/src/api/cocoa/mod.rs b/src/api/cocoa/mod.rs
index 2b4b5e5..1e5000b 100644
--- a/src/api/cocoa/mod.rs
+++ b/src/api/cocoa/mod.rs
@@ -81,7 +81,7 @@ impl WindowDelegate {

         extern fn window_should_close(this: &Object, _: Sel, _: id) -> BOOL {
             unsafe {
-                let state: *mut libc::c_void = *this.get_ivar("glutinState");
+                let state: usize = *this.get_ivar("glutinState");
                 let state = state as *mut DelegateState;
                 (*state).pending_events.lock().unwrap().push_back(Closed);
             }
@@ -90,7 +90,7 @@ impl WindowDelegate {

         extern fn window_did_resize(this: &Object, _: Sel, _: id) {
             unsafe {
-                let state: *mut libc::c_void = *this.get_ivar("glutinState");
+                let state: usize = *this.get_ivar("glutinState");
                 let state = &mut *(state as *mut DelegateState);

                 let _: () = msg_send![*state.context, update];
@@ -109,7 +109,7 @@ impl WindowDelegate {
                 // TODO: center the cursor if the window had mouse grab when it
                 // lost focus

-                let state: *mut libc::c_void = *this.get_ivar("glutinState");
+                let state: usize = *this.get_ivar("glutinState");
                 let state = state as *mut DelegateState;
                 (*state).pending_events.lock().unwrap().push_back(Focused(true));
             }
@@ -117,7 +117,7 @@ impl WindowDelegate {

         extern fn window_did_resign_key(this: &Object, _: Sel, _: id) {
             unsafe {
-                let state: *mut libc::c_void = *this.get_ivar("glutinState");
+                let state: usize = *this.get_ivar("glutinState");
                 let state = state as *mut DelegateState;
                 (*state).pending_events.lock().unwrap().push_back(Focused(false));
             }
@@ -143,7 +143,7 @@ impl WindowDelegate {
                 window_did_resign_key as extern fn(&Object, Sel, id));

             // Store internal state as user data
-            decl.add_ivar::<*mut libc::c_void>("glutinState");
+            decl.add_ivar::<usize>("glutinState");

             delegate_class = decl.register();
         });
@@ -160,7 +160,7 @@ impl WindowDelegate {
         unsafe {
             let delegate = IdRef::new(msg_send![WindowDelegate::class(), new]);

-            (&mut **delegate).set_ivar("glutinState", state_ptr as *mut libc::c_void);
+            (&mut **delegate).set_ivar("glutinState", state_ptr as usize);
             let _: () = msg_send![*state.window, setDelegate:*delegate];

             WindowDelegate { state: state, _this: delegate }

That way a mismatch between the libc versions in glutin and objc doesn't cause any errors.

Or just use *mut () instead of usize.

I'm not sure *mut () will work, it needs to be a type for which an Objective-C type encoding is known.
*mut _ also doesn't seem to work, since then the type is unconstrained; these methods can take any type, not just *mut c_void.

@SSheldon all good! It can be easy to overlook breakages sometimes especially when it's just in a version increment heh.
I tried building this again locally, however a wild #656 appeared. I don't have a windows system available to me atm so I'm unable to address this.
I did however try just updating kernel32-sys to 0.2 to appease the issue locally, however I was unable to see if this fixed anything as I'm now stuck behind rust-lang/cargo#2090, as is travis it seems. :confused:

Ok, let's merge this.


Updated for swift 5 and XCode 11.2

I tried to objective-git in a react-native project, but had issues importing the module in swift.
I have made these changes to the modulemap and the project settings to make it work.

I had similar issues - see #699 for some of my issues and eventual solution

What to do here, to make CI work ?


Can't change combat tracker position

I'm not sure why, but I can't seem to change the position of the combat tracker in the stream view using the module settings. I was, however, able to move the chat log. The combat tracker is always located at the top of the window, near the left side, regardless of the pixel settings.

Working as expected here. I would guess there's some sort of module conflict, please try to reproduce in a world with just Stream View enabled.
If it works with just this module enabled, try enabling other modules until you find the one that's causing the problem and we'll see if we can get them to be compatible.

I also can't change the combat tracker position. I can't even turn the auto combat tracker off.

Do you have problems in a world with just Stream View enabled? Both of these features test as working fine here, and I can't really investigate without knowing whether it's a particular module that is causing the issue.

I found the culprit. It is popout resizer.
I don't know why for a while I couldn't turn the combat tracker off. That issue has fixed itself.

Gotcha, going to close this as a duplicate of #16
And the corresponding Popout Resizer issue:
https://github.com/Cardagon/popout-resizer/issues/10


Add basic alarm component

Hi guys, i'm using your component somfy tahoma. Beautifull work! I'm wondering when the alarm will be integrated? I'm a volunteer for testing if needed ;) Thanks

@Glenn1986 which device do you have? Could you create a new issue with all the details of your device. You are the only tester for now. :)

Would the Somfy Protect alarm be supported with this integration ? Seems that the Somfy One / One+, Somfy Home Alarm and Somfy Security Camera can be integrated with TaHoma support.somfyprotect.com.
Thanks !

Hi @WhistleMaster , thanks for your interest.
The alarm component is still under development, but we want to support as many devices as possible. Do you own some of them? If so, can you test this branch? To do so, download the zip following this link, unzip it, and replace the tahoma directory installed by HACS by the one in the zip. Once done, restart HA and give it a try.
As we don't own alarms on our end, we rely on the community to help us develop it.

I have the Somfy Home Alarm and the Somfy Security Camera, but not yet the TaHoma box. I'll get one to do the tests.

@vlebourl I think this branch is broken currently, hopefully I have some spare time this / next week to fix it. :)
I believe the Security Camera is hard to integrate with HomeAssistant by the way..

@WhistleMaster would you be willing to help me a bit with the Somfy Home Alarm and Security Camera's? I don't have any devices to test.

Hi mick I would like to help you! The problem at the moment is that I can not login on tahomalink.com. Very strange though, I can login on somfy.be and than open my tahomo box. I did mail to somfy but no answer at the moment. I let you know when the problem is solved.

Sure ! That’s funny because I received the Tahoma box yesterday. I just need to setup everything and then I can help you on that !

@WhistleMaster haha, that's a great timing. Based on my research, it will be really hard to support the cameras. They are not controlled via Tahomalink API, it looks like there is a different platform for Somfy Protect...
Home Alarm could probably be supported.

But according to this link, it seems that the camera feed can be seen from the Tahoma App, right ?

But according to this link, it seems that the camera feed can be seen from the Tahoma App, right ?

True, but I can not seem to find it in their API. Let's have a closer look over the coming weeks, after you have installed your box / devices 👍


[Proposal] Automatic background segment compaction

Motivation
In Druid, segment size is important because it affects to query performance. If it is too small, druid spawns too many threads each of which read only a few bytes. If it's too large, query execution might not be fully parallelized.
Since the size of each segment can vary according to data distribution, it's difficult to optimize created segment size at ingestion time, especially for realtime indexing.
To handle this problem, operators usually have to setup compaction tasks manually which have still some problems like manual segment handling and unsupported concurrent execution of indexing tasks and compaction tasks.
Goals
This proposal is to introduce a new feature of automatic background segment compaction.

Coordinator runs compaction tasks periodically.
A compaction job reads a set of segments, and writes new optimized-in-size segments if necessary.
Compaction tasks must support atomic segment update, which means, for the same intervals, either new segments or old segments can be visible at any time.
Compaction tasks must not block indexing tasks from being started.

Challenge & solution
Druid is using a versioning system for atomic segment update. Whenever new segments are written for the same interval, they have higher versions than old segments.
This versioning system works well for normal indexing tasks, but it makes difficult to run compaction tasks and index tasks which appends data to existing data sources (hereafter appending tasks) at the same time.
For example, it would be very common to run compaction tasks while appending tasks are running for the same data source (ex, realtime tasks). In this case, the result of appending tasks must be visible which means they have the same version with the existing segments of the destination data source. Here, if the compaction task increases the version of segments, result segments of appending tasks will be overshadowed because they have a lower version.
A simple solution might be increasing the version of result segments of appending tasks accordingly whenever compaction tasks are finished. However, this will block appending tasks as well as query execution while updating segment versions.
As a result, we need a new mechanism for overshadowing only before-compaction segments. The proposed solution is lazy overshadowing which is marking overshadowed segments and let druid coordinators clean them periodically. The new segments created by compaction tasks are in the inactive (i.e., not used) state when they are created. The coordinator atomically activates them when it clean the segments marked as overshadowed. More details are presented in the below section.
Segment compaction
Segment compaction modes

Major compaction: this mode reads existing segments (ex, IngestSegmentFirehose) and writes optimized segments. In this mode, the compaction results in more than one output segments from a subset of input segments. For example, segments A,B,C can be merged into D,E. This mode can generate more optimized segments, but requires more complicated locks across the entire cluster.
Minor compaction: this mode simply merges existing segments. The compaction always merges a subset of input segments into a single segment. For example, segments A,B,C can be merged into D. This mode might result in sub-optimal segments, but can run with a small lock.

This proposal focuses on the minor compaction.
1. Compact segment generation

The coordinator runs a compaction task.
The compaction task gets a lock for all input segments. This lock is to prevent input segments from being removed or modified by other tasks during compaction. Read-only tasks can read segments without any segment locks.
Merge old segments into new ones. The new segments are in the inactive (not used) state. These segments include which old segments are overshadowed by themselves. This information is stored in the payload column of the druid_segments table of the metastore.
Repeat 3 until all input segments are processed.

Changes in Payload
DataSegments are serialized as bytes and stored in the payload column of the druid_segments table of the metastore. A new variable overshadowedSegments will be added to DataSegment which contains the information about the segments overshadowed by this segment. This is represented by a range of which the start and the end are the combination of <interval, version, shardSpec> of the start and end segments.
Segment locking
This proposal requires a new locking mechanism, segment locking.

The overlord maintains locks for segments in addition to the existing interval locks.
When a replacing task (like compaction tasks, rebuilding tasks) is submitted, it requests to get a lock to the overlord.
If any segment or interval locks exist for the requested segments, the task waits for getting a lock.
If there is no lock for the requested segments, the task gets a lock and starts its job.
When the lock is released can depend on applications. Compaction tasks release the segment lock when all old segments are replaced with new segments.

Note: Segment locks can be viewed as an extension of interval locks. While the current interval locks can be acquired for only an interval, segment locks can be acquired for a subset of the entire segments of an interval. Segment locks and interval locks block each other. If some tasks are using interval locks for some intervals, segment locks for the segments which fall into those intervals cannot be acquired and the tasks must wait for the interval locks to be released. Similarly, interval locks cannot be acquired if there already exist segment locks corresponding to the requested intervals.
2. Atomic segment update

This algorithm is to achieve atomic segment update with a small lock.

When a compaction task is finished, it pushes new segments to the deep storage and writes metadata in metastore.
The coordinator allocates new segments to historicals by running load rules for the new segments.
When a historical loads a new segments, it checks that it has old segments overshadowed by the newly loaded segment. If it has, it immediately removes those segments. Finally, it activates the new segment and announces the changes. The segment replacement should be atomic.
The coordinator/broker updates timeline according to historiocals' announcements. Once it detects a new segment is loaded by a historical, it immediately removes old segments overshadowed by the new one from its timeline. The segment replacement should be atomic.
The coordinator removes remaining overshadowed segments in background. When it's done, the segment lock for removed segments is released.

Note that locking is required only when historicals and coordinators replace old segments with new ones.
Implementation plan for compaction task
I'm going to add a compaction task running with a single process as the first step. And then, I'll parallelize it as the second step. For the task parallelization, I'll raise another issue soon.
The compaction task divides a set of input segments into several groups and runs sub tasks for each group which are similar to the existing merge task. Each sub task simply merges input segments into a single segment. Note that the merge can occur across the segments of the different intervals.

I have to admin that this proposal is quite complicated and tricky. I'll raise another proposal for this problem soon.


chore: correct minor spelling mistake in package name

minor bugfix for package.json, switching astor to astro

@strn3 Thanks!


Support new SProd

https://github.com/PennyLaneAI/pennylane/pull/5287

Labelling this as a "bug" since it needs to be fixed before the next PL ecosytem release.

I think this was fixed with #935, @dime10 can you also confirm?

I think so? 😅


sorry sd card is not accessible

Expected Behaviour
Encoded barcode shared with others.
Actual Behaviour
Error appeared: Sorry. SD Card is not accessible.
Reproduce Scenario (including but not limited to)
I am using ionic v4 with default tabs template:
ionic info

  Ionic:
     ionic (Ionic CLI)             : 4.12.0 (C:\Users\lag\AppData\Roaming\npm\node_modules\ionic)
     Ionic Framework               : @ionic/angular 4.3.0
     @angular-devkit/build-angular : 0.13.8
     @angular-devkit/schematics    : 7.3.8
     @angular/cli                  : 7.3.8
     @ionic/angular-toolkit        : 1.5.1

  Cordova:

     cordova (Cordova CLI) : 9.0.0<EMAIL_ADDRESS>     Cordova Platforms     : android 8.0.0
     Cordova Plugins       : cordova-plugin-ionic-keyboard 2.1.3, cordova-plugin-ionic-webview 4.0.1, (and 7 other plugins)

  System:

   (C:\Program Files (x86)\Android\android-sdk)
     NodeJS            : v10.8.0 (C:\Program Files\nodejs\node.exe)
     npm               : 6.2.0
     OS                : Windows 8.1

Installed plugin as mentioned in documentation and work correctly:
/* https://ionicframework.com/docs/native/barcode-scanner */
ionic cordova plugin add phonegap-plugin-barcodescanner
npm install @ionic-native/barcode-scanner

Steps to Reproduce
When barcode generate to screen, clicking to share button and error appeared. Immediately after, page closed automatically.
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Android 7.1.1
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
Tested with OUKITEL K6
Cordova CLI version and cordova platform version
cordova --version
  9.0.0<EMAIL_ADDRESS>
cordova platforms
  Installed platforms:
    android 8.0.0
  Available platforms:
    browser ^6.0.0
    electron ^1.0.0
    ios ^5.0.0
    osx ^5.0.0
    windows ^7.0.0

Plugin version
cordova plugin version | grep phonegap-plugin-barcodescanner
  phonegap-plugin-barcodescanner 8.0.1 "BarcodeScanner"

Sample Code that illustrates the problem
/* sample.page.html */
....
<ion-toolbar>
 <ion-buttons slot="end">
   <ion-icon name="barcode" size="large" (click)="makeBarcode()"></ion-icon>
 </ion-buttons>
  <ion-title>BARCODE TEST</ion-title>
</ion-toolbar>
....

/* sample.page.ts */
....
makeBarcode() {
  let tmpCODE = "demoTest";

  this.barcodeScanner
    .encode(this.barcodeScanner.Encode.TEXT_TYPE, tmpCODE)
    .then(
      dataEncoded => {
        //Do Nothing
      },
      err => {
        console.log("BARCODE ENCODE - ERROR: " + err);
      }
    );
}
....

Logs taken while reproducing problem
N/A

Further investigations about sd card have shown that it doesn't work anymore so I'll try with a new one


Does the LoadWAV binding make sense?

https://github.com/veandco/go-sdl2/blob/master/sdl/audio.go#L334
LoadWAV takes a pointer to an AudioSpec, then also returns a pointer to an audiospec, I think the same pointer.  Is the return value redundant/unecessary?

Hi @jackmott, you're right that it's redundant. @malashin has implemented the change so you won't need to pass the *AudioSpec anymore.

Great, seems solved to me.


RFC: Multiple data sources

Summary
Allow a single DAB instance to interact with multiple backend data sources.
Motivation
This design enables DAB to address more sophisticated customers.
Old behavior
Currently, DAB supports only a single data source and a single dab-config.json file.
Barriers to multiple data sources:

The data-source property in the config is of type object, not array.
The data-source property in the config applies to every entity.

New behavior
Support the use of multiple dab-config.json files, each corresponding to a different data-source, to merge at runtime.
⭐ When DAB starts, the GLOBAL and CHILD files will be merged.
Design goals:

A single dab-config.json file must always be viable in DAB.
We will not impose arbitrary limits on data-source or entities at this time.
Developers must easily understand which file has an error.
entity names across all files must be unique to support future features.

Sample global file
{
  "$schema": "https://github.com/Azure/data-api-builder/releases/download/v0.7.6/dab.draft.schema.json",
  "data-source-files": [
     "dab-config.mssql-hr.json",
     "dab-config.cosmosdb-sales.json",
     "dab-config.mysql-inventory.json",
     "dab-config.postgres-shipping.json",
   ],
  ...
}

Global file characteristics

The global file must have runtime properties.
The global file's data-source property is optional.
The global file's data-source-files property is optional.
Paths in data-source-files may include Unicode characters.

New data-source-files property in JSON schema.
{
  "$schema": "https://json-schema.org/draft-07/schema",
  "data-source-files": { // new property
      "type": "array",
      "description": "Child file paths",
      "items": {
        "type": "string"
      },
      "default": []
  }
}

This new property, of type string[], is optional. If the data-source-files property is [] or omitted, the data-source property is required. Otherwise, the data-source property is optional.
Path translation
When filled, the data-source-files property contains paths to child files. These paths can include dots . and slashes / & \, indicating the location of the child file relative to the global config file.
If the global config file is at c:\web\api\dab-config.json, then:

Path in Config
File Location

dab-config.02.json
c:\web\api\dab-config.02.json

./dab-config.03.json
c:\web\api\dab-config.03.json

../dab-config.04.json
c:\web\dab-config.04.json

/other/dab-config.05.json
c:\web\api\other\dab-config.05.json

../web/dab-config.06.json
c:\web\api\dab-config.06.json

Child file characteristics

A child file must have a data source defined.
A child file may define data-source-files, which can be thought of as "grandchild" files.
A child file may be used as a global file if it has runtime properties set.
If a child file has runtime properties, they will be ignored; the global file is always used.
A child file can be named anything and be located in any accessible folder relative to the global file.

@JerryNixon as the requirement is under development, is there a chance to extend it a little bit to "more than sophisticated" customers regarding the routing of the api ?
Currently, according to the specification, if the entity name doubles in the two data sources, the entity name needs to be replaced manually by the customer. For the automated tools that generate APIs based on the database metadata for different databases, it would be required to add the prefix or suffix per database for the entity name, like Db1_User, Db2_User.
I propose to use the urls to distinguish between the child databases, like /api/db1/user, /api/db2/user, etc. The root /api/user would refer to the global configuration file.
Is it possible to change that piece of the functionality?
kind regards,
Kamil

This is complete. @rohkhann we believe this was completed for both GQL and REST, which is why it was left open.