Code Monkey home page Code Monkey logo

ptc-print's Introduction

Hi there, I'm Gianluca! 👋

Some information

I'm a PhD student in particle physics at the University of Bologna and associate member of INFN. I am currently working for the ATLAS detector experiment at CERN. My research topics are related to the following fields:

  • Investigation of top-quark properties through the analysis of data sampled by the ATLAS detector.
  • Usage of quantum computing to boost particle physics researches.
  • Development of software tools to monitor the ALTAS RPC detector performance using the DCS data.

During my free time I am also an active open-source developer:

  • 📫 To contact me send an email.
  • 💬 For collaborations send a pull request or fork one of my repo.
  • ⬆️ Found a bug in one of my projects? Open an issue.

If you want to support me you can buy me a coffee!

Buy Me A Coffee


Tools I use


Links to my webpages


My statistics





3D profile statistics graph


Personal projects

Quantum computing


Applications

Machine learning

Utility



Games

Physics

Collections



Other


Contributing projects

Quantum computing

Utility


My latest scientific papers

  1. A method for the study of the quantum interference between singly and doubly resonant top-quark production in proton-proton collisions at the LHC with the ATLAS detector
  2. Software training in HEP

Trophies


If you like a repo, don't forget to leave a star! ⭐

ptc-print's People

Contributors

allcontributors[bot] avatar justwhit3 avatar miikaa3 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

ptc-print's Issues

Reduce the high compile time

Describe the bug
As shown in this plot:

image

The compilation time of the ptc::print function is too high with respect to the one of other libraries. It needs to be improved.

To Reproduce
Steps to reproduce the behavior:

  1. Run the script studies/benchmarking_compilation/run.sh

Expected behavior
I am expecting a compilation time at least comparable to the one of fmt::print.

Enable printing of SFML types

Enable the printing of SFML types. The idea is to create a new header which hosts overload of operator << to print different SFML basic types.

First impression (duplicate from reddit)

The library looks cool, but I think that fmtlib is much more flexible in general and it has already supported printing all the possible types. I think that such library will have a way better perspective it would be frontend for fmtlib that would convert pythonic

ptc::print("I am", "very similar to Python", 123, sep = " ", end = "\n" );

to

fmt::print("{} {} {}\n", "I am", "very similar to Python", 123);

It would allow not to repeat the same job for supporting formatting of each std container for PTC authors and more importantly it would allow not to repeat stringification code for each User-Defined Types.

I'm sure users would prefer to write

#include <fmt/format.h>

struct point {
  double x, y;
};

template <> struct fmt::formatter<point> {
  // Presentation format: 'f' - fixed, 'e' - exponential.
  char presentation = 'f';

  // Parses format specifications of the form ['f' | 'e'].
  constexpr auto parse(format_parse_context& ctx) -> decltype(ctx.begin()) {
    // [ctx.begin(), ctx.end()) is a character range that contains a part of
    // the format string starting from the format specifications to be parsed,
    // e.g. in
    //
    //   fmt::format("{:f} - point of interest", point{1, 2});
    //
    // the range will contain "f} - point of interest". The formatter should
    // parse specifiers until '}' or the end of the range. In this example
    // the formatter should parse the 'f' specifier and return an iterator
    // pointing to '}'.

    // Please also note that this character range may be empty, in case of
    // the "{}" format string, so therefore you should check ctx.begin()
    // for equality with ctx.end().

    // Parse the presentation format and store it in the formatter:
    auto it = ctx.begin(), end = ctx.end();
    if (it != end && (*it == 'f' || *it == 'e')) presentation = *it++;

    // Check if reached the end of the range:
    if (it != end && *it != '}') throw format_error("invalid format");

    // Return an iterator past the end of the parsed range:
    return it;
  }

  // Formats the point p using the parsed format specification (presentation)
  // stored in this formatter.
  template <typename FormatContext>
  auto format(const point& p, FormatContext& ctx) const -> decltype(ctx.out()) {
    // ctx.out() is an output iterator to write to.
    return presentation == 'f'
              ? fmt::format_to(ctx.out(), "({:.1f}, {:.1f})", p.x, p.y)
              : fmt::format_to(ctx.out(), "({:.1e}, {:.1e})", p.x, p.y);
  }
};

and then write

fmt::print("point: {}\n", point{0.0, 0.0});
fmt::print("point2: {:e}\n", point{-10.0, 10.0});
ptc::print("point3:", point{6.0, 7.0});

rather than writing formatter overload twice for each library.

Btw, even in this example, I don't see any way to select floating point representation in ptc::print, so it either can't print non-default representation, or values should be somehow wrapped into formatter.

Unable to print `std::stack` and `std::priority_queue`

Describe the bug
Unable to print std::stack and std::priority_queue containers, using the operator << overload defined in print.hpp. An error occurs:

../include/ptc/print.hpp:129:5: error: no matching function for call to ‘begin(const std::stack<int>&)’
  129 |     for ( const auto& elem: container )
      |     ^~~

To Reproduce
Steps to reproduce the behavior:

  1. Compile this program:
#include <ptc/print.hpp>
#include <stack>

int main()
 {
  std::stack <int> stack;
  stack.push( 21 );
  stack.push( 22 );
  stack.push( 24 );  

  ptc::print( stack );
 }

with g++ -std=c++17 program.cpp.

Expected behavior
I am expecting a clear compilation and this output:

[21, 22, 24]

Unable to print using `std::wcout`, `std::wcerr` and `std::wclog`

Describe the bug
The ptc::print function is unable to print using std::wcout, std::wcerr and std::wclog wostream objects. An error occurs:

../include/ptc/print.hpp:431:11: error: no match for ‘operator<<’ (operand types are ‘std::basic_ostream<wchar_t>’ and ‘const std::__cxx11::basic_string<char>’)
  431 |        os << getEnd();
      |        ~~~^~~~~~~~~~~

To Reproduce
Steps to reproduce the behavior:

  1. Compile this line of code: ptc::print( std::wcout, "Something" )

Expected behavior
I am expecting to have a clean compilation.

Linking Error: multiple definition of `ptc::__print__::mutex_` and `ptc::print`

I was testing ptc::print in this very simple example:

// -- logerror.hpp
#pragma once
#include "print.hpp"
void logerror(const char*);

// -- logerror.cpp
#include "logerror.hpp"
void logerror(const char* msg)
{
    ptc::print("\033[31m", "[ERROR]:", msg);
    return;
}

// -- main.cpp
#include "print.hpp"
#include "logerror.hpp"
int main()
{
    ptc::print("Hello World!";
    logerror("uh oh, spaghgetti-o");
    return 0;
}

This complies successfully but when it attempts to link, the linker complains about multiple definitions of ptc::__print__::mutex_ and ptc::print which makes sense given that I ostensibly #include print.hpp twice, it leads to two instantiations of the mentioned objects. I think this would successfully and simply be resolved by inling the definitions and declarations of those objects.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.