DEV Community: Traky Richard

Debugging code in C language with a Makefile on MAC

Traky Richard — Tue, 01 Nov 2022 13:38:04 +0000

Debugging its code remains a fundamental step in solving bugs. Some programs seem less bulky in terms of a line of code and don't really require the need for debugging. On the other hand, others contain several hundred lines of code, and it becomes almost impossible to fix bugs without debugging.

In this tutorial I will explain how to debug in C with a configured makefile.

The debugging option is by default integrated in visual studio,
In C to debug we need to install an extension that you will find on this link.

Once the extension is installed it is now time to start the configuration.

Create a .vscode folder
In this folder create a launch.json file in which you will put the code below

{
    “version”: “0.2.0”,
    “configurations”: [
        {
            “name”: “C/C++: clang++ build and debug active file”,
            “type”: “cppdbg”,
            “request”: “launch”,
            “program”: “${workspaceFolder}/[execName]”,
            “args”: [arg1, arg2],
            “stopAtEntry”: true,
            “cwd”: “${workspaceFolder}“,
            “environment”: [],
            “externalConsole”: false,
            “MIMode”: “lldb”,
            “preLaunchTask”: “make re”
        }
    ]
}

In summary, this config allows us to set up our debugger by giving it a name, the program to run, the arguments to pass etc...
The most important things to notice and modify are the name of your program and the various arguments you pass when running your program.

NB: The list of arguments must be in comma separated strings.

Only one last step
Have you noticed that the last line of our launch.json file contains an attribute “preLaunchTask”: “make re”, this line will be useful in the step below.

Let's create another tasks.json file in the same .vscode folder located at the root of your project, in this folder we will define some tasks to execute before launching our debugger.
A simplified version of this file should look like this.

{
    “version”: “2.0.0”,
    task:
    [
        {
            “label”: “make re”,
            “type”: “shell”,
            “command”: “make”,
            “args”: [“re”]
        }
    ]
}

NB: The label and the preLaunchTask must be identical to create the link.

To summarize this config allows us to launch our command make followed by an argument re which means "rebuild" so that the new instance of debugger contains the latest changes.

NB: For breakpoints to work you must include the #-g# attribute among the compilation flags of your project, for example: >gcc -g -wall -wextra etc...
otherwise all the work done so far will be in vain.

We're all good, all you have to do is click on the third tab on the left of your editor to launch your debugger.

Happy coding to you, and see you next week for a new article.

TimSort Algorithm in C with doubly Linked List

Traky Richard — Tue, 11 Oct 2022 08:21:56 +0000

Have you already chosen a sorting #algorithm?

I admit that the exercise is not one of the least, the sorting algorithms, there are dozens of them and everyone has their say.

Having almost all studied, one of the choices that I retain is the algo of #TimSort.

Timsort is an efficient sorting algorithm for real-world data. Created by Tim Peters and adopted in 2001 as the default sorting algo in the #Python programming language. Timsort first analyzes the list it is trying to sort, then chooses an approach based on the analysis performed.

The initial array is divided into sub-arrays called #RUN on which insertion sort is applied (insertion sort); and then merge sort on each of its RUNs to return to the initial array.

NB: The value of RUN may vary depending on the size of the initial array.

This algo allows you to have an order #complexity of O(n log n) in a worse case and a complexity of O(n) in a best case.

An implementation in C using the double linked lists that I made of this algo can be found in the Link

Your feedback is welcome in the comments.

Comprendre certaines notions des Hooks UseEffect UseCallBack et useMemo.

Traky Richard — Mon, 25 Oct 2021 19:39:01 +0000

Cela fait 2 ans j'utilise #React dans mes projets, l'utilisation de ces Hooks deviennent compliqués à comprendre dans certains cas d'utilisations(comme par exemple sur un projet plus ambitieux). Dans cet article je vais vous présenter certains erreurs qu'une mauvaise utilisation de ces hooks peut vous causer et ensuite nous verrons les bonnes pratiques pour y échapper.

1. Construire vos functions avec un seul UseEffect

