February 2022 - Pharo-users

Re: Too many parenthesis - a matter of syntax

by Richard O'Keefe

The fact that there is more than you want is precisely why you want to make classes for the data you *do* want. I do have kit for streaming JSON out directly without creating JSON data internally, but I'm still trying to find a good way to stream JSON in creating wanted objects on-the-fly so that the unwanted data are never stored. I think it can be done from the same schema language that I use to generate classes. On Mon, 28 Feb 2022 at 20:09, Kasper Osterbye <kasper.osterbye(a)gmail.com> wrote: > Thanks Richard, > > I tend to agree with your design experience. As it happens, in my concrete > code I get JSON back from a github api which serves me more than I want. I > am therefore not interested in making classes for those aspects of the data > I throw out. > > The way I handle this in practice myself is to introduce a local variable > for each level. Makes it easier to debug too. > > Best, > > Kasper > > On 27 Feb 2022, at 00.42, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I was bemused to realise that I've actually been programming > for literally 50 years. It finally seeped through my thick > skull I make enough mistakes that if it's hard to read, I > probably got it wrong. And THIS code fragment is hard to > read. I don't care if you use parentheses or pipes, it's > hard to read either way. Oh, the pipes make the structure > easier to see, true. But I am still left guessing what it > is FOR. What's it SUPPOSED to mean? And the problem is that > there are some abstractions missing. Of course this is JSON's > fault. > > This is the first code smell, and in my experience it is > almost ALWAYS a code smell: you are using JSON as a > "processing" data structure instead of as a "communication" > syntax. Using JSON inside your program, instead of at the > edges, means that the semantics gets scattered all over the > code, which leads to complexity and inconsistency. > > The convention I follow is that data structure more complicated > than a string or an array of numbers has a Smalltalk class > Whatsit>>asJson converts an instance to a JSON value > Whatsit class>>fromJson: converts a JSON value to an instance. > I'll start with > topLevel := TopLevelWhatsit fromJson: someStream nextJson. > and from then on I'm working with pure Smalltalk. > > This has the extra benefit of validating the input right away. > I don't want my program running for several hours and then > running into trouble because some component of the JSON value > is missing or ill-formed. > > In practice, the time cost of converting JSON to (application- > specific) Smalltalk is quite small compared with the cost of > reading the JSON in the first place, and there can be seriously > worthwhile savings in memory. > > For this example, we'd be looking at > topLevel tree blobs > collect: [:each | each path] > thenSelect: [:path | path hasAnyExtension: #('md' 'mic')] > > My Filename class has methods > has[Any]Extension:[ignoringCase:] > which I have shamelessly exploited here. I like the > way that they hide the structure of a Filename. > > The portmanteau methods > Collection>>collect:thenSelect: > Collection>>select:thenCollect: > have existed in Pharo as long as Pharo has existed. > They have two rationales: > (a) improve readability > (b) permit optimisation by eliminating an intermediate collection. > Sequences exploit (b). Sets could too but happen not to. > > THEREFORE, here are free implementations of > Set>>collect:thenSelect: and Set>>select:thenCollect: > consistent with Pharo's Set>>collect: > > collect: collectBlock thenSelect: selectBlock > "Override Collection>>collect:thenSelect: like OrderedCollection. > Beware: 'self species' is often inappropriate, as in #collect:." > |newSet| > newSet := self species new: self size. > self do: [:each | > |item| > item := collectBlock value: each. > (selectBlock value: each) ifTrue: [newSet add: item]]. > ^newSet > > select: selectBlock thenCollect: collectBlock > "Override Collection>>select:thenCollect: like OrderedCollection. > Beware: 'self species' is often inappropriate, as in #collect:." > |newSet| > newSet := self species new: self size. > self do: [:each | > (selectBlock value: each) ifTrue: [ > newSet add: (collectBlock value: each)]]. > ^newSet > > > > On Wed, 26 Jan 2022 at 22:19, Kasper Osterbye <kasper.osterbye(a)gmail.com> > wrote: > >> Cheers all >> >> I have noticed that I often ends up with quite a number of nested >> expressions, for example: >> >> (((json at: 'tree') >> select: [ :e | (e at: 'type') = âblob' ]) >> collect: [:e | Path from: (e at: 'path')]) >> select: [ :p | p segments last >> in: [ :name | (name endsWith: '.md') | >> (name endsWith: '.mic') ] ] >> >> What kind of proposals (if any) have been for a different syntax which >> could give a more streamlined syntax? >> >> My own thinking has been around an alternative to the cascade semicolon. >> What symbol to use does not matter for me, but something like >> json at: âtree' Âº >> select: [ :e | ((e at: 'type') = 'blobâ)]Âº >> collect: [:e | Path from: (e at: 'pathâ)]Âº >> select: [ :p | p segments last >> in: [ :name | (name endsWith: '.md') | (name endsWith: >> '.mic') ] ] >> >> Basically, a send the right hand expression to the result of the left >> hand expression. >> >> Has anyone ever tried this, or is it just one of the many small >> annoyances best left alone? >> >> Best, >> >> Kasper > > >

Feb. 28, 2022

Re: Too many parenthesis - a matter of syntax

by Kasper Osterbye

Thanks Richard, I tend to agree with your design experience. As it happens, in my concrete code I get JSON back from a github api which serves me more than I want. I am therefore not interested in making classes for those aspects of the data I throw out. The way I handle this in practice myself is to introduce a local variable for each level. Makes it easier to debug too. Best, Kasper > On 27 Feb 2022, at 00.42, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I was bemused to realise that I've actually been programming > for literally 50 years. It finally seeped through my thick > skull I make enough mistakes that if it's hard to read, I > probably got it wrong. And THIS code fragment is hard to > read. I don't care if you use parentheses or pipes, it's > hard to read either way. Oh, the pipes make the structure > easier to see, true. But I am still left guessing what it > is FOR. What's it SUPPOSED to mean? And the problem is that > there are some abstractions missing. Of course this is JSON's > fault. > > This is the first code smell, and in my experience it is > almost ALWAYS a code smell: you are using JSON as a > "processing" data structure instead of as a "communication" > syntax. Using JSON inside your program, instead of at the > edges, means that the semantics gets scattered all over the > code, which leads to complexity and inconsistency. > > The convention I follow is that data structure more complicated > than a string or an array of numbers has a Smalltalk class > Whatsit>>asJson converts an instance to a JSON value > Whatsit class>>fromJson: converts a JSON value to an instance. > I'll start with > topLevel := TopLevelWhatsit fromJson: someStream nextJson. > and from then on I'm working with pure Smalltalk. > > This has the extra benefit of validating the input right away. > I don't want my program running for several hours and then > running into trouble because some component of the JSON value > is missing or ill-formed. > > In practice, the time cost of converting JSON to (application- > specific) Smalltalk is quite small compared with the cost of > reading the JSON in the first place, and there can be seriously > worthwhile savings in memory. > > For this example, we'd be looking at > topLevel tree blobs > collect: [:each | each path] > thenSelect: [:path | path hasAnyExtension: #('md' 'mic')] > > My Filename class has methods > has[Any]Extension:[ignoringCase:] > which I have shamelessly exploited here. I like the > way that they hide the structure of a Filename. > > The portmanteau methods > Collection>>collect:thenSelect: > Collection>>select:thenCollect: > have existed in Pharo as long as Pharo has existed. > They have two rationales: > (a) improve readability > (b) permit optimisation by eliminating an intermediate collection. > Sequences exploit (b). Sets could too but happen not to. > > THEREFORE, here are free implementations of > Set>>collect:thenSelect: and Set>>select:thenCollect: > consistent with Pharo's Set>>collect: > > collect: collectBlock thenSelect: selectBlock > "Override Collection>>collect:thenSelect: like OrderedCollection. > Beware: 'self species' is often inappropriate, as in #collect:." > |newSet| > newSet := self species new: self size. > self do: [:each | > |item| > item := collectBlock value: each. > (selectBlock value: each) ifTrue: [newSet add: item]]. > ^newSet > > select: selectBlock thenCollect: collectBlock > "Override Collection>>select:thenCollect: like OrderedCollection. > Beware: 'self species' is often inappropriate, as in #collect:." > |newSet| > newSet := self species new: self size. > self do: [:each | > (selectBlock value: each) ifTrue: [ > newSet add: (collectBlock value: each)]]. > ^newSet > > > > On Wed, 26 Jan 2022 at 22:19, Kasper Osterbye <kasper.osterbye(a)gmail.com <mailto:kasper.osterbye@gmail.com>> wrote: > Cheers all > > I have noticed that I often ends up with quite a number of nested expressions, for example: > > (((json at: 'tree') > select: [ :e | (e at: 'type') = âblob' ]) > collect: [:e | Path from: (e at: 'path')]) > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > What kind of proposals (if any) have been for a different syntax which could give a more streamlined syntax? > > My own thinking has been around an alternative to the cascade semicolon. What symbol to use does not matter for me, but something like > json at: âtree' Âº > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > collect: [:e | Path from: (e at: 'pathâ)]Âº > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > Basically, a send the right hand expression to the result of the left hand expression. > > Has anyone ever tried this, or is it just one of the many small annoyances best left alone? > > Best, > > Kasper

Feb. 28, 2022

Re: Too many parenthesis - a matter of syntax

by Richard O'Keefe

I was bemused to realise that I've actually been programming for literally 50 years. It finally seeped through my thick skull I make enough mistakes that if it's hard to read, I probably got it wrong. And THIS code fragment is hard to read. I don't care if you use parentheses or pipes, it's hard to read either way. Oh, the pipes make the structure easier to see, true. But I am still left guessing what it is FOR. What's it SUPPOSED to mean? And the problem is that there are some abstractions missing. Of course this is JSON's fault. This is the first code smell, and in my experience it is almost ALWAYS a code smell: you are using JSON as a "processing" data structure instead of as a "communication" syntax. Using JSON inside your program, instead of at the edges, means that the semantics gets scattered all over the code, which leads to complexity and inconsistency. The convention I follow is that data structure more complicated than a string or an array of numbers has a Smalltalk class Whatsit>>asJson converts an instance to a JSON value Whatsit class>>fromJson: converts a JSON value to an instance. I'll start with topLevel := TopLevelWhatsit fromJson: someStream nextJson. and from then on I'm working with pure Smalltalk. This has the extra benefit of validating the input right away. I don't want my program running for several hours and then running into trouble because some component of the JSON value is missing or ill-formed. In practice, the time cost of converting JSON to (application- specific) Smalltalk is quite small compared with the cost of reading the JSON in the first place, and there can be seriously worthwhile savings in memory. For this example, we'd be looking at topLevel tree blobs collect: [:each | each path] thenSelect: [:path | path hasAnyExtension: #('md' 'mic')] My Filename class has methods has[Any]Extension:[ignoringCase:] which I have shamelessly exploited here. I like the way that they hide the structure of a Filename. The portmanteau methods Collection>>collect:thenSelect: Collection>>select:thenCollect: have existed in Pharo as long as Pharo has existed. They have two rationales: (a) improve readability (b) permit optimisation by eliminating an intermediate collection. Sequences exploit (b). Sets could too but happen not to. THEREFORE, here are free implementations of Set>>collect:thenSelect: and Set>>select:thenCollect: consistent with Pharo's Set>>collect: collect: collectBlock thenSelect: selectBlock "Override Collection>>collect:thenSelect: like OrderedCollection. Beware: 'self species' is often inappropriate, as in #collect:." |newSet| newSet := self species new: self size. self do: [:each | |item| item := collectBlock value: each. (selectBlock value: each) ifTrue: [newSet add: item]]. ^newSet select: selectBlock thenCollect: collectBlock "Override Collection>>select:thenCollect: like OrderedCollection. Beware: 'self species' is often inappropriate, as in #collect:." |newSet| newSet := self species new: self size. self do: [:each | (selectBlock value: each) ifTrue: [ newSet add: (collectBlock value: each)]]. ^newSet On Wed, 26 Jan 2022 at 22:19, Kasper Osterbye <kasper.osterbye(a)gmail.com> wrote: > Cheers all > > I have noticed that I often ends up with quite a number of nested > expressions, for example: > > (((json at: 'tree') > select: [ :e | (e at: 'type') = âblob' ]) > collect: [:e | Path from: (e at: 'path')]) > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | > (name endsWith: '.mic') ] ] > > What kind of proposals (if any) have been for a different syntax which > could give a more streamlined syntax? > > My own thinking has been around an alternative to the cascade semicolon. > What symbol to use does not matter for me, but something like > json at: âtree' Âº > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > collect: [:e | Path from: (e at: 'pathâ)]Âº > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: > '.mic') ] ] > > Basically, a send the right hand expression to the result of the left hand > expression. > > Has anyone ever tried this, or is it just one of the many small annoyances > best left alone? > > Best, > > Kasper

Feb. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Kasper Osterbye

All the answers have been good. I am somewhat provoked (in the good sense of forcing me to think) by Siemen who sort of think of it as a code-smell. Best, Kasper > On 26 Feb 2022, at 17.14, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > Hi Kasper, > > perhaps not what you are asking, but I find that this kind of nesting happens to me when parsing serialized data (web page sources or JSON as in your example). For me, the root cause of the problem is that these data structures are not represented by real classes in my code. I often start with what you are showing in a Playground, but then refactor it into specific parsers for the web sites I am scraping. The parsing selectors go into classes that mirror the parts of the data I am interested in. I find this to be more declarative and maintainable, and more natural in the Pharo environment with its browsers and code extractors. > > I hope this is of any use :)

Feb. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Siemen Baader

Hi Kasper, perhaps not what you are asking, but I find that this kind of nesting happens to me when parsing serialized data (web page sources or JSON as in your example). For me, the root cause of the problem is that these data structures are not represented by real classes in my code. I often start with what you are showing in a Playground, but then refactor it into specific parsers for the web sites I am scraping. The parsing selectors go into classes that mirror the parts of the data I am interested in. I find this to be more declarative and maintainable, and more natural in the Pharo environment with its browsers and code extractors. I hope this is of any use :) cheers Siemen On Fri, Jan 28, 2022 at 11:55 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > I think that's OK when you can choose when to use parentheses. If you > think it would improve readability it is ok to use it, the problem is to be > forced to use it even when you think it decreases readability, what I > believe to be the case in discussion. > > On Thu, Jan 27, 2022 at 3:24 PM Russ Whaley <whaley.russ(a)gmail.com> wrote: > >> What I like about parentheses (and I hate parentheses) is that it allows >> me to view/describe the intent of the code. When parens are not used, it is >> up to me (perhaps years later) to determine whether the original developer >> (sometimes me) understood (or not) the actual 'order of processing'. >> Parens - or another vehicle - should help me understand the intent (as >> would detailed comments) - so I can devise tests (oh yeah, are those >> available, too?) for the intent - even if it is just me in the debugger. >> >> So, I'm for whatever helps me understand the intent of the code - even if >> there is some slick way to nest everything. I generally prefer breaking >> nested processes down into multiple steps. Benchmarking rarely shows >> significant performance differences, for me. >> >> (and I've used parentheses 7 times in this one email!) :-) >> >> Russ >> >> On Wed, Jan 26, 2022 at 4:20 AM Kasper Osterbye < >> kasper.osterbye(a)gmail.com> wrote: >> >>> Cheers all >>> >>> I have noticed that I often ends up with quite a number of nested >>> expressions, for example: >>> >>> (((json at: 'tree') >>> select: [ :e | (e at: 'type') = âblob' ]) >>> collect: [:e | Path from: (e at: 'path')]) >>> select: [ :p | p segments last >>> in: [ :name | (name endsWith: '.md') | >>> (name endsWith: '.mic') ] ] >>> >>> What kind of proposals (if any) have been for a different syntax which >>> could give a more streamlined syntax? >>> >>> My own thinking has been around an alternative to the cascade semicolon. >>> What symbol to use does not matter for me, but something like >>> json at: âtree' Âº >>> select: [ :e | ((e at: 'type') = 'blobâ)]Âº >>> collect: [:e | Path from: (e at: 'pathâ)]Âº >>> select: [ :p | p segments last >>> in: [ :name | (name endsWith: '.md') | (name endsWith: >>> '.mic') ] ] >>> >>> Basically, a send the right hand expression to the result of the left >>> hand expression. >>> >>> Has anyone ever tried this, or is it just one of the many small >>> annoyances best left alone? >>> >>> Best, >>> >>> Kasper >> >> >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com >> >

Feb. 26, 2022

R: Re: Image

by kikka

Thank you a lot for you tip about newest version; Iâll take it for sure :) And thanks for your indications; Iâm watching the video you sent. Regards Federica Cordiali saluti Federica Schiavina Da: Tim Mackinnon [mailto:tim@testit.works] Inviato: giovedÃ¬ 24 febbraio 2022 15.21 A: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Oggetto: [Pharo-users] Re: Image Hi Federica - that is a very old version of Pharo that you are using - you should consider using a much newer version (ideally the latest - as there are many more tools for recovering lost work, and in fact the environment can detect it and prompt you, equally there is GIT integration which is something you should also consider learning about). This said - the above doesn't help you now. You are correct, that the .changes file will have your work in it. I don't quite recall back then what worked - I see in this video https://www.youtube.com/watch?v=jwKDFbPkHzw that you might be able to drag and drop that file to access them - or - worst case is, you can open that file with a pharo editor and then you can hilite sections and use "doit" to re-evaluate them. Or use a text editor to open the file and then find the code you are missing and paste it into pharo. Its a bit painful, but you should be able to get things back reasonably quickly. Someone else might remember more. If you are cutting and pasting - I would consider doing it with a newer version of Pharo. Hope this helps, Tim On Thu, 24 Feb 2022, at 1:45 PM, kikka wrote: Hi everybody, I have a big problem. After working on my application I closed Pharo. When I got back the shortcut wasnât working any more and I realized my image got ruined. I could recover just a very old version of my C:\Seaside-3.1-portable\Seaside-3.1-portable.app\Contents\Resources\Pharo4.0-portable.image (no recent backup). I have seen that all the changes I have developed can be seen in C:\Seaside-3.1-portable\Seaside-3.1-portable.app\Contents\Resources\Pharo4.0-portable.changes I was wondering if it was possible to load all the changes on the old Pharo4.0-portable.image without losing all my work. Hanks in advance for any help. Regards. Federica <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Mail priva di virus. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> www.avast.com -- Questa e-mail Ã¨ stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

Feb. 24, 2022

Re: Image

by Tim Mackinnon

Hi Federica - that is a very old version of Pharo that you are using - you should consider using a much newer version (ideally the latest - as there are many more tools for recovering lost work, and in fact the environment can detect it and prompt you, equally there is GIT integration which is something you should also consider learning about). This said - the above doesn't help you now. You are correct, that the .changes file will have your work in it. I don't quite recall back then what worked - I see in this video https://www.youtube.com/watch?v=jwKDFbPkHzw that you might be able to drag and drop that file to access them - or - worst case is, you can open that file with a pharo editor and then you can hilite sections and use "doit" to re-evaluate them. Or use a text editor to open the file and then find the code you are missing and paste it into pharo. Its a bit painful, but you should be able to get things back reasonably quickly. Someone else might remember more. If you are cutting and pasting - I would consider doing it with a newer version of Pharo. Hope this helps, Tim On Thu, 24 Feb 2022, at 1:45 PM, kikka wrote: > Hi everybody, > > I have a big problem. > > After working on my application I closed Pharo. > > When I got back the shortcut wasnât working any more and I realized my image got ruined. > > I could recover just a very old version of my C:\Seaside-3.1-portable\Seaside-3.1-portable.app\Contents\Resources\Pharo4.0-portable.image (no recent backup). > > I have seen that all the changes I have developed can be seen in C:\Seaside-3.1-portable\Seaside-3.1-portable.app\Contents\Resources\Pharo4.0-portable.changes I was wondering if it was possible to load all the changes on the old Pharo4.0-portable.image without losing all my work. > > Hanks in advance for any help. > > Regards. > > Federica > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > Mail priva di virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <https://www.fastmail.com/mail/list.1-pharo/compose/Me918b843c4f1c7537ab8ea4…>

Feb. 24, 2022

Image

by kikka

Hi everybody, I have a big problem. After working on my application I closed Pharo. When I got back the shortcut wasn't working any more and I realized my image got ruined. I could recover just a very old version of my C:\Seaside-3.1-portable\Seaside-3.1-portable.app\Contents\Resources\Pharo4.0 -portable.image (no recent backup). I have seen that all the changes I have developed can be seen in C:\Seaside-3.1-portable\Seaside-3.1-portable.app\Contents\Resources\Pharo4.0 -portable.changes I was wondering if it was possible to load all the changes on the old Pharo4.0-portable.image without losing all my work. Hanks in advance for any help. Regards. Federica -- Questa e-mail Ã¨ stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

Feb. 24, 2022

Re: Changes to class not recorded in change.log?

by Stewart MacLean

Hi Tim, Apologies for not replying sooner - I'm a recent migrant to GMail and it keeps flagging good mail as spam! I haven't explored this further, I think I was using the old Changes Browser. As I'm back to "square one" I've moved on to other problems, but when I get a chance I'll conduct some tests. Thanks, Stew On Tue, Feb 15, 2022 at 4:57 AM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Stewart - are you using the Code Changes (Epicea) browser - or trying > to use the older changes files? > > Your message wasn't clear - and I have seen oddities with Epicea too - but > normally I have been able to recover instance variables too (sometimes the > restore options were a bit confusing and I did it in the wrong order). > > Note - I haven't tried this in V9 though - so possibly something has > regressed. Thought it worth checking though. > > Tim > > On Mon, 14 Feb 2022, at 7:36 AM, Stewart MacLean wrote: > > Hi, > > The worst case scenario has just happened - my image is hosed. > > I've managed to recover a previous set of change/image files (thanks > CrashPlan!). > > Then I've replayed all the intervening changes - however I find that some > instance variables that I had defined haven't been reflected in class shape > changes. > > I notice all the changes for the complete change log are for Method, and > Do It (image saves) > > Surely class shape changes should be recorded as well? Is this a bug? > > Cheers, > > Stewart > > Platform Mac Mini > Pharo 9.0.0 > Build information: > Pharo-9.0.0+build.1573.sha.0e09d756fc99383cbb498565200d9e5e9841ce11 (64 Bit) > > >

Feb. 21, 2022

Fwd: ESUG 2022 call for presentations And Call for student volunteers

by stephane ducasse

A reminderâ¦ S > Begin forwarded message: > > From: "stephane.ducasse(a)free.fr" <stephane.ducasse(a)free.fr> > Subject: ESUG 2022 call for presentations And Call for student volunteers > Date: 13 January 2022 at 13:23:44 CET > > ESUG 2022 > Serbia 22. â 26.8. > > You can support the ESUG conference in many different ways: > Sponsor the conference. New sponsoring packages are described at http://www.esug.org/supportesug/becomeasponsor/ <http://www.esug.org/supportesug/becomeasponsor/> > Submit a talk, a software or a paper to one of the events. See below. > Attend the conference. We'd like to beat the previous record of attendance (170 people at Amsterdam 2008)! > Students can get free registration and hosting if they enroll into the the Student Volunteers program. See below. > <>Developers Forum: International Smalltalk Developers Conference > > We are looking for YOUR experience on using Smalltalk. You will have 30 min for presentations and 45 min for hands-on tutorials. > The list of topics for the normal talks and tutorials includes, but is not limited to the following: > XP practices, Development tools, Experience reports > Model driven development, Web development, Team management > Meta-Modeling, Security, New libraries & frameworks > Educational material, Embedded systems and robotics > SOA and Web services, Interaction with other programming languages > <>Teaching Pearls and Show us Your Business > > New this year!!! We added two types of sessions in addition to the regular talks and show us your projects sessions. > Show your business 10 min session (Get prepared!!) > Teaching pearls : we want some session on how to teach some design aspects. We want your tip and tricks to teach Smalltalk or OOP. > We expect to have several 10 to 15 min sessions aggregated. > <>How to submit? > > Make a Pull Request here https://github.com/ESUG/esug.github.io/tree/source/2022-Conference/talks > > Or but only if you are not connected to the worldâ¦ send an email to stephane.ducasse(a)inria.fr > > Title: [ESUG 2022] Please follow the template below the email will be automatically processed! > Name: > Email: > Abstract: > Bio: > > Call for Student Volunteers > Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. > > Pay attention: the places are limited so do not wait till the last minute to apply. > > Conference details: > Send an email to stephane.ducasse at inria.fr and serge.stinckwich at gmail.com with: > > title: [ESUG 2022 Student] > name, gender, university/school, country, email address > short description of you and why you are interested in participating > For which period is accommodation covered? Accommodation is covered from Sunday 21 August until Friday 26 August 2022 (including nights from Sunday to Monday and from Thursday to Friday). Students will be hosted in student rooms. ESUG additionally covers for the lunches during the week and one dinner. > > Duties include handling registration as people arrive at the conference, filling coffee machines, collecting presentation slides for ESUG right after the presentation is given, being present at an information desk to answer questions, and generally being helpful. Student volunteering makes the conference better, takes a fairly small amount of time and doesn't significantly interfere with enjoying and learning from the conference. Please Note, this role requires discipline and constant attention to all attendees. > > Information about hotel > Student Volunteer rooms are booked at (to be announced). If you are student volunteer, do not book yourself, we have arranged the booking already! >

Feb. 20, 2022