profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/contre/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

contre/Windows-API-Code-Pack-1.1 91

Windows API Code Pack 1.1

contre/cpp-doom 0

C++ Doom is a C++ fork of Crispy Doom 5.7.2 which is a limit-removing enhanced-resolution Doom source port based on Chocolate Doom.

contre/HighFive 0

HighFive - Header-only C++ HDF5 interface

contre/llvm-project 0

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

contre/pyFDT 0

Flattened Device Tree Python Module

contre/STL 0

MSVC's implementation of the C++ Standard Library.

contre/vcpkg 0

C++ Library Manager for Windows, Linux, and MacOS

startedcontre/Windows-API-Code-Pack-1.1

started time in 6 days

issue commentaras-p/ClangBuildAnalyzer

Wrong printf format specifiers for int64_t

Yep, good point.

randomascii

comment created time in 7 days

issue commentaras-p/ClangBuildAnalyzer

Wrong printf format specifiers for int64_t

%lld is probably fine, but the pedantically correct thing is to use the PRId64 macro from <stdint.h> or <cstdint>. https://en.cppreference.com/w/cpp/types/integer

randomascii

comment created time in 7 days

issue openedaras-p/ClangBuildAnalyzer

Wrong printf format specifiers for int64_t

In DebugPrintEvents %7ld is used to print a pair of int64_t values. When compiling with Visual Studio that leads to printf mismatch warnings because on Windows (32-bit or 64-bit) long is a 32-bit value.

I believe that %7lld is a portable 64-bit format value. It definitely works for 32-bit and 64-bit Windows processes. This is the updated line of code that I used to fix the warnings:

    printf("%4zi: t=%i t1=%7lld t2=%7lld par=%4i ch=%4zi det=%s\n", i, (int) event.type, event.ts, event.ts+event.dur, event.parent.idx, event.children.size(), std::string(names[event.detailIndex].substr(0,130)).c_str());

created time in 8 days

issue openedaras-p/ClangBuildAnalyzer

Build failure with CMake because of #define min/max in Windows.h

ClangBuildAnalyzer pulls in Windows.h at several points, leading to these compilation errors:

src\main.cpp(175): error C2589: '(': illegal token on right side of '::'
src\external\flat_hash_map\flat_hash_map.hpp(1282): error C2589: '(': illegal token on right side of '::'

It looks like you've avoided this in the Visual Studio project by adding a global NOMINMAX define.

This should be done for the CMake build as well. I fixed it locally by adding this to CMakeLists:

target_compile_definitions(ClangBuildAnalyzer PRIVATE "NOMINMAX")

created time in 11 days

issue commentcontre/Windows-API-Code-Pack-1.1

Nuget release?

Interested in this as well.

DanFTRX

comment created time in 18 days

issue commentcontre/Windows-API-Code-Pack-1.1

Nuget release?

@contre anything I could do to help move this along?

DanFTRX

comment created time in 22 days

issue openedaras-p/ClangBuildAnalyzer

crash when running --all on a very large project

ClangBuildAnalysis is a great tool and it has really helped me improve the build time of a large project I am working on.

My project is so large that the code crashes when loading the json files. I believe it is running out of memory while parsing the json dom. my project has 83GB of json files. I have run ClangBuildAnalyzer on all the files and I can analyze all of them if I do it in two groups, with the 51 largest json files in one group and the other 241 files in the other group.

While debugging, I changed the max tasks to 1 in main.cpp, hoping that parsing 1 json at a time would reduce the memory footprint. It may have gotten farther, but ClangBuildAnalyzer still crashed.

I tried using gdb to see the crash, but the app is killed due to out of memory, instead of core dumping, so gdb didn't give me any useful information.

I wondered if there was a memory leak or other bug in the json parsing. I manually copied the latest release of simdjson (0.9.4) into ClangBuildAnalyzer and rebuilt. I still got the same crashes.

