Re: Meson build system user learning D.
On Thu, 2019-05-23 at 04:21 +, Mike Brockus via Digitalmars-d-learn wrote: > […] > > That is cool that Atila was kind enough to accept the meson.build > file. But how do I use the written meson.build that is > apparently in the subdirectory directory "build"? Just asking > because normally I see a meson.build in the root of the project. Having the meson.build in the project root directory is the norm, and that was where I put it originally. However, Atila chose to leave only the Dub build in the root directory and place all other build-related files in the build directory. This is not a problem since Meson is entirely happy with that structure. I have my clone of unit-threaded in ~/Repositories/Git/Fork/Unit_Threaded and I build in ~/BuildArea/Unit_Threaded. My meson command in the build directory is: meson --prefix=$HOME/Built ~/Repositories/Git/Fork/Unit_Threaded/built and this works fine. I then build and install using Ninja. To date it all works for me. If you try this and something goes wrong put an issue on the unit-threaded GitHub project area and email me in case I don't get a notification from the issue system. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Meson build system user learning D.
On Tuesday, 21 May 2019 at 10:59:40 UTC, Russel Winder wrote: On Tue, 2019-05-21 at 05:21 +, Mike Brockus via Digitalmars-d-learn wrote: […] The solution from Reddit solves the problem for 'dub' but as part of my project C to D I wanted to use Meson and run test with whatever is available, coming next week I will try to incorporate 'unit-threaded' and if it works then I can tell Meson to include it as my decency and to use 'dub' to get it for me so I can focus on writing test for my code. I am currently working on becoming an Android app developer leaning Kotlin and on the weekends it's D. I use unit-threaded for my D code tests. Atila was kind enough to allow me to add a Meson build to unit-threaded. I therefore build and install a shared library of unit-threaded so as to avoid use of Dub in the Meson build of my D projects. […] However it is good to know that there is currently no compiler for D on a AVR chip. I thought GCC had an AVR backend so that GDC provides D on AVR. That is cool that Atila was kind enough to accept the meson.build file. But how do I use the written meson.build that is apparently in the subdirectory directory "build"? Just asking because normally I see a meson.build in the root of the project.
Re: Why function does not work with delegate
On Wednesday, 22 May 2019 at 22:33:52 UTC, Alex wrote:
auto x = (GdkEventButton* e, Widget w) ...
X.addOnButtonPress(x);
Why is x not a delegate?
Because you didn't ask for one and it didn't have to be.
Just add the delegate keyword to ask for one:
auto x = delegate(GdkEventButton* e, Widget w) {};
Re: Why function does not work with delegate
On Wed, May 22, 2019 at 10:33:52PM +, Alex via Digitalmars-d-learn wrote:
> In gtkD one can use a lambda directly:
>
> X.addOnButtonPress((GdkEventButton* e, Widget w) ...
>
> but if I try move the lambda in to a variable so I can use it with
> multiple handlers, I get an error:
>
> // x is a function and does not work
> auto x = (GdkEventButton* e, Widget w) ...
> X.addOnButtonPress(x);
>
> etc...
>
> It's because the second case treats x as a function while the first it
> is a delegate and addOnButtonPress requires a delegate...
[...]
You could try explicitly declaring it as a delegate:
void delegate(GdkEventButton*, Widget) x = (e, w) { ... };
X.addOnButtonPress(x);
T
--
I am Ohm of Borg. Resistance is voltage over current.
Why function does not work with delegate
In gtkD one can use a lambda directly:
X.addOnButtonPress((GdkEventButton* e, Widget w) ...
but if I try move the lambda in to a variable so I can use it
with multiple handlers, I get an error:
// x is a function and does not work
auto x = (GdkEventButton* e, Widget w) ...
X.addOnButtonPress(x);
etc...
It's because the second case treats x as a function while the
first it is a delegate and addOnButtonPress requires a delegate...
Why is x not a delegate?
Now, if I reference a variable outside the scope of the lambda it
turns magically in to a delegate and works!
But that is an ugly hack!
// now x is a delegate and works
auto x = (GdkEventButton* e, Widget w) { auto q = X; ...
Now sure I can hack x and use some template to turn it in to a
fake delegate but then that is dangerous.
I suppose one could have a template that only converts it if it
is a function and then that will deal with both cases and might
work...
But why?
Is there any way to force it to not reduce the delegate to a
function which is obviously an optimization when nothing accesses
the outside context.
Re: BetterC + Windows + setjmp longjmp
On Wednesday, 22 May 2019 at 16:37:36 UTC, Lobachevsky wrote: I have been experimenting with setjmp / longjmp under Windows as a way to break out of an endless loop. With my experiments, longjmp appears to silently exit the process, no stack trace, nothing. Black emptiness. I don't think breaking out of a loop this way can work. The CtrlHandler is called by another thread. Quoting from https://docs.microsoft.com/en-us/windows/console/handlerroutine: An application-defined function used with the SetConsoleCtrlHandler function. A console process uses this function to handle control signals received by the process. When the signal is received, the system creates a new thread in the process to execute the function.
Re: BetterC + Windows + setjmp longjmp
I have been experimenting with setjmp / longjmp under Windows as
a way to break out of an endless loop. With my experiments,
longjmp appears to silently exit the process, no stack trace,
nothing. Black emptiness.
I stared with the C program described in
https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler
and added the setjmp and longjmp code fragments.
When I try this, the CtrlHandler is successfully loaded and it
even beeps accordingly when cntl-C and cntl-break are pressed.
Of course, the Microsoft documentation warns against using setjmp
/ longjump from callbacks:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/longjmp?view=vs-2019
Here is the companion Microsoft setjmp documentation:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setjmp?view=vs-2019
I'm using DMD 2.084, VS 2017, not using BetterC
Compiler arguments: -boundscheck=on -dw -c -gf -debug -g -m64 -wi
Linker: /OUT:"C:\Users\...\Test.exe" /MANIFEST /NXCOMPAT
/PDB:"C:\Users\...\Test.pdb" /DEBUG /MACHINE:X64 /INCREMENTAL
/PGD:"C:\Users\...\Test.pgd" /SUBSYSTEM:CONSOLE
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"x64\Debug\Testexe.intermediate.manifest"
/ERRORREPORT:PROMPT /VERBOSE:Lib /TLBID:1
Suggestions welcome.
// CtrlHandler.d : This file contains the 'main' function.
Program execution begins and ends there.
// See
https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler
module CtrlHandler;
import core.sys.posix.setjmp;
import std.conv;
import core.sys.windows.windows;
import std.stdio;
// #include
// #include
alias ubyte[1024] jmp_buf;
extern(C) {
int _setjmp(ref jmp_buf) nothrow;
void longjmp(ref jmp_buf, int) nothrow;
}
alias _setjmp setjmp;
public static jmp_buf buf;
extern (Windows) private static int CtrlHandler(uint
fdwCtrlType) nothrow {
switch (fdwCtrlType) {
// Handle the CTRL-C signal.
case CTRL_C_EVENT:
// writeln("Ctrl-C event\n\n");
Beep(750, 300);
longjmp(buf, 42);
break;
// CTRL-CLOSE: confirm that the user wants to exit.
case CTRL_CLOSE_EVENT:
Beep(600, 200);
// writeln("Ctrl-Close event\n\n");
longjmp(buf, 39);
break;
// Pass other signals to the next handler.
case CTRL_BREAK_EVENT:
Beep(900, 200);
// writeln("Ctrl-Break event\n\n");
longjmp(buf, 13);
break;
case CTRL_LOGOFF_EVENT:
Beep(1000, 200);
// writeln("Ctrl-Logoff event\n\n");
return 0;
case CTRL_SHUTDOWN_EVENT:
Beep(750, 500);
// writeln("Ctrl-Shutdown event\n\n");
return 0;
default:
return 0;
}
return 0;
}
int main(string[] args)
{
int sj;
sj = setjmp(buf);
writeln("sj = " ~ to!string(sj));
readln();
if (sj != 0) goto breakout;
if (SetConsoleCtrlHandler(&CtrlHandler, 1))
{
writeln("\nThe Control Handler is installed.\n");
writeln("\n -- Now try pressing Ctrl+C or Ctrl+Break,
or");
writeln("\ntry logging off or closing the
console...\n");
writeln("\n(...waiting in a loop for events...)\n\n");
while (1) {}
}
else
{
writeln("\nERROR: Could not set control handler");
return 1;
}
breakout:
writeln("\nSuccessfully broke out of endless loop - sj = " ~
to!string(sj));
return 0;
}
DLS server can't install on my pc
I am having some difficulty installing DLS for dlang 1.16.4 the visual studio code plugin for Dlang on my pc-windows 10 Lenovo laptop ci7. it actually install in my ci3 running windows 10. It says this app can't install on this pc. I will be appreciate any help
viber.d: How to have dynamic query parameter?
Hi, I need to implement an Rest API that has kind of dynamic query parameter, which is an idea of getting Redis hash's field. I have some redis entries set as below * hmset foo:personA key_a key_b foo bar * hmset foo:personB key_a key_b foo bar The API endpoint looks like this [code] /get_person_key?person=personA&data.key_a= [/code] This is to check if the value of personA's `key_a` matches against some pattern. This can work around by using nested path, e.g, `/get_person_key/:person/:key?queryParam=`, but that requires a api spec. updated -- which is not available in my case. Looking at source code of viber's RestInterface doesn't sound this is supported. Thanks for your reading.
Re: Bitfields
On Wednesday, 22 May 2019 at 08:54:45 UTC, Russel Winder wrote: On Tue, 2019-05-21 at 19:14 +, Era Scarecrow via Digitalmars-d-learn wrote: […] I worked on/with bitfields in the past, the limit sizes is more or less for natural int types that D supports. Rust bitfield crate and it's macros are the same, the underlying type for a bitfield must be a primitive integer type. Fortunately, Rust has i128 and u128 which is enough for my 112 bit EIT header. Boris Barboris suggested using BitArray and I willinvestigate but the size_t/byte problem would need to go away. However this limitation is kinda arbitrary, as for simplicity it relies on shifting bits, going larger or any byte size is possible depending on what needs to be stored, but ti's the speed that really takes a penalty when you aren't using native types or you have to do a lot of shifting to get the job done. What's the layout of what you need? I'll see if i can't make something that would work for you. Would be better if you can use a object that breaks the parts down and you can actually fully access those parts, then just re-store it into the limited space you want for storage, which then would be faster than bitfields (although not by much) I found an interesting way forward in the source code of dvbsnoop. It basically uses the byte sequence as a backing store and then has a function to do the necessary accesses to treat it as a bit array. If D's Bit Array can work with bytes instead of size_t then it is exactly what dvbsnoop does (in C) but adds writing as well as reading. The Rust solution using bitfield with a u128 backing it seems to work, but it is all very clumsy even if it is efficacious. If the type of operations you need on your 128 bit container is simple enough (bitwise op) you can implement them, backed by two ulong in a custom struct. I did something similar for the tokens if my language[1]. There are probably wrong stuff in there but for my usage (include and bt) that works seamlessly. [1]: https://github.com/Basile-z/styx/blob/master/src/styx/data_structures.d#L40
Re: Bitfields
On Tue, 2019-05-21 at 19:14 +, Era Scarecrow via Digitalmars-d-learn wrote: > […] > I worked on/with bitfields in the past, the limit sizes is more > or less for natural int types that D supports. Rust bitfield crate and it's macros are the same, the underlying type for a bitfield must be a primitive integer type. Fortunately, Rust has i128 and u128 which is enough for my 112 bit EIT header. Boris Barboris suggested using BitArray and I willinvestigate but the size_t/byte problem would need to go away. > However this limitation is kinda arbitrary, as for simplicity it > relies on shifting bits, going larger or any byte size is > possible depending on what needs to be stored, but ti's the speed > that really takes a penalty when you aren't using native types or > you have to do a lot of shifting to get the job done. > > What's the layout of what you need? I'll see if i can't make > something that would work for you. > > Would be better if you can use a object that breaks the parts > down and you can actually fully access those parts, then just > re-store it into the limited space you want for storage, which > then would be faster than bitfields (although not by much) I found an interesting way forward in the source code of dvbsnoop. It basically uses the byte sequence as a backing store and then has a function to do the necessary accesses to treat it as a bit array. If D's Bit Array can work with bytes instead of size_t then it is exactly what dvbsnoop does (in C) but adds writing as well as reading. The Rust solution using bitfield with a u128 backing it seems to work, but it is all very clumsy even if it is efficacious. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Bitfields
On Tue, 2019-05-21 at 18:22 +, Boris-Barboris via Digitalmars-d-learn wrote: […] > > Never used it myself, but BitArray with careful handling of > endianess might fit your task. > > https://dlang.org/phobos/std_bitmanip.html#.BitArray.this.2 > https://dlang.org/phobos/std_bitmanip.html#.peek I'll have to mull that one over. The incoming data is a sequence of bytes that is treated as a bitfield. Although the standard says "big-endian" it is isn't entirely clear how this relates to the bitfields, I guess I need to read the standard more. :-( I guess the question is whether BitArray can work with bytes rather than size_t as elements of the backing array. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Performance of tables slower than built in?
On Wednesday, 22 May 2019 at 08:25:58 UTC, Basile B. wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
[...]
Hi, lookup tables ARE faster but the problem you have here, and
I'm surprised that nobody noticed it so far, is that YOUR
SWITCH LEADS TO A RUNTIME STRING COMPARISON AT RUNTIME. Just
replace it with a static if (Method = "Linear") { /*...*/} else
{ /*...*/}
Oh no... I meant "==" obviously
Also takes care to the type used. With DMD the implicit
coercion of float and double can lead to extra conversions.
You'll directly see a 15% gain after refactoring the switch.
Re: Performance of tables slower than built in?
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
[...]
Hi, lookup tables ARE faster but the problem you have here, and
I'm surprised that nobody noticed it so far, is that YOUR SWITCH
LEADS TO A RUNTIME STRING COMPARISON AT RUNTIME. Just replace it
with a static if (Method = "Linear") { /*...*/} else { /*...*/}
Also takes care to the type used. With DMD the implicit coercion
of float and double can lead to extra conversions.
You'll directly see a 15% gain after refactoring the switch.
