Ouster Compatability

@rsasaki0109 Hi Sir. I am Working on this repo and it is working perfectly. I have a doubt, does this repo supports ouster internal IMU. Can you please clarify me. Thanks in advance.

I have followed LIO-SAM's lead, and I've supported ouster, but I haven't confirmed that it works.
https://github.com/rsasaki0109/li_slam_ros2/blob/develop/scanmatcher/param/lio.yaml#L4-L6
PR
https://github.com/rsasaki0109/li_slam_ros2/pull/7

@rsasaki0109 Hi. I converted ouster pcap to rosbag and then converted that rosbag into ros2 sqlite3 format (.db3 extension). Does our repo supports sqlite3. I have tried but no mapping no initialization nothing happened. Could you please help me out or can you tell me how to run pcap files directly using our repo. This will be helpful Sir.

You may refer to the section on ouster below.
https://github.com/TixiaoShan/LIO-SAM#other-notes

Yes Sir I have followed the instruction. Actually I converted pcap format file into bag format using this tool https://github.com/Krishtof-Korda/pcap-to-bag.git. After that I used rosbag info it shows topic info but when i use ros2 bag it doesn't showing the topic info.

It would be better to convert ros1 rosbag to ros2 rosbag with the following package.
https://pypi.org/project/rosbags/

Hi. I converted rosbag to ros2 working format version for rosbag_v2 but I have internal IMU recorded data and I tried to play the bag file.Scanmatcher shows the error. I tried to check in image projection.cpp but i couldnot get rid of the error.
praveen@ubuntu:~/ros2_ws$ ros2 launch scanmatcher lio_ouster.launch.py
[INFO] [launch]: All log files can be found below /home/praveen/.ros/log/2023-01-25-16-45-11-188492-ubuntu-17135
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [scanmatcher_node-1]: process started with pid [17137]
[INFO] [static_transform_publisher-2]: process started with pid [17139]
[INFO] [imu_preintegration-3]: process started with pid [17141]
[INFO] [image_projection-4]: process started with pid [17161]
[INFO] [graph_based_slam_node-5]: process started with pid [17174]
[imu_preintegration-3] ----> IMU Preintegration Started.
[static_transform_publisher-2] [INFO] [1674636311.266374576] [static_transform_publisher_bnSGUpiqTIQPmcAH]: Spinning until killed publishing transform from 'base_link' to 'velodyne'
[scanmatcher_node-1] registration_method:NDT
[scanmatcher_node-1] ndt_resolution[m]:2
[scanmatcher_node-1] ndt_num_threads:0
[scanmatcher_node-1] gicp_corr_dist_threshold[m]:5
[scanmatcher_node-1] trans_for_mapupdate[m]:1.5
[scanmatcher_node-1] vg_size_for_input[m]:0.2
[scanmatcher_node-1] vg_size_for_map[m]:0.2
[scanmatcher_node-1] use_min_max_filter:false
[scanmatcher_node-1] scan_min_range[m]:0.1
[scanmatcher_node-1] scan_max_range[m]:100
[scanmatcher_node-1] set_initial_pose:true
[scanmatcher_node-1] use_odom:false
[scanmatcher_node-1] use_imu:true
[scanmatcher_node-1] debug_flag:false
[scanmatcher_node-1] map_publish_period[sec]:100
[scanmatcher_node-1] num_targeted_cloud:20
[scanmatcher_node-1] ------------------
[scanmatcher_node-1] [INFO] [1674636311.289797348] [scan_matcher]: initialize Publishers and Subscribers
[scanmatcher_node-1] [INFO] [1674636311.296548136] [scan_matcher]: initialization end
[image_projection-4] ----> ImageProjection Started.
[graph_based_slam_node-5] [INFO] [1674636311.353489260] [graph_based_slam]: initialization start
[graph_based_slam_node-5] registration_method:GICP
[graph_based_slam_node-5] voxel_leaf_size[m]:0.2
[graph_based_slam_node-5] ndt_resolution[m]:5
[graph_based_slam_node-5] ndt_num_threads:1
[graph_based_slam_node-5] loop_detection_period[Hz]:3000
[graph_based_slam_node-5] threshold_loop_closure_score:1
[graph_based_slam_node-5] distance_loop_closure[m]:25
[graph_based_slam_node-5] range_of_searching_loop_closure[m]:20
[graph_based_slam_node-5] search_submap_num:4
[graph_based_slam_node-5] num_adjacent_pose_cnstraints:5
[graph_based_slam_node-5] use_save_map_in_loop:false
[graph_based_slam_node-5] ------------------
[graph_based_slam_node-5] [INFO] [1674636311.358652508] [graph_based_slam]: initialize Publishers and Subscribers
[graph_based_slam_node-5] [INFO] [1674636311.361475503] [graph_based_slam]: initialization end
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[scanmatcher_node-1] [INFO] [1674636329.199597075] [scan_matcher]: create a first map
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.

@rsasaki0109 I managed to match the ring but hard to manage noise. Internal IMU data works with scanmatcher and started mapping but I can't solve this failed to find match noise issue. I reduced playback speed also but still getting Large Velocity Reset IMU Preintegration. I think it is because of noise in image projection. Could you please help me out.
praveen@ubuntu:~/ros2_ws$ ros2 launch scanmatcher lio_ouster_32.launch.py
[INFO] [launch]: All log files can be found below /home/praveen/.ros/log/2023-01-27-14-57-08-996706-ubuntu-23485
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [scanmatcher_node-1]: process started with pid [23487]
[INFO] [static_transform_publisher-2]: process started with pid [23489]
[INFO] [imu_preintegration-3]: process started with pid [23491]
[INFO] [image_projection-4]: process started with pid [23493]
[INFO] [graph_based_slam_node-5]: process started with pid [23499]
[imu_preintegration-3] ----> IMU Preintegration Started.
[static_transform_publisher-2] [INFO] [1674802629.224041429] [static_transform_publisher_MDU8TaMW2eviw9Zq]: Spinning until killed publishing transform from 'base_link' to 'velodyne'
[image_projection-4] ----> ImageProjection Started.
[scanmatcher_node-1] registration_method:NDT
[scanmatcher_node-1] ndt_resolution[m]:2
[scanmatcher_node-1] ndt_num_threads:0
[scanmatcher_node-1] gicp_corr_dist_threshold[m]:5
[scanmatcher_node-1] trans_for_mapupdate[m]:1.5
[scanmatcher_node-1] vg_size_for_input[m]:0.2
[scanmatcher_node-1] vg_size_for_map[m]:0.2
[scanmatcher_node-1] use_min_max_filter:false
[scanmatcher_node-1] scan_min_range[m]:0.1
[scanmatcher_node-1] scan_max_range[m]:100
[scanmatcher_node-1] set_initial_pose:true
[scanmatcher_node-1] use_odom:false
[scanmatcher_node-1] use_imu:true
[scanmatcher_node-1] debug_flag:false
[scanmatcher_node-1] map_publish_period[sec]:100
[scanmatcher_node-1] num_targeted_cloud:20
[scanmatcher_node-1] ------------------
[scanmatcher_node-1] [INFO] [1674802629.274256107] [scan_matcher]: initialize Publishers and Subscribers
[scanmatcher_node-1] [INFO] [1674802629.285926016] [scan_matcher]: initialization end
[graph_based_slam_node-5] [INFO] [1674802629.404393715] [graph_based_slam]: initialization start
[graph_based_slam_node-5] registration_method:GICP
[graph_based_slam_node-5] voxel_leaf_size[m]:0.1
[graph_based_slam_node-5] ndt_resolution[m]:5
[graph_based_slam_node-5] ndt_num_threads:1
[graph_based_slam_node-5] loop_detection_period[Hz]:3000
[graph_based_slam_node-5] threshold_loop_closure_score:1
[graph_based_slam_node-5] distance_loop_closure[m]:25
[graph_based_slam_node-5] range_of_searching_loop_closure[m]:20
[graph_based_slam_node-5] search_submap_num:4
[graph_based_slam_node-5] num_adjacent_pose_cnstraints:5
[graph_based_slam_node-5] use_save_map_in_loop:false
[graph_based_slam_node-5] ------------------
[graph_based_slam_node-5] [INFO] [1674802629.405143711] [graph_based_slam]: initialize Publishers and Subscribers
[graph_based_slam_node-5] [INFO] [1674802629.411520513] [graph_based_slam]: initialization end
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[scanmatcher_node-1] [INFO] [1674802638.088709724] [scan_matcher]: create a first map
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[imu_preintegration-3] [WARN] [1674802646.148734015] [imu_preintegration]: Large velocity, reset IMU-preintegration!
[image_projection-4] Failed to find match for field 'noise'.
[graph_based_slam_node-5] ----------------------------
[graph_based_slam_node-5] searching Loop, num_submaps:2
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'noise'.

Maybe slowing down the playback speed of rosbag would help.

@rsasaki0109 I tried as you said, recorded the rosbag by slowing down the playback speed. Still same noise error

I see. I'm a little too busy to respond right now...

@rsasaki0109 Once you are free please let me know how to fix this error sir. Awaiting your reply.

Is it possible to have your rosbag provided?

@rsasaki0109 https://drive.google.com/file/d/1TBhBEjeQ_oIxmd-qDBHK1sQvTX6nY4YR/view?usp=sharing

I can't find the ring when I converse your ros1 rosbag with rosbags.
Is the rosbag you provided correct?
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.
[image_projection-4] Failed to find match for field 'ring'.
[image_projection-4] Failed to find match for field 'noise'.

@rsasaki0109 Actually the rosbag that I sent to you is recorded with internal imu not external imu. I am able to solve the issue ring but noise unable to solve. Change image projection ouster struct uint_8t to uint_16t it will solve the ring issue.

Have you calculated the following parameters?
https://github.com/rsasaki0109/li_slam_ros2/blob/develop/scanmatcher/param/lio.yaml#L9-L12
If not, please use the following package to find them.
https://github.com/gaowenliang/imu_utils

Have you calculated the following parameters?
https://github.com/rsasaki0109/li_slam_ros2/blob/develop/scanmatcher/param/lio.yaml#L9-L12
If not, please use the following package to find them.
https://github.com/gaowenliang/imu_utils

@rsasaki0109 Ouster itself has some timestamp issues and they have mentioned in their community. And I don't have ouster lidar right now Sir.

Can you share the link where the ouster timestamp issue is discussed?

@rsasaki0109 Forgive me for the late reply stuck with another project. Timestamp issue has been corrected by ouster 2 weeks ago in their official repo. I converted pcap to rosbag. since the conversion contains /os_node/lidar_packets and /os_node/imu_packets topics, so I replayed the converted rosbag using their official repo https://github.com/ouster-lidar/ouster-ros roslaunch ouster_ros replay.launch  bag_file:=  metadata:= . When the recorded bag was playing in our li_slam_ros2 it gives ring and noise. ring has been solved using uint16_t in Image projection. Even though i reduce the playback speed it gives large velocity reset Imu preintegration. Could you please help me out with this issue. I have been dealing this issue for so long.

