February 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] The HiDPI Issue

by Eric Gade

Ben: > Would you volunteer for early testing of windowing driven from Image side > of headless-VM ? Yeah I would love to help test this. However, there's a good chance I'm going to return this new laptop for its lower resolution variant (I have a System76 Galago Pro). The HiDPI situation in Linux is, for the moment, not especially great. Some if it has to do with the whole X vs Wayland (vs NVIDIA) fiasco. But other than that, this is definitely something I'd be willing to help out with. Tim: > Eric - I had the same feeling a few years ago when I got a retina laptop > and found Pharo a bit fuzzy on the eyes (although itâs true that with time > you start to notice it less) > I think Apple has some secret sauce when dealing with scaling across different applications on their Retina displays. Xorg and friends do not have this magic on the Linux side. On a 3k 13/14inch screen, without switching my monitors resolution down in the settings, Pharo is downright microscopic (I don't have my new laptop with me otherwise I'd post a screenshot). The only way to deal with this is to completely switch my resolution and scaling factors at the system settings level every time I want to use Pharo. For other applications this might involve a restart, too, which is no bueno. The GToolkit stuff is promising and I had been waiting for this Bloc-in-external-window capability. With regard to the HiDPI stuff, it doesn't make a difference on Linux -- it's just as "small" as anything in the main Morphic window. Again, I think this is because Apple (maybe Windows too?) has more control over their whole graphics stack and can perform some kind of magic to deal with scaling across applications. Thanks for the replies, all.

Feb. 16, 2019

[Pharo 8.0] Build #83: 2562 Remove unused cache from TermInfoCharacter

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #83 was: SUCCESS. The Pull Request #2563 was integrated: "2562 Remove unused cache from TermInfoCharacter" Pull request url: https://github.com/pharo-project/pharo/pull/2563 Issue Url: https://pharo.fogbugz.com/f/cases/2562 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2019

Re: [Pharo-dev] The HiDPI Issue

by Tim Mackinnon

