Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote: Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. That is how a Python aficionado would defend the absence of visibility attributes therein. "We don't have them, because _ is enough, and there are no bugs". And I would agree that D would be better off without visibility attributes entirely instead of having unending issues with them (private aliases, private + reflection, private + synchronized/invariant, etc). In contrast, I use D every day and love its relaxed attitude towards private. Having class-private doesn't preclude module-private. Dennis even submitted a PR implementing class-private, but it stalled because people couldn't agree on whether class-private should be "private to class" or "private to class instance".
Re: How to debug/set breakpoint a dynamic library.so ?
On Thursday, 9 February 2023 at 19:26:59 UTC, Ali Çehreli wrote: On 2/9/23 06:00, mw wrote: The dynamic library.so is built from D (with pyd), and invoked from Python. I'm just wondering How to debug/set breakpoint a dynamic library.so ? Can someone give an example? Thanks. I may be totally off on this but I think it is as simple as the following: gdb --args your_python_program Once inside, set a break point on the dynamic library symbol. Then run. Ali Thank you, it worked! All the best wishes for the recent earthquake in Turkey.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 02:04:06 UTC, ProtectAndHide wrote: "Before practicing Zen, mountains were mountains and rivers were rivers. While practicing Zen, mountains are no longer mountains and rivers are no longer rivers. After realization, mountains are mountains and rivers are rivers again." Chinese proverb, is it very cool?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 00:18:59 UTC, Ali Çehreli wrote: Not everybody shares that view. So, there must be something deeper here: maybe some people are blind (including me), or others have expectations that they carry from other languages, or something else... But look at the contrast: Some people see the same thing as great and some people see it as really really bad. Well, it's true, that we all have preconceived and limited notions, about this or that. But honestly, dithyrambic praise of how D does things is not all that helpful. You talk about being 'free' as a programmer, but that terms only seems to apply to your needs. I'd like to be 'free' to decide on whether I want type privacy, or module privacy. I don't understand the dithyrambic praise, from some D users, for D preventing you from doing so (in a way that is truly 'free' - as opposed to enforcing a design decision on to the programmer) Anyway, the 'reality' is, that type privacy can be both convenient and inconvient. Good luck on your path towards that enlightenment ;-) "Before practicing Zen, mountains were mountains and rivers were rivers. While practicing Zen, mountains are no longer mountains and rivers are no longer rivers. After realization, mountains are mountains and rivers are rivers again."
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 00:58:51 UTC, zjh wrote: I admit that you use 'D' happy, but you don't admit that I use 'D' unhappy. Right,just `forkit`. The `minority` language is more closed than the big language! If you think about it, you will know that the `'D'` ranking should fall! `forkit` leaves `D` ,goto `swift`. This is what you expect. People are leaving. You can `have a party`.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote: In contrast, I use D every day and love its relaxed attitude towards private. I admit that you use 'D' happy, but you don't admit that I use 'D' unhappy.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote: On 2/8/23 04:07, zjh wrote: Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. In contrast, I use D every day and love its relaxed attitude towards private. Ali That comrade has mentioned it `many(>10) times`! `Private` can be used for two purposes. 1 is `module private`. 2 is `class private`!. However, you only provide `module private`, so programmers who want to use private classes as private classes leave, and then `D` continues to stay in a very small community. few man comes in!. Like me, from C++, I didn't even use `friend` once! It's useless for me! But the "`private`" of "C++" is just right for me!. But `D` refused to admit that `private` has two purposes! He said that you can only use private modules. Don't move around. It will increase `complexity` and make novices `afraid`! In this way, I will only stay in `C++`, because there are more and more features of `C++`, and I use them `more and more`!
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 23:05:35 UTC, Hipreme wrote: On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide wrote: On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote: On 2/8/23 04:07, zjh wrote: > Last time, someone proposed to add `private` like `C++'s`, We've discussed the 'private' topic very many times already. C++'s private necessitate the 'friend' keyword, which comes with it's own problems. Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. Given the number of individuals who bring this topic up over and over up is so few that I don't think there is a common problem. Do you have actual bugs related to this? "Wanting" the inclusion of a feature is sufficient. In contrast, I use D every day and love its relaxed attitude towards private. > and then it > was the same,they are always unwilling to add facilities useful That is not correct. The truth is, nobody is jumping to implementations just because some people think they are useful. There are always valid reasons for including a feature or not. Ali You mentioned previously that D implements various things in unprincipled ways. I guess, if one wants to use D, one has to be comfortable with this. But using a relaxed attitude towards the implementation of such a common and important abstraction, that in turn allows me to so easily shoot myself in the foot, is not really an attractive feature .. to me ;-) btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off. Most of the time, when people use "private", they are actually shooting their users which can't even extend their class. I rarely see code which people use "protected" instead and I find that pretty lacking. One thing is hiding memory allocation details on your class, other thing is hiding a property which could and should be controlled when extended in a class. To be fair I'm more often than not against private variables. Most of the time it only caused me headaches because there was a lot of unimplemented features and I could not simply fork the project. This is not only in D. I got that in Java, Haxe, C#. Thankfully those languages has ways to simply ignore the private attribute, which can't be done in D. Anyway, I'm not against static classes and I don't think they would bring any inherent problems, they should not cause regression and they should be easy to implement as the compiler already has the tools for it Glad to hear someone say they're not 'against' something ;-) btw. The Swift programming language is superior to D with regards to the notion of type privacy. That is, Swift has fileprivate (which provides **the exact** same flexibility of D's private), but Swift (unlike D), *does* allow the programmer to choose to have aspects of their type private to that type. To something similar to Swift private in D, the programmer is **required** to have that type - and nothing else, in a module. That then places an important design decision in the hands of the langauge, rather than the programmer. It's unlikely this aspect of Swift is in any way 'unprincipled', but more likely, a very well thought out decision to give programmers control of their design. So uising a term someone else mentioned in this thread, the programmer is 'free' to make their own choices around type privacy in Swift, but not in D :-(
Re: Non-ugly ways to implement a 'static' class or namespace?
On Friday, 10 February 2023 at 00:18:59 UTC, Ali Çehreli wrote: On 2/9/23 15:58, thebluepandabear wrote: >> In contrast, I use D every day and love its relaxed attitude towards >> private. > > the fact that private stuff is accessible from other classes in the same > module is really really bad, and it's pretty detrimental to the language. Not everybody shares that view. Correct. I think D has made the right decision, even if others want it to be what they're used to, and even if they have never bothered to try an alternative approach. In the many discussions on this, I have only seen opinions and conjecture, never a strong argument for a change.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 23:51:18 UTC, thebluepandabear wrote: btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off. yeah it seems like the community is closed off for feedback, which is concerning. Not at all. These things have been discussed to death and decisions have been made. Do you regularly have discussions with the folks in charge of Java, C#, or C++? Do they quickly implement your requested features? if the language wants to gain more people it needs to evolve I doubt that this would lead to a large influx of new D programmers. It would more than likely make the language more complex and less desirable, reducing the number of users.
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/9/23 15:59, ProtectAndHide wrote: > some 'key D > people' (wink wink) [...] > So I hand that over to you .. wink wink. You're trolling[1] again. Ali [1] https://www.merriam-webster.com/dictionary/troll#h3
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/9/23 15:58, thebluepandabear wrote: >> In contrast, I use D every day and love its relaxed attitude towards >> private. > > the fact that private stuff is accessible from other classes in the same > module is really really bad, and it's pretty detrimental to the language. Not everybody shares that view. So, there must be something deeper here: maybe some people are blind (including me), or others have expectations that they carry from other languages, or something else... But look at the contrast: Some people see the same thing as great and some people see it as really really bad. One thing is clear: We can't agree on this topic at least at this time. > let's actually think about what `private` means. It gives implementation freedom: I can change my implementation at will. The same exact goal can be achieved by convention as well: I can name my members with e.g. an underscore and everybody understands that they are private. Nobody touches it and they are protected from future implementation changes. If they do, they do it with full understanding that their code may break in the future. > when you come back from work, arrive home, and you close the curtains > and want some alone, you want to be private to everyone. I don't agree with that example: Yes, it's the same word but different meanings in code. > you wouldn't want your neighbours (the module) to peek at what you're > doing. Yes but I would have no problem other code looking at or using parts of my code if they wanted to. > your neighbours aren't your friends in real life, There is some friendship with my neighbors! :) > and they (the module) > aren't your friends in code Some of them are and some aren't. > -- just because they are in your vicinity > doesn't mean they have a right to violate your privacy. Right to violate doesn't mean anything will be broken. It means, there will be no hurdle if access is needed. Nobody will or does violate anything. I haven't seen a single time when D's approach to privacy caused harm. > tbh this whole private behaviour should be changed, it's just so weird Ok, I like "so weird" more than "really really bad". :) Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 23:13:00 UTC, Ali Çehreli wrote: ... Well, the only thing we can say for sure now, is that since 'class', 'oop', and 'private' have all been mentioned in this thread, some 'key D people' (wink wink) will come out to derail this thread by further pointing out how D neither needs (nor wants) any of these things... and that real programmers shouldn't need them either. So I hand that over to you .. wink wink.
Re: Non-ugly ways to implement a 'static' class or namespace?
In contrast, I use D every day and love its relaxed attitude towards private. the fact that private stuff is accessible from other classes in the same module is really really bad, and it's pretty detrimental to the language. let's actually think about what `private` means. when you come back from work, arrive home, and you close the curtains and want some alone, you want to be private to everyone. you wouldn't want your neighbours (the module) to peek at what you're doing. your neighbours aren't your friends in real life, and they (the module) aren't your friends in code -- just because they are in your vicinity doesn't mean they have a right to violate your privacy. tbh this whole private behaviour should be changed, it's just so weird
Re: Non-ugly ways to implement a 'static' class or namespace?
btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off. yeah it seems like the community is closed off for feedback, which is concerning. namespaces/static classes are a net positive for the language, and they've been shown to be an extremely good features, being implemented in Kotlin, C#, and C++. if the language wants to gain more people it needs to evolve
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 19:17:15 UTC, Adam D Ruppe wrote: On Thursday, 9 February 2023 at 13:00:04 UTC, thebluepandabear wrote: For my school I am commissioned to create many types of software. I tried to have a look at some of the gui kits in D but there was no tutorial for how to use them and they seemed as if they are lacking features in comparison to Qt/JavaFX. So your objection is one of newbie documentation. That's fair. Qt I always thought had nice docs, they're hard to beat. I've been slowly adding more to my stuff but it is a slow process. idk about features though, you saying "seemed" means you probably don't even actually know what they have so that's not as actionable. it's not anything personal, it's just that the current gui libraries for D are only around 1/100th of the size of other ones such as Qt/JavaFX, it's not really on the same wavelength, and there's nothing wrong with that specifically, it's very difficult to make an enterprise level gui library from scratch
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/9/23 14:34, ProtectAndHide wrote: > You mentioned previously that D implements various things in > unprincipled ways. I think you will continue misunderstanding that term. What it means is, D does not insist on certain programming paradigms over others. For example, you can code in structured, functional, object-oriented, etc. styles depending on your problem. > I guess, if one wants to use D, one has to be comfortable with this. I can't see how being free is something that one needs to be comfortable with but I guess you are correct. > But using a relaxed attitude towards the implementation of such a common > and important abstraction, that in turn allows me to so easily shoot > myself in the foot, is not really an attractive feature .. to me ;-) Thanks for the wink. > btw. When a newbie to D raises ideas, suggestions, etc... and you > counter them with (in essence) That is not the essence at all! There has been numerous responses here before I reminded how the path is actually open for language changes. > 'we don't need that in D, but go write a > dip if you think we do' attitude, is a real turn off. What was the alternative? Jumping to implementations of all suggested features? A bigger turn off would be forkit! Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 22:34:29 UTC, ProtectAndHide wrote: On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote: On 2/8/23 04:07, zjh wrote: > Last time, someone proposed to add `private` like `C++'s`, We've discussed the 'private' topic very many times already. C++'s private necessitate the 'friend' keyword, which comes with it's own problems. Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. Given the number of individuals who bring this topic up over and over up is so few that I don't think there is a common problem. Do you have actual bugs related to this? "Wanting" the inclusion of a feature is sufficient. In contrast, I use D every day and love its relaxed attitude towards private. > and then it > was the same,they are always unwilling to add facilities useful That is not correct. The truth is, nobody is jumping to implementations just because some people think they are useful. There are always valid reasons for including a feature or not. Ali You mentioned previously that D implements various things in unprincipled ways. I guess, if one wants to use D, one has to be comfortable with this. But using a relaxed attitude towards the implementation of such a common and important abstraction, that in turn allows me to so easily shoot myself in the foot, is not really an attractive feature .. to me ;-) btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off. Most of the time, when people use "private", they are actually shooting their users which can't even extend their class. I rarely see code which people use "protected" instead and I find that pretty lacking. One thing is hiding memory allocation details on your class, other thing is hiding a property which could and should be controlled when extended in a class. To be fair I'm more often than not against private variables. Most of the time it only caused me headaches because there was a lot of unimplemented features and I could not simply fork the project. This is not only in D. I got that in Java, Haxe, C#. Thankfully those languages has ways to simply ignore the private attribute, which can't be done in D. Anyway, I'm not against static classes and I don't think they would bring any inherent problems, they should not cause regression and they should be easy to implement as the compiler already has the tools for it
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote: On 2/8/23 04:07, zjh wrote: > Last time, someone proposed to add `private` like `C++'s`, We've discussed the 'private' topic very many times already. C++'s private necessitate the 'friend' keyword, which comes with it's own problems. Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. Given the number of individuals who bring this topic up over and over up is so few that I don't think there is a common problem. Do you have actual bugs related to this? "Wanting" the inclusion of a feature is sufficient. In contrast, I use D every day and love its relaxed attitude towards private. > and then it > was the same,they are always unwilling to add facilities useful That is not correct. The truth is, nobody is jumping to implementations just because some people think they are useful. There are always valid reasons for including a feature or not. Ali You mentioned previously that D implements various things in unprincipled ways. I guess, if one wants to use D, one has to be comfortable with this. But using a relaxed attitude towards the implementation of such a common and important abstraction, that in turn allows me to so easily shoot myself in the foot, is not really an attractive feature .. to me ;-) btw. When a newbie to D raises ideas, suggestions, etc... and you counter them with (in essence) 'we don't need that in D, but go write a dip if you think we do' attitude, is a real turn off.
MongoDB and vibe troubles.
Please consider the code:
mClient = connectMongoDB("127.0.0.1");
auto db = mClient.getDatabase("webAppMaster");
writeln(db);
auto users = db["users"];
writeln(users);
This follows this example:
https://github.com/vibe-d/vibe.d/blob/master/examples/mongodb/source/app.d
This results in :
MongoDatabase("webAppMaster", "webAppMaster.$cmd",
vibe.db.mongo.client.MongoClient)
and in the Next line:
MongoCollection(vibe.db.mongo.client.MongoClient,
MongoDatabase("webAppMaster", "webAppMaster.$cmd",
vibe.db.mongo.client.MongoClient), "users", "webAppMaster.users")
This makes me think that MongoDB driver has successfully found
the database and the collection. But now, this line is causing a
problem :
auto result = users.findOne(["_id": userName, "password"
: passHash]);
The error is, seen on the web page i am trying to serve:
vibe.db.mongo.connection.MongoDriverException@/root/.dub/packages/vibe-d-0.9.5/vibe-d/mongodb/vibe/db/mongo/cursor.d(304): Query failed. Does the database ex
and on the root console where vibe.d is running i have this :
MongoDB reply was longer than expected, skipping the
rest: 223 vs. 36
The database and collection exists:
> mongosh
> use webAppMaster
> db.webAppMaster.users.findOne({"_id": "testuser",
"password" : "1234"})
shows me what I want to see.
Where do I start debugging, please? Thank you
Re: staticMap but with two arguments
On 2/9/23 12:45, John Chapman wrote:
> On Thursday, 9 February 2023 at 19:17:55 UTC, Ali Çehreli wrote:
>> I could not figure out eliminating the hard-coded 4. Can we introspect
>> the parameter list of a template like 'fun' in the example? If we
>> could, then we could get 4 that way.
>
> Thank you for this. I don't mind hard-coding the N argument.
> TemplateArgsOf needs an instantiated template but maybe ```enum N =
> count(fun.stringof, ',') + 1``` is good enough.
Hopefully but very fragile:
template t(int[] T = [ 1, 2 ]) {}
void main() {
import std.algorithm : count;
enum N = count(t.stringof, ',') + 1;
static assert(N == 1); // FAILS
}
Same thing with any other thing with comma in it e.g.
template t(T = anotherTemplate!(1, 2)) {}
Ali
Re: staticMap but with two arguments
On Thursday, 9 February 2023 at 19:17:55 UTC, Ali Çehreli wrote: I could not figure out eliminating the hard-coded 4. Can we introspect the parameter list of a template like 'fun' in the example? If we could, then we could get 4 that way. Thank you for this. I don't mind hard-coding the N argument. TemplateArgsOf needs an instantiated template but maybe ```enum N = count(fun.stringof, ',') + 1``` is good enough.
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/8/23 04:07, zjh wrote: > Last time, someone proposed to add `private` like `C++'s`, We've discussed the 'private' topic very many times already. C++'s private necessitate the 'friend' keyword, which comes with it's own problems. Besides, D has zero problems with its private implementation in the sense that there has been zero bugs related to it being that way. Given the number of individuals who bring this topic up over and over up is so few that I don't think there is a common problem. Do you have actual bugs related to this? "Wanting" the inclusion of a feature is sufficient. In contrast, I use D every day and love its relaxed attitude towards private. > and then it > was the same,they are always unwilling to add facilities useful That is not correct. The truth is, nobody is jumping to implementations just because some people think they are useful. There are always valid reasons for including a feature or not. Ali
Re: ImportC "no include path set"
On Wednesday, 8 February 2023 at 14:08:47 UTC, bachmeier wrote: this looks like one of those "death by paper cut" things. It has the smell of a rough edge that needs fixing. It's the one reason I haven't even tried ImportC. I still wonder why I need to provide those headers while for linking MSVC is kinda autodetected now.
Re: Sort Associative Array by Key
On 2/8/23 23:19, Alexander Zhirov wrote:
>> foo.byPair
>> .array
>> .sort!((a, b) => a.key < b.key)
>> .map!(a => a.value);
>
> Is it possible to specify in `map` to return the result `[a.key] =
> a.value`? To make the result look like `[key:[val], key:[val]]`
map can return a tuple and std.array.assocArray can make an associative
array from those tuples:
import std;
void main() {
auto aa = iota(10)
.map!(n => tuple(n, n * n))
.assocArray;
writeln("Necessarily unsorted:\n", aa);
}
However, as the original question started with an associative array
anyway, I don't think I understand your question correctly. :)
If you are asking whether an associative array can store in sorted key
order, then no, it's impossible because associative arrays are hash
tables, which can't provide that.
But we can visit the elements in sorted order if we sort those keys
ourselves:
auto keys = aa
.keys // <- Makes an array by copying the keys
.sort;
writeln("In order:");
foreach (k; keys) {
writeln(k, ": ", aa[k]);
}
Ali
Re: How to debug/set breakpoint a dynamic library.so ?
On 2/9/23 06:00, mw wrote: The dynamic library.so is built from D (with pyd), and invoked from Python. I'm just wondering How to debug/set breakpoint a dynamic library.so ? Can someone give an example? Thanks. I may be totally off on this but I think it is as simple as the following: gdb --args your_python_program Once inside, set a break point on the dynamic library symbol. Then run. Ali
Re: staticMap but with two arguments
On 2/8/23 12:04, John Chapman wrote:
> rather than write it manually for each N?
import std.meta : AliasSeq;
template pickArgs(size_t totalElements,
size_t argsPerElement,
size_t whichElement,
args...) {
alias pickArgs = AliasSeq!();
static foreach (a; 0 .. argsPerElement) {
pickArgs = AliasSeq!(pickArgs, args[whichElement + a *
totalElements]);
}
}
template staticMapN(size_t N, alias fun, args...)
{
static assert(N != 0, "N must be non-zero.");
static assert((args.length % N) == 0,
"Mismatched number of arguments");
enum totalElements = args.length / N;
alias staticMapN = AliasSeq!();
static foreach (e; 0 .. totalElements) {
staticMapN = AliasSeq!(staticMapN,
fun!(pickArgs!(totalElements, N, e, args)));
}
}
// An example struct with some template parameters
struct S(T, size_t length, size_t foo, size_t bar) {
}
// An example template that creates instantiations of the S template
template Instantiate(T, size_t length, size_t foo, size_t bar) {
alias Instantiate = S!(T, length, foo, bar);
}
// Compile-time argument sets for three instantiations of the S template
alias myTypes = AliasSeq!(int, double, long);
alias mySizes = AliasSeq!(1, 2, 3);
alias myFoos = AliasSeq!(42, 43, 44);
alias myBars = AliasSeq!(100, 200, 300);
// A test with those 4 sets of template arguments
alias result = staticMapN!(4, Instantiate, myTypes, mySizes, myFoos,
myBars);
pragma(msg, result);
void main() {
}
I could not figure out eliminating the hard-coded 4. Can we introspect
the parameter list of a template like 'fun' in the example? If we could,
then we could get 4 that way.
Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 13:00:04 UTC, thebluepandabear wrote: For my school I am commissioned to create many types of software. I tried to have a look at some of the gui kits in D but there was no tutorial for how to use them and they seemed as if they are lacking features in comparison to Qt/JavaFX. So your objection is one of newbie documentation. That's fair. Qt I always thought had nice docs, they're hard to beat. I've been slowly adding more to my stuff but it is a slow process. idk about features though, you saying "seemed" means you probably don't even actually know what they have so that's not as actionable.
toString best practices
Hello everybody,
Let's assume there's an implementation of a templated struct like
this:
```
import std.format, std.range.primitives;
struct Point(T)
{
T x, y;
void toString(W)(ref W writer, scope const ref
FormatSpec!char f) const
if (isOutputRange!(W, char))
{
put(writer, "(");
formatValue(writer, x, f);
put(writer, ", ");
formatValue(writer, y, f);
put(writer, ")");
}
}
void main(){
import std.format : format;
assert( format("%s", Point!int(1,2)) == "(1, 2)");
import std.experimental.logger;
sharedLog.infof("%s", Point!int(1,2));
/+
Error: none of the overloads of template
`std.logger.core.Logger.memLogFunctions!LogLevel.info.logImplf`
are callable using argument types `!()(string, Point!int) shared`
/Users/pinver/dlang/dmd-2.102.0/osx/bin/../../src/phobos/std/logger/core.d(828,14):
Candidates are: `logImplf(int line = __LINE__, string file = __FILE__,
string funcName = __FUNCTION__, string prettyFuncName = __PRETTY_FUNCTION__,
string moduleName = __MODULE__, A...)(lazy bool condition, lazy string msg,
lazy A args)`
/Users/pinver/dlang/dmd-2.102.0/osx/bin/../../src/phobos/std/logger/core.d(876,14):
`logImplf(int line = __LINE__, string file = __FILE__,
string funcName = __FUNCTION__, string prettyFuncName = __PRETTY_FUNCTION__,
string moduleName = __MODULE__, A...)(lazy string msg, lazy A args)`
+/
}
```
What is the best way to handle also shared writers?
Thank you all,
Paolo
Re: ImportC "no include path set"
On Thursday, 9 February 2023 at 06:07:35 UTC, Elfstone wrote: Maybe Walter doesn't care about Windows enough, but I thought it'd be a must to add basic tests (say, "dmd hello.c") to run on all the platforms before release. Unlikely, since his text editor [doesn't even compile on Linux](https://github.com/DigitalMars/med/issues/8). I filed that two years ago. I assume that means Windows is his main development OS. The problems you're describing might be more of a reflection of shortage of Windows users that contribute.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 14:03:41 UTC, zjh wrote: If I can, I think `'D++'` is a good idea! Learn from a `successful` language! Don't be afraid of D becoming complex. C++ is already `super complex`. Aren't there more and more people still using it? Therefore, I don't approve of the behavior of reluctant to add new features. If it's me, as long as the new features are very good and meet people's needs, I will be very aggressive in 'adding new features'!
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 13:49:03 UTC, zjh wrote: .. There are too `few newcomers` to D, and D must change. If I can, I think `'D++'` is a good idea! Learn from a `successful` language! The typical feature of `C++` is that you have it. Although I don't have it now, I will have it sooner or later. If D is the same, it may expand the community, because you can attract programmers from `'java, C++, py, C#` and so on.
How to debug/set breakpoint a dynamic library.so ?
The dynamic library.so is built from D (with pyd), and invoked from Python. I'm just wondering How to debug/set breakpoint a dynamic library.so ? Can someone give an example? Thanks.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 13:41:27 UTC, zjh wrote: Our predecessors used D very early. At first, they were very `excited`. But `later`, they left because some people in D were too `stubborn`. Therefore, the community is very small. Our predecessors are `very smart` people, and they `left`. The loss of D community is `very large`.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 13:32:36 UTC, zjh wrote: They don't even admit the smaller the encapsulation, the better. Our predecessors used D very early. At first, they were very `excited`. But `later`, they left because some people in D were too `stubborn`. You can provide `facilities`, but you just don't do it! Others had to leave. Therefore, the community is very small.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 13:07:56 UTC, thebluepandabear wrote: yeah the whole module behaviour with `private` is just a massive turn off tbh, it needs to be changed to match the Java style They don't even admit the smaller the encapsulation, the better.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 12:55:41 UTC, Guillaume Piolat wrote: yeah right let's implement everything that people propose I like the concept of C++: I provide `facilities`, you can use it or not. Not that you can only do it `like this`! This is the only way. What's more, people put forward a `reasonable` request. It has been implemented, but it just not been `merged`. Maybe he thinks D does not welcome people who are used to `C++`.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote: On Friday, 20 January 2023 at 11:28:23 UTC, thebluepandabear wrote: Hi, In Java/C# you can create purely static classes. ... Last time, someone proposed to add `private` like `C++'s`, and then it was the same,they are always unwilling to add facilities useful to others, and then he left `D`. yeah the whole module behaviour with `private` is just a massive turn off tbh, it needs to be changed to match the Java style
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 12:55:41 UTC, Guillaume Piolat wrote: On Wednesday, 8 February 2023 at 12:10:59 UTC, zjh wrote: On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote: they are always unwilling to add facilities useful to others, `D`'s community is small, this is the reason! yeah right let's implement everything that people propose that's not the point of this thread here :P Of course you dont add stuff on the whim if one person says you should, I am just encouraging open ended discussion.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 12:50:48 UTC, Adam D Ruppe wrote: On Thursday, 9 February 2023 at 12:31:03 UTC, thebluepandabear wrote: I am actually taking a computer science class and I need to create desktop apps to pass and get through school. This is pretty easy in D. Like what specific kind of desktop app? For my school I am commissioned to create many types of software. I tried to have a look at some of the gui kits in D but there was no tutorial for how to use them and they seemed as if they are lacking features in comparison to Qt/JavaFX.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 8 February 2023 at 12:10:59 UTC, zjh wrote: On Wednesday, 8 February 2023 at 12:07:35 UTC, zjh wrote: they are always unwilling to add facilities useful to others, `D`'s community is small, this is the reason! yeah right let's implement everything that people propose
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 12:31:03 UTC, thebluepandabear wrote: I am actually taking a computer science class and I need to create desktop apps to pass and get through school. This is pretty easy in D. Like what specific kind of desktop app?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 8 February 2023 at 13:32:46 UTC, zjh wrote: On Wednesday, 8 February 2023 at 12:12:57 UTC, thebluepandabear wrote: but I still think the language has potential in the future I don't know if they have a sense of crisis. Now `D` in tiebo ranks `50`. I wouldn't say they have or should have a sense of crisis, the language itself is improving on a day-to-day basis but it isn't gaining popularity. I initially came in excited learning D because I thought that having a small ecosystem would just be a minor pain, but now I realize it's not minor -- it's pretty major. This is not to say D isn't a good language, it certainly is pretty good, but it just needs a bigger ecosystem. The community itself is great, no weirdos in it like Rust, but it just needs to be bigger. I am actually taking a computer science class and I need to create desktop apps to pass and get through school. I thought this would be possible with D, but it has turned out to be a massive pain, so this is why I am switching to Java. I think D may be one of those languages that eventually blows up like Rust because it's honestly great (it feels like a native Java some times), they just need to work on _marketing_ and _strengthening_ the ecosystem. Some corporate backing (RedHat, for example) would also be great since many people are working on it for free, and thus lacking in motivation. anyways I know nobody cares about my opinion, and hopefully this didn't come across disrespectful
Re: Sort Associative Array by Key
On Thursday, 9 February 2023 at 07:19:08 UTC, Alexander Zhirov
wrote:
foo.byPair
.array
.sort!((a, b) => a.key < b.key)
.map!(a => a.value);
Is it possible to specify in `map` to return the result
`[a.key] = a.value`? To make the result look like `[key:[val],
key:[val]]`
Wow. This is an old thread
.. anyway... how about making custom strings out of the KV pairs:
void main()
{
import std.conv : to;
import std.algorithm : sort;
import std.stdio : writeln;
auto foo = ["VXE":8, "BZP":5, "JLC":2];
string[] orderedKeyPairSet;
foreach (ref kv; foo.byKeyValue)
{
orderedKeyPairSet ~= kv.key.to!string ~ ":" ~
kv.value.to!string;
}
orderedKeyPairSet.sort;
foreach(ref str; orderedKeyPairSet)
writeln(str);
}
/*
output:
BZP:5
JLC:2
VXE:8
*/
