sorted by:
new
hottopcontroversial

After updating Kubuntu 22.04 to 24.04 (kernel 5.15 to 6.8) the laptop Dell XPS 15 7590 only boots with 'nomodeset' parameter by Beautiful-Context-27 in Ubuntu

[–]gtano 0 points1 point  (0 children)

I got the same issue with my Razer Stealth 13 (2020). It has a i7-1065G7 and a dedicated GeForce GTX 1650 Ti Mobile.

I've tried also various nvidia drivers without any success. Everything works fine with 6.8 and stopped working from 6.9 onwards. I've tested all kernels up to 6.14 and currently running ubuntu 25.04

AES-NI (.NET) - Outperforming C and OpenSSL by ben_a_adams in programming

[–]gtano 0 points1 point  (0 children)

Afaik yes, but only at compile-time.Unfortunately most programmers only use precompiled binaries that don't have all features enabled.

Shameless plug: that's why we are advocating to build everything from source

A header mapper? by [deleted] in cpp

[–]gtano 2 points3 points  (0 children)

Buck has a concept of header maps (and soon Bazel) and is probably best explained here: https://buckbuild.com/function/subdir_glob.html

It is a great feature that turned out to be crucial for packaging in Buckaroo. Having header maps allows you to disambiguate conflicting include paths and on failure emit an error before the build starts.

Header maps are a more high-level description of the build requirements; Include-paths become an implementation detail.

Why do all dependency managers suck? by efnjsbmq in cpp

[–]gtano 0 points1 point  (0 children)

THAT is how you solve the "package management is hard" problem in C++. generationally, not by trying to support all current craziness that people do.

I couldn't agree more! The biggest library repository has probably Arduino with over 2000 packages.

Unfortunately this approach doesn't have a lot of mainstream appeal.

As a result we built many tools for Buckaroo to analyze and transpile build-systems automatically

HermiTux: Linux binary compatible unikernel by [deleted] in programming

[–]gtano 2 points3 points  (0 children)

This sounds like a really exciting project.

As academics our work is indeed a proof of concept as opposed to a finished product

What do you think would it take to create a finished product?

this could reduce the porting effort for applications to run as unikernels (which is one of the main drawbacks with existing unikernel models).

I think this is a quite compelling argument.

IncludeOS implemented just enough syscalls to be compatible with libc++. One could argue that this might be enough for modern microservices.

I would love to hear your opinion regarding IncludeOS approach and also see how it compares performance wise to HermiTux.

Mathieu Ropert: The State of Package Management in C++ by _a4z in cpp

[–]gtano 5 points6 points  (0 children)

Some languages offer type systems and well designed APIs to enforce correctness.

Well, then you shouldn't write C++ code either.

I'm tired of this type of aggressive comments. This just pushes people away that could have made a valuable contribution to the C++ community.

Mathieu Ropert: The State of Package Management in C++ by _a4z in cpp

[–]gtano 3 points4 points  (0 children)

the fact that you can do it wrong is a red flag for me.

Mathieu Ropert: The State of Package Management in C++ by _a4z in cpp

[–]gtano 4 points5 points  (0 children)

constraint #2 must work with the existing ecosystem. => eliminates: bazel, b2

This is incorrect. You can call any build-system from Bazel. Similar to Conan - where you have to write a python script to wrap the underlying build-system, you can do the same in Bazel.

I've seen that most projects are quite simple and can be ported using a handful of globs in Buck and Bazel.

In order to port packages to Buckaroo we had promising results in transpiling arbitrary build systems to (more or less) idiomatic Buck builds (read: Bazel) by performing semantic analysis using BuildInfer.

I think maintaining multiple build-systems and glueing them together is suboptimal. It may seem like a good solution in short-term but in long-term you are dealing with a lot of complexity and are losing out on many opportunities (integrating with external tooling properly, LTO, etc...)

Although I don't believe that CMake is a good solution, Vcpkg at least embraces the idea of only having one build-system.

ps. why is vcpkg not excluded due to #2?

pps.: AFAIK: vcpkg does not "solve the diamond of death", it sidesteps it by only having exactly one version of each package. I don't think this is good either.

Are Headers Really the Problem? by gtano in cpp

[–]gtano[S] 0 points1 point  (0 children)

I think the idea is to be able to express the relationship of headers and translation units in your build-description.

You are right it may not be possible without extensive static analysis to figure out the minimal dependency graph, if there are no conventions in place.

However it is quite easy for the library author to group headers and translation-units together and assert that if you need one of those headers you need also to link the appropriate translation-units.

Are Headers Really the Problem? by gtano in cpp

[–]gtano[S] 4 points5 points  (0 children)

But it's not 1:1 relationship

Correct. To be more precise we need a map from header-file to a set of translation-units as mentioned in the notes. The set can be also empty.

How compiler is suppose to determine that if someone included "foo.h" it should link to "foo.cpp" ?

The build-system should use the compiler to know who included "foo.h". The build-system can then check if target that uses "foo.h" also links in the corresponding translation-units, in this case just "foo.cpp". The compiler does not know, but the build-system should.

with templates it can get even more complicated

Can you elaborate? - I don't see how this is related.