Imaginons que vous ayez un composant fonctionnel de post d'article comme celui-ci

    const [comments, setComments] =
    useState<QueryDocumentSnapshot<DocumentData>[]>();
  const [likes, setLikes] = useState<QueryDocumentSnapshot<DocumentData>[]>();
  const [posts, setPosts] = useState<QueryDocumentSnapshot<DocumentData>[]>();
  const [user, setUser] = useState<DocumentSnapshot<DocumentData>>();
  const [hasLiked, setHasLiked] = useState(false);

// query to get all comments
  const getAllComments = () =>
    onSnapshot(
      query(collection(firestore, `posts/${postId}/comments`)),
      (snapshot) => setComments(snapshot.docs)
    );
    const getCurrentUser = async () => {
    // query to get current user informations
    const currentUser = await getDoc(doc(firestore, "users", userId));
    setUser(currentUser);
  };
  const getAllLikes = () => {
    // query to get all likes
    onSnapshot(
      query(collection(firestore, `posts/${postId}/likes`)),
      (snapshot) => setLikes(snapshot.docs)
    );
  };

// user like or not the current post
  const setUserHasLiked = () => {
    likes &&
      setHasLiked(
        likes.findIndex((like) => like.id === user?.data()?.uid) !== -1
      );
  };
  useEffect(() => {
    getCurrentUser();
    getAllComments();
    getAllLikes();
    setUserHasLiked();
  }, [firestore, postId, likes]);

