Re: Why doesn't this work when the function is a static method?

2021-01-13 Thread Jack via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 17:21:23 UTC, Paul Backus wrote:

On Wednesday, 13 January 2021 at 17:14:04 UTC, Jack wrote:

but if I wrap this within a class:

class Foo
{
static int f(HWND hwnd, int n)
{
return n*10;
}


static void baa()
{
HWND foo;
writeln(foo.f(10));
}
}

I get the error:

Error: no property f for type void*


Member functions (including static ones) can't be called with 
UFCS.


Thanks
 is this documented somewhere? Is this going to change?


Re: How to define delegate with needed parameters

2021-01-13 Thread Tim via Digitalmars-d-learn

On Thursday, 14 January 2021 at 00:29:23 UTC, Paul Backus wrote:

Easiest way is to use a lambda:

doSomething(() => foo(q))


This worked perfectly, thank you for your timely response~


Re: writeln and write at CTFE

2021-01-13 Thread tsbockman via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 23:38:54 UTC, oddp wrote:

Just two langs I use from time to time:

1) nim via forced ctfe; way faster than d by running through a 
vm:


const foo = fib(42)
static:
  echo "foobar"

2) crystal via macros:

{{ puts "foobar" }}

Another one would be zig via comptime, but never tried that.


Good to know... doesn't sound like it's some kind of standard 
"2021" feature, though. Those are all lesser-known languages 
(like D), not industry standard stuff like C++, Java, etc.


Re: Why many programmers don't like GC?

2021-01-13 Thread mw via Digitalmars-d-learn
On Thursday, 14 January 2021 at 00:15:12 UTC, Ola Fosheim Grøstad 
wrote:

On Wednesday, 13 January 2021 at 21:56:58 UTC, mw wrote:
I think this flexibility to mix GC & manual memory management 
is very unique in D. Actually I'm not sure if it can be done 
in other languages at all.


It sure can. Most AOT languages that provide GC also provide 
C-interfaces and manual memory management. C++ also had the 
Boehm-collector since the 90s. Chrome uses Oilpan, a 
library-style GC with write barriers and incremental collection.


ok, what I really mean is:

... in other "(more popular) languages (than D, and directly 
supported by the language & std library only)" ...


Re: How to define delegate with needed parameters

2021-01-13 Thread Paul Backus via Digitalmars-d-learn

On Thursday, 14 January 2021 at 00:19:24 UTC, Tim wrote:
I would like to be able to create a delegate but also supply 
the function parameters to be used for the function call. How 
can I go about doing this? Example:


void foo(int i){
}

void bar(string m){
}

doSomething((q));
doSomething(("test");


Easiest way is to use a lambda:

doSomething(() => foo(q))


Re: Why many programmers don't like GC?

2021-01-13 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 21:56:58 UTC, mw wrote:
I think this flexibility to mix GC & manual memory management 
is very unique in D. Actually I'm not sure if it can be done in 
other languages at all.


It sure can. Most AOT languages that provide GC also provide 
C-interfaces and manual memory management. C++ also had the 
Boehm-collector since the 90s. Chrome uses Oilpan, a 
library-style GC with write barriers and incremental collection.









How to define delegate with needed parameters

2021-01-13 Thread Tim via Digitalmars-d-learn
I would like to be able to create a delegate but also supply the 
function parameters to be used for the function call. How can I 
go about doing this? Example:


void foo(int i){
}

void bar(string m){
}

doSomething((q));
doSomething(("test");


Re: writeln and write at CTFE

2021-01-13 Thread oddp via Digitalmars-d-learn

On 13.01.21 21:47, tsbockman via Digitalmars-d-learn wrote:
Is CTFE I/O a standard feature in other languages? How many other languages even have a CTFE 
feature comparable to D's?


Just two langs I use from time to time:

1) nim via forced ctfe; way faster than d by running through a vm:

const foo = fib(42)
static:
  echo "foobar"

2) crystal via macros:

{{ puts "foobar" }}

Another one would be zig via comptime, but never tried that.


Re: Why many programmers don't like GC?

2021-01-13 Thread tsbockman via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 21:56:58 UTC, mw wrote:
I think this flexibility to mix GC & manual memory management 
is very unique in D. Actually I'm not sure if it can be done in 
other languages at all.


Yes, this is one of the great things about D.

There are miscellaneous problems with the D runtime and the D 
standard library that make it harder than it needs to be, though. 
Improvements I would like to see in the future:


1) Finalize std.experimental.allocator

2) Good, safe, flexible reference counting module in the standard 
library (this requires further development of dip1000 and the 
like, I think).


3) Upgrade core.thread to fully support @nogc. I shouldn't lose 
access to Thread.sleep and the like just because a thread isn't 
being monitored by the GC.


4) Single-threaded versions of various components related to 
memory management that are more efficient because they don't need 
to be thread-safe. For example, people say that reference 
counting is slow because incrementing and decrementing the count 
is an atomic operation, but most references will never be shared 
between threads so it is just a waste to use atomics.


Still, all of these issues can be worked around today; D lacks 
high quality standards in this area more than it lacks necessary 
features.


Re: Why many programmers don't like GC?

2021-01-13 Thread mw via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector 
GC. But I never understood why they complain. What's bad about 
GC?


I want to stress: in D you can *MIX* GC with manual memory 
management, which gives you the best of both world.


I summarized my experience in one earlier post, (and copy & 
pasted below); and I also add the code to jdiutil: Just-Do-It util


https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation

https://github.com/mingwugmail/jdiutil/blob/master/source/jdiutil/memory.d


===
https://forum.dlang.org/post/hzryuifoixwwywwif...@forum.dlang.org

One of the upside of D I like is that one can mix GC with manual 
memory management:


https://dlang.org/library/core/memory/gc.free.html

which gives you the best of both world.

