Re: DIP 1017--Add Bottom Type--Community Review Round 1

[docandrew via Digitalmars-d]

On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote:
A better name for this type is `never`, which is the name of 
the TypeScript type with similar semantics. 
https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing.


+1 for "never" - it's descriptive and readable.

-Jon

Re: Copy Constructor DIP

[docandrew via Digitalmars-d]

On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu 
wrote:

On 7/14/18 5:03 AM, Luís Marques wrote:
If there is "no other meaning of @implicit" (other than the 
intersection of those two properties) why don't you just call 
it something like @copyctor?


I'm totally cool with giving the attribute a more obscure name 
such as @copyctor or anything people want really.


(What follows is a personal opinion.

I think it's better to choose a more general attribute name 
with reduced initial applicability. Then application of said 
attribute can be extended to other functions with ease. In 
contrast, an obscure attribute name is sure to be followed by 
more obscure attribute names. And don't get me started about 
inventing new syntax.


Regarding the hand-wringing over generality: we have an 
exceedingly poor record of paralysis of analysis, whereby we'd 
worry that every design decision potentially locks us out from 
all other as-of-yet-unchosen design decisions. If history is 
any indication, this sudden worry about vaguely-promising green 
pastures of the future is a sign of malady. We want copy 
construction. Conflating this with a very general schemata for 
implicit conversion would not be a wise decision in my opinion. 
I now deeply regret ever telling Razvan to mention future 
possible directions. This DIP must do implicit copy 
constructors and do it well, nothing less and nothing more.)



Andrei


I think in this case, a more obscure name like @copyctor is more 
descriptive. I fear that at some point, a more general attribute 
like "@implicit" will turn into the next "static". To me, 
@implicit smells like one of those keywords that will grow to 
carry many different meanings in different contexts and just end 
up overly-broad.


-Jon

Re: NES emulator written in D

[docandrew via Digitalmars-d-announce]

Really cool work!

Re: First Impressions!

[docandrew via Digitalmars-d]

On Tuesday, 28 November 2017 at 03:01:33 UTC, A Guy With an 
Opinion wrote:


- ...however, where are all of the collections? No Queue? No 
Stack? No HashTable? I've read that it's not a big focus 
because some of the built in stuff *can* behave like those 
things. The C# project I'm porting utilizes queues and a 
specifically C#'s Dictionary<> quite a bit, so I'm not looking 
forward to having to hand roll my own or use something that 
aren't fundamentally them. This is definitely the biggest 
negative I've come across. I want a queue, not something that 
*can* behave as a queue. I definitely expected more from a 
language that is this old.




Good feedback overall, thanks for checking it out. You're not 
wrong, but some of the design decisions that feel strange to 
newcomers at first have been heavily-debated, generally 
well-reasoned, and just take some time to get used to. That 
sounds like a cop-out, but stick with it and I think you'll find 
that a lot of the decisions make sense - see the extensive 
discussion on NaN-default for floats, for example.


Just one note about the above comment though: the 
std.container.dlist doubly-linked list has methods that you can 
use to put together stacks and queues easily:


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

Also, D's associative arrays implement a hash map 
https://dlang.org/spec/hash-map.html, which I think should take 
care of most of C#'s Dictionary functionality.


Anyhow, D is a big language (for better and sometimes worse), so 
it's easy to miss some of the good nuggets buried within the 
spec/library.


-Doc

Re: Alexa Skill written in D

[docandrew via Digitalmars-d-announce]

On Saturday, 7 January 2017 at 13:17:35 UTC, extrawurst wrote:

Hi guys,
the last 2 weeks I jumped on a new toy project: An Alexa Skill 
written in D.


It is a skill that allows me to voice control my TV receiver 
with commands like:



Alexa, ask Telly to go to standby
Alexa, ask Telly what is currently running


The project and all the source code sits on github:
https://github.com/Extrawurst/alexa-openwebif