@jeychandar
I'm sorry, but I think I accidentally deleted the rosbag you provided. Could you please share it with me again? The link you gave me before has already expired.

@rsasaki0109 I am sharing the pcap and metadata here sir. In case if i did wrong conversion can you check further. since rosbag has larger size I am unable to upload in mydrive.(Mydrive has limited storage). sorry for that.
metadata-- https://drive.google.com/file/d/17IAqYqTlZJi5qYtb_wAS9U32tok8r7Uj/view?usp=sharing
pcap-- https://drive.google.com/file/d/19ZNMHx5Ne9j9SgO36OejQmTnxzws3pmx/view?usp=sharing
pcap to bag conversion link: https://github.com/Krishtof-Korda/pcap-to-bag
Note: After converting the pcap to rosbag it contains only packet messages. You have to replay the converted rosbag into ouster replay and then record.
ouster replay to record bag: https://github.com/ouster-lidar/ouster-ros
command line for reference: roslaunch ouster_ros replay.launch
bag_file:=
metadata:=          # optional if bag file has /metadata topic

@rsasaki0109 Hi sir I am managed to find out the issue and it is working properly. Our repo supports both internal and external IMU for ouster.The issue is based on sensor msg type format. Thanks for the support :)

Hello, I am having the same problem as you.Currently using ouster lidar and external imu is using lord 3DM. Ring, noise problems are occurring the same as you. Please help. Which part did you modify and correct?

For your information, I changed the ring part to 16 based on what you said, so the ring problem disappeared, but the noise problem still occurs.

@lidarmansiwon can you share rosbag info and also try to reduce the playback speed and see if that works.

https://balsam-feet-f83.notion.site/bag_backup-9fed659470f64498b27293a3df5df20c?pvs=4
bag file is so big. so I posted it in notion. so you can get bag in there!
Now, I have ouster and lord 3DM imu. but when I get real sensor data, and using that for slam. it doesn't work too. I can see same error... please help me

Some modifications were made to the image_projection file during the debugging process. I changed the uint8_t ring part to 16 and just annotated the noise part. That's how I executed it, and the code didn't work anymore. When I echo the topic, I found that the data did not come out of the cloudHandler(), and after debugging, the problem occurred in the cloud_deskewed topic function.
There was a problem within the function, but the log "Waiting for IMU data ..." did not occur in the terminal.However, if (imuQueue.empty() || t_f > timeScanCur || t_b < timeScanNext) s were assigned to the false conditional statement, so the function did not spin. So let's process the comments as shown in the picture below
The projectPointCloud function started spinning and something started to be drawn on the rviz. That's the process I've done. I'm saying this because I'm wondering if it'll help you solve it. Thank you for trying to help.

@jeychandar

@rsasaki0109 I am sharing the pcap and metadata here sir. In case if i did wrong conversion can you check further. since rosbag has larger size I am unable to upload in mydrive.(Mydrive has limited storage). sorry for that.
metadata-- https://drive.google.com/file/d/17IAqYqTlZJi5qYtb_wAS9U32tok8r7Uj/view?usp=sharing pcap-- https://drive.google.com/file/d/19ZNMHx5Ne9j9SgO36OejQmTnxzws3pmx/view?usp=sharing
pcap to bag conversion link: https://github.com/Krishtof-Korda/pcap-to-bag
Note: After converting the pcap to rosbag it contains only packet messages. You have to replay the converted rosbag into ouster replay and then record.
Pcap to rosbag converted rosbag link: https://drive.google.com/file/d/1JFvBYXpI46_GKJKC9oYkweSCyG7eGGIE/view?usp=sharing You can replay and record in ouster_ros sir. may be this one will be helpful.
ouster replay to record bag: https://github.com/ouster-lidar/ouster-ros
command line for reference: roslaunch ouster_ros replay.launch bag_file:= metadata:= # optional if bag file has /metadata topic

Can you go into further details on how to convert the bag file to play the right messages?
When i use roslaunch ouster_ros replay.launch only the original /os_node/imu_packets and /os_node/lidar_packets get played.
What topic would you expect to be played to?


[Bug]: Typecast error occurs with string array

Description
function func() returns string[]|error {
    any|error val = ["q"];
    if (val is error) {
        return val;
    }
    return <string[]>val;
}

public function main() {
    string[]|error funcResult = func();
    if funcResult is string[] {
        io:println("str array");
    } else {
        io:println("error");
    }
}

I am getting below error with above code
Running executable

error: {ballerina}TypeCastError {"message":"incompatible types: '(any|error)[]' cannot be cast to 'string[]'"}
        at luheerathan.test1.0:func(main.bal:25)
           luheerathan.test1.0:main(main.bal:29)

Steps to Reproduce
No response
Affected Version(s)
No response
OS, DB, other environment details and versions
No response
Related area
-> Runtime
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response

The type cast expression checks if the value belongs to the target type (the type it is being cast to).

a value belongs to a type if it looks like the type, and it will necessarily continue to look like the type no matter how the value is mutated.

The array constructed with ["q"] is an (any|error)[] since the expected type is any|error. Since it is mutable, it can be updated to have any value, including non-string values. So the cast will fail. If the array was immutable, the cast will succeed.
    readonly & any|error immutableArr = ["q"];
    any|error val = immutableArr;
    if val is error {
        return val;
    }
    return <string[]>val; // succeeds now


Legal compilance changes

I've opened this PR to be able to track and discuss the changes made to be compilant to the EU legislation.
There's plenty left to do, so there are no plans to merge yet.
Releated issues: #973 #972 #971 #657 (Let me know if I've missed any)
Track list

[x] Disable FullStory (Closes #973)
[x] Do not log unnecessay data

[x] Filter out the last octets from the IPs on Morgan

Check https://github.com/mattgodbolt/compiler-explorer/pull/977#issuecomment-402516868 for counterpoint reasons against doing it this way

[x] Ensure we don't keep unnecessary logs for too long
[x] Anonymize Google Analytics data we send

[x] Ensure GA does not store unnecessary data

[x] Ensure Sentry does not get sent sensitive data as part of the error reportings

Should Sentry be disabled if no consent is given?

[x] Create cookie law notifications (Closes #972)

[x] Create base template page for cookie & privacy policies
[x] Make popups linkable

e.g: https://godbolt.org/#changes now directly opens the changelog

[x] Act accordingly to the consent given by the user

That is, store cookies ONLY and ONLY IF consent was given
[x] Ensure we have a working website when cookies are disabled
Don't assume consent for longer than a year!

[x] Make social sharing buttons not use 3rd party js

[x] Disable Twitter js code
[x] Get a static version working
[x] EXTRA BONUS: Add direct sharing of current url bind on share popup

[x] Disable for sites which dont allow html as links

[x] Create cookies.html and privacy.html files

[x] Make consent invalid on policy change

More will be added as we progress. Feel free to add more yourself

3 days is very aggressive. The Avast person said as long as we have some kind of retention policy (like delete after 3 years, or anonymise IPs in logs) then we're OK. They're useful for tracking site stats over a long period of time: I wouldn't want to delete them as soon as 3 days !!! I'd say a minimum is a few years, probably 3 or 4. I don't mind anonymising them after some time (a couple of weeks).
Also, anonymysing the IPs in Morgan might be too soon: if we ever get DoSed, then tracking to an actual real IP might be useful. We can legitimately use these. In fact, anonymising the IPs is overkill really, as they're not "really" user identifying data. It's just nice to not worry about it by filtering them later on.

For the static files (and their hash) we probably need to do something like:
path.join(defArgs.staticDir, webpackConfig.output.publicPath, 'favicon.ico'))

(see the code in app.js), as that knows where the files actually get served from...

Just working on a final pass on the policies, and then will merge.


Add ollama backend

For some use-cases using an external API may be too expensive or unsafe. Using Ollama as a backend allows you to run use aiac completely locally.

Oh damn, I just opened a PR for this, didn't notice this one...
My version has the benefit of not importing the ollama codebase, so we're not taking a large hit on dependencies. Your version has the benefit of returning actual supported models in ListModels (mine are hardcoded). Only problem is that it panics in case of errors, but I guess you had no choice, the interface doesn't call for errors.
I'll keep this open and perhaps rebase the model-related code on top of mine. I just need to figure out if and how to change the interface so that we don't panic.

Nice! I think for Ollama having the actual models is more important in comparison to OpenAI and Bedrock due to how many models are available and ollama also allows users to add customized models

Yep, it's kinda how Bedrock works too, by the way. I've been rethinking whether hard coding the list of supported models makes sense since Bedrock support was added. On the one hand, it allows us to cherry-pick models, those that are actually geared towards code generation so we can maintain a high quality of results. On the other hand, it forces us to release new versions of aiac when models are added and it removes a potentially beneficial flexibility.
I haven't made up my mind yet, but a combination of both might be the way to go.

Since version 5.0.0, we finally no longer hardcode the list of models, and the ListModels method actually contacts the provider API to query for supported models. Thanks for your contribution despite this not getting in, it was helpful.


System namespace fix in WindowsSpeechInputProvider.cs

Overview
Removed System out of #if UNITY_STANDALONE_WIN || UNITY_WSA || UNITY_EDITOR_WIN in WindowsSpeechInputProvider.cs because of missing ref issues while using a Mac #6638
Changes

Fixes: #6638

Verification

As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):
git fetch origin pull/{PR_ID}/head:name_of_local_branch
git checkout name_of_local_branch

/azp run


Comm calls init for you if that's already happened

@cekees - Any reason not to merge this?

Seems OK to me. Should we warn that init hadn't been called?

No, because this object is self-instantiating.  I don't see an explicit reason right now to force the user to know whether init has been called or not.

Sorry, I misunderstood.  Yes, let's log this if it occurs.

I'm a little concerned about the order of events with the Profiling.logEvent function, and that if you try to call it before the profiler has been set up, I believe it hard crashes.  For now I'm not going to add the log functionality here, but I'll raise an issue related to this.

Ooph, I need another cup of coffee.  That function looks safe to me.  I'll open a new PR.


MongoDBHandler can use ext-mongodb instead of userland library

See: https://github.com/Seldaek/monolog/pull/676#issuecomment-161344479
Since the handler class is constructed with the $database and $collection names as strings, we can receive a MongoDB\Driver\Manager instance and log messages with:
$bulk = new MongoDB\Driver\BulkWrite;
$bulk->insert($document);
$manager->executeBulkWrite($database . '.' . $collection, $bulk);

executeBulkWrite() can take an optional WriteConcern as its third argument, but it doesn't look like Monoglog is using that anyway.

ping @jmikola I can't assign you to the issue as you're not a contributor so.. just leave this notification unread as a TODO :p

Too late. I already had the tab open. Please try again!
/me closes tab

ping @jmikola (this is getting absurd) :p

Related PR: #724


Add Qos Policy tests

Added some http req mocking so we can be sure marshaling/unmarshalling works correctly. I added a travis file as well, but its up to you guys to modify it to do what you want it to do.
Also:

