[Issue 18220] Allow rt_trapexceptions to be set from the CLI
https://issues.dlang.org/show_bug.cgi?id=18220 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18220] Allow rt_trapexceptions to be set from the CLI
https://issues.dlang.org/show_bug.cgi?id=18220 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/6ca77797f1c5c8bede331cff3a4648288386ce02 Fix Issue 18220 - Allow `rt_trapexceptions` to be set from the CLI https://github.com/dlang/druntime/commit/540a6cbafee9847db973f4590d5d5f4bae7aa3b5 Merge pull request #2035 from wilzbach/trap Fix Issue 18220 - Allow `rt_trapexceptions` to be set from the CLI merged-on-behalf-of: Jacob Carlborg --
[Issue 19090] New: core.internal.hash.bytesHash unit test uses incorrect test vector on BigEndian machines
https://issues.dlang.org/show_bug.cgi?id=19090 Issue ID: 19090 Summary: core.internal.hash.bytesHash unit test uses incorrect test vector on BigEndian machines Product: D Version: D2 Hardware: Other OS: All Status: NEW Severity: minor Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com --
New to GDC on ARM 32-bit Ubuntu
I am getting an error when I try and compile anything with the
GDC compiler which is coming up associated with source code
within a D include file which is not one of mine
I am using a Raspberry Pi with Ubuntu 16.04 and have just done an
"apt-get install gdc". Using ldc works fine.
The error is :
root@raspberrypi:~# gdc mac_hex.d -O3 -frelease
/usr/include/d/core/stdc/config.d:58:3: error: static if
conditional cannot be at global scope
static if( (void*).sizeof > int.sizeof )
^
This file has
==
version(Windows)
...
else version( Posix )
{
static if( (void*).sizeof > int.sizeof )
{
etc etc
==
It shows version
gdc --version
gdc (Ubuntu/Linaro 5.3.1-14ubuntu2) 5.3.1 20160413
Copyright (C) 2015 Free Software Foundation, Inc.
So that is unfortunately really old and I would love to get a new
package
Re: Is there any tool that will auto publish my changes.
Thankyou Ali. Timoses. I did try DiamondMVC for a bit, but I found that there is more help out there for Vibe.d. So I reverted back to using that. And the Dependency Injection in Diamond MVC brings all the obscurity that spring has which makes debugging more of a guessing game than a logical derivation. My application isn't that big, so compile times aren't unbearable yet. And server restart, boy server starts under 10 seconds, unimaginable in java world !!! Static files are already reloaded automatically on edit. But edit, compile, restart cycle times do add up over a period. Not to mention the entire process is redundant and therefore a good candidate for automation. Anyway, thankyou for the insight. I'll have to admit I am not equipped with the knowledge to whip something up like that myself (yet ?). Absence of such a tool nevertheless doesn't diminish the pleasure of developing with D, dub, vibe.d, DDBC and HibernateD. Thanks to developers of those tools. Thanks evilrat.
Re: Copy Constructor DIP
On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu > wrote: > > On 7/14/18 5:03 AM, Luís Marques wrote: > >> If there is "no other meaning of @implicit" (other than the > >> intersection of those two properties) why don't you just call > >> it something like @copyctor? > > > > I'm totally cool with giving the attribute a more obscure name > > such as @copyctor or anything people want really. > > > > (What follows is a personal opinion. > > > > I think it's better to choose a more general attribute name > > with reduced initial applicability. Then application of said > > attribute can be extended to other functions with ease. In > > contrast, an obscure attribute name is sure to be followed by > > more obscure attribute names. And don't get me started about > > inventing new syntax. > > > > Regarding the hand-wringing over generality: we have an > > exceedingly poor record of paralysis of analysis, whereby we'd > > worry that every design decision potentially locks us out from > > all other as-of-yet-unchosen design decisions. If history is > > any indication, this sudden worry about vaguely-promising green > > pastures of the future is a sign of malady. We want copy > > construction. Conflating this with a very general schemata for > > implicit conversion would not be a wise decision in my opinion. > > I now deeply regret ever telling Razvan to mention future > > possible directions. This DIP must do implicit copy > > constructors and do it well, nothing less and nothing more.) > > > > > > Andrei > > I think in this case, a more obscure name like @copyctor is more > descriptive. I fear that at some point, a more general attribute > like "@implicit" will turn into the next "static". To me, > @implicit smells like one of those keywords that will grow to > carry many different meanings in different contexts and just end > up overly-broad. > But that's the point, and the key advantage of the name ;)
Re: Copy Constructor DIP
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote: On 7/14/18 5:03 AM, Luís Marques wrote: If there is "no other meaning of @implicit" (other than the intersection of those two properties) why don't you just call it something like @copyctor? I'm totally cool with giving the attribute a more obscure name such as @copyctor or anything people want really. (What follows is a personal opinion. I think it's better to choose a more general attribute name with reduced initial applicability. Then application of said attribute can be extended to other functions with ease. In contrast, an obscure attribute name is sure to be followed by more obscure attribute names. And don't get me started about inventing new syntax. Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. I now deeply regret ever telling Razvan to mention future possible directions. This DIP must do implicit copy constructors and do it well, nothing less and nothing more.) Andrei I think in this case, a more obscure name like @copyctor is more descriptive. I fear that at some point, a more general attribute like "@implicit" will turn into the next "static". To me, @implicit smells like one of those keywords that will grow to carry many different meanings in different contexts and just end up overly-broad. -Jon
Re: Copy Constructor DIP
On 7/16/18 3:12 PM, ag0aep6g wrote: On 07/16/2018 09:06 PM, Andrei Alexandrescu wrote: On 7/14/18 11:26 AM, Jacob Carlborg wrote: [...] That's easily fixed by implementing a compiler recognized UDA. That would mean that it would only be a copy constructor if "implicit" is defined in core.attribute. This would also avoid any special syntax in the parser. The already existing @selector is implemented like this. Affirmative. We're going that route, similar to "@safe" and "@nogc". @safe and @nogc are not compiler recognized UDAs. If you implement @implicit like them, then you're not doing what Jacob suggests. Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/
Re: crash when using in struct constructor
On 07/16/2018 03:08 PM, Eric wrote: This makes the compiler crash. Always a compiler bug: https://issues.dlang.org/show_bug.cgi?id=19089 Ali
[Issue 19089] New: Compiler crash for using struct
https://issues.dlang.org/show_bug.cgi?id=19089
Issue ID: 19089
Summary: Compiler crash for using struct
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: acehr...@yahoo.com
The following code segfaults dmd 2.081.0:
struct List {
private List* l;
this(int x) {
l =
}
}
List ls = 0;
void main() {
}
$ dmd --version
DMD64 D Compiler v2.081.0
[...]
$ dmd deneme.d
Segmentation fault <-- HERE
Forum discussion:
https://forum.dlang.org/post/ivfviezvxxhurymfw...@forum.dlang.org
--
Re: crash when using in struct constructor
On Monday, 16 July 2018 at 22:16:10 UTC, Adam D. Ruppe wrote:
On Monday, 16 July 2018 at 22:08:34 UTC, Eric wrote:
This makes the compiler crash. Is it illegal code?
Yes, a struct can be moved at any time by the compiler which
means pointers to it can be invalidated at random.
Unless you always allocate it externally yourself...
I know that. At the moment I disable the postblit and use an
init():
class Test {
List ls;
this() {
ls.init();
}
}
But I want to be able to write something less verbose like:
class Test {
List ls = 1;
}
And I was hoping a this(int) constructor would happen in place,
not move things around.
Re: crash when using in struct constructor
On Mon, Jul 16, 2018 at 10:08:34PM +, Eric via Digitalmars-d-learn wrote:
> This makes the compiler crash. Is it illegal code?
>
> struct List {
> private List* head;
> private List* tail;
>
> this(int x) {
> head = null;
> tail = // <-- crasher
> }
> }
>
> List2 ls = 2;
It's not illegal per se, but a very, very bad idea in general, because
in D, structs are expected to be int-like POD values that can be freely
copied/moved around by the compiler. More specifically, when structs
are passed into functions or returned from functions, they may be moved
around. Which means internal pointers will wind up being wrong.
This can be somewhat alleviated with a postblit ctor, but it doesn't
cover all the cases, and the above code looks like one of the cases
where it will likely not cover all cases. So yeah, you're probably
getting a dangling pointer because of this.
If you need something that doesn't move around, either allocate the
struct on the heap using `new`, or use classes instead. Note that while
the former will work, it will still require care, because passing the
resulting struct around will pass it by value, and you end up with the
same dangling pointer problem again. So you really want to be using
classes for this.
Or rethink your algorithms so that they don't depend on having internal
pointers.
T
--
Give me some fresh salted fish, please.
Re: crash when using in struct constructor
On Monday, 16 July 2018 at 22:08:34 UTC, Eric wrote: This makes the compiler crash. Is it illegal code? Yes, a struct can be moved at any time by the compiler which means pointers to it can be invalidated at random. Unless you always allocate it externally yourself...
Re: crash when using in struct constructor
Pasted slightly wrong code, last line should be: List ls = 2; Question still stands.
crash when using in struct constructor
This makes the compiler crash. Is it illegal code?
struct List {
private List* head;
private List* tail;
this(int x) {
head = null;
tail = // <-- crasher
}
}
List2 ls = 2;
Re: Completely Remove C Runtime with DMD for win32
On Sunday, 15 July 2018 at 20:29:29 UTC, tcb wrote:
I've been trying to compile a trivial program (extern C int
main() {return 0;}) without linking parts of the C runtime with
no success.
I compile with dmd -debuglib= -defaultlib= -v -L=/INFORMATION
-betterC but optlink shows a lot of things from snn.lib being
pulled in and the resultant executable is about 12kb. I also
replaced object.d with an empty module.
If I pass /nodefaultlib to the linker I get warning 23: no
stack and __acrtused_con is undefined so the linker fails with
no start address.
Is it possible to completely remove the C runtime on windows,
and if so how? Sorry for the sloppily formatted post.
I recently created an issue that included an example that allows
you to compile a Hello World program on linux x64 without the c
standard library, druntime or phobos.
https://issues.dlang.org/show_bug.cgi?id=19078
You can modify it to run on windows as well. I'm not sure if the
_start assembly implementation would be the same on windows. Try
it out and let me know how it works.
Re: Copy Constructor DIP
On 07/16/2018 09:06 PM, Andrei Alexandrescu wrote: On 7/14/18 11:26 AM, Jacob Carlborg wrote: [...] That's easily fixed by implementing a compiler recognized UDA. That would mean that it would only be a copy constructor if "implicit" is defined in core.attribute. This would also avoid any special syntax in the parser. The already existing @selector is implemented like this. Affirmative. We're going that route, similar to "@safe" and "@nogc". @safe and @nogc are not compiler recognized UDAs. If you implement @implicit like them, then you're not doing what Jacob suggests.
Re: Copy Constructor DIP
On 7/14/18 11:26 AM, Jacob Carlborg wrote:
On Friday, 13 July 2018 at 01:18:48 UTC, Andrei Alexandrescu wrote:
On 7/12/18 2:30 PM, ag0aep6g wrote:
You're still potentially changing the semantics of existing code.
`@implicit` can be a UDA today:
enum implicit = 0;
struct C
{
@implicit this(ref C another) {}
}
Today, that's a normal constructor. With the DIP, it becomes a copy
constructor.
That is correct and a liability of the current DIP. That should be
mentioned in it.
That's easily fixed by implementing a compiler recognized UDA. That
would mean that it would only be a copy constructor if "implicit" is
defined in core.attribute. This would also avoid any special syntax in
the parser. The already existing @selector is implemented like this.
Affirmative. We're going that route, similar to "@safe" and "@nogc".
Re: What determines if an algorithm goes in std.algorithm or std.range
On 7/14/18 5:32 PM, aliak wrote: Alo, I'm wondering how phobos devs view or determine what goes in to std.algorithm and what goes in to std.range. To me some of them are quite obvious - well, most things can arguably be an algorithm. But for example "refRange" is clearly a range specific thing, but "transpose" is not. And things that create ranges from nothing also may "clearly" belong in the range module? (e.g. iota, generate and recurrence) Also curious, are there any github PRs in phobos where certain algorithms were discussed as going in to where and what the reasonings were? cheers - Ali There is no hard and fast rule. If it does something one would naturally associate with an algorithm (e.g. it would belong in a book on algorithms etc), it belongs in std.algorithm even if it processes ranges. If something is algorithmically trivial but support ranges, then it belongs in std.range. Without looking: where should "chain" belong? It's a trivial algorithm but has a variety of intricacies for supporting different kinds of ranges. So it's in std.range. Andrei
Re: CJK problem when using console outputs
On 07/16/2018 11:30 AM, zhani wrote:
i got some problem about using CJK in windows10 console.
here my code(a code file encoded the utf-8):
--
import std.stdio;
/*
static this(){
core.stdc.wchar_.fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)"korea");
}*/
void main()
{
writeln("Allo");
writeln("こんにちは"); // C
writeln("你好"); // J
writeln("안녕하세요"); // K
}
--
and nice result on windows(cmd and powershell):
--
Allo
?볝굯?ャ걾?
鵝졾?
?덈뀞?섏꽭?
--
Try this:
import std.stdio: writeln;
import std.exception: enforce;
import core.sys.windows.windows: CP_UTF8, SetConsoleOutputCP;
void main()
{
SetConsoleOutputCP(CP_UTF8).enforce;
writeln("Allo");
writeln("こんにちは");
writeln("你好");
writeln("안녕하세요");
}
Re: @safe - why does this compile?
Johan Engelen wrote: On Friday, 13 July 2018 at 14:51:17 UTC, ketmar wrote: yeah. in simple words: safe code is *predictable*, but not "segfault-less". segfaults (null dereferences) in safe code are allowed, 'cause they have completely predictable behavior (instant program termination). @safe doesn't free you from doing your null checks, it protects you from so-called "undefined behavior" (aka "unpredictable execution results"). so when we are talking about "memory safety", it doesn't mean that your code cannot segfault, it means that your code won't corrupt random memory due to misbehaving. This is not true when using LDC (and I'd expect the same for GDC). With LDC, dereferencing `null` is undefined behavior regardless of whether you are in an @safe context or not. - Johan p.s.: it worth noting that *program* *state* is undefined after null dereference, though. i.e. program cannot continue execution, and must be aborted. in this sense, null dereferencing is defined behavior: it aborts the app unconditionally. and if you will catch segfault with some OS mechanics, you still cannot reliably do *anything* except immediately aborting (strictly speaking, this is true for any `Error` condition, even for asserts). so compiler *can* assume that null dereferencing is something code generally won't do, but it cannot do any optimisations assuming that code will not dereference nulls at all (dmd -O, afair, was guilty of some such optimisations too). so, code can dereference null, and it will be immediately aborted, without any chance to perform cleanup (as program state is undefined after this operation). in this sense, null dereferencing is "defined behavior".
Re: @safe - why does this compile?
Johan Engelen wrote: On Friday, 13 July 2018 at 14:51:17 UTC, ketmar wrote: yeah. in simple words: safe code is *predictable*, but not "segfault-less". segfaults (null dereferences) in safe code are allowed, 'cause they have completely predictable behavior (instant program termination). @safe doesn't free you from doing your null checks, it protects you from so-called "undefined behavior" (aka "unpredictable execution results"). so when we are talking about "memory safety", it doesn't mean that your code cannot segfault, it means that your code won't corrupt random memory due to misbehaving. This is not true when using LDC (and I'd expect the same for GDC). With LDC, dereferencing `null` is undefined behavior regardless of whether you are in an @safe context or not. - Johan then those compilers are broken, and should be fixed.
Re: @safe - why does this compile?
On Friday, 13 July 2018 at 14:51:17 UTC, ketmar wrote: yeah. in simple words: safe code is *predictable*, but not "segfault-less". segfaults (null dereferences) in safe code are allowed, 'cause they have completely predictable behavior (instant program termination). @safe doesn't free you from doing your null checks, it protects you from so-called "undefined behavior" (aka "unpredictable execution results"). so when we are talking about "memory safety", it doesn't mean that your code cannot segfault, it means that your code won't corrupt random memory due to misbehaving. This is not true when using LDC (and I'd expect the same for GDC). With LDC, dereferencing `null` is undefined behavior regardless of whether you are in an @safe context or not. - Johan
Re: Anyone can contact Dmitry Olshansky?
On Tuesday, 3 July 2018 at 07:31:46 UTC, Nick Sabalausky (Abscissa) wrote: On 07/01/2018 05:34 AM, ag0aep6g wrote: On 07/01/2018 08:00 AM, Ali Çehreli wrote: Apparent from uncharacteristic messages from Dmitry's account to multiple destinations recently, I suspect his gmail account has been compromised. Could also be a psychotic episode or some such. The incoherent rambling doesn't seem to be just bad English. You've got stuff like "I can save the world" in there, which sounds more like mental illness than an imposter to me. If someone's going around as an imposter on a web forum, I'd say it's pretty clear that in and of itself indicates SOME form of mental illness, even if the illness is something as basic and simple as "idiot" and "jackass". We already know we've had a problem with a puppet whackjob here lately. Occam's Razor suggests it's likely just more of the same nut. Over-analysing unlikely scenarios is only going to encourage more. It's also known that mental illness readily stems from paranoia and believing others are mentally ill and out to get them in some way shape or fashion. Probably comes from primitive circuitry that hasn't yet been eliminated evolution wise(after all, modern societies have only existed for a few hundred years... lot's have changed but the brain has yet to evolve to handle those changes). After all, I'd say that a society that has developed weapons that can only be used to destroy itself requires a massive amount of mental illness... of course, they disagree, so maybe mental illness is actually relative. It's known quite well that most people who work in the mental illness sector are also mentally ill themselves(I guess it's hard not to go crazy when everyone else is).
Re: Anyone can contact Dmitry Olshansky?
On Monday, 16 July 2018 at 15:07:20 UTC, rikki cattermole wrote: On 17/07/2018 2:45 AM, Ali wrote: Do we have any updates on Dmitry was anyone able to check on him I hope he is doing better Nope, appears he's gone. I think something happened. He do not getting online since 01.07.2018. Last time when we met (before one week of this) he was very optimistic and planed to develop some tool for a job in D.
Re: Anyone can contact Dmitry Olshansky?
On 17/07/2018 2:45 AM, Ali wrote: Do we have any updates on Dmitry was anyone able to check on him I hope he is doing better Nope, appears he's gone.
Re: Anyone can contact Dmitry Olshansky?
Do we have any updates on Dmitry was anyone able to check on him I hope he is doing better
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Friday, 13 July 2018 at 19:53:45 UTC, Laeeth Isharc wrote: On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: What are your ideas? If you would like to expose C function and type declarations to D, you could take a look at DPP, which allows you to just #include a C header. If you encounter a bug, please file an issue and in time we will fix it. Does not yet work for C++ except in some cases. https://github.com/atilaneves/dpp I would like to give this a try, but I don't see any instructions for installation on the Github page. I tried dub build dpp, but I got a bunch of error messages.
Re: Safe Memory Management and Ownership.
On Friday, 13 July 2018 at 20:03:37 UTC, jmh530 wrote: On Friday, 13 July 2018 at 17:12:26 UTC, Atila Neves wrote: [...] Hmm, thinking on this a little more...it does seem difficult...but I don't think the problem is with immutable borrows. I think the issue is with the exclusivity of Rust's borrowing. [...] You can probably finagle around with compile-time and get similar semantics, but after certain point you would need compiler help it seems like.
[Issue 18620] `error cannot be interpreted at compile time` is missing context where error occurs
https://issues.dlang.org/show_bug.cgi?id=18620 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote: On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote: On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote: Why does this fail? It doesn't. Not using DMD 2.081.1 under Windows, at least. I tried adding a bitfield since you mentioned it, but it compiles nicely for me. Which version of DMD are you using, and are you having the issues with the exact code you posted here? -- Simen https://run.dlang.io/is/Pgs527 I'm on 2.080.1. But above is on latest 2.081.1 I believe. Note that the bottom code snippet in the original post does work, while the first one does not. Yep, run.dlang.io automatically updates itself to the latest compiler (you can check this e.g. with -v).
[Issue 18620] `error cannot be interpreted at compile time` is missing context where error occurs
https://issues.dlang.org/show_bug.cgi?id=18620 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/304850d8810f937360a0c1391cb278248cb28f4f Fix Issue 18620 - error cannot be interpreted at compile time is missing context where error ocurrs https://github.com/dlang/dmd/commit/1e73e07467beff5bd48abe0df69e66135e2f9fd2 Fix Issue 18620 - error cannot be interpreted at compile time is missing context where error occurs https://github.com/dlang/dmd/commit/4cc487f1edb3ed1e91ec94c98407384d3e372ae8 Merge pull request #8049 from RazvanN7/Issue_18620 Fix Issue 18620 - error cannot be interpreted at compile time is missing context where error occurs --
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Monday, 16 July 2018 at 13:15:56 UTC, Timoses wrote: On Monday, 16 July 2018 at 11:31:32 UTC, Seb wrote: On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote: On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote: I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else. Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you! https://github.com/Ace17/dscriptenQ/issues/4 Superfluous Q attack. Working link: https://github.com/Ace17/dscripten/issues/4 Sorry for the typo (not sure how that happened) and thanks for correcting!
Re: std.experimental.allocator and const etc.
On Sunday, 15 July 2018 at 13:06:16 UTC, John Colvin wrote:
Currently the API's don't support const(void)[], e.g.
import std.experimental.allocator : makeArray, theAllocator,
dispose;
import std.experimental.allocator.mallocator : Mallocator;
void main()
{
const a = theAllocator.makeArray!ubyte(100);
theAllocator.dispose(a);
// can't call RCIAllocator.deallocate(void[] b) with
const(ubyte)[]
const(void)[] b = Mallocator.instance.allocate(100);
Mallocator.instance.deallocate(b);
// can't call Mallocator.deallocate(void[] b) with
const(void)[]
}
Is this deliberate? It's pretty annoying.
Probably not, the lifetime of the referenced memory is over.
There's a couple of other places where we cast away const and
shared before destroying and object.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Monday, 16 July 2018 at 11:31:32 UTC, Seb wrote: On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote: On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote: I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else. Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you! https://github.com/Ace17/dscriptenQ/issues/4 Superfluous Q attack. Working link: https://github.com/Ace17/dscripten/issues/4
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote: On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote: Why does this fail? It doesn't. Not using DMD 2.081.1 under Windows, at least. I tried adding a bitfield since you mentioned it, but it compiles nicely for me. Which version of DMD are you using, and are you having the issues with the exact code you posted here? -- Simen https://run.dlang.io/is/Pgs527 I'm on 2.080.1. But above is on latest 2.081.1 I believe. Note that the bottom code snippet in the original post does work, while the first one does not.
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote: Why does this fail? It doesn't. Not using DMD 2.081.1 under Windows, at least. I tried adding a bitfield since you mentioned it, but it compiles nicely for me. Which version of DMD are you using, and are you having the issues with the exact code you posted here? -- Simen
Implicit conversion of struct with methods to immutable in pure function fails
Why does this fail?
struct F
{
int i;
ushort _x;
void x(ushort v) pure
{_x = v;}
ushort x() const
{ return _x; }
}
immutable F f1 = () pure {
F lf = F();
return lf; }();
// Error: cannot implicitly convert expression delegate () =>
lf() of type F to immutable(F)
F makeF() pure
{
F lf = F();
return lf;
}
immutable F f2 = makeF();
// Error: cannot implicitly convert expression makeF() of
type F to immutable(F)
Removing the methods in struct F compiles fine.
Background: I have a mixin(bitfields!(...)) in the struct which
utilizes member functions.
/
Idea:
Just found out that it works when making the struct static. But
why does that help?
Is it because the compiler wouldn't be able to check whether
methods in the struct are accessing non-immutable data in the
enclosing context?
That would not make much sense though because the following works:
// Compiles fine!
int modi = 3;
void main ()
{
static struct F
{
int var() immutable { return modi; } // accessing modi
from module scope
}
immutable f = () pure { F f = F(); return f; }();
}
So my explanation wouldn't make sense, since why would it be okay
to use module-scope data and not enclosing context data?
So where does that limitation come from that I implicitly convert
a nested struct to immutable in a pure function?
[Issue 19082] Cannot inline "...Slides.numberOfFullFrames", "...Slides.gap"
https://issues.dlang.org/show_bug.cgi?id=19082 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #4 from Seb --- I'm sorry, but I can't reproduce this: https://run.dlang.io/is/W8BEnJ https://run.dlang.io/is/mHxy3W Have you tried DustMite? --
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Monday, 16 July 2018 at 11:12:20 UTC, Dukc wrote: On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote: I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else. Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you! https://github.com/Ace17/dscriptenQ/issues/4
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Saturday, 14 July 2018 at 03:08:50 UTC, Vladimir Panteleev wrote: I'll follow up with Alawain. Regardless, dscripten-tools borrows very little from the redistributable parts of dscripten - mostly the "minimalistic runtime", which I think was itself borrowed from somewhere else. Indeed, it appears Alawain himself just changed the runtime part to be boost! If he is reading this, thank you!
Re: CJK problem when using console outputs
On Monday, 16 July 2018 at 09:30:22 UTC, zhani wrote:
howdy :-)
i got some problem about using CJK in windows10 console.
[...]
oh, sorry for my mistake. here:
--
writeln("你好"); // C
writeln("こんにちは"); // J
writeln("안녕하세요"); // K
--
Re: Is there any tool that will auto publish my changes.
On Monday, 16 July 2018 at 08:28:06 UTC, Timoses wrote: On Sunday, 15 July 2018 at 00:25:22 UTC, Venkat wrote: [...] I don't believe there currently exists a tool to rebuild the Diet templates on the fly. The Diet templates require a step during compilation (I think), so that the entire application has to be rebuilt (at least the part that has the diet templates). If you have a large project, what I've heard from others what they do, is split the project into smaller pieces and can therefore have shorter compilation times [1]. There's also DiamondMVC which you could try depending on your use case [2], though I haven't tried it out myself. [1] https://forum.dlang.org/post/txgoxzroscysfbvio...@forum.dlang.org [2] https://github.com/DiamondMVC/Diamond There's this open issue in the vibed repo as well -> https://github.com/vibe-d/vibe.d/issues/676 and a script in the comments that may help what I have not tried out. Cheers, - Ali
CJK problem when using console outputs
howdy :-)
i got some problem about using CJK in windows10 console.
here my code(a code file encoded the utf-8):
--
import std.stdio;
/*
static this(){
core.stdc.wchar_.fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)"korea");
}*/
void main()
{
writeln("Allo");
writeln("こんにちは"); // C
writeln("你好"); // J
writeln("안녕하세요"); // K
}
--
and nice result on windows(cmd and powershell):
--
Allo
?볝굯?ャ걾?
鵝졾?
?덈뀞?섏꽭?
--
wow, very cool. see, wolrd-wise came here on dmd.
In fact, when i using dmd that older version, i solved this
problem with a cheated a way like this:
--
static this(){
core.stdc.wchar_.fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)"korea");
}
--
but the 'dmd v2.081.1' didnt want this.
i guess, because a core package is invisiable now. yap.
how can i solve this problem using clean a way?
thanks.
[Issue 19088] I am working with the package tinyredis 2.1.1 and I can't compile, dmd exit with exit code 1 because EWOULDBLOCK is not defined
https://issues.dlang.org/show_bug.cgi?id=19088 Seb changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #1 from Seb --- This looks like a problem with the library, not DMD. For a good bug report, we would need to have a minimal reproducible example (try dustmite) that typically is a few lines without dependencies on external projects. Sorry, but you might have a look at other redis projects in the meantime. Vibe.d has redis support for example. --
Re: UFCS confusion
On Friday, 13 July 2018 at 11:37:09 UTC, Michael wrote: On Friday, 13 July 2018 at 11:17:32 UTC, Radu wrote: On Friday, 13 July 2018 at 11:12:47 UTC, Michael wrote: On Friday, 13 July 2018 at 10:52:54 UTC, Radu wrote: On Friday, 13 July 2018 at 10:21:54 UTC, Michael wrote: [...] Do you try to call member functions? UFCS only works with free functions, meaning declared at module level. https://dlang.org/spec/function.html#pseudo-member I'm not intentionally trying to call member functions, no. The functions are all static functions of a class, but the chaining of them using UFCS doesn't seem to work. OK, static functions of a class are static *member* functions, they are not free functions. Oh, really? Well that will explain it then. I was sure I had used this syntax before but perhaps not. Thanks for your help! try this: import std.functional : pipe; createVector(langSize, index).pipe!createSet.length;
Re: I have a plan.. I really DO
On Monday, 16 July 2018 at 07:49:33 UTC, Kagamin wrote: On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote: If there is a language out there that gaps that C/Java/dynamic fast and easy feel, and offers the ability to compile down with ease. I have not seen it. There's no silver bullet, you can choose from what exists or create your own. If D could be used with automatic reference counting (with native weak references with OPTIONAL automatic cycle collection), while remaining easy to interoperate with C++, that could be a good candidate... I mean having something like that : T* pointer on any type (scalar, struct, class) T strong reference on a class T^ weak reference on a class And have --arc and --acc as compiler options. PS: I know this won't happen unless I implement it myself, I got the message... ;)
Re: REPL semantics
On Thursday, 12 July 2018 at 22:17:29 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 21:51:18 UTC, aliak wrote:
Cool, is there on going work to sprucing up the D repl in the
dlang-community repo or is this a new attempt? Either way if
something is happening here then awesome!
Ah, that explains why my clone of drepl didn't compile: it was
the Martin Novak's repo, not the D community one. Although on
macOS it still doesn't compile, because of the lack of
_rt_loadLibrary.
Regarding your question: I was investigating this as part of my
own D-related compiler efforts (DHDL stuff), but it won't
materialize into a D repl anytime soon. I actually never tried
the existing REPLs, what are your issues with them?
Ah I see. Last I remember it was just too buggy to use so it
caused more pain than pleasure :p I don't remember the exact
details though sorry.
As for your question, hard to say me thinks. On the one hand,
being able to do this is nice:
const int i = 3;
const int j = 4;
void complexCalculation() { use i and j }
complexCalculation() // uses 3 and 4
const int j = 5;
complexCalculation // uses the new j
On the other hand being able to redefine the name "j" as some
other type to use in some other computation without having
`complexCalculation` get messed up is also nice :)
I hadn't even considered *redefining* symbols, only
overloading. cling doesn't support redefining. Mmmm...
Which is how the swift repl works:
1> func f(_ a: Float) { print("f") }
2> f(3)
f
3> func f(_ a: Int) { print("i") }
4> f(3)
i
5> func foo(_ a: Float) { print("f") }
6> func bar() { print(foo(3)) }
7> bar()
f
8> func foo(_ a: Int) { print("i") }
9> bar()
f
Yeah, I had tried basically the same Swift example. But my
point stands: I think that behavior can be explained by ease of
implementation. Finding an example of the alternative would be
much more interesting. Lacking that we are going to have to
actually *think* about the problem ;-)
The examples with the dynamic languages are less relevant.
We can try and think:
So if we think of adding an overload as "redefining a name" then
is it fair to generalize the question to: "should redefining
symbol A affect any previously defined symbol B that was
dependent on the previous definition of A?"
And then I'd say that defining an overload of symbol A is
technically a redefining of A - i.e. it's semantics change.
Redefinition affects:
+ Can change functionality of B without having to redefine all of
it
- Can cause things to stop working silently (think a tree of
hidden dependencies)
Redefinition does not affect:
+ The last defined symbol works "as expected"
- Must redefine symbols if you want them to use redefined
dependent definitions.
I think changing the value of a variable should affect any
dependent definitions, while redefining a variable should not
affect dependent symbols - an appeal to predicability is what I'm
going for.
And I think defining an overload falls under redefining a symbol.
Or you can also have the best of both worlds if you allow a
special repl annotation before any definitinons - @dynamic on
symbol A can mean that redefining it will affect dependent
Symbols for e.g.
Haskell's GHCi repl does the same as swift (with redefining
symbols at least, don't think it supports overloading in the
imperative language sense of the term). Though I think that makes
the most sense for haskell being a pure language.
Cheers,
- Ali
[Issue 19088] New: I am working with the package tinyredis 2.1.1 and I can't compile, dmd exit with exit code 1 because EWOULDBLOCK is not defined
https://issues.dlang.org/show_bug.cgi?id=19088 Issue ID: 19088 Summary: I am working with the package tinyredis 2.1.1 and I can't compile, dmd exit with exit code 1 because EWOULDBLOCK is not defined Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: jakez.roll...@gmail.com I am working with the package tinyredis 2.1.1 and I can't compile, dmd exit with exit code 1 because EWOULDBLOCK is not defined C:\Users\jakez\AppData\Local\dub\packages\tinyredis-2.1.1\tinyredis\source\tinyredis\connection.d(145,30): Error: undefined identifier EWOULDBLOCK dmd failed with exit code 1. I signaled it to the tinyredis developer too. I hope this will help --
Re: Is there any tool that will auto publish my changes.
On Sunday, 15 July 2018 at 00:25:22 UTC, Venkat wrote: I am writing a simple vibe.d app. The following is what I do right now. - I make changes. - build - Restart the server. Is there any tool that will auto publish my changes as I save them ? I am using Visual Studio Code. Thanks Venkat I don't believe there currently exists a tool to rebuild the Diet templates on the fly. The Diet templates require a step during compilation (I think), so that the entire application has to be rebuilt (at least the part that has the diet templates). If you have a large project, what I've heard from others what they do, is split the project into smaller pieces and can therefore have shorter compilation times [1]. There's also DiamondMVC which you could try depending on your use case [2], though I haven't tried it out myself. [1] https://forum.dlang.org/post/txgoxzroscysfbvio...@forum.dlang.org [2] https://github.com/DiamondMVC/Diamond
[Issue 19082] Cannot inline "...Slides.numberOfFullFrames", "...Slides.gap"
https://issues.dlang.org/show_bug.cgi?id=19082
--- Comment #3 from Mitu ---
OK, I managed to find a minimal example. The code below builds properly for
debug build, but fails with the release build.
==
/+ dub.sdl: name "main" +/
import std.algorithm;
import std.range;
void main()
{
[1].map!(x => x).slide(2);
}
==
Replacing .map!(x => x) with .map!"a" makes the code code work strangely.
--
[Issue 19082] Cannot inline "...Slides.numberOfFullFrames", "...Slides.gap"
https://issues.dlang.org/show_bug.cgi?id=19082
--- Comment #2 from Mitu ---
OK, I managed to find a minimal example. The code below builds properly for
debug build, but fails with the release build.
=
/+ dub.sdl: name "main" +/
import std.algorithm;
import std.range;
void main()
{
[1].map!(x => x).slide(2);
}
===
Replacing .map!(x => x) with .map!"a" makes the code code work strangely.
--
Re: I have a plan.. I really DO
On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote: If there is a language out there that gaps that C/Java/dynamic fast and easy feel, and offers the ability to compile down with ease. I have not seen it. There's no silver bullet, you can choose from what exists or create your own. Recently we got a CI service that tests some packages from dub, that should deal with regressions.
Re: Is there any tool that will auto publish my changes.
On Sunday, 15 July 2018 at 00:25:22 UTC, Venkat wrote: I am writing a simple vibe.d app. The following is what I do right now. - I make changes. - build - Restart the server. Is there any tool that will auto publish my changes as I save them ? I am using Visual Studio Code. Thanks Venkat I don't think there are ready to use tools exists. But you can try to making (simple) one for your needs, for example using this package[1] to track file changes, then kill running instance, build and restart. Or doing the same with python/java/c#/whatever [1] https://code.dlang.org/packages/fswatch