Dans ce composant fonctionnel les 4 fonctions contenus dans le useEffect s'exécuteront à chaque fois que la valeur d'une des dépendances changera. cela ne vous causera pas d'erreur mais en terme de complexité cela peut s'avérer difficile à comprendre et vous ferai des appels inutile à chaque changement de dépendance (comme par exemple recharger l'utilisateur actuel lorsque le nombre de likes change ) alors que vous pourriez éviter cela en faisant ça.

 const [comments, setComments] = useState<any[]>([]);
  const [likes, setLikes] = useState<any[]>([]);
  const [hasLiked, setHasLiked] = useState(false);

  useEffect(() => {
    getCurrentUser();
  }, []);

  const getCurrentUser = async () => {
    // query to get current user informations
    const currentUser = await getDoc(doc(firestore, "users", userId));
    setUser(currentUser);
  };

// get post comments
  useEffect(
    () =>
      onSnapshot(
        query(
          collection(firestore, `posts/${postId}/comments`),
          orderBy("timestamp", "desc")
        ),
        (snapshot) => setComments(snapshot.docs)
      ),
    [firestore, id]
  );

  useEffect(
    () =>
      onSnapshot(
        query(collection(firestore, `posts/${postId}/likes`)),
        (snapshot) => setLikes(snapshot.docs)
      ),
    [firestore, id]
  );

  useEffect(
    () =>
      setHasLiked(
        likes.findIndex((like) => like.id === (session as any)?.user?.uid) !==
          -1
      ),
    [likes]
  );

L'utilisation de plusieurs useEffect dans un composant react vous permet de séparer vos besoins et vos préoccupations, cela rends votre code plus lisible et peut dans certains cas vous économiser des appels en base.

2. useCallback et UseMemo

intéressons nous à ce composant fonctionnel

import React from "react";
export default function DisplayDays() {
  const weekDays = [
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thrusday",
    "Friday",
    "Saturday",
    "Sunday",
  ];
  const [days, setDays] = React.useState(weekDays);
  const filterDays = (dayToFilter: string) => {
    setDays((weekDays) => weekDays.filter((day) => day !== dayToFilter));
  };
  return (
    <div>
      <h1>Display WeekDay</h1>
      <div>
        <div>WeekDays</div>
        {days.length === 0 ? (
          <button onClick={() => setDays(weekDays)}>recharge Days</button>
        ) : (
          <ul>
            {days.map((day) => (
              <li key={day}>
                {day} <button onClick={() => filterDays(day)}>remove</button>
              </li>
            ))}
          </ul>
        )}
      </div>
    </div>
  );
}

Ce composant permet d'afficher les différents jours de la semaine et nous pouvons les supprimer successivement en cliquant sur le jour sélectionné.
faisons une comparaison des 2 fonctions suivante ?

  const filterDays = (dayToFilter: string) => {
    setDays((weekDays) => weekDays.filter((day) => day !== dayToFilter));
  };

  const filterDaysCallBack = useCallback(filterDays, []);

En vrai elles font la même chose mais parmi elle figure une qui est plus optimisé pour notre besoin précis.
Dans cet exemple la fonction useCallBack ne nous sera d'aucune utilité, au contraire elle peut être la cause des problèmes de performance de notre application je vous explique pourquoi:

La fonction filterDays n'a aucune utilité d'être stocker en mémoire vu qu'elle filtre la donnée sélectionné et ne l'affiche plus dans notre tableau de jours.
Non seulement nous devons définir la fonction dans une variable, mais nous devons également définir un tableau ( []) et appeler le React.useCallback qui lui-même définit les propriétés et exécute des expressions logiques, etc.
lors d'une nouveau rendu du composant la fonction filterDays est supprimé pour libérer de la mémoire et recréer pour prendre ses nouveaux paramètres, ce qui n'est pas le cas avec useCallback qui garde toujours les ordures des anciens paramètres ce qui peut causer des problèmes de mémoires.

Deux bonnes raisons nous poussent à utiliser ces deux hooks:

L'inégalité référentiel
Les calculs coûteux en temps.

L'inégalité référentiel

Reprenons notre exemple précédent et changeons deux ou trois trucs.

const weekDays = [
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thrusday",
    "Friday",
    "Saturday",
    "Sunday",
  ];
  const mapMonth = {
    0: "Junuary",
    2: "February",
  };
  const [days, setDays] = React.useState(weekDays);
  const weekDayMemo = useMemo(() => weekDays, []);
  const monthCallBack = useCallback(() => mapMonth, []);

  useEffect(() => {
    console.log(weekDays, mapMonth);
  }, [weekDays, mapMonth]);

si vous vérifiez la console de votre navigateur vous verrez ce code s'exécuter à chaque rendu malgré que les valeurs de Weekdays, et mapMonth restent intact.
La raison pour laquelle cela pose problème est que useEffect va effectuer une vérification d'égalité référentielle sur les weekDays, et mapMonth entre chaque rendu, et de la manière dont JavaScript fonctionne, les weekDays, et mapMonth seront nouvelles à chaque fois, donc lorsque React teste si les weekDays, et mapMonth ont changé entre les rendus, la réponse sera toujours évalué à true, ce qui signifie que le rappel useEffect sera éffectué après chaque rendu.
Une belle utilisation de useCallBack et de useMemo pourrait se faire ici pour éviter cela.

const weekDays = [
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thrusday",
    "Friday",
    "Saturday",
    "Sunday",
  ];
  const mapMonth = {
    0: "Junuary",
    2: "February",
  };
  const [days, setDays] = React.useState(weekDays);
  const filterDays = () => {
    setDays((weekDays) => weekDays.filter((day) => day !== "dayToFilter"));
  };
  const weekDayMemo = useMemo(() => weekDays, []);
  const monthCallBack = useCallback(() => mapMonth, []);

  useEffect(() => {
    console.log(weekDays);
  }, [weekDayMemo, monthCallBack]);

Les Calculs coûteux en temps de calcul.

L'un des exemples les plus connu de la récursivité est la suite de fibonacci, implémentons cela dans notre application react pour mésurer les performances de useMemo.
Sans UseMemo

function fibonacci(num: any): any {
  if (num <= 1) return 1;

  return fibonacci(num - 1) + fibonacci(num - 2);
}

function PromptFibonacciNumber(props: any) {
  const fibonnacciNumber = fibonacci(props.number);
  return fibonnacciNumber;
}

// Our Counter
function Counter() {
  const [count, setCount] = useState(0);
  return (
    <>
      {count}
      <button onClick={() => setCount(count + 1)}> Add </button>
      <br />
      <br />
      <br />
      <PromptFibonacciNumber number={42} />
    </>
  );
}
export default Counter;

En testant ce code dans votre application react vous pouvez constater le temps énorme mis par l'application avant de générer un nouveau rendu, cela est du au fait que le composant <PromptFibonacciNumber number={42} /> calcule la valeur du composant à chaque rendu ce qui n'est pas très pratique puis que la valeur reste intacte.
Voyons comment optimiser cela.
Avec useMemo

function PromptFibonacciNumber(props: { number: number }) {
  const fibonnacciNumber = useMemo(
    () => fibonacci(props.number),
    // the function will not be executed again until the `number` property changes.
    [props.number]
  );
  return fibonnacciNumber;
}

Les performances de notre applications sont nettement meilleures qu'auparavant.

Je suis à la fin de mon article j'espère que vous aviez appris.
A la semaine prochaine pour un autre article.

MY 42 School Piscine.

Traky Richard — Mon, 10 May 2021 11:08:06 +0000

After having thought long and hard about what to publish as a coding-related article on the site, I finally decided to go ahead and share with you my feelings on a pleasant adventure that I spent the 4 last weeks in code. The adventure was that of a test call piscine, of a wonderful school that I discovered on Facebook, The 42 School. for more info, you can follow the link https://www.42heilbronn.de/
It is in the abundance of the heart that the mouth speaks. My Piscine at School 42 was an amazing and wonderful adventure for me.
This event was great, I didn't expect it at all, but it changed my life and my whole being. I have been tested on many levels and thank God I have overcome them all.
I will approach this trip in 3 different points: it will be at

I. Give the different challenges that I had to overcome;

II. Next, I would say the improvement that I had in certain behaviors;

III and finally I will say how I was able to hold out to the end of this Piscine.

I. Differents Challenges

As challenges, I had quite a few and if the other campers all started from zero I started from -2. Don't worry, I'll tell you why.
1. I started this Piscine (Test) with a very low level of English, not to say catastrophic hahaha. Where other campers would read and respond to the post, I needed the help of Google Translate to chat with them as I didn't understand all the terms and wanted to help them. The accents varied from person to person, so it was fun and complicated at the same time. the day before the end it was a great joy for me to hear one of my pair tell me that my level in English has changed a lot.
2. The internet connection for me was more of a challenge than being able to process the exercises. I stayed in a place for a month with all the restrictions possible (no friends, went out very limited, etc..) to be able to have at least one acceptable Piscine. This connection problem has indeed greatly delayed my Piscine since I had checked in for 4 months but I was waiting for the right moment to get started.

II. As an improvement,

many aspects of my life have been improved:
1. The aspect of giving and receiving. I started by receiving because I didn't know much about the C language, then I realized that others understood less than me and that it was my responsibility to contribute. It wasn't just my coding skills that were boosted, even my sense of sharing was enhanced.
2. I have learned a lot about humility.
By nature I am a very humble person who learns from everyone, big or small, I was even considered a strange man who did not care for himself and did not value himself.
This experience showed me that I was made for this kind of ecosystem and that in the world of 42, only humility will one day make us very good and competent developers.

III How I get Motivated.

I was able to reach the end of this test using these sentences
1. The first was: "If your dreams don't scare you, they aren't big enough." Mike Horn, adventurer.
My dream is to wake up one day in the offices of Facebook or Google in Silicon Valley and for that, I had to pay a price and whatever that price is
The pool experience went very well but I told myself that even if the campers did not accept me and criticized my English, I was going to keep fighting to achieve my goal for me success is not only having money is also having an inspiring life. I would like to be the first Nigerian from Niger (not Nigeria from Nigeria) to work at Google and the third to pass the 42 Piscine. And for that, I was more than motivated and very convinced that I had nothing to lose.
2. The second sentence is this: This sentence is an African proverb which says that if you want to live your old age well, you must suffer in your youth. And here I am in my youth, I have time, not a lot of burdens, and many projects that I would like to realize before old age takes hold of me. because time flies very quickly.
3. And finally, the last one is. “If you have to do a job, do it well and stay in it no matter how hard it is, that will make you a winner and not a loser. That line from Rick Rigsby has helped me a lot, I like to motivate people through what I do and code in my country I would like to bring a new touch and this is only possible by going elsewhere to learn the knowledge no matter what I will never give up and that is what I did.

Here are a few words about my career at school 42.
In the next few days, I will share the results with you, which I firmly believe are positive.