reordered methods to better fit CRUD in qos-policy
made all VolumeSpaceAtrributes fields omitempty
added some early http error transformation
added editorconfig file for xml files.

Note: im using a diff library to better show xml file differences, so in order to run tests you need to do go get -t ./netapp

didn't mean to close this

This is the great PR. Thank you.

do you want to enable travis on the main repo?

do you want to enable travis on the main repo?

I kept it enabled! Thank you.


[450] Scroll jumps on swipe

It looks like if you scroll down a post and swipe, the second time you do it the scroll jumps to the middle of the screen.
Like this:
https://docs.google.com/spreadsheets/d/1FWcvX7KiLAppGW2qOICxs8ATWqV1uEsCVdTnq5mK7q8/edit#gid=0&range=A39

Pageviews: (3)
Environment: production (x10)
Range: medium (x3)
Behaviour: not-nice (x1)
Mass: everyone (x5)
PRIORITY: [450]

I thought it may be related to dynamic height ads, but it's not. It also happens in other blogs:
https://docs.google.com/spreadsheets/d/1FWcvX7KiLAppGW2qOICxs8ATWqV1uEsCVdTnq5mK7q8/edit#gid=0&range=A40


hashmark size

smaller hashmark sizes would be helpful

Crosshairs should be thinner and the area in the middle smaller, less ambiguity about what it's pointing at


Feature/marshmellow support

This is great! Thanks for supporting marshmallow.
A suggestion for the future: allow marshmallow fields to be used as input validators:
from marshmallow import fields

def happy_birthday(name, age: fields.Int()):
    """Says happy birthday to a user"""
    return "Happy {age} Birthday {name}!".format(**locals())


Continuously contribute to/support key open-source projects

There are some pieces of software that PostHog would not exist without. We should setup a continuous monthly donation for those projects to do our part to support their continued development. An additional benefit is the visibility it will give PostHog.
What are those key projects? Please comment below👇  providing:

Link to repo
How we use it
Why we should support it
What we'd do if it went away (optional)

Analysis of our codebase to detect dependencies can be seen via https://backyourstack.com/PostHog
How we can sponsor
Open Collective
Open Collective provides a mechanism for us to sponsor projects each month e.g.

GitHub sponsors

Other
In other cases, we may need to contact the project maintainers directly.

I consider rrweb a critical investment.
Not only because we're already getting so much out of it, but also because we're only scratching the surface of session recording and a lot of deep technical work needs to go into making it competitive.
Working together with the people behind it will help us accelerate that development a lot, since our own expertise is much more narrow.
Some other context under https://github.com/PostHog/product-internal/issues/86

This graphile/worker is powering scheduled jobs, retries and other such logic for the plugin server. Its existence definitely saved us a lot of headache.

DRF is pretty critical, but might be quite big already. social-auth-core enables custom auth solutions purely for Enterprise and paid plans, so might make sense to support too.

@timgl can you or someone else with elevated GitHub permissions please give me whatever level of access is required to make sponsorships on GitHub via PostHog? I believe Member should do. See https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/permission-levels-for-an-organization
I presently get the following message when trying to create a sponsorship:

https://github.com/sponsors/Yuyz0112?preview=false&sponsor=PostHog

rrweb
Status: Sponsoring at $100 a month. This will get us logo placement on all of the author's projects.
TODOs:

[ ] PR against the rrweb README to add PostHog under "Who's using rrweb"

Django REST Framework
Status: Signup up. Awaiting set up which isn't fully automated.
$250 for Premium sponsorship which includes logo placement at the top of the main website. Seems like a really good way to both support the framework and get brand visibility.

Thank you so much for your support! :heart: :rocket:


Decrease Android Sync memory usage

This is a set of small changes to reduce memory pressure when doing Android Sync (and similar up-to-date scenarios). Each commit is self-contained, but they are so small that it didn't feel worth it to open four PRs/run four branch builds.

This makes Android Sync ~5% faster.


feature/canvas_drawing_board

Add: feature canvas drawing added

@jay-sharma-simform This should point out to develop branch first. Need to raise new one whenever you get time.
Also review the code and make sure few things like no empty line should be there, add some method description.

Closing PR due to merge conflicts and for pointing to develop


fix(Optional): change checkParent default to true

fixes #94

@jdanyow Looks like there's a unit test that needs to be fixed. If you can patch that up we can get it merged.

forgot to commit :(

Got it :)


RTOS: Make vector catches show originating thread

This follows discussions with Alan Hayward, and research into the
issue of showing HardFaults etc decently.
There has been discussion and attempts to patch GDB to let it unwind
from the Main stack to the Process stack, so that when stopping inside a
HardFault, we could see where the fault had come from. Discussion and
links here:
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1566054
After thought and discussion with Alan, I've concluded that that
approach is not conceptually correct - it would better suit GDB's
target process model to present the Handler Mode as a distinct thread
from the Processes, and ensure they accurately show the full system
state. This patch improves the RTX5 Thread provider to achieve this.
PyOCD's RTOS awareness already effectively achieves this, if you have a
supported RTOS, and my previous patches have helped ensure that the view
of the current thread is as up-to-date as possible when inside an
exception.
In future it would make sense to have a "bare metal RTOS" provider
for pyOCD to present Process and Main stacks as 2 threads, so the
same effect is achieved without an actual RTOS.
This patch is an extra refinement step, which further special-cases the
ARM vector catch stop when you have separate Process and Handler
threads.
Before the patch, when stopping due to a HardFault vector catch, you
would see:
   Thread #5 stopped due to SIGSEGV at HardFault_Handler
   #2 main thread (Running), PC at exception site
   #3 timer thread (Wait[MsgQueue])
   #4 idle thread (Ready)
   #5 Hander Mode thread (HardFault), PC at HardFault_Handler [GDB current]

This patch now gives you a more GDB-conventional view:
   Thread #2 stopped due to SIGSEGV at fault location
   #2 main thread (Running), PC at exception site [GDB current]
   #3 timer thread (Wait[MsgQueue])
   #4 idle thread (Ready)
   #5 Hander Mode thread (HardFault), PC at HardFault_Handler

This view better follows documented GDB behaviour that the "signal" is
reported at the site it occurred. The conventional behaviour is that the
system stops with PC showing the thread that received the signal,
pointing at the instruction we would execute next in the foreground -
for a SIGSEGV this would be the exception-generating instruction itself,
which would be retried if the signal handler (or ARM exception handler)
returned.
The ARM system state isn't modified - at the moment of stop the Handler
Mode thread has come into existence, and its PC still shows the first
instruction of HardFault_Handler.
On subsequent steps, we will step into the handler, and the Handler Mode
thread will be current, just as on a Unix system we might step into the
signal handler (albeit in the same thread, rather than a separate
Handler thread).
This patch only refines behaviour when an exception arises from the
Process stack. If the exception actually happens Handler mode, or in
Thread mode using the Main stack you will still see "SIGSEGV at
HardFault_Handler". But at least you will be in the correct thread - the
site will be 2 frames up the backtrace.

This is very much a first draft - I will continue to experiment with the concept. Thoughts welcome.
Main thing I now note using it is that the typical null pointer write exception in mbed OS is an external bus fault, so this doesn't work that well without a
SCnSCB->ACTLR |=  SCnSCB_ACTLR_DISDEFWBUF_Msk;

to make such faults be synchronous.

FYI @SeppoTakalo

This is what I see when stopping at a HardFault with Argon:

This is showing gdb continuing the backtrace in Handler mode even though the EXC_RETURN value indicates return should be to Thread mode on the Process stack.
I do think gdb should be able to correctly unwind across exception frames, simply to match the way Cortex-M exception stacking works.

the RTX5 thread provider didn't show the PC at HardFault_Handler(),

It did, this is about showing where we came from.

I do think gdb should be able to correctly unwind across exception frames, simply to match the way Cortex-M exception stacking works.

That was the subject of the discussion with Alan. It is what I'd always assumed was needed, prior to having the RTX5 thread awareness, and it's part of what the patches I linked to were looking at. I started off intending to polish them off to do it.
But conceptually it's not anything GDB has ever done on any target, as far as I can tell. GDB cannot unwind exception frames that change processor mode on any platform.
GDB debugs processes, each of which have a single stack, using core registers (r0-r15). Making the leap from Main Stack+Handler to Process Stack+Thread mode by interpreting system registers is kind of out of its scope. Certainly possible - stitching two stacks together to view as a single process - but is it conceptually right? Should ARM-M be a special case? The fact it would be special, and add system registers to GDB for the first time, was part of the reason the patches stalled.
My current view is no. If a Cortex-M system is bare-metal enough to just be using the Main stack, then it's reasonable for GDB to be able to bare metal unwind the Main stack, which it can do with just core registers, in the absence of Thread awareness.
But if a system is using Process stack(s), then that implies an OS, which implies you could get the Thread awareness to take care of showing the Process stack(s) and Main stack(s) alongside each other.
As a minimum, you could arrange for the vanilla unknown-OS pyOCD thread provider to offer the Process stack from PSP whenever in handlers state (if PSP is non-0?). So GDB can see 2 threads.
This patch is kind of independent of whatever happens at the GDB end - it would work regardless of whether GDB stitched stacks together. But it would make sense to agree the principle of how stuff should be presented. If the assumption was that PSP is displayed as different thread(s), then it would be neatest for GDB to terminate unwinding as it sees a Handler returning to Process stack, on the assumption that the Process stack will be visible elsewhere.
So, behaviour of GDB when unwinding Handler->Process exception frame:

Current: keeps unwinding down Handler stack, showing pointless/incorrect info like OS entry SVC
Proposed by previous patches, and my previous view: jump over to current PSP
My current view: terminate unwinding, expect current (and alternate) PSPs to be shown as different thread(s)

the RTX5 thread provider didn't show the PC at HardFault_Handler(),

It did, this is about showing where that fault came from - that's what we really need to know, and we generally struggle to figure out.

I do think gdb should be able to correctly unwind across exception frames, simply to match the way Cortex-M exception stacking works.

That was the subject of the discussion with Alan. It is what I'd always assumed was needed, prior to having the RTX5 thread awareness, and it's part of what the patches I linked to were looking at. I started off intending to polish them off to do it.
But conceptually it's not anything GDB has ever done on any target, as far as I can tell. GDB cannot unwind exception frames that change processor mode on any platform.
GDB debugs processes, each of which have a single stack, using core registers (r0-r15). Making the leap from Main Stack+Handler to Process Stack+Thread mode by interpreting system registers is kind of out of its scope. Certainly possible - stitching two stacks together to view as a single process - but is it conceptually right? Should ARM-M be a special case? The fact it would be special, and add system registers to GDB for the first time, was part of the reason the patches stalled.
My current view is no. If a Cortex-M system is bare-metal enough to just be using the Main stack, then it's reasonable for GDB to be able to bare metal unwind the Main stack, which it can do with just core registers, in the absence of Thread awareness.
But if a system is using Process stack(s), then that implies an OS, which implies you could get the Thread awareness to take care of showing the Process stack(s) and Main stack(s) alongside each other.
As a minimum, you could arrange for the vanilla unknown-OS pyOCD thread provider to offer the Process stack from PSP whenever in handlers state (if PSP is non-0?). So GDB can see 2 threads.
This patch is kind of independent of whatever happens at the GDB end - it would work regardless of whether GDB stitched stacks together. But it would make sense to agree the principle of how stuff should be presented. If the assumption was that PSP is displayed as different thread(s), then it would be neatest for GDB to terminate unwinding as it sees a Handler returning to Process stack, on the assumption that the Process stack will be visible elsewhere.
So, behaviour of GDB when unwinding Handler->Process exception frame:

