WIP: FW landing abort use REPOSITION

This updates FW landing abort to send a REPOSITION command to a location above the intended landing waypoint. I think this is safer than the current mechanism that overwrites the mission item with a loiter. It also resets the mission index to the location of MAV_CMD_DO_LAND_START (if available).
Landing abort is no longer ignored past flare. There are certain situations where a vehicle may flare incorrectly and the pilot still needs to abort. #6456
Needs to be tested. Currently no way to send abort (MAV_CMD_DO_GO_AROUND) from QGC.
FYI @Antiheavy

closes #5292

We can flight test this once we get a Abort button in Qgc.  Questions:

Is the REPOSITION command effectively just a commanded a loiter at a given position?
How to you set the altitude of the new position? possibilities to consider:
RTL_RETURN_ALT
the altitude of the landing complex mission item MAV_CMD_NAV_LOITER_TO_ALT
How does MIS_LTRMIN_ALT and MIS_TAKEOFF_ALT interact with this, if at all
what is the "mode" shown in Qgc and logs when Abort is active?
after Abort will the aircraft loiter at the abort reposition until the operator switches back into Mission mode or until some other failsafe triggered such as low battery or loss of comms?

Thanks, actual testing would be great. I'll test it in simulation a few times first.

REPOSITION is the mechanism (mavlink and internal vehicle command) you use in QGroundControl to click and go to a point. It's loiter/hold at specified coordinates
previously abort would keep you in mission mode but now loitering above land, this changes the mode of the autopilot to loiter (displayed as HOLD in QGC) and resets the mission to the start of the land.
If you flip back into mission mode the landing restarts. If you do nothing it loiters indefinitely or until the battery failsafe kicks in.
the mode may be loiter, but the roll (and heading) are limited until after climb out.
the abort loiter altitude is currently max(landing altitude + MIS_LTRMIN_ALT, current alt + 2 * FW_CLIMBOUT_DIFF). It could use a bit more thought.

a bit more thought:
I guess setting the MIS_LTRMIN_ALT to a safe altitude above trees and terrain would be smart and would make this work.  PX4 default for MIS_LTRMIN_ALT is 1.2 meters which would be dangerous for most fixed wing applications - just have to be sure we don't leave this parameter at default.
MIS_LTRMIN_ALT would also be used as the transition altitude back to MAV_CMD_NAV_LOITER_TO_ALT which could theoretically be above MIS_LTRMIN_ALT.  This might not be desired.  Hopefully switching to RTL mode instead of Mission after an abort would cause the aircraft to climb to RTL_RETURN_ALT on it's way back to the MAV_CMD_NAV_LOITER_TO_ALT.
Curious, what is the reason behind "current alt + 2*FW_CLMBOUT_DIFF"?

MIS_LTRMIN_ALT and MIS_TAKEOFF_ALT should be defaulting to 25m for FW, but if you directly set SYS_AUTOSTART on your vehicle it skips over the auto config (SYS_AUTOCONFIG 1) section. For your personal use I'd set all the parameters you care about in the config.
The altitude is a bit arbitrary. I wanted to make sure there was always some straight and level climbout on abort trigger. If you abort above land altitude + MIS_LTRMIN_ALT it would go straight into a loiter at that altitude. The assumption when auto landing and triggering abort is that the operator knows something the autopilot doesn't. In the case of abort FW_CLMBOUT_DIFF is the minimum altitude error needed to force the level climb out behaviour before regular loiter. As I said it's a bit arbitrary, and I didn't want to hardcode a value. If possible I like to avoid having every little thing configurable as a parameter.

@dagar is this done now? Its marked WIP.

It's untested. Once the button is exposed in QGC (https://github.com/mavlink/qgroundcontrol/pull/4546) it will be flight tested.

@dagar The button PR is blocked on review feedback that seems sensible: https://github.com/mavlink/qgroundcontrol/pull/4546

What's really missing from https://github.com/mavlink/qgroundcontrol/pull/4546 is a good mechanism for the autopilot to tell the GCS it's landing so that we don't need to always show the button.
@LorenzMeier any ideas for where that could fit into mavlink common? Extending EXTENDED_SYS_STATE seems like a bad idea for current SiK radio users, and I don't suppose I can get away with adding another MAV_LANDED_STATE? A new message (LANDING_STATUS) for a single field seems wasteful, although I'm now thinking of other information it could contain.

@Dagar we flight tested the fixed wing abort function using a test build PX4 with the change in this PR and a test build of Qgc that has an ABORT button exposed during flight.
When the ABORT button is pressed during normal flight nothing happens (as expected?).  When the ABORT button is pressed at any point during the landing QGC says "aborting" and the aircraft climbs in a controlled manner to a loiter over the LAND point.  It stays in Mission mode so activating any other waypoint causes the aircraft to immediately fly there and continue the mission from that point.
https://github.com/mavlink/qgroundcontrol/pull/4546 is now merged and the FW landing abort in this PR seems to work as intended.

Landing abort changes pulled into RTL landing PR. https://github.com/PX4/Firmware/pull/6727


Support android

In android StatusBarManager.getHeight is undefined, but StatusBarManager.HEIGHT is defined. Can we consider this in the library?

#4


Landscape orientation not working properly on iOS devices

At first, nice package and thanks for your contribution.
### Current Behavior
I lock stream screen to landscape mode with a package call 'react-native-orientation-locker', and the camera view did lock to landscape mode on android devices. However, it doesn't work with iOS devices, the camera view is still use portrait mode and it seems like it rotate 90 degrees with weird zoom out view.
It seems like when the camera got invoked or RTMPPublisher component got initialized, the orientation hasn't locked to landscape mode so the camera still take portrait view.
Does rtmp-publisher camera locked to portrait on iOS devices by default or any way we can change the camera orientation mode?
Stream screen component
...other code
 const [orientation, setOrientation] = useState()

 useEffect(() => {
        setTimeout(() => Orientation.lockToLandscape(), 1000)
        Dimensions.addEventListener('change', ({window: {width, height}}) => {
            if (width < height) {
                setOrientation('PORTRAIT')
            } else {
                    setOrientation('LANDSCAPE')
            }
        })
    }, [])
```

    return (
        <View style={styles.container}>
            <StatusBar hidden={true} />
            {permissionGranted && orientation === 'LANDSCAPE' && (
                <RTMPPublisher
                    ref={publisherRef}
                    streamURL={streamUrl}
                    streamName={streamKey}
                    style={styles.camStyle}
                    onConnectionFailed={handleOnConnectionFailed}
                    onStreamStateChanged={handleOnStreamStateChanged}
                />
            )}

...other code
`

Packages:

"react-native": "0.72.10",
"react-native-rtmp-publisher": "^0.4.7",
"react-native-orientation-locker": "^1.6.0",

same issue

any solution yet?

any solution yet?

I switched to another package

@stalteri can you please refer me to the package which is working fine?

@stalteri can you please refer me to the package which is working fine?

of course, its @api.video/react-native-livestream

@stalteri can you please refer me to the package which is working fine?

https://github.com/apivideo/api.video-reactnative-live-stream


New version: StefHeyenrath.GitHubReleaseNotes version <IP_ADDRESS>

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

/AzurePipelines run

Manual Validation ended with:

7:43:22 AM:
2024-02-02 07:43:21.164 [FAIL] Installer failed security check. Url: https://github.com/StefH/GitHubReleaseNotes/releases/download/<IP_ADDRESS>/GitHubReleaseNotes.zip Result: 0x80004005

(Automated response - build 695.)

Manual Validation ended with:

7:43:22 AM:
2024-02-02 07:43:21.164 [FAIL] Installer failed security check. Url: https://github.com/StefH/GitHubReleaseNotes/releases/download/<IP_ADDRESS>/GitHubReleaseNotes.zip Result: 0x80004005

(Automated response - build 695.)

Hi @StefH,
The package didn't pass a Defender or similar security scan. This might be a false positive and we can rescan tomorrow.
(Automated response - build 695.)

@stephengillie
Probably because Fody and Fody.Costura is used to include all dependencies to generate a single exe file.

Hi @StefH,
This manifest removes Apps and Features entries that are present in previous PR versions. Should these entries also be added to this version?
(Automated response - build 701.)

Dear @stephengillie,
Thanks for replying, can you please elaborate more on this?
My steps:

Previously I did have a WiX setup MSI, however I could not install this because of a warning in Windows
So I decided to only zip the exe and install the exe as portable.

/AzurePipelines run

/AzurePipelines run

Hi @StefH,
The package didn't pass a Defender or similar security scan. This might be a false positive and we can rescan tomorrow.
(Automated response - build 719.)

/AzurePipelines run

Hi @StefH,
The package didn't pass a Defender or similar security scan. This might be a false positive and we can rescan tomorrow.
(Automated response - build 731.)

Automatic Validation ended with:

Installation failed with exit code -1978335187 2024-02-12 15:57:40.301 [FAIL] Installer failed security check. Url: https://github.com/StefH/GitHubReleaseNotes/releases/download/<IP_ADDRESS>/GitHubReleaseNotes.zip Result: 0x80004005

(Automated response - build 731.)

@wingetbot run

Hi @StefH,
The package didn't pass a Defender or similar security scan. This might be a false positive and we can rescan tomorrow.
(Automated response - build 745.)

[Policy] Needs-Attention

[Policy] Validation-Defender-Error

Automatic Validation ended with:

Installation failed with exit code -1978335187 2024-02-14 14:50:13.525 [FAIL] Installer failed security check. Url: https://github.com/StefH/GitHubReleaseNotes/releases/download/<IP_ADDRESS>/GitHubReleaseNotes.zip Result: 0x80004005

(Automated response - build 745.)


support click-through-prediction

Codecov Report

Merging #189 (49191ce) into master (74c653d) will increase coverage by 0.54%.
The diff coverage is 34.12%.

@@            Coverage Diff             @@
##           master     #189      +/-   ##
==========================================
+ Coverage   59.49%   60.04%   +0.54%
==========================================
  Files          41       41
  Lines        5175     6242    +1067
==========================================
+ Hits         3079     3748     +669
- Misses       1698     2073     +375
- Partials      398      421      +23

