Re: How to store a pointer to class contructor

2020-12-24 Thread Jacob Shtokolov via Digitalmars-d-learn
On Thursday, 24 December 2020 at 10:23:09 UTC, Dmitriy Asondo 
wrote:

Hi!

I'm trying to check some js-like features. For example, if I 
want to store somewhere in array|tuple a list of pointers to 
classes (app services) how may I do that?


Hi, it seems that what you're looking for is Prototype 
Inheritance, which is not quite common among staticly typed 
programming languages due to its runtime nature.


Please note that the way you've implemented it in JavaScript 
doesn't take compile-time class constructors into consideration. 
Just look at how you're passing constructor parameters to your 
objects. In D, each class may have its own constructor, so the 
arguments may be totally different.


Also, it looks like you're trying to implement some kind of a 
Service Locator.


Could you tell what are you trying to achieve with this code? Are 
the arguments and the array index received at runtime?


Re: Small program producing binary with large filesize

2019-11-10 Thread Jacob Shtokolov via Digitalmars-d-learn

On Monday, 21 October 2019 at 19:20:04 UTC, Prokop Hapala wrote:
What exactly should I specify to make it link dynamcially and 
produce as small binary as possible (without increasing 
compilation time) ?


Hi! Sorry, just found your response here. In order to force it to 
link dynamically, add these lines to your `dub.json`:


```
"buildTypes": {
"release-shared": {
"dflags": ["-link-defaultlib-shared", "-release", "-O3"]
}
},
"postBuildCommands": [
"strip ./"
]
```

Then build it like that:

```
dub build --build=release-shared --compiler=ldc2
```

Make sure that you replace  under `postBuildCommands` 
with your own application (binary) name.


The thing is that LDC2 links statically by default, so you have 
to add a few flags to the command line


Distinguish float and integer types from string

2019-03-09 Thread Jacob Shtokolov via Digitalmars-d-learn

Hi,

Recently, I was trying to solve some funny coding challenges 
(https://www.techgig.com).
The questions were really simple, but I found it interesting 
because the website allows to use D.


One of the task was to take a string from STDIN and detect its 
type.
There were a few options: Float, Integer, string and "something 
else" (which, I think, doesn't have any sense under the scope of 
the task).


Anyway, I was struggling to find a built-in function to 
distinguish float and integer types from a string.


I came to the following solution:

```
import std.stdio;
import std.range;
import std.conv;
import std.string;
import std.format;

immutable msg = "This input is of type %s";

void main()
{
string type;
auto data = stdin.byLine.takeOne.front;

if (data.isNumeric) {
type = data.indexOf(".") >= 0 ? "Float" : "Integer";
}
else {
type = "string";
}

writeln(msg.format(type));
}
```

But I think that's ugly. The thing is that in PHP, for example, I 
would do that like this:


```
if (is_integer($data)) {
//...do smth
}
else if (is_float($data)) {
//...do smth
}
else {
//...do smth
}
```

I tried to use std.conv.to and std.conv.parse, but found that 
they can't really do this. When I call `data.to!int`, the value 
of "123.45" will be converted to int!


Is there any built-in way to detect these types?

Thanks!


Re: opEquals() non-standard return type

2019-01-24 Thread Jacob Shtokolov via Digitalmars-d-learn

On Wednesday, 23 January 2019 at 17:28:37 UTC, H. S. Teoh wrote:
The best way to do this is to use a string DSL or a delegate as 
template argument. For example:


auto result = User.filter!q{ User.name == "John" };

or:

auto result = User.filter!(u => u.name == "John");



I didn't know about q{} token strings! This looks very cool for 
implementing different DSLs.


Thank you!


Re: opEquals() non-standard return type

2019-01-24 Thread Jacob Shtokolov via Digitalmars-d-learn

On Thursday, 24 January 2019 at 00:47:37 UTC, Ali Çehreli wrote:
Yeah, that can't work. Remove the bool-returning one and your 
code works with the 'alias this' above.