Currently I have a personal project, initially I was solely 
relying on GC just like in Java: allocate all the objects via 
`new`, and let the GC take care of all the bookkeeping. But there 
is a particular set of objects which takes the majority of memory 
consumption of the program, and even after I carefully removed 
all the reference after the object is no longer used, the program 
still use lots of memory because GC collection is un-predictable, 
both in terms of timing and efficiency.


Then I decided to do manual core.memory.GC.free just for that 
particular objects, (it was not very easy in a multi-threaded 
program to make all the logic right, but eventually I got it 
done). And the resulting program now only use ~10% of the memory 
it used to use.


I think this flexibility to mix GC & manual memory management is 
very unique in D. Actually I'm not sure if it can be done in 
other languages at all.

===




Re: Why many programmers don't like GC?

2021-01-13 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector 
GC. But I never understood why they complain. What's bad about 
GC?


tsbockman gave a good answer.

In short:

- You need to design the language for GC for it to be a 
satisfying solution for interactive applications. For D and C++ 
it is bolted on... which is not great.


- You will use roughly twice as much memory with GC (you get more 
garbage).


- You will get more uneven performance with GC (humans are 
smarter).




Re: Developing and running D GUI app on Android

2021-01-13 Thread Adam D. Ruppe via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 20:23:22 UTC, H. S. Teoh wrote:

   Adam may be written a script for this, I'm not 100% sure.


Yeah, my code does it all, though the auto-generation is more 
about accessing Java from D than vice versa, since implementing 
the D parts are simple.


See the example at the top here:
http://dpldocs.info/experimental-docs/arsd.jni.html

Just write the @Export things in D with the right signature for 
the native things in Java and it will just work.


There's code in jni.d to auto-generate stubs but there's really 
no need since it is so simple; you rarely have all *that* many 
native things anyway.


   Adam's jni.d, this is generally very painless: you just 
declare the
   Java class using an equivalent D class, and jni.d uses 
introspection
   to auto-generate the JNI boilerplate for you, then you can 
just call

   it as if it were a D object.


yeah, and it can even read a .jar file to generate the D bindings 
with necessary @Imports automatically (just remember it compiles 
slow to bring it all in so i wouldn't do it when you just need a 
few things.)


Re: writeln and write at CTFE

2021-01-13 Thread tsbockman via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 11:50:26 UTC, Andrey wrote:

Today is 2021. Dlang still doesn't have ctfe write functions?


You make it sound like D is behind the times. Is CTFE I/O a 
standard feature in other languages? How many other languages 
even have a CTFE feature comparable to D's?


Re: Why many programmers don't like GC?

2021-01-13 Thread tsbockman via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector 
GC. But I never understood why they complain. What's bad about 
GC?


SHORT VERSION: While garbage collection is great for many 
applications, GC also has some significant disadvantages. As a 
systems programming language, D attracts users who care about the 
disadvantages of GC, but D's design prevents it from mitigating 
the downsides of GC to the extent that less powerful languages 
like Java can.


LONG VERSION: There are many different garbage collector designs, 
so not all of these criticisms apply to all garbage collector 
designs. Nevertheless, most every design suffers from at least 
some of these problems:


1) Freezes/pauses: many garbage collectors have to pause all 
other threads in the program for some significant time in order 
to collect. This takes somewhere between a few ms and a few s, 
depending on how much data needs to be scanned.


For interactive applications, these pauses can cripple the 
program's performance. 60 FPS, or 16ms per frame, is a typical 
target rate for modern user interfaces, video playback, and 
games. When any given frame may be subject to a 5ms pause by the 
GC, the processing for *every* frame must be limited to what can 
be accomplished in 11ms, effectively wasting 30% of the available 
CPU performance of *all cores* on most frames, when no collection 
was necessary. But, 5ms is on the low end for GC pauses. Pauses 
longer than 16ms are common with some GC designs, guaranteeing 
dropped frames which are distracting and unpleasant to the user.


For real-time applications such as hardware control systems, a 
pause that is too long could actually break something or injure 
someone.


2) Much higher memory consumption: all practical heap memory 
management schemes have some overhead - additional memory that is 
consumed by the manager itself, rather than the rest of the 
program's allocations. But, garbage collectors typically require 
three to ten times the size of the data for good performance, as 
opposed to two times or less for reference counting or manual 
management.


3) RAII doesn't work properly because the GC usually doesn't 
guarantee that destructors will be run for objects that it frees. 
I don't know why this is such a common limitation, but my guess 
is that it is due to one or both of:
a) Collection often happens on a different thread from an 
object's allocation and construction. So, either all destructors 
must be thread-safe, or they just can't be run.
b) A collection may occur at some awkward point where the 
program invariants depended on by non thread-safe destructors are 
violated, like inside of another destructor.


It is certainly possible to retrofit correct resource management 
on top of a GC scheme, but the logic required to determine when 
to close file handles (for example) is often the same as the 
logic required to determine when memory can safely be freed, so 
why not just combine the two and skip the GC?


GC has significant advantages, of course: simplicity (outside the 
GC itself), safety, and, for better designs, high throughput. 
But, the D users are more critical of GC than most for good 
reason:


I) D is a systems programming language. While a good GC is the 
best choice for many, many applications, the kinds of 
applications for which GC is inappropriate usually require, or at 
least greatly benefit from, the full power of a systems 
programming language. So, the minority of programmers who have 
good reason to avoid GC tend to leave other languages like Java, 
C#, python, and JavaScript and come to us (or C, C++, Zig, or 
Rust).


II) Historically, D's GC was embarrassingly bad compared to the 
state-of-the-art designs used by the JVM and .NET platforms. D's 
GC has improved quite a lot over the years, but it is not 
expected to ever catch up to the really good ones, because it is 
limited by other design decisions in the D language that 
prioritize efficient, easy-to-understand interoperability with 
C-style code over having the best possible GC.


