14 skills found
TRI-ML / PermatrackImplementation for Learning to Track with Object Permanence
ofrikleinfeld / ObjectPermanenceCode for our paper: *Shamsian, *Kleinfeld, Globerson & Chechik, "Learning Object Permanence from Video"
theweaver19 / CheckmynftNFT asset permanence checker
tudelft-iv-students / Offline Tracking With Object PermanenceThe open source implementation of 'Offline Tracking with Object Permanence', which aims to recover the occluded vehicle trajectories and reduce the identity switches caused by occlusions.
alopezrivera / AnchorageSave your bookmark collection in the Internet Archive, or locally.
TRI-ML / RAMImplementation for Object Permanence Emerges in a Random Walk along Memory
bitcoinecho / Bitcoin EchoA complete Bitcoin protocol implementation in pure C, designed to freeze forever upon completion. Zero dependencies. Built for permanence, not continued development.
Kevadroz / PracticeCheckpointPermanenceA Geometry Dash mod about saving and loading checkpoints
bluerider / BaseOSUSB based OS featuring selective data permanence and block level encryption
Jafree / Permanence Dynamic GameNo description available
voidsong-dragonfly / NaturalphilosophyAdding the object permanence that Mojang didn't have to Vanilla biome design
frankidav / Tp2 Capteurs1 Objectifs - Se familiariser avec des notions intermédiaires du langage C - Utiliser l’ensemble des notions présentées jusqu’à maintenant : les tableaux, les enregistrements, la modularité, les fichiers, les listes statiques, etc. 2 Description du projet : Un agglomérateur de données sans-fil Une tendance amorcée depuis plusieurs décennies est l’instrumentation de l’environnement et le stockage persistant de données, dans le but d’avoir accès au plus d’informations possibles et de pouvoir les utiliser pour mieux prédire et comprendre des comportements. Les données météorologiques et financières, l’instrumentation d’équipements industriels et commerciaux ou les mesures sur l’utilisation des axes routiers ne sont que quelques exemples de contextes dans lesquels les données sont agglomérées et analysées. Dernièrement, des tendances telles que l’utilisation de Big Data, l’Internet Of Thing (IOT) et le Cloud computing n’ont que confirmé que l’agglomération de données et la distributivité des systèmes informatiques étaient là pour rester et même que le volume de données n’allait que continuer à augmenter pour atteindre des proportions qu’on aurait à peine pu imaginer il y a à peine vingt ans. Bien que les infrastructures permettant d’enregistrer et de stocker les données soient multiples, un schéma émerge fréquemment : Dans ce schéma, on retrouve des équipements (E), un agglomérateur (A) et un serveur (S). INF-145 Programmation avancée et langage C Hiver 2017 /Page 2 Les équipements produisent des données. Il se peut que ce soit des mesures de température, des enregistrements audio ou des mesures biométriques, par exemple. L’agglomérateur a pour fonction d’établir le lien de communications avec les équipements et le serveur. Pour ce faire, il extrait les données des équipements, les accumulent, puis les transmettent au serveur qui les enregistrent dans une base de données, pour un stockage permanent. Le schéma présenté est une vulgaire simplification de la réalité. Généralement, il y a plus d’un agglomérateur et le nombre d’équipements peut-être incalculable. Même que le serveur peut- être un client vers un autre serveur central, s’il en est un. Ce type de topologie peut prendre des dimensions considérables même à l’échelle mondiale : Problématique Un cas particulier de ces systèmes est celui où la connexion entre les équipements et l’agglomérateur n’est pas permanente. Par exemple, si les équipements de mesures sont installés sur de la machinerie mobile, tel que des chariots élévateurs, et que le lien entre l’agglomérateur et les équipements est sans-fil et de portée limité (pensez à WiFi, Bluetooth ou ZigBee); il est évident que le mouvement des équipements les amènera à fréquemment entrer et sortir du rayon de portée de l’agglomérateur. La connexion ne peut donc pas être maintenue de façon permanente et est destinée à être interrompue à un moment ou à un autre. INF-145 Programmation avancée et langage C Hiver 2017 /Page 3 L’équipement ne peut se permettre de cesser de fonctionner lorsqu’il est hors ligne. Les données enregistrées qui ne peuvent être transmises immédiatement sont donc accumulées à l’équipement en attendant d’être transmises à l’agglomérateur. La stratégie de l’agglomérateur est donc de fonctionner de façon opportuniste. Quand un équipement entre dans le rayon – devient en ligne – l’agglomérateur lui demande de lui envoyer toutes les données enregistrées depuis la dernière connexion. De cette façon, même si les données n’arrivent pas au moment exact où elles ont été enregistrées, aucune donnée n’est perdue et elles peuvent toutes être sauvegardées. Travail à faire Dans le cadre de ce travail pratique, vous vous concentrerez sur la conception et la réalisation de l’agglomérateur et, plutôt que de communiquer avec un serveur comme illustré ci-haut, vous utiliserez un fichier texte (de format ASCII) pour stocker toutes les données sur disque dur. Les équipements et leur mise en ligne seront simulés par un module de sous-programmes qui vous est fourni. Votre programme devra implémenter la stratégie de transfert de données opportuniste décrite dans la problématique. Le projet qui vous est proposé est ancré fermement dans la réalité puisque, bien que simplifié, il s’inspire directement d’un contrat réalisé par une vraie firme d’ingénierie. Le principe de fonctionnement, l’implémentation du protocole de communication et de la structure de données est un véritable problème à résoudre pour un développeur logiciel en système embarquée. On espère que cette perspective vous stimulera. Voici une photo du prototype des équipements de mesures et de l’agglomérateur de ce travail : Les différents capteurs communiquent les données par l’entremise d’un lien Bluetooth (la lumière bleu indique d’ailleurs qu’un transfert est en cours). L’agglomérateur transmet ensuite les données vers un serveur s’exécutant sur Amazon Web Service (AWS). INF-145 Programmation avancée et langage C Hiver 2017 /Page 4 Note du concepteur du laboratoire à l’intention des élèves Prenez note que ce travail a pour but à vous amener à développer une aptitude à programmer de façon plus autonome. La longueur du travail, en ligne de code, est relativement courte et la description du fonctionnement des différents modules et sous-programme est très élaborée. D’un autre côté, très peu de noms de fonctions, de modules ou listes de paramètres sont fournis explicitement. C’est à vous d’essayer, d’inventer et, finalement, de coder ce programme. N’hésitez pas à poser des questions dans les cas où vous êtes vraiment bloqué. 3 Description de l’application L’application que vous devez développer est divisée en trois sections : 1. simulateur_capteurs : ce module vous est fourni. Il simule un groupe de capteurs qui enregistrent des données et qui les transmettent à l’agglomérateur, quand celui-ci en fait la demande. Les capteurs ne sont pas tous connectés en permanence, leurs communications avec l’agglomérateur se fait de façon asynchrone. Liste des fichiers fournis : simulateur_capteurs.cpp/.h, utils.h 2. interface : ce module vous est également fourni. Il est construit pour établir une division entre le module du simulateur de capteurs et l’agglomérateur. La seule façon par laquelle les capteurs et l’agglomérateur peuvent échanger des messages, c’est par l’entremise de l’interface. Cela met en évidence le fait que dans la réalité, le programme des capteurs et de l’agglomérateur sont deux programmes différents qui communiquent seulement par l’entremise d’une interface de transfert de données (Bluetooth, Wi-Fi, etc). L’interface définit également le protocole de communication qui doit être commun aux deux systèmes (voir : messages.h). Fichiers fournis : interface.cpp, interface.h, messages.h 3. agglomerateur : vous devez développer cette section, qui comporte plusieurs modules : le gestionnaire de communication, la base de données locale et l’interface fichier. L’agglomérateur est constamment dans l’attente de la réception d’un message et il répond en envoyant des commandes aux capteurs. De plus, il doit périodiquement écrire les données dans un fichier sur le disque dur, pour garantir leur stockage permanent. INF-145 Programmation avancée et langage C Hiver 2017 /Page 5 Schéma du programme, indiquant les principaux éléments à tenir en compte : le simulateur de capteurs, l’interface, l’agglomérateur ; De même que les définitions disponibles pour chacun des modules : messages.h pour tous, définit le protocole de communication. interface.h pour les capteurs et l’agglomérateur, Absente du schéma : utils.h accessible à tous, contient des fonctions utilitaires. 4 Module : Gestion des communications (semaine 1) Le gestionnaire des communications est son propre module, vous devez le créer et implémenter les fonctionnalités qui suivent. Lisez la section en entier avant de commencer le travail, et prenez le temps de planifier ce que vous allez faire, avant de vous lancer. 4.1 Détection des événements L’agglomérateur attend perpétuellement l’avènement d’un événement. Il le fait en faisant des requêtes périodiques à la fonction detection_evenement, disponible dans le module d’interface (interface.h). La fonction detection_evenement retourne VRAI (1) à chaque fois qu’un des capteurs a envoyé un message par l’entremise de l’interface. À ce moment, l’agglomérateur doit : récuperer le message (avec reception_message_capteur dans interface.h) analyser le message et produire une réponse (fonctions à définir et décrite dans la soussection suivante), INF-145 Programmation avancée et langage C Hiver 2017 /Page 6 puis envoyer le message au capteur (avec la fonction envoyer_vers_capteur, dans interface.h). Voici l’ordinogramme qui décrit ce processus : 4.2 Analyse du message et production de la réponse (entête) Les messages contiennent deux parties : l’entête et le contenu (voir messages.h). Dans cette section nous nous concentrons uniquement sur l’entête, car toute la séquence des communications peut s’exécuter sans tenir compte du contenu. Type : t_message - entête L’entête permet de savoir qu’elle est le message et, dans le cas où le message contient des données, le contenu contient ces données. Voici une illustration de la structure en mémoire d’un message, tel que défini dans messages.h : INF-145 Programmation avancée et langage C Hiver 2017 /Page 7 Le premier champ, id_capteur, est une chaîne de caractères unique à chaque capteur. Elle doit être utilisé lors de la réception d’un message, pour déterminer quel capteur a envoyé le message, puis doit être inclus dans les messages envoyés pour indiquer à quel capteur le message s’adresse. Le second champ, commande, indique de quel type de message il s’agit. C’est à partir de la commande que le capteur et l’agglomérateur savent ce qu’ils doivent faire avec le message (voir section 4.1.2). Les valeurs possibles pour la commande sont définies dans un enum t_commande. Le troisième champ, contenu, est un espace mémoire qui est utilisé dans les cas où le message contient des données. C’est à partir du champ commande que l’on sait comment interpréter cet espace-mémoire (voir section 5). 4.3 Séquence d’échange de message Voici maintenant la séquence des échanges entre les capteurs et l’agglommérateur; du début d’une connexion jusqu’à sa fin. Toutes les constantes commençant par « MSG_ » sont des commandes, tel que défini dans messages.h : Voici une description de la séquence : Tout d’abord, quand le capteur en a l’occasion, il envoie un message à l’agglomérateur qui contient la commande MSG_DEBUT_COMM. L’envoi de ce message résulte en un événement du côté de l’agglomérateur (section 4.1). L’agglomérateur répond avec un message demandant le statut du capteur MSG_DEMANDE_STATUS. INF-145 Programmation avancée et langage C Hiver 2017 /Page 8 Le capteur envoi ensuite un message contenant le statut MSG_ENVOI_STATUS. Le statut indique combien de mesuresle capteur a accumulé (traité dans la section 5). Si le nombre de mesures est supérieur à 0, l’agglomérateur doit répondre MSG_DEMANDE_MESURES, sinon il répond MSG_TERMINE_COMM. Si l’agglomérateur a demandé des mesures au capteur, le capteur envoie MSG_ENVOI_MESURES. S’il reste des mesures dans le capteur, l’agglomérateur répond MSG_DEMANDE_MESURES à nouveau, sinon il répond MSG_TERMINE_COMM. Prenez note que l’échange MSG_DEMANDE_MESURES MSG_ENVOI_MESURES, peut se répéter plusieurs fois lors d’une communication. 4.4 Implémentation Vous avez maintenant toute l’information nécessaire pour construire le gestionnaire d’événements. Voici quelques détails et instructions supplémentaires pour vous aider : o Le gestionnaire doit être entièrement contenu dans un seul module. o En plus des librairies standards, il ne peut inclure que le fichier « interface_agglomerateur.h », qui inclut également « message.h ». o Il est strictement interdit d’inclure des définitions provenant du simulateur de capteurs. o Le simulateur de capteurs peut-être initialisé (voir programme_principal.cpp) selon plusieurs modes d’opération. Pour l’instant, initialisez-le avec le mode UN_SEUL_CAPTEUR, cela simplifiera le problème pour l’instant. o Vous n’avez pas à analyser le champ id_capteur pour l’instant, mais il doit être copié dans la réponse. o Vous pouvez également ignorer le statut du capteur et ne faire qu’une seule demande de mesures : MSG_DEMANDE_MESURES, puis retourner MSG_TERMINER_COMM après la réception de MSG_ENVOI_MESURES. La gestion des mesures se fera dans la section 5. o Vous avez le droit d’analyser le code de « simulateur_capteurs.cpp » et de vous en inspirer. Vous avez même le droit de le modifier pour vos tests, mais il doit être remis à son état original avant votre remise. Par exemple, les fonctions simulateur_traitement_message et active_capteur_alea utilisent toutes deux un switch pour catégoriser un type enum. o Conseil, faites une fonction par message à traiter : MSG_DEBUT_COMM, MSG_ENVOI_STATUS, MSG_ENVOI_MESURES. o À la suite de votre développement, vous devriez être capable de lancer l’exécution du gestionnaire des communications à partir d’un seul appel de fonction, à ajouter au programme principal. Votre but est d’être capable d’exécuter toutes la séquence de communications, à répétition. Une fois cela fait, vous pouvez continuer à la prochaine section. Comparer le comportement de votre application avec la solution, configuré pour un seul capteur. INF-145 Programmation avancée et langage C Hiver 2017 /Page 9 5 Base de données locales (semaine 2-3) La base de données locales est une liste statique qui contient l’information relative à chaque capteur, tel que : le nom des capteurs, le nombre de mesures restantes dans le capteur et les mesures recueillis par l’agglomérateur jusqu’à maintenant. Son développement se fait en deux étapes. La première est de construire le système qui fait la liste des noms des capteurs du réseau. La seconde est d’extraire les mesures des capteurs et les stocker dans l’agglomérateur. La base de données locale est un module à part entière. Ce module ne peut inclure les entêtes du simulateur de capteurs. À ce point du développement, ce module est destiné à être appelé du gestionnaire des communications uniquement. 5.1 Identification des capteurs du réseau Initialisation du module Le nombre de capteurs présent dans le réseau est une donnée connue (voir le programme principal). L’information doit donc être passée comme argument à partir du programme principal. La taille de la liste statique doit être initialisée à partir du nombre de capteurs reçu en paramètre. Fonctionnement du module Au moment du lancement du programme, la liste statique contient des éléments initialisés avec des valeurs par défaut. Les noms des capteurs du réseau sont encore inconnus, puisqu’aucun capteur ne s’est connecté à l’agglomérateur. Au départ, il s’agit donc d’avoir un mécanisme qui permet d’ajouter un capteur dans la liste. Le même mécanisme sera également utilisé pour retrouver un capteur déjà présent dans la liste, un peu plus loin. Voici l’ordinogramme du fonctionnement de ce mécanisme. INF-145 Programmation avancée et langage C Hiver 2017 /Page 10 Une fois que tous les capteurs se seront connectés, voici l’état final du contenu de la liste : Procédure de validation Changer le mode d’opération du simulateur de capteurs pour NORMAL, puis laissez le code s’exécuter pendant au moins une minute. Assurez-vous que vous avez bel et bien un nombre d’identificateurs de capteur correspondant au nombre entré par l’utilisateur en début de simulation. Chaque nom doit être unique et du style : « id455 », où l’entier (455) est choisi aléatoirement. (faites-vous une fonction pour afficher le contenue de la liste) 5.2 Sauvegarde du nombre de mesures présente dans le capteur Au moment de sa connexion à l’agglomérateur, un capteur a généralement un certain nombre de mesures accumulées en mémoire. Le nombre de mesures est envoyé lors de la réponse au message MSG_DEMANDE_STATUS (voir messages.h). INF-145 Programmation avancée et langage C Hiver 2017 /Page 11 Lorsque le MSG_ENVOI_STATUS est reçu par le gestionnaire des communications, celui-ci doit sauvegarder la valeur contenue dans le message dans l’élément correspondant au capteur_id. Pour ce faire : Utilisez la fonction qui permet d’obtenir une référence sur l’élément correspondant à l’id du capteur (voir sous-section 5.1.2). Appelez la fonction permettant d’enregistrer le nombre de mesures sauvegardées dans le capteur (vous devez la faire). 5.3 Sauvegarde des mesures présentent dans le capteur À ce moment vous avez : Établit le contact avec les capteurs Organisé les capteurs dans une liste et construit un mécanisme pour les ajouter/trouver Enregistré le nombre de mesures disponibles au capteur Il s’agit maintenant de maîtriser le transfert des mesures des capteurs vers l’agglomérateur. 5.3.1 Explication : Côté capteur Le capteur accumule des mesures dans sa mémoire jusqu’à ce qu’il arrive à se connecter à l’agglomérateur. Lorsque la connexion est établit, il attend que l’agglomérateur lui demande des mesures. Quand l’agglomérateur lui demande des mesures, le capteur lui en envoie et efface de sa mémoire les mesures qui ont été envoyées. Le nombre de mesures qui peut être envoyé dans une transaction est limité par une constante définit dans messages.h. Si le nombre de mesures mémorisé est plus grand que ce nombre maximal, le transfert des mesures nécessitera plusieurs transactions. 5.3.2 Côté agglomérateur Lors de la connexion, l’agglomérateur demande le nombre de mesures que le capteur possède (voir section 5.2). Si le nombre de mesures est supérieur à 0, alors l’agglomérateur demande au capteur de lui envoyer des mesures. À chaque fois que le capteur envoi des mesures, l’agglomérateur : enregistre les mesures dans l’élément de liste correspondant (les détails suivent) actualise le nombre de mesures restantes dans le capteur. Cette valeur est sauvegardée dans l’élément de liste correspondant à ce capteur (section 5.2). INF-145 Programmation avancée et langage C Hiver 2017 /Page 12 L’agglomérateur vérifie à nouveau si le nombre de mesures est supérieur à 0. Si c’est le cas, il demande d’autres mesures, sinon il termine la communication (voir 4.1.2). Voici une illustration qui démontre comment cette opération est effectuée. 5.3.3 Détails concernant l’implémentation Le tableau contenant les mesures, du côté agglomérateur, doit être dans un élément de la liste. La taille maximale du tableau doit être une constante d’une valeur de 1000. Une fonction informatrice (get_) qui permet de connaître le nombre de mesures restantes dans le capteur est obligatoirement nécessaire. Une fonction qui ajoute les mesures à un élément de la liste doit être ajoutée au programme. Cette fonction reçoit une référence à l’élément de la liste, puis un tableau de réels contenant les mesures et finalement un entier indiquant le nombre de mesures dans le tableau. Toute la logique de la communication doit être ajoutée au segment de code qui gère le MSG_ENVOI_MESURES du module de gestion des communications. INF-145 Programmation avancée et langage C Hiver 2017 /Page 13 5.3.4 Validation 1. Tout d’abord tester votre programme en faisant l’initialisation du simulateur en mode UN_SEUL_CAPTEUR. Puisqu’il s’agit d’un mode de validation, toutes les mesures sont des entiers commençant à 0, puis s’incrémentant de 1. Vérifiez que les mesures sont bel et bien transmises du capteur vers votre base de données locale et que toutes les valeurs se retrouvent dans le bon ordre. 2. Pour tester avec plus d’un capteur, il y a deux modes disponibles : MESURE_EN_SEQUENCE_PAR_CAPTEUR : Toutes les mesures produites pour un capteur sont en ordre et commencent à 0, puis s’incrémentent de 1. Tous les capteurs ont donc les mêmes mesures, mais les mesures sont toutes uniques pour un capteur donné. Un exemple est fourni dans le fichier : ex_mesures_en_sequence_par_capteur.txt MESURE_EN_SEQUENCE : Toutes les mesures produites sont en ordre et commencent à 0, puis s’incrémentent de 1, indépendamment du capteur. Par conséquent, toutes les mesures sont uniques et chaque capteur contient des mesures différentes. Il reste que les mesures ont une structure qui aide à identifier les problèmes. Un exemple est fourni dans le fichier : ex_mesures_en_sequence.txt NORMAL : Les mesures sont déterminées aléatoirement. 6 Interface fichier (semaine 4) La base de données locales ne sert à garder les mesures que temporairement. Pour que les mesures soient mémorisées de façon permanente, elles doivent être transférées dans un fichier. Le format utilisé pour l’écriture des données dans le fichier est le format CSV (https://en.wikipedia.org/wiki/Comma-separated_values). Selon ce standard, chaque mesure est séparée par une virgule et chaque entrée est sur sa propre ligne. Dans notre cas, une entrée consiste en les mesures de chaque capteur. Par exemple, un système à 5 capteurs aura donc 5 mesures par ligne (voir fichier : ex_mesures_en_sequence.txt). 6.1 Initialisation Ce module doit proposer une procédure pour être initialisé. Cette fonction reçoit comme paramètre le nom du fichier et le nombre de capteurs. Cette procédure ouvre le fichier en écriture et le ferme immédiatement, pour effacer le contenu d’un fichier déjà existant. L’appel à cette procédure doit être placé dans l’initialisation du gestionnaire de messages. Ajustez les appels et définitions de fonctions en conséquence. 6.2 Transfer des données vers le fichier Le transfert de données vers le fichier doit se faire ligne par ligne. La façon dont les capteurs communiquent leurs mesures par contre est incompatible avec cela. En effet les capteurs transfèrent leurs mesures par paquet, mais l’écriture des mesures requiert que tous les capteurs aient le même nombre de mesures : INF-145 Programmation avancée et langage C Hiver 2017 /Page 14 Par exemple, disons que le système comporte 3 capteurs et qu’ils aient chacun {120, 150, 0} mesures en mémoire. Il n’est pas possible d’écrire les données lignes par lignes, car il n’y a pas de mesure à écrire sur la ligne pour le troisième capteur. Par contre, si les 3 capteurs ont chacun {75, 150 et 125} mesures, il est alors possible d’écrire dans le fichier 75 mesures pour chaque capteurs, ce qui fait qu’il n’en restera ensuite que {0, 75 et 50} dans la mémoire temporaire. C’est à cela que sert la base de données locale, elle sert de tampon de façon à accumuler les données jusqu’à ce que tous les capteurs aient un minimum de mesures en commun avant de pouvoir faire le transfert. 6.2.1 Nombre de mesures minimales en commun La gestion de la liste développée à la section 5 exige une fonction qui permet de connaître le nombre de mesures minimales, commun à tous les éléments. Ajoutez cette fonction (aide : Il s’agit d’un algorithme pour trouver la valeur minimale de la liste). 6.2.2 Lire les mesures de la base de données La lecture des données dans la base de données se fait de la manière suivante : Dans la liste La liste propose une fonction (à faire) qui reçoit en paramètre le nombre de mesures à lire et une référence vers un tableau où mettre ces mesures. L’appelant s’est déjà assuré de fournir un tableau de taille suffisante. La fonction copie les données dans le tableau reçu, et efface ensuite les données de la base de données, en décalant les mesures restantes vers le début du tableau. 6.2.2 Transfert des mesures vers les fichiers Dans l’interface fichier Il est maintenant possible d’ajouter une procédure dans l’interface-fichier qui transfert les mesures de la liste vers le fichier, voici la séquence d’opérations à faire : Obtenir le nombre de mesures minimales (voir 6.2.1) INF-145 Programmation avancée et langage C Hiver 2017 /Page 15 Si ce nombre est plus grand que 50 (constante à définir), Créer un tableau 2D de taille suffisante pour contenir les mesures (faites une fonction) Appeler la procédure de lecture des mesures (6.2.2) Ouvrir le fichier texte de mesures en mode d’ajout (append) Copier toutes les mesures dans le fichier selon le standard CSV Libérer la mémoire du tableau 3D (faites une fonction) Fermer le fichier Ajoutez un appel à cette fonction dans le gestionnaire de messages. L’appel doit être fait chaque fois que la détection d’événements retourne FAUX (voir section 4.1). 7 Contraintes de l'enseignant Votre programme devra respecter les contraintes suivantes : Il devra respecter les exigences de remise des travaux pratiques. Il ne devra contenir aucune variable globale. La présence d’une variable globale entraînera la perte de 25 % des points. Il ne devra contenir aucun goto et aucun exit. La présence d’une de ces instructions entraînera la perte de 10 % des points. Votre travail devra être remis sur Moodle. En cas de doute, n’hésitez pas à consulter votre enseignant. BON TRAVAIL!
AbdelaliChe / Pharmacy Permanence OdooIntroducing the Proximity and Permanence Pharmacy Management System—an efficient Odoo module designed for Moroccan pharmacies. This system ensures real-time updates on nearby and permanence pharmacies, along with a streamlined process for medicine booking.
CSDUMMI / SpatialPoolerState -> Potential Pool -> Permanence -> Activation -> State'