Eric - I had the same feeling a few years ago when I got a retina laptop and found Pharo a bit fuzzy on the eyes (although itâs true that with time you start to notice it less). Anyway - Iâm not sure anyone has actually mentioned that you can download the latest Glamourous Toolkit (https://gtoolkit.com/#install <https://gtoolkit.com/#install> - take the prebuilt image) and then open a playground (with all other windows closed) and evaluate: Bloc preferableHostClass: BlOSWindowHost Then try one of the examples in the GT menu (donât go full screen in your image), and this will open a second native window rendered in retina quality. Its still a bit alpha - you get a warning dialog that you have to click ignore on 3 times - but then it keeps running. It is also obviously unoptimised at this point too. I think this gives a welcome glance of the future - so there is hope. Tim > On 16 Feb 2019, at 11:04, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi Eric > > I will let esteban reply carefully :) > Now my take on this is > that we want to go via SDL and other backends to solve the problems (event dropping, display) > Back in October, Esteban fixed the SDL/OSWindows so that Bloc people can get rid of the > VM rendering and be free. > > This is the path to go. > For Bloc I (personally and discussing with Alain) think that there is 4-6 months of work (if I would overselling it I would have said that this is 2 month work) to clean it and tight it up - (not talking about Widgets). I personnally do not want Design like Glamour or GT in the system (too many announcers). > So we will take time to do real code review. > > So our roadmap is > - make sure that Pharo can work headless > - check the impact of SDL/OSWindow > - focus on new spec version so that we can have our tools migrated and we do not have to > rewrite them once more. > > Pharo 90 probably focus on Bloc. > > > Stef > >> On 15 Feb 2019, at 17:52, Eric Gade <eric.gade(a)gmail.com> wrote: >> >> Hello, >> >> I know that others have posted about this before but I wanted to get the current status. >> >> I've recently had to buy a new laptop that came with a HiDPI display. Generally (especially on Linux systems) this makes Pharo unusable. Though there are font size increase and scaling options in the Pharo system settings, these do not work as a solution -- buttons are still tiny, there is inconsistent scaling behavior across morphic, etc. The overall problem can be described as: in Pharo, one pixel equals one "point," and so the interface is incredibly small on these HiDPI screens (3k etc). >> >> These HiDPI screens are becoming more common, both as laptop and as external displays. Their main advantage is that they can render text very crisply. In the HN post announcing the release of P7, there were one or two complaints about this issue. It does make it hard to demonstrate to others (as I do often) the power of developing in Pharo. >> >> Here are some questions I have about this issue: >> 1) What is the current state of affairs in dealing with this issue, if any? >> 2) Would this require VM changes (I assume it would)? If so, what might those entail? >> 3) If this does require VM changes, I assume the Squeak people would want in on it? >> 4) Is the current plan to wait for Bloc to resolve these issues and/or would switching to Bloc resolve these issues at all anyway? >> 5) Related -- where can one start to learn about current VM architecture and development practices? >> >> That said I'm not here to just bellyache. While I don't have any VM experience, I'm willing to jump in and try to work on it if someone can point me in the right direction. Or perhaps this is too specialized a task... >> >> Thanks >> >> -- >> Eric > > >

Feb. 16, 2019

[Pharo 8.0] Build #82: 2554 Epicea: EpApplyPreviewer sourceEntries and logBrowserModel ivars not used

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #82 was: FAILURE. The Pull Request #2555 was integrated: "2554 Epicea: EpApplyPreviewer sourceEntries and logBrowserModel ivars not used" Pull request url: https://github.com/pharo-project/pharo/pull/2555 Issue Url: https://pharo.fogbugz.com/f/cases/2554 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2019

Re: [Pharo-dev] The HiDPI Issue

by ducasse

Hi Eric I will let esteban reply carefully :) Now my take on this is that we want to go via SDL and other backends to solve the problems (event dropping, display) Back in October, Esteban fixed the SDL/OSWindows so that Bloc people can get rid of the VM rendering and be free. This is the path to go. For Bloc I (personally and discussing with Alain) think that there is 4-6 months of work (if I would overselling it I would have said that this is 2 month work) to clean it and tight it up - (not talking about Widgets). I personnally do not want Design like Glamour or GT in the system (too many announcers). So we will take time to do real code review. So our roadmap is - make sure that Pharo can work headless - check the impact of SDL/OSWindow - focus on new spec version so that we can have our tools migrated and we do not have to rewrite them once more. Pharo 90 probably focus on Bloc. Stef > On 15 Feb 2019, at 17:52, Eric Gade <eric.gade(a)gmail.com> wrote: > > Hello, > > I know that others have posted about this before but I wanted to get the current status. > > I've recently had to buy a new laptop that came with a HiDPI display. Generally (especially on Linux systems) this makes Pharo unusable. Though there are font size increase and scaling options in the Pharo system settings, these do not work as a solution -- buttons are still tiny, there is inconsistent scaling behavior across morphic, etc. The overall problem can be described as: in Pharo, one pixel equals one "point," and so the interface is incredibly small on these HiDPI screens (3k etc). > > These HiDPI screens are becoming more common, both as laptop and as external displays. Their main advantage is that they can render text very crisply. In the HN post announcing the release of P7, there were one or two complaints about this issue. It does make it hard to demonstrate to others (as I do often) the power of developing in Pharo. > > Here are some questions I have about this issue: > 1) What is the current state of affairs in dealing with this issue, if any? > 2) Would this require VM changes (I assume it would)? If so, what might those entail? > 3) If this does require VM changes, I assume the Squeak people would want in on it? > 4) Is the current plan to wait for Bloc to resolve these issues and/or would switching to Bloc resolve these issues at all anyway? > 5) Related -- where can one start to learn about current VM architecture and development practices? > > That said I'm not here to just bellyache. While I don't have any VM experience, I'm willing to jump in and try to work on it if someone can point me in the right direction. Or perhaps this is too specialized a task... > > Thanks > > -- > Eric

