#namespace — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #namespace, aggregated by home.social.
-
#namespace ext_image_copy_capture ext_ext_image_copy_capture_ #namespace ext_image_copy_capture::manager_v1 manager_v1_ #namespace ext_image_capture_source ext_ext_image_capture_source_v1 #using ext_image_copy_capture as capture #using ext_image_capture_source as image::source #using capture::manager_v1 as image::manager #using capture::session_v1 as image::session #using capture::session_v1 as image::session #using capture::manager_v1::create_session extern struct image::manager *manager; extern struct image::source *source; struct image::session *session = create_session(manager, source);or something similar
RE: https://social.vlhl.dev/objects/e95463e7-b873-413d-8669-0ec0cd50e084 -
thinking of the namespace proposal for c, and, i wonder if, we couldn’t have namespaces done in the preprocessor, like:
/* lib.h */ #namespace lib lib_ void lib::foo(); /* declares lib_foo as a function name */ /* app.c */ #include <lib.h> #using lib::foo #using lib::foo as nya #using lib as MyApi int main(void) { /* all of those would be pre-processed to lib_foo() */ lib::foo(); foo(); nya(); MyApi::foo(); }works with macros, and identifiers, basically anywhere a
#definewould also workand could be backwards compatible, e.g. if i were to use it in openrc:
/* rc.h */ #ifdef _HAS_NAMESPACE #namespace rc rc_ #namespace RC RC_ #endifnow older c programs can still use
rc_service_resolve, and newer ones can userc::service_resolve(as well as#usingdirectives)including whole namespace, like
#using lib, could work but it’d be a pain to implement i think, since the preprocessor would need to keep track of alllib_it sees since#namespacewas declared, and forward-replace thembut with or without whole-namespace-inclusion, this has really simple semantics and imo predictable errors, as namespacing conflicts can be reported the same way “redefinition” of macro names are
-
When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.
> Namespaces are one honking great idea -- let's do more of those!
`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.
Don't do it.
-
When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.
> Namespaces are one honking great idea -- let's do more of those!
`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.
Don't do it.
-
When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.
> Namespaces are one honking great idea -- let's do more of those!
`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.
Don't do it.
-
When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.
> Namespaces are one honking great idea -- let's do more of those!
`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.
Don't do it.
-
When people have pushed that around me, I show them the Zen of Python. It's important enough that it's the climactic line.
> Namespaces are one honking great idea -- let's do more of those!
`from x import y` throws one of Python's greatest features in the trash, and mashes everything into a single namespace, with all the opportunities for collisions, accidental overwrites, thinkos, and other problems.
Don't do it.
-
Мой первый контейнер без Docker
Технологии контейнеризации, возможно, как и у большинства из нас, плотно засели в моей голове. И казалось бы, просто пиши Dockerfile и не выпендривайся. Но всегда же хочется узнавать что‑то новое и углубляться в уже освоенные темы. По этой причине я решил разобраться в реализации контейнеров в ОС на базе ядра linux и в последствие создать свой «контейнер» через cmd.
https://habr.com/ru/articles/881428/
#docker #контейнер #контейнеризация #linux #namespace #cgroups #cgroup_v2
-
ADL – Avoid Debugging Later
Back in the day, being a witch was considered a grave crime. Today, we’re diving into one of C++’s lesser-known spells: ADL (Argument-Dependent Lookup). But before we explore this arcane magic, you must heed a warning—black magic comes with consequences. ADL is particularly treacherous, often leading to frustrating and hard-to-debug issues. Whenever possible, it’s wise to avoid casting this spell unless absolutely necessary.
Ingredients
Every spell needs ingredients, this time the only ingredients you need are a C++ compiler and a function that accepts at least one parameter, but there is a try catch, the parameter type has to belong to the same namespace of the function.
Casting the Spell
This spell works in shadows—you must look closely to uncover its effect.
std::cout << "Can you see me?";
Should the spell have passed you by, I’ll summon its power again for your eyes:
std::vector<int> a{1}, b{2};swap(a, b);If the spell’s effect remains elusive, let’s summon the entire code for you to see:
#include <vector>int main() { std::vector<int> a{1}, b{2}; swap(a, b); return 0;}And there it is, I didn’t use
using namespace std;and yet I calledstd::swapfunction without thestd::prefix.Dangerous Path
Before we dive into unveiling the syntax secrets, this is the place for warning signs. We all know that
using namespace std;is considered bad practice—and for a good reason. When you import an entire namespace into your own without being fully aware of the functions and names you’re bringing in, collisions can occur. Such collisions might result in calling an unintended function or class, often one with a slightly different algorithm or mechanism (after all, there’s usually a reason for the identical naming).Calling an unexpected function might unintentionally summon dependencies from distant, unforeseen corners of your code, and in doing so, awaken Undefined Behavior lurking quietly in the shadows, waiting for the right moment to strike.
This ‘spell’ exposes you to the exact same issue, even without explicitly using
using namespace. There are situations where you may need to cast this spell to achieve generic or scalable code. However, even in those cases, you must ensure the area is clear. Treat these spell locations as dangerous and suspicious zones—mark them clearly, and suspect them first whenever a bug appears nearby.Syntax Ritual: Unveiling the Dark Art of ADL
This spell was originally crafted to support the well-known foundation of C++ code:
std::cout << "Hello World";
This simple, foundational code uses ADL to access
std::operator<<(std::ostream&, const char*), as the actual code is:std::operator<<(std::cout, "Hello World"); // Without using ADLoperator<<(std::cout, "Hello World"); // Using ADL
The general idea behind this magic is that the compiler searches for a matching function in the current namespace and in the namespaces of each argument in the function call. For example, in the code above, the
operator<<is located in thestdnamespace, and the argumentstd::coutalso belongs to the same namespace.However, there are many more rules regarding what the lookup would contain in each case. The exact rules of the ADL can be found on cppreference.
A slightly more complex example comes from my experience with the dlib library, which looks like this:
namespace dlib { class dense_feature_extractor { public: friend void serialize(const dense_feature_extractor& item, std::ostream& out) { out << "dense_feature_extractor::serialize\n"; } friend void deserialize(dense_feature_extractor& item, std::istream& in) { std::cout << "dense_feature_extractor::deserialize\n"; } }; class matrix {}; void serialize(const matrix& m, std::ostream& out) { out << "dlib::serialize(matrix)\n"; } void deserialize(const matrix& m, std::istream& in) { std::cout << "dlib::deserialize(matrix)\n"; }}Now, it becomes interesting: without ADL, we can’t access the
serializeanddeserializefriend functions inside thedense_feature_extractorclass, unless we modify the library to declare them outside the class or make them static functions within the class.By casting a few ADL spells, we can craft the following function:
dlib::matrix m;dlib::dense_feature_extractor d;serialize(m, std::cout); // dlib::serialize(matrix)// same as: dlib::serialize(m, std::cout);serialize(d, std::cout);// dense_feature_extractor::serializedeserialize(m, std::cin); // dlib::deserialize(matrix)// same as: dlib::deserialize(m, std::cin);deserialize(d, std::cin); // dense_feature_extractor::deserialize
Since the calls appear identical, we can generalize them as follows:
template <typename T>void dlib_serializer(const T &val) { serialize(val, std::cout);}template <typename T>void dlib_deserializer(T &val) { deserialize(val, std::cin);}void func() { dlib::matrix m; dlib::dense_feature_extractor d; dlib_serializer(m); dlib_serializer(d); dlib_deserializer(m); dlib_deserializer(d);}The Spell You Might Unintentionally Already Cast
This spell is subtle and elusive, and you may already be summoning it without even noticing—simply by forgetting the
std::prefix (or any other namespace’s arcane sigil). The silver lining is that now, armed with this knowledge, you’ll be able to spot its presence in any code that calls upon it.Special Thanks
- Ellie Bogdanov for spelling assistance.
- ChatGPT for the logo and for grammar and spelling assistance.
#adl #advanced #ArgumentDependentLookup #C_ #coding #cpp #debug #dlib #include #Intermediate #magic #namespace #programming #spell #spells #usingNamespace
-
This is where I am w/ the github repo @zombiewarrior
It's really close to being "right", so to speak.
compare that to e.g.
http://statecollegeguitarlessons.com/adb/index.phpNote: my server is #LiteSpeed and i don'[t mess w/ it. But, that should not have the /public/ in the URL. If you've ever worked w/ #laravel it's like the ./index.php of the proj dir there. where there's ./index.php "reditrecting" to ./public/index.php
but you need to mod the #NGINX server {} location {} stuff for the... mod_rewrite type stuff.
i.e. the URL should be .com/giterator/ , accomplished in nginx w/ "@alias"
(sans the ./public part). you see the same thing either way. pet peeves.EDIT: ALSO! CORRECTION -do NOT see the same! ARGGH! w/out that #mod_rewrite bit #htaccess whatever!~ the #CSS #asset paths mess up as well. Prob explains the missing SVG (masthead.php) forgot about that. oh well. hey. gimme a damn break! brain damage!
SEE "new" version here, ( i can fix that path thing. i forget the quick path top of my head momentarily. i prefer to be correct instead, anyway!)
this is NOT correct! http://statecollegeguitarlessons.com/giterator/public/index.phpfirst time w/ the #namespace #php8 #composer #autoloader #PSR4 #MVC #refactoring.
i must admit, it was more challenging that i expected.
but yea. feel free to hop in there at any time, and help me polish that old turd already!
Sheesh! -
We have just released version 0.2.0 of the nethsm-cli #RustLang #crate. 🥳
This executable allows for easy integration with @nitrokey #NetHSM devices (and containers).With this release we have added #namespace and #OpenPGP support! 🔑
Also, users can now rely on shell completion and man pages! 📚https://crates.io/crates/nethsm-cli/0.2.0
Thanks to @wiktor for working out #OpenPGP support using #rPGP! 🎉
#CLI #HSM #encryption #decryption #DigitalSignature #signing #ArchLinux #Nitrokey #signstar
