Re: Deprecation message when assigning Nullable values to an associative array.

2021-04-03 Thread Peter Jacobs via Digitalmars-d-learn

On Saturday, 3 April 2021 at 10:03:09 UTC, rikki cattermole wrote:


On 03/04/2021 10:58 PM, rikki cattermole wrote:

Nullable has an alias this which has been deprecated.

It is due for removal (the alias this).

You can remove it manually from your copy of phobos source.

Otherwise you'll just have to wait until it is removed 
upstream. (deprecation are not errors, so you can ignore them).


So yeah, next release.

https://github.com/dlang/phobos/commit/36c309fc5fb5bc886e14bd8010e1375fa3a57d53#diff-81bed7f05cbd4e992067b7019125e6a1349ebe5098c6980b64bbbca8d5491e17


Thank you.  I am happy with this situation.

PJ



Deprecation message when assigning Nullable values to an associative array.

2021-04-03 Thread Peter Jacobs via Digitalmars-d-learn
I am using the OpenMPI binding and, in recent times, I have been 
getting a deprecation message when compiling.  It seems to be 
related to assigning Nullable!int entries to an associative 
array.  The following program shows the same message three times 
but it does run as I expect.



import std.stdio, std.typecons;

void main(string[] args)
{
Nullable!(int)[string] my_entries;
// First way.
my_entries["A"] = Nullable!int.init;
// Second way.
Nullable!(int) empty;
my_entries["B"] = empty;
// Third way.
my_entries["C"] = 0.nullable;
my_entries["C"].nullify();
writeln("my_entries=", my_entries);

Nullable!(int) b = Nullable!int.init;
writeln("b=", b);
Nullable!(int) c = 0.nullable;
writeln("c=", c);
}



peterj@helmholtz ~/work/play/dlang $ dmd null_test.d
null_test.d(7): Deprecation: function 
`std.typecons.Nullable!int.Nullable.get_` is deprecated - 
Implicit conversion with `alias Nullable.get this` will be 
removed after 2.096. Please use `.get` explicitly.
null_test.d(10): Deprecation: function 
`std.typecons.Nullable!int.Nullable.get_` is deprecated - 
Implicit conversion with `alias Nullable.get this` will be 
removed after 2.096. Please use `.get` explicitly.
null_test.d(12): Deprecation: function 
`std.typecons.Nullable!int.Nullable.get_` is deprecated - 
Implicit conversion with `alias Nullable.get this` will be 
removed after 2.096. Please use `.get` explicitly.

peterj@helmholtz ~/work/play/dlang $ ./null_test
my_entries=["A":Nullable.null, "C":Nullable.null, 
"B":Nullable.null]

b=Nullable.null
c=0


Can someone please tell me how I should set these associative 
array entries such that I keep the compiler happy?




Re: exceptions and optimization

2019-10-21 Thread Peter Jacobs via Digitalmars-d-learn

On Monday, 21 October 2019 at 20:37:32 UTC, Nicholas Wilson wrote:


What kind of conditions are you wanting to throw exception on? 
infinities, NaNs, ill conditioning, something else?


As always the best way to check is to mark the function of 
interest, nothrow take a look at the disassembly and compare to 
without nothrow. You may also want to look to the optimisation 
summary that I _think_ you can get LDC to generate.


Our methods take a few short cuts and occasionally step over a 
stability boundary, so I guess that it may look like 
ill-conditioning.


Thank you for the explanation and suggestions.



exceptions and optimization

2019-10-21 Thread Peter Jacobs via Digitalmars-d-learn
Toward the end of Walter's recent talk, D at 20, he says 
something to the effect that optimizations are disabled when 
exceptions can be thrown.  We have a compressible flow solver in 
which it is very convenient to be able to throw an exception from 
deep within the code and catch it at a relatively high level 
where we can partially recover and continue the calculation.  
Because our calculations can run for days across hundreds of 
processors, we also care about letting the optimizer do its best. 
In what parts of our program would the optimizer be disabled 
because of the presence of the exception and its handling code?  
How do we tell?