Impacted Files
Coverage Δ

master/local_cache.go
0.00% <0.00%> (ø)

master/master.go
0.00% <0.00%> (ø)

master/rpc.go
0.00% <0.00%> (ø)

model/click/evaluator.go
92.30% <ø> (ø)

model/click/unified_index.go
71.96% <ø> (ø)

model/model.go
0.00% <ø> (ø)

model/ranking/knn.go
76.72% <0.00%> (-2.85%)
:arrow_down:

model/ranking/search.go
50.87% <0.00%> (ø)

model/click/search.go
56.31% <4.44%> (ø)

master/recommend.go
29.41% <9.67%> (-0.38%)
:arrow_down:

... and 52 more

Continue to review full report at Codecov.

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


Cannot use derived Deserialize impl for enums

When trying to deserialize a query string containing enum values encoded as strings, it fails with an "enum expected" error message.
Here's a repro code (with deserialization via serde_json thrown in for comparison):
             extern crate serde;
#[macro_use] extern crate serde_derive;
             extern crate serde_json;
             extern crate serde_qs;

#[derive(Deserialize, Debug)]
#[serde(rename_all = "lowercase")]
enum TestEnum { Foo, Bar }

#[derive(Deserialize, Debug)]
struct TestStruct {
    e: TestEnum,
}

fn main() {
    println!("serde_json: {:?}", serde_json::from_str::<TestStruct>(r#"{"e": "foo"}"#));
    println!("serde_qs: {:?}", serde_qs::from_str::<TestStruct>("e=foo"));
}

This produces:
serde_json: Ok(TestStruct { e: Foo })
serde_qs: Err(Error { err: "invalid type: string \"foo\", expected enum TestEnum" })

If we don't use #[derive(Deserialize)] however, and implement it manually for the enum type (like here), the enums will be correctly deserialized.

Hey,
Currently we only support tagged enums (see the example: https://github.com/samscott89/serde_qs/blob/master/examples/introduction.rs#L135).
So you could have the following:
#[derive(Deserialize, Debug)]
#[serde(rename_all = "lowercase")]
#[serde(tag = "type", content = "value")]
enum TestEnum { Foo, Bar }

#[derive(Deserialize, Debug)]
struct TestStruct {
    e: TestEnum,
}

fn main() {
    println!("serde_qs: {:?}", serde_qs::from_str::<TestStruct>("e[type]=foo"));
}

I will revisit the logic though, because it should at least be possible to deserialize UnitVariants as in your example.

Yes, that would be great to have :) I'll just continue using the manual impl workaround for now. Thanks!

Okay, I've finished the overdue refactor of the code. It should now happily serialize/deserialize all forms of enums in the following way.
Suppose you have a struct and enum like so:

    #[derive(Deserialize, Debug, PartialEq)]
    enum E {
        B,
        S(String),
    }

    #[derive(Deserialize, Debug, PartialEq)]
    struct Query {
        e: E,
    }

Then this would be de/serialized from/as either "e=B" or "e[S]=Hello+World" depending on which variant you have.

Let me know if this works for you and I'll publish this is 0.2.

Almost :) One problem I encountered is that since tuple_struct is no longer forward_to_deserialize_any, it now seems to mandate always being deserialized from a sequence. This breaks if a tuple struct is using a custom deserializer.
Here's a (somewhat complex) repro case:
             extern crate serde;
#[macro_use] extern crate serde_derive;
#[macro_use] extern crate serde_json;
             extern crate serde_qs;

use std::fmt;

use serde::de::{self, Deserialize, Visitor};

#[derive(Deserialize, Debug, Clone, Copy)]
#[serde(rename_all = "lowercase")]
enum TestEnum { Foo, Bar }

#[derive(Deserialize, Debug)]
struct TestStruct {
    e: TestEnum,
}

#[derive(Debug)]
struct TupleStruct(TestEnum, TestStruct);

impl<'de> Deserialize<'de> for TupleStruct {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
        where D: de::Deserializer<'de>
    {
        deserializer.deserialize_tuple_struct(
            "TupleStruct", 2, TupleStructVisitor)
    }
}

struct TupleStructVisitor;
impl<'de> Visitor<'de> for TupleStructVisitor {
    type Value = TupleStruct;

    fn expecting(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
        write!(fmt, "TupleStruct representation")
    }

    fn visit_map<V>(self, map: V) -> Result<Self::Value, V::Error>
        where V: de::MapAccess<'de>
    {
        let inner_de = de::value::MapAccessDeserializer::new(map);
        let test_struct: TestStruct = Deserialize::deserialize(inner_de)?;

        let result = TupleStruct(test_struct.e, test_struct);
        Ok(result)
    }
}

#[derive(Deserialize, Debug)]
struct NestedStruct {
    ts: Vec<TupleStruct>,
}

fn main() {
    println!("serde_json: {:?}", serde_json::from_str::<NestedStruct>(&json!({
        "ts": [{"e": "bar"}, {"e": "foo"}],
    }).to_string()));
    println!("serde_qs: {:?}", serde_qs::from_str::<NestedStruct>(
        "ts[0][e]=foo&ts[1][e]=bar"
    ));
}

Solving this may be as easy as moving tuple_struct back to forward_to_deserialize_any somewhere in the code. AFAIK it's impossible to write a custom deserializer just for one tuple variant of an enum (you need to do it for the entire enum), so this should not interfere with the new support for unit & tuple variants.

Oh one more completely unrelated thing. The HEAD version has hidden the serde_qs::de::Error type. It'd be nice to expose as just serde_qs::Error.

Ah okay, that's a nice point. I was thinking that I was helping implementations by forcing the "correct" visitor implementation on them, but I can see the problem here is that you are actually taking away information from the visitor.
Incidentally, that's a horrendous use case 😛. Great though! I wish there was a list of odd use cases to target support for. (Technically foo and bar are the wrong way around if you care about ordering btw).
I think I still need it to coerce some values to a sequence. For example, I want newtype structs to basically just act like the inner value, which means you need to treat a single value like a sequence of length 1. But I think that is necessary since currently the deserialize macro treats newtypes like tuples of length 1.
Thanks for the feedback. I'll try to get my head around using error chain properly to expose nice, chainable errors.

Okay, how about now?

I'm not sure you can just whack-a-mole the possible input types like that, because one can always add something non-standard (the visit_str is new):
             extern crate serde;
#[macro_use] extern crate serde_derive;
#[macro_use] extern crate serde_json;
             extern crate serde_qs;

use std::fmt;

use serde::de::{self, Deserialize, Visitor};

#[derive(Deserialize, Debug, Clone, Copy)]
#[serde(rename_all = "lowercase")]
enum TestEnum { Foo, Bar }

#[derive(Deserialize, Debug)]
struct TestStruct {
    e: TestEnum,
}

#[derive(Debug)]
struct TupleStruct(TestEnum, TestStruct);

impl<'de> Deserialize<'de> for TupleStruct {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
        where D: de::Deserializer<'de>
    {
        deserializer.deserialize_tuple_struct(
            "TupleStruct", 2, TupleStructVisitor)
    }
}

struct TupleStructVisitor;
impl<'de> Visitor<'de> for TupleStructVisitor {
    type Value = TupleStruct;

    fn expecting(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
        write!(fmt, "TupleStruct representation")
    }

    fn visit_str<E: de::Error>(self, s: &str) -> Result<Self::Value, E> {
        let e = match s {
            "alt_foo" => TestEnum::Foo,
            "alt_bar" => TestEnum::Bar,
            _ => return Err(E::custom("bad!")),
        };
        let result = TupleStruct(e, TestStruct { e });
        Ok(result)
    }

    fn visit_map<V>(self, map: V) -> Result<Self::Value, V::Error>
        where V: de::MapAccess<'de>
    {
        let inner_de = de::value::MapAccessDeserializer::new(map);
        let test_struct: TestStruct = Deserialize::deserialize(inner_de)?;

        let result = TupleStruct(test_struct.e, test_struct);
        Ok(result)
    }
}

#[derive(Deserialize, Debug)]
struct NestedStruct {
    ts: Vec<TupleStruct>,
}

fn main() {
    println!("serde_json: {:?}", serde_json::from_str::<NestedStruct>(&json!({
        "ts": ["alt_bar", "alt_foo"],
    }).to_string()));
    println!("serde_qs: {:?}", serde_qs::from_str::<NestedStruct>(
        "ts[0]=alt_foo&ts[1]=alt_bar"
    ));
}

serde_json: Ok(NestedStruct { ts: [TupleStruct(Bar, TestStruct { e: Bar }), TupleStruct(Foo, TestStruct { e: Foo })] })
serde_qs: Err(Error(Custom("invalid type: sequence, expected TupleStruct representation"), State { next_error: None, backtrace: None }))

As for my actual case, I like to think is not as horrendous :) I'm basically deserializing a list which may be of strings or of maps/structs, but I need to remember which one was it for the outer deserializer -- hence the tuple struct with additional "source" enum tag.
The real code is here -- I'm sure you will find this hack almost as amusing as the entire project ;) (The last test case that still doesn't pass with this version is here).

Hmm, okay, I think I get it now. Kind of tough with this format, since it's completely unspecified.
To make this work then I'll have to make it so that newtypes structs are serialized the same as tuple structs, so that the format is picked up and no tricks are needed to get the "String -> sequence -> newtype" trick to work.
On reviewing your use case, I'm not sure I can continue working on this repo in good conscience... For something this important you'd need someone with at least a decade of Rust experience to get it right. It can't afford to be any other way.

I've been giving it some more though, and I'm not entirely sure you can expect the Deserializer to necessarily call the correct visit_* method.
As described here:

Note that a Deserializer will not necessarily follow the type hint, so the call to deserialize_i32 does not necessarily mean the Deserializer will call I32Visitor::visit_i32.

 But that's only going to work for self-describing formats.
So it works for JSON, it could work in this exact case for serde_qs, but in general I don't think it can, and it certainly wouldn't work for something like bincode (for when you port your application to a compact binary format to save on bandwidth of course).

Sorry, didn't want to discourage you :) Remember that no one can have a decade of experience in Rust yet! No software is perfect, we are all still learning here, and -- like I mentioned at the very beginning -- workarounds exist.

