Re: How Performance down slow it is using UFCS friendly function?
On Saturday, 21 November 2020 at 00:26:03 UTC, Marcone wrote:
// Função receive()
char[] receive(Socket socket, int size = 8192) nothrow {
try {
char[] buffer;
buffer.length = size;
int rq = socket.receive(buffer);
return buffer[0..rq];
} catch(Throwable){return null;}
}
s = new Socket(AddressFamily.INET, SocketType.STREAM);
writeln(s.receive(8192)); // How slow is using as friendly
function?
Calling a function with or without UFCS makes absolutely no
difference to performance. The compiler will generate the exact
same code whether you write `receive(s, 8192)` or
`s.receive(8192)`.
How Performance down slow it is using UFCS friendly function?
// Função receive()
char[] receive(Socket socket, int size = 8192) nothrow {
try {
char[] buffer;
buffer.length = size;
int rq = socket.receive(buffer);
return buffer[0..rq];
} catch(Throwable){return null;}
}
s = new Socket(AddressFamily.INET, SocketType.STREAM);
writeln(s.receive(8192)); // How slow is using as friendly
function?
Re: why is "hello".writeln considered bad?
On Friday, 20 November 2020 at 18:46:40 UTC, Martin wrote: On Friday, 20 November 2020 at 10:03:18 UTC, Daniel Kozak wrote: I remember days when I liked UFCS too . Unfortunately it is not so awesome when you use it with IDE. And I would like to add: if you use in a bigger team. It's annoying when every dev have a own taste.. And together with optional () it's hell - no joke. The need to think about codeatyle definitions in such detail is a nogo for big projects. This is a good point. I find with D there are many different ways to write code and each can look different on the page. Where I work we mandated all D code will be implemented in Phobos style and use Phobos and mir source as guides. Some parts do heavily use UFCS/optional() and some parts do not. We have not had issues with readability, but maybe our D code isn't that complicated because it is mostly PC side data analysis tools. Personally a really like UFCS, even `"hello".writeln;` and I think I'd rather have UFCS than autocompletion. But then I did start out in industry well before autocomplete was a thing so maybe I have never relied on it too much. Thanks all for the replies! norm
Re: Reflection on the book D web development.
On Friday, 20 November 2020 at 19:12:38 UTC, Alaindevos wrote: I bought the book "D Web Development". I understand only 20% of the book,the other 80% is way above my head. Compare, I own a book on flask development, and I understand 100% of it. Which means I can use dlang for anything except QT and serious web development ... Could you explain some of the things that you found particularly challenging about the book? What level of D proficiency did you have before you started with the book?
Reflection on the book D web development.
I bought the book "D Web Development". I understand only 20% of the book,the other 80% is way above my head. Compare, I own a book on flask development, and I understand 100% of it. Which means I can use dlang for anything except QT and serious web development ...
Re: why is "hello".writeln considered bad?
On Friday, 20 November 2020 at 10:03:18 UTC, Daniel Kozak wrote: I remember days when I liked UFCS too . Unfortunately it is not so awesome when you use it with IDE. And I would like to add: if you use in a bigger team. It's annoying when every dev have a own taste.. And together with optional () it's hell - no joke. The need to think about codeatyle definitions in such detail is a nogo for big projects.
Re: lambdas with types
On Friday, 20 November 2020 at 15:07:09 UTC, H. S. Teoh wrote: Wouldn't it be just syntactic sugar for a manually-declared helper template? Yeah, there's just both alias and enum helper templates that can both be useful at times so you might have to use those keywords in there somewhere too. (isInputRange is prolly an enum, but like ElementTypeOf is an alias...)
Re: lambdas with types
On Fri, Nov 20, 2020 at 02:52:41PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Friday, 20 November 2020 at 14:47:52 UTC, Paul Backus wrote:
> > There is no way to create an anonymous template in D.
>
> I wish there was, maybe some day we can think of a way to add it to
> the language.
Wouldn't it be just syntactic sugar for a manually-declared helper
template? We could just adapt the syntax for anonymous classes and
combine it with the syntax for lambdas, something like this:
template(T) => ... /* compile-time expression */
So for example:
auto myFunc(Args...)(Args args)
if (allSatisfy!(template(T) => is(T : double)))
{ ... }
The template keyword is to differentiate between an actual lambda vs. a
"template lambda". Not sure if we can leave out the (), it may be
necessary to diambiguate it from a named template declaration?
Implementation-wise, it would of course just lower to an injected helper
template declaration.
T
--
It is impossible to make anything foolproof because fools are so ingenious. --
Sammy
Re: lambdas with types
On Friday, 20 November 2020 at 14:57:42 UTC, H. S. Teoh wrote:
On Fri, Nov 20, 2020 at 02:47:52PM +, Paul Backus via
Digitalmars-d-learn wrote: [...]
In this specific case, you could also make `foo` a type-safe
variadic function [1], which would eliminate the need for
`allSatisfy`:
void foo(double[] args...)
{
// ...
}
[...]
Yes, and this will also eliminate the template bloat associated
with .foo, which would have been instantiated once per call
with a different number of arguments. But of course, this only
works if all arguments are of the same type, and if the
function body does not depend on accessing the number of
arguments at compile-time.
T
Thanks all.
The template conditions I'm working on are complicated enough
that this approach might work for some but not all. However, if I
split out the function I'm working on into a separate one, then I
might be able to take advantage of that.
Re: lambdas with types
On Fri, Nov 20, 2020 at 02:47:52PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> In this specific case, you could also make `foo` a type-safe variadic
> function [1], which would eliminate the need for `allSatisfy`:
>
> void foo(double[] args...)
> {
> // ...
> }
[...]
Yes, and this will also eliminate the template bloat associated with
.foo, which would have been instantiated once per call with a different
number of arguments. But of course, this only works if all arguments
are of the same type, and if the function body does not depend on
accessing the number of arguments at compile-time.
T
--
What do you get if you drop a piano down a mineshaft? A flat minor.
Re: lambdas with types
On Friday, 20 November 2020 at 14:47:52 UTC, Paul Backus wrote: There is no way to create an anonymous template in D. I wish there was, maybe some day we can think of a way to add it to the language.
Re: lambdas with types
On Friday, 20 November 2020 at 14:08:23 UTC, jmh530 wrote:
Doing something like below fails because I don't seem to be
able to make a templated lambda that just takes types. Is the
only way to do something similar to create a separate function
to handle the condition, or is there some other way to do
something with similar flexibility?
import std.stdio: writeln;
import std.meta: allSatisfy;
void foo(Args...)(Args args)
if (allSatisfy!(x => is(x == double), Args))
{
writeln("works");
}
void main() {
foo(1.0, 2.0);
}
There is no way to create an anonymous template in D. You will
have to declare a separate helper template:
private enum isDouble(T) = is(T == double);
void foo(Args...)(Args args)
if (allSatisfy!(isDouble, Args))
{
// ...
}
In this specific case, you could also make `foo` a type-safe
variadic function [1], which would eliminate the need for
`allSatisfy`:
void foo(double[] args...)
{
// ...
}
[1]
https://dlang.org/spec/function.html#typesafe_variadic_functions
Re: why is "hello".writeln considered bad?
On Fri, Nov 20, 2020 at 11:03:18AM +0100, Daniel Kozak via Digitalmars-d-learn wrote: [...] >I remember days when I liked UFCS too . Unfortunately it is not so >awesome when you use it with IDE. So I am now avoiding UFCS as much >as possible and it is a much better experience for me. [...] IMO, if the IDE can't give a good experience with UFCS, then it's the IDE that needs to be fixed, rather than the programmer bending over backwards to please the IDE. T -- I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller
lambdas with types
Doing something like below fails because I don't seem to be able
to make a templated lambda that just takes types. Is the only way
to do something similar to create a separate function to handle
the condition, or is there some other way to do something with
similar flexibility?
import std.stdio: writeln;
import std.meta: allSatisfy;
void foo(Args...)(Args args)
if (allSatisfy!(x => is(x == double), Args))
{
writeln("works");
}
void main() {
foo(1.0, 2.0);
}
Re: why is "hello".writeln considered bad?
On Friday, 20 November 2020 at 10:03:18 UTC, Daniel Kozak wrote: I remember days when I liked UFCS too . Unfortunately it is not so awesome when you use it with IDE. So I am now avoiding UFCS as much as possible and it is a much better experience for me. Doesn't bother me. Auto-completion is a nice-to-have for me, not a must-have, and I don't miss it when I don't have it.
Re: why is "hello".writeln considered bad?
On Fri, Nov 20, 2020 at 8:55 AM Mike Parker via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > ... > Eh, I wouldn't quite put it that way. If we're thinking of the > same thread, one person said he thought it was a bad idea. That > doesn't make it bad practice. It's just his opinion. I think UFCS > is an awesome feature. And it's widely used in D code. > I remember days when I liked UFCS too . Unfortunately it is not so awesome when you use it with IDE. So I am now avoiding UFCS as much as possible and it is a much better experience for me.
Re: why is "hello".writeln considered bad?
I was the person who wrote that example. It was just an example to show how it can be used. I would not write a function call like that when using a literal. As Mike said, its all up to personal preference.
Re: Calling function within class.
On 19/11/20 20:51, Vino wrote:
Hi Ali,
Thank you very much, your solution works for my example, but it does not
work for the main goal, let me explain what we are trying to perform.
Nut shell: Try to execute an aws command on sever accounts in parallel
to get some data.
Noe: each account has as separate username and password store in a
database table(encrypted).
Cod Logic
Fetch the username/ password from the table for each account.
Get the “awssecrete” key and “accesskey” for each account by calling an
aws api using the above username/password.
Set the fetched key’s as an environment variable.
Execute the aws command and get the data for each of the account
As we have many accounts what we are trying is to get the data in
parallel(execute the aws command in parallel for each account and store
the result in a array). At present our code is working fine(without
parallel), the moment we enable parallelism, it is throwing an error on
the SQL part (Fetch the username/ password from the table for each
account), as it could not execute the SQL query in parallel for
different account. If there is any other logic please do let me know
will give it a try. Below is the SQL code.
@trusted public auto getAwsconf(immutable string account)
{
auto con = new GetConnections();
Statement stmt = con.db.prepare("SELECT
username,AES_DECRYPT(b.userpass,b.key,b.vector) AS passwd FROM config
WHERE account = :account");
stmt.setParameter("account", account);
RowSet awsaccount = stmt.query();
scope(exit) con.db.close();
return awsaccount;
}
From,
Vino.B
Hi,
How does the `GetConnections()` constructor work? Is it creating a new
connection to the DB each time it's called, or is it getting them from a
pool? In any case it should probably return a different connection for
each thread (so the pool size should be at least the same as the number
of workers).
Otherwise one thread will try to start a new SQL operation while there
is another already running. In the best case, if the library is
thread-safe, it could enqueue them thus negating the benefit of
parallelism... if not, then you'll likely get errors like the ones
you're seeing.
Best,
A.