Feb. 16, 2019

Re: [Pharo-dev] DisplayableObject

by ducasse

Hi pavel I spent quite some time (â¦ more days) looking at the Smalltalk ui theme and icons and I think that it will help. So let me give a real try and judge the result because the devils in the details. I do not think that displayableObject should be a superclass of Model and Iâm not sure that Model should DisplayableObject should be a subclass of Model. May be we should have a DisplayableObject and a subclass of Model. The first step is to make sure that Presenter handle theme and icons correctly that all the Presenter subclasses are clean. It will remove a lot of mess. Now I would like to have also UIManager default managed in a decent way Stef > On 15 Feb 2019, at 10:56, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi Stef, > > I think that the inclusion of DisplayableObject or something like that will not help in better system design. The only thing that should really know about how to generate forms for icons, should be the UI framework. Imagine that we will want to use something like GTK framework with vector icons. > The model classes should ideally never produce icons themselves. We should have maybe some class, an icon description. In the standard case, it will only hold the selector for the icon, but then it may add some additional data (like information about the small progress bar embedded in the icon). In the worst case it could provide as an additional property the form for the icon but then it will limit to use such thing effectively with other UI frameworks (like HTML rendering). > If we will add a DisplayableObject, we will only make easier to make models that are not strictly separated from the UI. > > Cheers, > -- Pavel

Feb. 16, 2019

Re: [Pharo-dev] The HiDPI Issue

by Ben Coman

On Sat, 16 Feb 2019 at 00:53, Eric Gade <eric.gade(a)gmail.com> wrote: > Hello, > > I know that others have posted about this before but I wanted to get the > current status. > > I've recently had to buy a new laptop that came with a HiDPI display. > Generally (especially on Linux systems) this makes Pharo unusable. Though > there are font size increase and scaling options in the Pharo system > settings, these do not work as a solution -- buttons are still tiny, there > is inconsistent scaling behavior across morphic, etc. The overall problem > can be described as: in Pharo, one pixel equals one "point," and so the > interface is incredibly small on these HiDPI screens (3k etc). > > These HiDPI screens are becoming more common, both as laptop and as > external displays. Their main advantage is that they can render text very > crisply. In the HN post announcing the release of P7, there were one or two > complaints about this issue. It does make it hard to demonstrate to others > (as I do often) the power of developing in Pharo. > > Here are some questions I have about this issue: > 1) What is the current state of affairs in dealing with this issue, if any? > This is what I understand from observing mail list discussions... For a long time Pharo has been wanting to move windowing out of the VM and into the Image and utilise FFI for the library calls. The Pharo 8 roadmap ( http://forum.world.st/Roadmap-for-Pharo-8-0-td5094949.html) includes using a true headless VM with zero windowing code as the standard Pharo VM and have windowing done from the Image. This should open up the possibility of you contributing by coding and debugging at the Image level. So stay tuned. > 2) Would this require VM changes (I assume it would)? If so, what might > those entail? > Yes. And, I don't know. Anyway, this question may end up mute if native-windowing is more exposed to Image-side as described above. 3) If this does require VM changes, I assume the Squeak people would want > in on it? > I'm sure they would broadly want the functionality. However Squeak is concerned more about backward compatibility than Pharo. They may be more conservative about following the same path as Pharo. Perhaps once Pharo has broken the ground and proved the concept Squeak could look at how to adopt it in a compatible way. For example, I wonder if its possible to isolate Squeak's VM side window initialization to a single function call that is invoked or not depending on a flag in the Image - which Pharo Images can have set moving forward, and remains unset for Squeak Images. 4) Is the current plan to wait for Bloc to resolve these issues and/or > would switching to Bloc resolve these issues at all anyway? > I'm not up to date on Bloc progress. But with the move to a headless VM, all old problems get thrown away (i.e. so we can make new problems ;) so HiDPI is likely to have the opportunity to be addressed this iteration. > 5) Related -- where can one start to learn about current VM architecture > and development practices? > https://hal.archives-ouvertes.fr/hal-01883380/document https://clementbera.wordpress.com/2016/05/30/simulating-the-cog-vm/ > That said I'm not here to just bellyache. While I don't have any VM > experience, I'm willing to jump in and try to work on it if someone can > point me in the right direction. Or perhaps this is too specialized a > task... > Hopefully it will become less specialised soon. Would you volunteer for early testing of windowing driven from Image side of headless-VM ? cheers -ben

