On Sunday, 29 September 2019 at 11:36:00 UTC, aberba wrote:
I have no idea how to do that from D. Any help/resources on
that?
You should be able to use the techniques at
https://dlang.org/spec/interfaceToC.html to declare the C
functions that you wish to use in your *.d source files, and
On Wednesday, 25 September 2019 at 23:56:45 UTC, aberba wrote:
I'm looking for resources on using D for basic Raspberry Pi
programming...stuff like turning on and off an LED light. I
believe it requires being able to call the Raspberry OS core
APIs from D as available in Python.
Anyone here
On Tuesday, 27 August 2019 at 17:11:33 UTC, Mike Franklin wrote:
If you look at the vibe.d compile-time graph, you'll see
there's a 2.5s increase around Mid-2014.
Sorry, that should be Mid-2015.
On Tuesday, 27 August 2019 at 12:58:20 UTC, Vladimir Panteleev
wrote:
It will eventually zero in to commit-level accuracy after it's
been running for a while. I cleared the database as the last
time it was running, it was on another CPU, so the timings are
going to be different. (Still need
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev
wrote:
Here's the original blog post:
https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/
I'll give it a kick and get it back online if there is
interest. Seems wasteful to reimplement it from scratch, though.
It's great
On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote:
There's probably at least one bug report on it, but as I
understand it, it's not a bug in the sense that the
implementation is currently expected to handle such a case.
It's an area where betterC should be improved upon, but
On Thursday, 25 July 2019 at 12:01:40 UTC, Oleg B wrote:
Hello everyone!
I try build this code with betterC
import core.stdc.stdio;
import std.format : format;
extern(C) int main()
{
mixin(format!`enum str = "%s\0";`("hello"));
fprintf(stderr, "%s\n", str.ptr);
return 0;
}
but
On Wednesday, 17 July 2019 at 13:56:38 UTC, RazvanN wrote:
We have encouraged the graduating students to participate to
SAOC and also we are in discussions with some of them to
initiate them into contributing to D.
And we'd love to have them. "Well done!" to everyone involved.
Mike
On Monday, 15 July 2019 at 14:58:55 UTC, Mike Parker wrote:
In the Draft Review for Walter's DIP, Argument Ownership and
Function Calls (which in the next half hour or so will be
starting a community review as DIP 1021), some folks asked for
some information about the bigger picture. In
On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
We are trying to implement many of those `extern(C)` runtime
hooks as templates. Those templates need to be implicitly
imported through object.d. That means code that was in `rt`
is converted to a template, and then moved to
On Monday, 15 July 2019 at 13:06:58 UTC, Vladimir Panteleev wrote:
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote:
... and are the exception, not the rule. I believe they
should be moved to `rt`.
BTW, from this discussion it seems to me that you did not have
a good overview of
On Monday, 15 July 2019 at 12:27:22 UTC, Vladimir Panteleev wrote:
This isn't exactly true. The restriction is that core should
not *import* rt. Have a look at all the extern(C) definitions
in Druntime - using extern(C) functions to communicate between
the compiler and rt, as well as core and
On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev wrote:
- core.internal.hash contains the implementation of hashing
routines used for associative arrays.
- core.internal.arrayop contains the implementation of array
vector operations. This one doesn't seem to be too far from
your
On Monday, 15 July 2019 at 12:19:02 UTC, Vladimir Panteleev wrote:
You don't need to move the implementations themselves into
core.internal. Adding declarations there for the rt
implementations would suffice.
Many of the implementations in `rt/array` are templates, so the
entire
On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote:
I think that fits core.internal better than rt. Have you
considered that during said discussion?
The implementations in `rt/array` contain templates that are
ports of runtime hooks that used to reside in `rt`. The
implementations also
On Monday, 15 July 2019 at 10:52:08 UTC, Vladimir Panteleev wrote:
On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote:
The copy should take place when building druntime from the
makefiles. The files to be copied are listed at
On Sunday, 14 July 2019 at 17:00:53 UTC, Patrick Schluter wrote:
DWT doesn't build anymore with the new compiler. Wasn't DWT
supposed to be part of the build job of compiler so that
regressions are caught in time?
It's not a regression; deprecations are a normal progression for
evolving the
On Thursday, 4 July 2019 at 12:48:15 UTC, Robert M. Münch wrote:
So, the problem is, that digger somehow misses to copy over the
new source to the install directory. It does for some parts
(phobos, but I'm not sure if for every file necessary) but not
for druntime files.
I just manually
On Thursday, 4 July 2019 at 10:01:10 UTC, Robert M. Münch wrote:
On 2019-07-04 08:11:26 +, Martin Nowak said:
Glad to announce D 2.087.0, ♥ to the 63 contributors.
This release comes with types matching single template alias
parameters,
nested template methods/local template functions,
On Saturday, 25 May 2019 at 21:56:57 UTC, Murilo wrote:
Sorry people
It's ok. I know you meant well, and we're happy to have people
in this community so passionate about D.
Mike
On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote:
On the 6th of June(6/6) we celebrate the D day on Normandy, but
I have decided to turn it into our own holiday to celebrate the
D language.
I'm sure you mean well, but I will be spending D-Day remembering
the sacrifice of these men:
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote:
I'd been holding off on announcing this until DIP1008 actually
got implemented, and now it has:
https://code.dlang.org/packages/nogc
This dub package has a @nogc version of `std.conv.text` (which
probably isn't as good yet) that,
On Friday, 17 May 2019 at 20:59:43 UTC, Mike Franklin wrote:
I don't think it does because `Queue!(T).store` has infinite
lifetime beyond that of even `main`, at least as far as the
compiler is concerned. The compiler doesn't have enough
information to know that `store` is tied to the
On Friday, 17 May 2019 at 17:03:51 UTC, Meta wrote:
If you look at `main` above, `rawData` has the same lifetime as
the `dataRange` struct returned from `makeDataRange` and the
queue returned from `copyToQueue`. True, there is some
traditionally unsafe stuff happening in between; however, I
On Thursday, 16 May 2019 at 12:16:26 UTC, Marco de Wild wrote:
Or are there any tips to roll my own implementation?
I took a stab at it:
---
@nogc:
nothrow:
pure:
struct NoGcArray(size_t maxSize, T)
{
private T[maxSize] _buffer;
private T[] _slice;
private size_t _frontIndex;
On Friday, 17 May 2019 at 05:22:30 UTC, Mike Franklin wrote:
My assessment (which could be wrong):
`scope` and `return` only apply to pointers and `ref`s. If you
remove all `scope` and `return` attributes from the function
`push`, it works fine.
I consider it a bug that the compiler
On Friday, 17 May 2019 at 04:50:52 UTC, Meta wrote:
Walter, can I get you to take a look at this post I made a few
months ago, and the contained example? I feel that this is a
case that *should* definitely work, but I'm not sure if it can
*currently* work - and so far, nobody else seems to be
On Wednesday, 15 May 2019 at 01:15:43 UTC, Andrei Alexandrescu
wrote:
That we even discuss just how bad bool is while we have no done
deals for safety, reference counting, shared, package
distribution/versioning, pay-as-you-go runtime, collections,
..., is a fascinating puzzle.
It can all
On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu
wrote:
There are many clowny things in D, of which bool is at best
somewhere beyond the radar. I suggest investing time *
expertise in the larger ones.
Once again, I disagree with what you think is important. `bool`
is a
On Tuesday, 14 May 2019 at 15:40:19 UTC, Kagamin wrote:
On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky
(Abscissa) wrote:
All this effort strongly implies that there's no such thing as
a satisfactory bool type *in languages which conflate booleans
with integers*
FWIW I write C# for
On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:
Sure it is convenient to have some properties of bool also be
similar to an integer, but it can definitely not be swapped in
to be used like a 1-bit integer and there are already plenty of
special rules for it.
Thanks for that analysis.
On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:
Regarding the discussion of how bool is handled...
It's a one bit integer so it should behave like a one bit
integer
https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s
I think Walter is conflating how bool is stored in memory with
On Saturday, 11 May 2019 at 05:39:12 UTC, H. S. Teoh wrote:
So potentially a D-based memcpy could have multiple concrete
implementations (copying strategies) that are statically chosen
based on the properties of T, like alignment and size.
Exactly.
[...]
However, DMD won't do the right
On Saturday, 11 May 2019 at 00:32:54 UTC, H. S. Teoh wrote:
When it comes to performance, I've essentially given up looking
at DMD output. DMD's inliner gives up far too easily, leading
to a lot of calls that aren't inlined when they really should
be, and DMD's optimizer does not have loop
On Saturday, 11 May 2019 at 00:09:08 UTC, Mike Franklin wrote:
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
I'm not 100% sure it's a good idea to implement memcpy in D
just to prove that it can be done / just to say that we're
independent of libc. Libc implementations of
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
I'm not 100% sure it's a good idea to implement memcpy in D
just to prove that it can be done / just to say that we're
independent of libc. Libc implementations of fundamental
operations, esp. memcpy, are usually optimized to next week
On Friday, 10 May 2019 at 17:55:53 UTC, Johan Engelen wrote:
Why would you use inline assembly ? (generalizing but:
extremely bad portability, bad performance, bad readability)
The only reason to use inline assembly is to achieve something
that can't be achieved directly with D. For
On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote:
- Memcmp, memcpy, memmove and memset are named equal, copy,
copyBackward and fill respectively. I just wanted to create
native implementations that are bit safer than their C
counterparts. So they do the same job, but accept void[]
On Thursday, 9 May 2019 at 07:45:41 UTC, Andrei Alexandrescu
wrote:
Just checked, it works:
https://youtu.be/Vj6jNAlv03o
Thank You!
On Wednesday, 8 May 2019 at 08:21:33 UTC, Thomas Brix Larsen
wrote:
I am able to join with Firefox. I can see the video, but no
audio. I'm still troubleshooting.
Mike
I had to click Audio Connection -> Computer to get audio.
You mean the "Call using computer" option. That gives me an
On Wednesday, 8 May 2019 at 08:00:15 UTC, Andrej Mitrovic wrote:
On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote:
The venue uses WebEx for livestreaming. All the information is
available in this PDF:
https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I
"When
On Sunday, 5 May 2019 at 05:23:26 UTC, Eugene Wissner wrote:
you may remember that I'm working on a library named "tanya"
(https://github.com/caraus-ecms/tanya). It is now almost
phobos-free and I reimplemented some routines from libc for
x86-64 linux. Ideally I'd like to get rid of libc for
On Monday, 22 April 2019 at 12:24:16 UTC, Mike Parker wrote:
To coincide with the announcement of DStep 1.0.0, Jacob
submitted a post to the D Blog that goes into detail on all the
new stuff included in this release.
The blog:
https://dlang.org/blog/2019/04/22/dstep-1-0-0/
Reddit:
On Friday, 12 April 2019 at 17:55:28 UTC, Piotrek wrote:
Coding guidelines like MISRA and AUTOSAR have been developed
and matured for C++ for years. There is no equivalent for D
for it to be even considered by the automotive industry.
Well, MISRA is an evidance that C (C++) is quite error
On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote:
Do @property attributes not allow postincrement operators?
import std.stdio;
struct Foo {
@property bar() { return 10; }
@property bar(int x) { writeln(x); }
}
void main()
{
Foo foo;
writeln(foo.bar); // actually calls
On Thursday, 21 March 2019 at 22:51:21 UTC, James Blachly wrote:
Thanks -- I also tried to figure out how to install GDC just
yesterday and gave up. All wiki links and google top results
seemed dead ends.
I'm also a little puzzled by how GDC is structured, but I have
learned a few things
On Wednesday, 13 February 2019 at 22:29:18 UTC, solidstate1991
wrote:
When I tried to apply to a position at Symmetry, I've got a
criticism from Atila Neves that some of my code relied too much
on memcpy, thus making it unsafe. After digging into std.array,
I found some function that could
On Saturday, 26 January 2019 at 10:24:05 UTC, Sebastiaan Koppe
wrote:
Spasm is a betterC library for web development that uses LDC to
compile to WebAssembly, and I just released a major update.
It now has bindings to most web api's, like the dom, fetch,
audio, webgl, etc.
[...]
See the
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:
When something like an object system is made part of the
language (or at the very least, the standard library), it
becomes a focal point [2] that the community can coordinate
around. Due to the diverse, distributed nature of any
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu
wrote:
https://youtube.com/watch?v=tcyb1lpEHm0
I especially like how design by introspection was contrasted with
concepts and metaclasses, culminating in "We want to generate
more smart code, not more boilerplate. We want to
On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven
Schveighoffer wrote:
@property: This was almost about to be awesome, but squabbling
amongst the D core team killed it.
Yes, the problem with @property is that it is neither correctly
implemented nor completely implemented. And to do the
On Monday, 10 December 2018 at 18:27:48 UTC, Neia Neutuladh wrote:
I wrote a post about language-agnostic (or, more accurately,
cross- language) build tools, primarily using D as an example
and Dub as a benchmark.
Spoiler: dub wins in speed, simplicity, dependency management,
and actually
On Sunday, 11 November 2018 at 23:40:16 UTC, Walter Bright wrote:
As:
https://github.com/dlang/dmd/pull/8946
removes the header files for the old C++ code!
This is a significant milestone. Congratulations, Walter!
There are still a few .c files in
On Monday, 29 October 2018 at 03:43:49 UTC, Mike Parker wrote:
Congratulations are in order for Iain Buclaw. His efforts have
been rewarded in a big way. Last Friday, he got the greenlight
to move forward with submitting his changes into GCC:
Congratulations! Iain. It's an extraordinary
On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson
wrote:
On Friday, 14 September 2018 at 13:41:40 UTC, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from
integer and character literals to bool", is now ready for
Final Review. This is a last chance for
On Saturday, 15 September 2018 at 20:07:06 UTC, Steven
Schveighoffer wrote:
Looks pretty good to me. The only question I have is on this
part:
enum YesNo : bool { no, yes } // Existing implementation: OK
// After stage 1: Deprecation
warning
On Wednesday, 5 September 2018 at 07:00:49 UTC, 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
On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc
wrote:
$500.00 to fix these three together - they may well be
essentially the same bug:
https://issues.dlang.org/show_bug.cgi?id=19179
https://issues.dlang.org/show_bug.cgi?id=5570
https://issues.dlang.org/show_bug.cgi?id=13957
On Wednesday, 5 September 2018 at 18:41:15 UTC, Jacob Carlborg
wrote:
On 2018-09-04 06:03, Mike Franklin wrote:
For that it needs to support all the features as classes do
today. In that case, what would be the difference compared to
classes?
Indeed, the idea is that structs, with a few
On Tuesday, 4 September 2018 at 03:38:41 UTC, 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:
On Sunday, 2 September 2018 at 12:08:37 UTC, Martin Nowak wrote:
Seems like they knew most artifacts within the installer by now,
scanning for the submitted binary was a lot faster than last
time.
I guess we should keep an eye on this for the next releases,
could you
take care of this Mike?
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote:
Glad to announce D 2.082.0.
The Windows installer gave me no warning messages this time.
Thanks, everyone.
Mike
On Friday, 24 August 2018 at 22:52:07 UTC, Steven Schveighoffer
wrote:
I really don't want to see dlang have to maintain posix system
calls on all supported OSes when that's already being done for
us.
Windows makes this simpler -- the system calls are separate
from the C runtime. It would
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote:
I think that you're crazy.
No, I just see more potential in D than you do.
Mike
On Friday, 24 August 2018 at 11:15:21 UTC, Jonathan M Davis wrote:
Linux is the only OS I'm aware of that considers the syscall
layer to be something that anything outside the OS would
normally call.
I think Linux considers system calls the OS API.
Other OSes consider libc to be part of
On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote:
One idea is we could add this template to `object.d`. This
would allow it to be used from any module that uses druntime
without having to import it first. The template itself is also
very friendly to "bloat" because it only
On Friday, 24 August 2018 at 10:09:07 UTC, Uknown wrote:
This is all very nice. I agree that this kind of thing should
be a part of the compiler, but I think it should be a compiler
plugin. If dmd had compiler plugins, I think stuff like this
and `dpp` would be much nicer to use.
I agree.
On Friday, 24 August 2018 at 09:46:08 UTC, Jonathan M Davis wrote:
For any kind of normal operating system, you _have_ to use
libc. It's part of the OS. Some pieces could be done without
it, but on the whole, you use libc if you want to talk to the
OS. That's just life. The only exceptions
On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis wrote:
Unless you're trying to argue for folks dropping Phobos, that's
just not going to fly. Phobos uses libc heavily, and it really
can't do what it needs to do without it (e.g. file operations).
Divorcing druntime from libc may
On Friday, 24 August 2018 at 00:58:35 UTC, Guillaume Piolat wrote:
D programs tend to use the C runtime directly, and quite a lot
of it:
https://github.com/search?l=D=%22import+core.stdc%22=Code
I know. They should get that from
https://github.com/D-Programming-Deimos/libc or perhaps even
On Friday, 24 August 2018 at 00:53:20 UTC, Guillaume Piolat wrote:
Do you also mean to reimplement everything related to FILE*?
floating-point parsing and conversion to string?
multithreaded malloc?
Only what's need for druntime. That would include multi-threaded
malloc, but not the FILE*
On Friday, 24 August 2018 at 00:32:59 UTC, Guillaume Piolat wrote:
For example: why implement AVX in DMD backend? Who are the
users that will be delighted by that? Those interested in
performance already use some other back-end, it's imo a
completely useless development since _no one_ use
On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote:
But I need it to implement `memcpy` and `memcmp` in D, so we
can remove the dependency on the D standard library :-)
Gah! What a typo. I mean the C standard library.
On Thursday, 23 August 2018 at 23:36:07 UTC, Chris M. wrote:
Heck, now that I'm looking at it, DIP25 seems like a more
restricted form of Rust's lifetimes. Let me know if I'm just
completely wrong about this, but
I think DIP 25 is analogous to Problem #3 for Rust's Non-Lexical
Lifetimes:
On Thursday, 23 August 2018 at 13:22:45 UTC, Shachar Shemesh
wrote:
Because in D, structs can't inherit,
Forgive me if I'm not helping, but if you are willing to create a
little infrastructure, I think you can create polymorphic structs
with the technique described at
On Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis
wrote:
Languages pretty much always get more complicated over time,
and unless we're willing to get rid of more stuff, it's
guaranteed to just become more complicated over time rather
than less.
"A designer knows he has achieved
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh
wrote:
And it's not just Weka. I've had a chance to talk in private to
some other developers. Quite a lot have serious, fundamental
issues with the language. You will notice none of them speaks
up on this thread.
They don't see
On Saturday, 18 August 2018 at 13:33:43 UTC, Andrei Alexandrescu
wrote:
where are the best leverage points in making the D language
more successful.
I'm still internalizing the article and thinking about how it
applies to the "D system", but I've always thought facilitating
the
On Wednesday, 22 August 2018 at 11:02:00 UTC, Seb wrote:
No, it's behind a flag, so you can't really say that we're
shipping it as "production ready release".
The changes to Phobos are not behind a flag. We're making
changes to Phobos in the release branch to accommodate a
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
dip1000 has been around for two years, and its predecessor
dip25 several years now. Plenty of time for anyone to comment
and/or propose something better.
Part of the problem is that the implementation keeps changing
without
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
I want to ensure Atila is successful with this. But that means
Phobos has to compile with dip1000. So I need to make it work.
There's a good chance you'll get your PR merged when it's
documented and vetted, then you'll be
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
The proposed idea wants to make the first parameter, if it's
`ref`, special.
This is because Phobos is written with functions of the form:
void put(sink, parameters...)
which corresponds to:
sink.put(parameters...)
On Wednesday, 22 August 2018 at 05:39:05 UTC, Mike Franklin wrote:
I understand that Walter's DIPs have been put through the
process just like the others, but with regard to the specific
issue in this thread
(https://issues.dlang.org/show_bug.cgi?id=19097), the
accompanying PR
On Wednesday, 22 August 2018 at 05:04:25 UTC, Mike Parker wrote:
Whatever the status of DIP 1000, I would point out that that
one of Walter's DIPs is in Community Review right now after
sitting in the PR queue in Draft Review for a while. Once this
review stage is done, it will go back into
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote:
It is hypocritical an arrogant to believe that only our ideas
have flaws and require scrutiny.
Sorry, that was poorly stated and conveyed the wrong intent. It
should read:
It is hypocritical an arrogant to believe that
On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis
wrote:
The reality of the matter is that the DIP system is a formal
way to propose language changes in order to convince Walter and
Andrei that those changes should be implemented, whereas if
Walter or Andrei writes the DIP,
On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote:
But what bothers me the most...
Something else that rubs me the wrong way is that DIP 1000 is
currently in a status of `DRAFT`:
https://github.com/dlang/DIPs/blob/master/DIPs/README.md
What the heck is going on here?
On Tuesday, 21 August 2018 at 21:17:25 UTC, Atila Neves wrote:
I don't have merge rights. I took a look anyway and it mostly
looks ok, but I'm not familiar enough with that part of the
codebase.
It's not the implementation that's preventing it from being
merged. It's the idea itself, weak
On Saturday, 18 August 2018 at 08:22:54 UTC, Mike Franklin wrote:
It's a little old, but from what I'm reading we need
"reputation" with Microsoft or an EV certificate, or publish on
the Windows Store.
I'm also reading that once the executable has been downloaded a
number of times from
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote:
I'll research a little and see if I can find some more
information.
This thread was also quite informative:
https://stackoverflow.com/questions/12311203/how-to-pass-the-smart-screen-on-win8-when-install-a-signed-application
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote:
I'll research a little and see if I can find some more
information.
Ok, so it is indeed signed: https://imgur.com/a/jGdoXSc
I found this which was disappointing:
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote:
I get the "Windows Defender SmartScreen prevented an
unrecognized app from starting. Running this app might put
your PC at risk" message. In other words this:
On Saturday, 18 August 2018 at 06:52:21 UTC, Martin Nowak wrote:
On Friday, 17 August 2018 at 22:01:29 UTC, Mike Franklin wrote:
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote:
Windows installer and binaries are now code-signed -
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.082.0 release
According to https://issues.dlang.org/show_bug.cgi?id=18786
VirusTotal used to report a virus for the installer. This beta
is now reporting clean:
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote:
Windows installer and binaries are now code-signed -
https://dlang.org/changelog/2.082.0.html#signed_windows_binaries
Was this beta installer supposed to be signed? Because it
doesn't seem to be.
Mike
On Friday, 17 August 2018 at 16:42:08 UTC, Martin Nowak wrote:
- help to test, debug, and fix the experimental lld/mingw
toolchain
(https://dlang.org/changelog/2.079.0.html#lld_mingw)
I'd be happy to test this, but where are the instructions for
using it?Do I need to uninstall Visual
On Friday, 17 August 2018 at 16:42:08 UTC, Martin Nowak wrote:
On 08/17/2018 01:24 AM, Mike Franklin wrote:
Well from my point of view the most important outstanding
Windows tasks are:
[...]
Thanks. I'm currently working on getting build.d to work on
Windows.
On Friday, 17 August 2018 at 16:00:26 UTC, 12345swordy wrote:
On Friday, 17 August 2018 at 15:27:22 UTC, Mike Franklin wrote:
I actually started writing a DIP for this about a year ago,
but I need to pick my battles.
Mike
Is it on github?
Alex
No,but here are some notes I found in my
On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote:
On Fri, Aug 17, 2018 at 01:50:32AM -0600, Jonathan M Davis via
Digitalmars-d wrote: [...]
Honestly, the reality of the matter is that @safe is probably
always going to be somewhat broken, because it's implemented
via blacklisting
On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote:
That particular bug is a duplicate of
https://issues.dlang.org/show_bug.cgi?id=8838, which was closed
as fixed based on the fact that -dip1000 fixes the problem by
treating marking the slice of a static array with scope. It's
1 - 100 of 373 matches
Mail list logo
