WEBVTT 00:00.270 --> 00:05.410 Welcome in this lecture, I'm going to show you how to solve the mascot challenge. 00:05.730 --> 00:06.940 All right, let's get started. 00:08.110 --> 00:09.590 OK, here are the goals. 00:10.090 --> 00:16.090 Let's start with the first goal, OK, then let's check whether there is a user input or not. 00:17.450 --> 00:20.210 If not so, then let's print the message and return. 00:21.310 --> 00:26.800 OK, now let's check out the second go create a buffer and use it as the output. 00:27.430 --> 00:30.820 OK, I'm going to use the input and its length in the following code. 00:31.390 --> 00:37.090 So let the save the input to a variable first, then I'm going to save its length to the size variable. 00:37.840 --> 00:39.670 OK, now I can create the buffer. 00:39.950 --> 00:45.070 Let me make a less with zero length and with a capacity of the size variable Lexar. 00:45.980 --> 00:51.170 OK, let's check out the next go right inputs to the buffer as it is and print it. 00:51.960 --> 00:58.760 OK, I want to analyze the input, bite by bite in a loop like so this way I can direct links inside 00:58.760 --> 00:59.360 the text. 00:59.900 --> 01:01.730 You will see how it works in a minute. 01:02.300 --> 01:02.830 All right. 01:02.960 --> 01:06.180 Now, let me append a bit of the input to the buffer. 01:06.410 --> 01:06.740 So. 01:09.310 --> 01:15.750 And lastly, I'm going to print the buffer to the console like this, remember, Buff is a bit slow, 01:15.810 --> 01:18.880 so that's why I need to convert it to a street value here. 01:22.310 --> 01:22.610 Good. 01:22.790 --> 01:29.600 Now it just prints the input, not that the program prints this output using our buffer, so why we 01:29.600 --> 01:33.300 have created a buffer and then appended bytes to it? 01:33.620 --> 01:35.530 Why didn't I use a string instead? 01:36.170 --> 01:38.510 For example, I can create a string buffer here. 01:39.730 --> 01:46.300 Then I can add the next bite into it like so here is the first reason why I didn't use a street buffer 01:46.810 --> 01:49.130 here, I need the convertible to a string. 01:49.480 --> 01:51.700 However, this is not a very big issue. 01:51.890 --> 01:56.550 It's because for a small number of whites go optimises this behind the scenes. 01:57.130 --> 02:03.070 The main reason why I didn't use a street buffer is that whenever I add a new string to the string buffer, 02:03.070 --> 02:04.830 Gore creates a new string here. 02:05.320 --> 02:07.350 This because string values are immutable. 02:07.540 --> 02:09.060 I mean, you cannot change that. 02:09.190 --> 02:11.230 You can only create a new string value. 02:11.680 --> 02:17.800 However, with a buffer, I allocate it only once and I can change the elements of the same bytes. 02:18.220 --> 02:24.160 So here, if I had used a string buffer instead, it would OK the new string value as much as the number 02:24.160 --> 02:25.930 of what's inside of the input string. 02:26.410 --> 02:27.910 OK, let me take this back. 02:28.420 --> 02:30.490 OK, now let's check out the next goal. 02:31.570 --> 02:36.830 OK, to detect the link, I need the search for HTP pattern inside the input. 02:36.880 --> 02:41.350 This pattern won't change, so let's create a constant to represent it. 02:42.550 --> 02:46.160 Let's also create another constant for the length of the link pattern. 02:46.540 --> 02:49.600 I'll use it in a second inside the loop. 02:50.110 --> 02:52.590 I'm going to search for the link pattern here. 02:52.600 --> 02:56.110 I'm slicing the input text to seven bytes chunks at a time. 02:56.570 --> 03:00.880 That's because I'm searching for HDP and its length is seven bytes. 03:02.600 --> 03:09.500 As you can see, it moves or the input looking for the link pattern here, there is a link pattern so 03:09.500 --> 03:12.340 I can tell that a link starts from here. 03:12.380 --> 03:12.790 Right. 03:13.190 --> 03:19.040 But before doing that, let's find out why there is this error to understand what's going on. 03:19.070 --> 03:21.320 First, let's bring the length of the text. 03:24.250 --> 03:27.850 Then I'm going to dump the Cilliers expression to the console like this. 03:31.040 --> 03:32.240 OK, let's try it. 03:33.620 --> 03:40.700 As you can see, the input text length is for, however, on the last line here, twenty eight plus 03:40.700 --> 03:42.390 seven equals to thirty five. 03:43.160 --> 03:45.980 So it tries to slice the input beyond its length. 03:46.520 --> 03:47.920 That is the cause of the error. 03:48.770 --> 03:55.520 So it is clear that I should not slice the text beyond is lacked to clue that I can check whether the 03:55.520 --> 04:00.620 remaining part of the text is greater than or equal to the length of the linked pattern. 04:00.960 --> 04:03.080 So let me also remove this one. 04:03.680 --> 04:05.090 OK, let's try it. 04:06.700 --> 04:13.910 Cool, now it works without any errors, but do you really understand how this works here? 04:13.960 --> 04:19.780 I get the remaining part of the text, then I check whether there is more room for a link or not. 04:20.170 --> 04:22.980 Only then I continue slicing the input. 04:23.440 --> 04:27.490 So this ensures that I never slice the input beyond its capacity. 04:27.790 --> 04:30.250 Now I can check for a link like so. 04:32.220 --> 04:35.960 Here I compare whether it equals to the link pattern or not. 04:38.090 --> 04:42.470 Cool, it has returned on the part of the input that contains the link. 04:42.770 --> 04:45.500 So now I know the starting position of the link. 04:45.650 --> 04:51.600 It's between 12 and 19 to position cool limos to remove these ones. 04:51.920 --> 04:53.120 I don't need them anymore. 04:53.200 --> 04:54.500 OK, all right. 04:54.710 --> 04:55.790 Let's take a break now. 04:56.180 --> 04:56.780 No worries. 04:56.780 --> 05:01.160 I'm going to continue this project in the next lecture, but I'm going to have coffee first. 05:02.060 --> 05:03.350 See, in the next lecture by.