So it works for JSON, it could work in this exact case for serde_qs, but in general I don't think it can, and it certainly wouldn't work for something like bincode (for when you port your application to a compact binary format to save on bandwidth of course).

Yes, the deserializers I wrote were specifically tailored for self-describing, tree-like structures -- most notably JSON. I was actually kind of surprised it is possible to encode those in query strings, but seeing the format serde_qs uses made it seem very simple.
Indeed, I think the scheme you're using is completely isomorphic with JSON, as it is essentially a linear list of all key paths. In a pinch, it should be possible to just parse it first to HashMap<String, Stuff> (or HashMap<Index, Stuff> to account for numeric indices) and work with that.
In any case, I think the most important part is to make it clear about the limitations of the current (or any) version. You are definitely welcome to simply add a note in README about the assumptions your deserializer makes and just close this issue :)

Indeed, I think the scheme you're using is completely isomorphic with JSON, as it is essentially a linear list of all key paths.

Yeah, it started out as an experiment to see if it was possible, and took a lot of inspiration from the JSON code. I'm actually kind of tempted to just implement the whole thing by deserializing to serde_json::Value instead. The minor problem is that String aren't properly delimited in querystrings.
I'll have a think if there's a nice way to keep it flexible enough to support custom deserializers expected odd formats, but without degrading the experience for derived deserializations.
Thanks for discussing this one out :) Helps my understanding of all this, and eventually the library as well.

The minor problem is that String aren't properly delimited in querystrings.
They aren't? I've seen plenty of web frameworks that parse QS's into some equivalent of HashMap<String, Vec<String>>. It was actually this plus the fact that either HTTP or browsers limit the QS size (2048 bytes or so) that made me think of just parsing the whole "AST" upfront.

But of course that may be a complete overhaul of your entire approach so take it with a grain of salt :)

Right, a better way to phrase it is that querystrings are informally defined as nested maps where keys and (leaf) values are both strings. What I mean is that there is no distinction between bools/numbers/units and strings, like in JSON "null" vs null or "10.3" vs 10.3.
For example, is a[0] = 1 either: [1u8; 1], ["1"; 1], or even a Map<u8, String>, ... etc.
I could definitely just return this nested map of Strings instead. This would be really simple, but not very useful in the serde sense.

I think you can make your code work in a slightly more robust way all around:
impl<'de> Deserialize<'de> for TupleStruct {

    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
        where D: de::Deserializer<'de>
    {
        #[derive(Deserialize)]
        #[serde(untagged)]
        enum UntaggedEnum {
            E(TestStruct),
            S(String),
        }
        let us = UntaggedEnum::deserialize(deserializer)?;

        match us {
            UntaggedEnum::E(ts) => {
                Ok(TupleStruct(ts.e, ts))
            },
            UntaggedEnum::S(s) => {
                de::Deserializer::deserialize_tuple_struct(s.into_deserializer(), "TupleStruct", 2, TupleStructVisitor)
            }
        }
    }
}

struct TupleStructVisitor;
impl<'de> Visitor<'de> for TupleStructVisitor {
    type Value = TupleStruct;

    fn expecting(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
        write!(fmt, "TupleStruct representation")
    }

    fn visit_str<E: de::Error>(self, s: &str) -> Result<Self::Value, E> {
        let e = match s {
            "alt_foo" => TestEnum::Foo,
            "alt_bar" => TestEnum::Bar,
            _ => return Err(E::custom("bad!")),
        };
        let result = TupleStruct(e, TestStruct { e });
        Ok(result)
    }
}

This works with the current version in the repo, requires less code (don't need to manually visit_map any more), and (to me at least) makes more sense. Semantically, you are trying to deserialize a TupleStruct from either a struct or a String, which is exactly what this code achieves. Instead of assuming the deserializer can make this distinction, using untagged enums makes it more explicit on your side and will attempt to deserialize each one.

Ah, it may very well be that this is in fact the correct way. I remember reading through the custom deserializers' examples in Serde docs and thinking "wait, this is doing it in a roundabout way, I can make it shorter", so it's likely I have taken some (too radical shortcuts) :)
I'll try this when I get home.

I get the impression that there is often no "correct way" in serde. But this seems like a nice compromise where I can let serde_qs take as many hints as it can from which deserialize_* method is called, but you can still make sure the right visitor method is called.

So this seems to have worked :) There is another type that I seem to have problems with now but I'll try to solve using a similar solution. Will report soon.

Alright, fixed all. I applied the "lookahead enum" technique in one more spot (https://github.com/Xion/rofld/commit/dca9e0e40f15c7998dc2421cf5dcbf19b6df4eda#diff-362ff1d9014c27059ccc2de11400e306) and it works nicely. I could in theory get rid of the Visitor in that file but I kinda like how it organizes the code right now.
Ultimately, I think the whole problem stems from Serde's unclear deserialization protocol, and the leaky abstraction it provides. On one hand, authors of data format deserializers (like you) need to take every possible action to determine the shape of the input beforehand (so they can calls the right deserialize_foo). On the other hand, people writing deserialization for their types need to provide the information somehow, and some techniques are more robust here than others.
So basically, it's a balance, but Serde basically leaves us to figure it out ourselves. I predict many more issues like this arising with different serde_foo crates when more people try to write some wonky deserialization code.
Anyway! :) I'm content with the way it turned out, so feel free to close the issue. You may want to summarize the problem & the solution in your docs, though to be fair the best place for it would be Serde docs.
Thanks again!

It seems like there is a misunderstanding about what the various Deserializer methods mean. In particular, in this code https://github.com/Xion/rofld/commit/dca9e0e40f15c7998dc2421cf5dcbf19b6df4eda#diff-362ff1d9014c27059ccc2de11400e306 neither the "before" nor "after" code makes sense to me.
In the "before" code, the deserialize_tuple_struct method means that the type's representation in the Serde data model is a tuple struct, i.e. the Deserializer should follow up with a call to visit_seq. The bug in the original code is that visit_seq is not implemented on the relevant Visitor.
In the "after" code, I don't understand the lookhead enum thing. It is equivalent to calling deserializer.deserialize_any(ColorVisitor).
Basically if your Deserialize implementation knows the Serde data model representation of the type that the input contains, call the right Deserializer method. If the Deserializer needs to figure it out, call deserialize_any.
I skimmed the discussion and it sounds like serde_qs had the correct behavior all along since the first refactor in https://github.com/samscott89/serde_qs/issues/6#issuecomment-302934235, and the user's Deserialize impl was badly behaved.

In the "before" code, the deserialize_tuple_struct method means that the type's representation in the Serde data model is a tuple struct, i.e. the Deserializer should follow up with a call to visit_seq. The bug in the original code is that visit_seq is not implemented on the relevant Visitor.

I see know -- I have misunderstood the purpose of Deserializer::deserialize_foo methods. I thought you are supposed to invoke them when your final data is of shape foo (so for tuple structs, it'd be deserialize_tuple_struct). But now I understand it's about what you expect in the input -- which may have only tenuous relation to the final type being deserialized.
So I guess apologies to @samscott89 are in order :) The original enum bug was a legitimate issue, but the rest turned out to be trying to whip serde_qs into supporting ill-behaved Deserialize impls which was likely unnecessary. I feel like I should atone by writing a blog post about all this Deserialize, Deserializer, and Visitor stuff so others won't repeat my mistakes :)
This saying, the remarks about Serde not doing a very good job at documenting such pitfalls still stand ;p

Hey @dtolnay! Thanks for popping by to impart some wisdom. I was actually planning on writing this up a little better before asking for your opinion on the whole thing.
Since you already found us though...

In the "after" code, I don't understand the lookhead enum thing. It is equivalent to calling deserializer.deserialize_any(ColorVisitor).

Basically if your Deserialize implementation knows the Serde data model representation of the type that the input contains, call the right Deserializer method. If the Deserializer needs to figure it out, call deserialize_any.

That's a nice summary which would have made things a bit clearer earlier (still, many thanks to @Xion, I think we both learnt a lot through this exchange).
One thing I'm not too sure about still: if the Deserializer kind of knows what format the data is in, should it still make an effort to coerce it into the right/expected type? For example, serde_json wont try to convert a map into a sequence (doing something like .map(|(k, v)| v) perhaps) even if deserialize_seq is called, since JSON is self-describing so a map would be invalid. On the other hand, with these slightly informally-defined querystrings, you need a bit of help from the deserializer, so is it a reasonable thing to do to convert to the expected format?

I would recommend against preemptively implementing those coercions but if somebody asks for a specific one and the coercion is reasonable, it is fine to implement. Basically that falls under the Serializer and Deserializer's right to define the mapping between Serde data model <-> the format. That mapping is an art rather than a science. For example serde_json's mapping of an enum like E::V { x: 0 } <-> {"V":{"x":0}} is one of many reasonable choices for that mapping. Haskell and Java libraries typically map the equivalent data structure in a different way.

Okay, thanks!
My only real issue is the ambiguity between a Map<{integer}, Thing>, and a sequence Vec<Thing>, since something like a[0]=blah could easily be parsed as either. Hence needing the extra hints.
I think I could avoid most of these issues if integer keys were restricted for array indices and never as keys for a map, and then the key map/seq/value distinction is a bit more obvious.

Ideally, a would be a sequence if all keys can be parsed as numbers. Though that of course precludes incremental deserializing of individual elements, so it's a tradeoff...

Okay, so 0.2.0 is pushed and now detects sequences properly, which means that less coercing between types is needed.
Enums are definitely supported at this point, which solves the original issue 😄 .
Thanks both for your help on this.


[Galley] Fix for ServiceEntry event ordering

The integration test was encountering this, exposing a real bug. If nodes/pod events occur after service/endpoints (which should generally be unusual) then it is possible to have a ServiceEntry missing pod/node information (e.g. locality).
Fixes #12820

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: nmittler
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: ozevren
If they are not already assigned, you can assign the PR to them by writing /assign @ozevren in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

galley/OWNERS
tests/integration/OWNERS [nmittler]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@nmittler: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@nmittler: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: nmittler, ozevren
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

