profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/woshilapin/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

woshilapin/dot 1

All "dot" files for the configuration of the system

woshilapin/mytexlive 1

Personal packages for LaTeX

woshilapin/advent-calendar 0

https://adventofcode.com/

woshilapin/api-xff 0

Propose a filter for XFS file format

woshilapin/application-project 0

Project Management Application

woshilapin/bill 0

Application to share the bill between your friends

woshilapin/cargo-tomlfmt 0

Formatting Cargo.toml

woshilapin/centaurus 0

The relativist ray-tracer

woshilapin/cg-accountant-game 0

A program that simulate "The Accountant" problem of Codingame

push eventCanalTP/skip_error

Jean SIMARD

commit sha e389f118e51ca9f6fd8d35904283d2751d417ad9

[feature] add shortcuts to the iterator methods

view details

push time in a day

pull request commentCanalTP/skip_error

[feature] add shortcuts to the iterator methods

I've reworked the PR to factorize the code into a macro.

woshilapin

comment created time in 2 days

push eventCanalTP/skip_error

Jean SIMARD

commit sha 6106b45c525d89e2b4e7f9682b0e95b4c13a9d65

[feature] add shortcuts to the iterator methods

view details

push time in 2 days

push eventCanalTP/skip_error

Jean SIMARD

commit sha 57f0b89e70a95286dbc9e26b42f3f9e4defaf3fc

[feature] add shortcuts to the iterator methods

view details

push time in 2 days

delete branch CanalTP/transit_model

delete branch : no-incremental-ci

delete time in 2 days

PR closed CanalTP/transit_model

[tech] remove incremental build for CI

Current builds are hardly going under 10mn (for PR on CI, I'm not talking about releases). In CI, we don't really need the compiler to generate incremental metadata to be able to compile faster on next run so how about dseems teactivating it? I'm opening this PR in draft so we can check if this does make a difference.

I'm not innovating here, I'm just borrowing some ideas from rust-analyzer. It's only one of a few ideas exposed in matklad article.

+3 -0

1 comment

1 changed file

woshilapin

pr closed time in 2 days

pull request commentCanalTP/transit_model

[tech] remove incremental build for CI

This test doesn't seem to bring significant improvements (it's actually even showing worse build times). It might be because we do use incremental by building the library then the tests in multiple steps. Anyway, I'm closing this PR for now.

woshilapin

comment created time in 2 days

push eventwoshilapin/dot

Jean SIMARD

commit sha 72321d780baac371b09e2b0ded3af23c1c2a424a

[zsh] improve configuration of 'exa'

view details

Jean SIMARD

commit sha 0acbfc107ba97553183dcf1b2a9a6fac593adf87

[zsh] update 'oh-my-zsh' plugin

view details

Jean SIMARD

commit sha f80054cda9eec84e3bfc8df4b3915d7341da99e5

[zsh] add 'zoxide' initialisation

view details

push time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentCanalTP/transit_model