Feb. 16, 2019

Re: [Pharo-dev] How does Metacello decide what is already loaded ?

by Sven Van Caekenberghe

Hi Dale, Thanks for the explanation. For now I managed to do what I wanted, using #onConflict #useLoaded I could prevent a dependencies' ConfigurationOf from going over a BaselineOf with the same name. Sven > On 15 Feb 2019, at 01:50, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On 2/14/19 11:28 AM, Sven Van Caekenberghe wrote: >> OK, where is the registry, how does it work, where can I read about it ? > `MetacelloProjectRegistration registry` ... It is a private registry of loaded baselines and configurations used by Metacello. It's been around roughly 6-7 years or so (ever since I added git support to Metacello and when I create the `Metacello new` style of launching Metacello loads) ... 6-7 years ago I wrote a first cut of documentation that Torsten references, but at that time no one cared about the features I had added to Metacello, because, well they pretty much applied to git-based support and using and the `Metacello new` style of launching Metacello and it was hard enought to get folks to use `Metacello new` by itself, let alone any of the "new features" ... > > Metacello started out (2009) supporting Monticello repositories (ConfigurationOf) and then transitioned (2012) to supporting git repositories (BaselineOf). Much of the complexity in Metacello is a carry over from Monticello support ... and isn't really needed. > > Today (2018) I am working on Rowan which is/will be a wholesale replacement for Monticello/Metacello and the specifications for what packages will be loaded is simplified quite a bit ... > > So it is a bit ironic, that real interest in how Metacello works comes at a time when I am well on my way to finishing a replacement for Metacello:) Okay this is not entirely true ... over the years I have been quizzed by folks and if you look through the pharo mailing list archives, you'll probably see that I've written a few long-winded mails answering questions or trying to describe how things work:) > >> >> Let's make this more concrete: I load Bootstrap which will load Seaside and I load Material Design Lite which will load Seaside. Will Seaside be loaded twice ? On what does this depend ? How can we as a community make sure we are talking about the same Seaside ? >> >> That is essentially my question. >> >> I know it is not an easy question, but I find it an important one. >> > First there is the Monticello "mcz file" answer, which applies to real .mcz files and filetree repositories with Monticello meta data. > The simplest case is a project without dependencies. > > When a Metacello load is kicked off, Metacello evaluates the configuration or baseline specification and determines the list of packages in load order that are needed to satisfy the specification. Metacello then traverses the list and compares the mcz version of the Monticello package working copy in the image with the mcz version of the Monticello package on disk those Monticello packages that are newer than the loaded packages are then loaded into the image .... (how the packages are loaded is dependent upon whether not using are using #atomic or #linear loads). > > If there is a project dependency, Metacello determines the version of the project that is loaded in the image (looking in the registry) and compares that to the incoming version of the project. If the incoming project version is greater than or equal to the loaded project (this is a simplification of reality, since individual loads can be customized to allow or disallow a number of conflicts and or default decisions made by Metacello), the packages from the dependent project are added to the list of packages in load order ... > > This process is repeated until all dependent projects are accounted for ... > > If a dependency loop is encountered as you suggest, Metacello will choose to load the latest version of the dependent project ... > > In general Metacello loads the latest version of a project encountered and the latest version of package encountered ... > > If you inspect/print the result `Metacello new ... record` you will see a collection of load directives, which details which packages will be loaded the order that they will be loaded. > > Here's an example printed load directive from a GemStone image I happen to have open (Seaside is not loaded): > > [ Metacello new > baseline: 'Seaside3'; record ] on: Warning do: [:ex | ex resume ]. > > linear load : > linear load : baseline [BaselineOfSeaside3] > load : BaselineOfGLASS1 > linear load : baseline [BaselineOfSeaside3] > load : BaselineOfGrease > linear load : baseline [BaselineOfSeaside3] > load : BaselineOfGrease > linear load : baseline [BaselineOfSeaside3] > linear load : baseline [BaselineOfGLASS1] > load : BaselineOfGrease > linear load : baseline [BaselineOfGLASS1] > load : BaselineOfMetacello > linear load : baseline [BaselineOfGLASS1] > linear load : 1.0-alpha2.2 [ConfigurationOfGoferProjectLoader] > load : Network-Url > linear load : baseline [BaselineOfGrease] > atomic load : 0.250 [ConfigurationOfGsCore] > load : Network-Url-dkh.2 > atomic load : 0.243 [ConfigurationOfGsMisc] > load : Grease-Core > atomic load : 0.243 [ConfigurationOfGsMisc] > atomic load : 0.243 [ConfigurationOfGsMisc] > load : Grease-GemStone-Core > load : Grease-GemStone330-Core > load : Grease-Tests-Core > load : Grease-Tests-GemStone-Core.v32 > linear load : baseline [BaselineOfMetacello] > load : BaselineOfFileTree > linear load : baseline [BaselineOfMetacello] > load : Metacello-Base > load : Metacello-Core > load : Metacello-MC > load : Metacello-Platform.gemstone > load : Metacello-ToolBox > load : Metacello-Cypress > load : Metacello-Tutorial > load : Metacello-TestsCore > load : Metacello-TestsMCResources > load : Metacello-TestsCommonMC.common > load : Metacello-TestsMCCore > load : Metacello-TestsTutorial > linear load : baseline [BaselineOfFileTree] > load : MonticelloFileTree-Core > load : MonticelloFileTree-FileDirectory-Utilities > load : Metacello-GS3x-Platform > load : Metacello-FileTree > load : Metacello-GitBasedRepository > load : Metacello-GitHub > load : Metacello-Bitbucket > load : Metacello-Reference > load : Metacello-TestsReference > load : Metacello-TestsMC > load : Metacello-TestsMCB > load : Metacello-TestsCypress > load : Metacello-TestsMCA > load : Metacello-TestsPlatform.gemstone > load : Metacello-GemStone-TestsMCB > load : GemStone-Interactions > load : Core.v3 > load : GemStone-Compression > load : Core322x > load : Base-Bootstrap.v3 > load : Bootstrap.v34 > load : GemStone-ANSI-Streams > load : GemStone-Indexing-Extensions.v34 > load : OmniBrowser > load : OB-GemStone-Platform > load : Squeak.v34 > load : Regex-Core > load : Regex-Tests-Core > load : GsSqueakCommon-Core > load : GsSqueakCommon-CoreV30 > load : PackageInfo-Base.g > load : Monticello.v34 > load : MonticelloGs.v33 > load : GemStone-Deployment.v310 > load : Change-Notification.v310 > load : OB-Standard.v3 > load : OB-Monticello > load : OB-SymbolListBrowser > load : OB-SUnitIntegration > load : OB-SUnitGUI.g > load : Announcements > load : OB-Tools.v33 > load : JadeServer > load : GemStone-Release-Support > load : Seaside-Squeak-Compatibility > linear load : baseline [BaselineOfGrease] > atomic load : 0.250 [ConfigurationOfGsCore] > load : Core.v3-dkh.78 > load : Core322x-dkh.2 > load : Base-Bootstrap.v3-dkh.29 > load : Bootstrap.v34-dkh.261 > load : GemStone-ANSI-Streams-dkh.9 > load : GemStone-Indexing-Extensions-dkh.3 > load : Squeak.v34-dkh.339 > load : Regex-Core-DaleHenrichs.3 > load : Regex-Tests-Core-DaleHenrichs.5 > atomic load : 0.243 [ConfigurationOfGsMisc] > load : Announcements.v3-dkh.18 > load : GemStone-Release-Support-dkh.67 > load : Grease-Core > atomic load : 0.243 [ConfigurationOfGsMisc] > atomic load : 0.243 [ConfigurationOfGsMisc] > load : Grease-GemStone-Core > load : Grease-GemStone330-Core > load : Grease-Tests-Core > load : Grease-Tests-GemStone-Core.v32 > load : Seaside-Continuation > linear load : baseline [BaselineOfGrease] > atomic load : 0.243 [ConfigurationOfGsMisc] > load : Grease-Core > atomic load : 0.243 [ConfigurationOfGsMisc] > atomic load : 0.243 [ConfigurationOfGsMisc] > load : Grease-GemStone-Core > load : Grease-GemStone330-Core > load : Grease-Tests-Core > load : Grease-Tests-GemStone-Core.v32 > load : Seaside-Core > load : Seaside-GemStone320-Core > load : Seaside-GemStone-Core > load : Seaside-GemStone-Basic-Development > load : Seaside-Tests-Core > load : Seaside-Tests-GemStone-Core > load : Seaside-Email > load : Seaside-GemStone-Email > load : Seaside-Canvas > load : Seaside-JSON-Core > load : Seaside-GemStone-JSON-Core > load : Javascript-Core > load : Javascript-GemStone-Core > load : JQuery-Core > load : JQuery-UI > load : JQuery-JSON > load : Seaside-Session > load : Seaside-GemStone-Session > load : Seaside-Component > load : Seaside-Widgets > load : Seaside-GemStone-Tools-Production > load : Seaside-RenderLoop > load : Seaside-Tools-Core > load : Seaside-Tools-Web > load : Seaside-GemStone-Tools-Web > load : Seaside-Flow > load : Seaside-Development > load : Seaside-GemStone-Development > load : Seaside-Examples > load : Seaside-Environment > load : Seaside-GemStone-Environment > load : Seaside-Tests-Functional > load : Seaside-Tests-GemStone-Functional > load : Seaside-Tests-Flow > load : Seaside-Tests-GemStone-Flow > load : Seaside-Welcome > load : Seaside-GemStone-Welcome > load : Seaside-GemStone-Continuation > load : Seaside-Tests-GemStone-Continuation > load : Seaside-GemStone-Flow > > I started off talking about the Monticello load with Monticello meta data ... If you've got a metadataless repository and you've got a projectClass method in the baseline that references MetacelloCypressBaselineProject, then Metacello will ignore the mcz version calculation and load all of the packages from the target repository (which because of git, are all of the proper version). Metacello relies on the fact that Monticello does a package definition comparison before loading which means that only the changed definitions will actually be loaded ... > > If you don't have a projectClass method in your baseline in a metadataless repository, then Metacello _will_ apply the mcz version rule and because all of the mcz version for packages in a metadataless repository is 1, Metacello will not load anything at all ... the second time you try to load the project in the repository ... > > Dale >