In particular, D's GC is a stop-the-world design that must pause 
*all* threads that may own any GC memory whenever it collects, 
and thus it fully suffers from problem (1) which I described 
earlier. Also, it used to have the additional problem that it 
leaked memory by design (not a bug). This is mostly fixed now, 
but for some reason the fix is not enabled by default?! 
https://dlang.org/spec/garbage.html#precise_gc


(In before someone answers with, "Nothing. It works for me, so 
people who say it's bad are just stupid and don't profile.")


Re: Developing and running D GUI app on Android

2021-01-13 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Jan 13, 2021 at 07:51:08PM +, aberba via Digitalmars-d-learn wrote:
[...]
> So Adam's tool setup is pretty clear (talked to him). What remains is
> calling Java classes and interacting with the Android's API. I know a
> little bit of Java but not enough Android. Just the calling
> conversation part.
> 
> Do you have a sample of how that works?

Android's APIs are mostly Java.  So what you'll need to do is to
interface with it via JNI.  The basic idea is:

1) To call D from Java, you'd define Java methods as native methods, and
   implement the native methods in D (using the JNI naming convention so
   that the JVM knows how to match them up) to make it accessible to
   Java code. In your Java class you'd have a static {} block that calls
   System.loadLibrary to load your D code into the JVM. If your entire
   class is in D, it may be possible to auto-generate the Java wrapper;
   Adam may be written a script for this, I'm not 100% sure.

2) To call Java from D, you'd use JNI. This involves a lot of
   boilerplate to marshal your arguments and/or convert them to
   Java-compatible types, and unmarshal/convert the results, and so
   lends itself very well to automation using D templates.  Thanks to
   Adam's jni.d, this is generally very painless: you just declare the
   Java class using an equivalent D class, and jni.d uses introspection
   to auto-generate the JNI boilerplate for you, then you can just call
   it as if it were a D object.

My own code predates Adam's jni.d, though, so I have my own templates
for taking care of the boilerplate.  If you want examples using jni.d
you'd best ask Adam. :-D

If you ever need to look under the hood, though, e.g. for debugging
purposes, take a look at the JNI spec and Android's NDK docs.


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL


Re: Why D functions paramter can not implicit infer type of Variant?

2021-01-13 Thread sighoya via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 19:38:55 UTC, Paul Backus wrote:

That's what Variant is--a struct that models the universal 
supertype (sometimes called "Top" or "Any").


Ahh right. Good point, so it already fits.


Re: Why many programmers don't like GC?

2021-01-13 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Jan 13, 2021 at 06:58:56PM +, Marcone via Digitalmars-d-learn wrote:
> I've always heard programmers complain about Garbage Collector GC. But
> I never understood why they complain. What's bad about GC?

It's not merely a technical issue, but also a historical and
sociological one.  The perception of many people, esp. those with C/C++
background, is heavily colored by the GC shipped with early versions of
Java, which was stop-the-world, inefficient, and associated with random
GUI freezes and jerky animations.  This initial bad impression continues
to persist today esp. among the C/C++ crowd, despite GC technology
having made great advances since those early Java days.

Aside from skewed impressions, there's still these potential concerns
with the GC:

(1) Stop-the-world GC pauses (no longer a problem with modern
generational collectors, but still applies to D's GC);

(2) Non-deterministic destruction of objects (D's dtors are not even
guaranteed to run if it's a GC'd object) -- you cannot predict when an
object will be collected;

(3) GC generally needs more memory than the equivalent manual memory
management system.

(1) and (2) can be mitigated in D in various ways, e.g., prefer structs
over classes to reduce GC load, use GC.stop, GC.collect to control when
collections happen, etc.. Use RAII structs or scope guards for things
that need deterministic destruction. (Or use malloc/free yourself.) (3)
is generally not a big problem unless you're targeting low-memory
devices, in which case you already have to do many things manually
anyway, so you generally won't be relying on the GC in the first place.

There's also the matter of ROI: it's *much* easier, and faster, to write
GC code than code with manual memory management.  For 90% of software,
none of the above concerns matter anyway, and you're just wasting your
time/energy for essentially no benefit (and lots of disadvantages, like
wasting time/energy debugging hard-to-trace pointer bugs and subtle
memory corruptions).  GC code also tends to be cleaner: your APIs don't
have to be polluted with memory-management paraphrenalia that tend to
percolate all over your code and make it hard to read and harder to
maintain.  You get to focus your mental resources on making actual
progress in your problem domain instead of grappling with memory
management issues at every turn.  And most of the time, it's Good
Enough(tm); the customer won't even notice a difference.  The price of
using a GC is far dwarved by the benefits it brings.

Without a GC you're pouring down blood and sweat just to make a little
progress in your problem domain, and the whole time you're plagued with
pointer bugs, memory corruptions, and all sorts of lovely issues that
come with just one tiny mistake in your code but takes hours, days, or
even months to fix. And your code will be convoluted, your API's ugly,
fragile, and hard to maintain. The ROI simply makes no sense, except for
very narrow niches like hard real-time software (where a patient may die
if you get an unexpected GC pause while controlling a radiation
treatment device) and game engine cores.


But there is no convincing a hard-core GC hater sometimes. You do so at
your own risk. :-D


T

-- 
Life begins when you can spend your spare time programming instead of watching 
television. -- Cal Keegan


Re: Developing and running D GUI app on Android

2021-01-13 Thread aberba via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 02:02:16 UTC, H. S. Teoh wrote:
On Sun, Jan 10, 2021 at 06:58:13PM +, aberba via 
Digitalmars-d-learn wrote:

[...]


First, you need a way to build an APK, and then transfer that 
to your Android device for testing.  Building an APK *can* be 
done manually (well, scripted), but I don't recommend it.  The 
simplest way is probably to install Android Studio and the 
Android SDK, and use Gradle to build your project.  Gradle 
takes care of the finicky details of how to build an APK, and 
the Android dev tools let you install to Android in debug mode 
without having to find your own way of transferring APKs.


[...]


So Adam's tool setup is pretty clear (talked to him). What 
remains is calling Java classes and interacting with the 
Android's API. I know a little bit of Java but not enough 
Android. Just the calling conversation part.


Do you have a sample of how that works?


Re: Why D functions paramter can not implicit infer type of Variant?

2021-01-13 Thread Paul Backus via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 18:09:08 UTC, sighoya wrote:
A more natural conclusion would be to infer c to the most 
common supertype as other inferences would unnecessarily 
exclude future assignments to c.  But the most common supertype 
doesn't seem to exist, and I'm unsure if this type can be 
modeled at all in D?


That's what Variant is--a struct that models the universal 
supertype (sometimes called "Top" or "Any").


Re: Why many programmers don't like GC?

2021-01-13 Thread Imperatorn via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector 
GC. But I never understood why they complain. What's bad about 
GC?


I would guess because of performance issues.


Why many programmers don't like GC?

2021-01-13 Thread Marcone via Digitalmars-d-learn
I've always heard programmers complain about Garbage Collector 
GC. But I never understood why they complain. What's bad about GC?


How to get call stack for InvalidMemoryOperationError while doing unittest?

2021-01-13 Thread apz28 via Digitalmars-d-learn

core.exception.InvalidMemoryOperationError@src\core\exception.d(647): Invalid 
memory operation

reference D runtime unittest executor codes
try
{
fp();
++results.passed;
}
catch ( Throwable e )
{
import core.stdc.stdio;
printf("%.*s(%llu): [unittest] %.*s\n",
cast(int) e.file.length, e.file.ptr, cast(ulong) 
e.line,

cast(int) e.message.length, e.message.ptr);

if ( typeid(e) == typeid(AssertError) )
{
// Crude heuristic to figure whether the 
assertion originates in

// the unittested module. TODO: improve.
auto moduleName = m.name;
if (moduleName.length && e.file.length > 
moduleName.length
&& e.file[0 .. moduleName.length] == 
moduleName)

{
// Exception originates in the same module, 
don't print

// the stack trace.
// TODO: omit stack trace only if assert was 
thrown

// directly by the unittest.
continue;
}
}
// TODO: perhaps indent all of this stuff.
_d_print_throwable(e);
}



Re: Why D functions paramter can not implicit infer type of Variant?

2021-01-13 Thread sighoya via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 16:17:02 UTC, Marcone wrote:

import std;

void a(int b){
}

void main()
{
  Variant c = 10;
  a(c); // Error
}

Need more sugar.


Two problems:

1.) Variant is library defined, compared to the language level 
there isn't a default strategy to choose int32 here, it could be 
also, short, long, unsigned ... not to mention all the alias this 
types.
Though it may be possible to define a default strategy but part 
of the problem is how to tell D to init the type parameters 
appropriately.


2.) c is mutable, what is if you return c and assign other values 
of other types to it?
Determining all possibilities by traversing following assignments 
leads to global type inference which no one would ever want to 
have especially with support of subtyping.


A more natural conclusion would be to infer c to the most common 
supertype as other inferences would unnecessarily exclude future 
assignments to c.  But the most common supertype doesn't seem to 
exist, and I'm unsure if this type can be modeled at all in D?





Re: Why D functions paramter can not implicit infer type of Variant?

2021-01-13 Thread Ali Çehreli via Digitalmars-d-learn

On 1/13/21 8:17 AM, Marcone wrote:

> import std;
>
> void a(int b){
> }
>
> void main()
> {
>Variant c = 10;
>a(c); // Error
> }
>
> Need more sugar.

That can't work in a strongly statically typed language. The call a(c) 
is decided at compile time but Variant is not an int at compile time.


It could only work if Variant were a user-defined type that had an 
automatic conversion to int with 'alias this'.


Ali



Re: Why doesn't this work when the function is a static method?

2021-01-13 Thread Paul Backus via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 17:14:04 UTC, Jack wrote:

but if I wrap this within a class:

class Foo
{
static int f(HWND hwnd, int n)
{
return n*10;
}


static void baa()
{
HWND foo;
writeln(foo.f(10));
}
}

I get the error:

Error: no property f for type void*


Member functions (including static ones) can't be called with 
UFCS.


Re: Collections in D

2021-01-13 Thread mw via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 12:06:05 UTC, Roguish wrote:



which seems perfectly adequate.

What about sets?


You can also search https://code.dlang.org

I use:

https://code.dlang.org/packages/emsi_containers

Which has hashset:

https://github.com/dlang-community/containers/blob/fc1625a5a0c253272b80addfb4107928495fd647/src/containers/hashset.d


Why doesn't this work when the function is a static method?

2021-01-13 Thread Jack via Digitalmars-d-learn
works fine (this is defined at global scope, g and baa are same 
as static)


int f(HWND hwnd, int n)
{
return n*10;
}


void baa()
{
HWND foo;
writeln(foo.f(10));
}


but if I wrap this within a class:

class Foo
{
static int f(HWND hwnd, int n)
{
return n*10;
}


static void baa()
{
HWND foo;
writeln(foo.f(10));
}
}

I get the error:

Error: no property f for type void*


Why D functions paramter can not implicit infer type of Variant?

2021-01-13 Thread Marcone via Digitalmars-d-learn

import std;

void a(int b){
}

void main()
{
  Variant c = 10;
  a(c); // Error
}

Need more sugar.


Re: Is there a way to work with processes in Windows without extern(c)?

2021-01-13 Thread dog2002 via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 15:11:40 UTC, Dennis wrote:

On Wednesday, 13 January 2021 at 14:04:52 UTC, dog2002 wrote:

[...]


I don't think this is part of the standard library.
Here's a piece of code I wrote a while ago if that's useful:

[...]


Thank you so much!


Re: How to debug D on Linux