[feature] Don't export dummy stop time

 pub struct Collections { }  impl Collections {+    /// Remove associated schedules with route points+    pub fn remove_route_points(&mut self) {+        let vj_idxs: Vec<Idx<VehicleJourney>> =+            self.vehicle_journeys.iter().map(|(idx, _)| idx).collect();+        let is_point_of_route = |stop_time: &StopTime| -> bool {

If the function above is named remove_route_points, this closure can probably be named is_route_point :wink:

patochectp

comment created time in 5 days

Pull request review commentCanalTP/transit_model

[feature] Don't export dummy stop time

 struct Route {     sort_order: Option<u32>, } -fn remove_stop_zones(model: Model) -> Collections {-    let mut collections = model.into_collections();-    collections-        .stop_points-        .retain(|sp| sp.stop_type != StopType::Zone);--    let stop_point_ids: Vec<Idx<StopPoint>> = collections-        .stop_points-        .get_id_to_idx()-        .values()-        .copied()-        .collect();--    collections.vehicle_journeys.retain(|vj| {-        vj.stop_times-            .iter()-            .all(|st| stop_point_ids.contains(&st.stop_point_idx))-    });--    collections-}- /// Exports a `Model` to [GTFS](https://gtfs.org/reference/static) files /// in the given directory. /// see [NTFS to GTFS conversion](https://github.com/CanalTP/transit_model/blob/master/src/documentation/ntfs2gtfs.md) pub fn write<P: AsRef<Path>>(model: Model, path: P) -> Result<()> {-    let collections = remove_stop_zones(model);

OK, so we discussed it together and the conclusion is: yes, it is true that if we ever have another binary that is writing GTFS, we need to not forget to add a call remove_stop_zones(). However:

  • it is still very unlikely we have to create a new binary that write GTFS (we usually convert to or from NTFS)
  • even in the case of such a binary, it is very unlikely that we will end up with pickup_type and/or drop_off_type with a value of 3
  • this PR probably improved performance by an order of magnitude by avoiding transforming a Model back to a Collections, then back again to a Model (which is the main reason why the call to remove_stop_zones() has been moved in the first place).

Therefore, we're ok to lose a bit of a "maybe more logical" place to call remove_stop_zones() in the profit of performance.

patochectp

comment created time in 5 days

Pull request review commentCanalTP/transit_model

[feature] Don't export dummy stop time

 							<ForAlighting>true</ForAlighting> 							<ForBoarding>true</ForBoarding> 						</StopPointInJourneyPattern>-						<StopPointInJourneyPattern id="FR:StopPointInJourneyPattern:M1F1_2:" order="3" version="any">-							<ScheduledStopPointRef ref="FR:ScheduledStopPoint:M1F1_2:">+						<StopPointInJourneyPattern id="FR:StopPointInJourneyPattern:M1F1_3:" order="4" version="any">

Interesting (and kind of funny too), if we had chosen to make the filtering of route points at the reading of NTFS (instead of at the writing of NeTEx France), then order would not have been modified... This almost means that we're revealing an implementation detail here... But I believe it's fine!

patochectp

comment created time in 5 days

Pull request review commentCanalTP/transit_model

[feature] Don't export dummy stop time

 struct Route {     sort_order: Option<u32>, } -fn remove_stop_zones(model: Model) -> Collections {-    let mut collections = model.into_collections();-    collections-        .stop_points-        .retain(|sp| sp.stop_type != StopType::Zone);--    let stop_point_ids: Vec<Idx<StopPoint>> = collections-        .stop_points-        .get_id_to_idx()-        .values()-        .copied()-        .collect();--    collections.vehicle_journeys.retain(|vj| {-        vj.stop_times-            .iter()-            .all(|st| stop_point_ids.contains(&st.stop_point_idx))-    });--    collections-}- /// Exports a `Model` to [GTFS](https://gtfs.org/reference/static) files /// in the given directory. /// see [NTFS to GTFS conversion](https://github.com/CanalTP/transit_model/blob/master/src/documentation/ntfs2gtfs.md) pub fn write<P: AsRef<Path>>(model: Model, path: P) -> Result<()> {-    let collections = remove_stop_zones(model);

I think I understand why you did move this line directly to the connector, but it seems it would be better to keep it here, so anything that is writing GTFS will be impacted. With your solution, we would need to think about adding a call to remove_stop_zones on every new binary producing some GTFS.

patochectp

comment created time in 5 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentCanalTP/transit_model

[feature] remove dummy stop times

 mod tests {             assert_eq!(3, stop_time.pickup_type);             assert_eq!(3, stop_time.drop_off_type);         }++        #[test]+        fn remove_pickup_drop_off_type_3() {+            let model = transit_model_builder::ModelBuilder::default()+                .vj("vj1", |vj| {+                    vj.st_mut("SP1", "10:00:00", "10:01:00", |st| {+                        st.pickup_type = 0;+                        st.drop_off_type = 1;+                    })+                    .st_mut("SP2", "11:00:00", "11:01:00", |st| {+                        st.pickup_type = 3;+                        st.drop_off_type = 2;+                    })+                    .st_mut("SP3", "12:00:00", "12:01:00", |st| {+                        st.pickup_type = 3;+                        st.drop_off_type = 2;+                    })+                    .st_mut("SP4", "13:00:00", "13:01:00", |st| {+                        st.pickup_type = 1;+                        st.drop_off_type = 0;+                    });+                })+                .build();++            let mut collections = model.into_collections();+            collections.remove_points_of_route();+            let vj = collections+                .vehicle_journeys+                .get("vj1")+                .expect("Failed to find vehicle journey vj1");

minor: we actually don't expect to "Failed to find vehicle journey vj1", we actually expect to find it (but all the other tests are doing the same weirdness, so I'm fine if this is not fixed here).

