Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 22:03
    mloskot commented #599
  • 22:02
    mloskot commented #599
  • 21:59
    mloskot commented #453
  • 21:39

    github-actions[bot] on gh-pages

    deploy: 0a21d741ce06ad3a880efb0… (compare)

  • 21:10
    mloskot labeled #599
  • 21:10
    mloskot labeled #599
  • 21:10
    mloskot unlabeled #599
  • 21:09
    mloskot edited #599
  • 21:08
    mloskot ready_for_review #599
  • 21:06
    mloskot edited #599
  • 21:06
    mloskot edited #599
  • 21:06

    mloskot on develop

    test: Verify core IO headers ar… (compare)

  • 21:04
    codecov[bot] commented #599
  • 21:04
    mloskot synchronize #599
  • 19:23
    codecov[bot] commented #599
  • 19:23
    mloskot synchronize #599
  • 18:36
    mloskot opened #605
  • 18:36
    mloskot labeled #605
  • 18:36
    mloskot milestoned #605
  • 18:36
    mloskot labeled #605
Mateusz Łoskot
@mloskot
:point_up: October 12, 2019 6:17 PM This is not enough
Olzhas Zhumabek
@simmplecoder
I went with a very simple approach of creating library boost and shoving include directories and required binaries with set_target_properties
Mateusz Łoskot
@mloskot
I'll put kids to bed and will give you more explanation
Olzhas Zhumabek
@simmplecoder
no need, only if you'd like to
and thanks
Mateusz Łoskot
@mloskot

Step 1: Lightweight clone of Boost superproject (without --recurse-submodules)

git clone https://github.com/boostorg/boost.git

Step 2: Clone libraries required by GIL

Method 1: Roll required git submodule update --init-s manually as https://github.com/boostorg/gil/blob/develop/.ci/get-boost.sh#L28-L86

Method 2: Run python tools/boostdep/depinst/depinst.py gil that does it automatically https://github.com/boostorg/boostdep/blob/develop/depinst/depinst.py

Step 3: Deploy headers of libraries required by GIL

Method 1: Just build your project with b2 and the magic should happen.

Method 2: Run b2 headers inside the Boost superproject tree and it will deploy all required Boost headers where all Boost libraries look for them (ie. boost/ subdirectory of the tree)

Finally, to configure your CMake project using GIL headers you just need:

find_package(Boost REQUIRED)

add_executable(myexe ...)
target_link_libraries(myexe Boost::boost)
This is minimum to understand in order to use any header-only Boost libraries in CMake project .
Olzhas Zhumabek
@simmplecoder
thanks! I'll try to setup reproducible builds tomorrow, and I hope to make a small example with heterogeneous memory management approach I have in mind tomorrow. I'd like to take the most pragmatic approach to it for now
Mateusz Łoskot
@mloskot
@simmplecoder Keep in mind that instead of cloning Boost and its submodules, you can try apt-get install libboost-dev to get all Boost headers and they you can just git clone ..../boostorg/gil.git and build GIL-based programs using the system-wide installed Boost.
This is what I called lightweight mode in here https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md#using-cmake
Obviously, using ancient Boost .1.60 with GIL's develop may be not working well :-) Prefer fairly recent Boost releases
Olzhas Zhumabek
@simmplecoder
yeah, I was thinking of something like that. I saw an issue though that was related to built-in boost causing troubles
I'll try a CI setup tomorrow, going to sleep for now. Good night
Olzhas Zhumabek
@simmplecoder
I started reading the design guide again ... and found that I could avoid so much typing by just reading that document
Mateusz Łoskot
@mloskot
From my own fairly long experience with GIL, I can only confirm that returning back to the docs is worth it. They may feel overwhelming at first but that is why reaching them frequently pays off
Mateusz Łoskot
@mloskot
Speaking of docs, I need to get back to structuring the image processing.
I want to create chapters almost directly based on structuring proposed in "Principles of Digital Image Processing" by Burger & Burge
Mateusz Łoskot
@mloskot
@miralshah365 I'm looking at your PR. Please, take the nitpicking comments as just comments for some future consideration, not as request for changes now
Mateusz Łoskot
@mloskot
This seems like a cool idea for a pet project for GIL user
https://www.pyimagesearch.com/2015/09/07/blur-detection-with-opencv/
Olzhas Zhumabek
@simmplecoder
I'm writing senior project regarding 3d gaze estimation. I'm still unsure though how to integrate GIL with CUDA. The simplest approach is I believe just creating some sort of a buffer that would hold the content part of image, then just add ability to create image_views from it. I have no idea though how to initialize image_view with just a pointer, or if it is even possible. Too many abstraction layers to peel off
Mateusz Łoskot
@mloskot
Look at interleaved_view and other view creating functions.
If not inside GIL source tree, web search for interleaved_view and you will find lots of examples. I think it's one of most popular GIL function :-)
Olzhas Zhumabek
@simmplecoder
nvcc seems to choke on GIL real hard. I believe I'll need to setup some sort of incremental compilation or something like that
I believe it is because it tries to compile every function, and it needs to do some register allocation stuff which slows it down
Mateusz Łoskot
@mloskot
I wish I could help, but zero experience with CUDA here.
You may have much better luck on channels of cpplang.slack.com, #cuda, #gpu etc
Olzhas Zhumabek
@simmplecoder
thanks! I believe I'll be able to take it from here. May be create a cpp file that I could just link to, and compile only once
Olzhas Zhumabek
@simmplecoder
I have a question: is there any reason why add_deref functions need type specified in the type itself? I believe making the function a template would make it so much easier to use, because I found that I have to write auto deref_fn = [](...){...}; auto deref_view = ...::add_deref<decltype(deref_fn)>(view, deref_fn); instead of just writing the lambda inline
it might be a breaking change though, and I believe it will break ABI as template parameter will get mangled into the name
I believe one solution would be to just write a global function that would just place the right types. May be there is already something similar?
Mateusz Łoskot
@mloskot

