Today we are going to discuss the linker algorithm. We have seen the linker and its specifications in the last video. At the end of this session, students will be able to demonstrate the steps involved in designing a linker. When we look at the background, we see first the steps for execution, which include translation of a program, linking of the program from other programs needed for its execution, relocation of the program to execute from a specific memory area attached to it, and finally loading of the program in the memory for the purpose of execution. Here we see the schematic of how the procedure works. A source program is given to a translator which produces an object module. This object module is given to the linker for information that is required for linking, and a binary program is produced by the linker which is loaded by the loader into the main memory and data is supplied to it to produce the results. Let us now think and answer what is the information present in that object module that is input to the linker. We once again revisit the working of the system software where a source code is given to a file processor and is given to a compiler or assembler to produce the object file or the obj file, which is given as input to the linker and the loader loads the binary program produced by the linker into the main memory for execution. This object module contains all the information necessary to relocate and link the program with other programs. We have already understood what are the conditions of relocation in our previous video and therefore object module consists of four components a header that contains translated origin size and execution start address of a program P. A program contains a machine language program corresponding to this program P and a relocation table reloc tab describing the instruction requiring relocations and each entry containing the field of a translated address of the address sensitive instruction and the linking table link tab contains information concerning public definitions and external references. A linking table has three fields a symbol which has a symbolic name type which is a public definition or an external reference. A translated address if public definition or address of the first memory of the word allocated and if it is external reference then it is the address of the memory word containing the reference of the symbol. Let us first understand what is done in relocation therefore we treat this algorithm separately as a relocation algorithm. The program linked origin is different from that which is produced by the linker command. Therefore for each object module we have translated origin is equal to translated origin of the object module. The object module size is the size of the object module. We apply a relocation factor and find out where the program has to be relocated. We read the machine language program in the work area which is an example program and we read the relocatable table of an object module and for each entry in the relocatable table we have translated address assigned to the address of the relocation entry and address in the work area assigned to the address of the work area plus translated address minus the translated origin. And then we add relocation factor to the operand address in the word with the address in the work area. And finally the program linked origin is assigned to the program linked origin and added to the object module size. When we talk about linking let us first understand the requirements. All program units are translated separately. All sub-programs call the common variable reference required for linking and programs are nested in the main program. Procedure reference do not require linking. They can be handled using only relocation. Built-in functions require linking and the linker processes all object modules being linked and builds a table of all public definitions and load time addresses. Now we go for understanding that linking also requires a name table which contains the symbol name for external references or object module and linked address for public definitions that contain link address for object module contains the link origin. Therefore most of the information in the end tab is derived from the link tab entries with the type public definition. The algorithm for linking consists of program linked origin is assigned to the link origin which is got by the linker command and for each object module t origin is equal to translated origin of the object module size plus the size of the object module and the relocation factor is then calculated and assigned to the program linked origin minus t origin value and we read the machine language program in the work area and we read the link table of the object module. For each of the link table entry with the type public definition we assign the symbol to the name and we assign linked address to translated address plus the relocation factor which we have calculated and we enter the name and the linked address in the end tab. We enter object module name program linked origin in the end tab and program linked origin is assigned to program linked origin plus object module size. For each object module now we do t origin is equal to translated origin of the object module for each link tab entry with the type is equal to external the address in the work area is assigned the address of the work area plus program linked origin minus linked origin plus translated address minus t origin. The search symbol in the end tab and copy its linked address add the linked address to the operand address in the word with the address address in the work space. As an example let us consider for an instruction requiring relocation IRR it is set to the instruction that performs relocation of the program. So our steps include calculation the relocation factor RF add it to the translation time address for every instruction which is the member of instruction requiring relocation. For example the relocation for a particular example program is 900 minus 500 is equal to 400 and IRR contains the translated address 540 and 538 which are instruction and reading of A. The address is changed to 540 plus 400 is equal to 940 and 538 plus 400 is equal to 938. Here we are adding the relocation factor 400. For the previous given assembly program object module contains following information translated origin given as 500 the size being 42 and external string being added as 500. Therefore for the machine language instruction which is given we now have the relocation table which looks as we have shown here and the linking table as we have shown here having external and public definition addresses. A loop is not here as it is not a public definition. Let the address of the work area be now 300 while relocation of the object module relocation factor being 400 for the first relocation table the address in the work area is 300 plus the 500 minus 500 which is 300 and this word contains the instruction of the read A. It is relocated by adding 400 to operand address in it. For the second relocation table entry address in the work area is 300 plus 538 minus 500 is equal to 338 and the instruction in this word is similarly located by adding 400 to the operand address in it. All these calculations are done and then we go while linking the program P the program Q with the origin 900 as shown here and tab contains the following information the work area being 300 then link tab of alpha is processing during the link address in the work area as 300 plus the 900 minus the 900 plus 518 which minus 500 which is 318 hence linked address of alpha is 973 and this is copied from n-tab entry of alpha and added to the word in the address 318 for our references we have used thank you


Participants page filters in Moodle 3.9. Thanks to this Moodle uses association funded project, users can now benefit from significantly improved filters on the participants page with multiple conditions available. Here, our teacher is on the participants page and can select from a number of options. He chooses groups and can match any or all. He's then able to add another condition. This time he selects keywords and inputs a family name to locate members of the same family in this course. With a third condition he can find out which members of that family have been inactive for more than five days. Again, he can match any or all of these and then applies a filter and finds two participants. He can easily clear the filters to start again. To summarise, a Moodle uses association funded project brings improved filters on the participants page including multiple conditions.