I created two new dub libraries that this app uses:
https://github.com/Extrawurst/openwebif-client-d
https://github.com/Extrawurst/alexa-skill-kit-d

*openwebif-client-d* is the REST api that my receiver speaks.
*alexa-skill-kit-d* is the base class and the types that amazon 
throws at when the user activated your skill.


you can find the blog post here:
http://blog.extrawurst.org/programming/dlang/alexa/2017/01/06/alexa-in-d.html

Feel free to share, to spread the word about using D for this 
fancy new tech.


~Stephan


Good work! I've been using my Echo for a little while now and 
it's great to know I can start using D with it! Great write-up on 
the project, thanks for sharing this.


-Doc

Re: Using .lib and .dll in D applications

[docandrew via Digitalmars-d-learn]

On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:

On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:

On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:







Unfortunatelly I still don't get it. I would like to have an 
independant project "dbar". The created lib is then used in 
another project "dfoo". Assuming that "dfoo" has no access to 
"dbar" other than the .lib file.


You can't do it with only the lib file. You *need* the source 
file too for the import statement. As I explained, the lib 
file is used by the linker, not the compiler. The compiler 
needs the source file.




My folder structure is like this:

-dtest
--dbar
source\barlib.d
dub.json
This project creates a dbar.lib file which seams to work.


-dtest
--dfoo
lib\dbar.d  // copied from the dbar project
source\app.d
dub.json


You don't need to copy dbar to the lib directory in this case.

This project would use the dbar.lib but should otherwise not 
have access to the dbar project. Basically simulating, that 
someone else made a dbar project to which I would not have 
access other than using the dbar.lib. How do I have to 
configure the dub.json file for this to work?


One of two things would happen:

1) They would register the project with he dub registry, then 
you add a dependency to a specific version the library. Dub 
would then download the necessary files for you and ensure 
that everything you need is passed to the compiler when 
building your project.


2) They would provide some other means for you to get the 
source and the library. Then you would need to manually 
configure your dub.json to pass the import path to the 
compiler and link with the library.




I have tried a variety of configurations for the dub.json. At 
this point it feels like a bad guessing game. That is no way 
to deveop anything. I need to figure out how to properly 
setup the dub.json but I don't seam to find the answer 
online. "http://code.dlang.org/package-format?lang=json; 
isn't very helpful.


All the information you need is there on that page.



I have meanwhile adjusted my dtest/dfoo/dub.json to this:



"dependencies": {
"dbar": "~master"
}


This gives me the error: "Root package dfoo references 
unknown package dear"


As I explained above, you need a path attribute for the 
dependency in this case since it is on your local file system 
and not in the registry. The documentation link I gave you 
explains how to to this. Try this:


"dependencies": {
"dbar":  {"path": "../dbar"}
}


I see where I went wrong. I thought that it's possible to only 
use the .lib file without the source code of dbar. Having 
access to the source makes what I am trying somewhat pointless. 
Is it otherwise possible to provide some functionality without 
having to give away your source? I would like to put together a 
library that I can reuse, without having to rely on the source 
each time. Maybe a dll instead?


Note: I don't have a problem with giving away my code. I just 
want to know if it can be done. Or maybe later build a plugin 
system where the creator of the plugin does not need the source 
of the entire application. And in turn the app does not need to 
be recompiled in order to use the plugin.


Thanks for your help!


Sure, you can just have a file with "extern" functions that tells 
the compiler that the source for those functions isn't available 
at compile time, but that later on when you link the library, the 
linker will find those function definitions in the .lib file (I'm 
not a Windows expert, but from my understanding .DLLs are a 
different ball game, and have to be loaded and called with 
special functions in your app.)


In your example, in your "dfoo.d", you can declare the functions 
from the dbar.lib inside as "extern myfunction();" and the 
compiler will say, "OK, myfunction() isn't defined here, so we'll 
let the linker sort it out." If you try and compile without 
telling it about dbar.lib, you'll get errors like "undefined 
reference to myfunction()...".