@simmplecoder

is there any reason why add_deref functions need type specified in the type itself?

I have never analysed / considered that myself. Possibly C++98 kind of legacy.
I'm not aware of any 'factory' function deducing the types.

IMHO, breaking API/ABI is fine, especially if it will help to modernise GIL as well as GIL users codebase.
If it is not possible to extend/overload existing functions, then breaking is the only way.

What I'd suggest is: get your idea implemented, submit PR for review, and let's see.

Mateusz Łoskot
@mloskot
@miralshah365 & @simmplecoder :point_right: https://lists.boost.org/boost-gil/2019/10/0314.php
Olzhas Zhumabek
@simmplecoder
roger that
Mateusz Łoskot
@mloskot
It's certainly not a request, rather FYI :)
Pranam Lashkari
@lpranam
are we going to release any GSoC work with this release?
Mateusz Łoskot
@mloskot
Yes, as stated in the thread
Pranam Lashkari
@lpranam
I have a few comments I'll share in the mail
BTW have we decided till wich commit we are going to release?
Mateusz Łoskot
@mloskot
I think @stefanseefeld will do the grand merge of everything in develop
@lpranam If you want to share any feedback, objection, suggestion, please do it ASAP following up to the boost-gil thread
Pranam Lashkari
@lpranam
@mloskot just sent the mail
Pranam Lashkari
@lpranam
it awaits approval
Mateusz Łoskot
@mloskot
Looks like you are not subscribed. I will accept your post this time
Pranam Lashkari
@lpranam
This is my first email to GIL-list that's why
Mateusz Łoskot
@mloskot
Indeed. I did not realise the moderation flag is on by default for new posters
Mateusz Łoskot
@mloskot

@stefanseefeld Since time will run short soon, I have to nudge you to ensure you got this on time. Please, have a look at

Thanks @lpranam for heads up!

Stefan Seefeld
@stefanseefeld
@mloskot Thanks. https://lists.boost.org/boost-gil/2019/10/0316.php is referring to a commit to develop, no ? Is there anything left to do ? (other than merge develop to master, I mean ?)
I can certainly do the merge once you confirm that develop is complete, i.e. there are no other expected commits targeted for 1.72.
Mateusz Łoskot
@mloskot
Yes, I made those adjustments in develop only.
Outstanding is this one PR by @simmplecoder waiting for your review https://github.com/boostorg/gil/milestones/Boost%201.72
Once that is merged to develop
Or postponed after 1.72 (milestone removed)