On Tuesday, 17 November 2020 at 22:14:04 UTC, aliak wrote:
[snip]
Alright!! A 1.0.0 release! Awesome work here!
Agreed.
On Tuesday, 17 November 2020 at 05:50:27 UTC, dangbinghoo wrote:
On Friday, 13 November 2020 at 12:25:48 UTC, Dibyendu Majumdar
wrote:
On Thursday, 12 November 2020 at 15:28:44 UTC, Faux Amis wrote:
[...]
I think it is too early for that as my project is not yet
started, and it may not
On Friday, 30 October 2020 at 10:12:58 UTC, Kagamin wrote:
On Tuesday, 13 October 2020 at 10:30:41 UTC, jmh530 wrote:
The difference is that MIT says you can use it without
restriction, including a few things, while Boost says you can
do some things. I only meant that MIT license was more
On Tuesday, 20 October 2020 at 21:58:16 UTC, Johan Engelen wrote:
On Tuesday, 20 October 2020 at 20:21:56 UTC, aberba wrote:
[...]
Guys, all points have been made, there is no wrong and right
here, let's stop arguing over this.
What is needed is someone who thinks it is useful to have an
On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote:
[snip]
See https://github.com/ldc-developers/ldc/issues/1754. I
personally never download the DMD installers, only the .7z. I
also don't use a global PATH set up to point to a particular
LDC installation. I expect the vast majority of
On Tuesday, 13 October 2020 at 07:02:26 UTC, aberba wrote:
On Monday, 12 October 2020 at 00:43:51 UTC, jmh530 wrote:
On Sunday, 11 October 2020 at 17:35:26 UTC, 9il wrote:
[snip]
I can't speak to the technical differences between the two. My
understanding is that MIT is more permissive than
On Sunday, 11 October 2020 at 17:35:26 UTC, 9il wrote:
[snip]
Maybe we should replace Boost with MIT for most of the Mir
packages. What do you think?
I can't speak to the technical differences between the two. My
understanding is that MIT is more permissive than Boost, but MIT
always
On Sunday, 11 October 2020 at 10:14:04 UTC, tastyminerals wrote:
On Thursday, 8 October 2020 at 16:40:01 UTC, 9il wrote:
It is a pleasure to announce the Dlang Statistical Package by
John Michael Hall.
[...]
Awesome! Are there any plans to add functions for inferential
stats?
Next thing
On Thursday, 8 October 2020 at 17:53:53 UTC, Andre Pany wrote:
[snip]
Thanks for this great piece of software. Does Mir provides
s.th. similar like Pandas DataFrame, especially the feature to
give columns a name and marking as inde x columns?
Kind regards
Andre
Magpie [1] was an initial
On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote:
[snip]
Author here. The most complete way to know would be to read the
changelog: https://dlang.org/changelog/2.094.0.html#preview-in
The TL;DR is that, in addition to `const scope`, `in` now
automatically behaves as `ref` when
On Thursday, 1 October 2020 at 16:44:09 UTC, jmh530 wrote:
[snip]
Typo from the link
"However, this didn't really capture the intended meaning of
in: the be applied on input parameters. "
It looks like that whole paragraph has a bunch of typos...
On Monday, 28 September 2020 at 13:44:25 UTC, Mike Parker wrote:
Jean-Louis Leroy sent in a blog post prompted by Andrei's
"Perfect forwarding" challenge from the July #beerconf. He digs
into D's metaprogramming and code generation facilities, and
shows how he arrived at his "refraction"
On Thursday, 3 September 2020 at 13:13:40 UTC, Per Nordlöw wrote:
D just got a better formatting of existing template usage
sorted by descending unique instantiation count via the flag
`-vtemplates`. Each template that has a least one instantiation
is now printed using standard compiler
On Tuesday, 11 August 2020 at 12:46:51 UTC, Atwork wrote:
[snip]
Just needs a rotation feature (unless I am just unaware of how
to do that.)
But pretty cool project
The blog post says it is space bar. Tripped me up too.
On Monday, 20 July 2020 at 14:14:26 UTC, Bastiaan Veelo wrote:
[snip]
Thanks for your reply. I have put some comments in line below.
I don't think it is related to the Ubuntu 16.10 issue, because
the above test does not rely on SHLVL being 2 initially. If the
script is called from the
On Sunday, 12 July 2020 at 09:04:40 UTC, Martin Nowak wrote:
Glad to announce D 2.093.0, ♥ to the 54 contributors.
This release comes with a preview for shared variable
initialization, template instantiation statistics, better
Windows support of the install.sh script, and higher accuracy
GC
On Thursday, 16 July 2020 at 19:08:59 UTC, Per Nordlöw wrote:
On Thursday, 16 July 2020 at 18:27:54 UTC, jmh530 wrote:
How are the functions generated? I see something about
function-depth, but it might be good to have an example in the
readme.
This is, of course, a very contrived benchmark
On Thursday, 16 July 2020 at 15:56:45 UTC, Per Nordlöw wrote:
I've updated
https://github.com/nordlow/compiler-benchmark
with
- source variants with templated function variants for
languages having generics
- stdout-printing in Markdown (used in README.md)
- benchmarks for the languages
On Tuesday, 7 July 2020 at 12:33:40 UTC, jmh530 wrote:
On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote:
[snip]
Likewise, you've made the std.experimental.allocator on DUB
depends on mir-core...
Is that not an example of how Steve thinks it should work? Both
are Boost
On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote:
[snip]
Likewise, you've made the std.experimental.allocator on DUB
depends on mir-core...
Is that not an example of how Steve thinks it should work? Both
are Boost licensed. mir-core has no external dependencies. Ilya
could
On Thursday, 2 July 2020 at 16:04:20 UTC, Patrick Schluter wrote:
[snip]
Thank you. Really good and I hope devs here will follow your
advices. It's needed.
Agreed.
On Monday, 29 June 2020 at 15:44:38 UTC, Patrick Schluter wrote:
[snip]
And that is completely wrong headed.
+1
As much as I'm sympathetic to the arguments for a slim standard
library, the amount of problems I've had in a corporate setting
trying to get libraries installed behind
On Thursday, 25 June 2020 at 11:55:14 UTC, Mike Parker wrote:
Simen Kjærås outlines an approach to supporting head-mutable
types in D without the need for compiler or language changes.
[snip]
Good piece. I've been following the recent thread, but this
really helped make some things clear.
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote:
[snip]
IMO this can be done more elegantly by separating out the code
that looks up methods in the current module from the code that
does the actual type erasure.
A while ago, I collaborated briefly with Adam Kowalski from the
On Wednesday, 17 June 2020 at 11:46:12 UTC, Atila Neves wrote:
[snip]
I think these questions are good motivators for making it
interface-only since then I don't have to check for data
definitions.
Makes sense.
On Wednesday, 17 June 2020 at 10:04:59 UTC, Atila Neves wrote:
[snip]
I was going to say "it should work" but instead I wrote the
code and... it does. It all falls out of how UFCS works and
usual language rules.
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
[snip]
Pretty cool, thanks for the fixups.
It may make for a good documentation example, in that it may help
make clear that you need to pass the module in somehow when
dealing with non-member functions (AFAICT). You could include
On Tuesday, 16 June 2020 at 12:30:24 UTC, jmh530 wrote:
[snip]
double area(Rect r) {
return r.width * r.height
}
double perim(Rect r) {
return 2 * r.width + 2 * r.height
}
double area(Circle c) {
import std.math: PI;
return PI * c.radius * c.radius
}
double perim(Circle c) {
On Tuesday, 16 June 2020 at 11:31:14 UTC, Atila Neves wrote:
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
[snip]
In the more longer-term, is the goal of the project to
implement a Typescript / Go interfaces like
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
[snip]
In the more longer-term, is the goal of the project to
implement a Typescript / Go interfaces like structural type
system in user space?
Yes. Other than allowing multiple interfaces, I think it's
already implemented.
I'm
On Monday, 15 June 2020 at 14:12:17 UTC, Atila Neves wrote:
[snip]
Yep:
https://github.com/atilaneves/tardy/blob/d5f1102a6a791e77e0a27ee1a7920166fba8fcc8/tests/ut/polymorphic.d#L222
Thanks, I missed that.
On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
[snip]
This is pretty cool. Thanks for sharing.
I have a few questions/comments:
1) It might make a good blog post at some point to discuss this
and the
On Friday, 12 June 2020 at 18:22:28 UTC, Selim wrote:
I wrote a small Yahoo finance scraper and wanted to share with
the community. I have been using D for a while and I think
contributing something to the community is good. There is an
example main script and a unit test. Those should get you
On Wednesday, 3 June 2020 at 17:37:59 UTC, data pulverizer wrote:
[snip]
Thanks. Very thorough!
On Wednesday, 3 June 2020 at 16:39:38 UTC, 9il wrote:
On Wednesday, 3 June 2020 at 16:15:41 UTC, jmh530 wrote:
This is unclear:
The chart below shows matrix implementation times minus
ndslice times; negative means that ndslice is slower,
indicating that the implementation used here does not
On Wednesday, 3 June 2020 at 17:07:34 UTC, jmh530 wrote:
[snip]
"The chart below shows the elapsed time of running the matrix
implementation times subtracted by the elapsed time of an
ndslice implementation."
Should be
"The chart below shows the elapsed time of running the matrix
On Wednesday, 3 June 2020 at 15:55:53 UTC, data pulverizer wrote:
On Wednesday, 3 June 2020 at 14:34:02 UTC, Mike Parker wrote:
Some of you may have seen a draft of this post from user "data
pulverizer" elsewhere on the forums. The final draft is now
on the D Blog under his real name and
On Monday, 1 June 2020 at 19:51:34 UTC, tastyminerals wrote:
[snip]
I see. It depends on how much work is needed for any of the
options, right?
For now, I think having a function that does the job suffices
for me at least. Since I always printed tensors in Python to
see what's going on, I
On Sunday, 31 May 2020 at 22:40:09 UTC, tastyminerals wrote:
I often print arrays to see how they look and their contents.
NumPy has a nice way of pretty-printing the arrays, and I was
lacking this in D.
For the sake of practice, I wrote a small package. It uses
mir.ndslice but works for both
On Sunday, 31 May 2020 at 14:43:46 UTC, 9il wrote:
by Shigeki Karita
https://github.com/ShigekiKarita/tfd
Cool.
On Friday, 29 May 2020 at 11:33:01 UTC, Sebastiaan Koppe wrote:
On Thursday, 28 May 2020 at 16:01:35 UTC, Johannes Pfau wrote:
[snip]
This would be another round of massively breaking user code.
The breakage will be split in two rounds, but the amount of
code needed to be modified would be
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote:
The subject says it all.
If you care about memory safety, I recommending adding `safe:`
as the first line in all your project modules, and annotate
individual functions otherwise as necessary. For modules with C
declarations, do as
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
[snip]
This last is sad, for me. I like using test functions rather
than named unittest blocks.
I recall playing with them when it was originally announced and
thought they were quite nice, but I haven't used them since.
The
On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote:
[snip]
Nothing at all.
But I doubt there is much legacy non-compiling code around.
I cannot speak for all the code out there, but I know of at least
one binding out there [1] that will need to get updated in light
of this DIP.
On Friday, 22 May 2020 at 18:44:09 UTC, Steven Schveighoffer
wrote:
[snip]
You are using library fubar.
fubar defines a function foo:
I agree with most of what you said.
I was trying to make the point that this is a contrived example
where we know for sure that one function should be
On Friday, 22 May 2020 at 18:34:32 UTC, Gregory wrote:
[snip]
Why are you assuming that the only thing wrong with
useClibrary() is that it would use a C declaration that is
@system? All @system code I've written is @system and wouldn't
compile to @safe even if extern(C) declarations are
On Friday, 22 May 2020 at 17:40:59 UTC, Atila Neves wrote:
[snip]
That is a failure of the language that should be resolved.
And how do you suggest we fix it?
@safe as whitelist instead of blacklist.
When the compiler cannot verify that it is @safe, then it cannot
be @safe.
On Friday, 22 May 2020 at 16:47:34 UTC, Steven Schveighoffer
wrote:
[snip]
You can't, you don't control that code, someone else does (this
is important, you can declare extern(C) functions anywhere,
even locally).
You can make a separate module with one function that just calls
the `free`
On Friday, 22 May 2020 at 16:03:00 UTC, Steven Schveighoffer
wrote:
[snip]
Fortunately, the above point can be more easily fixed by making
`free` @system, which will then require annotating every
subsequent piece of code that touches it. It's annoying
transition, but it's do-able. The
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
[snip]
Thank you for your reply.
How about some time before this DIP is fully in the language, a
compiler flag is added that will produce warnings for when extern
prototypes without explicit @safe/@trusted/@system are used? Or
On Thursday, 14 May 2020 at 13:40:24 UTC, Andrei Alexandrescu
wrote:
[snip]
Really interesting. Thanks for sharing.
I have recently been spending some spare time learning more about
D's topN and pivotPartition implementation, which led me to your
paper on fast deterministic selection.
On Thursday, 7 May 2020 at 14:15:07 UTC, Greatsam4sure wrote:
[snip]
Yeah, I thought it looked good.
I make mistakes all the time. I find that saying dumb things out
loud often will help me learn and make fewer mistakes in the
future.
On Monday, 20 April 2020 at 13:25:14 UTC, Jean-Louis Leroy wrote:
[snip]
That is not a problem. If I was granted two wishes, they would
be: 1/ reallocate 'ClassInfo.deallocator' to me ;-) and 2/ add
a more general feature to the language, similar to Perl's
'import' function: if a module
On Monday, 20 April 2020 at 08:17:24 UTC, Robert M. Münch wrote:
[snip]
This is very interesting stuff! Thanks a lot.
I just read your blog post [1] and wonder if it's still
up-to-date or maybe an update would make sense?
This stuff sounds like a very fundamental concept/pattern and
IMO
On Thursday, 2 April 2020 at 13:16:46 UTC, 9il wrote:
[snip]
For my work, I use `mir-blas` - ndslice bindings to CBLAS API.
It is faster to write binding rather than finish BLAS
implementation.
It is useful. And I think it is very promising for Dlang
promotion and can really involve new
On Monday, 30 March 2020 at 17:47:19 UTC, jmh530 wrote:
[snip]
The relevant function signature is
@safe sumType!YRange[2] simpleLinearRegression(XRange,
YRange)(XRange x, YRange y)
if (isInputRange!XRange && isInputRange!YRange &&
!(isArray!XRange && isArray!YRange) &&
On Monday, 30 March 2020 at 17:21:57 UTC, Vino wrote:
Hi All,
Can anyone guide me what is the problem with below code as
it throws error.
import std.stdio, mir.math.common: approxEqual;
static immutable x = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
static immutable y = [1, 3, 2, 5, 7, 8, 8, 9,
On Monday, 30 March 2020 at 06:33:13 UTC, 9il wrote:
[snip]
Thanks, I like 'em.
I noticed that the little icon in the tabs has changed from most
of them. However, the mir random is unchanged from before.
Also, on the mir.glas page, one of the lines says "matrix-vector
operations %3 done,
On Thursday, 27 February 2020 at 15:11:07 UTC, Steven
Schveighoffer wrote:
[snip]
We're going very off topic here, but I wanted to address this.
Large hidden invisible types are not the problem (look at
normal dynamic arrays, the large hidden type built into the
runtime is a huge success I
On Wednesday, 26 February 2020 at 16:17:06 UTC, Panke wrote:
[snip]
If you had an RSS feed, I would subscribe. Wasn't there a
planet D in the past?
I've been subscribed on feedly without any issues. I can't recall
what I actually did to subscribe as I can't seem to replicate it,
but you
On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves wrote:
[snip]
A lot of the comments were about how stupid I was for not just
using ctypes or cffi. I tried today and both of them are
horrible. As I say in the blog post below, either they didn't
read the article (people on the
On Wednesday, 26 February 2020 at 12:17:43 UTC, Martin Nowak
wrote:
Glad to announce the first beta for the 2.091.0 release, ♥ to
the 55 contributors.
[snip]
I'm happy to see those Windows install improvements.
In the changelog, it mentions isClose, but I didn't see that
listed in the
On Friday, 7 February 2020 at 23:14:28 UTC, Andre Pany wrote:
[snip]
All what you say is completely true. Still, the license makes
it a very hard job to advertise the D Programming Language at
the place I work. It is already hard, and I do not want also
get into discussions with IP
On Friday, 7 February 2020 at 19:51:52 UTC, Andre Pany wrote:
[snip]
Now it gets more complicated, GtkD has some additions to the
lgpl rules.
I cannot judge how high the risk is for companies to use this
component, but as an employee I do anything to avoid any risk
for the company I work
On Monday, 27 January 2020 at 14:16:47 UTC, Mike Parker wrote:
You've seen Lance Bachmeier posting in the forums under the
bachmeier handle. He's put together a post for the D Blog
showing how to integrate R into a D program.
The Blog:
On Tuesday, 17 December 2019 at 17:41:46 UTC, bachmeier wrote:
[snip]
I had no idea that existed. That should really be promoted.
There might be a lot of interest.
First commit was only 8 days ago [1]. I'm sure there will be a
bigger announcement when it's ready.
[1]
On Monday, 11 November 2019 at 19:17:54 UTC, Jacob Carlborg wrote:
[snip]
Hmm, that's unfortunate. It happens way too often in the D
community, that a project is rewritten from scratch instead of
improving the existing one. Especially since the D community is
not that big.
Although I can
On Wednesday, 6 November 2019 at 01:51:24 UTC, Heromyth wrote:
[snip]
There are some bugs in cas. See here:
https://issues.dlang.org/show_bug.cgi?id=20354
https://issues.dlang.org/show_bug.cgi?id=20355
I suspect that providing simplified examples might improve your
chances of getting these
On Sunday, 20 October 2019 at 12:31:23 UTC, Mike Parker wrote:
DIP 1021, "Argument Ownership and Function Calls", has been
formally accepted with minor revision. It was updated to make
clear that the proposal is one piece of a bigger plan.
On Monday, 30 September 2019 at 13:14:52 UTC, Mike Parker wrote:
Andrea Fontana has contributed a guest post to the D blog about
his company's experience moving their online magazine from PHP
to D. Not only did they gain performance, they also saved quite
a bit of money as a result.
The
On Tuesday, 24 September 2019 at 18:24:36 UTC, Ivan Butygin wrote:
On Tuesday, 24 September 2019 at 17:49:13 UTC, jmh530 wrote:
About bind call overhead, bind object hold pointer to shared
payload, which is allocated via malloc. This payload has
function pointer (initially null).
During
On Tuesday, 24 September 2019 at 16:48:48 UTC, kinke wrote:
[snip]
If you don't want to ship 10 fine-tuned binaries for 10
different CPUs (see `-mcpu=?`), you can use JIT to compile and
tune performance-critical pieces for the executing/target CPU.
E.g., letting the auto-vectorizer exploit
On Monday, 23 September 2019 at 20:57:49 UTC, Ivan Butygin wrote:
[snip]
With @dynamicCompileEmit normal calls to function will go to
static version but these functions can still be targets for
bind.
The confusing thing is that if I add a normal call to foo and
then change
On Monday, 23 September 2019 at 19:40:13 UTC, Ivan Butygin wrote:
On Monday, 23 September 2019 at 12:22:47 UTC, Martin
Tschierschke wrote:
Can you please give (again?) a link or a more detailed
description of the JIT, explaining some use cases?
On Saturday, 7 September 2019 at 07:16:36 UTC, Manu wrote:
[snip]
What's the story with string though; the second line (linking
back to the C++ reference) of the doco isn't there... O_o
Hmm, I didn't notice that. It also is a problem for
core.stdcpp.array. I'm looking at other uses of LINK2
On Thursday, 5 September 2019 at 20:55:15 UTC, Manu wrote:
[snip]
Interesting... you can see in the code, there are doco comments
everywhere, but the docs are empty O_o
Also the second line of the description linking to the C++ docs
is
missing too... where did all the docs go?
The point I
On Tuesday, 3 September 2019 at 14:02:43 UTC, bachmeier wrote:
[snip]
Those are a big deal. From a marketing perspective, those are
gold IMO.
If these are as big a deal as people seem to think, the
documentation could be improved by including a brief example of
how to use.
In addition,
On Friday, 30 August 2019 at 13:30:06 UTC, Robert Schadek wrote:
[snip]
Cool. I haven't done much programming in Julia myself, but glad
you guys are doing this kind of work.
On Monday, 22 July 2019 at 20:57:19 UTC, Meta wrote:
[snip]
This seems like a major failure in the process that this was
allowed to happen - good work almost went abandoned. How can we
prevent this in future SAoC/GSoC? Without knowing what the
mentor did/didn't do, an obvious answer seems
On Wednesday, 8 May 2019 at 13:26:15 UTC, Mike Parker wrote:
On Wednesday, 8 May 2019 at 13:14:05 UTC, RazvanN wrote:
Will the recordings be uploaded somewhere (preferably youtube)?
YouTube in approximately two weeks.
Thanks for the slides thread as well...though I don't see
Walter's on
On Monday, 6 May 2019 at 18:15:54 UTC, Seb wrote:
Hi all,
I'm very happy to announce that this year we will have six
amazing GSoC students:
[snip]
Thanks to all those who helped make this happen. Good luck to the
students.
On Friday, 26 April 2019 at 06:35:42 UTC, Shigeki Karita wrote:
I haven't know that GPU support in Stan. That's Cool! Cholesky
decomposition always suffers me when I use covariance matrix or
something. If you are interested in GPU acceleration in
probabilistic programming, see also this
On Wednesday, 24 April 2019 at 14:05:28 UTC, 9il wrote:
[snip]
RC types are created to be used with DIP1000. Plus, Mir
Algorithm used in production with this DIP. See configuration
"dips" [1]
Well, the allocator support is not ready yet. But the
mir_rc_context already contains `void*
On Wednesday, 24 April 2019 at 16:33:00 UTC, Shigeki Karita wrote:
[snip]
I see. I'm interested in Stan that is the best library for
probabilistic models but it lacks of GPU computation.
Therefore, I plan to add some probabilistic programming
paradigm into grain like pytorch (pyro) and
On Wednesday, 24 April 2019 at 10:51:08 UTC, jmh530 wrote:
On Wednesday, 24 April 2019 at 06:13:13 UTC, Fynn Schröder
wrote:
[snip]
It's an autograd library for dynamic neural networks based on
mir and cuda. See GitHub for more details:
https://github.com/ShigekiKarita/grain
I've tried it
On Wednesday, 24 April 2019 at 01:34:58 UTC, 9il wrote:
Thread safe RC Array and Ptr. Plus C++ headers for code
integration.
[snip]
Cool.
Does this make any use of DIP1000? How is the run-time/memory
performance vs. the GC versions?
On Wednesday, 24 April 2019 at 06:13:13 UTC, Fynn Schröder wrote:
[snip]
It's an autograd library for dynamic neural networks based on
mir and cuda. See GitHub for more details:
https://github.com/ShigekiKarita/grain
I've tried it and it works great -- although it's far from
feature complete
On Friday, 12 April 2019 at 13:54:05 UTC, kinke wrote:
[snip]
I'd use something like
version (LDC) import ldc.attributes : restrict;
else enum restrict = null;
Excellent. Thanks.
On Friday, 12 April 2019 at 13:54:05 UTC, kinke wrote:
[snip]
I'd use something like
version (LDC) import ldc.attributes : restrict;
else enum restrict = null;
Much better, thanks.
On Saturday, 6 April 2019 at 17:40:39 UTC, kinke wrote:
* New generic @llvmAttr("name") parameter UDAs, incl. @restrict
with C-like semantics.
[snip]
I think I had passed over this when I first read the
announcement. The @llvmAttr("noalias") compiled on run.dlang.org,
but I couldn't get
On Tuesday, 26 February 2019 at 22:34:45 UTC, Seb wrote:
Hi all,
I have some very exciting news to share.
[snip]
Great news.
On Friday, 1 February 2019 at 12:51:18 UTC, Atila Neves wrote:
[snip]
I appreciate the reply. Thanks.
On Thursday, 31 January 2019 at 22:35:26 UTC, H. S. Teoh wrote:
On Thu, Jan 31, 2019 at 10:26:39PM +, jmh530 via
Digitalmars-d-announce wrote:
On Thursday, 31 January 2019 at 21:57:21 UTC, Steven
Schveighoffer wrote:
[...]
> That being said, you can look at the fact that most peo
On Thursday, 31 January 2019 at 21:57:21 UTC, Steven
Schveighoffer wrote:
[snip]
That being said, you can look at the fact that most people
don't even know about this problem, even seasoned veterans, as
a sign that it's really not a big problem.
The way you put it makes it sound like a
On Thursday, 31 January 2019 at 21:50:19 UTC, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 21:44:53 UTC, jmh530 wrote:
It doesn't compile with dip1000 without first giving the
getter functions a return attribute for this.
But it still compiles with -dip1000 once you give x() and y()
On Thursday, 31 January 2019 at 21:42:04 UTC, Olivier FAURE wrote:
[snip]
It took me a while to understand what the compiler was doing.
This really feels like something that shouldn't compile.
It doesn't compile with dip1000 without first giving the getter
functions a return attribute for
On Thursday, 31 January 2019 at 14:42:43 UTC, Atila Neves wrote:
[snip]
I've never had a need to use complicated values, so I haven't
coded that.
If presented with an example, I think there's a high chance I'd
consider it an anti-pattern.
I was thinking about something like what is in one
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves wrote:
[snip]
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one
On Wednesday, 23 January 2019 at 13:03:18 UTC, Bienlein wrote:
Also, the Internet was Java's killer application. No other
language had the libraries for accessing the Internet easily.
Then there is dynamic class loading. This made things a little
bit more unsafe at runtime but in general
On Thursday, 13 December 2018 at 17:07:58 UTC, H. S. Teoh wrote:
[snip]
Why not? You can opt out. It's not as though you're forced to
use immutable everything and nothing but, like in a pure
functional language. Just tack on @system or mutable when you
need to.
Mutable might be a
101 - 200 of 417 matches
Mail list logo