Ok, donc, merci d'être venu et d'être réveillé à l'heure pour ce bif. Il y a quelqu'un hier soir, qui m'a dit qu'il y avait quelque chose... J'aimerais vraiment venir au bif, mais en fait, je n'ai qu'une chose à dire à vous. Donc, si je dis que je peux dormir, il n'est pas là aujourd'hui. Je vais protéger sa identité. Donc, originalement, quand Zack a commencé l'initiative d'un DPL, je pense qu'il y avait trois grands axes de motivation pour ça. Le premier était de partager l'initiative d'un DPL, pour que ce soit plus de travail pour le DPL, et plus de tasks qui sont généralement fallus dans le domaine d'un DPL. Plus qu'un d'eux qui doit vraiment être fait. Et aussi, il y avait l'idée de donner des candidats d'un DPL perspective afin de découvrir l'initiative d'un DPL et d'exprimer eux-mêmes dans le processus. Est-ce que ça reflète ce que vous avez dit ? Totalement. Il y avait aussi de plus d'inspiration sur ce que le DPL fait, et d'actuellement montrer ce qu'est-ce qui se passe. C'est peut-être un sub-point de la deuxième, mais oui. Merci. Oui, mais ça ne va pas se faire plus. Je vais essayer. Je me sens frappé de toute façon. Ok. Donc, j'ai essayé de passer par ma liste de currentes et de prendre des items qui pourraient être faits par quelqu'un d'autre. Pour quelqu'un d'autre, c'est vraiment facile pour quelqu'un d'autre de les faire. Pour quelqu'un d'autre, c'est beaucoup plus difficile de voir si quelqu'un d'autre pourrait le faire. Mais, on va voir. Je vais juste passer par les items très rapidement afin de savoir ce qu'il y a dans les descriptions. Donc, la première. C'est ce qu'il y a, c'est la bibliothèque infamuse qui a besoin de jouer un DPD. Nous avons un conseil légal pour l'autopacage dans Debian. Le package est prêt. Il faut être réveillé par les masters de FPMAS et puis le CFC, pour que ça puisse arriver à Debian. Et c'est currently blocked dans ce stade pour les dernières 3 mois. Donc, il y a un peu de bouquins. La deuxième, c'est qu'il y a un nouveau site de NM qui a été développé principalement par Enrico. Nous avons le DM Workflow qui est complètement séparé. C'est possible d'essayer de mettre le DM Workflow dans le site de NM. Nous pouvons faire ça. Il y a plusieurs choses qui sont relatives à la délégation. Donc, la team de relance n'est pas délégée. C'est possible d'être délégée pour que ses pouvoirs soient plus expérimentés comme... Par exemple, quand ils décident de retirer les packages de test, c'est des choses qui peuvent être très controversées dans un projet. C'est sympa d'avoir un moyen de dire oui, ils peuvent faire ça. C'est le même pour la team de trademark. On a un nouveau team de trademark. On doit préparer... Il y a quelqu'un qui doit préparer la délégation. On a des idées qui sont faites, mais elles doivent être considérées. Il n'y a pas d'activité de développement autour de la délégation. Donc, un call for help devrait être préparé et posté pour approprier la liste de mail pour essayer de recréer une volonté pour cela. Nous devons juste écrire la description du travail et travailler sur ça avec Kibi, qui est l'un des plus actifs de l'AI. Le team de Debian Events... J'ai été dit que le team de Debian Events est un peu MIA, donc on doit voir ce qui est le problème, voir ce qui pourrait être fait, etc. La délégation de Press Team a besoin d'une date. Il y a quelqu'un qui peut être convaincu d'augmenter l'activité, peut-être. Ce n'est pas clair. Relé aux discussions de Code of Conduct, il y a une question si le maître de liste doit être délégué. Si ils font la décision de banter quelqu'un de la liste et ne sont pas délégués, c'est un peu étrange. Peut-être que ce n'est pas nécessaire, mais nous devons penser à ça. Il y a un gros set d'items qui sont des contributions. Je pense que c'est quelque chose qui est très important pour le projet. Donc, les meilleurs sont... Vous avez des questions ? Je pense que le maître est plus explicite que pour le premier set. C'est OK ? Les meilleurs sont vraiment packaging-related. Depuis que j'ai originalité les tutoriels de packaging, j'ai des items qui sont liés à ça, mais c'est clairement quelque chose qui peut être... Le DPR n'a pas besoin de maintenir la documentation. Et puis des items de valeur. J'ai fait des statistiques d'utilisation avec FTP.be, il serait intéressant de confirmer ces résultats avec d'autres logs. Donc, il y a Amazon CloudFront, qui est utilisé comme partie de la nette de FTP. Et aussi FTP.mx qui est offert pour les logs. Je dois... Le DPR a besoin d'avoir ou quelqu'un qui a besoin d'avoir le DPR paragraph dans le report. Je pense que c'est plus d'un paragraph, mais... Je n'ai pas regardé ça. Le DSA tend à avoir beaucoup de petites expériences, comme acheter des câbles ou des services de shipping. C'est un peu stupide, que chaque fois qu'ils font ça et demandent pour 100 euros, ils ont besoin d'avoir l'approval d'DPR. Donc, ils demandent si nous ne pouvons pas avoir de plus de 200 euros d'expérience de plus que 200 euros chaque 7 jours. Donc, ils n'ont pas besoin d'arrêter quand ils commencent à travailler sur quelque chose pour l'approval d'DPR. Et, bien sûr, ne notifiez pas les auditeurs d'DPL que ça se passe. Mais, dans le meilleur cas, ça veut dire qu'ils demandent 200 euros et quelque chose qu'on ne veut pas. Donc, oui, ça doit être créé sur Dash Project pour que nous puissions avoir une discussion sur ce projet. Et puis, quelques médias une médias spécifiquement. Dans le package LXI, il y a un template d'Adebian qui est assez différent de ce que l'upstream donne, et apparemment, je suis très heureux de ça. Et j'ai préféré utiliser le package Ubuntu. C'est-à-dire que ce template a été broken avec Zee. J'ai peur. Donc, quelqu'un doit parler d'un maintainer LXI pour voir ce qu'il peut faire. Oui. Donc, vraiment, je pense que ces tests sont assez différents dans la nature, et pas tous peuvent être adressés de la même manière. Donc, les règles d'une autre personne sera d'avoir un draft et que le draft soit modifié et envoyé au DDA. Par exemple, pour les délégations, ce n'est pas le cas.  Well, the last two are quite similar actually. So, there are more people in the room than the sum of people who ever attended DPL helpers both. So, the obvious question is, what are your reasons for not taking a DPL helpers task yet? And then, how can I help you pick one? So, if the answer to the first two questions is not possible, I would never do that. Maybe we should think about reducing our expectations of what the DPL does. That's also something that we might be a good thing to allow people with more diverse, personal day job et stuff like that to apply for DPL. Because we are kind of a shortage of people in French academia who need to run for DPL. So, and well, maybe one question related to that is maybe we could just, the DPL should just try harder to offload work to the relevant teams. The problem is that the relevant teams are usually teams that are already quite busy with lots of other things. So, it's not really just moving the problem to the next step. So, maybe start with that. Who wants to comment about that? So, who was? So, I guess I'm fairly typical in that I'm vaguely interested in helping but I have 46 other things to do and I don't really need to do any DPL tasks. I'd like to help but mostly I'm too busy with all the other things I'm supposed to be doing already for not even necessarily just for Debian. So, I guess that applies to quite a lot of people. So, I don't really have any answers. I'm just saying that's why I haven't done anything yet. So, I kind of turn up and listen and see what's going on. I've taken more interest in this than I used to for the last seven years. I have actually come to this at least one IRC meeting. So, I'm approaching actually doing something maybe. So, for some of the tasks, I don't see why they are listed as DPL tasks like the packaging tutorial things or the ITP template. Yeah, well usually for many DPL tasks there's no strong reason for the DPL to make them but if the DPL doesn't do them, well usually it doesn't happen. So, it might be that they are not important enough but I think that most of the people in the project agree that we have a problem attracting new contributors and that we could do better. No, no, no, I'm not saying those are not tasks that should be addressed. I just don't see why they are DPL tasks. Maybe they are just things that we should do but anybody can do them. Yeah, well the point of having them there well, that's ... ... ... ... because they are basically things I'd like to keep an eye on and make sure that things progress clearly in terms of in terms of priority what's there about teams, I'm going to try to do that before working on working on HML version of the packaging tutorial, it's just... I mean, I actually do help with the trademark, but from this perspective, if you had asked, hey, I need someone to do DPL work, that's a big and scary thing, but you asked, is there someone to help with trademark, and that's a clearly defined sub-problem, and I thought, yes, I'm able to do this. So it's maybe even a little bit in the same direction. DPL helper tasks are big and scary, and clearly defined problems of domain X are not as scary if you're somewhat familiar or happy with that particular problem domain. So maybe that's one of the approaches to better define the problems and simply put them out there, these are the things which are currently open, and they may not even be DPL helper tasks, they may just be Debian tasks, which no one actually does at the moment, because if I understood you correctly, you more or less said it needs to be done, so you just pulled the task to you because somebody has to do it. So yeah, I've tried to describe tasks, well, not really there, I was to keep it short, but in a quite actionable way so that people understand what they would be supposed to do if they agree to do something. One problem with that, so, is that from my point of view, well, this takes a lot of time, everything seems related, and actually, this is not the most fun things to do. I think a mix of this is more interesting from my perspective than finding people to do all of that and then get stuck with this myself. So, those are probably harder to split into quite large amount of work that could be transferred, because individually it's quite easy to send a call for help on DDA for that, and then wait for people to volunteer. So, sending a call for help for, and sending a call for help for someone responsible for preparing delegations for the next six months, that's a bit quite strange as well, it might not work, I'm sure I would get volunteers for that. I think an important point here is that on one hand, the role of the DPL is something people look up to, it's a cool thing you do, you are the representative of the Deven Project and so on and so forth, but on the other hand, it's also a kind of a dumping ground where we as developers push stuff which is not funny to do and which is not something we would like to work on. And in some ways fine, actually that's part of the constitutional definition of DPL, it's sort of decision garbage collection, it's only decision because it's also some sort of action item garbage collection. And the important point here I think is that in Deven, we do ourselves as volunteers a lot of stuff which other projects have other way of doing, usually by having some corporate support, by having some paid stuff for this kind of stuff. So I think here what's at stake is really, are we really able to be sustainable as a project and work on this kind of stuff or not? If we want to be, and I think it's truly important to be independent, so if we want to be, we need some sort of collective awareness that this stuff needs to be done. So there has been in the past DPL tasks that took like four years, five years to complete, but there was stuff on which the project was blocked on. So I guess the question is, how do we made people realize more often that everyone need this kind of stuff to be done but it's just insane to think that one person at a time, the one who is elected as DPL, can reasonably make progress on all of them. So I think the question is, okay, how do we collectively realize that we need progress in this and then how do we attract volunteers to work on this? I think it's not only a matter of, okay, it's not funny to work on that, sure. I think it's really trying to make people understand that we need progress on those as a project. So I'm sorry I missed the beginning of this, but have we considered paid administration for some tasks? I mean, has anyone thought about how that might work? Are there jobs? Again, it's a question of job divisibility. Is there a little blob that you could actually give to somebody? And I guess it's the same problem as paying developers, tricky in a project with a culture like this. Well, if you start going into that direction, the other problem is that you get less diverse on who would be interested in that work. For example, I cannot easily give up my current position. Well, I could try, but probably the process of giving it up requires at least one year due to French administration. I wasn't suggesting that we paid the DPL. I was suggesting that they had a paid surf, a PA, whatever, that kind of concept. And that person stuck around, he might get some useful continuity out of it. I don't know, it's just... It's not very deboutish, but... I just wonder if you've already decided it's nonsense and we definitely shouldn't do that. My problem with DPL helpers is that we see lots of administrative work mainly, so sometimes it's not even much. I mean, I could probably spare the time to go and ask the David Evans team what's going on and report back to you. But, well, when I see the DPL, I elect him based on a vision and some direction where I want him to steer the project too. And, well, if I want to help the DPL, I would like to help him do that. Donc, je veux dire, si vous ajoutez sur votre liste peut-être d'études, comme des discussions sur conduct, ça pourrait être intéressant pour moi, mais ce n'est pas vraiment ça. Donc, peut-être que vous devriez broadenir la liste de choses parce que même si... C'est-à-dire que des choses administratives ne vont pas être dans le moment. C'est-à-dire que vous avez l'opportunité d'attracter les gens dans votre team pour aider vous à faire quelque chose d'intéressant. Je pense que nous sommes... dans les élections d'DPL, en fait, on n'oublie pas que ce que la DPL fait n'est pas aussi intéressant et qu'elle doit démontrer une capacité de travail sur ces choses-là. Et on n'évaluera pas ça dans les élections d'DPL. C'est vraiment brouillant. On peut arriver avec quelqu'un qui a une belle vision pour le projet, mais on ne peut pas faire ce genre de brouillage. Et ça serait vraiment très important pour Debian. Oh, je dis ça, mais c'est... C'est-à-dire que pour quelque raison, je ne pouvais pas dédicier autant de temps qu'à Debian. Les choses que j'ai vraiment besoin de faire sont la plupart des choses qui ne sont pas vraiment importantes. Mais elles sont très importantes et je dois toujours faire ça. Si j'ai besoin de prioritiser. Je ne pense pas que ce soit un DPL qui donne beaucoup de belles idées sur le projet et de pousser une vision sans faire le travail actuel. C'est une chose positive par le reste du projet. Et... Je voulais juste dédicier la partie intéressante. Donc, vous devez dédicier la partie intéressante. Je dois dédicier la partie intéressante. C'est pourquoi je suis intéressé à dédicier ça, mais... Je voulais aussi dédicier que... En Debian, je pense que certaines personnes sont belles en poussant leurs propres idées et leurs projets. Certaines ne sont pas si belles à ça, mais elles ont encore belles idées. C'est seulement la partie poussant qui est la plus récente. Et je pense que c'est vraiment important de dédicier que tout le monde soit bienvenu pour s'y arriver à une meeting d'aile d'aile d'aile d'aile et, bien, décrire leurs idées et poser des réponses. Et je pense que avoir un endroit où vous pouvez avoir des réponses sur vos idées et de pousser leurs projets c'est assez utile pour beaucoup de projets. Ce n'est pas vraiment ok que, en Debian, vous avez une bonne idée. Vous devez être capable d'être bon en poussant pour atteindre les compétitions. Peut-être si vous avez un type de bug tracker pour ces projets et que vous puissiez les relier en quelque sorte. Peut-être que, dans vos bits d'DPL, vous ne pensez pas qu'il y a encore des problèmes et qu'il n'y a pas de volunteer pour ce mois. Mais, bien sûr, vous êtes au risque de juste générer des noises qui sont ignorées à un certain point. Mais, encore une fois, ce serait d'avoir l'air qu'il n'y a pas trop de travail à faire. Je pense que c'est une bonne idée parce que, vous pouvez partager votre liste sur d'EDA mais je ne pense pas que quelqu'un d'autre soit comme ça. Mais si vous préparez un petit peu le travail en termes de ce qu'est le next step dans ce projet spécifique et si vous donnez une introduction plus longue pour expliquer le contexte et tout ça, parce que pas tout le monde comprend ce que ça veut dire pour parler d'une nouvelle web site. Ils ne connaissent pas le tracker avec une explication plus longue et le next step. Donc, même si vous n'avez pas le tout le tout l'item, vous pouvez au moins faire le premier step. Et ça veut dire que vous avez un log. Donc, si je prépare un e-mail, je peux lui demander d'y répondre à la porte de bourg et quelqu'un d'autre peut le prendre plus tard. Donc, un issue n'est pas tout qui peut être discuté publicement. Oui, c'est vrai. Mais au moins, à la fois, les meilleurs ici semblent qu'ils se battent. Probablement. Oui, public, non. Mais pas le next step, pour exemple. Oui, pour certains, le next step c'est d'essayer d'accepter les gens d'accepter quelque chose qu'ils n'aiment pas. D'accord. L'accepter du consensus est often done in public, sometimes it won't work, so you can always say... It's a fun about people more than about technical stuff. So, but, yeah. There are people that support it. It's true that I could try to be a bit more verbose about what's the current state and what's the next action. Yeah, but for example for those two we have a draft like items, list of items for the delegation. It needs to be rewritten into proper text and then go through the teams respective teams that can provide feedback and iterate on that. That could happen. Well, even if you have only the bug report with a link to Titanpad draft, it's still better than the current status. Thank you. I was suggesting to have a public to-the-list or maybe not a whole to-the-list but the same way I said. Focus on some items you want to achieve in the next month. So it's usually one nice way of having things done is to not do it yourself. It's just so abuse or not do it at all, actually. Maybe I'll read the line right to go for help for the DI team. Maybe you could just send a mail very short to the DI list and say, well, the DI is not having much attention at this time. So if you prepare a mail and send it to Debian Devil, just offload and by saying this it's also another thing I wanted to say DPL helpers is a bit scary. I wouldn't get into the whole thing. I don't want to attend meetings every week about but if there's some items like having more people in the DI team it's something I could be interested in saying the DI team needs more help and I would send a mail I could try to push more of the work to the 11 teams but for DI the problem is they are too busy so like many people or teams in Debian they are past the point where they are able to ask for help themselves Yeah, but if people who are overloaded sometimes need someone to say you can't do it yourself anymore and maybe if you just send this very small mail it would trigger the thing Yeah I was just wondering about the concepts as was mentioned a few times there's a difference between the leadership and the administration they're quite closely tied and that makes it difficult to separate but you can be good at administration you can be good at leadership and we haven't got that many people who are great at both and that's a lot of time so could we try having the Debian administrator as well as the DPL if we made another position would that help kind of officially or is that not really because you just spend all your time communicating it would have to be someone you get on with I guess otherwise it wouldn't work it would be interesting so I've always been a bit surprised no not surprised I see there's a bit of a conflict of connections that we are electing someone to be our leader but most of what we expect them to do is be as an administrator however the leader has no teeth without the administrative powers would anyone listen to someone who just made a lot of noise saying we should do these cool things we've got some crazy people who do that on the lists all the time and we ignore them to some degree yes ah so Bookie said the authority comes from doing all the boring work and that's probably true but we but maybe it doesn't make sense to split administrator from leader because they are totally different things suited to different people but in such a case you have the problem of how to determine who's the administrator and how long will he stay the administrator because if this person is just like our secretary going on and on and on for years to be the de facto administrator and the de facto power that be ah this person gains more and more power both implicit and explicit over time so this may be a real risk as in even if this person doesn't even intend to for this to happen but still you kind of it doesn't feel right that's a short version so you could deal with that by effectively having the administrator come with the DPL par for that period I mean continuity is actually useful in an administrator but as you say there is the problem that they'll slowly acquire stuff which could become an issue after a while I don't know I guess we press on with this helpers concept for a while and see whether we get enough traction in general assistance distributed through everybody which seems a better concept if you could make it work and if it's still not working in another year or two then I think we have to think harder about another position yeah yeah we have had DPL assistance in the past we're also going to charge but I'm not sure of all the split of powers work between them right so there was a point that we discussed that you forgot to mention in the beginning was actually that the idea of a DPL helpers team was actually to have more continuity than a single year and your comment now made me remember that because indeed the problem with DPL assistance is that if they are tied to the same period of one year which is relatively short to learn how to get around so then you still have the problem that every year you restart from scratch and with inertia and common mistakes and whatever so that's actually part of the reason why in hypothetical the more stable DPL helpers team would need to be longer than DPL election term Jacques did you read the DPL archives about always a second in charge and the DPL interact in the past I think partly yes so I think the question interested in is how did they work I think the only time I remember only the last time and I think they both rated DPL and they just coordinated via the same others I haven't checked the AJKs in the past so well you have a whole list of tasks how to get on now is it how do you intend to polish them in some way so people can grab them not just today where you you could shout and say yes each one here takes one shot so what I've been doing during the last DPL helpers meeting the one before I think was to publish actually that to-do list which actually is quite a lot of work because rewriting your to-do list that you write using more direct words into something that you can put in a in a Gobi document it's like at least one hour of work to write this down and find the but yeah so yeah I'm trying to so DPL helpers happen once every two weeks and in the future I plan to continue to publish that kind of to-do list probably a bit more verbose feel free to attend the meetings and ask for details about some some items so one of the question is in DPL we tend not to do ISE meetings that often that's not really something that is really common in the Debian culture except for some teams like Depp Comfort got him is it a blocker for you that meetings happen may I see at a specific time that you have to be there if you want to participate because we could try to be better at moving that change the time each time so that everybody can participate or move try to move to mainly these discussions nobody feels strongly about that well it's not really about problems about ISE it's about holding the meetings on ISE at a specific time of course there is the usual problem that these groups end up self-selecting and the people you've got here or people who found these meetings happened at times that suited them other people might have taken one look at DPL helpers but decided maybe get DPL it's more interesting because they never got involved so just a general comment I feel personally pretty strongly about the usefulness of a periodic ISE meeting especially in this case because it's the place where you have tasks that have been lingering for a long while so having periodic reassessment of are we doing progress or not is pretty useful but your mileage may vary so I fully agree with that but we could do that via email as well I mean I send monthly emails to DDA we could have the same kind of emails sent on a regular basis I agree it's better to have ISE meetings for that reason I guess it makes sense to have the ISE meeting because it's just easier to sync up quickly but there's no harm in having a backup place on email list where you can basically go through issues a little bit earlier and then do the actual more involve discussion in real time maybe it would even be a possibility to put the helpers discussions on to WMD well or on to WM private to kind of force people to keep seeing those issues popping up so not to move it away to a place where only those people who really care and who really decided yes this is not scary enough for me to run away see this but so everybody continually sees okay there is stuff which needs to be done they may need help here hey that's something I can do yes I wanted to say there's also the technical committee who's doing regular meeting in the same way but I really feel some difference between both because on one side there's a team who's trying to find solution and reach consensus and what's the best way to go forward whereas in the DPL Helpers meeting it looks like more you asking each volunteer individually oh how far are you not so much discussion on their decision making group so while it's useful to ping people I don't think it needs to happen over ISE always at least and if you move part of the management over to DTSN in the backtracking system you can at least also use the owner feature to record with working on each entry well at least some people can help on a specific item without subscribing to the all DPL Helpers infrastructure that's actually a very good point sorry most of the things we did within a travelmark team could be done on the mailing list and it was more or less just reporting back to you what the actual status is what we did and what we came up with and just pinging you that's the actual status what we did a few days earlier on sitting down that's something which is better suited for ISE where you just have real-time communication and the whole team is better than just one of the team but all the other preparation and especially this is the status synchronously and that would probably make it easier both for you and for others someone that yeah well I changed the topic just a question for you for the fun would you consider delegating someone to steer the discussion concerning the code of conduct for example butter I started it would you mind giving him some sort of official advice to try to bring it to a conclusion hmm good question can you can you think of another occurrence of someone being delegated to steer the discussion doesn't really sound don't think we need that I fear that that would be a way for that person to push his views quite strongly doesn't really make sense especially for a code of conduct discussion to put a final point on this if this happens as you said there's the possibility of that person just strong arming their way into the direction which they want instead of trying to reach consensus I just lost my point sorry oh yeah there would be a lot more discussion about hey you delegated or delegated this person why not mini-delegate someone else so you would just if people are aware this person has this leaning or this type of agenda you would just move the discussion about who gets to really decide and lead well I say delegated but not formally in the official sense I mean just like you try to delegate those tasks just so that it will happen so that he you ensure there's some progress made and you can now hey did you do something yeah well one thing that could help with the code of conduct discussion is find a group of three to four people who care about it and would disagree on it for quite some aspects of it and ask them to push it forward together to reach consensus between themselves before it gets too much larger many discussions are difficult to to converge that smells of a working group which doesn't have to be a bad idea but then you have to make sure that the working group keeps and remains open because else you would more or less exclude the rest of the project from a pre-selection or pre-discussion they are fed maybe even foregone conclusions which will probably get quite your assistance within Debian what often happens in Debian is that nobody cares thinks that something is quite important but nobody cares particularly empowered to work on it for the code of conduct for example I think that's the case or that was the case for I'm not sure who to even I'm not sure I'm not sure of his motivation so working on that but he might be feeling very empowered to work on it himself he's pushing it which is great I think a more explicit way of saying thanks for pushing it please continue Yes I guess encouraging him is a good idea because I feel it's going to run out of time after that this will not go further which is a shame because while we made a bit of progress it would be nice to go to the end Ok I think we are out of time so thanks a lot for attending I will watch the video and prepare some minutes for the both probably I will provide the link in my next DDA bits Yeah Yeah I will post the notes there and provide a link to that in my next DDA bits Thank you