Re: Linux & DMD & GtkD

2019-02-18 Thread Peter Jacobs via Digitalmars-d-learn

On Monday, 18 February 2019 at 14:24:46 UTC, Ron Tarrant wrote:

On Monday, 18 February 2019 at 10:38:10 UTC, Peter Jacobs wrote:

Being an old linux user, I prefer make to dub, however, I do 
use dub to build GtkD and then I just use dmd to build my 
application program.


This appeals to me, too.


dub clean
dub build


Got this bit working after generating an sdl file. But I think 
I'm missing something from this next approach:



make
dmd -w -g -debug -I=../GtkD/generated/gtkd \
-oftest_rig_imperative test_rig_imperative.d \
-L../GtkD/libgtkd-3.a
./test_rig_imperative


It's been literally decades since I used a makefile. Did I miss 
the part where you the makefile was written/generated?




Yes, you did miss that part because I didn't write it in, 
thinking that the echo of the command would be sufficient.  
Sorry.  Anyway, here is the single rule in my makefile.  I tend 
to use makefiles as a memory aid so they are often quite simple.


test_rig_imperative: test_rig_imperative.d
dmd -w -g -debug -I=../GtkD/generated/gtkd \
-oftest_rig_imperative test_rig_imperative.d \
-L../GtkD/libgtkd-3.a

Cheers,
Peter J.



Re: Linux & DMD & GtkD

2019-02-18 Thread Peter Jacobs via Digitalmars-d-learn

On Saturday, 16 February 2019 at 13:35:57 UTC, Ron Tarrant wrote:

Hi guys,

I finally got a Linux Mint installation happening (very 
impressed, BTW) and did the usual HelloWorld.d compile with 
dmd, but I'm having trouble working out how to link to GtkD.


dmd -de -w -m64 -L+gtkd hello_gtkd_world.d

says it can't find MainWindow which tells me the gtkd libraries 
are not installed, are not included in the path, or some other 
oversight on my part.


I tried using whereis to find gtkd, but to no avail.

Questions:

1. Am I using the right syntax in the above command line?

2. How to search for things on Linux Mint

The recommendations I've found so far are for the gnome search 
tool which spits out an error:


Package gnome-search-tool is not available, but is referred to 
by another package.
This may mean that the package is missing, has been obsoleted, 
or

is only available from another source


Being an old linux user, I prefer make to dub, however, I do use 
dub to build GtkD and then I just use dmd to build my application 
program.  Here is a transcript of building and running the first 
tutorial exercise on my computer that runs LinuxMint.  It all 
works nicely, when pointing the DMD compiler to the generated 
gtkd bindings and the linker to the dub-built library file.


peterj@helmholtz ~/work/play/dlang/GtkD $ dub clean
Cleaning package at /home/peterj/work/play/dlang/GtkD...
peterj@helmholtz ~/work/play/dlang/GtkD $ dub build
Performing "debug" build using /usr/bin/dmd for x86_64.
gtk-d:gtkd ~master: building configuration "library"...
generated/gtkd/glib/Spawn.d(305,3): Deprecation: foreach: loop 
index implicitly converted from size_t to int

gtk-d:gstreamer ~master: building configuration "library"...
gtk-d:peas ~master: building configuration "library"...
gtk-d:sv ~master: building configuration "library"...
gtk-d:vte ~master: building configuration "library"...
peterj@helmholtz ~/work/play/dlang/GtkD $ cd ../gtkd-example/
peterj@helmholtz ~/work/play/dlang/gtkd-example $ make
dmd -w -g -debug -I=../GtkD/generated/gtkd \
-oftest_rig_imperative test_rig_imperative.d \
-L../GtkD/libgtkd-3.a
peterj@helmholtz ~/work/play/dlang/gtkd-example $ 
./test_rig_imperative

Hello GtkD Imperative
Bye.
peterj@helmholtz ~/work/play/dlang/gtkd-example $ dmd --version
DMD64 D Compiler v2.085.0-beta.1
Copyright (C) 1999-2019 by The D Language Foundation, All Rights 
Reserved written by Walter Bright