 Donc, pourquoi double feature ? Parce que je suis encore en train de travailler sur beaucoup de choses que je n'ai pas fait. Donc, j'ai travaillé sur la première partie de ce doigt, pour cacher ou non pour cacher. C'est légèrement l'année dernière. Qui utilise OpenBSD régulièrement ? Oui, vous avez probablement remarqué les résultats. Parce que c'est un énorme improvement en speed. Et j'ai travaillé sur des choses un peu plus récentes, pour des raisons variées. L'un des choses plus récentes, c'est que j'ai un étudiant, donc il est intéressant de travailler sur ces outils de baguette et tout. Et il me semble être remarquablement compliqué de expliquer tout à lui. Donc, j'essaie de faire des choses un peu plus simples, ce qui est un challenge, bien sûr. Donc, oui, c'est la seconde partie. Donc, on commence pour vrai. Donc, nous avons travaillé pendant 3 ans, comme je l'ai dit. Et pour ceux de vous qui n'est pas familiar avec OpenBSD packages, nous faisons juste des updates en temps, on voit quelque chose qui a été designé presque depuis le début. Donc, à l'aide de downloader la liste de packages et tout, nous ouvrons un package qui est possible pour l'update. Nous regardons des informations de meta, et nous avons décidé qu'on ne veut pas d'update. Il y a des avantages, et il y a des rares avantages. C'est que c'est vraiment difficile de faire, parce qu'on n'est pas de l'espace, ou de la mémoire, ou quelque chose comme ça. Parce qu'on ne garde pas trop d'informations en mémoire. Il y a aussi un design concernant les noms de packages, qui signifie que c'est souvent facile de trouver des updates, avec des exceptions, parce que les gens tendent à renouer les choses quand ils ne devront pas. Assumons qu'on a besoin d'updates. Nous allons premièrement extracter un nouvel package, puis relâcher l'autre, et ensuite installer un nouvel package. C'est un peu différent de l'autre système, où souvent c'est un peu... Ok, on va essayer d'updates, et si ça ne fonctionne pas, nous allons retourner à l'installation précédente. On essaie de prouver que l'installation va travailler bien, spécifiquement, pour exemple, nous avons extracté tout d'abord, pour que nous sommes sûrs, nous avons suffisamment besoin d'un nouvel package, et ensuite, nous avons réalisé le nouvel package, et ensuite, nous avons terminé l'installation. Donc, à presque aucun point en temps, nous avons un nouvel package. Donc, si nous ne l'avons pas, nous allons juste ouvrir la connexion et passer à la prochaine. Comme ça, notre propre set de compromises et de soucis, nous pouvons essayer d'avoir un connecteur spécialisé à l'extérieur, mais nous avons décidé de ne pas faire ça pour des raisons de sécurité, c'est beaucoup plus simple d'avoir quelque chose comme FTP, qui connecte à l'extérieur, et donc, je n'ai pas besoin d'une issue de sécurité TLS, pour exemple. Et aussi, nous pouvons vraiment essayer d'avoir, non plus que ça, FTP a été fait comme un utilisé complètement imprivile pour les raisons de sécurité. Il devrait probablement aller un peu plus vite. Donc, cette information que nous avons utilisé pour les updates ressemble à ceci. C'est ce que vous avez dans le nouvel package. C'était le bus des jours auparavant. Donc, vous savez où ça vient, alors que vous pouvez vérifier qu'il y a un bus d'augmentation ou quelque chose d'autre. Et vous avez des informations d'informations, comme création d'utilisateurs et puis vous avez les actuales files. Donc, c'est la information de la back-in liste, mais pas ceci. C'est la source d'informations. Quand vous avez un nouvel package créé, c'est allé annoter avec beaucoup d'autres choses, comme, pour exemple, la information dépendante, qui est compétue dynamiquement chaque fois que vous créez un nouvel package. Donc, en ce cas, vous avez encore un set de points libres, libres du système et du port 3 que nous avons utilisé pour compilier le bus. Et quand vous allez regarder l'update du bus, bien sûr, vous allez augmenter le bus, chaque fois que l'une des versions libres change. Et aussi, des informations d'actuales fondamentales. Mais je ne pense pas qu'il y a d'autres buses, pour quelque chose d'autre. Et quelques années auparavant, il y a un panneur qui s'appelle version à version, dans la seconde ligne, qui vous pouvez bumper chaque fois que vous changez quelque chose dans le système base, ce qui signifie que toutes les packages avec des trucs binariés devraient être updates. Comme, pour exemple, si vous changez votre compiler C++ et le changement de base types, comme, pour exemple, si vous bougez pour que je reste de l'insignement à l'insignement, ce qui s'est passé dans le passé. Ensuite, vous n'avez pas à travers le port 3 chaque et chaque single package qui dépend de cette information. Et aussi, de temps en temps, on obtient le même problème avec certaines architectures. Oui, donc c'est un peu long, bien sûr. Donc, comment fonctionne la programmation ? Donc, les listes de packages sont des informations structurelles. C'est créé par plusieurs constructeurs, qui habitent des files d'informations, et qui créent une liste de différents objectifs. Chaque objectif est un membre de la base class qui s'appelle Packing Elements. Oui, je sais, c'est pas original pour un nom. Et vous avez des objectifs complexes parfois, qui ont des informations qui sont dans plusieurs lignes. Comme, pour exemple, un file peut avoir un nom, d'autres modes, et en fait, il y a un timestamp. Nous utilisons des timestamps dans le tar archive, mais nous n'avons pas du tout, ce qui signifie qu'il n'y a plus de variation de tableaux, ce qui est génial quand vous voulez synchroniser des choses sur la salle, en fait. Et sur la salle, bien sûr. Cela va nous battre plus tard. Ce serait très bien, si le Packing Elements était sur une salle, mais ce n'est pas pas un peu de problème, de toute façon. Il y a des objectifs orientés. Il y a des objectifs fileraux. Et toutes les annotations sont membres de la classe métallique. Et depuis qu'il y a un Packing List c'est assez expensif. Il y a des objectifs de Wally Arcea. Nous avons des méthodes spécifiques qui peuvent être vraiment partie du Packing List. Donc, pour exemple, quand vous regardez l'information d'updates, vous avez usually un complete Packing List, et vous regardez les informations métalliques qui sont nécessaires pour décider si vous voulez un update ou pas. Donc, basiquement, vous voulez le nom d'un Packing List. Vous voulez tout ce qui ressemble à une dépendance. Et depuis que ce sont les ordres dans le Packing List, dès que vous rencontrez un annotation qui n'est pas partie de l'information de dépendance, vous savez que vous avez arrêté de lire les informations de dépendance, et rien d'autre vous intéresse. Donc, la vitesse a toujours été une issue, mais c'était plus en plus. Pour décider les candidats qu'on considère pour un update, vous regardez les noms. Dans la plupart des cas, vous regardez un single Packing. Dans certains cas, il serait plus important de regarder toutes les versions de l'autoconf dans les 3. Donc, ça veut dire que quand vous voulez upgrade l'autoconf, vous avez besoin de regarder 17 différents packages. Ça prend beaucoup de temps. Ce n'était pas un gros problème 10 ans plus tard, parce que nous n'avons pas des networks très rapides. Et très souvent, le bandwidth était une issue, donc prendre moins de bandwidth était la partie vis-d'à-vis de l'Afrique et d'autres places. Nous avons beaucoup de bandwidth, mais nous avons encore très vite 1 trip de temps comparatively. Donc, ça veut dire que les connections et les connections de closures sont plus en plus installées quand vous faites ce genre de choses. Et donc, les packages vont vite. Mais c'était toujours très vite, mais c'était plus vite avec une récentes networks. Et aussi, nous avons un CDN, thanks to jobs. Donc, oui, nous utilisons HTTP et HTTPS. Ça peut être un peu plus lent. La première connexion est rédirectement à l'actualité. Et les packages déjà regardent ça et cachent la connexion à l'actualité pour la region d'application. Il y a un star, c'est parce que l'application est une grande connexion. Vous devez considérer que la grande connexion de packages est à peu près 60 gigabytes ces jours. Donc, l'updating d'une connexion pour la prochaine connexion n'est pas instantanée. Et si vous êtes vraiment malheureux, vous allez avoir une grande connexion et une nouvelle connexion, ce qui peut être une issue. C'est une grande connexion. C'est déjà une grande connexion. Nous avons un saveguards comme si vous avez un snapshot de la connexion, vous avez beaucoup d'insultes sur packages. Je suis français, donc il y a des insultes, bien sûr. Je vais vous dire que quelque chose de mauvais s'occupe. L'un d'entre vous est d'essayer de faire un peu moins d'intimidité. La connexion est utile pour moi, mais ça peut être short, pour les utilisateurs, mais c'est juste un snapshot et rien de mauvais. Je vais parler contre HTTPS parce que pour packages, ce n'est pas une bonne idée. Nos packages sont déjà signées, donc on n'a absolument pas d'authentication d'issue, mais HTTPS ne le met pas. Vous savez que HTTPS tendance à être un peu plus lent qu'une pure connexion de HTTPS. Parce qu'il faut souvent prendre des credentials des clients, des clés et tout. Il est supposé d'être plus rapide avec TLS 1.3, d'assumer que tout supporte TLS 1.3 au niveau récord. La dernière fois j'ai essayé de jouer avec TLS, c'était quelque chose comme 2 ans ago. Certains de nos mirrors n'étaient pas obligés de s'assurer. C'est une résumé, pour exemple, qui n'a pas travaillé sur les deux mirrors. Comme je l'ai dit, nous avons des packages signées, donc je ne vais pas parler de ça, parce que j'ai déjà parlé de ça quelques années plus tard. Mais cela signifie que plus ou moins d'assumer d'enforcer un bon habitant, HTTPS ne va pas prendre tout avec respect d'actuellement les packages. Donc, le gros problème est de prendre cette information de chaque packages, ne pas prendre tout. Et peut-être il y avait l'idée de faire un expériment en essayant de cacher quelque part de ce qui s'arrête. Mais il y a un problème, c'est qu'il y a une installation en production. Et ça va faire le sens seulement si on teste que l'information de cacher est bonne. Mais pour faire ça, j'ai besoin de convencer mes développeurs qu'ils devraient produire caches pour les snapshots. Et puis, j'aurai besoin d'écrire le code pour tester. Et aussi, nous n'avons pas de tools dans le système verbal. Donc, si vous avez 10 000 packages d'information pour chaque et every one of them, comment allez-vous les utiliser ? À un moment, nous avons eu l'escalier dans le système verbal. Mais c'était pour je dirais, pour vos raisons. Et aussi, il ne m'a pas aidé parce que ce code est toujours prête. Et que l'escalier n'est pas suffisant, vous devez aussi avoir le volant de l'escalier d'DB et d'DBI, c'est une grosse bise qu'ils ne veulent pas dans le système verbal. Mais il y avait une solution, pourtant, une solution de MacGyver. Nous avons un code Locate qui peut actuer comme un simple database. Ça signifie que vous avez tous ces lignes. Et vous pouvez mettre tout à l'heure. Et si vous avez un code, c'est partie de la ligne, vous pouvez le faire. Donc, on va essayer. Je l'ai déjà utilisé pour Package Locate d'DB. C'est une de les packages que vous pouvez installer, qui vous donneront la full liste de tous les files produits par toutes les packages avec les packages NEM. Et pour l'instant, c'est comme ça. Si je suis en train de regarder la VM, il faut me dire que ça commence avec, non, ça ne commence, ce path. Donc, ici, vous voyez que vous avez quelques packages actuales et surprenant, gravise aussi quelque chose qui ressemble à la même chose. Simple comme ça. Vous vous mettez votre information dans le database Locate informé et vous pouvez le retirer et vous n'avez pas à installer. Donc, c'est en fait j'ai fait des measurements à l'époque, nous avons eu 300 megabytes de Package Locate information compressée à seulement 23 megabytes. C'est très facile. Il y a d'autres algorithmes d'algorithmes pour Locate qui sont beaucoup plus vite comme je l'ai trouvé dans Dublin très rapidement. Mais c'est assez bon pour nous. Et c'est partie de la base systeme. Donc, je n'ai pas besoin de clémer l'openBSD. Vous savez que le service est faux si vous n'êtes pas un developer de l'openBSD. Vous n'avez pas entendu de ça, mais il y a une très définitive tendance de ne pas mettre quelque chose dans la base systeme. Avec respect à l'information basicale, c'est très simple. Vous créez une ligne avec chaque ligne de la liste actuale préparée avec l'éname actuale. Et ça compresse juste bien. Vous commencez avec 23 megabytes d'information actuale. Et ça compresse seulement 3 megabytes. Oui, 3 megabytes, c'est tout. En considérant la bande-width de ces jours. Et j'ai donné un script qui a créé de l'information pour mes pétiers de package. Et ensuite j'ai été distracté par le travail. Et j'ai oublié de le faire. Et la prochaine fois que je pouvais essayer de tester l'éname actuelle qui a disparu parce qu'elle ne s'est pas élevé. Vous verrez que ce que j'ai besoin de faire c'est de créer un script après les pétiers de package et d'obtenir les résultats sur le côté de quelque part. Alors que je ne pouvais pas le retirer. Donc pour faire des pétiers de package et d'obtenir les résultats, c'est pour une raison. C'est pour ça que les gens comme Nadi peuvent faire ça tous les 3 jours. On n'a pas trop de travail. Et en demandant de faire quelque chose d'autre, il s'agit de ne pas être trop fun après quelques semaines. Donc il l'a oublié. Et je ne l'ai pas oublié. Donc, pour faire le test d'aujourd'hui, j'ai dû trouver un moyen pour faire sure avant que je puisse le tester. Et on a déjà eu un mécanisme pour essayer de créer un package pour faire la même chose. On a eu un très mauvais package qui s'appelle Quirks qui a été créé pour contacter des exceptions. Parce que parfois, il y a des choses qui sont renseignées. Parce qu'il y a des bugs en base de distribution. Quirks est là parce qu'on ne peut pas prédiquer le futur. Et c'est toujours la première chose que le package a regardé. Il y a des updates chaque et à chaque fois. Vous essayez d'obleter votre base de système. Donc j'ai essayé de prétire les Quirks. Et j'ai demandé à mes amis, pour régénérer un package en viendres. Et cette fois, ils étaient disponibles. J'étais disponible. Donc, le succès a réussi à obtenir des choses dans Quirks. Et oui, il y a des trépidations pour qu'il soit ou pas, qu'il soit fonctionné ou pas. Et comment vite il va être. Donc, quelques résultats. Il y avait un grand smith avec quelques packages. J'ai toujours les updates. Je vais parler de ça plus tard. Je pense que c'est Sébastien Marie qui l'a décrochée. Et à part de l'information de la nouvelle database avant d'actuellement aller aux packages. Et wow, c'était rapide. 20 fois. En avantage. Donc, oui, à ce point c'est une bonne idée d'essayer de bouger de la partie expérimentale. Et de faire le travail. Qu'est-ce qu'il faut faire à ce point ? En général, avec un cash, avec aucun cash, je suis désolé. Un grand problème est de faire surement que vous avez la bonne information et que vos outils vont détecter le problème si quelque chose ne va pas. Donc, à l'abord, il y avait beaucoup de codes supplémentaires pour ne pas acheter le cash et aller aux packages de toute façon. Au moins comme une possibilité de débug. Et faire surement que les choses se matchent. J'étais en train de ne pas acheter rien mais pas beaucoup. J'étais surprisement en avantage d'être en train de faire le travail à chaque fois. Un non-issue aussi c'est que, bien sûr, vous allez agir de la même location que vos packages que vous avez créées. C'est-à-dire que vous ne pouvez pas cacher plusieurs sources de packages à une fois. C'est-à-dire que ce n'est pas un issue de toute façon. Parce que la plupart des gens vont seulement agir des packages officielles et quand vous êtes en train de débugger des packages, comme quand Robert crée un nouveau Chrome, quand généralement vous allez agir de toute façon l'opération des packages est juste fine. Donc, oui, ce n'est pas un issue. Si vous voulez avoir vos propres packages locales, généralement vous pouvez les transformer par un netwerk, ou vous pouvez aussi les transformer par un SSH. Et la connexion SSH a un code spécial qui signifie que le package est très rapide même quand vous êtes en train de graber des packages partielles. Et enfin, Quox est toujours subjet quand quelque chose change. Donc, j'ai bien sûr que j'ai toujours eu le right quick package at the end. Et on a mis ça en production et la vie était bonne tout le temps. J'ai eu quelques petits détails pour parler de ça, mais juste un second. Donc, c'est l'actual code qu'on a mis en production avec des simplifications. Au début, le concept pouf était que nous serions en place pour chaque package updates mais il semble qu'à le début de la package, j'ai ma full list de packages qui nécessitent l'updating. C'est en fait la full set list de line 1. Et je peux regarder chaque set que j'ai besoin de deux updates. Et quelque chose qu'il n'y a pas de package ou d'indication de choses que j'ai besoin de deux updates, c'est line 7. Si j'ai trouvé un update à ce point je n'ai pas trouvé un update, sorry, encore à ce point. Puis je regarde le nombre de packages et ajoute ça à la prochaine run of locket. Donc, line 15 ici. J'ai ajouté le stamp à la full list. Quand je fais ça j'ai en fait le run locket itself, line 28. Avec seulement ces stamps ce qui signifie que j'ai un single run c'est-à-dire 1000 packages qui nécessitent l'updating. Et puis, tout que j'ai besoin de deux parts d'outre, c'est packageM plus updateLine. Donc, j'ai créé updateLine straight into memory rawData for this packageM. Et, fortunately, Perl a des fonctions qui me permettent d'actualiser les files de data in memory. Et, d'ailleurs, j'ai aussi des instrumentations si quelque chose va bien. Comme pour exemple, figure out pourquoi je n'ai pas trouvé d'informations pour beaucoup de packages. Détails, toujours update. Pourquoi est-ce un problème ? Historiquement, toujours updatePackage est quelque chose qu'est-ce qu'on regarde d'autant d'informations, d'informations habituelles. Si quelque chose change, c'est-à-dire qu'on doit update le package. Comme pour exemple, un file n'est pas exactement le même, il n'a pas le même checksum et il doit être update. Un gros problème c'est que, à l'extérieur, d'informations normales d'informations, et le look at database n'est pas le même. Donc, si vous portez un full packing list, à l'intérieur de le local database et vous essayez de grave-le de nouveau, vous allez avoir un pur garbage. Et le packing list s'est rendu très chiant, mais il n'était pas capable de faire ça. Donc, j'ai décidé de simplifier le code pour toujours update. Faire un check-up d'un package. Mais toujours update packages. En fait, il contient juste un hash d'un full packing list, d'un specific élément. Et vous devez juste checker ce hash d'un update d'informations. Donc, il s'y fit encore. Une autre chose, c'est que généralement, quand vous avez quelque chose de plus vite, vous verrez que tout est slow, encore. Donc, ça s'occupe, évidemment. Nous sommes supposés d'avoir des files dans un package d'un ordre, donc des files qui n'ont pas changé ont été installées à la fin pour un update de plus vite. Et il y avait un bug subtel là-bas. Donc, c'était beaucoup plus facile de voir quand tout s'occupe de plus vite. Et aussi, le prochain bottleneck était qu'en fait, les files sur le système de file étaient un peu de problème. Parce qu'on aurait probablement un système de file slowest dans l'existence. Si quelqu'un peut le kidnapper, il peut le mettre en place pour s'occuper de plus vite. Donc, j'ai fait des choses très horribles pour essayer de optimiser ça. Pour vous donner une idée de la code avant, quand nous l'avions installé, c'était le premier de extracter le whole package avec des files temporaires avec des names temporaires. Il a aussi créé des liens pour filer sur le new package, si ça n'a pas changé. Puis, c'était de retirer chaque partie du package. Et puis, c'était de changer les files temporaires dans les places finales. Le fait d'avoir des files en OpenBSD est très très lent. Donc, en en décevingant quand je pouvais évoquer les names temporaires et juste créer les files dans la bonne location du début, c'était aussi un grand profit. La dernière change était l'interface. Quand tout était slow, vous étiez en train de dire que le package Z n'est pas en train de faire quelque chose. Mais maintenant, vous avez vu que ce n'était pas en train de bouger. Et oui, ce n'était pas en train de bouger. Il s'agissait que quelques listes de packages quand vous décidez de faire un update, vous allez prendre un peu de temps de lire, comme pour exemple la vie, qui est quelque chose comme 100K files ou quelque chose comme ça. Donc, juste évoquer un message à l'utilisateur d'être en train de procéder cette et cette liste de packages ou quelque chose comme ça. Donc, ce n'est pas tout sur les packages de caching. Oh oui, cette partie. Il s'agissait d'apprécier les gens de créer des packages à la fin de créer des packages. Vous pouvez faire ça pour peut-être deux ou trois semaines. Mais plus tard, vous l'aurez oublié. Donc, vous devez automater. Donc, c'était assez facile de faire. Ce code juste le fait. Si je suis en train de créer toutes les packages des portes 3, alors je vais aussi créer Quicks-Adviend. Et c'était la première version, un peu de MacGyver version. Je l'ai fait un petit peu différemment comme ce jour. Vous pouvez actually annoter le package pour être construit plus tard, avec dpb properties. Right now, you only have Quicks, and we'll probably always only have Quicks. But if you're building everything, if you find out that you have a package that is supposed to be later, then you're going to build it at that point instead of earlier. Spoiler alert, it means that instead of being completely synchronous when you run a dpb for the full port 3, you're going to wait maybe one or two minutes at the end until it's regenerate Quicks. Acceptable. And second part of the talk, which is a bit shorter. This code is a bit old, but this one, it means I've written it something like 20 years ago. And there were some experiments at the time, which did turn out quite well. And some of the stuff which is a bit outdated and need suppressing. Plus I regularly run into people who say, hey, we don't understand your code, we would like to help, but yeah, it's quirky, it's complicated, we can't do anything. So, I think so I've started actually removing your stuff and killing it and trying to write better comments about some stuff that was a bit icky at first and document stuff that I found would work really well for me. One big thing that helped recently is that Pearl got a huge update. Who is using Pearl here? Yeah, I got at least 3 of them. Pearl 5.36 is a huge big change in order to at least people to help you. There have been some over interesting advances, but nothing as good as that one. So Pearl gets new features from time to time. For instance, Yada Yada, look it up, I don't have time to talk about it actually. And sometimes they do stuff that's not so great, like they tried to add something that looks a bit like pattern matching from Mochamel and shit like that. But they did some big mistakes, so it was experimental for a few years and they did good to remove it. So Pearl is actually several languages at once. You can activate some features by saying you are using this and this version. One big problem for us, as far as production goes, is that obviously you can't use experimental stuff. Because yeah, sure, we started using given one and oops, it's no longer there. You're going to have to rewrite everything. So Pearl actually gained prototypes from normal programming languages except they didn't call it that. Prototypes in Pearl are something entirely different. They used to create syntax that's similar to the base language. They called that signatures instead. So that makes things incredibly confusing because in Package Land we already have cryptographic signatures. We've got update signatures and now we've got signatures on Pearl. So yeah, prototypes for normal languages. Basically, it's very simple. It's just the thing that you're used to in languages like C, C++ and things. You can actually name parameters for having to pass them at underscore and grabbing them later on this function. This is absolutely useless, more or less to the experience Pearl programmer. But it means that if you try to enlist new people into working with you, suddenly it becomes much simpler because they have way less of a learning curve when they try to do stuff. How much time do I have? Ah cool, let's mix up between prototypes and signatures. If you already have prototypes or style Pearl in your code you also have to annotate them to be able to use a new version. But after that, all you need to do is you need to just name your parameters within the function declaration. So every prototype needs to be ambiguous. You need to be careful about code that actually calls over code which can be written like this here. En personne dollar code you need to put parentheses at the end of it because en personne dollar code means something else now. And also there are some yeah, something that I seldom use anyway. Which is that you need to use the arrow version of actually calling object methods with this. So detail. So this way of calling functions using just en personne we would in a parenthesis it's actually useful it's what called forwarder in most object oriented languages it means that ok I have this method and actually I don't want to implement it here. I'm just going to forward it somewhere else and I don't need to care about parameters at all because they're going to give the exact same thing. So this is the only case in my code where I actually don't use the new signature syntax because all I'm saying is this is not the function you're looking for look elsewhere, you've got the full implementation you've got the full prototype there and you don't need to worry about details. All I did is that I added a comment anybody cares to guess why as a comment there, let's say forwarder simply put it's because I want to be able to grade things I want to be able to check wherever I forgot to add prototypes somewhere and there are exactly two cases in Perl where you don't need or want to add prototypes forwarders and signalanglers signalanglers it's because the syntax is a bit fuzzy we don't quite know how many parameters we're going to have so when in doubt you leave it with the prototype so the indirect syntax stuff yeah it's just an issue with built-ins they had the almost small talk way of calling objects where you first put the method then the object name then the further parameters and they still used for instance, you have objects that looks almost exactly like the base syntax of a system, like you can have an actual filander in Perl which will work as print $fh and you can have an object that looks like a filander which will be called exactly the same so they see something they are slowly moving away from so that the parser gets a bit simpler and less C++ so speaking of C++ as usual in Perl parameters scalar parameters start with $ you can have a news parameters by just removing the name and you can have default parameters by specifying a value if you're used to C++ that's almost exactly the same you can also have lists which means that you're going to write scalar parameters when you're going to write something that starts with a net and obviously it will slurp every remaining parameter or you can even have an hash by using a percent which means that you will check that you have the right number of parameters and that's about it, that's as simple and as intuitive as that as far as having Perl be intuitive goes 5 minutes or so so the old way for those of you familiar with Perl of using hat underscore is deprecating if you have a routine that has the signature and you are trying to use hat underscore then Perl will be very unhappy about it you might wonder why the name reason is that with name parameters it's obvious that there is an opportunity for optimization like if you have a routine that has name parameters then almost certainly you don't need to actually fill robots underscore with some parameters so here Perl wants you that they haven't decided yet or still make it do something so in the end you don't mix both and this is by the way this is how I found yeah this is where I found that calling dollar code without parenthesis wouldn't work anymore because Perl would want me that I am using our bus underscore even in an implicit way so classical Perl code which is a bit longish yeah takes two slides after moving to prototypes it looks almost like your usual programming language so I get new victims I can probably trick new students into looking at my code and trying to improve it which was the goal of the loop or season developers report bugs possible so so so there were some best practices to find in particular when you have un name routine and you are doing object oriented stuff you need to find a way to put the documentation somewhere turns out that just documenting the code actually works instead of trying to awkwardly put names into commands on the proper line one small problem is that it took maybe two months to correct everything because there are some situations where having an extra parameter or missing a parameter won't happen in every case and you have to actually run this part of the code to be sure that everything is good and also if you have anonymous subroutines Perl is still pretty shitty telling you that something went wrong like if you look at the second call you got an anonymous subroutine you don't know where it is you just know that you don't have the right number of parameters also there's the fact that I wasn't too clean about doing things sometimes I have routines that take a variable number of parameters because you know the best class for its constructor it needs two parameters but I have a derived class that requires something more so sometimes you don't even bother mentioning the third parameter but as soon as you actually get prototypes you need to make sure that everything is mentioned and even Perl itself has issues with that like signals normal signals take exactly one parameter which is the number of the signal but you have some pseudo-signal code in Perl that triggers when you are warning or dying and that code can have any number of parameters so making sure that everything works each and every time is a bit complicated so in some cases I decided to delay the actual solution for later like you slurp all parameters and yeah we will figure it out later but I find it best to try to fix it along the way as soon as possible so that ten years down the line we still don't have legacy code that doesn't know how many parameters it has one cool thing you can do for which is impossible in C++ but works really nice with Perl is that sometimes you don't actually know what your default value is going to be at a given site maybe you have to call three methods until you end up with object that is actually owning the default value and you can do that really easily with Perl because you will just say ok I have maybe one extra parameter or not so you declare it at the top level with a list and you pass the list along and when you end up with the actual method that needs to say ok I don't actually have anything here and I need to create a default value then you can do it at that point which is really cool so yeah I'm actually using it here like I have read from file grabPayList grabPayList is not supposed to know about packing list so instead of having to ask packing list for what's the default code to run when you're trying to grab a packing list from somewhere you can just say ok there is a list that might contain some code and when I get to the actual packing list reading information then I will decide what the default value is this is something that as far as I know is not possible to do simple, as simple as that in any other language like I said we are gripping so all my methods now have signatures, apart from forwarders and signal learners and both of these are notated with a comment so I can't miss anything unfortunately this is something of a limitation of value because right now signatures are just fine but some metatools introspection tools in Perl don't support them like Perl Critique for instance is going to just barf over signatures as you can see from those slides stuff like pigments also doesn't like signatures at all it looks like shit but apart from that it's just fine one thing I would love to do after that is figure out if I've called everything in my code again there's some code that doesn't work very well I've tried playing with double cover contrary to Perl Profiler which is amazing the coverage tool is complete shit it breaks very badly on Package Ad and Dpb in various cases as far as I know the main issue it has is that it's really uncomfortable with code that changes identity and I've got privileged separation all over the place in both Package Ad and Dpb so devil cover is not at all transparent and all this code will break in various ways when you try to do coverage on it I would like possibly somebody to look at because right now it's completely broken if we can do that we can probably do some more optimization in Package Ad and Dpb and implement some more features but I think I'm about run out of time more or less so it's time for some questions was it too complicated so yeah I'm still going to answer anyway why won't I rewrite it to Python there are several reasons for that the first reason is that we don't have Python in the best system because Python is not in the best system because it's the wrong license because there was no questions so why not and there is a deeper reason which is that one I don't like Python and two it's way less expressive in Perl for this kind of thing like in Perl you can do programming object oriented small talk style and they have exactly zero idea you can do the same thing in Python and the other reason I hate Python is because it's opposite to everything that I believe like they have decided to take a language and dub it down until it's available for everybody and every idiot can write Python code that works more or less but we can do magical stuff with it and I like to do magical stuff from time to time after all it's still hobby you know from time to time as well any other serious or non serious questions