In this presentation, we will take a look at the calculation for earnings per share. The earnings per share calculation is useful for people that are analyzing the stocks. And it's very common calculation. So we want to take a look at the earnings per share. We want to say what it does and what it does not do. First of all, the earnings per share can give some kind of implications that aren't exactly true when we think about the earnings per share, meaning the earnings per share by its name would often give us the impression that those earnings would then be distributed to the shareholders, which is not necessarily the case. So earnings per share is going to be useful for analyzing the stock, but isn't exactly what is going to be distributed, almost never will be what is distributed, and can lead to untrue expectations about what the dividends may be. So in order to think about this further, let's just take a look at the calculation, what the calculation will be. We'll start with net income, and then we're going to divide net income by the weighted average common shares outstanding. Now what this means is what we're just doing is we're taking the net income, which is of course the performance of the company, how the company did over the time period, whether that be a month or a year, and we're dividing it. You could think of just basically the shares outstanding. Why do we have the weighted average? Because we're trying to find out how many shares are outstanding kind of average through the time period, and if there were no new shares outstanding or no new shares issued, then it would be the same. In other words, we would calculate this as taking the average or the shares at the beginning of the time period, whether it be year or month, and then the shares at the end of the time period, year or month, adding them together, dividing by two. And what we're trying to do then is find, okay, what's the average amount of shares that are outstanding at any given time? The only reason that would change is if the company issued more shares, something that doesn't happen all the time. We might not think that because shares are being traded all the time on like a stock exchange, but those shares aren't being issued from the corporations. Typically, most of those shares being traded by far are just being traded amongst individuals not being part of shares that are being issued from the company. So in other words, when we think about the shares being issued from the company, it's kind of like we are having an initial, an offering of the shares and that's like the owners investing into the company. We expect that to happen at the beginning of the company and periodically as we have the need for capital throughout the life of the company, but we hope that normally what's going to happen is we're going to have generate revenue, generate money into the company, and then the money should be going the other way in the form of dividends out to the shareholders. So you could think of this basically as net income divided by the shares outstanding for the most part. And then what that means is that we're just basically taking if we had each number of shares outstanding, you could think of it as net income. If we had the cash, if we had just the pile of money, the net income, what we've earned throughout the time period, and the number of shares divided by that, you would think, okay, that just means the amount of money then that the company has earned, they can then be allocated to each share. And so then if we then owned the shares, if we owned one share, you would think that that would be the amount of net income allocated to our one share. If we own two shares, then we'd get twice that amount, each share being proportional. And that's why it all works out nicely as we are a corporation. What this can lead us to think however, is that the net income is owed to the owners in a sense, we are the owners. So you might think, we might think, well, if we have net income, we should be distributing that net income in accordance with however many shares are out there, which could happen. A company might say, hey, we earned this much money, we're going to distribute that money to the shareholders. But that decision isn't necessarily the stockholders or not directly. The stockholders vote for the board of directors, which would then decide how much dividends to give. So the dividends could be whatever the company decides to give in terms of dividends. But this is a useful calculation for us to think about, okay, what was really kind of generated in value. You would think that the value of the stock would go up from a market standpoint in terms of the cost of the stock in some relationship to the earnings per share. That might be some kind of logical relationship or correlation between those. Doesn't necessarily correlate to the dividends that would be given. Why might it and why might it not? Some companies, if they're really established companies and they've been doing very well and they don't need to invest in more capital because they already have all the capital, the infrastructure they need to generate revenue, the business model is set up, and they know how to just make money with it. Then they don't need more capital investment to generate more earning potential. Then they may give a lot of the dividend back because that might be their business model. They're established companies, they're just making money doing what they do. They're already in place and they have a policy of giving dividends based on their earnings. But that's going to be a policy standpoint. A company may be a growing company or have ideas on growing in the future, which would probably include capital investments, investing in more machinery, investing in more individuals and buildings or something like that with the goal of income generation in the future. In that case, even if we had income and we could distribute it, but we may not, the company may decide we're going to hold on to that income and we're going to invest it. Why would that be okay to us, the shareholders? Why wouldn't we just sell the shares and say, you know, you're hoarding the income, I want the money back? Because we're hoping in that case, if we're that type of shareholder, we're not really looking for income through dividends. If we're holding a stock that plans in that format, we're looking for the value of the stock to go up. If they do that, then we would think there's going to be future value going up in the corporation. That will increase the value of the stock price now. And hopefully that would be the idea and possibly lead to income in the future, either through dividends that would then be distributed to us or through the sale of a stock which would increase in value. So this again, very common type of ratio for us to kind of analyze the stock. It gets a little bit more into the type of analysis we would do if we were valuing the stock rather than the type of analysis we will do all the time in terms of creating the financial statements. However, once we start to look at the financial statements, we want to start introducing these ratios because they can help us in the creation of the financial statements because they can point out where there's going to be problems and see and point out areas where there may be errors. So as we start putting the financial statements together, looking at some of these ratios will be very useful for decision making, for putting the financial statements together, for detecting if there's errors, for looking at audits. They're also very useful for my financial statement standpoint, from a financial analysis standpoint, from an investor standpoint for example, trying to determine the health of the business.