Wow, this is an amazing workaround! I didn't think about it in 
that way.

It perfectly solves the issue.

Thank you!


Re: opEquals() non-standard return type

2019-01-23 Thread Jacob Shtokolov via Digitalmars-d-learn
On Wednesday, 23 January 2019 at 15:28:02 UTC, Jonathan M Davis 
wrote:
But regardless of the specifics of operator overloading in D, D 
does not support overloading _any_ functions on the return type.


Thanks!


opEquals() non-standard return type

2019-01-23 Thread Jacob Shtokolov via Digitalmars-d-learn

Hi,

I'm trying to check whether it's possible to implement Python's 
SQLAlchemy-like query syntax in D, but I get stuck a bit.


Here is a simple example of what I want to achieve:

```
auto result = User.filter(User.id == 10);
result = User.filter(User.name == "John");
result = User.filter(User.age > 18);
```

Expressions like `User.id == 10`, `User.age > 18`, etc. should 
return a struct instead of a bool (let's call it `struct 
BinaryExpression`).


So I'm making the two versions of opEquals: one returns a 
BinaryExpression, and the second - a boolean value.


However, when I want to use the same expression for the `if` 
operator, the compiler cannot decide what function to call and 
shows an error: "overloads bool(int b) and BinaryExpr!int(int b) 
both match argument list for opEquals".



I'm wondering, is that possible to declare multiple versions of 
opEquals() and evaluate them in the different places depending on 
return type?


Here is my test code to check: https://run.dlang.io/is/yTFHWp
Gist: 
https://gist.github.com/run-dlang/67ec42ca73d56d310e8ae765fabede69


Thanks!


Re: Compile time opAssign/@property constraints

2019-01-05 Thread Jacob Shtokolov via Digitalmars-d-learn

On Friday, 4 January 2019 at 14:36:16 UTC, Mike Parker wrote:

v is a run-time value, not available at compile time.


Sorry about that, looks like if I edit the text in the 
run.dlang.io editor, the link also gets updated. I was using 
"void opAssign(T)(T v)" in the initial example, but it seems that 
I got the idea.


So even if I'd write opAssign or @property as a template 
function, I won't be able to get their arguments at compile time 
because every template takes different set of arguments: for 
compile time and for run time.


And due to the fact that D is calling opAssign as 
obj.opAssign(arg) and not as obj.opAssign!(arg)(arg), this is not 
possible to get the runtime arguments.


On Saturday, 5 January 2019 at 01:38:43 UTC, Jonathan M Davis 
wrote:

I suggest that you read

https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time

IIRC, it's still a work in progress, but it should give you a 
much clearer idea of how CTFE fits into things.


Many thanks for this article! Now I understand it much better.

So it seems that the only "true way" is to use the struct 
invariant feature, but this will work only at run time.


It turned out that I just want some compile-time mechanism 
(static analyzer?) that will validate (solve) all reachable 
constraints in the program.


Then I'd like to reformulate the question: is there any tools or 
compiler features that are capable of validating asserts at 
compile time?


Thanks!


Re: Compile time opAssign/@property constraints

2019-01-04 Thread Jacob Shtokolov via Digitalmars-d-learn

On Friday, 4 January 2019 at 11:45:24 UTC, Jacob Shtokolov wrote:


Here is the simple example:

https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6


Sorry, invalid link.
Here is a new one: https://run.dlang.io/is/QZ5hLV



Re: Compile time opAssign/@property constraints

2019-01-04 Thread Jacob Shtokolov via Digitalmars-d-learn

On Friday, 4 January 2019 at 11:41:59 UTC, Simen Kjærås wrote:
The thing is, compile-time tests like static if and static 
assert can only test values that are known at compile-time, and 
are for the most part useful only in templates.


Thanks for this answer! That's sad to hear.
But, is there anything to do with CTFE? Can it help somehow in 
such situation?


Re: Compile time opAssign/@property constraints

2019-01-04 Thread Jacob Shtokolov via Digitalmars-d-learn

On Friday, 4 January 2019 at 10:34:07 UTC, Basile.B wrote:

Show us some code.


Here is the simple example:

https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6

The thing I'm trying to do is to make an experimental port (for 
education purposes) of https://github.com/fthomas/refined library 
for Scala, which allows to set constraints on basic types like 
numeric, bool, string, etc.


For example, you can force an integer variable to take a range 
between 0 and 15. And if constraint is not satisfied, you get a 
compile time error.


There is no predicate in my example, but even if I add one (using 
alias template parameter), it shows the same error.


So is that possible in D?


Compile time opAssign/@property constraints

2019-01-04 Thread Jacob Shtokolov via Digitalmars-d-learn

Hi,

I'd like to implement some compile time constraints for a struct 
(though not sure if that's possible).


I already tried to place "static assert" or any kind of static 
condition into a body of @property and opAssign(), but every time 
it shows the error "variable cannot be read at compile time".


Is there any way to catch and validate assignments or struct 
initialization at compile time?


Thanks,
Jacob


Re: How to understand context type of a delegate?

2018-09-08 Thread Jacob Shtokolov via Digitalmars-d-learn

On Wednesday, 5 September 2018 at 16:53:42 UTC, NX wrote:
Is there a way to know what kind of context a delegate has 
either in compile time or runtime?


Also is there any way to check whether a pointer legitimately 
points to an Object instance?


No and no. I was fighting this problem in std.signals but found 
only one way to fix that without breaking backwards 
compatibility: we can use core.memory.GC class in order to check 
whether the object was allocated by GC (GC.addrOf). If it was, we 
need to retain the delegate context pointer to prevent accidental 
deallocation of this class by GC.


And if the object is not managed by GC, it means that the 
delegate's context is a simple anonymous function, struct 
function, or manually allocated delegate's heap (there are few 
more cases though).


In this case we just allow the user to manage this object 
manually. So if he decides to deallocate the entity behind the 
context pointer, he should be ready for a segmentation fault if 
he didn't remove an object from listeners before deallocation.


The main reason why std.signals allows only objects to be used as 
a delegate context is that every object is tracked by D runtime 
(by the so-called Monitor object) and even in the case of manual 
deallocation (if you're using the std.experimental.allocator), 
you will be notified about object destruction if you were 
subscribed to this event.


This makes the implementation extremely safe, but the author of 
the original library didn't finish his work properly. So 
std.signals now is a good candidate for replacement.


I'm working on the fix and will create a pull request soon. Not 
sure if it will be accepted, but this module definitely needs to 
be replaced. If you want to join me in this work, I can share 
additional details about the situation around std.signals in 
general.


If you don't want to spend your time on this, check this module: 
https://github.com/buggins/dlangui/blob/master/src/dlangui/core/signals.d - it's a part of the DlangUI project which already contains most of the things you may need.


Re: Is there a simple way to check if value is null for every case?

2018-08-27 Thread Jacob Shtokolov via Digitalmars-d-learn

On Monday, 27 August 2018 at 14:11:32 UTC, SG wrote:
On Monday, 27 August 2018 at 13:02:28 UTC, rikki cattermole 
wrote:
So Nullable in D and C# is basically the same except C#'s has 
language support.



Shouldn't it be in the standard library?

I think it's worth it to create a feature request in Phobos for 
that. Or at least make a bug report.


Such inconsistencies must be handled by a standard library, not 
manually, I believe.


Re: Small program producing binary with large filesize

2018-08-01 Thread Jacob Shtokolov via Digitalmars-d-learn

On Tuesday, 31 July 2018 at 15:19:19 UTC, Dan Barbarito wrote:

Hi all,

I am starting to write a command line tool.


Hi!

First, Vibe.d will increase your binary size because it contains 
a lot of unnecessary things inside it. So instead of using the 
entire vibe.d library, you may point dub to specific vibe.d 
parts, like `vibe.d:core`, `vibe.d:http` etc.


If you put the whole vibe.d framework as a dub dependency and use 
it like `import vibe;` the things like mongodb drivers, email 
libraries, redis driver etc. will be linked to your binary as 
well, even if you don't need them.


Second, you need to compile your code in the release mode to cut 
all debug information out of it. Also, you can try to use the 
`strip` command line tool to cut all export symbols if your 
binary is an executable file, not a library. This will reduce the 
size. In some cases a lot.


The third thing is already mentioned: by default, the DMD 
compiler builds and links the code statically. In other words, 
your binary contains parts of the DRuntime and the Phobos 
libraries (those parts that you've used in your program).


This thing helps to distribute compiled binaries without external 
dependencies (except libc and libpthread), because your binary is 
already contains all needed stuff.


If you're not happy with it, you can try to use the LDC compiler, 
which uses the dynamic linking by default. Your binary will be 
really tiny, but in order to execute it, you'll need to have the 
libdruntime.so and libphobos.so installed in your system. This 
may add additional issues if you plan to distribute your program.


Sadly, we still don't have the D runtime libraries installed in 
all popular OSes. Currently only the libc has this privilege 


I hope the situation will change in the future.



Re: Dlangui customize app icon on dock or menu bar

2018-07-25 Thread Jacob Shtokolov via Digitalmars-d-learn

On Wednesday, 25 July 2018 at 09:42:00 UTC, Ivo wrote:

I'm a macOs user and I need to build a application with a GUI.


Not sure if the author of the DLangUI is visiting this forum so 
often to be able to answer.


If you won't get an answer in the next few days, I would 
recommend to make an issue in the DLangUI repo: 
https://github.com/buggins/dlangui


Re: High memory usage in vibe.d application

2018-07-01 Thread Jacob Shtokolov via Digitalmars-d-learn

On Sunday, 1 July 2018 at 05:20:17 UTC, Anton Fediushin wrote:
Now I tried it and indeed, it's vibe.d's fault. I'm not quite 
sure what causes it and if this problem is known, I'll look 
into that later and open an issue if it doesn't exist already.


Yes, please do this when you have time. That would be really 
helpful for further vibe.d improvement.


I remember a pretty old (and closed) bug of HTTP client here:
https://github.com/vibe-d/vibe.d/issues/1321

So it might be somehow related to this one. Probably something 
wrong with HTTP client or TLS/SSL related logic. You example code 
is very good and I was able to reproduce the same issue with the 
latest stable compiler, so I hope the guys will find the problem.


Thanks!


Re: High memory usage in vibe.d application

2018-06-30 Thread Jacob Shtokolov via Digitalmars-d-learn

On Friday, 29 June 2018 at 17:40:07 UTC, Anton Fediushin wrote:

So, long story short:
- Usage of Mallocator instead of theAllocator made it a little 
bit better

- VibeManualMemoryManagement had no (or little) effect
- Manually calling GC.collect had no (or little) effect


You could try to call GC.minimize in pair with GC.collect:

```
GC.collect();
GC.minimize();
```

to return all freed memory back to the OS.

Not sure that the leakage of this type is possible because if 
you're running your program on 64bit Linux the probability of it 
is very low. AFAIK the GC is launched every (almost) time you 
allocate the memory, and if it finds "dead" pointers, it 
definitely must clean them out.


Vibe.d may also leak. Have you tried to run the same code without 
Vibe.d, say, using https://github.com/ikod/dlang-requests as an 
HTTP client?


Also, have you tried to change vibe.d's event loop engine, like 
libevent or libasync?


Re: Can't start application on heroku

2018-06-16 Thread Jacob Shtokolov via Digitalmars-d-learn

On Saturday, 16 June 2018 at 01:24:04 UTC, crimaniak wrote:

Hi all!

The first try to host application on Heroku provider. The 
application is started and starts to listen in 3 seconds on the 
port, provided by heroku-buildpack-d. But the server doesn't 
detect listening and stops the application. On the local 
machine, the application works as expected. What can be the 
problem here?


[...]


Probably you could try to change your listening address from 
127.0.0.1 to 0.0.0.0