Feb. 15, 2019

The HiDPI Issue

by Eric Gade

Hello, I know that others have posted about this before but I wanted to get the current status. I've recently had to buy a new laptop that came with a HiDPI display. Generally (especially on Linux systems) this makes Pharo unusable. Though there are font size increase and scaling options in the Pharo system settings, these do not work as a solution -- buttons are still tiny, there is inconsistent scaling behavior across morphic, etc. The overall problem can be described as: in Pharo, one pixel equals one "point," and so the interface is incredibly small on these HiDPI screens (3k etc). These HiDPI screens are becoming more common, both as laptop and as external displays. Their main advantage is that they can render text very crisply. In the HN post announcing the release of P7, there were one or two complaints about this issue. It does make it hard to demonstrate to others (as I do often) the power of developing in Pharo. Here are some questions I have about this issue: 1) What is the current state of affairs in dealing with this issue, if any? 2) Would this require VM changes (I assume it would)? If so, what might those entail? 3) If this does require VM changes, I assume the Squeak people would want in on it? 4) Is the current plan to wait for Bloc to resolve these issues and/or would switching to Bloc resolve these issues at all anyway? 5) Related -- where can one start to learn about current VM architecture and development practices? That said I'm not here to just bellyache. While I don't have any VM experience, I'm willing to jump in and try to work on it if someone can point me in the right direction. Or perhaps this is too specialized a task... Thanks -- Eric