patochectp

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentCanalTP/transit_model

[feature] remove dummy stop times

 DEFR,RERAB1,5,09:24:00,09:25:00,0,0,0,1,1,,,,2 CDGR,RERAB1,8,09:39:00,09:40:00,0,0,0,0,0,,,,0 GDLR,RERAB1,13,09:44:00,09:45:00,0,0,0,0,0,,,,0 NATR,RERAB1,21,09:49:00,09:50:00,0,0,0,0,0,,,,0-MTPZ,RERAB1,50,19:24:00,19:25:00,0,0,0,0,1,,,,2+MTPZ,RERAB1,50,19:24:00,19:25:00,0,0,0,0,0,,,,0

I'm not sure that I understand why this is changing?

patochectp

comment created time in 6 days

Pull request review commentCanalTP/transit_model

[feature] remove dummy stop times

 pub struct Collections { }  impl Collections {+    /// Remove associated schedules with points of route+    pub fn remove_points_of_route(&mut self) {+        let vj_idxs: Vec<Idx<VehicleJourney>> =+            self.vehicle_journeys.iter().map(|(idx, _)| idx).collect();+        for vj_idx in vj_idxs {+            let mut vj = self.vehicle_journeys.index_mut(vj_idx);++            let is_point_of_route = |stop_time: &mut StopTime| -> bool {+                stop_time.pickup_type == 3 || stop_time.drop_off_type == 3+            };
  1. This function can be declared outside of the for loop (and might be named is_route_point if you change the other one too).
  2. I don't think this closure needs a mutable reference, since it's only about reading information. A simple reference is probably enough.
patochectp

comment created time in 6 days

Pull request review commentCanalTP/transit_model

[feature] remove dummy stop times

 pub struct Collections { }  impl Collections {+    /// Remove associated schedules with points of route+    pub fn remove_points_of_route(&mut self) {+        let vj_idxs: Vec<Idx<VehicleJourney>> =+            self.vehicle_journeys.iter().map(|(idx, _)| idx).collect();+        for vj_idx in vj_idxs {+            let mut vj = self.vehicle_journeys.index_mut(vj_idx);++            let is_point_of_route = |stop_time: &mut StopTime| -> bool {+                stop_time.pickup_type == 3 || stop_time.drop_off_type == 3+            };+            let mut stop_time_idx = 0;+            while stop_time_idx < vj.stop_times.len() {+                if is_point_of_route(&mut vj.stop_times[stop_time_idx]) {+                    vj.stop_times.remove(stop_time_idx);+                } else {+                    stop_time_idx += 1+                }+            }

You might be able to use something like .retain() here instead of the entire while loop.

vj.stop_times.retain(|stop_time| !is_point_of_route(stop_time));
patochectp

comment created time in 6 days

Pull request review commentCanalTP/transit_model

[feature] remove dummy stop times

 pub struct Collections { }  impl Collections {+    /// Remove associated schedules with points of route+    pub fn remove_points_of_route(&mut self) {

How about remove_route_points()?

patochectp

comment created time in 6 days

PullRequestReviewEvent

PR opened CanalTP/transit_model

[tech] remove incremental build for CI

Current builds are hardly going under 10mn (for PR in CI, I'm not talking about releases). In CI, we don't really need the compiler to generate incremental metadata to be able to compile faster on next run so how about deactivating it? I'm not innovating here, I'm just borrowing some ideas from rust-analyzer. It's only one of a few ideas exposed in matklad article.

+3 -0

0 comment

1 changed file

pr created time in 6 days

create barnchCanalTP/transit_model

branch : no-incremental-ci

created branch time in 6 days

PR opened alexislozano/website

Typo in article 4 on hexagonal
+2 -2

0 comment

1 changed file

pr created time in 6 days

push eventwoshilapin/website

Jean SIMARD

commit sha cae2d3987a7c0eeaea21410c91a8e9112b7c1a83

Typo in article 4 on hexagonal

view details

push time in 6 days

PR opened alexislozano/website

Typo in article 3 on hexagonal
+2 -2

0 comment

1 changed file

pr created time in 6 days

push eventwoshilapin/website

Jean SIMARD

commit sha b4ad3d18995b21df0dfc91e5c9b5bb8fa1389b7c

Typo in article 3 on hexagonal

view details

push time in 6 days