When you see that somebody wrote a "binding" in D for a library 
like OpenGL, etc., this is what they are providing, a .d file 
filled with "extern" definitions and maybe some glue code to 
convert D types into C types if the .lib file is a C library.


APIs generally work the same way. Library writers will provide a 
.h header file that doesn't expose any of their closed source, 
but gives users of the library the definitions of the functions 
they need to use it's functions.


I hope this helps!

-Jon

Re: What exactly does the compiler switch -betterC do?

[docandrew via Digitalmars-d-learn]

On Sunday, 19 June 2016 at 19:53:46 UTC, Gary Willoughby wrote:
When compiling, what exactly does the -betterC flag do? The 
command help says "omit generating some runtime information and 
helper functions" but what does this really mean? Is there any 
specifics somewhere?


My understanding was that -betterC was not fully implemented yet, 
due mostly to tight compiler integration with the runtime. (old 
info?)


I'm not super smart on the DMD source, but it looks like betterC 
prevents genhelpers() and genModuleInfo() from being called, with 
"helpers" appearing to be array checking, asserts and unit tests.


A comparison of object files compiled with and without the flags 
shows just a small reduction in the size of the code, but 
grepping for bounds checking, unit tests and ModuleInfo in the 
-betterC generated object file shows they are missing.


Hope this helps,

-Jon

Re: Linker error

[docandrew via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 21:26:56 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 21:16:36 UTC, Andrej Mitrovic wrote:
On 6/5/16, Anonymous via Digitalmars-d-learn 
 wrote:
Should I report this as a dmd bug then? Not sure where / how 
to do that.


You can report it here: https://issues.dlang.org

I think I'll just let it go; I was able to work passed it 
anyway using "static Note[] empty;", and `null` works too. Is 
either one better?


null is simpler from a reader's perspective. :)

By the way, this is from an example I found in "D Web 
Development" by Kai Nacke.


Interesting that they would use such code in the book. Which 
chapter is it?


Thanks. I agree it's simpler and switched to `null`.

The example is in chapter 3.


That it works on OSX but not on Windows makes me think it should 
definitely be reported as a bug.


-Jon

Re: Embed files into binary.

[docandrew via Digitalmars-d-learn]

On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I saw somewhere someone explaining how to embed resources into 
a binary using the import keyword.


I believe the essentially converted the file into a ubyte or 
something and then wrote that out to a temp file and read in 
the temp file... this seems a bit of a kludge to me.


Is it possible to do the same, but create a sort of "in memory" 
file layout?


While I can modify my own routines to read the "file" from 
memory, I can't do that easily with outside code(I could modify 
the binaries).


Basically reading a file has to read it to memory, and if the 
file data already exists in memory, there is no point to read, 
just get it direct.


Any thoughts on this?

Because D allows such an embedding feature, maybe the file 
system should allow working with this concept? That way, it 
becomes VERY easy to embed files into the binary and work with 
them like they wernt. Also, going between the two different 
versions(embedded vs not) could be done with version (Release).


I'm not sure about import, but one option is to put the external 
files directly in your binary as part of the linker step. Check 
out:


http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967

On Windows I think there's a way to embed files in .DLLs and then 
link those into your executable, but I'm ignorant of the 
steps/tools required.


-Jon

Re: Linker error

[docandrew via Digitalmars-d-learn]

On Sunday, 5 June 2016 at 18:36:13 UTC, Anonymous wrote:

On Sunday, 5 June 2016 at 18:30:25 UTC, Anonymous wrote:

[...]


Should have included:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ns.obj(ns)  Offset 0BA0AH Record Type 009D
 Error 16: Index Range
--- errorlevel 1


Hmm, on OSX w/ dmd v2.071.0 I'm unable to duplicate. Can you try 
upgrading to v2.071 and see if that works?


-Jon

Re: The Case Against Autodecode

[docandrew via Digitalmars-d]