2021-01-13 Thread Daniel Kozak via Digitalmars-d-learn
On Wed, Jan 13, 2021 at 4:10 PM Roguish via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> On Wednesday, 13 January 2021 at 14:17:51 UTC, Rikki Cattermole
> wrote:
> >
> > Same thing.
>
> Clear, thanks.
>
> I'm just discovering today that DMD and LDC are two different
> compilers. I got a different impression from the following
> webpage, which claims that ldmd2 is a wrapper invoking ldc2.
>
>
> https://stackoverflow.com/questions/35515138/ldc2-vs-ldmd2-whats-the-difference
>
> Perhaps this is just a peculiarity of how D is distributed on
> Debian? I simply installed the 'ldc' package from Debian's
> official repos, and that contains both a binary called ldc2 and
> one called ldmd2.
>

There are 3 main compilers which share same frontend,
DMD (using own backend), LDC2(llvm backend) a GDC(gcc backend)

ldmd and gdmd are some wrappers to make similar interface for compiling
with any of these compilers.
So generally dmd, gdmd and ldmd2(on some distribution ldmd without 2)
should have accept same args

So calling  -arg1 -arg2 -arg3 should do the same but
with different compilers behind the scene.


Re: How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 14:27:48 UTC, user1234 wrote:


You really mostly only requires -g. Then you have to learn gdb.
A few basis to get started


I've used GDB before, but I've forgotten nearly all of it. Your 
recap of the basics is appreciated. :-)




Re: Is there a way to work with processes in Windows without extern(c)?

2021-01-13 Thread Dennis via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 14:04:52 UTC, dog2002 wrote:
I could use extern(c) and Process Walking (Process32First, 
Process32Next), but maybe there is a way to get the list by 
means of D?


I don't think this is part of the standard library.
Here's a piece of code I wrote a while ago if that's useful:

```
pragma(lib, "Kernel32.lib");

/**
 * Get a list of tuples for each currently running process, 
containing name and id

 * Returns:
 *   array of (name, id) tuples
 */
auto getProcessList() @system {
	import core.sys.windows.tlhelp32: CreateToolhelp32Snapshot, 
TH32CS_SNAPPROCESS,

Process32First, Process32Next, PROCESSENTRY32;
	import core.sys.windows.windows: HANDLE, INVALID_HANDLE_VALUE, 
CloseHandle;


import std.typecons: Tuple, tuple;
import std.string: fromStringz;
import std.conv: to;

HANDLE hProcessSnap;
PROCESSENTRY32 pe32;
hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
scope(exit) CloseHandle(hProcessSnap);

alias restype = Tuple!(string, "name", int, "id");
restype[] result = [];

if (hProcessSnap != INVALID_HANDLE_VALUE) {
pe32.dwSize = PROCESSENTRY32.sizeof;
for (auto notAtEnd = Process32First(hProcessSnap, );
notAtEnd;
notAtEnd = Process32Next(hProcessSnap, )
) {
			string processName = 
pe32.szExeFile[].ptr.fromStringz.to!string;

result ~= restype(processName, pe32.th32ProcessID);
}
}

return result;
}
```


Re: How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn
On Wednesday, 13 January 2021 at 14:17:51 UTC, Rikki Cattermole 
wrote:


Same thing.


Clear, thanks.

I'm just discovering today that DMD and LDC are two different 
compilers. I got a different impression from the following 
webpage, which claims that ldmd2 is a wrapper invoking ldc2.


https://stackoverflow.com/questions/35515138/ldc2-vs-ldmd2-whats-the-difference

Perhaps this is just a peculiarity of how D is distributed on 
Debian? I simply installed the 'ldc' package from Debian's 
official repos, and that contains both a binary called ldc2 and 
one called ldmd2.


Re: How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 14:13:17 UTC, evilrat wrote:
if you are looking for back trace someone recently posted a 
hint for linux where there is no back trace by default is to 
import core.sys.linux.backtrace or something that has back 
trace info and using it in exception handler for runtime to 
print the stack trace.

https://dlang.org/phobos/core_runtime.html#.defaultTraceHandler


Good tip, thanks.


Re: How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn
On Wednesday, 13 January 2021 at 14:13:11 UTC, Adam D. Ruppe 
wrote:


-debug enables the `debug` keyword inside the D code itself. 
This lets you bypass other rules temporarily. For example


...

It does NOT do anything related to running D in debuggers like 
gdb, it just enables code guarded by that debug keyword.




Thanks, that's very clear.

* Segfaults should be run inside the debugger to get the stack 
trace. If your program did "Segmentation fault (core dumped)", 
you can fire up gdb after the fact on it. Check that directory 
for a .core file and then run `gdb program that.core` to 
inspect it.


It seems on my system no .core file gets generated, even though 
the program outputs "Segmentation fault (core dumped)". At least 
it's not present in the directory from where I compile and run 
the program, nor is it in /var/lib/systemd/coredump where, 
according to systemd-coredump's documentation, it should go by 
default. Anyway, I'm guessing this is a config problem with my 
Linux, rather than anything to do with D's compiler or runtime.


* Running a program in gdb may sometimes say "program received 
SIGUSR1" and pause.


The commands

handle SIGUSR1 noprint
handle SIGUSR2 noprint

will skip this. SIGUSR1/2 are used by the GC when doing 
collections so you probably don't care about it. You can put 
those commands i your ~/.gdbinit to run every time.


* Running `gdb --args ./yourprogram --DRT-trapExceptions=0` 
will break on any uncaught exception so you can inspect that 
stuff. Super useful if you get one of those.


Yes! Excellent tips these. Thank you.


Re: writeln and write at CTFE

2021-01-13 Thread z via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 11:50:26 UTC, Andrey wrote:


Function "ctfeWriteln" doens't exist.

pragma(msg, ...) is used only for CT values.

Today is 2021. Dlang still doesn't have ctfe write functions?


