[vibe.d] How to create authentication system via REST interface?

[Pablo De Nápoli via Digitalmars-d-learn]

https://forum.dlang.org/post/bctojiyzicxaueqgm...@forum.dlang.org

On Wednesday, 15 March 2017 at 13:24:07 UTC, NX wrote:
I'm trying to understand how to create some json-rest api that 
would return data (in json format) related to that specific 
logged in user. I see the documentation covers these but I'm 
totally new to vibe.d so can't quite figure out putting these 
two things together and make them work. Some easy to follow 
sample would be incredibly helpful, though any help is 
appreciated.


I have just posted an example on this on github at

https://github.com/pdenapo/jwt_in_d

(It is just a proof of concept)

It would be great to add vibe-d built in support for this.
Its documentation was somewhat hard to read for me.

Re: Is there a way to do the same thing in entry and return of a bunch of functions?

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 17:11:09 UTC, Stefanos Baziotis 
wrote:
I think it's better to give a concrete example rather than 
explaining this vaguely.


-- The question --
Can we do better ? For one, I believe that because D does not 
have a preprocessor,
we have to do an actual declaration which would be somewhat 
more verbose.
Or do a mixin that does it. mixin can help as it can be more 
complicated
and also we can access local scope (although I don't think this 
is a good idea).


But in both cases, they're not totally invisible.

Can we do something like: func1, func2 and func3, when they 
enter do the X

and when they return, they do the Y.

Thanks,
Stefanos


I think a mixin that does

string LOG_SCOPE = q{
callDepth++;
scope(exit) callDepth--;
}

is probably the easiest. for bonus points

string LOG_SCOPE = q{
callDepth++;
debug_log(__FUNCTION__);// or __PRETTY_FUNTION__
scope(exit) callDepth--;
}

and the mixin(LOG_SCOPE);

I mean you _could_ do some UDA reflection to generate wrapping 
function that do the indentation, bit that is overkill.

Re: Building 64-bit Windows application with console window

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 18 September 2019 at 00:13:43 UTC, cc wrote:

Sample program here: https://pastebin.com/wpLetNKP


You have a WinMain function there. The Microsoft linker sees that 
as an indication that you are writing a Windows gui application 
and thus suppresses the console window.


Inside your program, you can always call the AllocConsole() 
function to pop up a console and attach it: 
https://docs.microsoft.com/en-us/windows/console/allocconsole


So a potential fix for you to just stick

debug AllocConsole();

right inside your WinMain before doing anything else.


Or my preference is to just never write WinMain in D. Just write 
a normal D main and use -L/subsystem:windows when you don't want 
the console (note: on 64 bit using the subsystem with normal 
main(), you also need to pass `-L/entry:mainCRTStartup.` to dmd 
so it uses the right entry point), and allow the defaults if you 
do want it.

Building 64-bit Windows application with console window

[cc via Digitalmars-d-learn]

This might be more a question about the MS linker than D, but I'm 
noticing that when building with -m64 under DMD v2.087.1, it is 
no longer generating a console window when running the 
application.  Under 32-bit, it would always generate the console 
window, and I had to disable it by building with a .def file that 
specified SUBSYSTEM WINDOWS when I no longer wanted it.  Is there 
a way to instruct it to still spawn the console window for 
debugging purposes?


Sample program here: https://pastebin.com/wpLetNKP

rdmd --build-only -debug -g -of"con32.exe" contest.d  ## 
Generates console window and main application window


rdmd --build-only -debug -g -m64 -of"con64.exe" contest.d  ## 
Only generates main application window


I tried adding -L/SUBSYSTEM:CONSOLE to the build arguments but 
then I believe it looks for the wrong entry point and fails:


libcmt.lib(exe_main.obj) : error LNK2019: unresolved external 
symbol main referenced in function "int __cdecl 
__scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)