On Saturday, 4 June 2016 at 08:12:47 UTC, Walter Bright wrote:

On 6/3/2016 11:17 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jun 03, 2016 at 08:03:16PM -0700, Walter Bright via 
Digitalmars-d wrote:

It works for books.

Because books don't allow their readers to change the font.


Unicode is not the font.


This madness already exists *without* Unicode. If you have a 
page with a
single glyph 'm' printed on it and show it to an English 
speaker, he
will say it's lowercase M. Show it to a Russian speaker, and 
he will say

it's lowercase Т.  So which letter is it, M or Т?


It's not a problem that Unicode can solve. As you said, the 
meaning is in the context. Unicode has no context, and tries to 
solve something it cannot.


('m' doesn't always mean m in english, either. It depends on 
the context.)


Ya know, if Unicode actually solved these problems, you'd have 
a case. But it doesn't, and so you don't :-)



If you're going to represent both languages, you cannot get 
away from

needing to represent letters abstractly, rather than visually.


Books do visually just fine!


So should O and 0 share the same glyph or not? They're 
visually the same

thing,


No, they're not. Not even on old typewriters where every key 
was expensive. Even without the slash, the O tends to be fatter 
than the 0.



The very fact that we distinguish between O and 0, 
independently of what

Unicode did/does, is already proof enough that going by visual
representation is inadequate.


Except that you right now are using a font where they are 
different enough that you have no trouble at all distinguishing 
them without bothering to look it up. And so am I.



In other words toUpper and toLower does not belong in the 
standard

library. Great.


Unicode and the standard library are two different things.


Even if a character in different languages share a glyph or look 
identical though, it makes sense to duplicate them with different 
code points/units/whatever.


Simple functions like isCyrillicLetter() can then do a simple 
less-than / greater-than comparison instead of having a lookup 
table to check different numeric representations scattered 
throughout the Unicode table. Functions like toUpper and toLower 
become easier to write as well (for SOME languages anyhow), it's 
simply myletter +/- numlettersinalphabet. Redundancy here is very 
helpful.


Maybe instead of Unicode they should have called it Babel... :)

"The Lord said, “If as one people speaking the same language they 
have begun to do this, then nothing they plan to do will be 
impossible for them. Come, let us go down and confuse their 
language so they will not understand each other.”"


-Jon

Re: [OT] Things I like about Andrei

[docandrew via Digitalmars-d]

On Friday, 3 June 2016 at 02:17:51 UTC, Adam D. Ruppe wrote:
A lot of us, myself included, have been very critical of Andrei 
lately but I want to list of the excellent work he has done 
over the years:


First, early D was very different to D of today. Andrei changed 
that, for the better. He's a genius of innovation with 
templates and good at getting to the bottom of generic code.


The Range concept is excellent, the logical extension of 
iterators like slices are to pointers, and std.algorithm is 
generally brilliant.


Many of the patterns we take for granted in D, from templates 
in general to conversion and literals on top of them, to ranges 
and algorithms, were principally designed and implemented by 
Andrei.


std.experimental.allocator is very well done and the Design by 
Introspection is not just smart insight to the generic 
programming problem, but actually explored and explained in 
such a way that we can hook onto it.


His talks and writing are amusing and informative, and his 
dedication unquestionable.


Andrei Alexandrescu is a very good, innovative programmer and 
writer who invents and explains things that others can't even 
consider.


We're lucky to have him with us!


+1.

I've been following D since the (dead tree) Dr. Dobbs article I 
found in a supermarket a decade ago, and it's been amazing to 
watch it grow since his participation. Even concepts that Walter 
used to swear off, like templates, have become not just bearable 
but a legitimately kick-ass feature thanks to Andrei's help. D 
owes him a lot!


-Jon

Re: Lifetime tracking

[docandrew via Digitalmars-d]

On Friday, 3 June 2016 at 00:40:09 UTC, Stefan Koch wrote:

On Friday, 3 June 2016 at 00:31:31 UTC, Walter Bright wrote:

If they cover the cases that matter, it's good. Rust has the 
type system annotations you want, but Rust has a reputation 
for being difficult to write code for.


I think we can incorporate typesafe borrowing without making it 
difficult to write.


+1, a big problem with Rust is just that the syntax is really 
ugly to those coming from D/C/C++/Java. An idea I had was using 
plain English attributes in function signatures to denote 
ownership.


e.g.

void myfunc(sees Myobj arg1, copies Myobj arg2, borrows Myobj 
arg3, owns Myobj arg4)

{
	//"sees arg1" - read-only reference (basically const now, but 
cannot be

//cast away)

	//"copies arg2" - read/write copy of argument. It works the same 
way
//value types work now, and will be freed after function 
exit (unless it is

//returned).

	//"borrows arg3" is a by-reference pass, may have the benefit of 
enabling
//optimization for small functions since it eliminates a 
copy
	// (maybe save a stack push and allow register re-use?). Will 
not be freed

//after function exits (ownership returns to calling
// function). Reference can be locked for multi-threaded apps.

	//"owns arg4" - frees after function exit (unless it is 
returned).

}

At a glance it's obvious who owns what, what's read-only, etc.

Also, a nice bonus is that "const" can become a more rigid 
guarantee - as in Rust,  there can exist multiple const 
references to an object, but only one mutable reference. 
Immutable or const by default is probably a bridge too far from 
what we're used to.


There are still a lot of corner-cases that I'd have to think 
through, i.e. calling class methods through a const/"sees" 
reference (would have to be "pure" calls only), good syntax for 
ownership changes mid-function (maybe use "sees" "copies" 
"borrows" and "owns" as operators?), passing to C functions, 
mangling, etc.


Anyhow, just some brainstorming to stir discussion. It looks 
pleasant to me, but I'm not sure if you can call it "D" anymore.


-Jon

Re: Quite sure a simple basic problem...

[docandrew via Digitalmars-d-learn]

On Thursday, 2 June 2016 at 00:37:58 UTC, WhatMeWorry wrote:
I've got a fairly complex D project (25+ modules) that has 
grown haphazardly over time. So it is not well designed. But I 
want to get the thing fully ported before refining the code. 
(that's called refactoring, I believe?)


Anyway, there is a new module called audio.d which which has 
all the sound functionality.


And in the (main.d) module is a code snippet like so

void main(string[] argv)
{
// . . .
auto blop = new AlurePlaySound("../bleep.wav");
blop.play();
// . . .
}

So all is well and good except I need to place the sound in 
another module (game.d) where

collisions are detected.

I tried:

module game;
import main;   // is this as ugly as I think it is?

if (collision[0])  // If collision make sound
blop.play();


but this returns:  game.d(501): Error: undefined identifier 
'blop'



So can someone tell me what various solutions to this problem 
or type of problems?  I presume there are quick and dirty 
solutions (like here) and more elegant solutions?


Would this type of problem fall under the domain of "scope".  
Like in global scope. But I don't think D has such a concept.


Thanks.


Since blop is being declared inside your main() function, it 
isn't visible to other modules or functions. You're right that 
the issue is a problem of "scope".


Importing your main module will work, but you must declare your 
as a global variable outside the main() function.


i.e.

--

module main;

AlurePlaySound blop;

void main()
{
   //etc...

   blop = new AlurePlaySound("../beep.wav");

   //etc...
}

--

module game;

import main;

void collision()
{
blop.play(); //or whatever
}

If your game loop is running in a separate thread, then I think 
you'll want to use:


__gshared AlurePlaySound blop;

for the declaration, since variables are thread-local by default.

Using global variables is generally frowned upon for production 
code because you can never be sure which functions are modifying 
it. But for a quick hack, it works! A better option might be to 
make a third module with a class containing all your audio 
objects, initialize it in main(), and then pass it to your main 
game loop.


-Jon