Re: Should the "front" range primitive be "const" ?
On Wednesday, 31 January 2018 at 01:45:57 UTC, H. S. Teoh wrote: I haven't thought through it carefully, but if .headConst is a viable solution to the head-const problem, then conceivably we could also extend it to deal with immutable payloads too. Then we could go from, say, RefCounted!(immutable(T)) to RefCounted!(const(T)) generically, without any casting or breaking the type system. We could potentially expand the scope of usefulness of immutable this way, if this approach turns out to be workable. Going from RefCounted!(immutable(T)) to RefCounted!(const(T)) is nice, but I'd like to see a conversion from, const(RefCounted!T) to RefCounted!(const(T)). While this cannot be done without casts, the logic can be put inside .headMutable(), and include relevant checks. This will make it much safer than having the programmer cast manually. -- Simen
Re: Don't expect class destructors to be called at all by the GC
On Wednesday, January 31, 2018 10:51:10 DanielG via Digitalmars-d-learn wrote: > On Wednesday, 31 January 2018 at 10:34:53 UTC, Mike Parker wrote: > > delete is deprecated: > > > > https://dlang.org/deprecate.html#delete > > Ah, thanks! Actually double-thanks, because my progress through > your book is what prompted me to search for threads about class > destructors. The existence of .destroy answers my question > (namely, "should I just use 'delete', or my own .dispose method, > for deterministic resource freeing?") The main problem with delete is that it's inherently unsafe. GC-managed memory is supposed to be @safe (it's one of the main reasons that D has a GC in the first place), but having the programmer go and delete a GC-managed object rather than waiting for the GC to do it makes it trivial to do wrong stuff like free an object's memory while it's still referenced by something else (the sort of thing that the GC is supposed to avoid). It's far better to either explicitly destroy the object without freeing its memory or to use memory that is not managed by the GC if you want deterministic destruction of an object on the heap. - Jonathan M Davis
Re: Should the "front" range primitive be "const" ?
On 1/31/18 7:49 PM, Jonathan M Davis wrote:
On Wednesday, January 31, 2018 11:58:38 Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 1/30/18 8:05 PM, Jonathan M Davis wrote:
Except that unless front returns by ref, it really doesn't matter
whether
front is const unless it's violating the range API, since front is
supposed to return the same value until popFront is called (or if it's
assigned a new value via a front that returns by ref). So, in practice,
putting const on front really doesn't help you any, and it actually
hurts you for range composability.
Right, but that is the difference between a convention ("front is
supposed to...") vs. a compiler-enforced guarantee (modifying data by
calling a const-tagged front is a compiler error).
If you are OK with conventions, you don't need const at all.
Except that if you're the one writing the function and decided whether it's
const or not, you're also the one deciding whether it returns by ref or not.
Unless you're dealing with a reference type, and it doesn't return by ref,
then const doesn't protect front at all. It just affects whether it can be
called on a const range.
You are misunderstanding here. You don't put const on front for the
purpose of allowing const ranges (which are useless), what it does is
say that the compiler guarantees, *even if the range is mutable* that
front won't modify it.
That is, code like the following is rejected by the compiler:
int front() const { return ++val; }
In other words, it's a contract that you can read without having to
examine the code saying "this won't mutate the range".
Sure, you can document "front shouldn't modify the range", and use that
convention, but without const, the compiler doesn't care.
If you're dealing with generic code, then you have less control, and const
starts mattering more, since you don't necessarily know what type is being
returned, and if you're returning front from an underlying range, you the
choice of eixther returning it by value or returning it by auto ref in case
the underlying range returned by ref and passing that refness on is
desirable. But const also interacts far more badly with generic code,
because the odds are pretty high that it won't work in many cases. So, while
in principle, using const to actually have the guarantees is valuable, in
practice, it isn't very viable, because D's const is so restrictive.
Technically, wrapping requires introspection. If you don't care about
forwarding the "guarantee" of constness, then you can just tag all your
functions mutable, but if you do care, then you have to introspect.
Personally, I avoid const in generic code like the plague, because unless
you've restricted the types enough to know what you're dealing with and know
that it will work with const, the odds are quite high that you're writing
code that's going to fall flat on its face with many types.
Indeed, it's not straightforward, if you have to deal with types that
aren't tagged the way they should be. In addition, const is not inferred
for templates like other attributes, so you can't rely on that either.
-Steve
Re: enforce (i > 0) for i = int.min does not throw
On 1/31/18 6:19 PM, Azi Hassan wrote:
On Saturday, 27 January 2018 at 14:13:49 UTC, kdevel wrote:
I would expect this code
enforce3.d
---
import std.exception;
void main ()
{
int i = int.min;
enforce (i > 0);
}
---
to throw an "Enforcement failed" exception, but it doesn't:
$ dmd enforce3.d
$ ./enforce3
[nothing]
I wonder if it's caused by a comparison between signed and unsigned
integers.
No, the answer is, there's a shortcut optimization used by the compiler.
See the discussion elsewhere in this thread.
import std.stdio;
void main ()
{
int zero = 0;
writeln(int.min > 0u);
writeln(int.min > zero);
}
Note that comparing the literal int.min will get folded into a constant,
and do the right thing. You have to assign it a variable to see the
incorrect behavior:
int i = int.min;
writeln(i > 0);
-Steve
Re: Should the "front" range primitive be "const" ?
On Wednesday, January 31, 2018 11:58:38 Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 1/30/18 8:05 PM, Jonathan M Davis wrote:
> > Except that unless front returns by ref, it really doesn't matter
> > whether
> > front is const unless it's violating the range API, since front is
> > supposed to return the same value until popFront is called (or if it's
> > assigned a new value via a front that returns by ref). So, in practice,
> > putting const on front really doesn't help you any, and it actually
> > hurts you for range composability.
>
> Right, but that is the difference between a convention ("front is
> supposed to...") vs. a compiler-enforced guarantee (modifying data by
> calling a const-tagged front is a compiler error).
>
> If you are OK with conventions, you don't need const at all.
Except that if you're the one writing the function and decided whether it's
const or not, you're also the one deciding whether it returns by ref or not.
Unless you're dealing with a reference type, and it doesn't return by ref,
then const doesn't protect front at all. It just affects whether it can be
called on a const range.
If you're dealing with generic code, then you have less control, and const
starts mattering more, since you don't necessarily know what type is being
returned, and if you're returning front from an underlying range, you the
choice of eixther returning it by value or returning it by auto ref in case
the underlying range returned by ref and passing that refness on is
desirable. But const also interacts far more badly with generic code,
because the odds are pretty high that it won't work in many cases. So, while
in principle, using const to actually have the guarantees is valuable, in
practice, it isn't very viable, because D's const is so restrictive.
Personally, I avoid const in generic code like the plague, because unless
you've restricted the types enough to know what you're dealing with and know
that it will work with const, the odds are quite high that you're writing
code that's going to fall flat on its face with many types.
- Jonathan M Davis
Re: enforce (i > 0) for i = int.min does not throw
On Saturday, 27 January 2018 at 14:13:49 UTC, kdevel wrote:
I would expect this code
enforce3.d
---
import std.exception;
void main ()
{
int i = int.min;
enforce (i > 0);
}
---
to throw an "Enforcement failed" exception, but it doesn't:
$ dmd enforce3.d
$ ./enforce3
[nothing]
I wonder if it's caused by a comparison between signed and
unsigned integers.
import std.stdio;
void main ()
{
int zero = 0;
writeln(int.min > 0u);
writeln(int.min > zero);
}
$ rdmd test.d
true
false
The same behavior can be observed in C :
#include
#include
int main(void)
{
int zero = 0;
printf("%d\n", INT_MIN > 0u);
printf("%d\n", INT_MIN > zero);
return 0;
}
$ gcc test.c && ./a.out
1
0
Re: Terminating multiple processes
On Wednesday, 31 January 2018 at 17:44:37 UTC, Russel Winder wrote: So, I have an application which has a sort of nano-services architecture, basically it is a set of communicating processes. Terminating those processes blocked on an input channel is quite easy, send a terminate message on the input channel. But what about a process that has no input channel, one that is blocked on OS events? Is there a way of forcibly, but nicely, terminating a spawned process that never executes `receive()`? Assuming your're talking about threads: there's no secure method of forcing the thread to stop. Threads share the state (eg. can hold the locks) and killing them is always risky. If your threads are blocked reading the socket, you probably can close these sockets and exit after the read error. Another way is to use atomic flag indicating that thread needs to be interrupted. After any blocking operation, the thread have to check this flag and finish the job. It's good to use timeouts (eg socket timeout) in such scenario (if possible). Arek
Re: How to get a range from std.container.array for use with std.format.sformat?
On 1/30/18 2:19 PM, cc wrote:
Still doesn't work without the cast it seems..
auto rng = str[];
rng.sformat!"%s:%s"("some", "string");
// Error: template std.format.sformat cannot deduce function from
argument types !("%s:%s")(RangeT!(Array!char), string, string)
I misunderstood what you were trying to do. I thought you were just
trying to get a valid range, missed the requirement that the range works
with sformat (obviously from the subject! sorry).
Indeed, there isn't a way to extract an actual char[] from Array (and
this is intentional).
But as Seb says, you can use formattedWrite:
auto rng = str[];
rng.formattedWrite("%s:%s", "some", "string");
-Steve
Re: Terminating multiple processes
On 1/31/18 12:44 PM, Russel Winder wrote: So, I have an application which has a sort of nano-services architecture, basically it is a set of communicating processes. Terminating those processes blocked on an input channel is quite easy, send a terminate message on the input channel. But what about a process that has no input channel, one that is blocked on OS events? Is there a way of forcibly, but nicely, terminating a spawned process that never executes `receive()`? You talking about processes or threads? `receive` I believe is an inter-thread channel, no? Terminating processes is generally done via signals or in the case of windows, calling the right system call. Threads are another story. Typically, you need to have the thread check periodically for a termination event. There's no "nice" way to do it out of band. In my experience, the best way to do it is to never block, but use some sort of "wait on input" for any would-be-blocking operation. You can use a large timeout, like 1 second, if immediate termination isn't important. If you are using Fibers, and all your i/o is done using some event-based system (e.g. vibe.d), then things can be easier. -Steve
Terminating multiple processes
So, I have an application which has a sort of nano-services architecture, basically it is a set of communicating processes. Terminating those processes blocked on an input channel is quite easy, send a terminate message on the input channel. But what about a process that has no input channel, one that is blocked on OS events? Is there a way of forcibly, but nicely, terminating a spawned process that never executes `receive()`? -- 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: rdmd main.d leads to Segmentation fault
On Wednesday, 31 January 2018 at 08:40:26 UTC, Kagamin wrote: On Tuesday, 30 January 2018 at 16:56:28 UTC, Timoses wrote: Output: https://pastebin.com/raw/SSx0P1Av Helps? Looks like TLS is not initialized. And I would need to do what about it? Sorry, I'm not familiar with assembly code stuff in detail.
Re: Should the "front" range primitive be "const" ?
On 1/30/18 8:05 PM, Jonathan M Davis wrote:
Except that unless front returns by ref, it really doesn't matter whether
front is const unless it's violating the range API, since front is supposed
to return the same value until popFront is called (or if it's assigned a new
value via a front that returns by ref). So, in practice, putting const on
front really doesn't help you any, and it actually hurts you for range
composability.
Right, but that is the difference between a convention ("front is
supposed to...") vs. a compiler-enforced guarantee (modifying data by
calling a const-tagged front is a compiler error).
If you are OK with conventions, you don't need const at all.
-Steve
Re: enforce (i > 0) for i = int.min does not throw
On 1/30/18 3:37 PM, kdevel wrote:
On Sunday, 28 January 2018 at 19:17:49 UTC, Steven Schveighoffer wrote:
This is insane. i > 0 is used in so many places. The only saving grace
appears to be that int.min is just so uncommonly seen in the wild.
And another one that it does not happen when compiled with optimization
(-O) and also that it does not affect all the ints:
---
import std.stdio;
void foo (T) ()
{
auto i = T.min;
writefln ("%12s: %24X %12s", T.stringof, i, i > cast(T) 0);
}
void main ()
{
foo!byte;
foo!short;
foo!int;
foo!long;
}
---
byte: 80 false
short: 8000 false
int: 8000 true
long: 8000 true
This is due to integer promotion
(https://dlang.org/spec/type.html#usual-arithmetic-conversions). Any
operation between two non-integers, first the two operands are promoted
to integers.
You can see the result here:
https://run.dlang.io/is/RAk9tE
In 32 bit mode:
byte: 80 false
short: 8000 false
int: 8000 true
long: 8000 false
Most likely, this is due to the fact that working with longs cannot be
done natively by the CPU, so it can't use the same shifting shortcut
that causes the issue in the first place.
-Steve
Re: How to proceed with learning to code Windows desktop applications?
On Wednesday, 31 January 2018 at 12:25:36 UTC, John Chapman wrote: Just to say that it is actually possible to write modern Windows apps in D - I've done it. WinRT is just COM. Granted it's not as easy as using Microsoft's language projections, but it's doable if you really want to. The .winmd files describing the WinRT API surface are machine-readable, so in theory some enterprising D developer should be able to generate an elegant D projection. But as with many things, there might not be much overlap between "those who can" and "those who want to" :P It's certainly beyond my skill level at the moment ...
what is local package map(local-packages.json) for dub while doing building?
$ dub build -b release -v Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/john/.dub/packages/local-packages.json Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/john/.dub/packages/local-packages.json Found dependency gtk-d 3.7.3 Found dependency gtk-d:sv 3.7.3 Found dependency gtk-d:gtkd 3.7.3 Found dependency gtk-d:gstreamer 3.7.3 Found dependency gtk-d:peas 3.7.3 Found dependency gtk-d:vte 3.7.3 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/john/.dub/packages/local-packages.json Found dependency gtk-d 3.7.3 Found dependency gtk-d:sv 3.7.3 Found dependency gtk-d:gtkd 3.7.3 Found dependency gtk-d:gstreamer 3.7.3 Found dependency gtk-d:peas 3.7.3 Found dependency gtk-d:vte 3.7.3 Checking for upgrades. Using cached upgrade results... Generating using build The verbose message is confusing. Why are there so many attempts to look for local package map? And I don't even have it. How can I generate one if it's useful? What does "Checking for upgrades" do?
Re: Don't expect class destructors to be called at all by the GC
On Thursday, 21 December 2017 at 18:45:27 UTC, Adam D. Ruppe wrote: On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote: When the scoped destruction of structs isn't an option, RefCounted!T seems to be a less evil alternative than an unreliable class dtor. :-/ Alas, RefCounted doesn't work well with inheritance... Though, what you could do is make the refcounted owners and borrow the actual reference later. Is there some summary of the things you have to be aware of when using the GC in D and not using the GC? I feel this would be very useful especially for people that are new to D or are not used to that kind of issues (because coming from a GCed language).
Re: How to proceed with learning to code Windows desktop applications?
On Tuesday, 30 January 2018 at 18:52:18 UTC, I Lindström wrote: On Tuesday, 30 January 2018 at 12:30:36 UTC, rjframe wrote: VS release builds compile to native now by default; for easy Windows programming, you really can't beat C# and drawing the GUI (Windows Forms, not necessarily the new stuff). If the OP wants to learn what's needed for more complex GUI tasks (like for most non-simple applications), learning to build a GUI from source is kind of necessary though. I've been looking into C# and VS2017 today along with VisualD. Reading through all this it looks like the simplest path is to learn C# and VS and go from there. I've found a pile of courses on LinkedIn that seem to build up to what I need. What makes me sad is that I have to drop D for at least the time being. As other have said, WPF and C# is the way to go for Windows GUI programming, but you don't necessarily need to drop D. You could write your interface code in VS and have it call your D library via pinvoke (Platform Invoke). To make this work you must mark your public D functions with extern(C). Read the documentation on extern(C) and PInvoke. Honestly, I don't know why more people don't do this. It really seems to be like the best of both worlds, as C# + WPF is king for Windows GUI and D is king for library development. The only drawback I can think of is you have to expose your awesome D library via a dumped down C interface.
Re: How to proceed with learning to code Windows desktop applications?
On Wednesday, 31 January 2018 at 11:52:20 UTC, rumbu wrote: On Windows platform, WPF is the way to go right now. Once you accommodate yourself with XAML (descriptive language for designing windows and controls), you can step up from WPF to modern Windows apps (UWP). Unfortunately, none of these technologies are supported in D. Just to say that it is actually possible to write modern Windows apps in D - I've done it. WinRT is just COM. Granted it's not as easy as using Microsoft's language projections, but it's doable if you really want to.
Re: How to proceed with learning to code Windows desktop applications?
On Monday, 29 January 2018 at 22:55:12 UTC, I Lindström wrote: Hello all! I've been doing console apps for about a year and a half now, but my requirements are reaching the limits of easy to use with ASCII-based UI and typed commands so I'm thinking of moving into GUI-era with my projects. I was wondering if some one could help me into the right direction. I've been Googling a ton these past few days for some kind of a book or a course on how to code desktop applications for Windows, but either there isn't one, or it's very well hidden. I've found bits and pieces but nothing to give me a coherent approach. The other way I've been thinking is to do the thing browser-based, but for some reason that doesn't feel right. On Windows platform, WPF is the way to go right now. Once you accommodate yourself with XAML (descriptive language for designing windows and controls), you can step up from WPF to modern Windows apps (UWP). Unfortunately, none of these technologies are supported in D. WinAPI is for masochistic people, WinForms is obsolete. But we are leaving in the everything-is-an-web-app era, therefore don't dismiss the idea of an web application. I don't like them either.
Re: Should the "front" range primitive be "const" ?
On Wed, Jan 31, 2018 at 07:08:58AM +, Simen Kjærås via Digitalmars-d-learn wrote: > On Wednesday, 31 January 2018 at 01:45:57 UTC, H. S. Teoh wrote: > > .headConst > > .headMutable. :p Head-const is something we generally want to avoid. [...] *facepalm* Yes, .headMutable, not .headConst. Argh... T -- VI = Visual Irritation
Re: Don't expect class destructors to be called at all by the GC
On Wednesday, 31 January 2018 at 10:34:53 UTC, Mike Parker wrote: delete is deprecated: https://dlang.org/deprecate.html#delete Ah, thanks! Actually double-thanks, because my progress through your book is what prompted me to search for threads about class destructors. The existence of .destroy answers my question (namely, "should I just use 'delete', or my own .dispose method, for deterministic resource freeing?")
Re: Don't expect class destructors to be called at all by the GC
On Wednesday, 31 January 2018 at 10:14:53 UTC, DanielG wrote: Pardon my probable ignorance (D newbie and all), but why wouldn't a 'delete' work for this? https://dlang.org/spec/expression.html#delete_expressions delete is deprecated: https://dlang.org/deprecate.html#delete
Re: Don't expect class destructors to be called at all by the GC
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote: I ended up calling .destroy on the class instance explicitly just so the destructor would run at the right time, right before nulling the reference so that the GC would collect the memory. Pardon my probable ignorance (D newbie and all), but why wouldn't a 'delete' work for this? https://dlang.org/spec/expression.html#delete_expressions
Re: How to proceed with learning to code Windows desktop applications?
On Tuesday, 30 January 2018 at 18:52:18 UTC, I Lindström wrote: I've been looking into C# and VS2017 today along with VisualD. Reading through all this it looks like the simplest path is to learn C# and VS and go from there. I've found a pile of courses on LinkedIn that seem to build up to what I need. What makes me sad is that I have to drop D for at least the time being. The good news is after you learn the basics of WinForms in C#, you can take DFL and have basically all the same code in D. DFL (D Forms Library) is a pure D thin wrapper around WinAPI that looks like an identical twin of WinForms. There was even some visual forms builder for it. And then, once you're familiar with this kind of GUI lib, it's not hard to learn DlangUI or GtkD or some other libraries mentioned above. D does have GUI libs, just not books and courses about them.
Re: rdmd main.d leads to Segmentation fault
On Tuesday, 30 January 2018 at 16:56:28 UTC, Timoses wrote: Output: https://pastebin.com/raw/SSx0P1Av Helps? Looks like TLS is not initialized.