galley/OWNERS [ozevren]
tests/integration/OWNERS [nmittler,ozevren]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@nmittler: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@nmittler: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@nmittler: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@nmittler: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@nmittler: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-pilot-multicluster-e2e

prow/istio-integ-k8s-tests.sh
fef236e0138f3ad9d3aed37c97ae69580f8d3079
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


How do you download the developer version? Stuck on Build #535

I feel really stupid here, but I've been stuck on Build #535 for so long now, and I cannot figure out how to update to Build #537. Can someone please help me?

https://github.com/YePpHa/YouTubeCenter/wiki/Developer-Version

Thank you, fireattack, but it just doesn't work for me. I'm using Chrome on Mac, and have developer mode enabled. However, it still only results in Build #535 being installed. I'm not sure what I'm doing wrong. Thank you

Oh, so you're using the extension version?
If you really want to use extension version (there is no point to, IMHO),

Download https://github.com/YePpHa/YouTubeCenter/raw/master/dist/YouTubeCenter.crx manually
open chrome://extensions/  and make sure you checked dev mode
Drag the crx file to here and confirm

Does Chrome have a menu option to see the add-ons? If so, go there and see if you can find a "Check for Updates" option. (I'm going by Firefox; I'm not sure if it's the same for Chrome.)

i was using firefox 40 and YouTube Center Developer Build 537 and youtube slowed down for couple days so i updated firefox to 43.
and youtube center doesn't work on firefox 43.  can u fix it pls?

It works fine here, Firefox 43. Try user script version if you're not already.

could u pls give a link to it?
it was hard to find developer version, this site seems not to be user-friendly)

Sure, it's here: https://github.com/YePpHa/YouTubeCenter/wiki/Developer-Version

thx but not working((
i download Firefox: YouTubeCenter.xpi and try to install it but get a message that this extension is not signed.
if i click to user script version it just opens a page with textl.

You need to install a script addon first (like Greasemonkey). Install GM, then try that script link again.

thx, i did as u said and succeeded!
but all setings are gone((
ok, i'll set it up again even if i don't remember how it was))
could u please make a hotkey for speed?  we need to go to settings\speed\ and there set it up but it would be much better if there was a hotkey or buttons for 1x 1.25x 1.5x 1.75x and 2x


Tiller isn't able to find pid file

My build pipeline doesn't work properly anymore after last update (~3h hours ago) of the tiller plugin.
The error message:

Stopping Tiller...
can not find tiller pid file /helm-tiller-44134.pid
Error: plugin "tiller" exited with error

Would you please rollback the pid changes?

please latest v0.8.6, if that still fails for you I will roll back the plugin release.
But ideally you shouldn't be using latest release, pin to some version which works for you so you
don't get surprises with the new releases :-)

I can confirm that I have no issues with 0.8.4 and I have the same issue as @konstantinwirz in 0.8.5 and 0.8.6.
To pin a version use this command...
helm plugin install https://github.com/rimusz/helm-tiller --version 0.8.4

ok, I’m going to revert code back to 0.8.4

#63 reverted code back to v0.8.4
released v0.8.7 https://github.com/rimusz/helm-tiller/releases/tag/v0.8.7


Unexpected external Interrupt/ XIRQ behavior in Indirect Boot from SPI Flash

The Problem
I don't know where to fit this information inside this issue so let me put this bit of information first, before I give this huge description of my projects and related issue. During the problematic simulation that I further describe in details the NeoRV32 RTE spits out the following: Store address misaligned @ PC=0x000007D6, MTINST=0x04C4A221, MTVAL=0x00000045
As a start I give an overview of the problem first. When I run a software simulation with a testbench in Direct Boot, it is working as intended. On the other hand when I run it after loading it from an external flash memory via the bootloader in autoboot mode it doesn't work as intended anymore. Somehow the same external Interrupt signals that I use to trigger different behaviors of the internal Statemachine in software are not detected correctly by the NeoRV32 in the Indirect Boot scenario.
So I have this bigger project with the NeoRV32 were I try to implement an ASIC with the processor. In the process of that I also created a sort of test software that emulates the later functionality of that Chip in the project.
In the project the NeoRV32 should collect 16bytes of data via the SLINK interface and depending on some other signals add a 4 byte EvtID that is received via SDI to that data package or not. In any case the newly created data package is sent further via SDI.
The test software should do 3 test cases/ variations of that process. The first one is that both the 16 Byte Data Package and the EvtPackage is sent. Next only the Data Package is sent without the EvtID. Finally in the last test only an EvtID is sent without a data Package.

The Hit Signal which is connected via the external interrupt controller signals that a new DataPackage is arriving via SLINK.
The EvtID is only added to the Data Package when inside the Hit-Frame (Hit == HIGH) a TrigAck Signal is also received via another external Interrupt.
To Reproduce
Run the neoipe_test_setup_bootloader_full_tb.vhd testbench together with the respective processor config neoipe_test_setup_bootloader_autoboot.vhd. Use the spi_flash_mem_emu.sv as the module to simulate the upload of the executable.
Finally the executable is stored inside the neorv32_exe.mem file in the hex format required for simulation with the flash module.
In contrast the expected behavior occurs with the neoipe_test_setup_approm_full_tb.vhd testbench and the respective processor config
neoipe_approm_comp2_test.vhd processor config. For that the neorv32_application_image.vhd is also provided.
Expected behavior
I would expect that the same executable results in the same behavior no matter if its uploaded via an SPI flash in Indirect Boot or in the Direct Boot where its stored directly in the IMEM. In Detail that means that the 3 test cases from the testbench result in the expected behavior from the processor. Which is

When the Hit Signal arrives together with a TrigAck signal inside, then the CPU should create a package with Data+EvtID. Next this should be sent via SDI
When the Hit Signal arrives only, then the Processor should create and forward a package with Data only.
When the TrigAck arrives only, then the Processor should create and forward a package with EvtID only.

This shows my simulation screenshot when i simulate the Direct Boot testbench of my software simulation. As expected the 3 testcases lead finally to different data output on the w_spi_miso signal line.

Screenshots
Here the problematic behaviour becomes visible. In contrast to the Direct Boot behavior in the Indirect Boot simulation the software state machine transitions in the DataPackage + EvtID case from the Wait_Evt State directly into the Gen_Empty_Pck state. Although the external Interrupt from the Hit signal that comes first, which would stop this from happening normally.(this is visible in the Wave Diagram on the right. I created "Debug Information" via the gpios representing the current state).

This results in the behavior of sending an empty package without data. which would normally only occur, when no hit signal is send together with the TrigAck Signal.
In the next testcase no EvtID is send and no TrigAck signal is generated. Nevertheless the statemachine transitions into the Wait_Evt_Id state as if it had actually received an TrigAck Interrupt. Thus the testbench gets stuck, because no EvtID is actually send in this testcase and the statemachine rests in this state.

See the application software that is executed in the main.c file for full code.
Environment:

Simulator: Xcelium 22.03
OS: Ubuntu 22.04 / 18.04 on simulation server
GCC Version (RISC-V and native): gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, I just used the standard make cmds to create .bin files

Hardware:

Hardware version (<IP_ADDRESS>)
CPU extensions: A, B, C, M, U, Zfinx, Zicntr, Zicond, Zihpm, Fast_Mul, Fast_Shift
CPU peripherals: GPIO, MTIME, UART0, SPI, SDI, SLINK, XIRQ, OCD, Bootloader

Additional context
I have tested the flash module used in the simulation separately here #878 with another testbench that I also provide together with a respective blink_led_neorv32.mem. Here the upload of the executable is functional and the GPIO starts to generate the expected counting behavior from the blink_led example software.
Just to be sure I also simulated the Direct Boot version also with a UART Module and here the NEORV32 RTE doesn't create any output via UART, so the mysterious store address misaligned is only present in the Indirect Boot scenario.
I also wonder if this issue with the NeoRV32 RTE is related to #626 somehow as I can't find the mentioned instruction inside the main.asm file
Full Simulation Files
ProblemFiles.zip

Hey @ucycg!
Oh wow, this is a big one... 😅 Thanks for the detailed description!

So I have this bigger project with the NeoRV32 were I try to implement an ASIC with the processor.

Now that sounds interesting! Can you tell us a bit more about it? :wink:

I would expect that the same executable results in the same behavior no matter if its uploaded via an SPI flash in Indirect Boot or in the Direct Boot where its stored directly in the IMEM.

You are right, there should be no difference at all. I am using both mechanism all the time and I have never seen any difference. However, there might be a difference regarding the timing of the processor-external logic; or more precise: the time when your XIRQ interrupt fires.

Hardware version (<IP_ADDRESS>)

I see that you are using an older version of the core. We identified a bug in the handling of the FIRQs where some interrupt requests just got lost. See #818.
We tried to fix that in #821 and #829, but ultimately we reworked the entire FIRQ trigger mechanism (#858, #859, #860 and especially #864). Long story short, the FIRQ are now triggered by high-level and not just by a single edge. With this modification, a FIRQ remains pending as long as the according interrupt signal is high - making it "impossible" to loose a triggering event.
I have not looked into your sources yet, but does this sound like it might be the reason for your issue?

Hey Stephan,
thank you for your quick reply, I will try my simulations with the latest NeoRV32 version and report back when I'm ready. I'm not sure that this is the reason for my problem, but I think its a good idea anyway to update my project. I actually noticed the udpates in the FIRQ, but I didn't really understand or maybe I forgot that was due to a bug!
One of the reasons why I delayed the update was that as far as I understand it right now a functionality in sw that I implemented isn't supported/possible in the latest CPU version anymore. I use the SDI_CTRL_IRQ_TX_EMPTY Interrupt, but I'm sort of transforming it into an edge based interrupt by turning it off with my own interrupt handler and clearing the mip. But I think I can just remove the interrupt for now and instead just read the SDI_CTRL register in an extra state of my state machine instead.

Now that sounds interesting! Can you tell us a bit more about it? 😉
Thank you for your interest, I might do that in the future, right now I don't feel comfortable to do that yet :)

Hello Stephan,
so I managed to update my project with the latest Hardware Version <IP_ADDRESS>, but the behavior hasn't changed at all. I'm actually a bit suprised, that in the case of the Direct Boot scenario my old code is functional without any changes. As far as I understood write access to the MIP isn't possible anymore. Maybe I have a confusion in my code, but currently it seems that I can still execute this:
neorv32_cpu_csr_clr(CSR_MIP, 1 << CSR_MIP_FIRQ11P);
Anyway the signal of the XIRQ inside the FIRQ has changed as expected with the Processor Update, as far as I can see it right now all interrupt handlers are actually executed. I will go on with the debugging and see if I can solve or narrow done the problem.

now a functionality in sw that I implemented isn't supported/possible in the latest CPU version anymore. I use the SDI_CTRL_IRQ_TX_EMPTY Interrupt, but I'm sort of transforming it into an edge based interrupt by turning it off with my own interrupt handler and clearing the mip

This interrupt (TX FIFO empty) is still available, but it will keep firing until the interrupt-causing condition is no longer met (i.e. data being written to the TX FIFO). You can still turn that into a single-shot interrupt within your interrupt handler by clearing SDI_CTRL_IRQ_TX_EMPTY until your program has written data to TX.
Maybe this does not perfectly fit your application, but the main goal of this entire FIRQ rework was to make all internal interrupts more consistent (and more RISC-V alike). 😉

so I managed to update my project with the latest Hardware Version <IP_ADDRESS>, but the behavior hasn't changed at all.

Sorry to hear that.
The executable for both boot scenarios are completely identical, right? Or in other words: how did you compile each of these executables? Are both using the same memory layout configuration?

Maybe I have a confusion in my code, but currently it seems that I can still execute this:
neorv32_cpu_csr_clr(CSR_MIP, 1 << CSR_MIP_FIRQ11P);

You can still write to mip without raising an exception as the CSR is read-write according to the RISC-V spec. However, all bits are read-only so writing any data to them will have no effect.

So I still dont know what the exact issue is with my old code, but I managed to find a solution for now.

I try to tell appart the two cases A) and B) with the "Bug" my state machine behaved as if case B) occured thought the input signals where as in case A)