Yes.(afaik)
It has shot me on the foot once, to the point i abandoned the 
idea of ever accomplishing what i wanted to do at compile-time 
and instead just did it at module construction-time, and i must 
admit that it was immediately easier to debug.


Re: How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 14:13:07 UTC, drug wrote:
Short answer - sometimes the compiler does not emit a 
stackframe (due to optimization for example).


OK, so -gs prevents a certain optimization that would make 
debugging harder in certain situations. Thanks for clearing that 
up.




Re: How to debug D on Linux

2021-01-13 Thread user1234 via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote:

On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote:
Anything else I need to know when debugging on Linux, without 
an IDE?


One specific question I have is: what's the difference between 
-g and -debug and -d-debug?


Also, what does it mean to "always emit a stackframe" (compiler 
option -gs) ?


-g : generate dwarf info, the debug info, the most important
-debug : compiles the debug statements, e.g debug logging. not so 
important, this

 is a conditional compilation feature.
-gs: always emit a prelude/prologue. but dmd pretty much 
always do that even

 when not required (sigh).

You really mostly only requires -g. Then you have to learn gdb.
A few basis to get started, a session for a segfault is often like

  $ gdb ./myapp
  $ run

and when it crashes, note the source position, additionally

  $ bt
  $ p somevar
  $ p some.more.complex.expression

may already give interesting infos. If not, during a second 
session you will rather put breakpoints to see what happens 
before the access violation and step from that breakpoint to the 
code that accesses unowned memory.


  $ gdb ./myapp
  $ break .d 
  $ run

and then step by step, each time it pauses you inspect the 
interesting stuff.
Note that I may be wrong on the syntax of the commands as I 
always use an IDE GUI.


Re: How to debug D on Linux

2021-01-13 Thread Rikki Cattermole via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote:

On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote:
Anything else I need to know when debugging on Linux, without 
an IDE?


One specific question I have is: what's the difference between 
-g and -debug and -d-debug?


From LDC (ldc specific):

  --d-debug[=]   - Compile in 
debug code >=  or identified by 
  --d-version= - Compile in 
version code >=  or identified by 


From dmd:

  -debugcompile in debug code
  -debug=compile in debug code <= level
  -debug=compile in debug code identified by ident
  -version=  compile in version code >= level
  -version=  compile in version code identified by ident

Same thing.


Re: How to debug D on Linux

2021-01-13 Thread evilrat via Digitalmars-d-learn
if you are looking for back trace someone recently posted a hint 
for linux where there is no back trace by default is to import 
core.sys.linux.backtrace or something that has back trace info 
and using it in exception handler for runtime to print the stack 
trace.

https://dlang.org/phobos/core_runtime.html#.defaultTraceHandler


On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote:


One specific question I have is: what's the difference between 
-g and -debug and -d-debug?


no idea what is -d-debug, but -g will emit debug info for 
debugger, and -debug will turn on certain features such as 
contracts and asserts even in release builds.


Re: How to debug D on Linux

2021-01-13 Thread Adam D. Ruppe via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote:
One specific question I have is: what's the difference between 
-g and -debug and -d-debug?


-debug enables the `debug` keyword inside the D code itself. This 
lets you bypass other rules temporarily. For example


void foo() pure {
   writeln("called foo");
}

Normally, that wouldn't compile, since writeln is not pure. But 
if you do



void foo() pure {
   debug writeln("called foo");
}

It is allowed. Without the `-debug` switch, that line is just 
ignored, it is not compiled. With the `-debug` switch, that line 
is allowed - and it bypasses the pure restriction.


It does NOT do anything related to running D in debuggers like 
gdb, it just enables code guarded by that debug keyword.



-g


-g is what compiles in the information gdb uses. This info is 
used to print function names in stack traces, make breakpoints by 
file and line number, etc.



You can use -g and -debug together or independently or whatever 
depending on what exactly you want to do.




Now, some general tips on using D with gdb:


* Segfaults should be run inside the debugger to get the stack 
trace. If your program did "Segmentation fault (core dumped)", 
you can fire up gdb after the fact on it. Check that directory 
for a .core file and then run `gdb program that.core` to inspect 
it.


* Running a program in gdb may sometimes say "program received 
SIGUSR1" and pause.


The commands

handle SIGUSR1 noprint
handle SIGUSR2 noprint

will skip this. SIGUSR1/2 are used by the GC when doing 
collections so you probably don't care about it. You can put 
those commands i your ~/.gdbinit to run every time.


* Running `gdb --args ./yourprogram --DRT-trapExceptions=0` will 
break on any uncaught exception so you can inspect that stuff. 
Super useful if you get one of those.


Re: How to debug D on Linux

2021-01-13 Thread drug via Digitalmars-d-learn

On 1/13/21 4:47 PM, Roguish wrote:


Also, what does it mean to "always emit a stackframe" (compiler option 
-gs) ?


Short answer - sometimes the compiler does not emit a stackframe (due to 
optimization for example). In general if you are able to debug your 
binary by gdb then you don't need to worry this flag.

I skip long answer, sorry :-) But you can google about stack frame.


Re: How to debug D on Linux

2021-01-13 Thread drug via Digitalmars-d-learn

On 1/13/21 4:47 PM, Roguish wrote:

On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote:

Anything else I need to know when debugging on Linux, without an IDE?


One specific question I have is: what's the difference between -g and 
-debug and -d-debug?


Also, what does it mean to "always emit a stackframe" (compiler option 
-gs) ?


https://stackoverflow.com/questions/17392200/debugging-dmd-generate-program-through-gdb


Is there a way to work with processes in Windows without extern(c)?

2021-01-13 Thread dog2002 via Digitalmars-d-learn
I need to get a list of processes in Windows (and their pid). I 
could use extern(c) and Process Walking (Process32First, 
Process32Next), but maybe there is a way to get the list by means 
of D?