Current: keeps unwinding down Handler stack, showing pointless/incorrect info like OS entry SVC
Proposed by previous patches, and my previous view: jump over to current PSP
My current view: terminate unwinding, expect current (and alternate) PSPs to be shown as different thread(s)

the RTX5 thread provider didn't show the PC at HardFault_Handler(),

It did, this is about showing where that fault came from - that's what we really need to know, and we generally struggle to figure out.

I do think gdb should be able to correctly unwind across exception frames, simply to match the way Cortex-M exception stacking works.

That was the subject of the discussion with Alan. It is what I'd always assumed was needed, prior to having the RTX5 thread awareness, and it's part of what the patches I linked to were looking at. I started off intending to polish them off to do it.
But conceptually it's not anything GDB has ever done on any target, as far as I can tell. GDB cannot unwind exception frames that change processor mode on any platform.
GDB debugs processes, each of which have a single stack, using core registers (r0-r15). Making the leap from Main Stack+Handler to Process Stack+Thread mode by interpreting system registers is kind of out of its scope. Certainly possible - stitching two stacks together to view as a single process - but is it conceptually right? Should ARM-M be a special case? The fact it would be special, and add system registers to GDB for the first time, was part of the reason the patches stalled.
My current view is no. If a Cortex-M system is bare-metal enough to just be using the Main stack, then it's reasonable for GDB to be able to bare metal unwind the Main stack, which it can do with just core registers, in the absence of Thread awareness.
But if a system is using Process stack(s), then that implies an OS, which implies you could get the Thread awareness to take care of showing the Process stack(s) and Main stack(s) alongside each other.
As a minimum, you could arrange for the vanilla unknown-OS pyOCD thread provider to offer the Process stack from PSP whenever in handlers state (if PSP is non-0?). So GDB can see 2 threads.
This patch is kind of independent of whatever happens at the GDB end - it would work regardless of whether GDB stitched stacks together. But it would make sense to agree the principle of how stuff should be presented. If the assumption was that PSP is displayed as different thread(s), then it would be neatest for GDB to terminate unwinding as it sees a Handler returning to Process stack, on the assumption that the Process stack will be visible elsewhere.
So, behaviour of GDB when unwinding Handler->Process exception frame:

Current: keeps unwinding down Handler stack, showing pointless/incorrect info like OS entry SVC
Proposed by previous patches, and my previous view: jump over to current PSP
My current view: terminate unwinding, expect current (and alternate) PSPs to be shown as different thread(s)

Rebased and split this up into as small a chunks as I can, and transferred most of the relevant changes I made to RTX5 into other RTOS providers.
One of the key improvements - the "actual current thread" was actually already present in the other providers - it appears RTX5 was deficient, so I've brought it into line.
Most of these commits are now straight bug fixes or innocuous refactorings.
Some then improve behaviour slightly - eg unavailable registers.
The last commit is then the key behaviour-changing one, which holds off from flipping "current thread" until after the vector catch stop.

Thanks for the updated commits. I'll try this PR out while I'm working on a project this weekend.

/morph test

If accepting as conceptually right, the last "rework vector catch" commit and should also be extended to cover other providers - the "get live LR" one may also be relevant for some.
As the next step I'm currently looking at the "bare metal" version equivalent version of this - a thread provider with 2 threads for PSP and MSP. Could possibly act as an increased amount of common code for the RTOS providers, as well as eliminate the "no thread provider" special cases from the core.

Excellent! I'm looking forward to the PSP/MSP provider.

To be honest, I'm not sure how I feel about showing the faulting thread as current when the actual PC is at the HardFault_Handler. When break in the debugger through whatever means, I expect (or at least, I'm very much used to) the debugger showing the actual PC.
To me, the most important part of this PR is fixing up the running thread view. Showing the HardFault_Handler as active when breaking tells the user that something broke. They can then look at the running thread for the faulting instruction.
If you drop the last commit, I can go ahead and merge this. Then we can continue the discussion 😄

