From f0f838c13f4a552dca7b5dbaca066a382c1145f8 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 14 Nov 2021 12:15:17 +0700 Subject: Update Franklin --- blog/2020/gsoc/article/1.md | 2 +- blog/2020/gsoc/article/3.md | 4 ++-- blog/2020/gsoc/article/4.md | 6 +++--- blog/2020/gsoc/article/5.md | 2 +- blog/2020/gsoc/article/7.md | 4 ++-- 5 files changed, 9 insertions(+), 9 deletions(-) (limited to 'blog/2020/gsoc/article') diff --git a/blog/2020/gsoc/article/1.md b/blog/2020/gsoc/article/1.md index b0e6a7b..b98e2d5 100644 --- a/blog/2020/gsoc/article/1.md +++ b/blog/2020/gsoc/article/1.md @@ -69,7 +69,7 @@ the resolution of dependency. While this is only applicable to wheels (i.e. prebuilt packages), other packaging format only make up less than 20% of the downloads (at least on PyPI), and the figure is much less for the most popular packages. Therefore, this optimization alone could make -[the upcoming backtracking resolver][]'s performance par with the legacy one. +[the upcoming backtracking resolver]'s performance par with the legacy one. During the last few years, there has been a lot of effort being poured into replacing `pip`'s current resolver that is unable to resolve conflicts. diff --git a/blog/2020/gsoc/article/3.md b/blog/2020/gsoc/article/3.md index 9c41b31..175486c 100644 --- a/blog/2020/gsoc/article/3.md +++ b/blog/2020/gsoc/article/3.md @@ -15,8 +15,8 @@ and group projects left to be done. I for sure underestimated the workload of these and in the last (and probably next) few days I'm drowning in work trying to meet my deadlines. -One project that might be remotely relevant is [cheese-shop][], which tries to -manage the metadata of packages from the real [Cheese Shop][]. Other than that, +One project that might be remotely relevant is [cheese-shop], which tries to +manage the metadata of packages from the real [Cheese Shop]. Other than that, schoolwork is draining a lot of my time and I can't remember the last time I came up with something new for my GSoC project )-; diff --git a/blog/2020/gsoc/article/4.md b/blog/2020/gsoc/article/4.md index 43738a7..5a1cf50 100644 --- a/blog/2020/gsoc/article/4.md +++ b/blog/2020/gsoc/article/4.md @@ -30,7 +30,7 @@ and rebased, but my `git` skill is far from gud enuff to confidently do it. Testing this one has been a lot of fun though. At first, integration tests were added as a rerun of the tests for the new resolver, with an additional flag -to use feature `fast-deps`. It indeed made me feel guilty towards [Travis][], +to use feature `fast-deps`. It indeed made me feel guilty towards [Travis], who has to work around 30 minutes more every run. Per Chris Hunt's suggestion, in the new PR, I instead write a few functional tests for the area relating the most to the feature, namely `pip`'s subcommands `wheel`, @@ -45,7 +45,7 @@ Why did I say I'm half way there? With the parallel utilities merged and a way to quickly get the list of distribution to be downloaded being really close, what left is *only* to figure out a way to properly download them in parallel. With no distribution to be added during the download progress, the model of this -will fit very well with the architecture in [my original proposal][]. +will fit very well with the architecture in [my original proposal]. A batch downloader can be implemented to track the progress of each download and thus report them cleanly as e.g. progress bar or percentage. This is the part I am second-most excited about of my GSoC project this summer @@ -71,7 +71,7 @@ the upcoming Pinephone prototype. It's one of the first smartphones to fully support a GNU/Linux distribution, where one can run desktop apps (including proper terminals) as well as traditional services like SSH, HTTP server and IPFS node because why not? Just a few hours ago, -I pre-ordered the [postmarketOS community edition][] with additional hardware +I pre-ordered the [postmarketOS community edition] with additional hardware for convergence. If you did not come here for a Pinephone ad, please take my apologies though d-; diff --git a/blog/2020/gsoc/article/5.md b/blog/2020/gsoc/article/5.md index de2ef8d..5404089 100644 --- a/blog/2020/gsoc/article/5.md +++ b/blog/2020/gsoc/article/5.md @@ -15,7 +15,7 @@ Last Wednesday, `pip` 20.2 was released, delivering the `2020-resolver` as well as many other improvements! I was lucky to be able to get the `fast-deps` feature to be included as part of the release. A brief description of this *experimental* feature as well as testing -instruction can be found on [Python Discuss][]. +instruction can be found on [Python Discuss]. The public exposure of the feature also remind me of some further {{pip 8681 optimization}} to make on {{pip 8670 "the lazy wheel"}}. diff --git a/blog/2020/gsoc/article/7.md b/blog/2020/gsoc/article/7.md index 58d8d33..c574865 100644 --- a/blog/2020/gsoc/article/7.md +++ b/blog/2020/gsoc/article/7.md @@ -41,7 +41,7 @@ $ pip --use-feature=2020-resolver --use-feature=fast-deps \ --no-cache-dir download {requirement} # fast-deps ``` -In the first test, I used [axuy][] and obtained the following results +In the first test, I used [axuy] and obtained the following results | legacy-resolver | 2020-resolver | fast-deps | | --------------- | ------------- | --------- | @@ -71,7 +71,7 @@ which are apparently more expensive than actual data transmission on my network. ### Large Distribution -In this test, I used [TensorFlow][] as the requirement and obtained +In this test, I used [TensorFlow] as the requirement and obtained the following figures: | legacy-resolver | 2020-resolver | fast-deps | -- cgit 1.4.1