Re: Deprecation message sources

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, September 17, 2019 2:34:00 PM MDT Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 9/17/19 4:16 PM, Anonymouse wrote:
> > On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven Schveighoffer 
wrote:
> >> I'd hate to say the answer is to special case Nullable for so many
> >> functions, but what other alternative is there?
> >>
> >> -Steve
> >
> > Nullable isn't alone, std.json.JSONType causes a literal wall of text of
> > deprecation warnings.
> >
> > import std.stdio;
> > import std.json;
> >
> > void main()
> > {
> >
> >  writeln(JSONValue.init.type);
> >
> > }
> >
> > https://run.dlang.io/is/J0UDay
>
> I mean, I'm OK with the idea, but having these deprecation messages is
> helping nobody. I can't figure out if there's something I'm supposed to,
> or can, change in order to get rid of them.
>
> There are quite a few places where it is flagging my code for Nullable
> usage without get, and I'm fixing those. But I'll still be left with
> this mess of deprecation messages from Phobos and vibe.d. I don't even
> know where or if it will break once the alias this is removed.

I ran into problems along those lines with dxml recently, and I couldn't
figure out why one of the deprecation messages was being triggered. It
seemed to have to do with isInputRange, but I couldn't figure out where in
my code was resulting in that problem. I tried to track it down by compiling
Phobos with the alias this outright removed from Nullable (with the idea
that I'd then hopefully get some decent error messages wherever the real
problem was), and dxml's tests then compiled and ran just fine with no
deprecation messages. So, I don't know what to do about it. I suspect that
deprecation messages are being triggered simply by code trying to use
Nullable in template constraints rather than just when it's actually used in
proper code, but I don't know.