Re: How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote:
Anything else I need to know when debugging on Linux, without 
an IDE?


One specific question I have is: what's the difference between -g 
and -debug and -d-debug?


Also, what does it mean to "always emit a stackframe" (compiler 
option -gs) ?


Re: How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 13:22:01 UTC, Roguish wrote:

How to debug D?  be possible to get at least a stack trace?


I've discovered that GDB works with the binary generated by the D 
compiler, so that's great.


Anything else I need to know when debugging on Linux, without an 
IDE?


Re: Collections in D

2021-01-13 Thread Roguish via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 12:39:50 UTC, evilrat wrote:
There is no specific set container, they just implemented as 
generic algorithms over the ranges.


I see. Thanks for pointing that out.



How to debug D on Linux

2021-01-13 Thread Roguish via Digitalmars-d-learn
How to debug D? My little trial app gives a segmentation fault. 
Probably a null pointer somewhere, which I could find simply by 
reading my code. But I'm puzzled that the program outputs very 
little helpful info when it crashes, even though I've compiled 
with all the debug options I could find in the docs:


   -g -gs -gf -debug -d-debug

Still all I get at runtime is

   Segmentation fault (core dumped)

Surely it should be possible to get at least a stack trace?


Re: Collections in D

2021-01-13 Thread Roguish via Digitalmars-d-learn
On Wednesday, 13 January 2021 at 12:48:47 UTC, Ferhat Kurtulmuş 
wrote:
I read many posts that rbtree can be a replacement for sets in 
dlang.


see its behaviour is identical.


Thanks, will read up.




Re: Collections in D

2021-01-13 Thread Ferhat Kurtulmuş via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 12:06:05 UTC, Roguish wrote:

On Wednesday, 13 January 2021 at 11:58:11 UTC, Roguish wrote:
I can't find anything about collections in D. All I have found 
are arrays and maps ("associative arrays"). What about lists 
and sets? What if I just want a linked list?


It seems collections are called "containers" in D's standard 
library, which explains why I didn't find anything searching 
for "collections".


As concerns linked lists, I have found

   https://dlang.org/phobos/std_container_dlist.html

which seems perfectly adequate.

What about sets?


I read many posts that rbtree can be a replacement for sets in 
dlang.


see its behaviour is identical.

https://dlang.org/phobos/std_container_rbtree.html


Re: Collections in D

2021-01-13 Thread evilrat via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 12:06:05 UTC, Roguish wrote:


What about sets?


There is no specific set container, they just implemented as 
generic algorithms over the ranges.


There is a section for set operations (std.algorithm.setops 
module).

https://dlang.org/phobos/std_algorithm.html


Re: Anything in D to avoid check for null everywhere?

2021-01-13 Thread ddcovery via Digitalmars-d-learn

On Tuesday, 12 January 2021 at 21:37:11 UTC, Jack wrote:
I was looking for a way to avoid null checks everywhere. I was 
checking the Null object pattern, or use something like enforce 
pattern, or even if I could make a new operator and implement 
something like C#'s .? operator, that Java was going to have 
one but they refused[1] (doesn't behave exactly as C#'s 
actually), Kotlin also got something in this area[2]


What some D ways to avoid those checks?

[1]: 
https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/47.html
[2]: 
https://kotlinlang.org/docs/reference/null-safety.html#safe-calls


Hi Jack,

I have created this example implementation of the "Null safety" 
pattern using templates in D:


https://github.com/ddcovery/d_null_safety

It is, basically, a monad (functional programming orientation)  
with some syntax sugar taking advantage of the power of templates 
in D.





Re: Collections in D

2021-01-13 Thread Roguish via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 11:58:11 UTC, Roguish wrote:
I can't find anything about collections in D. All I have found 
are arrays and maps ("associative arrays"). What about lists 
and sets? What if I just want a linked list?


It seems collections are called "containers" in D's standard 
library, which explains why I didn't find anything searching for 
"collections".


As concerns linked lists, I have found

   https://dlang.org/phobos/std_container_dlist.html

which seems perfectly adequate.

What about sets?


Re: Collections in D

2021-01-13 Thread Ferhat Kurtulmuş via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 11:58:11 UTC, Roguish wrote:
I can't find anything about collections in D. All I have found 
are arrays and maps ("associative arrays"). What about lists 
and sets? What if I just want a linked list?


You can refer to the docs for them:

https://dlang.org/phobos/std_container.html

https://dlang.org/phobos/std_container_slist.html
https://dlang.org/phobos/std_container_dlist.html

For sets see:
https://forum.dlang.org/thread/vqyxqkcszqfwpgqtj...@forum.dlang.org



Collections in D

2021-01-13 Thread Roguish via Digitalmars-d-learn
I can't find anything about collections in D. All I have found 
are arrays and maps ("associative arrays"). What about lists and 
sets? What if I just want a linked list?


Re: writeln and write at CTFE

2021-01-13 Thread Andrey via Digitalmars-d-learn
On Wednesday, 13 January 2021 at 11:31:16 UTC, Bastiaan Veelo 
wrote:
On Wednesday, 13 January 2021 at 09:11:53 UTC, Guillaume Piolat 
wrote:

On Wednesday, 13 January 2021 at 08:35:09 UTC, Andrey wrote:

Hello all,
Tell me please how can I "writeln" and "write" in function 
that is used in CTFE?

At the moment I get this:
import\std\stdio.d(4952,5): Error: variable impl cannot be 
modified at compile time


Or may be exist some other ways to do it?


pragma(msg, );


This may however not do what you wish it to do: 
https://forum.dlang.org/post/mailman.4526.1499573493.31550.digitalmars-d-le...@puremagic.com


— Bastiaan.


Function "ctfeWriteln" doens't exist.

pragma(msg, ...) is used only for CT values.

Today is 2021. Dlang still doesn't have ctfe write functions?