Its weird, because in theory the hitFlag according to my understanding is set by an interrupt with higher priority then the trigAckFlag

Are both flags updated by interrupts? If so, are they both updated by the XIRQ interrupt?
Maybe there is a problem with the XIRQ prioritization (inside the interrupt handler?) resulting in some kind of race condition... 🤔


Bump tract to 0.17.4

Checklist

[x] I have read the Contributor Guide
[x] I have read and agree to the Code of Conduct
[x] I have added a description of my changes and why I'd like them included in the section below

Description of Changes
Bump tract to add aarch64-unknown-linux support among other things. See their changelog here.

Closing as the bump is semver-compatible and should work fine as is.


chore: simplify cli structure and common tools

Summary:
Cleaning up the packages/cli structure. This might be pretty disruptive to already open PRs :D.

Renamed core -> tools
Moved util to tools
Flatten-out server/util
Create commands dir and put all commands there

packages/cli/src
├── bin.js
├── cliEntry.js
├── commands
│   ├── bundle
│   ├── dependencies
│   ├── eject
│   ├── index.js
│   ├── info
│   ├── init
│   ├── install
│   ├── library
│   ├── link
│   ├── logAndroid
│   ├── logIOS
│   ├── runAndroid
│   ├── runIOS
│   ├── server
│   └── upgrade
├── index.js
└── tools
    ├── ...

Fixes https://github.com/react-native-community/react-native-cli/issues/49
Test Plan:
CI green

Thanks @thymikee for taking up this PR. If tests are green, I believe it's good to go.
Might require some work on React Native side that uses private API to make sure the paths are correct. If there's work required on React Native side, we need to make this a breaking change.

Can you check that?