I ran into problems along those lines when I last tried to deprecate
TickDuration (which is why it's not yet deprecated). Template constraints
were triggering deprecation messages when I didn't think that they should
be, but unfortunately, I didn't have time to narrow down what was going on
so that I could create a proper bug report for it, and I haven't gotten back
to it.

- Jonathan M Davis

Re: Deprecation message sources

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, September 17, 2019 5:28:33 PM MDT H. S. Teoh via Digitalmars-d-
learn wrote:
> On Tue, Sep 17, 2019 at 08:55:27PM +, Johan Engelen via
> Digitalmars-d-learn wrote: [...]
>
> > Wow. How come this is not caught by the CI testing?
>
> [...]
>
> Is the CI setup to detect deprecations and flag them as failures?
>
> It's either that, or many cases are not tested because Phobos has a lot
> of templates, not all of which are instantiated with the specific
> combination of template arguments that triggers deprecation messages.

Yes. Seb made druntime and Phobos compile with -de a while back in order to
make sure that all cases where deprecations pop up actually get fixed - but
of course, that's only going to catch the cases that are in the tests, and
it probably wouldn't be hard to trigger a bunch of deprecations in Phobos by
doing something like using a range of Nullable, since implicit conversions
would probably get triggered all over the place - especially if it's the
case that the deprecation message gets triggered by stuff like static if
tests and template constraints (I'm not sure that it does in this case, but
I have seen problems in the past where template constraints triggered
deprecation messages; last time I tried to deprecate TickDuration, I ran
into a bunch of problems like that, which is why it hasn't been deprecated
yet).

- Jonathan M Davis

Re: Deprecation message sources

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Sep 17, 2019 at 08:55:27PM +, Johan Engelen via Digitalmars-d-learn 
wrote:
[...]
> Wow. How come this is not caught by the CI testing?
[...]

Is the CI setup to detect deprecations and flag them as failures?

It's either that, or many cases are not tested because Phobos has a lot
of templates, not all of which are instantiated with the specific
combination of template arguments that triggers deprecation messages.


T

-- 
Without outlines, life would be pointless.

Re: Deprecation message sources

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/17/19 3:31 PM, Steven Schveighoffer wrote:

Hi,

I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores 
of deprecation messages. One thing I've realized is that most of these 
messages are generated by calls outside my code. These deprecation 
messages are intended to tell you where you are calling them, but end up 
telling you where phobos, or vibe.d, or whatever, is calling them.


Bug in compiler?

void foo(int y)
{
}

void main()
{
  Nullable!int x = 5;
  assert(x > 0); // No deprecation warning
  foo(x); // deprecation warning
}

Using -vcg-ast, it is indeed calling the _get function in both cases.

-Steve

Re: Deprecation message sources

[Johan Engelen via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 20:16:12 UTC, Anonymouse wrote:
On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven 
Schveighoffer wrote:
I'd hate to say the answer is to special case Nullable for so 
many functions, but what other alternative is there?


-Steve


Nullable isn't alone, std.json.JSONType causes a literal wall 
of text of deprecation warnings.


import std.stdio;
import std.json;

void main()
{
writeln(JSONValue.init.type);
}

https://run.dlang.io/is/J0UDay


Wow. How come this is not caught by the CI testing?

-Johan

Re: Deprecation message sources

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/17/19 4:16 PM, Anonymouse wrote:

On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven Schveighoffer wrote:
I'd hate to say the answer is to special case Nullable for so many 
functions, but what other alternative is there?


-Steve


Nullable isn't alone, std.json.JSONType causes a literal wall of text of 
deprecation warnings.


import std.stdio;
import std.json;

void main()
{
     writeln(JSONValue.init.type);
}

https://run.dlang.io/is/J0UDay


I mean, I'm OK with the idea, but having these deprecation messages is 
helping nobody. I can't figure out if there's something I'm supposed to, 
or can, change in order to get rid of them.


There are quite a few places where it is flagging my code for Nullable 
usage without get, and I'm fixing those. But I'll still be left with 
this mess of deprecation messages from Phobos and vibe.d. I don't even 
know where or if it will break once the alias this is removed.


-Steve

Re: Deprecation message sources

[Anonymouse via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 19:31:53 UTC, Steven 
Schveighoffer wrote:
I'd hate to say the answer is to special case Nullable for so 
many functions, but what other alternative is there?


-Steve


Nullable isn't alone, std.json.JSONType causes a literal wall of 
text of deprecation warnings.


import std.stdio;
import std.json;

void main()
{
writeln(JSONValue.init.type);
}

https://run.dlang.io/is/J0UDay

Deprecation message sources

[Steven Schveighoffer via Digitalmars-d-learn]

Hi,

I just upgraded my compiler from 2.084 to 2.088, and I'm getting scores 
of deprecation messages. One thing I've realized is that most of these 
messages are generated by calls outside my code. These deprecation 
messages are intended to tell you where you are calling them, but end up 
telling you where phobos, or vibe.d, or whatever, is calling them.


For example, I get messages like:

home/steves/.dvm/compilers/dmd-2.088.0/linux/bin/../../src/phobos/std/traits.d(3687,61): 
Deprecation: function std.typecons.Nullable!string.Nullable.get_ is 
deprecated - Implicit conversion with alias Nullable.get this will be 
removed after 2.096. Please use .get explicitly.


The line in question is commented below:

template hasElaborateAssign(S)
{
static if (isStaticArray!S && S.length)
{
enum bool hasElaborateAssign = 
hasElaborateAssign!(typeof(S.init[0]));

}
else static if (is(S == struct))
{
/* the line below /
enum hasElaborateAssign = 
is(typeof(S.init.opAssign(rvalueOf!S))) ||


is(typeof(S.init.opAssign(lvalueOf!S))) ||
anySatisfy!(.hasElaborateAssign, FieldTypeTuple!S);
}
else
{
enum bool hasElaborateAssign = false;
}
}

I'm not calling hasElaborateAssign from anywhere in my code. So 1. how 
am I supposed to know where this call is being generated from, and 2. 
I'm assuming this is happening inside a static if buried deep somewhere 
in library code, so how am I supposed to fix it?


I'd hate to say the answer is to special case Nullable for so many 
functions, but what other alternative is there?


-Steve

Re: segmentation fault when running void main() {}

[Adam D. Ruppe via Digitalmars-d-learn]

Did you make sure the old version was totally uninstalled before 
the new version was attempted to be built? This thing often 
happens because of a compiler/runtime version mismatch, typically 
because the old version didn't get fully removed first.

segmentation fault when running void main() {}

[berni via Digitalmars-d-learn]

I'm not sure, if this is the right place to ask, but I couldn't 
find a better one either.


I'm trying to install D on my old 32-bit machine (debian stable). 
First I tried to install a precompiled version and now I followed 
[1]. In both cases, I always get a segmentation fault when I try 
to run a compiled program.


With make -f posix.mak AUTO_BOOTSTRAP=1 I got:


...
../generated/build 
HOST_DMD="../generated/host_dmd-2.079.1/dmd2/linux/bin32/dmd" 
OS=linux BUILD=release MODEL=32 AUTO_BOOTSTRAP="1" 
--called-from-make ../generated/linux/release/32/lexer.a

Segmentation fault
...


Any ideas, what's missing?

[1] https://wiki.dlang.org/Building_under_Posix

Is there a way to do the same thing in entry and return of a bunch of functions?

[Stefanos Baziotis via Digitalmars-d-learn]

I think it's better to give a concrete example rather than 
explaining this vaguely.


- For those who are familiar with LDC internals:
I want to create something like LOG_SCOPE. You can skip the 
explanation.


- For those who are not:
Imagine that you want to track down how deep in the call stack 
you are,

so that you can print nice log messages.

That is, if you have:

func3() {
  debug_log("message in func3");
}

func2() {
  debug_log("message in func2");
  func3();
  debug_log("message in func2");
}

func1() {
  func2();
}

main() {
  func1();
}

In this case, I'd like to have something like this:
* * message in func 2
* * * message in func3
* * message in func2

So, we could create a global variable CALL_DEPTH or smth, and in 
every

function right at the beginning, do: CALL_DEPTH += 1;
and in the end: CALL_DEPTH -= 1;

And then implement debug_log as (skipping the printf-like things 
etc.):

  for (int i = 0; i != CALL_DEPTH; ++i)
printf("* ");

But the thing is, now we have to put the += and -= in every 
function,
when it is really common in all of them and there's no reason to 
be visible

anyway.

LDC does something that IMO is ingenious. It's something like 
(it's C++):

#define LOG_SCOPE LoggerObj _logscope;

But LoggerObj has a constructor that does the += and the 
destructor that does

-=. So, you can put just one line of:
LOG_SCOPE;

at any point inside a function and the desired thing is done 
almost invisibly.



-- The question --
Can we do better ? For one, I believe that because D does not 
have a preprocessor,
we have to do an actual declaration which would be somewhat more 
verbose.
Or do a mixin that does it. mixin can help as it can be more 
complicated
and also we can access local scope (although I don't think this 
is a good idea).


But in both cases, they're not totally invisible.

Can we do something like: func1, func2 and func3, when they enter 
do the X

and when they return, they do the Y.

Thanks,
Stefanos

Re: Dynamic array + AA array

[Brett via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 15:51:34 UTC, Andrea Fontana 
wrote:

On Tuesday, 17 September 2019 at 14:33:30 UTC, Brett wrote:
The idea is to basically use a dynamic array for most of the 
items, then an array to get the rest.


T[] Base;
T[int] Rest;

Then if Base has a max size(usually it might be fixed due to 
some algorithm) the Rest AA can pick up any outside values 
easily.


The idea here is to be able to combine them as one "infinite" 
array of T.


Any indexing outside of Base gets carried in to Rest.


What if I try to read an index that was not assigned?
What if I try a foreach on it?


 It all has to function as an single array.

If you try to read an index that wasn't assigned to a normal 
array or AA what happens?


If you try a foreach on a normal array or AA what happens?

Re: matplotlibD returns

[Brett via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 15:21:37 UTC, jmh530 wrote:

On Tuesday, 17 September 2019 at 01:54:01 UTC, Brett wrote:

How does one get return values?

https://matplotlib.org/3.1.0/gallery/statistics/hist.html

Shows that python uses return values to set properties of the 
plot


https://github.com/koji-kojiro/matplotlib-d/blob/master/examples/source/app.d

Does not give any examples of return values and when trying 
gives error about void returns.


If I'm reading the following comment [1] correctly, this 
feature may require changes to matplotlib-d to implement.



[1] 
https://github.com/koji-kojiro/matplotlib-d/issues/7#issuecomment-274001515


That was over 2 years ago, it seems he isn't interested in making 
it work. In his code he uses pipes...



void call(string py_script) {
import std.process: environment, pipeProcess, wait, Redirect;

auto py_path =  environment.get("MATPLOTLIB_D_PYTHON", 
"python3");

py_path = `python.exe`;
auto pipes = pipeProcess(py_path, Redirect.stdin | 
Redirect.stderr);


pipes.stdin.writeln(py_script);
pipes.stdin.writeln("exit()");
pipes.stdin.close();

auto result = wait(pipes.pid);

if (result != 0) {
string error;
foreach (line; pipes.stderr.byLine)
error ~= line ~ "\n";
throw new Exception("\n\nERROR occurred in Python:\n" ~ 
error);

}
}

Not sure if this can be modified to work with returns? I guess 
they could be exported through json and possible read and used?
I don't see how it could work though since it seems that pointers 
will be returned. I don't know enough about python to know if 
some mechanism would work.


Maybe some python code could be created to call D and pass info 
back and forth or some better interprocess communications can be 
used?


He's essentially just send commands through text(py_script) that 
are executed on the python side of things. Nothing ever really 
takes place in D.


I guess a return type could could done on the python side too but 
it would require modifying the code and would be overly complex.

Re: Dynamic array + AA array

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 14:33:30 UTC, Brett wrote:
The idea is to basically use a dynamic array for most of the 
items, then an array to get the rest.


T[] Base;
T[int] Rest;

Then if Base has a max size(usually it might be fixed due to 
some algorithm) the Rest AA can pick up any outside values 
easily.


The idea here is to be able to combine them as one "infinite" 
array of T.


Any indexing outside of Base gets carried in to Rest.


What if I try to read an index that was not assigned?
What if I try a foreach on it?

Re: matplotlibD returns

[jmh530 via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 01:54:01 UTC, Brett wrote:

How does one get return values?

https://matplotlib.org/3.1.0/gallery/statistics/hist.html

Shows that python uses return values to set properties of the 
plot


https://github.com/koji-kojiro/matplotlib-d/blob/master/examples/source/app.d

Does not give any examples of return values and when trying 
gives error about void returns.


If I'm reading the following comment [1] correctly, this feature 
may require changes to matplotlib-d to implement.



[1] 
https://github.com/koji-kojiro/matplotlib-d/issues/7#issuecomment-274001515

Re: Dynamic array + AA array

[Paul Backus via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 14:33:30 UTC, Brett wrote:
The idea is to basically use a dynamic array for most of the 
items, then an array to get the rest.


T[] Base;
T[int] Rest;

Then if Base has a max size(usually it might be fixed due to 
some algorithm) the Rest AA can pick up any outside values 
easily.


The idea here is to be able to combine them as one "infinite" 
array of T.


Any indexing outside of Base gets carried in to Rest.

Now the question is, is there any way to wrap all this in to 
dynamic array semantics easily?


You can create a wrapper type for this that supports indexing, 
slicing, etc. using D's operator overloading:


https://dlang.org/spec/operatoroverloading.html

Dynamic array + AA array

[Brett via Digitalmars-d-learn]

The idea is to basically use a dynamic array for most of the 
items, then an array to get the rest.


T[] Base;
T[int] Rest;

Then if Base has a max size(usually it might be fixed due to some 
algorithm) the Rest AA can pick up any outside values easily.


The idea here is to be able to combine them as one "infinite" 
array of T.


Any indexing outside of Base gets carried in to Rest.

Now the question is, is there any way to wrap all this in to 
dynamic array semantics easily?


In fact, we might want to have ranges of indices that are 
relatively dense handled by several Bases and then sparse ranges 
handled by the Rest. If the structure is nice we can just nest it.


E.g.,

InfArray(InfArray(min1, max1),min2,max2)

would have two bases, one that handles [min1...max1) and then 
[min2..max2) and then has one or two Rest's for the rest of the 
values(not sure if we could probably use a single AA sense it 
might be used for something else or not, could make it optional 
to reference the same array).


This sorta gets one that best of both worlds, in fact, I wonder 
if a programming language could use such a thing(I think Lua 
probably is based on this idea with it's table's?).

Re: Collect Statistics efficiently and easily

[Paul Backus via Digitalmars-d-learn]

On Tuesday, 17 September 2019 at 01:53:39 UTC, Brett wrote:
Many times I have to get statistical info which is simply 
compute statistics on a data set that may be generating or 
already generated.


The code usually is

M = max(M, v);
m = min(m, v);

but other things like standard deviation, mean, etc might need 
to be computed.


This may need to be done on several data sets simultaneously.

is there any way that one could just compute them in one line 
that is efficient, probably using ranges? I'd like to avoid 
having to loop through a data set multiple times as it would be 
quite inefficient.


You can use `std.algorithm.fold` to compute multiple results in a 
single pass:


auto stats = v.fold!(max, min);
M = stats[0];
m = stats[1];

Blog Post #71: Expanding on the Statusbar

[Ron Tarrant via Digitalmars-d-learn]

Here's the second instalment on the lowly Statusbar wherein we 
look at multiple status reports as well as the Statusbar's 
signal: 
https://gtkdcoding.com/2019/09/17/0071-expanding-on-the-statusbar.html