Yeah, how are we doing now? Great. Thanks for having me. Like my colleague, Luca, that just spoke previously. I'm from the Open Source Robotics Foundation slash Open Robotics. We have an office here in Singapore, as Luca said, as well as all around the world. So I'm going to talk about an Open Source Robotics middleware framework for health care. I'll get into exactly what we mean by that. There's lots of applications of robotics in health care. The first thing that you think of might be surgery robots, which is great. But there's also many other applications of just logistics and large hospitals are a giant operation happening, and just everything needs to move everywhere else at all times. So I'll talk more about that. Of course, you can't talk very long in robotics without saying we're hiring. We are hiring from many different roles, ranging from robotics software engineers to DevOps to web to build tests that are just a whole software chain that needs to happen. And we're always looking for great people interested in this fun stuff. So let me back up a little and talk about the motivation of why we're doing this big project, what exactly we're trying to do, and how we're going to do it. So when we talk about hospitals here in Asia in general and Singapore in specific, these are very large buildings in large cities, talking like 1,000 to 2,000 bed hospitals. So there's a ton of people involved in the situation. There might be thousands of people at any given time inside the building, all of whom need to be fed, taken care of, given supplies they need. Inputs and outputs all process appropriately. So there's a lot of opportunities for automation to help make these processes run more economically so they can scale to the anticipated needs of the future. In general, there are many different vendors of robots that sell into the health care robotic space. So for any particular size of supply that you're trying to move around, there might be a few choices. But it's very rare for a vendor to be able to offer the full range of supply motions. So whether that's from just little, small medicine bottles all the way up to like a giant cart or giant pallet full of meals for an entire hospital ward, there's a wide range of volumes and shapes and sizes and masses that need to be moved around the facility. And again, we're not even talking about surgery robots here. We're talking purely about logistics or cleaning robots, maybe, or just anything that's not surgical. So just you can kind of block that part of the domain and think more of just sort of facility management, facility processing helping. So we're going to build these systems. We're starting with open source robotics projects that Luca mentioned called ROS, the robot operating system, as well as Gazebo, which is a simulation framework. And we're going to use those then to build up to hospital scale simulation and multi-fleet management. And I'll get into through the next 25 minutes or so what we mean and a little more specific about that. So at Open Robotics, we're the stewards of two large open source projects, the robot operating system or ROS. We've been working on that in public now for about 13 years or so. The first, I think, official version had a number on it maybe in 2007 or 2008. And ancestors go back quite a bit further than that. The domains are on the lower left, ROS.org. And then there's a new and improved, everything better, ROS2.org also happening in parallel. That project works hand in hand with a simulation framework called Gazebo. The URLs are on the lower right there, Gazebosim.org. And then the next generation, IgnitionRobotics.org. And to summarize these big projects in one slide here, what we try to do is to break up the robot software problem into a bunch of small sub-problems. So imagine, like Luca was showing previously in that open source camera projects, you have the device driver node, which maybe can get the raw data from the imagers and then publish it in a standard form of a message that is a kind of abstracted image. And then you can have further nodes that listen to that message, do some more processing, pass on more messages and such. So when you build a robot software system rather than building one gigantic robot binary, instead you end up launching lots of little small binaries that find each other at runtime. So that's the dynamic computation graph you see represented by those colored bubbles in the middle there. In simulation is invaluable in robotics because these systems cost a ton of money. So the humanoid robot on the bottom there, you can see both in the renderings and in the real-world photo, that's a real NASA robot. I don't even know how much it costs. There's not for many of them, so sometimes you don't even really put a price tag on them. If it falls over, it's very bad. So typically it's all like an umbilical, it hangs from the ceiling, so it can't really fall on its face. But yet you want to simulate it going up and downstairs and doing all sorts of interesting postures and things you are not willing to try on the real robot until you're really convinced that it's going to work out. And so that's where it becomes extremely useful to have a high-fidelity simulator. Also, in this particular example, that's a simulated Mars landing site in a simulated Mars lander. Obviously those don't exist. So when you're trying to simulate difficult worlds or extremely expensive worlds, you can use the simulation framework to save a ton of time and money. In the hospital, this is all relevant because hospital facilities, of course, are critical in national infrastructure wherever where they are. So you can't just run arbitrary experiments in them. If you want to see what happens with running different numbers of robots for delivery or different sequencing of lifts or automatic doors, how do you queue for a door, how do you queue for the lifts? Those are experiments that you can't really run in an operational hospital. So instead what we can do is we can create models of these facilities and then run all of our algorithms and test them in this simulation. So to do that, we have been constructing all sorts of simulation assets. So there are all sorts of different roles of people in hospitals, of course, when you go. There's all sorts of different staff, different visitors, different patients with different mobility aids there to help them as well as all sorts of hospital equipment. It's amazing when you start walking around large hospitals, how many things there are that are basically in the shape of a thing on wheels that you push around. It's kind of astonishing. Everything from any kind of diagnostic equipment to basically lots of different shapes of computers on wheels that they push around. COW called a cow. There's cows everywhere getting pushed around. Sanitation carts, that's just a few of them that we've modeled in the picture there. But there's, again, anything that's sort of the shape of a cart that you can push through a doorway, they've got it. So we're modeling all these things so we can simulate them and simulate the motions of the algorithms that are gonna drive their robots around. The mechanical infrastructure, by which we mean doors and lifts are a key part of this operation because large urban hospitals are essentially stacked vertically. So it's very common for a large urban hospital to be 10 levels, several levels below ground, many levels above ground. Where most of the infrastructure to run the facility and to provide for the patient's needs is in the, oftentimes, the basement levels. So things like the central kitchen, the central surgical supply sterilization areas, the laundry, imagine how much laundry is produced in a large hospital, right? So we're running all those linens through, getting them all sanitized and ready to go back up. That's all in the basement of the building and then all that stuff needs to be distributed up vertically so where all the patient wards are usually above ground for airflow and light and all that stuff. So the vertical transportation provided by the elevators are really the kind of what dictate the throughput of this entire operation. So getting the simulation of the elevator cabins or lift cabins, correct, is a key part here. Modeling the network and topology of the lifts. In many of these hospitals that are quite sophisticated in their use of robotics, they have certain banks of lifts or only for robots. And then, so you can schedule those totally for the robot operations and there's other banks of elevators that are used for patients, other banks used for visitors, other banks for staff. It's very complex and a typical hospital will have 30 or more lifts just in the complex. As you can imagine, once the facility is built, it's approximately infinitely expensive to add more lifts. So basically getting the most throughput possible out of the current lifts is required in order to keep introducing more robots. So here's a few of the common healthcare robots today that you go if you go to public hospitals here in Singapore, you'll see some or all of these. The Panasonic Hospi robots they use, Swiss log meal carts. Essentially the robot, but which I mean the kind of second one from the left here, it's a cart full of food that sits on top of a little robot that goes underneath that cart and lifts it up a few centimeters and it can drive it to where it needs to go. So odds are, if you're warded at a hospital here in Singapore, your lunch, your breakfast or dinner, all comes on these Swiss log robots. The essential kitchen is in the basement. They drive them around to the service lifts and they bring the cart up to the level where you are. They drop it near the nurse area in the ward and the nurses will then hand deliver the trays of food out of that cart. So you can imagine if that cart has the food for 40 people, it's very heavy. So it's the robots to get a ton done. Every breakfast, lunch, and dinner, they have to distribute these carts to all the different wards across, let's say seven levels of patients and then bring them back two hours later to have all the dishes washed and ready to go again. So now I'm gonna talk a little bit about what do we do with the simulation model that we've created. And then the goal is to allow multiple robot fleets. So this simulation snapshot will be, this is like what would be great to happen in the future, just as kind of a cartoon of you have three different robots from three different vendors, but they're sharing the same space and they're operating reasonably around people. So what we're trying to do is to have it so that you can mix and match these robots. And the question of course is why we're doing this is just making everything more complex. And the kind of easy single slide answer is that robot, it's a rapidly developing field. Every year, if you go to a robotics trade show, there's new applications. There's new providers of robots. There's new robots of course themselves. Today we do a lot of delivery in the field. So you see lots of like meal delivery, linen delivery, medication delivery, case files in a hospital, all sorts of stuff moving up and down around the facility. That's so delivery is very common today. But I think we can all agree there'll be new applications in the future. Things that we can maybe see coming on the horizon are like more and more of automated cleaning robots. So imagine like the Roomba vacuum, but like, you know, way more sophisticated with more, maybe like the ultraviolet light so it can spray around to do the sanitation, sanitize rooms, you know, it can scrub floors, mop floors, what have you. So cleaning is certainly coming. Security robots, you know, patrolling around when the facility is supposed to be closed or you know, not supposed to be someone there or if there is supposed to be someone there or whatever. So all these applications are coming. And then of course there's many that we probably can't even imagine right now that will be out in a few years. So what we want to have are software systems that allow new applications to come into the field and just deploy them without having to kind of sit there and replan and reschedule all the machinery. So if you look at that picture, that's a picture of Penang, Malaysia, we took that picture a few months ago just looking down from one of the big towers there. You can see there's an incredibly complex field or incredibly complex kind of like flow of traffic there. There's many different roadways that are all kind of coming and going in different directions and it all flows fine. And that's because there's a well-understood rules of the road that people follow mostly.  And when you introduce the N plus one vehicle, it just merges into this flow and eventually it goes where it needs to go. And so our goal is can we figure out something similar for robotics. So this is the situation today. This is in one of the hospitals here in Singapore. The hospital that are really impressive, they run essentially one robot fleet. And so this is a picture of like on their upper right there, the meal carts. So this is taking the, it takes the food out of the central kitchen in the basement, distributes it up to the wards.  So it's impressive. These are large robots. Those are very heavy carts full of food for 40, 50 people. It's actually kind of amazing and almost hypnotizing to stand there and watch these giant things move around. It's very well orchestrated. It's very impressive. So the single vendor fleets, this is really impressive to see this today. What we are trying to push though is this multi-vendor operations in the same space. So if you look at how things are kind of where it goes today, it's like the fleets don't talk to each other. So vendor A doesn't talk to vendor B.  That's one solution. You can also just sort of hope for the best and kind of just send them through. They all of course have onboard collision avoidance sensors of many different modalities and so they never collide. It's just they kind of do this kind of funny thing. Sometimes we call it robot dance. They just sort of look at each other and like one of them backs up and kind of like it's sort of hilarious to watch. And eventually it'll all kind of, the traffic all flows through the lobby usually. So it's not optimal. I think we can say that pretty safely. And so wouldn't it be great if you could have a joint planner that is planning for both fleets or at least can kind of be like a traffic police.  And finally, I'd mentioned it a little bit before but the lift integration is key, especially in these hospitals that have so much vertical motion happening. And essentially it's a little bit hilarious to think about but in some of these facilities the reality is that there aren't enough service lifts to keep dedicating new lifts to new vendors. In other words, so if we have two vendors of robots and you've allocated two banks of service lifts to those two vendors you actually can't bring on another robot vendor because you don't have any more lifts to dedicate to them because lifts are essentially infinitely expensive to add to an existing building. So what we're looking to do is to help multiplex these lifts so that you can have different vendors share the same lift, which is not current practice. The goal then is to more specifically say these multi-fleet conventions for robot operations. So couldn't we come up with something like a cross-vendor lane network, for example, in these large buildings? So if you're vendor N plus one you sort of download the road map just like if you have a self-driving car system and you're joining the public road you download the public road map and then you're not just gonna drive anywhere you're gonna follow the existing traffic conventions. So this is a part of the project we've been working on is to develop some conventions like this that we can push out as a vendor neutral. So our organization doesn't make robots we don't have any robots to sell so we're not trying to sort of push one over the other. What we're trying to do is instead is to generalize these ideas of train traffic motion how do you call a lift, how do you open door that kind of thing. So to do that we've been creating open source tools the URLs there on the upper left this one is called traffic editor so the idea is we can get the floor plans from the facilities. So that's our an office kind of layout the lower right there and you can see we've annotated some robot lanes on there and then the upper right is another facility where we've taken their blueprints we've traced the walls, the doors and stuff and then added where we think the robot traffic lanes should be and you can see there's different colors in there to imply that different fleets might have different routes through the same space because they might be doing different tasks like bedside delivery as opposed to surgical supply delivery or what have you. An interesting thing this is kind of an interesting journey we've been going down is how much control do we really get over these robots? So these are all safety certified systems they're operating in the hospital so it's not like you can just go and casually run some new software on these robots they're basically completely welded shut but instead what you can talk to is a fleet manager API and most of the vendors provide some of the semblance of an API where you can talk to some over some protocol maybe it's REST maybe it's XML, RPC what have you to issue various tasks or to get various informations from them. So as one example maybe some fleets only will tell you where the robots are but they won't ever let you issue commands to the robots or maybe other fleets will let you see where the robots are and you can temporarily pause a robot where it'll just stop and then you can say resume your task and it'll keep going again and maybe some other fleets will give you full control where you can like give it a path to follow and it'll follow the path as long as there's nothing in its way and so the hope is that if we can have a system which can deal with those various levels of control then we'd be able to mix and match and essentially do what a traffic police officer does when they stand in the middle of an intersection and just sort of give hand signals to drivers to help the traffic clear out. So of course the more control we have over these fleets the more potential there is for improvement. So there's kind of a give and take here of if the reality is just that over one particular fleet of robots we don't get any control we can just read where they are then okay that's just reality but we would then suggest that they have other fleets in the system that we can have more and more control over. So to do this we're creating this vendor neutral system that the URL is up there in GitHub, RMF for Robotics Middleware Framework this is the core scheduling system. So you can imagine the user interfaces in this case it'd be like the surgical supply staff making orders or requests for the new supplies for that day's operations or the nursing staff wanting an item delivered to the award. So that goes through a dispatcher or a task planner which then talks to a negotiation process between the different fleet adapters and a unified schedule that can able to predict where the robots are going, how much time they're gonna delay waiting for this lift or all that kind of thing. Try to push that all into as grand unified schedule of the facility so that the shared space can all be allocated in a reasonable fashion. And one thing that's kind of interesting about all these robots is that all of them will yield to the people in the hospital. So if you get in the way of a meal cart robot it just stops, it's kind of funny then it'll very politely say like please move aside I'm trying to make a delivery. So then you move away and it just kind of keeps on its way. So essentially the task that your prediction of the task completion time it can always be delayed because maybe someone like left the box in the corridor or something and the robot is not willing to go around the box it'll just stop there. It'll then ask the box to move aside over and over and over it's really almost comical. It'll just like park in front of a box asking the box to move aside. Eventually it sends a page to one of the operations staff and then they'll come and move the box out of the way and the robot can keep going. So essentially any of these tasks can be delayed arbitrarily but they'll never go faster than you think they will. So it's a bit of an interesting planning problem. Robots all have a speed limit on them. I think around here it's regulated to like 0.7 meters per second or something and that's it'll never go faster than that. It can only be delayed essentially. And when a robot's delayed you can imagine that does interesting things for the schedule where now you have to re-plan that you know this robot is got there sooner than we thought. So here's a little cartoon to try to show what's gonna happen. So let's say that there are three different fleets of robots they're all trying to use the same corridor or this more likely in reality the same lift lobby because all the past tend to kind of converge in the lobby for the lift where they're gonna we're gonna wait for the lift car to come. So it's interesting because the robots even though they all are kind of the same they're all sort of boxes on wheels. They're all implemented differently inside. And so each fleet doesn't necessarily know what the other one is capable of. One might be a very tall heavy robot where it has to move very slowly and turn very slowly. Another one might be in a more of like a cylinder shape where it can kind of turn on the dime much faster and be able to maneuver more easily. So each fleet essentially is just kind of generates what it would love to do in an empty world if there were no other robot fleets around. So that would be great but typically they're gonna interfere in some sort. So then now that they can see what the other fleets are trying to do then now you have a game, right? If you know what would I do if you do that and what would you do if I do that and that game continues as deep as you have fleets and then at the end of it you can now have a score and now a third party judge can be the kind of arbiter between all those plans and those plans that are determining of other plans as it all rattles out. And finally we can pick the winner, essentially the winning plan that requires the least sort of joint delay on everyone's desires through the space. So that's what to do with fleets. It's also interesting to consider different classes of robots. So there are many robots that do not have a fleet manager shipped with them. So let's say, you know, research projects, low cost, like rapid prototyping projects or even a standalone proof of concept or something like that, where it's not necessarily a totally shrink wrapped product that comes like with a fleet manager and technicians to install it and make it work great. And so for those we're having a fully open source fleet manager which can plug in at the same level of these proprietary vendor fleet managers. So those hook into the common internal robot software like ROS for example, that is used on many research robots. And then it's essentially a peer of these proprietary fleet managers so you can have these mixed fleets of, you know, fully shrink wrapped robots as well as kind of more R&D or lower cost platform. Okay, so that's a lot of talking. Let's do some demos, it's kind of fun. So I will just first show what the simulation looks like. It'll come up in a little bit. So here's for example, one of the test facilities in one of the buildings that we work in. This is designed to be kind of a mixture of a ward. So here's like a couple of people is like a four person hospital ward here as well as to simulate some of the storage rooms and storage facilities. So like this is what it looks like when you go to the surgical supply store room through these little like lots and lots of shelving units with sterilized instruments that are in there in storage. There's usually patients in transit. If you spend much time in a hospital you see people moving around in various ways. This over here is intended to be another kind of surgical store. Let's see here, what else is there? Oh yeah, and of course there's always tons of people waiting in various parts of the building. So what we can do is now I'll show the traffic manager after I first introduce you to the robots. So this is a common robot that you can buy off the shelf. It's a nice robot, maybe a company called MR. It's one of the common industrial sort of you wanna move a thing type robots. This will move your thing. You can put stuff on it or you can have accessories for it that make the top lift up and down to lift other carts that it rolls underneath. And then these are lower cost platforms intended for rapid prototyping here called Magni. And let's see, so now we'll show what happens when the grand planner all runs. So let's see here, let's go somewhere else. Right, let's tricky to type one handed. Okay, let's run this demo. So it's gonna go very fast. I'll play it a few times because one of the funny things with large robots because they're speed limited to like 0.7 meters per second. If you watch them in real time, it's like watching grass grow, right? It's just like that's so boring. Anyone who thinks robots are taking over the world hasn't ever seen real robots because they're so boring. They will do it extremely slowly. You know, it's fine, you're fine. Everyone's fine. So let's see, so we've sped the world up eight times here. So now this is showing that same world but with robots moving around. Okay, let me stop this for a second because there's a lot going on. On the right side, you have the path network from the robots that was a screenshot from that traffic editor before. So here we have a purple fleet. There's a blue kind of cyan fleet and orange fleet. So there's three kinds of robots here. We're actually only running two now but they're gonna only move around just like railroad tracks on those paths. At any given time, the central planning entity is trying to predict the future of where these robots are going to go. So there's a green arrow that you'll see and that green path is the prediction if you roll out the trajectory in the future. Like where does it think the robots are gonna be as time goes forward? At any given time, there's these little purple kind of dots and that's where the robots last reported position was. So we're simulating all this in gazebo but we've run it in reality as well in the same space. So the one, the big white robot is gonna go from this simulated storage facility here to this simulated storage facility here.   So those are gonna be kind of just going everywhere. And the idea is we've set this up on purpose to be almost pathologically difficult because all these paths are intersecting on purpose. So the central entity is then gonna be sort of stopping particular robots from getting close to each other. So as you see them go back and forth, they will stop and wait for each other as the predicted paths intersect over time. You'll see some of them stop like this. There'll be a situation here. Whoop, that one moved out of the way. It's sort of this like ballet as it goes on. And you can imagine this gets even more complex as we have more levels to it and more robots to this situation. So it's a little hard to see what would have happened because we're not showing what would have happened if you didn't have the central planner telling people to stop and start. But so you have to sort of believe me when I say that it's not good, it's just a train wreck. It's not a train wreck. It's more like a traffic jam. Let's say on the road outside no one follows the rules and no one follows the traffic signals or the stop signs and you just like, just giant gridlock. That's what can happen with these robots. And the goal is to make this thing scalable so that when you wanna add n plus one or n plus two robots in the future, it's no big deal. And so you can imagine a future world in a few years or who knows when when there'll be 10 times as many robots as there are now where this type of a system will become increasingly important to prevent these traffic jams from happening. So I'll let this thing play. It's kind of fun to watch. So again, it's almost like the software is running really well when there's no obvious traffic jams happening, which is a little bit, you're trying to prove a negative, but it's okay.  Okay, so that's the end of my prepared talk here. These are all open source projects. There's some URLs and GitHub there as well as the kind of foundational projects Ross and Gazebo, those are the websites that those have. And we're always fully welcome contributions from everyone from all domains. It's a fun wide open space to play in. So thanks for your time.