Also, no RN version lower than 0.59 installs this CLI, so we could only break RC (which is not good, but you know, it's RC)

Breaking RC should be fine. At FB, nothing depends on this code, so you can do whatever you want as long as it works with RN.

So it turns out that hasteImpl in RN uses it:
https://github.com/facebook/react-native/blob/9cb4d3f2c1e133d40d5c5d44583dc45243e033bd/jest/hasteImpl.js#L28-L29
We could apply this diff to make it backcompat:
--- a/packages/cli/src/cliEntry.js
+++ b/packages/cli/src/cliEntry.js
@@ -17,6 +17,7 @@ import getLegacyConfig from './tools/getLegacyConfig';
 import { getCommands } from './commands';
 import init from './commands/init/init';
 import assertRequiredOptions from './tools/assertRequiredOptions';
+import findPlugins from './tools/findPlugins';
 import logger from './tools/logger';
 import pkg from '../package.json';

@@ -208,4 +209,6 @@ export default {
   init,
 };

+export { findPlugins };
+
 // export { run, init };
diff --git a/packages/cli/src/core/findPlugins.js b/packages/cli/src/core/findPlugins.js
new file mode 100644
index 0000000..d1ac206
--- /dev/null
+++ b/packages/cli/src/core/findPlugins.js
@@ -0,0 +1,5 @@
+/**
+ * TODO: This file exists only because RN 0.59.0-rc depends on importing private
+ * methods. Remove it once it's updated with public API.
+ */
+module.exports = require('../tools/findPlugins');

Double checked and we should be good to make a breaking change now.
The CLI is only consumed by 0.59-stable release candidates. I am about to make a new one with few of the cherry-picks, so we can technically do the breaking change (we need to bump major to avoid older RCs installing this one).


python functions cannot find python3 interpreter

Describe the bug
python functions do not start if the system has "python3" but not "python" (which is the case for modern Ubuntu systems - "python" is python2 and is not installed by default)
To Reproduce
Write a simple function func1.py
from pulsar import Function

class FirstFunction(Function):
    def process(self, item, context):
        log = context.get_logger()
        log.info("Got %r with properties %r" % (item, context.get_message_properties()))

Deploy it:
apache-pulsar-2.4.1/bin/pulsar-admin functions create --name womble --inputs my-topic \
  --py /home/ubuntu/func1.py --classname FirstFunction --log-topic pulsar-log

(side note: have to give absolute path to function, pulsar-admin changes the working directory)
Check its status:
$ apache-pulsar-2.4.1/bin/pulsar-admin functions status --name womble
{
  "numInstances" : 1,
  "numRunning" : 0,
  "instances" : [ {
    "instanceId" : 0,
    "status" : {
      "running" : false,
      "error" : "Cannot run program \"python\": error=2, No such file or directory",
      "numRestarts" : 16,
      "numReceived" : 0,
      "numSuccessfullyProcessed" : 0,
      "numUserExceptions" : 0,
      "latestUserExceptions" : [ ],
      "numSystemExceptions" : 0,
      "latestSystemExceptions" : [ ],
      "averageLatency" : 0.0,
      "lastInvocationTime" : 0,
      "workerId" : "c-standalone-fw-ldex-pulsar.int.example.net-8080"
    }
  } ]
}

Note error: Cannot run program "python": error=2, No such file or directory
Expected behavior
I would expect the function to deploy.
Screenshots
N/A
Desktop (please complete the following information):
N/A
Additional context
This may be the same problem as #5369 - however in that case, it's the shebang line in pulsar's own python code, whereas this one is my own function which is not starting.
I cannot find it stated in Pulsar documentation whether Pulsar supports python2, python3 or both.  However python2 is very shortly going to be end-of-life.
Workarounds
Install python2 and write my code in python2.  I really don't want to do that, with python2 being end-of-life in 2 months' time.
Symlink python to python3.  However in Ubuntu systems, symlinking python to python3 has the potential to cause all sorts of problems. Many applications and scripts depend on python meaning python2 (in which case they will depend on the python-XXX packages rather than python3-XXX).  More content here.
Ideally pulsar would try python3 and fallback to python.  If pulsar were to be hard-coded to run "python3" instead of "python" that would also be fine IMO, given the impending EOL of python2.

Hmm, I found docker/pulsar/scripts/set_python_version.sh which suggests that people are making python a symlink to python3
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 10

As I say, this is generally frowned upon.
I found there is pythonInstanceLocation in WorkerConfig.java.  The documentation says "change the python instance location only when you put the python instance jar in a different location" - but I'm looking for the python interpreter, not a jar file.  (I don't think it's using anything
I haven't yet found the point where pulsar execs the python interpreter.

Part of the answer comes from pulsar's debug output: it is running python .../python_instance_main.py ...args...
12:25:45.004 [function-timer-thread-94-1] INFO  org.apache.pulsar.functions.runtime.ProcessRuntime - ProcessBuilder starting the process with args
  python /home/ubuntu/apache-pulsar-2.4.1/instances/python-instance/python_instance_main.py
  --py /tmp/pulsar_functions/public/default/womble/0/func1.py
  --logging_directory /home/ubuntu/apache-pulsar-2.4.1/logs/functions --logging_file womble
  --logging_config_file /home/ubuntu/apache-pulsar-2.4.1/conf/functions-logging/logging_config.ini
  --instance_id 0 --function_id 67fb9828-56ab-49ff-bbbc-56db9510d26c
  --function_version 4f01d696-28da-40b7-b9f5-2283fbe9bd7c
  --function_details '{"tenant":"public","namespace":"default","name":"womble","className":"FirstFunction","logTopic":"pulsar-log","runtime":"PYTHON","autoAck":true,"parallelism":1,"source":{"inputSpecs":{"my-topic":{}},"cleanupSubscription":true},"sink":{},"resources":{"cpu":1.0,"ram":"1073741824","disk":"10737418240"},"componentType":"FUNCTION"}'
  --pulsar_serviceurl pulsar://ldex-pulsar.int.soundmouse.net:6650 --max_buffered_tuples 1024
  --port 38423 --metrics_port 36591 --state_storage_serviceurl bk://<IP_ADDRESS>:4181
  --expected_healthcheck_interval 30 --secrets_provider secretsprovider.ClearTextSecretsProvider
  --cluster_name standalone

So a configuration option to change "python" to "python3" here would be great, and solve the problem.

the question would be what is the default option if any.

the question would be what is the default option if any.

I would be fine with the default remaining at "python" for backwards-compatibility reasons, as long as there's a way to override it.

@wolfstudy could you please help look into the issue? Thank you.

How about adding a setting to broker.conf / standalone.conf? e.g.
python_interpreter=/usr/bin/python

However I notice some places where searching in  $PATH search is currently required:
./pulsar-client-cpp/docker/Dockerfile:ENV PATH="/opt/python/${PYTHON_SPEC}/bin:${PATH}"
./build/docker/Dockerfile:ENV PATH "$PATH:/usr/local/rvm/bin"

So I suggest:

Default is python_interpreter=python
If the setting starts with slash, it's an absolute path (avoids some edge-case security issues)
Otherwise search for it in $PATH as today

conf file is a better options makes it more explicit

Please can this be re-opened?  That might have been my mistake, but #5536 doesn't fix this issue, it only documents the (bad) workaround.
IMO Pulsar still needs a conf option to set the python interpreter path.

You can reopen it manually.
Since we relate PR-#5536 to this issue, when that PR is merged, this issue is closed automatically.

When you add the conf info in a PR, you can relate the PR to this issue as well.

@srkukarni, you got me thinking. How about reusing customRuntimeOptions? Eg: 3a2b312c4ded8cd78ca61e3877add394f01b8fe4.
Then setting custom-runtime-options to {"PythonInterpreter": "python3"} or even {"PythonInterpreter": "/opt/python-3.6.5/bin/python3"} would set the interpreter. The reason for using json is to maintain compatibility with KubernetesManifestCustomizer which I think is the only other use of the parameter.
By the way, the protobuf python definitions also need to be recompiled for this to work. Probably should be done in any case. The one in master seems to be old and doesn't include customRuntimeOptions (added with 320cebe09f80116a2df81a5df1bcfd518ecf8c08)
(The python definitions don't get built by maven - they are been generated manually and tracked by git).

https://github.com/apache/pulsar/pull/15376 (PIP-155) should drop support for Python 2 now.
Please open a new issue with repro if it's still relevant.


How to achive Inactivity timeout in nuxtjs

@venugopalsundaram Please describe more what you want to do exactly.

@Atinux I am using NUXT as my front end.I want to implement idle timeout/logout.For ex. no action in front for 5 mins, then the application will be redirected to login page.
#1958 open


Handle ConditionalPermission in middleware.

EnsureJWTAuthSettingsMiddleware's check for permissions classes would
fail if it was applied to a view that uses conditional permissions from
the rest_condition library, like:
C(permissions.IsStaff) | permissions.IsUserInUrl

The cause of failure is that we were checking for subclasses of
particular permissions like IsStaff, and ConditionalPermissions are
outside of that hierarchy (and aren't even classes). This is one of the
contributing issues in ARCH-153.
This commit checks to see if a permission is a ConditionalPermission
and then expands it out so that we capture only the Permission classes
inside. So the check will pass as long as you have the required
permission class somewhere in your view's permissions, with the
assumption being that if you're using the required permission in a
Conditional, you probably know what you're doing and we shouldn't
blindly append the required permission class at the end.

@nasthagiri, @douglashall: Ready for review

Squashed commits. Will merge as soon as the build turns green.


Document browser compatibility

Somewhere we should just mention that Safari has problems when using Basic Auth
And IE11 is no longer supported - but if this is something you require and can help with development reach out to us.

The best thing to do here would be to add to the Requirements section "Browser Requirements"
See https://osc.github.io/ood-documentation/master/requirements.html as there is already Hardware Requirements and Software Requirements.
We would explain that:

Chrome is best supported because hterm is from Chrome OS and the NoVNC copy/paste streamlining is a Chrome only feature at this point
Browser support is for versions that support ES6 features (do we actually use ES7 or later features?) but haven't identified exact browser versions - just use the latest Edge/Chrome/Firefox
Safari is problematic with websockets when using BasicAuth or sometimes just in general - so some sites report problems with the shell app and NoVNC as a result.

Also call out in a warning box:

No IE11 support. If you are a site that requires IE11 support and are willing to contribute developer time to the project to support this, please reach out to us.


Cannot build OpenCV-3.4.6 in Jetson Nano

I was installing OpenCV-3.4.6 according to instructions provided by you and I encountered this error:
[ 49%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/minmax.cpp.o
[ 49%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/norm.cpp.o
[ 49%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/ocl.cpp.o
[ 49%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/opencl/runtime/opencl_clamdblas.cpp.o
[ 49%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/opencl/runtime/opencl_clamdfft.cpp.o
[ 50%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/opencl/runtime/opencl_core.cpp.o
[ 50%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/opengl.cpp.o

In file included from /home/jetson-beta/src/opencv-3.4.6/modules/core/src/opengl.cpp:48:0:
/usr/local/cuda/include/cuda_gl_interop.h:63:2: error: #error Please include the appropriate gl headers before including cuda_gl_interop.h
 #error Please include the appropriate gl headers before including cuda_gl_interop.h
  ^~~~~
In file included from /home/jetson-beta/src/opencv-3.4.6/modules/core/include/opencv2/core/private.cuda.hpp:73:0,
                 from /home/jetson-beta/src/opencv-3.4.6/build/modules/core/precomp.hpp:56:
/home/jetson-beta/src/opencv-3.4.6/modules/core/src/opengl.cpp: In function ‘void cv::cuda::setGlDevice(int)’:
/home/jetson-beta/src/opencv-3.4.6/modules/core/src/opengl.cpp:118:47: warning: ‘cudaError_t cudaGLSetGLDevice(int)’ is deprecated [-Wdeprecated-declarations]
         cudaSafeCall( cudaGLSetGLDevice(device) );
                                               ^
/home/jetson-beta/src/opencv-3.4.6/modules/core/include/opencv2/core/cuda/common.hpp:74:58: note: in definition of macro ‘cudaSafeCall’
     #define cudaSafeCall(expr)  cv::cuda::checkCudaError(expr, __FILE__, __LINE__, CV_Func)
                                                          ^~~~
In file included from /home/jetson-beta/src/opencv-3.4.6/modules/core/src/opengl.cpp:48:0:
/usr/local/cuda/include/cuda_gl_interop.h:305:57: note: declared here
 extern __CUDA_DEPRECATED __host__ cudaError_t CUDARTAPI cudaGLSetGLDevice(int device);
                                                         ^~~~~~~~~~~~~~~~~
modules/core/CMakeFiles/opencv_core.dir/build.make:1344: recipe for target 'modules/core/CMakeFiles/opencv_core.dir/src/opengl.cpp.o' failed
make[2]: *** [modules/core/CMakeFiles/opencv_core.dir/src/opengl.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/Makefile2:1755: recipe for target 'modules/core/CMakeFiles/opencv_core.dir/all' failed
make[1]: *** [modules/core/CMakeFiles/opencv_core.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

Only edits I made to the cmake command was removing -D ENABLE_FAST_MATH=ON -D CUDA_FAST_MATH=ON as I wanted precise calculations for OpenCV. How can I resolve this build error?

Please check out the solution here: https://forums.developer.nvidia.com/t/building-opencv-with-opengl-support/49741/3
I wonder whether you are running my install_opencv-3.4.6.sh script on a Jetson TX2 or Nano?  Which version of JetPack are you using?

I'm installing it on Jetson nano. I downloaded the latest image provided on Nvidia website to flash my Jetson nano. I think it's 4.2

Not sure why you encountered the problem.  Anyway, the solution pointed to by https://github.com/jkjung-avt/jetson_nano/issues/11#issuecomment-626255852 should work.

It worked. Thanks!


Convert many util functions to use id-sdk/util

This is a big one!
This PR builds on previous  work... This time we're swapping the internal util functions out and replacing them with their id-sdk/util counterparts ..
Thanks @vanreece for your work on getting the util functions tested, typescripted, and ready to use!  👏

iD-sdk is an initiative to extract the useful code from the iD/RapiD monolithic repositories, and convert them into modular libraries that can be used to build new editors and tools.  The replacement SDK code is written in TypeScript and has more complete documentation and test coverage.  It's a win for everyone because it means less code to maintain in RapiD, and unlocks the ability to use this code in other projects.

Before

After


open issues in the old repo?

What is their status? Have they all been resolved?
Should hey be migrated here?
(my specific interest concerns https://bitbucket.org/al45tair/ds_store/issues/7)

They haven't been migrated, no; unfortunately it appears Github's migration doesn't copy the issues across. As regards using ds_store to set background images, if you're doing it by hand then you want to be using 'pBBk' as well as 'icvp' (I've just updated that bug to explain). Alternatively you could just use dmgbuild which already knows what to do.


Assignee menu text is overwritten when typing name #3963

Added the select attribute to the dropdown settings. This prevents the selected option from changing the main label text when typing to select the label.

Thanks for the PR! Have you tested other places where we do need this behavior, e.g. selecting owner in create new repository?

Hmm, combining two independent features/functions together in one PR is not very good... As I will squash the commits, this could cause losing credits from you (if you don't mind about this effect, you don't have to split into two PRs).

yeah, in the process of fixing that now.

removed the other PR there is just one now.

OK, thank you!


.env missing! (Docker)

When I try to run sudo docker-compose up -d I get error: ERROR: Couldn't find env file:

Hey @sonnimon! Fancy seeing you here again, diving into the Docker depths, I see. 🐳
To resolve the "ERROR: Couldn't find env file" issue when running sudo docker-compose up -d, you need to ensure that the .env file is in the correct directory where the docker-compose command is being executed. The error suggests that Docker Compose cannot find the .env file because it either does not exist in the expected directory or Docker Compose does not have permission to access it.
Given the context of your setup_env.sh script, it seems you are correctly checking for the existence of the .env file and creating it if it doesn't exist. However, the issue might be related to where and how you are running this script in relation to your Docker Compose command. Here are steps to troubleshoot and resolve the issue:

Run the Script in the Correct Directory: Ensure that setup_env.sh is executed in the same directory as your docker-compose.yml file. Docker Compose expects the .env file to be in the same directory from which the docker-compose command is run.

Permissions: Running docker-compose with sudo might cause it to look for the .env file in the root user's home directory or affect its ability to access the file due to permission issues. Try running the script and the docker-compose command without sudo if your setup allows it, or ensure the .env file is accessible by the root user.

Explicitly Specify the .env File: If the .env file is in a different location or if you want to ensure Docker Compose recognizes it, you can explicitly specify the path to the .env file in your docker-compose command using the --env-file option:
sudo docker-compose --env-file /path/to/your/.env up -d

Replace /path/to/your/.env with the actual path to your .env file.

Check for Typos: Ensure there are no typos in your .env file name or path. It should be named .env and not, for example, env or .env.txt.

File Permissions: Ensure the .env file has the correct permissions that allow it to be read by the user running the docker-compose command. You can set read permissions using:
chmod +r .env

By following these steps, you should be able to resolve the "ERROR: Couldn't find env file" issue.
Regarding your questions about the .env file and Docker setup in the langflow repository, I wasn't able to find a .env file in the repository. However, the repository does provide a Docker setup. It is located in the Dockerfile at the root of the repository, as indicated by the line dockerfilePath: ./Dockerfile in the provided render.yaml file. You can find the Dockerfile here and the render.yaml file here.
Please let me know if you need further assistance.
Sources

scripts/setup/setup_env.sh
render.yaml

About Dosu

there is no .env file how do I get one I just fresh cloned the repo!

Based on the context provided, it seems like the .env file is indeed missing from the root directory of the langflow repository. This file is typically used to store environment variables that are required for the Docker setup.
To create the .env file, you can follow these steps:

Navigate to the deploy/ directory in the langflow repository.
Create a new file named .env.
Open the deploy/.env.example file, copy its contents, and paste them into the .env file you just created.
Save the .env file.

If you're using a Unix-like command line, you can use the following command from within the deploy/ directory to create the .env file:
cp .env.example .env

This command will create a copy of the .env.example file and name it .env.
The .env file should contain the following variables:

LANGFLOW_DATABASE_URL=sqlite:///./langflow.db
LANGFLOW_LANGCHAIN_CACHE=SQLiteCache
LANGFLOW_HOST= (Set based on your environment)
LANGFLOW_WORKERS= (Set based on your environment)
LANGFLOW_PORT= (Set based on your environment)
LANGFLOW_LOG_LEVEL= (Set based on your environment)
LANGFLOW_LOG_FILE= (Set based on your environment)
LANGFLOW_FRONTEND_PATH= (Set based on your environment)
LANGFLOW_OPEN_BROWSER= (Set based on your environment)
LANGFLOW_REMOVE_API_KEYS= (Set based on your environment)
LANGFLOW_CACHE_TYPE= (Set based on your environment)
LANGFLOW_AUTO_LOGIN= (Set based on your environment)
LANGFLOW_SUPERUSER= (Set based on your environment)
LANGFLOW_SUPERUSER_PASSWORD= (Set based on your environment)
LANGFLOW_STORE_URL= (Set based on your environment)
LANGFLOW_DOWNLOAD_WEBHOOK_URL= (Set based on your environment)
LANGFLOW_LIKE_WEBHOOK_URL= (Set based on your environment)

If LANGFLOW_CACHE_TYPE=redis is chosen, the following variables must also be set:

LANGFLOW_REDIS_HOST (default: localhost)
LANGFLOW_REDIS_PORT (default: 6379)
LANGFLOW_REDIS_DB (default: 0)
LANGFLOW_REDIS_CACHE_EXPIRE (default: 3600)

You can find more details about these variables in the .env.example file.
As for additional steps or requirements for setting up the Docker environment for the langflow repository, beyond creating the .env file, I wasn't able to find any in the repository. However, it's always a good idea to check the repository's README or other documentation for any additional setup instructions or requirements. If you encounter any issues or need further assistance, feel free to ask.
I hope this helps! If you have any other questions, don't hesitate to ask.
Sources

deploy/.env.example
.env.example

About Dosu

Thanks that helped no were was described how to run docker installation!

Huh this bot is pro in solving issues !


Batch never prints

I'm attempting in Debian 8 and this is what I see:
sudo ./nejePrint.sh /dev/ttyUSB0 mono.bmp
[sudo] password for ****:
setting port...
speed 57600 baud; line = 0;
-brkint -imaxbel
done
Handshake...
done
Sending
done
home
Burning Time 0x20
preview
All Done

If I don't sudo it'll spew a pile of permission denied.  The laser seems to flash a bit during the Sending portion so it appears to be sending but after "All Done" nothing happens.  The laser never moves at any point during this.
Is there some sort of driver or the like?  Am I missing a step?
Thanks

Also tried it as root (so no sudo needed).  The only difference was that while the Sending command was going, the laser was completely off.  It then turned on again after the "done" was posted.  But still no output and nothing prints.
I pushed the button on the printer just to see if maybe the image was sent but didn't start printing.  It just printed the previous (when I used windows) image.

Are you in the "dialout" group?

I added and tried, same result.  Although both times now the laser was turned off completely during the "sending" step:
root : root dialout
chris : chris dialout cdrom floppy audio dip video plugdev netdev lpadmin scanner

It just seems so close!  The laser never moves during the script either :(
I tried playing around with some of the steps and even sending some of the codes found here: https://github.com/mrehqe/pyneje/blob/master/doc/neje-serial-protocol.txt  None of the "move" codes made the laser move either.

Got the same problem, will try to find a Windows Computer with USB- sniffer program

Can we create new platform software for this all models neje?
On Wed, Dec 21, 2016, 21:05 Alessio Graziano<EMAIL_ADDRESS>wrote:

Is the image 512x512 with 2bit color depth?
If length and encoding is not exactly right the printer just goes insane...
I'm working on a node version, bash is nice 'cause it has no dependencies
but it's meant to be used only as a hacking tool, the software is really
the python one!
I'm working on a node sw, the bash one will be deleted in future versions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AxelTB/nejePrint/issues/4#issuecomment-268625461, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AG0ta21AVzoIT2-nGgzqZzQd3hiTbQg0ks5rKYadgaJpZM4LQWAM
.

--
Pozdrawiam,
Krzysztof Szeremeta
KSZERE | SO4ASN

Yes, it´ s 512x512 with 2bit color depth,
(ImageMagic)

convert Biohazard.bmp BMP3:test.bmp
file test.bmp
test.bmp: PC bitmap, Windows 3.x format, 512 x 512 x 1

even the included "mono.bmp" don´ t work..

Yeah I was working with mono.bmp, I just wanted to really see if it worked (then worry about the GUI gloss bits later).
I was tempted to try the Python version, but I know nothing about Python and the dependencies were already too much for me.  I figured if the batch process didn't work the Python one wouldn't either (figuring it was using the same techniques).

Try the version on the develop (adc717749e1b9f085e73cae9027f10d252cb97a9).
This version does a full setup of the Serial port and a complete handshake.
Let me know if it works.

Sorry it took awhile.  I checked out develop branch and as root tried the command.  Unfortunately the handshake seems to have failed:
# sh ./nejePrint.sh /dev/ttyUSB0 mono.bmp
setting port...
Handshake...
Handshake Failed (Error 0):
speed 57600 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl ixoff -imaxbel
-opost -onlcr
-isig -icanon -echo -echoe

Try it a couple of times without root. Sometimes fails for no reason.
Besides that I have no clue.

Sorry this took so long, but I've tried:
./nejePrint.sh /dev/ttyUSB0 ./mono.bmp

Several times and tried with sudo.  No matter how many times I try, it gives the same error (what I have above).
I fear using a whole VM just for this :)

Just for information: which model do you have?
Right now it seem to work for the DK-8 and it shouldn't on the DK-BL

If it helps, I found a project that does work: https://github.com/camrein/EzGraver
I compiled it from source on my machine and it's currently printing (using the GUI).  Maybe you could check that out and see what they did?  I've never really read C++ code or whatever they are using.

I have the "NEJE DK-8-KZ 1000mW Laser Engraver Printer BLACK"

I also NEJE DK-8KZ 1W
On Thu, Jan 12, 2017, 20:23 Chris Weed<EMAIL_ADDRESS>wrote:

I have the "NEJE DK-8-KZ 1000mW Laser Engraver Printer BLACK"
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AxelTB/nejePrint/issues/4#issuecomment-272256765, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AG0ta16FSv7xA10byng2Exhs28Bl9fh6ks5rRn3FgaJpZM4LQWAM
.

--
Pozdrawiam,
Krzysztof Szeremeta
KSZERE | SO4ASN

This is strange, I have the same model...
When I'll have some time I'll check everything out and maybe trying to figure out this mess

I also tried with a recent NEJE DK-8-KZ
Also tried the EzGraver form https://github.com/camrein
And the results are similar.
It seems the protocol has changed.
I can find the NEJE on ttyUSB0 and seem to be able to connect..
But that is about it.
None of the commands pushed to the NEJE seem to work.
Also the initial uload does not change the butterfly test image that NEJE suplied on their Eprom
I tried:

The NEJE seems to respond on upload and recenter while buzzing a bit.
For the rest it does nothing. As if it has another protocol and does not understand the scripts and data we push to it.

Maybe NEJE udated and changed the protocol?
How to find out though? I have a CD with windows software and drivers they suplied me.. But dont own a windows machine. Otherwise I could have tried to wireshark on the serial port to see what gets pushed by their software,,,,,....
What do You think?
xxx-xxxxxx nejePrint-master # sudo ./nejePrint.sh /dev/ttyUSB0 mono.bmp [40]
(standard_in) 1: syntax error
setting port...
speed 57600 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -iexten -echo
done
Handshake...
done
Sending
done
home
Burning Time 0x
preview
All
Done

You're very welcome.
If it may help you to reverse engineer the protocol I used a VirtualBox VM with windows on it and a cheap serial hex sniffer software (On the windows VM too). I didn't have any windows machine either.


[FLINK-23064][flink-connectors][flink-formats] Expose connector/format config options as @PublicEvolving

What is the purpose of the change
This exposes ConfigOption<>s for connectors and formats by marking them as @PublicEvolving. Where applicable we reduce the exposed API surface by refactoring constants, validation helpers, and utilities into another class (annotated with @Internal).
This is done as part of FLIP-129 to allow users to refer to these options when creating table (and format) descriptors.
(!) Review on a per-commit basis is encouraged. Each commit touches a specific connector/format. Otherwise the changes are fairly technical.
In a follow-up step (separate sub-task) we'll move these classes into a common location (package) for easier discovery.
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

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

Documentation

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

Thanks for the review @twalthr. I think all your points are valid, but I'd like to address the rest of them in a separate PR. To summarize:

Use the new map config option type in HBase
Convert string constants to enums where possible
(Remove Utils classes afterwards if possible by moving things into the factory directly)


Fix minor code comment typo

Hi @awortman-fastly, is there anything I can do to fix the validation errors?

Closing this PR as the code example has changed significantly since.


ff4j_audit table column size issue

Hi,
I could see that the FF4J_FEATURES table has the following column definition.
"FEAT_UID"     	VARCHAR(100).
And the ff4j_audit has the following, and the insert/update features fails if the feature name length> 30.
"EVT_NAME" 	 VARCHAR(30)  NOT NULL
Is this an issue with my implementation? I increased the size of the EVT_NAME column in ff4j_audit to 100 and the issue seems fixed.
Thanks
Vinod

You are right, it's a bug.
The EVT_NAME should be long enough to have any Feature identifier or Property Name. We reduced in the first place to reduce the space use (there migh be a lot of event out there). I cannot reduce the feature name column without impacting the users.

Part of 1.7


Move "component term" images to different location in hover

The new "component words" feature in the hover includes the component words in the top-level images, but this can get really confusing per https://github.com/jzohrab/lute-v3/issues/354.
The "right" way to handle this -- I think! -- is via allowing interactions with the hover (https://github.com/jzohrab/lute-v3/issues/341) or some kind of settings (https://github.com/jzohrab/lute-v3/issues/236), but those could be a while off.
In the meantime, I think a good stop-gap move would be to move the component images to a different place in the popup, ensuring that the pop-up itself doesn't get really clumsy looking.

Temporarily disabling these component images ... they get messy.

Launched in 3.3.3


Allow default behavior with HTTP interceptors

In our project we wanted to be able to POST to a certain path we had mocked using the in-memory-web-api, but wanted to retain the ability for POST to add collection items without having to reinvent the wheel.  It was not immediately apparent if our service had access to its controlling service object to call the collectionHandler() method, so we just modified the service to accept a null return to continue default processing.  Submitting here in case it is found useful to others.

I signed it!
On Fri, Jul 7, 2017 at 6:23 PM, googlebot<EMAIL_ADDRESS>wrote:

Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project. Before we can look at your
pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll
verify. Thanks.

If you've already signed a CLA, it's possible we don't have your
GitHub username or you're using a different email address. Check your
existing CLA data https://cla.developers.google.com/clas and verify
that your email is set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
If your company signed a CLA, they designated a Point of Contact who
decides which employees are authorized to participate. You may need to
contact the Point of Contact for your company and ask to be added to the
group of authorized contributors. If you don't know who your Point of
Contact is, direct the project maintainer to go/cla#troubleshoot.
In order to pass this check, please resolve this problem and have
the pull request author add another comment and the bot will run again.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/in-memory-web-api/pull/120#issuecomment-313824840,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABJS6qMx6vjXJvI-smFBk5BvwQgjAUkaks5sLtn2gaJpZM4ORlYR
.

Closing for reason give in my review.

Thanks Ward!  Good luck on the refactor.


fix embedded null character

What does this PR do?
Removes potential null character \x00 when log_level: debug which can cause warnings to be raised.
Motivation
2299-embedded-null-character
Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

We really need a test, because I highly doubt that's the source of the error we see. Why do you think that comes from here?

pretty much from local testing. We can also use ensure_bytes(displayed). Thenhttps://github.com/DataDog/integrations-core/blob/7.19.x/snmp/datadog_checks/snmp/snmp.py#L210 would actually log the literal \x00. Granted the null character came from the SNMP raw data but the exception occurs when we try to log it. Commenting out the self.log line
or not using OIDprinter here willl also make the fetch_results not raise an exception.
Also, not sure how to test something that only happens on debug mode. is there a function to check if a certain string was logged? I could replace \x00 with __NULL__ instead and check for its existence if ligged.

We really need a test, because I highly doubt that's the source of the error we see. Why do you think that comes from here?

pretty much from local testing. We can also use ensure_bytes(displayed). Then https://github.com/DataDog/integrations-core/blob/7.19.x/snmp/datadog_checks/snmp/snmp.py#L210 would actually log the literal \x00. Granted the null character came from the SNMP raw data but the exception occurs when we try to log it. Commenting out the self.log line
or not using OIDprinter here willl also make the fetch_results not raise an exception.

Thanks for all the details. I'll test it out as well and come back here.

Any update?


Add current developments beyond W3C?

The official W3C standards seem "frozen in time" around 2005-2010, but several standards are still being developed further, for instance as community groups:

XProc 3.0+: An XML Pipeline Language (draft) and XProc 3.0+: Standard Step Library (draft)

Book: XProc 3.0 Programmer Reference

XSL Transformations (XSLT) Version 3.0 and XSL Transformations (XSLT) Version 4.0 (draft)
...etc

It seems to make most sense to add such links as versions in the XML family section, to help people find more contemporary versions?

Hey Rolf,
Thank you for the suggestions!
I agree that it is essential to help people find the latest developments/drafts. However, I want to ensure a clear distinction between official W3C standards/recommendations and drafts that are still under development.
I propose creating a separate section for actively-developed drafts. This way, we can provide visibility to the latest work without confusing drafts with the finalized standards. I believe this approach will maintain the clarity of the repository while acknowledging ongoing developments in the XML community.
To address the rest of your points:

The suggested book can most certainly be added to the books section.
The XSLT 3.0 is linked in The XML Family section. As you can see, the link leads to the XSLT cover page that lists all specification versions.

Thank you again for your input. If you have any further suggestions or concerns, please feel free to share!

hi Stan,
I agree with adding a section for "active development", or perhaps a section under "community". It could be a way to add other current developments, like the Invisible XML Specification.
I'm still trying to navigate how W3C actually works, between endorsed standards and community initiatives :-)

Sounds like a plan!
I will add a Drafts and Community Specifications section.
Looking forward to all the awesomeness that will end up there.


docs(markdown): migrate docs from rst to md

Migrated docs from readthedocs.io to github.io.

Let's clean up README.md file as well - let's have it similar to https://github.com/splunk/pytest-splunk-addon/blob/main/README.md.
If instructions listed there are valid - let's move them in the documentation, if not - let's remove them.

The content was related to the design of the framework, which I think isn't relevant to developers using this framework, and hence has been removed.

:tada: This PR is included in version 4.0.0-beta.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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


s2n_composite_cipher_aes_sha

Problem:
The chage from v0.9 to v0.10
from : if S2N_OPENSSL_VERSION_AT_LEAST(1,0,2) && !defined LIBRESSL_VERSION_NUMBER
to : if defined(S2N_AES_SHA_COMPOSITE_AVAILABLE)
Is breaking my build.
OpenSSL 1.0.1 doesn't have EVP_aes_256_cbc_hmac_sha256 so I guess that the old check was the correct one.
Solution:
breaking :
#if S2N_OPENSSL_VERSION_AT_LEAST(1,0,1) && !defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL)
#define S2N_AES_SHA_COMPOSITE_AVAILABLE
#endif

into:
#if S2N_OPENSSL_VERSION_AT_LEAST(1,0,1) && !defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL)
#define S2N_AES_SHA1_COMPOSITE_AVAILABLE
#endif

and
#if S2N_OPENSSL_VERSION_AT_LEAST(1,0,2) && !defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL)
#define S2N_AES_SHA256_COMPOSITE_AVAILABLE
#endif

should solve the issue.
(undoing the changes from v0.9 to v1.0 is also an option)
Requirements / Acceptance Criteria:
The code must build with OpenSSL 1.0.1

https://github.com/awslabs/s2n/pull/2195

Thanks for the PR! Just to clarify, the break occurred between v0.9.0 and v0.10.0? I ask because we just moved from v0.10.9 to v0.10.10. I want to be sure we examine the right changeset.

Yes , v0.9.0 to v0.10.0. Introduced by commit https://github.com/awslabs/s2n/commit/9802a051850e8bb8dbfe0f03d66fc9f6249d7bb3
I was using an old version of the lib here. I just updated and noticed the issue.

:shipit: (merged) Thanks!


Avoid elaborating errors when relating primitives to union types of any form.

Fixes #7530.
The idea here is that if you have a primitive, and you're trying to relate to some union type, then that primitive is simply not in the union.

:+1:

:+1:


Task-based Inspection for Dr. Yang #8

Please review the NFR2 of 5.1 Nonfunctional Requirements section of the SRS, what are the goals that you think should user achieve? For example, approximately what amount of time should they spend from opening the website to finding the result they want?
The section 3.2 is also attached. What would be some minimum knowledge that the user should have to use this software?

The software interface should be intuitive and easy to use, allowing users in the section 3.2 to easily choose salt application levels and concerned bridge components, input coordinates or click on the map, look at the predicted chloride exposure, and download the input data and the results of chloride exposure at that specific location in no more than five minutes.
The end user of BCP should have a high school understanding of geographic coordinates. Additionally, users may benet from university level of knowledge of bridge components and chloride-induced corrosion to better understand the context and implications of the predicted chloride exposure.


Weird System bug running as batch file.

command in batch
start "C:\mj" MouseJiggler.exe -j -z -s 60 -m
at this location a file gets created
C:\Users\User\AppData\Local\Temp\system-commandline-sentinel-files(screen shot)

older version did not do this. 1.x

That's an artifact of the command-line parser Mouse Jiggler uses, which registers with the dotnet-suggest tool - if installed - to allow command-line autocompletion. If it's not installed, this error is logged. It's harmless.


ARROW-5343: [C++] Refactor dictionary unification to incremental interface, and use Buffer for transpose map allocations

I went ahead and nixed the current DictionaryType::Unify API since it is fairly internal anyway. I want to code against this API for ARROW-5717 which I'll stack on top of this patch

Travis CI: https://travis-ci.org/wesm/arrow/builds/587244732
Appveyor seems to be passing: https://ci.appveyor.com/project/wesm/arrow/builds/27537470