Skip to content

2024 01 09 Eclipse iceoryx developer meetup

Jump to bottom
Mathias Kraus edited this page Jan 9, 2024 · 5 revisions

Eclipse iceoryx developer meetup

Date: 2024/01/09

Time: 17:00 CET

Link: https://app.element.io/jitsi.html#conferenceDomain=meet.element.io&conferenceId=JitsiVtfrqukadefbqiqfxryxabai&userId=&roomId=!AooDAAwkyNWwkMElpt%3Agitter.im&roomName=eclipse%2Ficeoryx&startWithAudioMuted=true&startWithVideoMuted=true&language=en

Attendees

  • Matthias Killat, Apex.AI
  • Simon Hoinkis, Apex.AI
  • Graham Palmer, Latitude AI
  • Christian Eltzschig, Apex.AI
  • Marika Lehmann, Apex.AI
  • Dennis Liu
  • Mathias Kraus,ekxide

Agenda

  1. Look at the open tasks from previous meetings, 10 min, Mathias
    • Adding the new meeting date to the ROS 2 calendar
    • Update iceoryx.io to inform about the new Rust implementation - maybe also register iceoryx.rs - how to restructure iceoryx.io for the new Rust implementation
  2. If there is time, talk about a common coding style for iceoryx, 15 min, Mathias
    • currently it is different for parts of hoofs and the rest of the codebase
    • see also
    • proposal
      • CamelCase for classes to prevent confusion with STL types
      • snake_case for free functions and methods
      • snake_case for variables and members (members with a m_ prefix)
      • snake_case for type traits, they are similar to variables in template meta-programming after all and are quite often used on the same line like STL type traits
      • CamelCase for enums
      • SCREAMING_SNAKE_CASE for enum tags (we might need to rethink this; according to the C++ core guidelines this should be avoided to prevent name clashes with macros)
      • SCREAMING_SNAKE_CASE for constants
      • SCREAMING_SNAKE_CASE for macros but with an IOX_ prefix
    • it's basically what we have now but defines one style in case there are currently two in use
      • snake_case for some classes and methods in hoofs
      • CamelCalse for classes and lowerCamelCase for methods in the remaining codebase
      • since the API surface in posh is smaller than in hoofs, going with snake_case for methods should have the lesser impact than the other way around
      • we can provide a using declaration for classes with snake_case during the v3 lifetime with a doxygen deprecation warning
      • deprecate snake_case classes with v4 using the C++ deprecate attribute
      • if someone wants to keep the snake_case classes it is a simple using declaration in their code
      • for methods and functions we could think of a similar strategy

Minutes

  1. Move everything to the next meetup
  2. There was consensus on the proposal
    • We need to think about the SCREAMING_SNAKE_CASE
    • this is something for the v4 release to not delay the v3 release even more

Topics for future meetings

  1. Move C-binding to separate repo?
    • #2030
Clone this wiki locally