I expect (or at least, I'm very much used to) the debugger showing the actual PC.)

Yes, that's certainly what we're used to in "bare metal". Very much not what happens once you start putting stuff on top of the bare metal, and I've come around to the view that it is just expectation.
GDB has a high-level thread view - it was never designed for bare metal - and we have scope for a certain amount of interpretation in presenting that, and what we do now is a "literal to the hardware" interpretation - excessively so in that it's somewhat off as a standard GDB thread/signal view.
GDB documentation is very clear that the expectation is that the debugger stops showing the thread that the "signal" was delivered to.  "SIGSEGV in thread X at YYY" is the truth, or at least as close as we can get to it for GDB's presentation. "SIGSEGV in thread MainStack at HardFault_Handler" is very much not it, unless the first instruction of HardFault_Handler has trapped itself.
Certainly this is a compromise - the PC is really in the MainStack/HandlerMode thread at the instant of stop. But then in Unix at the instant of stop the execution path is already "going in" to the signal handler - if you step from SIGSEGV it won't execute the instruction the visible PC is pointing at, it will head into the pending signal handler. So in both cases PC points at where we /were/, but it's not what we will execute next. (And with this patch, step from SIGSEGV does flip the view immediately to the HandlerMode thread.)
Some older ARMs (or at least the debugger I used way back) had the decency to actually stop on the exception-causing instruction /without/ entering the handler, which was ideal. No compromise needed on the view. Although it did mean then you got a bit stuck if you wanted to continue because a step would just retrigger the fault. Hard to either get past the instruction in the thread or into the handler. Would need to disable the catch temporarily and set a breakpoint in the handler.
Anyway, sure, I can separate it. I'll put the fixes into a separate PR, so this can stay discussion of the final commit. (When I started this, I never realised how close the RTX5 view was to what I wanted, and it mainly just needed some exception-handling fixes).

Rebased, and extended to all RTOS providers. Session option added to control behaviour.
Selection of HandlerModeThread as current when IPSR > 0 is now performed up in GDBServer, so is not required to be fitted to every ThreadProvider, and that centralises the session option logic.  A logical next step would be to eliminate all HandlerModeThread references from the thread providers, and have it centrally added to the OS-derived list they supply.
If we wanted this to be more general a possible structuring would to separate RTOS ThreadProviders from "core" ThreadProviders.  RTOS ones would provide all the banked Process stacks, and "core" ones would provide any extra handlers (just 1 for ARM-M, but IRQ/SVC/FIQ... for ARM-A).

Okay, my last couple of edits broke something, so don't bother testing - will need to fix this up tomorrow. Feel free to comment though.

Thanks again, especially for the session option!

Fixed - seems to be working okay now.

/morph test

Showing the context in which a hardfault occurred rather than the hardfault ISR
I like the idea of this, but I don't like the fact that what the debugger is showing you doesn't match reality. My expectation for being in the context the fault occurred in is I can manipulate the PC and registers to replay the failure. This is not the case, as moving the PC back is either meaningless (As the thread won't execute again) or a problem if the PC from the fault context is moved without returning from the exception.

Showing the context in which a hardfault occurred rather than the hardfault ISR

My expectation for being in the context the fault occurred in is I can manipulate the PC and registers to replay the failure.

99% of C developers are not capable of doing this. For most, the PC is too abstract, and that is why debuggers like GDB have been invented for them. Also, you seem to assume knowledge of Cortex-M cores for embedded developers. I have seen quite opposite.
Therefore I very much like the debugger showing where the HardFault originated from, and if this means that register values don't match anymore, it is a limitation that I can happily live with. The stuff that I'm interested with have so far been the local variables, and parameters on where the hardfault happened.

My expectation...

This PR does have a session option to retain current catch behaviour, so there is scope for taste/expectations. I guess we're just debating the default.

the debugger is showing you doesn't match reality.

I did consider and discard some other approaches because they would have (IMO) violated that rule. This one was close enough to make me comfortable.

My expectation for being in the context the fault occurred in is I can manipulate the PC and registers to replay the failure.

This change doesn't affect our ability to do that. (Or at least, I don't believe it does.) The only change is which thread is selected in GDB at the instant of vector catch stop, as far as I'm aware. Nothing else about the presentation is modified. If you just click on the "Handler" thread (or use the "thread" command to select it), you're back to where you were without this change.
Note: as far as I can see currently all writes to a thread's registers in pyOCD are treated as writes to live registers, so it only really behaves sensibly when GDB's selected thread is the real current one. If this were improved so that writes to non-live threads modified the parked OS state or exception return frame,  I still don't think this change would affect the situation.
I agree with Seppo that wanting to manipulate the "raw" stack frame and registers, rather than looking at the variables of the faulting thread, is going to be 1% of cases, which is why I think the default should be the new form.
You're possibly operating at one extreme here where I suspect you'd like each GDB "thread" to be mapped raw to 1 CPU. Just see live registers, with no interpretation. That's the purest view, and you could extend it to SMP - 4 threads for 4 cores, so 4 sets of live registers. No danger of confusion.
But with all these pyOCD non-SMP RTOS (or Process+Main stack) approaches, there is still always exactly 1 "live" thread which is working like that, showing the live registers that you can also write to, while the others are "parked". GDB doesn't display the current thread directly, but you can infer it from which pops up when you stop. This change does mean there's an extra inference required - when it's a vector catch the Handler thread appears but is not immediately selected. I think that's an extra inference anyone capable of manually manipulating an exception unwind is also capable of.
(You can infer that the live CPU is really stopped at the first instruction of the handler by the fact that it was a SIGSEGV, and that the Handler thread exists at all - it doesn't if not in a handler).

Rebased, no changes. But note that #453 ends up reworking the implementation significantly (and changes the option name to be generic).

Rebased and retested.

Thanks for rebasing! I'll merge this if you make the default for vector_catch_show_process as False. Sam Grove does not want this to be the default view (sorry).

Missed this comment, or I would have discussed it with him when he was visiting last week...

If we do want to take this without #453, I'll probably want to pull in at least the edit to the option name, to keep the path open to #453.

Pulled in the more generic option name and description from #453, not flipped the default yet.  Going to discuss with Sam.
Guess if it ends up off I just need to spend the time to add it to the Eclipse plugin GUI, so it's trivial to activate...

There are a lot of things I'd like to add to the Eclipse plugin, to make it easier to set any of the declared user options, among other improvements. 😄

I know that this is a bit outdated, but still very usefull change to PyOCD. Hugely improves GDB experience, so I recommend that you try to merge this in.

Yep, this should be rebased and merged in.

I can look at this again now I'm back. (FWIW, I did have that discussion with Sam Grove back in March, and won him around - although it seems he wasn't specifically opposed as @flit believed).
I got a bit stuck on #453, because I was having issues with the tests, but this one should be okay standalone.
I've also seen a few pyOCD crashes arising inside the RTOS awareness code when there's bad OS state - it needs to be a little more robust when trying transfers - add some more exception handling. I should start investigating that too.

Rebased and adjusted - this is now the more-generically-named version from #453. (vector_catch_show_origin instead of vector_catch_show_process).


Fixes #341 (Make Quilt work on Android)

Use android-compatible API for token expiry.
Update build file to easily support building for both JRE and Android platforms.

Signed-off-by: David Fuelling<EMAIL_ADDRESS>

Well... :shipit: once the build passes. Changes seem straightforward.


Added updateShipment DHL-Method plus a helper method

I forgot to add the Shipment-Number to the update request, I will fix this before I merge it
Will also update the Doku


Why the dataset has to be aligned

i ran the following script ,
sudo python align_dataset_mtcnn.py /datasets/lfw/raw /datasets/lfw/lfw_mtcnnpy_160 --image_size 160 --margin 32 --random_order --gpu_memory_fraction 0.25
May I know what this script basically does? why do we have to align it? This doesn't explain why alignment is necessary

The code in the repository does not do a proper facde alignment. In fact, it does not even use the facial landmarks points from MTCNN. All it does is recropping the image based on the face detected bounding box.
There are some papers claiming that doing alignement does not help in training DCNN for face recognition. See for example http://openaccess.thecvf.com/content_cvpr_2017_workshops/w6/papers/Ferrari_Investigating_Nuisance_Factors_CVPR_2017_paper.pdf

okay thank you...


Roll engine 8176f4d3c467..75e404f39ef5 (4 commits)

https://github.com/flutter/engine/compare/8176f4d3c467...75e404f39ef5
git log 8176f4d3c467..75e404f39ef5 --no-merges --oneline
75e404f39 Roll src/third_party/skia 656cefe65d62..b726c89ff8a8 (8 commits) (flutter/engine#6370)
2a22019a8 Roll Dart to version 7f9a9feae181573cca609fd1b8760d7992176699 (flutter/engine#6366)
0fa159a26 Add debug info to figure out why the bots are unhappy (flutter/engine#6369)
e031ccef7 Add missing binding for pushOffset (flutter/engine#6367)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

@rmistry @liyuqian : New roll has been created by https://autoroll.skia.org/r/flutter-engine-flutter-autoroll

Trybots failed. These were the failed builds: https://flutter-dashboard.appspot.com/build.html

Commit queue failed; closing this roll.


Video was taken for map reconstruction

Hello author, is it possible to take videos of local scenes and then reconstruct dense maps through this algorithm

Hi, Thanks for your interest!
In its current form, SplaTAM doesn't directly support this. We hope to have future work to make this super easy.


Extension fails to execute build task

I installed this extension and got it setup. I've read through the documentation and searched for solutions online with no luck.
When I attempt to build the program, I get this back:
> Executing task:  && C:/ProgramData/chocolatey/bin/gcc.exe -Wall -Wextra -Wpedantic --std=c99 -g3 -O0 -c f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\main.c -o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\main.o && C:/ProgramData/chocolatey/bin/gcc.exe -Wall -Wextra -Wpedantic --std=c99 -g3 -O0 -c f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\champion.c -o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\champion.o && C:/ProgramData/chocolatey/bin/gcc.exe -Wall -Wextra -Wpedantic --std=c99 -g3 -O0 f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\main.o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\champion.o -o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\outDebug.exe <

&& was unexpected at this time.
The terminal process "C:\Windows\System32\cmd.exe /d /c  && C:/ProgramData/chocolatey/bin/gcc.exe -Wall -Wextra -Wpedantic --std=c99 -g3 -O0 -c f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\main.c -o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\main.o && C:/ProgramData/chocolatey/bin/gcc.exe -Wall -Wextra -Wpedantic --std=c99 -g3 -O0 -c f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\champion.c -o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\champion.o && C:/ProgramData/chocolatey/bin/gcc.exe -Wall -Wextra -Wpedantic --std=c99 -g3 -O0 f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\main.o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\champion.o -o f:\UTSA\Classes\Fall 2021\CS-1714-0D1\Projects\champions\build\Debug\outDebug.exe" terminated with exit code: 1.

I looked into it and got the idea it may have been due to the terminal being used by VS Code, so I changed the integrated terminal shell selected from cmd to powershell.exe. Unfortunately, nothing changed. Search results past this yield no results and I'm now lost about what I should do from here.
Windows 10.0.19042
VS Code 1.62.2
C/C++ v1.171
C/C++ Runner v1.5.5

I will look into this.
Is your compiler based on a MinGW Compiler?
I am asking because the logic of executing tasks is different for Cygwin and MinGW based compilers on windows.
As a side note in my opinion cmd should work with less issues than the powershell.

I could not reproduce the issue.
I had a similar issue in the past with the VSCodes Python extension.
After a restart of VSCode, it worked again.
Seems to be related to the Task Interface of VSCode's API.

Will be fixed in release 2.0.


Quick and dirty retry logic

This PR implements a quick and dirty solution for the problem raised in https://github.com/cloudfoundry/vcap-services-base/issues/21

Give us a day or two to figure out whether we can move this repo to cloudfoundry-community. There's a CAB call tomorrow.

Hello @rkoster so the guidance from the Foundation is we should move this repo to cloudfoundry-attic, and you should fork it into cloudfoundry-community to live on as long as you'd like to maintain it.
Would you like to fork now, and we can update the README on this one to point to your fork? Then you can make the change in this PR directly and we'll close this PR without merge.
Thank you!

@shalako the fork has been created in cloudfoundry-community will merge the PR there thanks

Thank you, @rkoster. I've updated the README on our copy to point to yours. We'll be moving our repo to cloudfoundry-attic.


Numeric input's increment/decrement buttons displayed outside window when outside viewport

Microsoft PowerToys version
0.55.0
Running as admin

[X] Yes

Area(s) with issue?
Settings
Steps to reproduce

Focus a numeric input in settings
Scroll the control out of view

✔ Expected Behavior
The popup with increment/decrement buttons should disappear as it's scrolled out of the viewport.
❌ Actual Behavior
The increment/decrement buttons remain visible, outside the containing window.
Here, "Crosshairs border size (px)" setting has focus:

Other Software
No response

cc: @niels9001 Same cause as #13346 (https://github.com/microsoft/microsoft-ui-xaml/issues/4554)?

Closing this as duplicate of: https://github.com/microsoft/PowerToys/issues/13346


write

There were problems in writing when writing the Arabic language with English words. The only problem in the application is that there are problems in writing, and the rest is a wonderful program.

/needsMoreInfo
Please provide more examples on how to reproduce problem. Great if you can also provide screenshots/videos to show it.


Chapter12: Update packages, use python 3.8, fix docker-compose file

Update packages and lock versions
Update Dockerfiles to use python 3.8 base image
Update docker compose file to add tags to pulled images

Fix #15


Can't delete from Athena table

I've created database, table and imported some data with awswrangler following the tutorial.
Now, when I try to DELETE anything from this table (all table or just subset of the table), I get the following error:
GENERIC_INTERNAL_ERROR: Can not create a Path from an empty string

What SO suggests: it happens when database or table is created without location, see
https://stackoverflow.com/questions/64459472/can-not-create-a-path-from-an-empty-string-error-for-create-table-as-in-hive
Indeed, when creating the database, no location is asked, so I assume this is the problem.
My goal is to have working deletion from Athena database (without deleting the whole table), suggestions are welcome

@arogozhnikov Is this the tutorial you followed? Both wr.catalog.create_parquet_table and wr.s3.to_parquet require path when creating a table so I'm not quite sure how you succeeded to create a table without a location. Could you share wrangler calls, code, or the tutorial you went through to help us reproduce, please?

Yes, I followed that tutorial.
Though looks like one can't delete data from athena using DELETE statement (which I was trying to achieve).


[WIP] Welch PR 1 - add spectral helper

Breaking up #3820 into smaller steps.
This one adds _spectral_helper from scipy.signal.spectral which is needed for different window reductions (median, trimmed mean etc. - this will come in subsequent PR) - because all public scipy functions reduce windows with mean by default. This function has been somewhat adapted by throwing out unnecessary functionality. More on this in notes section of _spectral_helper, copied below:

Differences with respect to scipy.signal.spectral._spectral_helper:

only one data argument - x instead of x and y, because csd is not
computed
sampling frequency (fs) is no longer optional
always returns one-sided spectrum thus return_onesided arg is gone
use 'density' scaling by default (this is the default for
scipy.signal.welch)
mode is always 'psd' so mode argument is removed

Todos:

[ ] add tests against scipy's csd of relevant features of _spectral_helper

Things to discuss:

is the way _spectral_helper is adapted ok for you?
_spectral_helper returns psd, time and freq - but time is unused and freq is computed in _psd_welch - so these return args could be removed from _spectral_helper
I removed _compute_psd because it was not used anywhere

There is an ImportError: numpy.core.multiarray failed to import in make_scalp_surfaces - I assume it is unrelated.

Yes that has been happening on all PRs. Anaconda must have updated something and broke it

naughty anaconda... 🐍

Ok, this needs a few more tests, and also it turns out detrend=False does not work on scipy 0.12 (I think I'll just make a separate test function that is dependent on scipy 0.17 - is that ok?).
Before I add more tests and fix the scipy 0.12 issue in tests I would like to know if _spectral_helper is ok as it is now or should I change it (for example - add some features that I threw out).

You should be able to use requires_version('scipy', '0.17')

Ok, these are the options that are available in _spectral_heper but not through psd_welch - which ones should I remove from _spectral_helper and which should I add to psd_welch (later on)?:

axis - this one I can definitelly remove (will be -1 without ability to change)
scaling?
detrend?
window - might be useful but I can remove it too
nfft - this will be handled in padding so I don't plan removing this

I'd get rid of all but nfft, otherwise we should probably write tests to make sure all of the others work

Some of these options are already tested (at least to some degree), I'll see if I manage to save window and detrend with relevant tests :)

Sorry to just notice/remember this now, but I think you might be able to get away with using spectrogram instead since it's a thin wrapper over _spectral_helper but we should be guaranteed API stability:
https://github.com/scipy/scipy/pull/6655#issuecomment-252364107

Right, that will be better. No problem - I should have looked closer for wrappers around _spectral_helper.
Should I open another PR or change it here?

Changing it here is fine, we squash and merge now anyway

It was easier to start clean - closing in favor of #3823


'safe' option for update: exit if there are migrations

Propose a feature:
Could a "safe" mode be added to update such that if there are any migrations required the update is cancelled, giving the user a chance to backup the brew installation directory before proceeding?
Or is there a way to list pending migrations before they're executed?
An update in a package that breaks is relatively easy to fix by reverting/editing the brew file.
But a migration seems to be able to relocate a package, rename it, remove it, replace it with a cask, etc. Much harder to unwind.
Although breaks due to migration issues seem to be rare, they're a big time-suck to unravel if they do happen.
Part of it is user expectation; after using package managers like apt I've come to assume update is non-destructive to the installed application state; i.e. it only changes package meta-data. I'm used to upgrade being the destructive step.
If it's not trivial/won't be considered, can some further verbiage be added to the text that @MikeMcQuaid added in  https://github.com/Homebrew/brew/commit/664d0c67d5947605c914c4c56ebcfaa80cb6eca0? (Thanks Mike!)
e.g. something like:

Migrations are internal updates and changes that brew needs to perform. These typically only affect brews internals, but sometimes involve moving and renaming installed formula. There is a chance update can break packages; you may wish to backup the brew installation before updating.

If it's helpful I can make a pull request to add the above (after suggestions/feedback below...) to the files @MikeMcQuaid edited in https://github.com/Homebrew/brew/commit/664d0c67d5947605c914c4c56ebcfaa80cb6eca0.
Specifically:

Library/Homebrew/cmd/update.sh
docs/brew.1.html
manpages/brew.1

Are there any other spots that that could/should be added to?
(I don't have capacity to learn internals/edit code- but text changes I can handle.)

Sorry, not running migrations breaks a bunch of internal assumptions we have and I don't want to recommend a backup for this case. Thanks anyway.

Thanks @MikeMcQuaid. Is it that by doing the (git) update it might require migrations to keep the metadata etc 'sane'? i.e. to detect that there would be migrations, they in effect become mandatory?
If that's the case, I see where you're coming from.
Would you be against a pull request adding a bit more description re migrations to the docs?
Admittedly, I've only been bitten by a bad migration once... but it proved to be a royal pain to get myself out of.

Thanks @MikeMcQuaid. Is it that by doing the (git) update it might require migrations to keep the metadata etc 'sane'? i.e. to detect that there would be migrations, they in effect become mandatory?

Yes, pretty much. Basically once Git has been updated if e.g. formulae have been renamed or migrated we need to handle that immediately otherwise there's weird errors and messaging that are hard to figure out unless you're a developer (and there's no particularly easy way around them as our e.g. rename and migration system is heavily hooked into Git itself).

Assuming detection makes the migration mandatory, would you be against a pull request adding a bit more description re migrations to the docs?

That seems reasonable, we can debate the wording there, thanks for the offer ❤

Admittedly, I've only been bitten by a bad migration once... but it proved to be a royal pain to get myself out of.

The Inkscape one? Just for reference that's a known problem that won't be recurring.


Ember 2.12 incompatibility?

Running my tests suite with Ember 2.12.0 produces the following warning:
DEPRECATION: Addon files were detected in [...]/node_modules/ember-load-initializers/addon, but no JavaScript preprocessors were found for ember-load-initializers. Please make sure to add a preprocessor (most likely ember-cli-babel) to in dependencies (NOT devDependencies) in ember-load-initializers's package.json.
... even though ember-cli-babel is set as a dependency in package.json for ember-load-initializers.
Then, my test suite fails with:
not ok 1 PhantomJS 2.1 - Global error: SyntaxError: Use of reserved word 'export' at http://localhost:7357/assets/test-support.js, line 14642
Locking Ember to 2.11.0 fixes the issue.
My package.json:
{
  [...]
  "devDependencies": {
    "broccoli-asset-rev": "^2.4.2",
    "ember-ajax": "^2.0.1",
    "ember-basic-dropdown": ">= 0.16.0-beta.6",
    "ember-cli": "^2.11.0",
    "ember-cli-app-version": "~2.0.0",
    "ember-cli-babel": "^5.1.6",
    "ember-cli-dependency-checker": "^1.2.0",
    "ember-cli-dotenv": "1.2.0",
    "ember-cli-fastclick": "1.2.0",
    "ember-cli-gzip": "^1.1.3",
    "ember-cli-htmlbars": "^1.0.3",
    "ember-cli-htmlbars-inline-precompile": "^0.3.1",
    "ember-cli-inject-live-reload": "^1.4.0",
    "ember-cli-jshint": "^1.0.0",
    "ember-cli-loading-slider": "1.3.0",
    "ember-cli-mirage": "^0.2.1",
    "ember-cli-mocha": "^0.10.4",
    "ember-cli-moment-shim": "2.0.0",
    "ember-cli-rails-addon": "~0.8.0",
    "ember-cli-release": "^0.2.9",
    "ember-cli-sass": "~5.4.0",
    "ember-cli-sentry": "2.4.2",
    "ember-cli-sri": "^2.1.0",
    "ember-cli-test-loader": "^1.1.0",
    "ember-cli-uglify": "^1.2.0",
    "ember-cli-underscore": "0.0.3",
    "ember-data": "^2.11.0",
    "ember-export-application-global": "^1.0.5",
    "ember-font-awesome": "2.1.1",
    "ember-i18n": "^4.2.2",
    "ember-i18n-iso-countries": "1.1.0",
    "ember-intl-tel-input": "^1.2.0",
    "ember-load-initializers": "^0.6.3",
    "ember-moment": "^7.0.0-beta",
    "ember-percy": "1.2.5",
    "ember-pikaday": "2.1.0",
    "ember-power-select": "^1.4.4",
    "ember-resolver": "^2.0.3",
    "ember-route-action-helper": "^2.0.0",
    "ember-social-share": "git://github.com/jdurand/ember-social-share.git",
    "ember-wormhole": "^0.4.0",
    "loader.js": "^4.0.1",
    "torii": "git://github.com/jdurand/torii.git"
  }
}

Any hints on where to look at?

DEPRECATION: Addon files were detected in [...]/node_modules/ember-load-initializers/addon, but no JavaScript preprocessors were found for ember-load-initializers. Please make sure to add a preprocessor (most likely ember-cli-babel) to in dependencies (NOT devDependencies) in ember-load-initializers's package.json.

This warning was fixed in https://github.com/ember-cli/ember-load-initializers/pull/37, and released in 0.6.3.

not ok 1 PhantomJS 2.1 - Global error: SyntaxError: Use of reserved word 'export' at http://localhost:7357/assets/test-support.js, line 14642

I doubt that this issue is caused by ember-load-initializers.  The best thing to do would be to inspect dist/assets/test-support.js at line 14642 and see what addon that is from.  Most likely they are not properly transpiling in a custom treeForAddon hook.

I'm going to close this for now, as I do not believe this is an issue here.  Please feel free to continue the conversation as you dig deeper into your various addons...

I have the same problem with the addon 'ember-ted-select' (2.2.2) and Ember 2.13.1.
Downgrading to Ember 2.11.0 fixed it.
The error message:
DEPRECATION: Addon files were detected in /node_modules/ember-ted-select/addon, but no JavaScript preprocessors were found for ember-ted-select. Please make sure to add a preprocessor (most likely ember-cli-babel) to in dependencies (NOT devDependencies) in ember-ted-select's package.json.
Ember-ted-select's package.json already contains '"ember-cli-babel": "^5.1.7"'.
Se https://github.com/tedconf/ember-ted-select/blob/master/package.json


chore(ci): add self-test workflow

Overview
Closes #115
This pull request adds a new workflow to self-test the pull request before merging. It listens to pull_request event.

Pull Request Validation Report
This comment is automatically generated by Conventional PR
Whitelist Report

Whitelist
Active
Result

Pull request is a draft and should be ignored
✅
❌

Pull request is made by a whitelisted user and should be ignored
❌
❌

Pull request is submitted by a bot and should be ignored
✅
❌

Pull request is submitted by administrators and should be ignored
❌
❌

Result
Pull request does not satisfy any enabled whitelist criteria. Pull request will be validated.
Validation Report

Validation
Active
Result

All commits in this pull request has valid messages
❌
✅

Pull request does not introduce too many changes
❌
✅

Pull request has a valid title
✅
✅

Pull request has mentioned issues
✅
✅

Pull request has valid branch name
❌
✅

Pull request should have a non-empty body
✅
✅

Result
Pull request satisfies all enabled pull request rules.
Last Modified at 21 Dec 23 00:39 UTC


smaller default makefile target

Erlang.mk builds the default target from the makefile, which can be pretty slow if it has to set up dialyzer. This PR makes the default target just build, without running any checks or tests.

@waisbrot This is actually an explicit choice on our part. We are strong believers that all the checks should be run on every build. The dialyzer is only slow on the first one. then its somewhat reasonable.  So while I have no problem at all with the existence of a quick target. I wouldn't want it to be the default.

I believe that Rebar builds its (Rebar-using) dependences with rebar compile, so your tests aren't run by people using that build system. My test/no test expectations here are based on dpkg, RPM, homebrew, pip, CPAN, NPM, and Maven, which all default to not running tests even though some (all?) of them are capable of testing the packages they install.
I just rewrote this PR. See if it's more palatable to you? In the updated version, I'm using MAKELEVEL to decide if dialyzer should run. So if you say make in episcina, you'll get dialyzed. But if you say make in some erlang.mk project that pulls in episcina and ultimately runs $(MAKE) -C $$dep, then you get no dialyzer.

Closing this. I'm going to be getting rid of the Makefile as we move to rebar3 anyway.


fix for consul startup script

Consul startup script needs host name/ip for consul cli to function properly, at least for cases where ip is bound to different network device i.e. eth1 etc.

molecule was updated with breaking changes.

Hi, wasn't even aware this is still relevant :)
Nice to see there is still appetite for this change.
We've moved on from this mix of tech in the meantime, but if you feel this will be beneficial please feel free to still merge this PR.
Cheers,
Christian


g:plug_timeout is not respected for SSL connection timeout

When I do :PlugUpdate, it takes much more time than expected according to the configuration of g:plug_timeout and g:plug_retries.
let g:plug_timeout = 10
let g:plug_retries = 0

It takes over 300 seconds, and it's because of vim-open-color entry, which gets SSL connection timeout.
Updated. Elapsed time: 306.388908 sec.
[==========================================================xx]

- Finishing ... Done!
- vim-rubocop: Already up to date.
- fzf: Already up to date.
- vim-plugin-AnsiEsc: Already up to date.
- lightline.vim: Already up to date.
- matchit: Already up to date.
- vim-diff-fold: Already up to date.
- php.vim-html-enhanced: Already up to date.
- vim-rst: Already up to date.
- bullets.vim: Already up to date.
- vim-smali: Already up to date.
- vim-gtfo: Already up to date.
- rbs.vim: Already up to date.
- aheui.vim: Already up to date.
- tabular: Already up to date.
- adblock-filter.vim: Already up to date.
- vim-polyglot: Already up to date.
- vim-markdown: Already up to date.
x vim-open-color:
    fatal: unable to access 'https://github.com/yous/vim-open-color.git/': SSL connection timeout
- vim-eunuch: Already up to date.
- coc.nvim: Already up to date.
- vim-repeat: Already up to date.
- vim-git: Already up to date.
x goyo.vim:
    fatal: unable to access 'https://github.com/junegunn/goyo.vim.git/': Recv failure: Connection reset by peer
- vim-wordmotion: Already up to date.
- vim-obsession: Already up to date.
- vim-endwise: Already up to date.
- gv.vim: Already up to date.
- vader.vim: Already up to date.
- rainbow_parentheses.vim: Already up to date.
- vim-unimpaired: Already up to date.
- editorconfig-vim: Already up to date.
- vim-gas: Already up to date.
- vim-rake: Already up to date.
- vim-python-matchit: Already up to date.
- vim-signify: Already up to date.
- vim-oscyank: Already up to date.
- smt-vim: Already up to date.
- a.vim: Already up to date.
- vim-tradewinds: Already up to date.
- echodoc.vim: Already up to date.
- vim-fugitive: Already up to date.
- vim-dirdiff: Already up to date.
- vim-closetag: Already up to date.
- vim-sandwich: Already up to date.
- vinarise.vim: Already up to date.
- ale: Already up to date.
- Recover.vim: Already up to date.
- fzf.vim: Already up to date.
- zoomwintab.vim: Already up to date.
- vim-dirvish-git: Already up to date.
- splitjoin.vim: Already up to date.
- diffchar.vim: Already up to date.
- quick-scope: Already up to date.
- Colorizer: Already up to date.
- vim-gutentags: Already up to date.
- vim-plist: Already up to date.
- vim-dirvish: Already up to date.
- FixCursorHold.nvim: Already up to date.
- vimtex: Already up to date.
- traces.vim: Already up to date.

Pasting my Plug block, but it doesn't really relevant with this issue.
Plug block

call plug#begin(s:vimfiles . '/plugged')

" -----------------------------------------------------------------------------
" Colorscheme
" -----------------------------------------------------------------------------
Plug 'yous/vim-open-color'

" -----------------------------------------------------------------------------
" General
" -----------------------------------------------------------------------------
if !exists('+fixendofline')
  " Preserve missing EOL at the end of text files
  Plug 'yous/PreserveNoEOL', {
        \ 'commit': '9ef2f01',
        \ 'frozen': 1 }
endif
" EditorConfig plugin for Vim
Plug 'editorconfig/editorconfig-vim'
" A Plugin to show a diff, whenever recovering a buffer
Plug 'chrisbra/Recover.vim'
" obsession.vim: continuously updated session files
Plug 'tpope/vim-obsession'
if has('timers') && exists('v:exiting')
  " Fix CursorHold Performance
  Plug 'antoinemadec/FixCursorHold.nvim'
endif
" Ultimate hex editing system with Vim
Plug 'Shougo/vinarise.vim'
" Vim sugar for the UNIX shell commands
Plug 'tpope/vim-eunuch'
" the missing window movement
if exists('*win_screenpos') || exists('nvim_win_get_position')
  Plug 'andymass/vim-tradewinds'
endif
" Vim plugin to diff two directories
Plug 'will133/vim-dirdiff'
" Vim: file and hunk folding support for diff/patch files.

Plug 'dkarter/bullets.vim'
" Auto close (X)HTML tags
Plug 'alvan/vim-closetag', {
      \ 'for': ['html', 'javascript.jsx', 'php', 'xhtml', 'xml'] }
" Simplify the transition between multiline and single-line code
Plug 'AndrewRadev/splitjoin.vim'
" The set of operator and textobject plugins to search/select/edit sandwiched
" textobjects
Plug 'machakann/vim-sandwich'
" Pairs of handy bracket mappings
Plug 'tpope/vim-unimpaired'
if v:version == 704 && !has('patch754') || v:version < 704 && v:version >= 700
  " Produce increasing/decreasing columns of numbers, dates, or daynames
  Plug 'vim-scripts/VisIncr'
endif
" Switch between source files and header files
Plug 'vim-scripts/a.vim'
" Enable repeating supported plugin maps with "."
Plug 'tpope/vim-repeat'

" -----------------------------------------------------------------------------
" Vim UI
" -----------------------------------------------------------------------------
" A light and configurable statusline/tabline for Vim
Plug 'itchyny/lightline.vim'
" Highlight the exact differences, based on characters and words
Plug 'rickhowe/diffchar.vim'
if !has('patch-8.1.1270') && !has('nvim-0.4.0')
  " vim-searchindex: display number of search matches & index of a current match
  Plug 'google/vim-searchindex'
endif
if has('patch-8.0.1206') || has('nvim-0.2.3')
  " Range, pattern and substitute preview for Vim
  Plug 'markonm/traces.vim'
elseif v:version >= 703
  " :substitute preview
  Plug 'osyo-manga/vim-over'
endif
" Simpler Rainbow Parentheses
Plug 'junegunn/rainbow_parentheses.vim', { 'for': [
      \ 'clojure',
      \ 'lisp',
      \ 'racket',
      \ 'scheme'] }
if has('patch-8.0.902') || has('nvim')
  " Show a diff using Vim its sign column.
  Plug 'mhinz/vim-signify'
elseif has('signs')
  " Show a git diff in the gutter and stages/reverts hunks
  Plug 'airblade/vim-gitgutter'
endif
" zoomwintab vim plugin
Plug 'troydm/zoomwintab.vim', { 'on': 'ZoomWinTabToggle' }
" Distraction-free writing in Vim
Plug 'junegunn/goyo.vim', { 'on': 'Goyo' }
" color hex codes and color names
Plug 'chrisbra/Colorizer'

" -----------------------------------------------------------------------------
" Support file types
" -----------------------------------------------------------------------------
" AdBlock
Plug 'yous/adblock-filter.vim', { 'for': 'adblockfilter' }
" Aheui
Plug 'yous/aheui.vim', { 'for': 'aheui' }
" GNU As
Plug 'Shirk/vim-gas', { 'for': 'gas' }
" LaTeX
Plug 'lervag/vimtex', { 'for': ['bib', 'tex'] }
" Markdown
Plug 'godlygeek/tabular', { 'for': 'markdown' } |
Plug 'preservim/vim-markdown', { 'for': 'markdown' }
" PHP
Plug 'vim-scripts/php.vim-html-enhanced', { 'for': ['html', 'php'] }
if v:version >= 700
  " ANSI escape sequences concealed, but highlighted as specified (conceal)
  Plug 'powerman/vim-plugin-AnsiEsc', { 'for': 'railslog' }
endif
" Rake
Plug 'tpope/vim-rake'
" RBS
Plug 'pocke/rbs.vim'
" reStructuredText
Plug 'habamax/vim-rst', { 'for': 'rst' }
" RuboCop
Plug 'ngmy/vim-rubocop', { 'on': 'RuboCop' }
" smali
Plug 'kelwin/vim-smali', { 'for': 'smali' }
" SMT-LIB
Plug 'raichoo/smt-vim', { 'for': 'smt' }
" Vader
Plug 'junegunn/vader.vim', { 'for': 'vader' }
" A solid language pack for Vim
let g:polyglot_disabled = [
      \ 'latex', 'markdown', 'rst',
      \ 'autoindent', 'sensible']
Plug 'sheerun/vim-polyglot'

" -----------------------------------------------------------------------------
" macOS
" -----------------------------------------------------------------------------
if has('mac') || has('macunix')
  " Add plist editing support to Vim
  Plug 'darfink/vim-plist'
endif

call plug#end()

VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Jun 18 2024 19:01:23)
macOS version - arm64
Included patches: 1-500
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl               +cmdline_hist      +ex_extra          +jumplist          +mouse_dec         +perl              +sodium            +textobjects       +wildmenu
+arabic            +cmdline_info      +extra_search      +keymap            -mouse_gpm         +persistent_undo   +sound             +textprop          +windows
+autocmd           +comments          -farsi             +lambda            -mouse_jsbterm     +popupwin          +spell             +timers            +writebackup
+autochdir         +conceal           +file_in_path      +langmap           +mouse_netterm     +postscript        +startuptime       +title             -X11
-autoservername    +cryptv            +find_in_path      +libcall           +mouse_sgr         +printer           +statusline        -toolbar           -xattr
-balloon_eval      +cscope            +float             +linebreak         -mouse_sysmouse    +profile           -sun_workshop      +user_commands     -xfontset
+balloon_eval_term +cursorbind        +folding           +lispindent        +mouse_urxvt       -python            +syntax            +vartabs           -xim
-browse            +cursorshape       -footer            +listcmds          +mouse_xterm       +python3           +tag_binary        +vertsplit         -xpm
++builtin_terms    +dialog_con        +fork()            +localmap          +multi_byte        +quickfix          -tag_old_static    +vim9script        -xsmp
+byte_offset       +diff              +gettext           +lua               +multi_lang        +reltime           -tag_any_white     +viminfo           -xterm_clipboard
+channel           +digraphs          -hangul_input      +menu              -mzscheme          +rightleft         -tcl               +virtualedit       -xterm_save
+cindent           -dnd               +iconv             +mksession         +netbeans_intg     +ruby              +termguicolors     +visual
-clientserver      -ebcdic            +insert_expand     +modify_fname      +num64             +scrollbind        +terminal          +visualextra
+clipboard         +emacs_tags        +ipv6              +mouse             +packages          +signs             +terminfo          +vreplace
+cmdline_compl     +eval              +job               -mouseshape        +path_extra        +smartindent       +termresponse      +wildignore
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
 3rd user vimrc file: "~/.config/vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/opt/homebrew/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X -DMACOS_X_DARWIN -g -O2 -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -o vim -lm -lncurses -lsodium -liconv -lintl -framework AppKit -L/opt/homebrew/opt/lua/lib -llua5.4 -mmacosx-version-min=14.2 -fstack-protector-strong -L/opt/homebrew
/opt/perl/lib/perl5/5.38/darwin-thread-multi-2level/CORE -lperl<EMAIL_ADDRESS>-lpython3
.12 -framework CoreFoundation -lruby.3.3 -L/opt/homebrew/Cellar/ruby/3.3.3/lib

Type:

[x] Bug
[ ] Enhancement
[ ] Feature Request
[ ] Question

OS:

[ ] All/Other
[ ] Linux
[x] macOS
[ ] Windows

Vim:

[x] Terminal Vim
[ ] GVim
[ ] Neovim

I think this is the minimal vimrc:
let g:plug_timeout = 10
let g:plug_retries = 0

filetype off

call plug#begin()

Plug 'https://localhost/fake/repo.git'

call plug#end()

Run nc -l 443 to raise SSL timeout, then try :PlugUpdate.

https://github.com/junegunn/vim-plug/blob/d863d0783236e1a46291f7791347740891186154/README.md?plain=1#L304-L305
Those variables are only used by the legacy Ruby/Python parallel installers. We don't enforce any timeouts when using the Vim 8+/Neovim installers.

I see, then is there a way to abort the ongoing :PlugUpdate, so I can retry unfinished entries with R?

The ongoing processes will be aborted when you close the plug window, but we don't have a way to retry only the aborted processes afterward. Never felt that I needed it. If I had to abort the update, I can then just re-run :PlugUpdate and it doesn't take long to do the whole thing again, so it doesn't bother me that much. Does this happen to you often?

I also didn't have issues for years, but I think something goes weird with my internet connection to GitHub nowadays. I've been experiencing timeouts repeatedly, getting more bothered.

Seeing #1093, maybe this is because of rate limiting as I have 60 plugins, and timeout occurs only when I'm on a shared network.


revise lock/pid file directory

Moving Epicon_Socket_init from /var/tmp to /var/run/lock is no problem
on Linux, but this makes problem on NetBSD/OpenBSD.
epicon cannot send binary file (with ~f command) under these OSes.
specifying VAR_LOCK, TTY_LOCK and Epicon_Socket_init is now resssembled with
VAR_PREFIX, TTY_LOCK and Epicon_Socket_init.
now TTY_LOCK and Epicon_Socket_init requires VAR_PREFIX.

I hope it can be used in a wider environment, so I commit.


Bugfix for /comment slash command which does nothing.

Description

the default behavior of /comment doesn't do anything unless the user adds additional prompt. It'll essentially perform the same as an /edit with no additional instruction.
edit.ts was ignoring the default input prompt from comment.ts

Checklist

[ ] Review code

Thanks for the fix! It passes my review, is that what the checklist item is for? If so I'll go ahead and merge

@sestinj yep, should be good to go!


Error: attempt to perform arithmetic on local 'win_size' (a nil value)

Hi
I'm receiving this error the first time the UI loads after opening Vim.
It happens once for each side panel layout, but not for the bottom layout.
It only occurs after I modified the config, if I just setup() with no custom config there is no error.
Here is my config:
{
    layouts = {
        {
            elements = {
                { id = 'scopes', size = 0.75 },
                { id = 'watches' },
        },
        size = 50,
        position = 'left'
    },
    {
       elements = {
           'breakpoints',
       },
       position = 'right',
       size = 20
    },
    {
        elements = {
            { id = 'repl' },
        },
           size = 0.25,
           position = 'bottom'
        }
   },
}

Here is the error:

After I dismiss the error everything appears to load and work perfectly fine.
Appreciate your help with this.

{ id = 'repl' },

{ id = 'watches' },

You have to specify a size field if using a table or just provide "repl" and "watches" directly to avoid the issue. Though if you're specifying a size for one element in a layout, all elements in that layout should have a size field to guarantee correct sizing.

Thanks, that solved the issue!


DatePickerInput crashed with initial value

Current behaviour
When you tap the icon to open the modal, the application crashes.
Expected behaviour
Open the modal to select the date.
How to reproduce?
export function DatePicker({ control, name, rules, style, ...rest }) {
  return (
    <Controller
      control={control}
      name={name}
      rules={rules}
      render={({ field: { onChange, value } }) => (
        <DatePickerInput
          locale={i18n.locale}
          label=""
          iconSize={16}
          inputMode="start"
          style={[styles.datePicker, style]}
          mode="outlined"
          dense
          withDateFormatInLabel={false}
          onChange={(d) => onChange(d)}
          value={value}
          {...rest}
        />
      )}
    />
  );
}

Preview

What have you tried so far?
If I do not pass the value property, the modal is displayed.
Your Environment

software
version

ios
17.2

react-native
0.74.1

react-native-paper
^5.12.3

expo sdk
^51.0.8

Working examples can be found in the docs. If you suspect this is still a bug feel free to open a PR!

Thanks for the reply, I finally realized that I was passing a dayjs object instead of Date as a value


ImportError: No module named 'pycocotools'

D:\software\Anaconda3\python.exe C:/Users/Link/Desktop/tf-faster-rcnn-master/train.py
Traceback (most recent call last):
File "C:/Users/Link/Desktop/tf-faster-rcnn-master/train.py", line 9, in
from lib.datasets.factory import get_imdb
File "C:\Users\Link\Desktop\tf-faster-rcnn-master\lib\datasets\factory.py", line 15, in
from lib.datasets.coco import coco
File "C:\Users\Link\Desktop\tf-faster-rcnn-master\lib\datasets\coco.py", line 21, in
from pycocotools.coco import COCO
ImportError: No module named 'pycocotools'

You need to compile pycocotools. I have added an instruction how to do it to readme. Please follow instructions and let me know if I missed something.

my error is same as the above, where the instruction of th pycocotools? thanks

https://github.com/dBeker/Faster-RCNN-TensorFlow-Python3/blob/master/README.md

https://github.com/dBeker/Faster-RCNN-TensorFlow-Python3/blob/master/README.md

I need to download pycocotools, and place it in the profiles.
I did not find the infomation of the pycocotools in this readme.md.
please paste the info on this. thank you very much

Step 4:

Go to ./data/coco/PythonAPI
Run python setup.py build_ext --inplace
Run python setup.py build_ext install
Go to ./lib/utils and run python setup.py build_ext --inplace


Viewer workload

This workload uses the action.VIEW intent. It will use the
most appropriate package for a given URI, e.g. Gmaps app for
a Gmaps location url. If the device doesn't have Google services,
it will open Gmaps in the browser, and so on.

Most comments should be addressed. I've modified the Workload class so that (subclasses of)+ Workload subclasses are also taken into account.
I've also added pre_viewing(), viewing() and post_viewing() methods to the Viewer class for better tweaking.
Once this is merged I will update gmaps/youtube to use it, and see if some simple workloads could be added (e.g. web page browsing).

Cleaned up things, added docstring, and moved the s/Viewer/ViewerWorkload/ class to utils/android. _check_availables() still sees ViewerWorkload as an available workload although it should be a purely abstract workload, so this might be one more thing to clean up.

@derkling Jankbench still works in a Notebook and in the command-line benchmarks, so I think I haven't broken anything Workload-related. Do you think you can have another look at this PR ? Thanks.


how to train fastreid on multi-class ?

how to train fastreid on multi-class ? It seems only one class support ReID.

I think you should try to ask this question at the FastReID repo, I didn't try this.
Some solutions that I think may work:

Train a network with one class by setting your dataset accordingly. Sort the dataset ID as follow: from 1 to N person, from N to N + M cars, and so on.
If you don't have many classes you can train network for each class.
In any case, pay attention that different classes may need different patch input shape (e.g. person 128x256, car 256x256).
Good luck!


TypeError: type is not a function

i have these entity -
import {Entity, field, rootCollection} from "firebase-firestorm/lib";

@rootCollection({
    name: 'Discounts'
})
export default class Discounts extends Entity {

    @field({name: 'name'})
    name!: string;

    @field({name: 'price'})
    price!: number;

    @field({name: 'type'})
    type!: string
}

@rootCollection({
    name: 'members'
})
export default class Member extends Entity {

    @field({name: 'fname'})
    fname!: string;

    @field({name: 'lname'})
    lname!: string;

    @field({name: 'email'})
    email!: string;

    @field({name: 'phone'})
    phone!: string;

    @field({name: 'dob'})
    dob!: Date;

    @field({name: 'address'})
    address!: string;

    @documentRef({name: 'plan', entity: MemberShipPlans})
    plan!: IDocumentRef<MemberShipPlans>;

    @field({name: 'end'})
    end!: Date;
}

@rootCollection({
    name: 'Memberships'
})
export default class MemberShipPlans extends Entity {

    @field({name: 'name'})
    name!: string;

    @field({name: 'price'})
    price!: number;

    @field({name: 'tenure'})
    tenrure!: number;

    @documentRef({name: 'discount', entity: Discounts})
    discount!:

Hi,
This is because the 'dob' and 'end' fields are Date's. Unfortunately, Date's are not currently supported if you're using the @field decorator. As they are supported in with the standard firestore sdk, they should also be supported in firestorm, so I'll find a fix.
Right now, you can use the @timestamp decorator, which will uses firestore's Timestamp class.

thanks worked

Hi  i'm having this issue too but your solution didn't work for me...
Here is my entity:
import { rootCollection, field, timestamp, Entity, ITimestamp } from 'firebase-firestorm/lib';

@rootCollection({
    name: 'users'
})
export default class User extends Entity {
    @timestamp({
        name: 'created_at',
        updateOnCreate: true
    })
    public createdAt!: ITimestamp;

    @timestamp({
        name: 'modified_at',
        updateOnUpdate: true
    })
    public modifiedAt!: ITimestamp;

    @field({ name: 'nom' })
    name!: string;

    @field({ name: 'prenom' })
    firstname!: string;

    @field({ name: 'email' })
    email!: string;

    @field({ name: 'username' })
    username!: string;
}

PB: I'm using firestorm 2.0.5

A bit late but had a similar Issue, a fix was to check the Compiler Options
{
  "compilerOptions": {
    "target": "ES5",
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
  }
}


Rename the relevant forest server route and response keys to 'lattice…

Completes the rename to "lattice" everywhere

lgtm!


Export types via root export

When using this package I quickly found myself wanting to use the ObjectToCamel type (and friends) to type my functions, and while they can be imported as
import type { ObjectToCamel } from 'ts-case-convert/lib/caseConvert'
I'd feel more secure relying on them if they were exported as part of the public api, i.e.
import type { ObjectToCamel } from 'ts-case-convert'
Are you open to making the types importable like that? If so, I can prepare a PR 👍

+1 I'd very much like this as well.


Fix some typos

Description
Noticed the heading below says Changsets instead of Changesets so used a proofreading plugin to find some typos
Changsets
We use Changesets to automatically create our changelog per each release. Any changes or additions to the Library assets in /lib must be documented with a new Changeset. This can be done as follows:

Navigate to the root of the project on your feature branch.
Run pnpm changeset to trigger the Changeset CLI.
Follow the instructions when prompted.

Changesets should be either minor or patch. Never major.
Prefix your Changeset description using: feature:, chore: or bugfix:.

Changeset .md files are added to the /.changeset directory.
Commit and push the the new changeset file.

Checklist
Please read and apply all contribution requirements.

[x] PR targets the dev branch (NEVER master)
[x] All website documentation is current with your changes
[x] Ensure Prettier formatting is current - run pnpm format
[x] Ensure Prettier linting is current - run pnpm format
[x] All test cases are passing - run pnpm test
[ ] Includes a changeset (if relevant; see above)

@Hugos68 @jaakkonakaza I've given my approval, but looks like a minor merge conflict will need to be resolved here.

I've resolved the conflict, I'll merge once CI passes👍


Wishlist won't start SSH Server unless root

When I start soft-serve, it happily starts its SSH server. When I start wishlist as shown below, it fails and throws a permission error:
$ wishlist serve
2022/07/30 13:01:14 Using config from .wishlist/config.yaml
2022/07/30 13:01:14 Starting SSH server for list on ssh://<IP_ADDRESS>:23
Error: listen tcp <IP_ADDRESS>:23: bind: permission denied
2022/07/30 13:01:14 listen tcp <IP_ADDRESS>:23: bind: permission denied

Wishlist seems to only work when elevated.

Ahh okay. Cheers @caarlos0