Academic research is a wonderful and important enterprise to be a part of. And the purpose of research of universities is to create and disseminate knowledge. And humanists and scientists use many kinds of sources, like texts and molecules, to understand society, history, people, and how the world works. And my own work is devoted to a field called developmental science. We study the behavior, brains, and learning capacities of young children to understand what human cognition is and how our experiences bring it to life. And at the Princeton Baby Lab, we study the intersection of two signatures of human cognition. On the one hand, our species prodigious attention, memory, perception, and pattern detection abilities. And on the other, our propensity for language and communication with others. The product of these signatures, efficient learning, and exchange of information, is one of the greatest demonstrations of the power of the human mind. And in particular, we study how babies break into the structure of the world. And I hope to show you why proficiency in finding structure is important. So what do I mean by this? I mean the process of finding regularities in patterned input, such as finding words in language. And learning patterns is critical. And generalizing what you know to new experiences is very important too. And it's a hallmark of language in particular, because language is filled with patterns and rules that govern how words are combined. Language learning seems impossibly complex, given that our eyes and our ears are bombarded with millions of bits of data at every moment. The eardrum, a thin, stretched membrane, just vibrates with fluctuations of air pressure, and we end up knowing fine-grained information about tens of thousands of words and how they go together. How do we understand infants' early stabilities to break into structure, right? Data come in, we detect structure, and we learn. Well, lab studies are a useful way to start. So in one interesting study, seven-month-old infants heard sequences of syllables that followed a particular pattern, like an AAB pattern. Le, le, di, go, go, la. And then the researchers measured how long infants wanted to listen to new syllables that either matched this pattern, like si, si, ru, or did not match this pattern, like si, ru, si. And infants listened longer to this novel ABA pattern. They were surprised, so to speak. They had learned something about this pattern. But critically, infants consistently failed to do this with non-speech sounds. If you do the identical study with sine wave tones or music notes, infants fail to learn. They don't show any element of surprise when they hear this violation of the pattern they learned. This led to the conclusion that speech has a privileged status in early learning, perhaps resulting from speech-specific adaptations that evolved with our capacity for language. But we tested a different hypothesis, that learning patterns is engaged by communication in general, not by speech, per se. And infants love people. They love their faces, their sounds, the fact that they move. So maybe their massive experience watching people use speech in dynamic ways is responsible for enabling the learning of patterns. So we actually tricked babies into thinking that tones could be used to communicate. We showed infants a short video of two women talking, one in English, one responding in sine wave tones, the other responding in English. And this brief video of people changed the landscape of their learning. They successfully learned the inherent structure in sequences of tones, just as well as they did with speech. This led us to conclude, based on various control and replication studies, that communicative signals grab our attention. And in doing so, catalyze a fundamental achievement of early learning, the detection of structure. And this is just one example of how infants find structure in the world. Our field has shown collectively that the moment-to-moment detection of structure and the processing of incoming information has cascading effects on later learning. The first 1,000 days of life have consequences, troubling consequences on outcomes, because learning is fragile and it's subject to the environment. So for example, in the United States, children from wealthier families here on average three times as much language as children from poor families. This gives some kids an enormous boost in discovering the structure of language and leaves other kids behind. And this brings me to another valuable contribution of our field. We are at a turning point in our ability to conduct rigorous interventions to understand how to foster successful learning. One example is the 30 million words project based at the University of Chicago. We are conducting a parent-directed intervention aimed at reducing disparities in language experience and reducing gaps in school readiness. We're using a randomized controlled trial design and we are providing an in-home course in either child development or nutrition with 200 families in poverty in Chicago. The goal is to see if we can enhance the quality of parent-child interactions and accelerate the early detection of structure. And labs all over the world, including here in China, are equipped with theories and methods to understand how human infants learn so well and also why some children are hindered in this pursuit, like children with autism or children raised in institutions who often do not have the same access to enriching experience. And developmental science allows basic and translational science to coexist productively. And key to this is that infants' learning trajectories diverge more and more over time. So if we're looking for the greatest return on investments in human capital, there's no time like infancy. If we can uncover how experience is structured and how infants discover structure in its complexities, we will be well positioned to unearth the consequential variable and still largely mysterious human ability to learn.