I am currently using clang-11. I had more luck with ClangBuildAnalyzer on this project in the past and may have been using clang-10. I wonder if clang-10 writes fewer events? I do not see any warnings about unknown events while running ClangBuildAnalyzer with clang-11.

Could ClangBuildAnalyzer support a batch mode to support large projects? For example, I could run ClangBuildAnalyzer -all <subdirN> on the N subdirs of my build. Then, I would run ClangBuildAnalyzer --analyze with N file names instead of 1. ClangBuildAnalyzer would then read all N binary event files and concatenate all the data together before producing the statistics over the combined set of all events.

I have studied the LoadBuildEvents() method and believe it could be possible to have it append new files to the current event and names lists, but haven't had time to do it yet, especially making the event to name index is updated correctly.

created time in 25 days

Pull request review commentaras-p/ClangBuildAnalyzer

Fix build on MinGW (MSYS2)

 set(SRC ) add_executable(ClangBuildAnalyzer "${SRC}") target_compile_features(ClangBuildAnalyzer PRIVATE cxx_std_17)-target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)++if (MINGW)

This one was addressed in a different way by #62, and now would be conflicting.

SuperV1234

comment created time in a month

delete branch aras-p/ClangBuildAnalyzer

delete branch : actions

delete time in a month

push eventaras-p/ClangBuildAnalyzer

Aras Pranckevicius

commit sha ddd3e2aac9fa1851a7b7f74468517f23c2ae765c

Actions: move to Ubuntu 18 (looks like Github dropped Gcc 7 from Ubuntu 17 image)

view details

Aras Pranckevicius

commit sha 13f2bdf168ad9d0b99a345d1c14addc0594e5fc2

Actions: build with cmake on Mac too, for extra coverage

view details

Aras Pranckevičius

commit sha e121bf36a9eee1aee76c88236ca420dbb7b11b13

Merge pull request #70 from aras-p/actions Improvements to Github Actions CI

view details

push time in a month

issue closedaras-p/ClangBuildAnalyzer

CMake does not work on macOS due to rt requirement

The rt library is unconditionally added as requirement in file CMakeLists.txt:

target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)

This library is not present on macOS, and hence the build fails.

When I remove the -lrt entry, building succeeds.

The line above should be changed like:

if (APPLE)
  target_link_libraries(ClangBuildAnalyzer -lpthread)
else()
  target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)
endif()

I can make a PR if requested.

closed time in a month

nlohmann

issue commentaras-p/ClangBuildAnalyzer

CMake does not work on macOS due to rt requirement

Ok, blindly merged #62 (GitHub Actions are seemingly failing everywhere with internal errors today). 🤞

nlohmann

comment created time in a month

push eventaras-p/ClangBuildAnalyzer

Jérémie Dumas

commit sha b825054631baf92e2c29939818d98d737d0b7fe1

Update CMakeLists.txt for macOS.

view details

Aras Pranckevičius

commit sha 516acfa8663ad2316102df1233bbc618288375b4

Merge pull request #62 from jdumas/master Update CMakeLists.txt for macOS.

view details

push time in a month

PR merged aras-p/ClangBuildAnalyzer

Update CMakeLists.txt for macOS.

This is a duplicate of #55, but rather than hardcoding rules depending on the OS, I'm using CMake to discover -lrt or -lpthread.

+8 -1

1 comment

1 changed file

jdumas

pr closed time in a month

push eventaras-p/ClangBuildAnalyzer

Aras Pranckevicius

commit sha 13f2bdf168ad9d0b99a345d1c14addc0594e5fc2

Actions: build with cmake on Mac too, for extra coverage

view details

push time in a month

create barncharas-p/ClangBuildAnalyzer

branch : actions

created branch time in a month

push eventaras-p/ClangBuildAnalyzer

Simon Giesecke

commit sha faf3dcab635a681bdda0270ea92e19486136d73b

Update cute_files.h to upstream f04e37c5a8ba1c7ce385b0f38b584bec1056e831

view details

Simon Giesecke

commit sha dd8ade7d81c659fddff5aa34062cf2df82d34b19