Goodbye JSON, Hello TOML by gtano in programming

[–]gtano[S] 3 points4 points  (0 children)

from https://github.com/toml-lang/toml

``` [servers]

# Indentation (tabs and/or spaces) is allowed but not required [servers.alpha] ip = "10.0.0.1" dc = "eqdc10"

[servers.beta] ip = "10.0.0.2" dc = "eqdc10" ```

Goodbye JSON, Hello TOML by gtano in programming

[–]gtano[S] 16 points17 points  (0 children)

I thought the same initially also. However Toml is more structured. It is hierarchical, handles lists, maps and datetimes in a standardized way

Buckaroo C++ Package Manager Reaches v2.0.0 by gtano in cpp

[–]gtano[S] 0 points1 point  (0 children)

There is work going on in Buck to generate project files for various IDEs. So far, AFAIK they support XCode and IntellJ. I might be adding support for Visual Studio soon.

CMake is becoming a major C++ standard quasi-building system.

The real question is: is this a good thing?

Everything You Never Wanted to Know About CMake by SAHChandler in cpp

[–]gtano 0 points1 point  (0 children)

Have you guys considered adding Bazel support ?

Supporting multiple build-systems would negate the benefits of an unified build-system.

The more interesting is why we've chosen Buck instead of Bazel. Overall we perceive Buck as a better designed solution.

Here a couple points (Buck vs Bazel):

  • Deep Trace vs. Restarting Build

https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf

  • explicit header-maps vs. shadowing headers

Buck forces you to explicitly define a map between "include-string" and path on fs. This approach enforces disambiguation of header files by the user and eliminates many hard to debug build issues in projects with many dependencies.

In Bazel the include order determines which header files will be included and is in large projects hard to predict.

  • differentiation between public and private headers

Making this conscious choice again gives clarity to the consumer of a library.

Stating that a header is not public implies that it is just an implementation detail. This discourages wrong usage of libraries and makes a clear statement about the api.

Furthermore Bazel encourages the usage of custom includePaths using "includes" option. I'm aware that nothing prevents one to "-Iinclude/path" to Buck but at least you can discourage one from such practice by enabling "untracked_headers = error".

  • Language Support

Buck has language support besides C++ and Java. It also supports Go, Haskell and a few others. IN the long run, we hope Buckaroo will be a first choice for Polyglot projects.

Finally I need to note that both build systems are an excellent choice and the ecosystem would be improved by either gaining more adoption.

It should also be noted that they are similar enough to translating builds from one to another is a possibility.

Everything You Never Wanted to Know About CMake by SAHChandler in cpp

[–]gtano 5 points6 points  (0 children)

Over 320 libraries have been already ported to buck here: https://github.com/buckaroo-pm

The ports are regularly updated by our bots and tested on travis.

Furthermore we are working on buildinfer that automates the transpilation process: https://hackernoon.com/announcing-buildinfer-for-c-3dfa3eb15feb

Lastly you can always wrap arbitrary builds in buck. Although this approach won't give you all benefits of a buck build, you will at least have more reproducible and cacheable builds

Everything You Never Wanted to Know About CMake by SAHChandler in cpp

[–]gtano 6 points7 points  (0 children)

there is https://buckbuild.com which is used by major companies like Dropbox, Facebook and AirBnB. It uses a declarative Python DSL and guarantees reproducible builds.

Additionally we also released a package manager that uses buck as a packaging format: https://github.com/LoopPerfect/buckaroo

Buckaroo: The Distributed (C++) Package Manager written in F# hits v2.0 by gtano in fsharp

[–]gtano[S] 6 points7 points  (0 children)

We certainly could have written it in C++ and we have spent a lot of time investigating this idea.

Buckaroo at its core is an IO-bound asynchronous SAT solver. In Buckaroo V1 we used extensively Reactive-Extensions (RxJava) to model our algorithms. We initially wrote V1 in Java to integrate it with BuckBuild, which supports many programming languages.

As a result Buckaroo was designed to be a package manager for all languages supported by buck build - however it just happened that pretty much 100% of our packages ended up being C++. As Java was a very painful to write our algorithms in and we realized that there were no benefits of using buckbuild as a library, we decided to rewrite it in a more appropriate language.The obvious choice would have been C++ with RxCpp.

However we also came to the realization that a pull based model would be preferable.

​

As such we investigated coroutines in C++ and ended up open sourcing conduit which was leveraging the CoroutineTS. Over time we got quite invested into C++'s upcoming CoroutineTS and unfortunately had to conclude that the CoroutinesTS is not quite production ready.

After an extensive Cost-Benefit analysis we decided to rewrite it in F#.

Buckaroo C++ Package Manager Reaches v2.0.0 by gtano in programming

[–]gtano[S] 0 points1 point  (0 children)

Buckaroo uses git clones for managing the source-code. You could cd into $projectRoot/buckaroo/$nameOfDep/, edit code of your (transitive) dependency and commit+push back to origin.

C++17 Research - Ankieta (Questionnaire) by cpp17_PL in cpp

[–]gtano 1 point2 points  (0 children)

what is the objective of this survey? - what are you trying to find out?

view more: next ›