Feb. 15, 2019

Call for Participation: <Programming> 2019

by Fabio Niephaus

<Programming> 2019 : The Art, Science, and Engineering of Programming April 1-4, 2019, Genova, Italy http://2019.programming-conference.org The International Conference on the Art, Science, and Engineering of Programming is a new conference focused on programming topics including the experience of programming. We have named it <Programming> for short. The conference is co located with the 12th European Lisp Symposium, several workshops, a poster and a demo session and the student research competition. Registration: February 25, 2019 (Early Registration Deadline) Register: https://2019.programming-conference.org/attending/Registration Venue: Hotel Bristol Palace, Genova https://2018.splashcon.org/venue/splash-2018-venue Keynotes: Heather Miller (Carnegie Mellon University) Lars Bak (Toitware Aps) Workshops PX/19 ProWebâ19 MiniPLOP ICW: Interconnecting Code Workshop MoreVMsâ19 Salon des RefusÃ©s CoCoDo VPT Co-located Symposia 12th European Lisp Symposium (ELS) Invited Talks MoreVMsâ19: Guilherme Ottoni (Facebook) ELS: Matthew Flatt (University of Utah) ELS: Stefan Monnier (UniversitÃ© de MontrÃ©al) ELS: Christophe Rhodes (Goldsmiths, University of London) ******************************************************** ORGANIZATION ******************************************************** General Chair: Davide Ancona, University of Genova Local Organizing Chair: Elena Zucca, University of Genova Program Chair: Matthew Flatt, University of Utah Organizing Committee: Walter Cazzola (Workshops Co-Chair), UniversitÃ degli Studi di Milano Luca Franceschini (Student Volunteer Co-Chair), DIBRIS, University of Genova, Italy Philipp Haller (Student Research Competition Co-chair), KTH Royal Institute of Technology, Sweden Maurizio Leotta (Poster Co-Chair), DIBRIS, University of Genova, Italy Stefan Marr (Workshops Co-Chair), University of Kent Toni Mattis (Student Volunteer Co-Chair), Hasso Plattner Institute, University of Potsdam, Germany Ana Milanova (Student Research Competition Co-Chair), Rensselaer Polytechnic Institute Fabio Niephaus (Publicity Co-Chair), Hasso Plattner Institute, University of Potsdam Tobias Pape (Web Technology Chair), Hasso Plattner Institute, University of Potsdam Manuel Rigger (Demo Chair), Johannes Kepler University Linz, Austria Coen De Roover (Poster Co-Chair), Vrije Universiteit Brussel, Belgium Guido Salvaneschi (Publicity Co-Chair), TU Darmstadt, Germany Program Committee: Anya Helene Bagge, University of Bergen Mehdi Bagherzadeh, Oakland University Walter Cazzola, UniversitÃ degli Studi di Milano Ravi Chugh, University of Chicago Joeri De Koster, Vrije Universiteit Brussel Christos Dimoulas, Northwestern University Susan Eisenbach, Imperial College London Richard P. Gabriel, Dream Songs, Inc. & HPI Jeremy Gibbons, University of Oxford Michael Greenberg, Pomona College Philipp Haller, KTH Royal Institute of Technology Robert Hirschfeld, HPI, University of Potsdam Eunsuk Kang, Carnegie Mellon University Stephen Kell, University of Cambridge Stefan Marr, University of Kent Tamara Rezk, Inria Joshua Sunshine, Carnegie Mellon University Steffen Zschaler, King's College London ******************************************************** <Programming> 2019 is kindly supported by AOSA ******************************************************** For more information, visit http://2019.programming-conference.org

Feb. 15, 2019