Re: writeln and write at CTFE

2021-01-13 Thread Bastiaan Veelo via Digitalmars-d-learn
On Wednesday, 13 January 2021 at 09:11:53 UTC, Guillaume Piolat 
wrote:

On Wednesday, 13 January 2021 at 08:35:09 UTC, Andrey wrote:

Hello all,
Tell me please how can I "writeln" and "write" in function 
that is used in CTFE?

At the moment I get this:
import\std\stdio.d(4952,5): Error: variable impl cannot be 
modified at compile time


Or may be exist some other ways to do it?


pragma(msg, );


This may however not do what you wish it to do: 
https://forum.dlang.org/post/mailman.4526.1499573493.31550.digitalmars-d-le...@puremagic.com


— Bastiaan.


Re: Anything in D to avoid check for null everywhere?

2021-01-13 Thread ddcovery via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 09:02:37 UTC, ddcovery wrote:

Find more details here:

https://run.dlang.io/gist/392c06e745d1a35df71084ce4d29fed7


Ups... it seems that the link is not working (it is the first 
time I try to generate a dalng/gist link... I'm not sure if this 
can really be done)...


I will create an example github project tonight... may be it can 
help you.











Re: writeln and write at CTFE

2021-01-13 Thread Guillaume Piolat via Digitalmars-d-learn

On Wednesday, 13 January 2021 at 08:35:09 UTC, Andrey wrote:

Hello all,
Tell me please how can I "writeln" and "write" in function that 
is used in CTFE?

At the moment I get this:
import\std\stdio.d(4952,5): Error: variable impl cannot be 
modified at compile time


Or may be exist some other ways to do it?


pragma(msg, );


Re: Anything in D to avoid check for null everywhere?

2021-01-13 Thread ddcovery via Digitalmars-d-learn

On Tuesday, 12 January 2021 at 21:37:11 UTC, Jack wrote:
I was looking for a way to avoid null checks everywhere. I was 
checking the Null object pattern, or use something like enforce 
pattern, or even if I could make a new operator and implement 
something like C#'s .? operator, that Java was going to have 
one but they refused[1] (doesn't behave exactly as C#'s 
actually), Kotlin also got something in this area[2]


What some D ways to avoid those checks?

[1]: 
https://mail.openjdk.java.net/pipermail/coin-dev/2009-March/47.html
[2]: 
https://kotlinlang.org/docs/reference/null-safety.html#safe-calls


Personally, I really like functional orientation (MayBe, None, 
Some... and pattern matching) avoiding the use of null, but D is 
a "system" language compatible with C and null is mandatory.


Some months ago I wrote an utility template to simulate the ?. 
mechanism.



The resulting syntax:

  class Person
  {
string name;
Person father;

this(string name, Person father){   
  this.name=name;
  this.father=father;
}
  }

 Person p = new Person("Peter", new Person("John", null));
 assert( p.d!"father".d!"father".d!"name".get is null);
 assert( p.d!"father".d!"name".get == "John");
 assert( p.d!"father".d!"name".d!"length".get(0) == 4);
 assert( p.d!"father".d!"father".d!"name".d!"length".get(0) == 0);
 assert( (cast(Person) null).d!"father".d!"father".d!"father".get 
is null);



That is a "compact" version of a first solution using lambdas

 assert( 
dot(p).dot(a=>a.father).dot(a=>a.father).dot(a=>a.name).dot(a=>a.length).get(0) == 0);


Find more details here:

https://run.dlang.io/gist/392c06e745d1a35df71084ce4d29fed7



writeln and write at CTFE

2021-01-13 Thread Andrey via Digitalmars-d-learn

Hello all,
Tell me please how can I "writeln" and "write" in function that 
is used in CTFE?

At the moment I get this:
import\std\stdio.d(4952,5): Error: variable impl cannot be 
modified at compile time


Or may be exist some other ways to do it?


Re: Member variables in method are null when called as delegate from thread

2021-01-13 Thread Arafel via Digitalmars-d-learn

On 13/1/21 3:15, Tim wrote:


Fantastic response, thank you! I did some more digging and properly 
narrowed down where the issue is and created a test script that 
demonstrates the problem. Let me know what you think and if it could 
still be a similar problem to what you have stated above. I'll still 
read that info you sent to sharpen up on these concepts.


Basically, the program calls a function which modifies a document in the 
database. If it is called form it's own class' constructor, it works 
fine. If it is called by a thread, it never returns. I don't think that 
a member variable is going null or anything. But a strange problem that 
I can't seem to debug. The output is at the bottom.




import vibe.db.mongo.mongo;
import core.thread;
import std.stdio;

void main(){
     auto callable = new Callable();

     while(true){}
}

class Caller : Thread{
     void delegate() mFunc;

     this(void delegate() func){
     mFunc = func;
     super();
     start();
     }

     void loop(){
     while(true){
     mFunc();
     }
     }
}

class Callable{
     MongoClient db;
     Caller caller;

     this(){
     db = connectMongoDB("127.0.0.1");
     foo();
     caller = new Caller();
     }

     ~this(){
 db.cleanupConnections();
     }

     void foo(){
     writeln("Started");
     auto result = db.getCollection("test.collection").findAndModify([
     "state": "running"],
     ["$set": ["state": "stopped"]
 ]);
     writeln(result);
     writeln("Finished");
     }
}



Output:
     Started
{"_id":"5ff6705e21e91678c737533f","state":"running","knowledge":true}
     Finished
     Started


Something that you could try for debugging is to add a try / catch block 
around your call to `db.getCollection` (and printing out the exception 
details). IIRC, if a thread throws, it will just end without printing 
anything until the thread is joined, when the exception will be rethrown 
[1].


The program hanging would be then the main thread waiting. This kind of 
problem has already bitten me more than once...


[1]: https://dlang.org/library/core/thread/osthread/thread.join.html