Re: Temporary @trusted scope
On 19/12/2018 1:34 AM, Per Nordlöw wrote:
On Tuesday, 18 December 2018 at 10:42:51 UTC, Jonathan M Davis wrote:
Unfortunately, D does not currently have a way to do that. Only
functions can be marked with @trusted. However, the typical approach
to this problem is to use a lambda, which is more or less
syntactically the same except that it has some extra parens. e.g.
() @trusted { doUnsafe(); }();
Is there a performance hit when using this?
Yes except for ldc with -O3.
But it is a function not a delegate so it should be all nicely
prefetched and ready to go. So I wouldn't worry about it too much.
Re: is(ElementType!(char[2]) == dchar - why?
On 12/12/2018 6:51 AM, Denis Feklushkin wrote:
import std.stdio;
import std.range.primitives;
void main()
{
writeln(
typeid(ElementType!(char[2]))
);
static assert(is(ElementType!(char[2]) == dchar)); // why?
}
?
https://run.dlang.io/is/Q74yHm
Because docs: https://dlang.org/phobos/std_range_primitives.html#ElementType
What you probably want is:
https://dlang.org/phobos/std_traits.html#ForeachType
Re: Writing Program Without main Function
There is always a main function. It doesn't matter in which module its in or language. It just has to exist.
Re: Imports and Subfolders and Links (Oh, My!)
On 08/12/2018 6:41 AM, Ron Tarrant wrote: Does D have the concept of makefiles? I haven't run across any reference to such things so far. Make isn't a D specification application (it doesn't really specialize in any language) dmd, druntime and Phobos are all built using it. Though for user code, dub is the package+build manager that is more commonly used.
Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System
On 06/12/2018 12:35 PM, aliak wrote: On Wednesday, 5 December 2018 at 23:18:12 UTC, rikki cattermole wrote: On 06/12/2018 10:18 AM, aliak wrote: "Weka is a name of a Machine learning product from New Zealand. Weka is the company that produced Lord of the Rings here in NZ. *Weta. Bless them :D Weka is a set of ML tools from waikato uni => https://www.cs.waikato.ac.nz/ml/weka/ Woops I should know better even after an all nighter. After all, I've known people that worked there! Kinda like with that Jade/Diet fiasco a while back.
Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System
On 06/12/2018 10:18 AM, aliak wrote: "Weka is a name of a Machine learning product from New Zealand. Weka is the company that produced Lord of the Rings here in NZ. It is also a bird! (which makes WekaIO's name a bit weird). http://nzbirdsonline.org.nz/species/weka
Re: How to pass -J switch to compiler via DUB?
On 01/12/2018 12:05 AM, Andrey wrote:
Hi,
How to pass -J switch to compiler via DUB?
I want to import some text file at compile time:
string data = import("vertex.glsl");
In dub.json:
"dflags": [
"-J=vertex.glsl"
]
The file itself is located on the same level as "dub.json".
stringImportPaths
Re: Profiling DMD's Compilation Time with dmdprof
On 18/11/2018 1:29 AM, welkam wrote:
I just updated DMD on my windows and tried to compile hello world. It
took 7.4 sec. Something is not right. Can anyone reproduce? On the same
mashine running linux it compiles and runs in 0.1 sec
PS C:\Users\Welkam\Desktop\Projects> Measure-Command {dmd -run main.d}
Days : 0
Hours : 0
Minutes : 0
Seconds : 7
Milliseconds : 418
Ticks : 74184371
TotalDays : 8.58615405092593E-05
TotalHours : 0.0020606769722
TotalMinutes : 0.12364061833
TotalSeconds : 7.4184371
TotalMilliseconds : 7418.4371
Just in case, did you disable your anti-virus first?
Re: Writing Postgresql extension in D
On 16/11/2018 3:18 PM, Ranjan wrote: On Thursday, 15 November 2018 at 17:03:55 UTC, Andrea Fontana wrote: On Thursday, 15 November 2018 at 13:05:59 UTC, Ranjan wrote: This is my first time on the Dlang forum. I like the language but my usecase is a bit different. I want to write Postgresql extension in D. Currently extension can be written in C or C linked languages. Has anyone done this or can point me to some code. Thanks Did you read this: https://dlang.org/spec/interfaceToC.html ? Andrea Yes, but it's not useful, in Postgesql extension C code needs to call D, without GarbageCollection. I am able to do this in RustLang but I am not sure how to in D, as it has a GC. Looking for examples from the community. Thanks There isn't anything special you need to learn. As long as you don't mutate anything you receive via the GC or send any GC owned memory outside of D, you'll have an easy time of it.
Re: DMD backend now in D
On 13/11/2018 12:12 AM, Jacob Carlborg wrote: On 2018-11-12 03:37, Walter Bright wrote: On 11/11/2018 3:58 PM, Mike Franklin wrote: This is a significant milestone. Congratulations, Walter! Many people helped out with this, too. There are still a few .c files in https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's the significance of those? tk.c fp.c os.c strtold.c tk/mem.c These could be converted too, but are independent from everything else and hardly seem worth the bother. Sebastian has a PR for os.cd. dmd/root/ctfloat.d depends on the "strtold_dm" function defined in strtold.c [2] when compiling using Visual Studio. That means that the Dub package cannot be compile using Visual Studio without this file. [1] https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/root/ctfloat.d#L167-L170 [2] https://github.com/dlang/dmd/blob/4df5d6a6e8775754148939beb6de827fe4b0b9ab/src/dmd/backend/strtold.c#L138 That module needs a right rethink for dmd-fe as a library purposes. https://issues.dlang.org/show_bug.cgi?id=18810
Re: Creating InputRanges from strings, files etc.
On 09/11/2018 2:58 AM, Vinay Sajip wrote:
Excuse my ignorance, but from looking at the documentation on std.range
and a quick skim of the guides mentioned there near the top, I can't see
what the simple way is of creating an InputRange!(ubyte) from strings,
files etc. I would have expected to find something in the DLang Tour
about this, but couldn't find anything. Please can someone tell me how
to do it? Just to be clear, I want to create an object which is an
InputRange!(ubyte) and pass that around, rather than e.g. iterate over a
string or a file.
TLDR of how to write an input range:
struct MyInputRange {
ubyte[] input;
@property {
ubyte front() {
return this.input[0];
}
bool empty() {
return this.input.length == 0;
}
}
void popFront() {
this.input = this.input[1 .. $];
}
}
import std.stdio;
void main() {
foreach(b; MyInputRange([1, 2, 3])) {
writeln(b);
}
}
Re: Profiling DMD's Compilation Time with dmdprof
On 08/11/2018 4:17 AM, Neia Neutuladh wrote: On Thu, 08 Nov 2018 01:49:49 +1300, rikki cattermole wrote: On 08/11/2018 1:46 AM, Patrick Schluter wrote: Now that the compiler is completely in D, wouldn't it be a good idea to activate the GC in the compiler. I know that it requires some care for bootstrapping the compiler when there are dependencies to the D runtime, but the compiler would be an excellent example of the advantage of the GC (i.e. dumb fast allocations as long as there's memory, collection when no memory left which is miles away better than to get OOM-killed). No, that would be a bad idea currently. https://issues.dlang.org/show_bug.cgi?id=18811 That issue describes a memory leak. A memory leak of half a megabyte per full compiler invocation on a small file should still result in a lot of code being compilable on low-end machines that currently isn't. Its a symptom of a larger set of problems. The frontend is not quite ready to have the GC turned on full time. Based upon my testing, that little memory leak prevents pretty much *all* memory allocated by the GC to not be collected. I don't know why, but for some reason it pins it. Mind you, my testing could have been flawed, and needs more eyes on it *shrug*.
Re: Profiling DMD's Compilation Time with dmdprof
On 08/11/2018 1:46 AM, Patrick Schluter wrote: Now that the compiler is completely in D, wouldn't it be a good idea to activate the GC in the compiler. I know that it requires some care for bootstrapping the compiler when there are dependencies to the D runtime, but the compiler would be an excellent example of the advantage of the GC (i.e. dumb fast allocations as long as there's memory, collection when no memory left which is miles away better than to get OOM-killed). No, that would be a bad idea currently. https://issues.dlang.org/show_bug.cgi?id=18811
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:42 AM, Stanislav Blinov wrote: Well, yes, it can be a litmus test, I guess. I meant to say that it isn't per se a deciding factor. It is a deciding factor for me. Because it seems to be almost always correct. As I said, my rules are stricter than what most people have. My preferences may or may not be applicable for others tho.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:35 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: On 01/11/2018 2:25 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: [...] We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science. Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Ok, you agree that it is subjective. Why is having more then one class per file "too large"? It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:33 AM, Stanislav Blinov wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails... Actually it is quite informative. As a code smell it does tell you pretty decently in my experience if your scope is too large or if you are in need of refactoring.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:25 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"? We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science. Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:16 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"? We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
Re: expanding variadic into format
On 01/11/2018 1:08 AM, Codifies wrote:
On Wednesday, 31 October 2018 at 11:56:31 UTC, rikki cattermole wrote:
On 01/11/2018 12:53 AM, Codifies wrote:
[...]
Just to confirm, format there is std.format:format right?
Because that isn't using C variadics, its using template variadics.
thought I was using core.vararg and std.format both using templates ??
No. They use different variadics.
Template variadics happen on the template parameter side:
void func(T...)(T args) {
pragma(msg, T.length);
pragma(msg, T.stringof);
}
C variadics happen on the function parameters side and are highly unsafe:
void func(...) {
}
If you use core.vararg you're talking with C.
If you use std.format you're talking D's template variadics.
Re: expanding variadic into format
On 01/11/2018 12:53 AM, Codifies wrote:
I have a routine that was happily printing ASCII strings and values
using opengl, however I want to improve it so it can be used in the same
manner as some other languages printf function...
void printValue(Font fnt,float x, float y, string frmt, ...)
{
/* matrix math and other stuff removed for readability */
string message = format(frmt, _arguments);
no surprise this naive attempt causes a runtime error as its trying to
format a range using the first format specifier in frmt
am I going to have to chop frmt into descrete chunks that have just one
% symbol in them and then build up the formatted message string like that?
is there some way to somehow transfer my input variadic into formats
variadic ?
Just to confirm, format there is std.format:format right?
Because that isn't using C variadics, its using template variadics.
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On 30/10/2018 10:47 AM, Walter Bright wrote: On 10/28/2018 8:43 PM, Mike Parker wrote: Congratulations are in order for Iain Buclaw. His efforts have been rewarded in a big way. I think that's an understatement. It's a massive achievement by Iain, and he did it pretty much all on his own. Very few developers have both the technical chops and dogged persistence to pull something like this off. It's a career-making accomplishment, and all Iain ever needs to put on his resume! We're all enormously lucky to have Iain on our team! Please join me in hefting a pint to Iain! It was bourbon for me last night, but yes indeed! P.S. I do hope Iain sees our HL's congratulating him on IRC.
Re: link errors when using extern (C) structs
On 28/10/2018 11:11 PM, DanielG wrote: Wait, wut? Do modules that get pulled in from dub's "importPaths" not get compiled in the same way? No. They just get -I'd.
Re: getting Win32 Messagebox to work
On 27/10/2018 1:46 AM, Mark Moorhen wrote: On Friday, 26 October 2018 at 12:39:13 UTC, rikki cattermole wrote: On 27/10/2018 1:36 AM, Mark Moorhen wrote: [...] alias string = immutable(char)[]; A slice (string in this case) is a length + pointer pair. You need to add .ptr on content with a cast to get to const(char)*. Thanks for your quick reply. However when I do: cast(const(char)*) content.ptr; I get a error: HelloMsg.d(9): Error: `cast(const(char)*)cast(immutable(char)*)content` has no effect This should work: string content = "Some random content."; MessageBoxA(null, cast(const(char)*)content.ptr, cast(const(char)*)"Window title".ptr, 0);
Re: getting Win32 Messagebox to work
On 27/10/2018 1:36 AM, Mark Moorhen wrote:
Hi,
I've recently started looking into D, and I'm afraid i'm gonna need some
support to get me going.
I work mostly on Windows, so i've downloaded the examples from
"https://github.com/AndrejMitrovic/DWinProgramming;. Only these examples
do not work out-of-the-box on my machine (Win10, 64-bit / DMD32 D
Compiler v2.082.0)
Now I'm trying to pass the content for a Messagebox as a variable like
this:
import core.runtime;
import win32.windef;
import win32.winuser;
extern (Windows)
void WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
string content = "Some random content.";
MessageBox(NULL, content , "Window title", 0);
}
When compiling I get the error:
HelloMsg.d(9): Error: function `win32.winuser.MessageBoxA(void*,
const(char)*, const(char)*, uint)` is not callable using argument types
`(typeof(null), string, string, int)`
HelloMsg.d(9): cannot pass argument `content` of type `string` to
parameter `const(char)*`
Can anyone help me out with this?
alias string = immutable(char)[];
A slice (string in this case) is a length + pointer pair. You need to
add .ptr on content with a cast to get to const(char)*.
Re: shared - i need it to be useful
On 22/10/2018 10:28 PM, Walter Bright wrote: On 10/22/2018 1:34 AM, Manu wrote: I posted it, twice... 2 messages, back to back, and you're responding to this one, and not that one. I'll post it again... Posting it over and over is illustrative of the failure of posting proposal documents to the n.g. instead of posting it as a DIP which can be referred to: 1. nobody knows which of your 70 messages are the ones with the proposal in it 2. with multiple posts of the proposal, nobody knows which one is the most up-to-date one Doing it this way does not work. Continuing to repost it is a waste of your time. Post it as a DIP and link to it. As I've said previously, it doesn't need to be a good DIP or anywhere near complete. It just needs code examples comparing current and proposed behavior with some text about semantics changes.
Re: shared - i need it to be useful
On 21/10/2018 10:41 PM, Manu wrote: On Sun., 21 Oct. 2018, 2:05 am Walter Bright via Digitalmars-d, mailto:digitalmars-d@puremagic.com>> wrote: On 10/20/2018 11:30 AM, Manu wrote: > You can write an invalid program in any imaginable number of ways; > that's just not an interesting discussion. What we're discussing is not an invalid program, but what guarantees the type system can provide. D's current type system guarantees that a T* and a shared(T)* do not point to the same memory location in @safe code. My proposal guarantees that too, but in a more interesting way, because it opens the door to a whole working model. And it's totally @safe. To get them to point to the same memory location, you've got to dip into @system code, where *you* become responsible for maintaining the guarantees. My model preserves that property. Why do you think I'm running that static guarantee? It's all irrelevant if you don't express any mechanism to *do* anything. Shared today does not have any use. It simply expresses that data *is* shared, and says nothing about what you can do with it. If you don't express a safe mechanism for interacting with shared data, then simply expressing the distinction of shared data really is completely uninteresting. It's just a marker that's mixed up in a bunch of unsafe code. I'm no more satisfied than I am with C++. Shared needs to do something; I propose that it strictly models operations that are threadsafe and semantic restrictions required to support that, and then you have a *usage* scheme, which is safe, and API conveys proper interaction.. not just an uninteresting marker. I'm genuinely amazed that you're not intrigued by a @safe shared proposition. Nobly likes @safe more than you. I could run our entire SMP stack 100% @safe. I am going to fork D with this feature one way or another. It's the most meaningful and compelling opportunity I've seen in ever. If there's ever been a single thing that could truly move a bunch of C++ programmers, this is it. C++ can do a crappy job of modelling most stuff in D, but it simply can't go anywhere near this, and I've been working on competing C++ models for months. SMP is the future, we're going all-in this generation. Almost every function in our codebase runs in an SMP environment... And I was staggered that I was able to work this definition through to such a simple and elegant set of rules. I can't get my head around why people aren't more excited about this... fully @safe SMP is huge! I'm excited, but you need to write a DIP even if preliminary which shows both new semantics but also shows both working and current code to compare them.
Re: Just found this debugger...
On 21/10/2018 5:59 PM, solidstate1991 wrote: On Wednesday, 3 October 2018 at 13:08:50 UTC, Vladimir Panteleev wrote: On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: and I don't want to go back to VisualD after VSCode for either a usable mago or VS native debug. Visual Studio makes a decent stand-alone source-level debugger. Just select the .exe file, and right-click it in the project/solution pane to start a debugging session. (Of course, you need to build with -m32mscoff or -m64 as well as -g). VisualD isn't even needed, though VS by itself won't understand D types like arrays/strings. I cannot find that option... Open it as a solution/project if I remember right.
Re: Can opApply be made @nogc?
On 20/10/2018 12:32 PM, solidstate1991 wrote:
Since it's a bit difficult to make tree traversal through range
(especially if someone wants to make it @nogc), I thought I'll make it
through opApply override, however the delegate passed by it doesn't have
the @nogc attribute, which would automatically make it incapable to be
used in a @nogc context.
I also don't know if it would work with structs instead of classes,
since they're easier to handle in a @nogc situation.
class Foo
{
uint[2] array;
int opApply(scope int delegate(ref uint) @nogc dg) @nogc
{
int result = 0;
for (int i = 0; i < array.length; i++)
{
result = dg(array[i]);
if (result)
break;
}
return result;
}
}
void test()
{
Foo a = new Foo();
a.array[0] = 73;
a.array[1] = 82;
foreach (uint u; a)
{
printf("%d\n", u);
}
}
Re: shared - i need it to be useful
On 20/10/2018 2:07 AM, Dominikus Dittes Scherkl wrote: This document provide no reasoning about what usecases it supports: It was a basic idea of mine... It was never meant to be PR'd.
Re: shared - i need it to be useful
On 19/10/2018 9:02 PM, Walter Bright wrote: On 10/17/2018 4:29 AM, jmh530 wrote: Isn't that also true for isolated data (data that only allows one alias)? That's colloquially called "unique" data. And yes, it is also true for that. That's why casting the return value of malloc() to 'shared' is safe. It's just that the language has no way to semantically identify unique data with its current type system. Actually we kind of have a way to do this (I think). Scope. It can't cross the thread boundary and it has a pretty clear owner as far as the stack is concerned. Given a bit of time and empowering of scope, we could do a @scopeonly type attribute for functions.
Re: shared - i need it to be useful
On 19/10/2018 7:09 PM, Norm wrote: There's another way; Stanislav isn't one you need to convince so if that particular discussion is unproductive and disruptive just ignore it. I.e technical discussions should be robust but once they become personal just ignore that input and move on. Isn't always possible I know but in this case I reckon you can. Trust me, I think a few of us at least have already figured that out. Convincing Walter, Andrei and the rest of the core dev team of course will require a DIP. Keep going on this, it is the first hint of movement with shared since like foreva! As long as it doesn't look like my idea[0] (Andrei doesn't like it, I may have asked) it should have some sort of legs. [0] https://github.com/rikkimax/DIPs/blob/shared/DIPs/DIP1xxx-RC2.md
Re: Documents about ddoc? and markdown in ddoc?
On 18/10/2018 6:38 PM, dangbinghoo wrote: hi, Is there any other documents related about ddoc usage? the only thing I can find is: https://dlang.org/spec/ddoc.html#using_ddoc_to_generate_examples But I found it never mentioned something like $(LI a list item), is there a full ddoc document available? Default for html output: https://github.com/dlang/dmd/blob/master/res/default_ddoc_theme.ddoc And, is there any info about using markdown in ddoc? Not possible.
Re: std.digest
On 17/10/2018 10:36 PM, Márcio Martins wrote: Hi! To my surprise, std.digest.MurmurHash3 doesn't work in CTFE. Would it be hard to have it explicit in the documentation if a particular Phobos symbol works in CTFE? Maybe it could be manual, and vote-based, to avoid building infrastructure around it. It uses a union, that is why it doesn't work at CTFE. Hopefully newCTFE can solve that one. Also, MurmurHash3 only outputs 32-bit or 128-bit hashes, which leaves us without any modern fast 64-bit digest. Would anyone oppose pulling an XXHash implementation into Phobos? A better question is why doesn't it support 64bit?
Re: ref tidy way to defreference or is something else going on ?
On 16/10/2018 11:36 PM, Codifies wrote: I've a bunch of 4x4 matrix routines in C, in order to avoid copying around multiple 4x4 matrices I pass pointers... I'm assuming that in D it would make sense to use ref ? what's going on behind the scenes with ref is it just a nice way of passing pointers with automagical dereferencing or is something more going on? Yup, exactly!
Re: When does GC run?
On 16/10/2018 10:38 PM, John Burton wrote: Is there any documentation or information about the specifics of the garbage collector? The information I have found indicates that it runs to free memory when the system runs out of memory to allocate. But will this try to use all the system memory or some other amount before trying to garbage collect? If I have a _lot_ of garbage, will it try to collect that before allocating any more system memory? Is this configurable in any way? Any information or just pointer to information that I've somehow failed to find would be appreciated. It is based upon how much is currently free and is not configurable. The GC of course doesn't just use all the system resources that would be stupid. It will collect long before that either when you tell it to (core.memory GC.collect) or when you do an allocation and it is enabled. GC series on the D blog: https://dlang.org/blog/the-gc-series/
Re: You don't like GC? Do you?
On 14/10/2018 2:08 AM, Atila Neves wrote:
"Fun" fact: it's not @safe to "new" anything in D if your program uses
any classes. Thing is, it does unconditionally thanks to DRuntime.
I hardly ever use classes in D, but I'd like to know more about why it's
not @safe.
void main() @safe {
Foo foo = new Foo(8);
foo.print();
}
class Foo {
int x;
this(int x) @safe {
this.x = x;
}
void print() @safe {
import std.stdio;
try {
writeln(x);
} catch(Exception) {
}
}
}
Re: D Logic bug
On 12/10/2018 3:35 AM, James Japherson wrote: Took me about an hour to track this one down! A + (B == 0) ? 0 : C; D is evaluating it as (A + (B == 0)) ? 0 : C; The whole point of the parenthesis was to associate. I usually explicitly associate precisely because of this! A + ((B == 0) ? 0 : C); In the ternary operator it should treat parenthesis directly to the left as the argument. Of course, I doubt this will get fixed but it should be noted so other don't step in the same poo. The specification makes this clear (even if another example is needed). The conditional expression takes an OrOrExpression not an expression as the condition. In other words, it requires a boolean operation on the left, with Expression's for the branches (deprecated behavior related to assignment for else branch but won't go into that). So not a bug and is working in a reasonable way. https://dlang.org/spec/expression.html#conditional_expressions
Re: Can't Compile Global Semaphores?
On 09/10/2018 4:43 AM, Matt Richardson wrote:
On Monday, 27 July 2015 at 20:57:00 UTC, Jack Stouffer wrote:
On Monday, 27 July 2015 at 20:12:10 UTC, John Colvin wrote:
Yes, but then core.sync.semaphore doesn't support being shared, so...
Ok, so I made the code run by using __gshared instead of shared. It
seems really odd that a semaphore object doesn't support being shared,
this that a bug?
Here is the modified code:
import core.sync.semaphore;
import core.thread;
import std.string;
import std.stdio;
__gshared string data;
__gshared Semaphore sem;
void read() {
data = "From Thread";
sem.notify();
}
void write() {
sem.wait();
data.writeln;
}
void main() {
sem = new Semaphore();
Thread reader = new Thread();
Thread writer = new Thread();
reader.start();
writer.start();
}
I JUST found this after several hours of searching. Thank you, Jack.
Now if sharing a semaphore could be thing, I'd be happy. It's honestly
one of (it's actually a long list) the major blocks to us using D
primarily.
shared doesn't do much, so if __gshared works, use it (that is what it
is there for). So it isn't a blocker.
Re: DUB??
On 07/10/2018 6:36 AM, steven kladitis wrote: what has happened to dub? 1.11 is current or so it says, but I see 1.9.x and when I click on dub in dub I get vibe errors. What has happened? 1.11.0 is current https://github.com/dlang/dub/tree/v1.11.0 for DUB I always see 500 - Internal Server Error Do you mean code.dlang.org not dub? Because the common cause there is to do with searching and http://code.dlang.org/search?q=printed is working.
Re: Deep nesting vs early returns
On 05/10/2018 8:23 AM, Nick Sabalausky (Abscissa) wrote: I was in college during the height of the Java craze, so my instructors highly recommended the deep nesting approach. This was because return statements are control-flow, and control-flow isn't very object-orientedy, and is old-fasioned and in the same category as the dreaded goto and was therefore bad. So I switched to the nesting-instead-of-returning style because it was "The Right Way". "Terminology invoking "objects" and "oriented" in the modern sense of object-oriented programming made its first appearance at MIT in the late 1950s and early 1960s."[0]. And this is why you have to be very careful with any sort of trend in programming. Because it was already done before you were born (assuming you began learning after 1990) ;) [0] https://en.wikipedia.org/wiki/Object-oriented_programming#History
Re: Please don't do a DConf 2018, consider alternatives
On 04/10/2018 8:53 PM, Iain Buclaw wrote: I went to a conference once where they had mixed live talks and prerecorded talks - questions where taken at the end to the speaker of the prerecorded talk via a sip call. The organisers at the end admitted that the prerecorded talks experiment failed. No one really paid attention to any of the content in it. There are a lot of social cues that a speaker can take note of and use to determine the pace of the talk or what to put emphasis on. So that result doesn't really surprise me.
Re: Aurora DirectX Bindings 12.1
On 04/10/2018 5:33 PM, Nicholas Wilson wrote: On Thursday, 4 October 2018 at 04:03:27 UTC, rikki cattermole wrote: On 04/10/2018 2:06 PM, Adam Wilson wrote: The Aurora DirectX bindings have been updated to support Windows 10 1809. Also the D2D Effect Authoring SDK has been added. GitHub: https://github.com/auroragraphics/directx DUB: http://code.dlang.org/packages/aurora-directx Please send PR's if you find any bugs! It would be nice to get DirectX bindings into druntime. Just need 9/10 (some are floating about) after these mature a bit. I don't think thats wise, nor is it ever like to happen. Druntime is D's runtime, the only reason there are bindings to the C and and C++ standard library is because of their ubiquity. This is much better suited to a dub package. Side note, its possible that I might end up adding a DX12 backend to LDC/DCompute (which I'm going to have to rename if I do) based on https://github.com/Microsoft/DirectXShaderCompiler/ even more likely if MS (Hi Adam) upstream it to LLVM. Direct3D is part of the system API on Window's today, it is equivalent to using WinAPI for graphics. Which is well within the scope of druntime bindings.
Re: Aurora DirectX Bindings 12.1
On 04/10/2018 2:06 PM, Adam Wilson wrote: The Aurora DirectX bindings have been updated to support Windows 10 1809. Also the D2D Effect Authoring SDK has been added. GitHub: https://github.com/auroragraphics/directx DUB: http://code.dlang.org/packages/aurora-directx Please send PR's if you find any bugs! It would be nice to get DirectX bindings into druntime. Just need 9/10 (some are floating about) after these mature a bit.
Re: New With Struct and Getting Class Object Pointers
On 30/09/2018 8:29 PM, Vijay Nayar wrote:
I have two brief questions.
Code that uses "new" to create struct objects appears to compile and
run. Is this an actual language feature, to get structs on the heap?
void main()
{
struct S {int data = 1;}
S* s1 = new S();
S* s2 = s1;
S s3 = *s1; // Still copies on assignment.
s3.data = 2;
assert(s1.data != s3.data);
}
Yes. Uses a compiler hook to call into the GC, like with everything else.
Re: Does the WInMain function is mandatory ?
On 30/09/2018 7:24 PM, Vinod K Chandran wrote: Hi, I would like to do some win api coding in D. I just taste the syntactic sugar but cant do anything more. I have few questions. 1. Does WinMain is needed for a D program in order to use win api ? No. 2. Can we use D strings in win api functions ?, If not, please show me how to convert strings null terminated, nothing really special.
Re: Warn on unused imports?
On 27/09/2018 3:53 AM, Neia Neutuladh wrote: On 09/26/2018 12:39 AM, FeepingCreature wrote: On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg wrote: The DMD compiler is available as a library. A linter tool can be based on that. Repeating it here: the library does not have version-tagged releases. For a build system based around reproducible builds, this makes it completely unusable. It means you need to use git submodules and depend on a specific version that way. And that means you can't tell why you chose a particular revision. For those who are unaware, dmd-fe for usage as a library is completely worthless currently. So not having the tags is probably a good thing.
Re: Rather D1 then D2
On 23/09/2018 2:31 AM, Jonathan Marler wrote: On Saturday, 22 September 2018 at 13:25:27 UTC, rikki cattermole wrote: Then D isn't the right choice for you. I think it makes for a better community if we can be more welcoming, helpful a gracious instead of responding to criticism this way. This is someone who saw enough potential with D to end up on the forums but had some gripes with it, after all who doesn't? I'm glad he took the initiative to provide us with good feedback, and he's not the first to take issue with the inconsistent '@' attribute syntax. I'm sure everyone can agree this inconsistency is less than ideal but that doesn't mean D isn't right for them and we should respond this feedback like this with thanks rather than dismissal. It's much better for the language and for the person looking into a technology to be open to saying that it isn't the right tool for the job after some discussion which has taken place. I would much rather stop people looking instead of trying to impose changes on us that are not likely to happen in any acceptable time span. Let alone at all. At least then, they can look back and see that we didn't want to waste their or our time trying to compromise on something that wasn't going to happen anyway. After all, don't we want to make people happy with their decision?
Re: Rather D1 then D2
On 23/09/2018 1:22 AM, new wrote: On Saturday, 22 September 2018 at 10:53:25 UTC, bauss wrote: On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan Marler wrote: I'd be interested to hear/read about the features that some developers don't like with D2. I'm going to guess it has to do with all the attributes for functions which you often have to remember is it @attribute or is it just attribute like is it @nogc or is it nogc etc. It's one of the things that probably throws off a lot of new users of D, because they feel like they __have__ to know those although they're often optional and you can live without them completely. They make the language seem bloated. the language is bloated. trying to read the source of D2 makes gives you the feeling of getting eye cancer. so we decided if D at all then it should be D1. Then D isn't the right choice for you.
Re: Updating D beyond Unicode 2.0
On 22/09/2018 11:17 AM, Seb wrote: In all seriousness I hate it when someone thought its funny to use the lambda symbol as an identifier and I have to copy that symbol whenever I want to use it because there's no convenient way to type it. (This is already supported in D.) This can be strongly mitigated by using a compose key. But they are not terribly common unfortunately.
Re: LLVM 7.0.0 no mention of D anymore
On 20/09/2018 1:10 AM, Daniel Kozak wrote: http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-7 no mention of D anymore :( http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-6 http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-5 http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-4-0-0 "Supports LLVM 3.7 - 6.0." https://github.com/ldc-developers/ldc/releases/tag/v1.12.0-beta1
Re: extern(C++, ns) is wrong
On 19/09/2018 1:49 PM, Jonathan M Davis wrote: On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote: On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d wrote: On Sunday, 16 September 2018 at 17:46:26 UTC, Steven Schveighoffer wrote: On 9/14/18 6:41 PM, Neia Neutuladh wrote: Specifically, Walter wants this to compile: module whatever; extern(C++, foo) void doStuff(); extern(C++, bar) void doStuff(); And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like: import core.stdcpp.sstream; import core.stdcpp.vector; core.stdcpp.vector.std.vector v; This is probably the best explanation of why the current situation sucks. -Steve Agreed. Up until now, I didn't even understand the rationale for why it works the way it does. https://github.com/dlang/dmd/pull/8667 O_O Thank you Walter for coming to the party! Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty clear that a DIP was needed, and even then, it didn't seem likely that it would be accepted. This is awesome. I guess that he finally came around. - Jonathan M Davis Indeed, thank you Walter!
Re: filtered imports
On 13/09/2018 11:54 PM, Jonathan Marler wrote:
"Selective imports" limit the symbols imported from a module by
providing a list of all the symbols to include:
import std.stdio : writeln, writefln;
The complement of this would be a "Filtered import", meaning, import all
the symbols except the ones in the provided list. I imagine the syntax
would look something like:
import std.stdio ~ writeln, writefln;
To provide a use case for this, say you have a module that uses a fair
amount of symbols from `std.file` but you want to make sure that all
calls to `chdir` are logged. Using a filtered import would allow you to
exclude `chdir` from being available globally so you could create a
wrapper that all code is forced to go through.
import std.stdio;
import std.file ~ chdir;
void chdir(R)(R path)
{
writefln("chdir '%s'", path);
from!"std.file".chdir(path);
}
It's an interesting variation on D's current repertoire of import
semantics. Possibly worth consideration as an addition to the language.
Grammar Changes:
-
ImportBindings: (existing rule)
Import : ImportBindList (existing rule)
Import ~ ImportExcludeList (new rule)
ImportExcludeList: (new rule)
Identifier, ImportExcludeList (new rule)
-
import std.stdio;
import std.file;
void chdir(R)(R path) {
writeln("changing dir to ", path);
std.file.chdir(path);
}
void main()
{
chdir("/tmp");
}
Re: Is it's correct to say that ALL types that can grow are place on heap?
On 13/09/2018 3:22 AM, Timoses wrote: On Wednesday, 12 September 2018 at 14:46:22 UTC, rikki cattermole wrote: On 13/09/2018 2:34 AM, drug wrote: 12.09.2018 15:14, Timoses пишет: On Tuesday, 11 September 2018 at 12:07:14 UTC, drug wrote: If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it. Thank you! So if I pass by reference it will ALWAYS use the address in memory to fetch the data, whereas passing it by value enables the (compiler?..) to use the register which has already loaded the data from memory (stack for example)? Honestly, I'm not an expert in this domain, but I think so. Recently used areas of the stack will be available in the cache in most cases. The issue with passing by reference is it increases the indirection (number of pointers) that it must go through to get to the raw bytes. This is why classes are bad but structs are good. Even if the struct is allocated on the heap and you're accessing it via a pointer. This sounds like classes should never be used.. I don't recall right now what issues I'm usually encountering with structs that make me switch to classes (in D). Nah, this is cycle counting aka don't worry about it if you're not doing anything super high performance.
Re: Is it's correct to say that ALL types that can grow are place on heap?
On 13/09/2018 2:34 AM, drug wrote: 12.09.2018 15:14, Timoses пишет: On Tuesday, 11 September 2018 at 12:07:14 UTC, drug wrote: If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it. Thank you! So if I pass by reference it will ALWAYS use the address in memory to fetch the data, whereas passing it by value enables the (compiler?..) to use the register which has already loaded the data from memory (stack for example)? Honestly, I'm not an expert in this domain, but I think so. Recently used areas of the stack will be available in the cache in most cases. The issue with passing by reference is it increases the indirection (number of pointers) that it must go through to get to the raw bytes. This is why classes are bad but structs are good. Even if the struct is allocated on the heap and you're accessing it via a pointer.
Re: Copy Constructor DIP and implementation
On 12/09/2018 3:08 AM, RazvanN wrote:
Hello everyone,
I have finished writing the last details of the copy constructor DIP[1]
and also I have published the first implementation [2]. As I wrongfully
made a PR for the DIP queue in the early stages of the development of
the DIP, I want to announce this way that the DIP is ready for the draft
review now. Those who are familiar with the compiler, please take a look
at the implementation and help me improve it!
Thanks,
RazvanN
[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688
Here is a question (that I don't think has been asked) why not @copy?
@copy this(ref Foo other) { }
It can be read as copy constructor, which would be excellent for helping
people learn what it is doing (spec lookup).
Also can we really not come up with an alternative bit of code than the
tupleof to copying wholesale? E.g. super(other);
Re: Small @nogc experience report
On 10/09/2018 9:11 PM, Kagamin wrote: On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: There is no other choice when the runtime is disabled but to have @nogc. It's a fantastic peace of mind for high-performance to be able to _enforce_ something will not allocate. You can't have a working GC allocation with disabled runtime, can you? Yes. GC.disable
Re: "immutable string" vs "const string*"
On 09/09/2018 8:41 PM, Christian Mayer wrote: On Sunday, 9 September 2018 at 08:14:41 UTC, rikki cattermole wrote: Are you aware that a string is just an alias of immutable(char)[]? Yes, I'm aware of that. But it's the same, for example, with just one char. "immutable char" vs "const char*". Or int, or any other data type. As of my current understanding "char" will create a new variable and copy the content of the original to the new variable. "char*" will just use the pointer. And "const char*" is good for when not modifying. But I also can achieve the same using "immutable char". But I'm not sure when better using "immutable char". In C I would rather use a const pointer. But since I just started learing D I'm not so sure because there are so many ways. Don't over think it. The only thing you're doing by micro-optimization is causing potential problems that wouldn't otherwise exist.
Re: "immutable string" vs "const string*"
On 09/09/2018 8:09 PM, Christian Mayer wrote: In regard of performance, why should I rather use "immutable string" over "const string*" (or just "string*")? For example, as a function argument. When I have a loop which calls a function with a string argument. (And to avoid function inling in this example the function call is also used in several other places.) It's better to use a pointer instead of every time coping the content of the original string to a new immutable string, right? Or is the optimizer somehow treating the immutable string in another way I'm currently not aware of? Is there an example of a usecase for better using "string" over "string*"? Just want to figure out how to do it the "right" way. Are you aware that a string is just an alias of immutable(char)[]? It already is a pointer with a length, just like any other slice.
Re: Source changes should include date of change
On 09/09/2018 5:43 PM, Paul Backus wrote:
On Sunday, 9 September 2018 at 04:37:48 UTC, Josphe Brigmo wrote:
If git would automatically do the dates then one could download the
source code. Git would be the central repository and if one wanted an
offline version that had enough info in it such as the data a change
was made, who changed it, the date the file was generated etc, then it
would be better than having nothing.
[...]
The thing is, none of this shit hurts anything. Comments don't change
programs so really it is just an issue about bloat and rot. The rot is
covered by git hub automatically generating all the info(then it
becomes no different than the problem of versioning with everything,
want an update, just download it from git). The bloat is minimum and
the bloat is precisely valid information(it's not like it is gibberish).
I think perhaps you are laboring under a severe misunderstanding of what
git is, and how git and Github actually work.
Git is a version control system. It records historical snapshots
("commits") of a project, along with metadata like date and author, and
lets you navigate between different versions. The collection of data and
metadata saved by git for a particular project is called a "git
repository".
Github is a website for hosting git repositories. When you download the
dmd source code from Github using `git clone`, you receive a complete
copy of the entire history of dmd, including both the commits themselves
and the metadata associated with them.
That's why there's no need to add comments--all the data you want is
already there, not just on Github, but in *every single* offline copy.
When we say "just use git," we don't mean "use Github, the website," we
mean "use git, the version control system, to view the historical
information *in your local copy*".
Or Mercurial, SVN, CVS... we are not using mainframes anymore. We can
afford the cost of a full blown database with all this extra information
in it as well as all the past changes. Anyways, we're no longer talking
hundreds of lines of code. We talk in millions of lines of code where
comments just don't scale to.
Re: Returning dynamic array from the function?
On 08/09/2018 9:46 PM, SuperPrower wrote:
On Saturday, 8 September 2018 at 09:36:21 UTC, rikki cattermole wrote:
We're going to need to see a minified version of the code to see what
you're doing.
Sure, here it is:
```
auto getBoards()
{
string[] boardList;
auto url = baseUrl ~ "/api/v2/boards";
auto http = HTTP(url);
http.method = HTTP.Method.get;
http.onReceive = (ubyte[] data) {
auto content = cast(string) data[];
auto content = cast(string)(data.dup);
boardList = strip(content, "[", "]").split(",");
foreach (ref b; boardList) {
b = strip(b, `"`);
}
return data.length;
};
http.perform();
writeln(boardList);
return boardList;
}
```
This is a member function of some class. It doesn't really have any
fields, so I left if out. In it, I use curl library to getch some data
and split it. Next, I try to use this function to get this list:
```
Fetcher fetcher = new Fetcher;
auto boards = fetcher.getBoards();
writeln(boards);
```
I printed array twice: inside the function and after return. Here is the
output:
```
["a", "burg", "cyb", "d", "lain", "mu", "new", "tech", "test", "u", "v",
"all"]
[x"F9"c, x"FA 01 00 00"c, "\0\0\0", "d", "lain", "mu", "new", "tech",
"test", "u", "v", "all"]
```
As you can see, when outside of the funtion, first few elements of the
array contain garbage. I would like to know both why this happens and
how do I avoid it (i.e. what is the correct way of returning dynamic
array).
onReceive:
"The event handler that receives incoming data. Be sure to copy the
incoming ubyte[] since it is not guaranteed to be valid after the
callback returns."
It could be a buffer on the stack, either way, .dup it before you cast.
Re: Returning dynamic array from the function?
On 08/09/2018 9:34 PM, SuperPrower wrote: I have a function that produces dynamic array of strings. I would like to return this array from this function. I understand that dynamic arrays are of reference type, and thus if I try to return array variable, I will actually return a pointer to the first element of the array on the heap. Problem is, when I return dynamic array and try to print it outside of the function, I see garbage in a first few elements. My humble experience with languages like C++ doesn't really help with understanding how Garbage Collector (if it's because of it, because if I understand correctly, I can imagine memory being de-allocated because we get out of scope of local variable that points to the array, thus there are no more pointers to this memory, thus it gets de-allocated, but we still return reference to this memory, so GC shouldn't really free it?) can cause this - can anyone please explain me what's exactly going on and what would be the proper way to return dynamic array from the function? Thanks in advance. We're going to need to see a minified version of the code to see what you're doing.
Re: [vibe-d/dub] Lin
On 08/09/2018 4:20 AM, MamoKupe wrote: marcinan@marcinan-PC ~/Pulpit/d $ dub init bibe Package recipe format (sdl/json) [json]: d Invalid format, "d", enter either "sdl" or "json". Package recipe format (sdl/json) [json]: Name [bibe]: Description [A minimal D application.]: Author name [Marcin]: License [proprietary]: Copyright string [Copyright © 2018, Marcin]: Add dependency (leave empty to skip) []: vibe-d Added dependency vibe-d ~>0.8.4 Add dependency (leave empty to skip) []: Successfully created an empty project in '/home/marcinan/Pulpit/d/bibe'. Package successfully created in bibe marcinan@marcinan-PC ~/Pulpit/d $ cd bibe/ marcinan@marcinan-PC ~/Pulpit/d/bibe $ dub run Performing "debug" build using /usr/bin/dmd for x86_64. taggedalgebraic 0.10.11: target for configuration "library" is up to date. eventcore 0.8.35: target for configuration "epoll" is up to date. stdx-allocator 2.77.2: target for configuration "library" is up to date. vibe-core 1.4.2: target for configuration "winapi" is up to date. vibe-d:utils 0.8.4: target for configuration "library" is up to date. vibe-d:data 0.8.4: target for configuration "library" is up to date. mir-linux-kernel 1.0.0: target for configuration "library" is up to date. vibe-d:crypto 0.8.4: target for configuration "library" is up to date. diet-ng 1.5.0: target for configuration "library" is up to date. vibe-d:stream 0.8.4: target for configuration "library" is up to date. vibe-d:textfilter 0.8.4: target for configuration "library" is up to date. vibe-d:inet 0.8.4: target for configuration "library" is up to date. vibe-d:tls 0.8.4: target for configuration "openssl" is up to date. vibe-d:http 0.8.4: target for configuration "library" is up to date. vibe-d:mail 0.8.4: target for configuration "library" is up to date. vibe-d:mongodb 0.8.4: target for configuration "library" is up to date. vibe-d:redis 0.8.4: target for configuration "library" is up to date. vibe-d:web 0.8.4: target for configuration "library" is up to date. vibe-d 0.8.4: target for configuration "vibe-core" is up to date. bibe ~master: building configuration "application"... Linking... /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto collect2: error: ld returned 1 exit status Error: linker exited with status 1 /usr/bin/dmd failed with exit code 1. On linux Mint with DUB version 1.11.0, built on Sep 1 2018 Nothing wrong with vibe-d. You're just missing the required -dev packages (apt).
Re: dip1000 issue
On 08/09/2018 2:29 AM, Orfeo wrote: ==> And why (maybe a silly question) `-dip1000` breaks my project so badly without warning.. DIP 1000 is an experimental addition to D, that is yet to be complete. It is a compiler switch for a reason, it isn't ready for usage, only some experimentation.
Re: file io
On 07/09/2018 4:17 AM, Arun Chandrasekaran wrote:
On Thursday, 6 September 2018 at 16:13:42 UTC, hridyansh thakur wrote:
how to read a file line by line in D
std.stdio.File.byLine()
Refer the doc here: https://dlang.org/library/std/stdio/file.by_line.html
An example from the doc:
```
import std.algorithm, std.stdio, std.string;
// Count words in a file using ranges.
void main()
{
auto file = File("file.txt"); // Open for reading
const wordCount = file.byLine() // Read lines
.map!split // Split into words
.map!(a => a.length) // Count words per line
.sum(); // Total word count
writeln(wordCount);
}
```
Ranges will be far too advanced of a topic to bring up at this stage.
So something a little more conventional might be a better option:
---
import std.file : readText;
import std.array : split;
import std.string : strip;
string text = readText("file.txt");
string[] onlyWords = text.split(" ");
uint countWords;
foreach(ref word; onlyWords) {
word = word.strip();
if (word.length > 0)
countWords++;
}
---
Re: linking trouble
On 07/09/2018 4:03 AM, hridyansh thakur wrote:
i am on windows i have tried
DMD
LDC
and i am getting same linking error with linking my c++ object
i am doing by the official tutorial (dlang spec book)
here is my app.d code
import std.stdio;
void main()
{
//writeln("Edit source/app.d to start your project.");
int[] m = someFUN(44,55);
ulong k = m.length;
for (int i=0;i
That definition isn't complete. Missing at the very least ``();`` to
make it a function declaration.
here is the C++ code
#include
#include
#include
FILE *fp;
int*file_io(){
char name[20] ;
std::cout << "please enter the file name " << '\n';
std::cin >> name;
fp = fopen(name,"r+");
char a = 'a';
int n = 0 ;
while (!feof(fp)) {
a = fgetc(fp);
if (a=='\n') {
n++;
}
}
int *p = (int*)calloc(n,sizeof(int));
for (size_t i = 0; i < n ; i++) {
fscanf(fp,"%d",(p+i));
}
return p;
}
So what is the errors you're getting?
And what are the commands you're executing?
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 07/09/2018 2:30 AM, Guillaume Piolat wrote: On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote: And autodecode is a good example of experts getting it wrong, because, you know, you cannot be an expert in all fields. I think the problem was that it was discovered too late. There are very valid reasons not to talk about auto-decoding again: - it's too late to remove because breakage - attempts at removing it were _already_ tried - it has been debated to DEATH - there is an easy work-around So any discussion _now_ would have the very same structure of the discussion _then_, and would lead to the exact same result. It's quite tragic. And I urge the real D supporters to let such conversation die (topics debated to death) as soon as they appear. +1 Either decide a list of conditions before we can break to remove it, or yes lets let this idea go. It isn't helping anyone.
Re: Dub registry refresh
On 06/09/2018 8:39 PM, Bastiaan Veelo wrote: On Thursday, 6 September 2018 at 08:29:03 UTC, rikki cattermole wrote: On 06/09/2018 8:22 PM, Bastiaan Veelo wrote: Hi, How often and when does code.dlang.org look for new releases? Pegged has tagged a new release 14 hours ago, and I wonder when I can expect dub to pick that up. Thanks! It is semi-constant. How semi? :-) Does 14 hours still count, or should we assume the process is somehow stuck? Process has been and gone but it wasn't tagged correctly so it never updated. See other comment.
Re: Dub registry refresh
On 06/09/2018 8:29 PM, rikki cattermole wrote: On 06/09/2018 8:22 PM, Bastiaan Veelo wrote: Hi, How often and when does code.dlang.org look for new releases? Pegged has tagged a new release 14 hours ago, and I wonder when I can expect dub to pick that up. Thanks! It is semi-constant. However if you care about it showing up sooner, you should trigger it manually. Also, you forgot the v in the tag. 0.4.4 isn't valid tagged version name.
Re: Dub registry refresh
On 06/09/2018 8:22 PM, Bastiaan Veelo wrote: Hi, How often and when does code.dlang.org look for new releases? Pegged has tagged a new release 14 hours ago, and I wonder when I can expect dub to pick that up. Thanks! It is semi-constant. However if you care about it showing up sooner, you should trigger it manually.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 06/09/2018 7:54 PM, Joakim wrote:
On Thursday, 6 September 2018 at 07:23:57 UTC, Chris wrote:
On Wednesday, 5 September 2018 at 22:00:27 UTC, H. S. Teoh wrote:
//
Seriously, people need to get over the fantasy that they can just use
Unicode without understanding how Unicode works. Most of the time,
you can get the illusion that it's working, but actually 99% of the
time the code is actually wrong and will do the wrong thing when
given an unexpected (but still valid) Unicode string. You can't
drive without a license, and even if you try anyway, the chances of
ending up in a nasty accident is pretty high. People *need* to learn
how to use Unicode properly before complaining about why this or that
doesn't work the way they thought it should work.
T
Python 3 gives me this:
print(len("á"))
1
and so do other languages.
The same Python 3 that people criticize for having unintuitive unicode
string handling?
https://learnpythonthehardway.org/book/nopython3.html
Is it asking too much to ask for `string` (not `dstring` or `wstring`)
to behave as most people would expect it to behave in 2018 - and not
like Python 2 from days of yore? But of course, D users should have a
"Unicode license" before they do anything with strings. (I wonder is
there a different license for UTF8 and UTF16 and UTF32, Big / Little
Endian, BOM? Just asking.)
Yes and no, unicode is a clusterf***, so every programming language is
having problems with it.
So again, for the umpteenth time, it's the users' fault. I see.
Ironically enough, it was the language developers' lack of
understanding of Unicode that led to string handling being a nightmare
in D in the first place. Oh lads, if you were politicians I'd say that
with this attitude you're gonna the next election. I say this, because
many times the posts by (core) developers remind me so much of
politicians who are completely detached from the reality of the
people. Right oh!
You have a point that it was D devs' ignorance of unicode that led to
the current auto-decoding problem. But let's have some nuance here, the
problem ultimately is unicode.
Let's also be realistic here, when D was being designed UTF-16 was
touted as being 'the' solution you should support e.g. Java had it
retrofitted shortly before D. So it isn't anyone's fault on D's end.
Re: Random thought: Alternative stuct
On 04/09/2018 3:38 PM, Nick Sabalausky (Abscissa) wrote: We have classes and structs: Classes: - Default Storage: GC Heap - Indirection Overhead: Yes - Semantics: Reference - Passed By: Copying the Data's Address Structs: - Default Storage: Stack - Indirection Overhead: No - Semantics: Value - Passed By: Copying the Data (except where the compiler can determine it can safely and more efficiently pass by reference...at least, IIUC) Signatures: - Default Storage: Heap (with help of scope so won't be GC'd) - Indirection Overhead: Yes, one layer, no other way to do it if the backend can't optimize it out - Semantics: Reference - Passed By: Copying a pointer static array around (ref+scope can make this near free) - Implementation support: Classes and structs
Re: This is why I don't use D.
On 06/09/2018 4:19 AM, H. S. Teoh wrote: On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d wrote: [...] And that is why I think we should implement my idea of putting *all* dub packages on code.dlang.org into our CI infrastructure, and log all successes / failures to a database that can then be used to display the range of version(s) of compilers that successfully built each package on code.dlang.org. Then people can quickly see, at a glance, whether the package still works with the version of the compiler that they're using (usually the most recent release, but not always, so this information can be super useful in making decisions). Oh, I think that that's a good idea, and it should help with folks picking libraries to use, but it doesn't fix the fundamental problem that whoever wrote the library needs to continue to maintain it or pass it on to someone else to maintain it when they don't want to maintain it anymore, or anyone using it is going to be screwed. So, while your suggestion will definitely help with a piece of the problem, it doesn't solve the part that I was talking about. [...] Once packages are annotated with the last working compiler version, it will be an easy next step to identify all broken packages that need maintenance. If there's an easy fix, someone could open a PR and push it upstream, or if upstream has abandoned the project, we could fork it and apply the fix. Either way, CI automation would help us with the initial chore of identifying such packages in the first place. Also, if the last working compiler version is prominently displayed e.g. in the search results, it will inform people about the maintenance state of that package, which could factor in their decision to use that package or find an alternative. It will also inform people about potential breakages before they upgrade their compiler. It doesn't solve all the problems, but it does seem like a good initial low-hanging fruit that shouldn't be too hard to implement. T Alternatively we can let dub call home for usage with CI systems and register it having been tested for a given compiler on a specific tag.
Re: DIP Draft Reviews
On 06/09/2018 2:20 AM, Nicholas Wilson wrote: On Monday, 20 August 2018 at 14:54:24 UTC, Mike Parker wrote: I'm getting ready to start prepping one of the DIPs in the PR queue for community review. It proposes adding an `in` operator for arrays. I haven't gone through it in detail yet, so I invite anyone with time on their hands to provide feedback on the Draft so we can more speedily get in shape to kick off the big-league reviews. https://github.com/dlang/DIPs/pull/101 While you're at it, feel free to poke around and leave some feedback on other drafts in the queue. pull/101 was closed. What's happening now? Last time I checked, it should be me and yshui's named parameter DIP's next, they really need to be reviewed together though, at least initially.
Re: Static foreach bug?
On 06/09/2018 12:52 AM, JN wrote: On Wednesday, 5 September 2018 at 12:41:05 UTC, Andre Pany wrote: On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote: Indeed. scope enum would make much more sense. scope enum sounds a lot better for me than static enum or even __local. The __ words looks a little bit like compiler magic as the __ words are reserved for the compiler. Kind regards Andre To be honest, using enum as "compile-time variable" is magic enough. Enum should be reserved for enumerations. But I guess it's one of those things that is too late to change. An enum is some sort of constant. As long as something like scope enum remains a constant and not an actual variable that can be modified, then I think that it is ok naming-wise. Of course the manifest enum's that you're referring to is a remnant of #define in C. So it sort of makes sense and a little not at the same time. Tis' weird.
Re: Static foreach bug?
On 05/09/2018 11:39 PM, Jonathan M Davis wrote:
On Wednesday, September 5, 2018 5:19:04 AM MDT Dechcaudron via Digitalmars-d
wrote:
On Wednesday, 5 September 2018 at 10:45:20 UTC, Jonathan M Davis
wrote:
Too many people already think that the point of static is to
just make something be done at compile time (which is actually
a pretty terrible reason to use static) without adding that
sort of thing into the confusion.
Well, "static" in English means something that does not change
(so do constant and immutable, but that's another story). One
could argue that using static for function-scope variables with
extended lifespan and for variables shared between instances of a
class is more misleading. But since virtually every language out
there uses them for that purpose, I understand we want to go with
it. But then again, "static if" and "static foreach" make sense
to me. And since all enums are compile time constants by
definition, "static enum" may be a good way to tell them apart,
although I do agree that it is far from ideal.
I understand that the syntax for CT if and foreach blocks is not
going to be changed for good reasons now, but was something like
"CTif" considered at the time? I know it doesn't "look" good as
is, but maybe some small variation could have done the trick.
The thing is that static already has a meaning when it's used on a variable
declaration.
static foo = 42;
and
enum foo = 42;
already have distinct meanings, and _everything_ having to do with enums is
already a compile-time thing. So, something like
static enum foo = 42;
really stands no chance of being anything other than highly confusing. Not
to mention, you then get into the fun question of what happens when someone
does something like
static
{
enum foo = 42;
}
or
static:
enum foo = 42;
And actually, right now,
static enum foo = 42;
has exactly the same meaning. In all three cases, the static is ignored,
because it's meaningless to apply it to an enum. So, making
static enum foo = 42;
change its meaning could actually break code (albeit code that's badly
written), and if
static enum foo = 42;
had a special meaning, then it would be inconsistent if the
static { enum foo = 42; }
or
static: enum foo = 42;
versions acted differently. And those actually are much more likely to break
otherwise valid code.
Conceptually, what Timon is talking about doing here is to add an attribute
to symbols declared within a static foreach where that attribute indicates
that the symbol is temporary (or at least scoped to a particular iteration
of the loop). So, saying that it's "local" as __local would makes perfect
sense. It's local to that iteration of the loop.
And there may very well be other syntaxes which would be better, but trying
to overload the meaning of static even further by using it in this context
would risk code breakage and would be _very_ confusing for most people.
- Jonathan M Davis
Indeed. scope enum would make much more sense.
Re: andrei - better breakdown of statistics for downloads by region, OS, kind of site (academic/large corporate/large financial/etc)
On 05/09/2018 10:19 PM, Jonathan M Davis wrote: On Wednesday, September 5, 2018 1:44:33 AM MDT Suliman via Digitalmars-d wrote: On Tuesday, 8 May 2018 at 07:54:15 UTC, Suliman wrote: Stat out of date... Plz update it. And once again plz Just FYI, responding to a thread that's several months old is a good way for a lot of folks to not see it. While the forum interface puts the most recent posts at the top, even if it's in an old thread, folks using the newsgroup or mailing list interfaces probably won't see it (and that includes most of the long time contributors). If the thread you want to post in is not recent, your post is much more likely to be seen if you create a new thread. - Jonathan M Davis What client has that behavior? Because it is displayed quite happily in Thunderbird.
Re: extern(C++, ns) is wrong
On 05/09/2018 9:35 PM, Jonathan M Davis wrote: On Wednesday, September 5, 2018 2:30:25 AM MDT Walter Bright via Digitalmars-d wrote: On 9/4/2018 10:16 PM, Manu wrote: I'm serious, you can have your cake, and potentially, I could have my cake too, and everybody would be happy... nobody would be sad. If it is the same, I provided solutions in those threads. The incomplete example code did not make use of them. I don't know why you have "no option" left. If I understand correctly, what it basically comes down to is that Manu finds all of the workarounds that you've suggested to be so annoying as to be intolerable. And after running into some of the same problems yet again, he felt the need to complain about it again and beg you to change your mind, since he feels that he has no idea how to convince you. I get the impression that he thinks that his proposed solution is so obviously better that he doesn't understand why you don't see that it's better, but I don't know. Either way, I think that we all know that it can be very difficult to convince you of something (though that's true of many of us around here). :) From what I understand of the situation, I'm inclined to agree with Manu's position on this topic, but I thought that it was clear from the previous discussion that if there were any chance of anything changing, we were going to need a DIP. Based on everything that's been said thus far, I question that that stands much chance of convincing you, but I do think that we need a clear definition of the proposed solution so that we can avoid talking passed each other, which seemed to be happening at least some of the time in the recent thread. Either way, unless someone can come up with an example of the problem or argument about it that somehow convinces you when the previous examples and arguments didn't, I'm not sure that there's much point in arguing about it without at least having a clear DIP on the topic. - Jonathan M Davis +1 My interpretation is very similar, only difference is that Manu is asking for is removal of some artificial restrictions put in place to prevent possible problems that probably won't appear in D. I agree with the solution you have provided to move forward. I think we're done arguing, Walter just doesn't seem to want to accept Manu's use case as-is.
Re: What changes to D would you like to pay for?
On 05/09/2018 7:00 PM, Joakim wrote: The D foundation is planning to add a way for us to pay for changes we'd like to see in D and its ecosystem, rather than having to code everything we need ourselves or find and hire a D dev to do it: "[W]e’re going to add a page to the web site where we can define targets, allow donations through Open Collective or PayPal, and track donation progress. Each target will allow us to lay out exactly what the donations are being used for, so potential donors can see in advance where their money is going. We’ll be using the State of D Survey as a guide to begin with, but we’ll always be open to suggestions, and we’ll adapt to what works over what doesn’t as we go along." https://dlang.org/blog/2018/07/13/funding-code-d/ I'm opening this thread to figure out what the community would like to pay for specifically, so we know what to focus on initially, whether as part of that funding initiative or elsewhere. I am not doing this in any official capacity, just a community member who would like to hear what people want. Please answer these two questions if you're using or would like to use D, I have supplied my own answers as an example: I have $50USD to spend upon shared library support to be designed (not just patching bugs) and implemented.Sadly that is my limit. I wish it was more given how much of a blocker it can be (and has shown to be). $25 - Enable GC for the DMD frontend, so that dmd/gdc/ldc use less memory The only thing I believe required for this is [0]. This depends upon a decision from Walter and should be pretty straight forward to do. But the frontend will not be in any way ready to be used as a library. During DConf I did attempt to get the frontend ready to be actually usable. After my first PR sitting for like 3 months and is now looking like its dead, I won't be the one handling that anymore. [0] https://issues.dlang.org/show_bug.cgi?id=18811
Re: How to use listener.d example?
On 05/09/2018 12:10 AM, Marcin wrote: "" Am i doing it right? I've unpacked vibe.d-master to my "C:\D\dtwo\src" commands in cmd: cd C:\D\dtwo\windows\bin\ echo "vibe.d-master is a folder" dmd -lib C:\D\dtwo\src\vibe.d-master\core\vibe\appmain.d C:\D\dtwo\src\vibe.d-master\http\vibe\http\server.d no wai, Ill just paste the vibe.d-master to my code location and add more arguments. dub fetch vibe-d downloaded something dub run vibe-d runs something dub test vibe-d vibe-d:redis 0.8.4: building configuration "library"... vibe-d:web 0.8.4: building configuration "library"... vibe-d 0.8.4: building configuration "vibe-d-test-vibe-core"... Linking... Error: linker exited with status 1 C:\D\dtwo\windows\bin\dmd.exe failed with exit code 1. still don't work I love programming... after 37 h of tryin to force run compiler. You didn't need to download or manually fetch vibe-d yourself (it won't work this way FYI). Just make sure dmd (windows/bin directory) is on your PATH variable, and you're good to go for the below example. $ cd c:/projects/test_vibed $ dub init json someprojectname my description Marcin proprietary Copyright 2018 vibe-d \n $ dub run
Re: Random thought: Alternative stuct
On 04/09/2018 11:47 PM, Kagamin wrote: On Tuesday, 4 September 2018 at 06:32:02 UTC, rikki cattermole wrote: If D didn't have built-in OOP features already, it'd be an interesting question, but given that it does, I think getting rid of them is a clear net-negative. You also loose loads of stuff like extern(C++) classes interop and COM. Definitely a net negative. Even with a concept like signatures, you just can't replace the class/interface system. Even in betterC? Last I checked classes pulled TypeInfos and all the stuff. What's the problem to use COM without classes? I do it. Being able to define and use COM as it was intended (via classes) is a feature of D. Looks like it could be pretty straight forward to get it working in -betterC, since what it isn't complaining about is TypeInfo. Keep in mind, IUnknown is its own root, just like Object and has a completely different ABI for vtable's and such. test.obj(test) Error 42: Symbol Undefined __D6object6Object8opEqualsMFCQtZb test.obj(test) Error 42: Symbol Undefined __D6object6Object5opCmpMFCQqZi test.obj(test) Error 42: Symbol Undefined __D6object6Object6toHashMFNbNeZk test.obj(test) Error 42: Symbol Undefined __D6object6Object8toStringMFZAya test.obj(test) Error 42: Symbol Undefined __D4test3Foo7__ClassZ
Re: How to use listener.d example?
On 04/09/2018 10:57 PM, Marcin wrote: On Friday, 31 August 2018 at 07:38:54 UTC, Marcin wrote: https://github.com/dlang/dmd/blob/master/samples/listener.d Im using Notepad++ as my IDE cuz i dont have administrator privileges on PC Coedit is a good option since it is a simple unzip and ready to go. Although less than ugh "normal" but still a good option when nothing else decent exists. https://github.com/BBasile/Coedit To import modules i use -I option cmd /k cd C:\D\dtwo\windows\bin\ & C:\D\dtwo\windows\bin\dmd.exe -I="$(CURRENT_DIRECTORY)" "$(FULL_CURRENT_PATH)" & C:\D\dtwo\windows\bin\$(NAME_PART).exe -I is only for directories and the modules contained must be already compiled and ready to be linked in. C:\Users\wjelki\Desktop\d\aplikacja.d(2): Error: module `server` is in file 'vibe\http\server.d' which cannot be read import path[0] = C:\Users\wjelki\Desktop\d\vibe.d\core import path[1] = .\..\..\src\phobos import path[2] = .\..\..\src\druntime\import How to import other modules than Phobos? For vibe.d use the build manager dub and yes dmd comes with it already. But the general way to do it straight is: dmd -of mylib.lib -lib a/filea.d a/fileb.d dmd -of myprog.exe mylib.lib b/filec.d -I a Of course that is off the top of my head and I only ever use dub so... take that with a grain of salt.
Re: D is dead
On 04/09/2018 10:27 PM, Ecstatic Coder wrote:
On Tuesday, 4 September 2018 at 09:56:13 UTC, rikki cattermole wrote:
On 04/09/2018 9:40 PM, Ecstatic Coder wrote:
But it seems that the latest version of "std.file.copy" now
completely ignores the "PreserveAttributes.no" argument on Windows,
which made recent Windows builds of Resync fail on read-only files.
What???
There is nothing in the changelog between 2.080.0 and 2.082.0 for
changes to std.file.
Version from July 2017[0]. Version from 2.082.0[1]. They look the same
to me.
[0]
https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430
[1] https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216
Mayb I'm wrong, but what I can say is that I've recently updated DMD and
compiled a windows build of Resync, and that I *HAD* to make
Windows-specific code that removes the "read-only" attributes only on
Windows.
attributes = source_file_path.getAttributes();
source_file_path.getTimes( access_time, modification_time );
version ( Windows )
{
if ( target_file_path.exists() )
{
target_file_path.setAttributes( attributes & ~1 );
}
source_file_path.copy( target_file_path, PreserveAttributes.no );
target_file_path.setAttributes( attributes & ~1 );
target_file_path.setTimes( access_time, modification_time );
target_file_path.setAttributes( attributes );
}
else
{
if ( target_file_path.exists() )
{
target_file_path.setAttributes( 511 );
}
source_file_path.copy( target_file_path, PreserveAttributes.no );
target_file_path.setAttributes( attributes );
target_file_path.setTimes( access_time, modification_time );
}
Honestly I don't see why I have to make this ugly fix on Windows, while
the Linux version has always worked fine on read-only files.
Hang on a second.
assert(preserve == Yes.preserveAttributes);
Something is smelling an awful lot here.
Up to Windows 7 CopyFileW which is used for Windows didn't copy the
attributes over[0] but it does now.
This is a bug on our end, which should include a fallback to copying
manually the file contents over.
[0]
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-copyfilew
Re: D is dead
On 04/09/2018 9:40 PM, Ecstatic Coder wrote: But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files. What??? There is nothing in the changelog between 2.080.0 and 2.082.0 for changes to std.file. Version from July 2017[0]. Version from 2.082.0[1]. They look the same to me. [0] https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430 [1] https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216
Re: Random thought: Alternative stuct
On 04/09/2018 4:24 PM, Paul Backus wrote: On Tuesday, 4 September 2018 at 04:03:19 UTC, Mike Franklin wrote: There are also a few additional differences. classes can inherit implementations, but using the technique illustrated in https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html, you can get something very much like classes. With `alias this` and multiple-`alias this` (https://github.com/dlang/dmd/pull/8378) it gets even better. [...] In my opinion, we shouldn't add a third option. Rather, we should deprecate classes, and make and expand the capabilities of structs. Languages like Zig and Rust have done away with classes and all runtime overhead that accompanies them, and are showing great promise by expanding on structs with much more composable features. You can implement inheritance in C, if you really want to, but doing it by hand is far less productive and far more error prone than using a compiler that does it for you. Now, with D's metaprogramming capabilities, it may well be possible to implement an object system as a library, using only structs. Without AST macros, though, a library solution is always going to have uglier syntax and worse error messages than a language feature with compiler support. If D didn't have built-in OOP features already, it'd be an interesting question, but given that it does, I think getting rid of them is a clear net-negative. You also loose loads of stuff like extern(C++) classes interop and COM. Definitely a net negative. Even with a concept like signatures, you just can't replace the class/interface system.
Re: Load entire file, as a char array.
On 03/09/2018 7:38 PM, Chris Katko wrote:
On Monday, 3 September 2018 at 06:28:38 UTC, bauss wrote:
On Monday, 3 September 2018 at 06:25:23 UTC, bauss wrote:
On Monday, 3 September 2018 at 03:19:39 UTC, Neia Neutuladh wrote:
On Monday, 3 September 2018 at 03:04:57 UTC, Chris Katko wrote:
This should be simple? All I want to do is load an entire file, and
access individual bytes. The entire thing. I don't want to have
know the file size before hand, or "guess" and have a "maximum
size" buffer.
So far, all google searches for "dlang binary file read" end up not
working for me.
Thank you.
http://dpldocs.info/experimental-docs/std.file.read.1.html
import std.file : read;
auto bytes = read("filename");
This gives you a void[], which you can cast to ubyte[] or char[] or
whatever you need.
Or he could do readText() which returns a string, which in turn will
give a proper char array when casted.
Actually ignore the casting thing, looking at readText it takes a
template parameter.
So:
char[] a = readText!(char[])("filename");
Thanks, that works!
But... I'm so confused by D's fifty different string types.
Only three. string, wstring and dstring. They are all aliases for
immutable(Char)[].
I can run .strip() on a char[]. But I can't run .replace('\n','?') ?
Replace is working on arrays, use " not '. There is a dedicated version
for characters (tr).
So then I convert char[] to a temporary string and run replace on that.
import std.stdio;
import std.array;
void main()
{
char[] text = "123\nhi".dup;
text = text.replace("\n", "?");
text.writeln;
}
but then writefln("%s") doesn't accept strings! Only char[].
char []t = cast(char[])(c[i-15 .. i+1]).strip();
string s = text(t); //s.replace('\n','?')
writefln(" - [%s]", s); // fail
Looks ok to me:
import std.stdio;
void main()
{
string s = "text";
writefln(" - [%s]", s);
}
Re: [OT] college
On 03/09/2018 7:05 PM, Joakim wrote: One of the root causes of that dysfunction is there's way too much software written. Open source has actually helped alleviate this, because instead of every embedded or server developer who needs an OS kernel convincing management that they should write their own, they now have a hard time justifying it when a free, OSS kernel like linux is out there, which is why so many of those places use linux now. Of course, you'd often like to modify the kernel and linux may not be stripped down or modular enough for some, but there's always other OSS kernels like Minix or Contiki for them. Yes but 30 years ago it was actually realistic and even best practice to write your own OS as part of deployment of e.g. game. Can't say that now even in the micro controller space.
Re: Example of using C API from D?
On 03/09/2018 5:07 AM, Russel Winder wrote: On Mon, 2018-09-03 at 01:00 +1200, rikki cattermole via Digitalmars-d- learn wrote: […] You don't need to create a complete binding for something to use a subset of it. True, but all too often you find there are so many interdependencies of names, you end up binding most of the API. I tried fiddling with Fontconfig using Python which has no binding and was able to hack up just enough using CFFI to get things working. So I think in this case a subset for the application is feasible – as opposed to creating a complete binding. You won't need to actually fill out any c struct's that you don't need either. Make them opaque as long as they are referenced via pointer and not by value. Writing up a Derelict style binding is easy enough since e.g. SharedLib struct handles most of the work (from util package). https://github.com/DerelictOrg/DerelictUtil/blob/master/source/derelict/util/sharedlib.d#L118 I am not convinced this is a good approach since you do not get the signatures at compile time. The advantage of a binding, or subset of a binding is that you get full compiler support. Ugh, you do know that the linker which does all the hard work doesn't know anything about the signature of the C function? That is the part SharedLib replaces. You will of course define it with a proper signature on D's side with a helpful cast :) i.e. https://github.com/DerelictOrg/DerelictGL3/blob/master/source/derelict/opengl/versions/gl1x.d
Re: Example of using C API from D?
On 03/09/2018 12:52 AM, Russel Winder wrote: I am rewriting a C++ program in D, but need to access a C library that has no D binding: this is a GtkD based program which has a Pango binding, but Pango doesn't offer the information I need, that is hidden in the underlying Fontconfig C API. I could create a complete D binding for Fontconfig using the GIR files but that seems a bit over the top. Can anyone point me at an example of a D program using a C API that has structs, enums and functions so I can see if I just hack enough for my use or go on to the full binding activity. You don't need to create a complete binding for something to use a subset of it. Writing up a Derelict style binding is easy enough since e.g. SharedLib struct handles most of the work (from util package). https://github.com/DerelictOrg/DerelictUtil/blob/master/source/derelict/util/sharedlib.d#L118
Re: This thread on Hacker News terrifies me
On 02/09/2018 1:15 AM, Jonathan M Davis wrote: On Saturday, September 1, 2018 6:46:38 AM MDT rikki cattermole via Digitalmars-d wrote: On 02/09/2018 12:21 AM, tide wrote: On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote: On 01/09/2018 12:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. And yet they manage to run a JVM with Java on it. Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it. For some reason I have memories related to DVD players containing a JVM to provide interactivity. But it doesn't look like those memory were based on anything. So ignore me. I don't know if any DVD players have ever used Java, but all Blu-ray players do require it, because unfortunately, the Blu-ray spec allows for the menus to be done via Java (presumably so that they can be fancier than what was possible on DVDs). - Jonathan M Davis Harry potter 1&2 had games as part of their menus as of 2001/2, so it was already pretty sophisticated.
Re: This thread on Hacker News terrifies me
On 02/09/2018 12:57 AM, tide wrote: On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote: On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it. And you're putting that into production code? Cause that's the entire point of this topic :). Goodness no. I can BSOD Windows just by writing user-land code that pretty much every program uses (yes related). Some things can definitely be tested in an assert, however like Walter has been arguing, are better left untested in production. Keep in mind, a window whose decorations has changed color, is a very reasonable and should be expected situation. It is no where near an error. This is one of the reasons I wouldn't bother with automated UI testing. Too many things can make it fail that is not related to your code, and integration may as well not exist cross-platform anyway. Let alone be well defined.
Re: This thread on Hacker News terrifies me
On 02/09/2018 12:21 AM, tide wrote: On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote: On 01/09/2018 12:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. And yet they manage to run a JVM with Java on it. Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it. For some reason I have memories related to DVD players containing a JVM to provide interactivity. But it doesn't look like those memory were based on anything. So ignore me.
Re: This thread on Hacker News terrifies me
On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it.
Re: This thread on Hacker News terrifies me
It all comes down to, not enough time to cover the material. Programming is the largest scientific field in existence. It has merged material from Physics, Chemistry, Psychology (in a BIG WAY), Biology, you name it and that ignores Mathematics. Three to four years is just scratching the surface of what is needed to be known. There is simply no way to ignore that fact.
Re: This thread on Hacker News terrifies me
Then there are polytechnics which I went to for my degree, where the focus was squarely on Industry and not on academia at all. But in saying that, we had third year students starting out not understanding how cli arguments work so... Proper software engineering really takes 5+ years just to get started, 10+ to become actually good at it. Sadly that won't be acceptable in our current society.
Re: This thread on Hacker News terrifies me
On 01/09/2018 12:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. And yet they manage to run a JVM with Java on it.
Re: Engine of forum
On 31/08/2018 10:16 PM, Andrey wrote: Any self-respecting website related to programming or developing something, has in its composition a place where people can comfortably and freely discuss pressing issues. Not some weird news group. Feel free to argue this for projects like the Linux kernel. If you succeed it is safe to say we will too.
Re: splitting general into Technical and less technical
On 30/08/2018 5:20 AM, Jonathan M Davis wrote: Also, dlang-study was already basically an attempt to get more focused, technical discussions separate from the main newsgroup, and it didn't work. It wasn't as simple as posting to D.General. It required subscription (based upon what I did) and it couldn't just be posted to like D.General even from e.g. Thunderbird. So there was a barrier to actually posting there.
Re: Go 2 draft
On 29/08/2018 7:03 PM, JN wrote: Found this interesting link on proggit - https://go.googlesource.com/proposal/+/master/design/go2draft.md D is mentioned in the generics part: https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md I like their design for contract's, it looks rather fitting for the language. It's a real scaled back approach to a full blown signature design (which I want + WIP DIP).
Re: std.encoding:2554 - Unrecognized Encoding: big5 - Please help!
We have a reasonably number (but quiet) Chinese user base, we should really support big5 and its extensions out-right.
Re: std.encoding:2554 - Unrecognized Encoding: big5 - Please help!
https://github.com/dlang/phobos/blob/master/std/net/curl.d#L1197 get!ubyte will disable encoding.