Revert CUTE_FILES_MAX_EXT to 64

view details

Aras Pranckevičius

commit sha 8d1319978b49d159177cc363a960e33774ad8c5f

Merge pull request #58 from sigiesec/update-cute-files Update cute_files.h to upstream f04e37c5a8ba1c7ce385b0f38b584bec1056e831

view details

push time in a month

issue closedaras-p/ClangBuildAnalyzer

../src/external/cute_files.h:427: int cf_dir_open(cf_dir_t*, const char*): Assertion `0' failed on ClangBuildAnalyzer --stop

Recently, when trying to use ClangBuildAnalyzer to analyze a firefox build, I got the following error and assertion failure on ClangBuildAnalyzer --stop:

ERROR: Failed to open directory (obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd): No such file or directory.
ClangBuildAnalyzer: ../src/external/cute_files.h:427: int cf_dir_open(cf_dir_t*, const char*): Assertion `0' failed.

obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd exists, but is a symbolic link to a file, not a directory:

[simon@sigibln fuzzy]$ stat obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd
  File: obj-x86_64-pc-linux-gnu-trace/dist/bin/chrome/en-US/locale/en-US/mozapps/downloads/settingsChange.dtd -> /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
  Size: 88              Blocks: 8          IO Block: 4096   symbolic link
Device: fd02h/64770d    Inode: 34560445    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/   simon)   Gid: ( 1000/   simon)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2020-10-21 18:42:33.948517287 +0200
Modify: 2020-10-14 18:48:03.012265746 +0200
Change: 2020-10-14 18:48:03.012265746 +0200
 Birth: 2020-10-14 18:48:03.012265746 +0200
[simon@sigibln fuzzy]$ stat /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
  File: /home/simon/work/fuzzy/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 49026953    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   simon)   Gid: ( 1000/   simon)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2020-10-22 09:43:44.048022446 +0200
Modify: 2020-10-22 09:43:34.870015064 +0200
Change: 2020-10-22 09:43:34.870015064 +0200
 Birth: 2020-10-22 09:43:29.366010639 +0200

closed time in a month

sigiesec

pull request commentaras-p/ClangBuildAnalyzer

Update cute_files.h to upstream f04e37c5a8ba1c7ce385b0f38b584bec1056e831

@aras-p I reverted that change as you requested, can this be merged now?

sigiesec

comment created time in a month

startedcontre/Windows-API-Code-Pack-1.1

started time in a month

startedcontre/Windows-API-Code-Pack-1.1

started time in 2 months

issue commentaras-p/ClangBuildAnalyzer

CMake does not work on macOS due to rt requirement

Yes, #62 would fix this.

nlohmann

comment created time in 2 months

issue commentaras-p/ClangBuildAnalyzer

CMake does not work on macOS due to rt requirement

There's already that fixes this problem: https://github.com/aras-p/ClangBuildAnalyzer/pull/62

@aras-p may I kindly ask you to take a look, please?

nlohmann

comment created time in 2 months

issue openedaras-p/ClangBuildAnalyzer

CMake does not work on macOS due to rt requirement

The rt library is unconditionally added as requirement in file CMakeLists.txt:

target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)

This library is not present on macOS, and hence the build fails.

When I remove the -lrt entry, building succeeds.

The line above should be changed like:

if (APPLE)
  target_link_libraries(ClangBuildAnalyzer -lpthread)
else()
  target_link_libraries(ClangBuildAnalyzer -lrt -lpthread)
endif()

I can make a PR if requested.

created time in 2 months

PR opened aras-p/ClangBuildAnalyzer

Fix build on MinGW (MSYS2)

mtime.time is of type FILETIME when compiling under MinGW x64 using MSYS2. The presence of -lrt causes a linker error as well, removing it fixes the issue.

+8 -3

0 comment

2 changed files

pr created time in 2 months

issue commentcontre/Windows-API-Code-Pack-1.1

Nuget release?

NuGet release?

DanFTRX

comment created time in 2 months