On Friday, 20 October 2017 at 20:41:24 UTC, Nordlöw wrote:
Ever since I first tried programming in VHDL and realized that
it, at that time, was far too unproductive for my taste, I've
been waiting for the software and FPGA programming models to
unite...
What kinds of simplifications (over Ope
On Monday, 26 June 2017 at 10:23:05 UTC, Martin Tschierschke
wrote:
This is only partially true, as I know from a friend, he is
physicist @ DESY Hamburg, he is programming exactly with this
pair of languages for data analysis.
(Could not convince him to try D jet :-))
If the comparison was br
On Monday, 26 June 2017 at 09:51:37 UTC, Wulfklaue wrote:
They are comparing the old, newer and newest ( in that order ).
Yes, that was confusing too. But it makes no sense to plot
ranking on a linear scale, they should plot actual numbers. The
plot they provide says nothing meaningful about
On Monday, 26 June 2017 at 09:30:04 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 25 June 2017 at 00:52:14 UTC, Wulfklaue wrote:
On Saturday, 24 June 2017 at 22:05:44 UTC, Andrei Alexandrescu
wrote:
http://i-programmer.info/news/98-languages/10859-redmonk-rankings-reveal-the-languages-we
On Sunday, 25 June 2017 at 00:52:14 UTC, Wulfklaue wrote:
On Saturday, 24 June 2017 at 22:05:44 UTC, Andrei Alexandrescu
wrote:
http://i-programmer.info/news/98-languages/10859-redmonk-rankings-reveal-the-languages-we-love.html
-- Andrei
It looks like D almost never moved on those rankings.
On Friday, 26 May 2017 at 16:55:44 UTC, Joakim wrote:
On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu
wrote:
Walter and I have implicitly fostered a kind of meritocracy
whereby it's the point/argument that matters.
I don't see any evidence of this statement being true.
Unfortunate
On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter
wrote:
That's not a simple assumption, it's acknowledgment that a C
program runs on real
hardware not a virtual machine like Java or C#.
Modern X86s are basically virtual machines... The instruction set
is decoded and executed on a
On Saturday, 29 April 2017 at 11:24:36 UTC, Patrick Schluter
wrote:
C99 says "if an int can represent all values of the original
type, the value is converted to an int; otherwise, it is
converted to an unsigned int."
Well, C is making the simple assumption that registers are
int-sized...
Th
On Saturday, 29 April 2017 at 03:44:50 UTC, Nick Sabalausky
(Abscissa) wrote:
On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce
wrote:
https://bartoszmilewski.com/2013/09/19/edward-chands/
That is *awesome*!
Although, I always saw Eddie Scissors as more of a retelling of
On Monday, 24 April 2017 at 15:17:18 UTC, Timon Gehr wrote:
Swift allows raw pointer manipulation.
I didn't know that Swift had that as a language construct. Link?
I know that it provides library solutions for raw pointers, but
that can be said for most languages.
Java implementations expo
On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote:
The trouble is, one cannot look at a piece of code and tell if
it follows the rules or not.
I.e. it's not about it being possible to write memory safe code
in C or C++ (it is), it's about verifying an arbitrary piece of
code as be
On Saturday, 15 April 2017 at 20:20:01 UTC, Bill Baxter wrote:
And more than that, companies that are serious about avoiding
litigation will make sure that everyone working on this new
project has not even seen the source code for the library with
the other license. If someone who has seen the
On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote:
* "Minimal Runtime" is the building block of systems
programming.
If this is not a core feature of a language, it will never
compete with C. Systems programmers in my field need to
incrementally opt-in to features in a pay-as-you-go f
On Saturday, 14 January 2017 at 15:41:01 UTC, Dmitry Olshansky
wrote:
That is C++ smart_ptr has to be atomic, while its D counter
part may safely be non-atomic because everything is TLS be
default.
I assume you mean std::shared_ptr. The reference counting
semantics are atomic, but the I don't
On Tuesday, 12 July 2016 at 15:24:29 UTC, Guillaume Chatelet
wrote:
2. As far as I know, Android does not expose either CPU
identification or cache structure information to userspace.
Please do correct me if I'm wrong and this library found a way
around that --- but from a cursory look at the
On Monday, 11 July 2016 at 16:18:47 UTC, Dietrich Daroch wrote:
Previous discussion seems to favour @unboundedStack as it can
become a requirement to go beyond the stack-size-safe
operations effectibly tracking where stack overflow may happen
and encourage detailed review of those functions.
On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote:
I've been thinking about changing @tco for @boundedStack, as
it'll really reflect guarantees on functions while implicitly
asking for TCO on functions that require it. But the fact that
most functions should be marked as @boundedSt
On Sunday, 10 July 2016 at 17:32:32 UTC, Dietrich Daroch wrote:
It might be interesting to have proof that the stack is bounded
(and won't overflow).
Yes, a stack depth guarantee would be useful for D fibers.
On Sunday, 10 July 2016 at 17:10:32 UTC, Dietrich Daroch wrote:
Annotating every callsite seems uncomfortable, being able to
perform TCO is a property of the function and not something
that might look call-site dependant.
You only need to annotate the location where the function calls
itself.
On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
Hi everyone (=
I've just added a new proposal to add a new attribute to ensure
TCO is applied.
The proposal is really simple, but I'm clueless on how to
implement it and also interested on getting feedback on it.
Why should it
On Tuesday, 5 July 2016 at 16:40:05 UTC, ketmar wrote:
so, we played a little game with Stefan: i wrote a simple
stack-based VM implementation for our beloved bug6498, and got
What is «bug6498»?
On Monday, 4 July 2016 at 08:34:15 UTC, Andrea Fontana wrote:
On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella
wrote:
Hello again Dland! I'm happy to finally announce the open
sourcing of our Ocean base library, just it time to keep our
word and make it in June ;-)
https://github.
On Friday, 1 July 2016 at 10:31:59 UTC, Leandro Lucarella wrote:
Oh, well. Sorting out the license(s) were one of the major
pains and time consuming tasks we had to do to opensource this,
and apparently despite our best efforts there are stuff that we
didn't see.
*nods* I was only looking at
On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella
wrote:
(although please have a look at the licensing terms, even when
all our code is Boost, there is code inherited from Tango that
isn't), criticize it, and if you are really nice, fill issues
and make pull requests!
I find the li
On Monday, 27 June 2016 at 21:41:57 UTC, Jay Norwood wrote:
measurements. I'm using a 100KB char array terminated by four
zeros, and doing strlen on substring pointers into it
incremented by 1 for 100K times.
But this is a rather atypical use case for zero terminated
strings? It would make mo
On Monday, 27 June 2016 at 06:31:49 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 June 2016 at 05:27:12 UTC, chmike wrote:
Ending strings with a single null byte/char is to save space.
It was critical in the 70´s when C was created and memory
space was very limited. That's not the case an
On Monday, 27 June 2016 at 19:51:48 UTC, Jay Norwood wrote:
Your link's use of padding pads out with a variable number of
zeros, so that a larger data type can be used for the compare
operations. This isn't the same as my example, which is
simpler due to not having to fiddle with alignment and
On Monday, 27 June 2016 at 16:22:56 UTC, Jay Norwood wrote:
This strlen2 doesn't require special alignment or casting of
char pointer types to some larger type. That keeps the strlen2
implementation fairly simple.
Yes, and the idea of speeding up strings by padding out with
zeros is not new.
On Monday, 27 June 2016 at 05:27:12 UTC, chmike wrote:
Ending strings with a single null byte/char is to save space.
It was critical in the 70´s when C was created and memory space
was very limited. That's not the case anymore and I guess the
Not only to save space, some CPUs also had cheap in
On Friday, 24 June 2016 at 15:27:14 UTC, Wild wrote:
Ya, I did borrow some code, mostly because my 64-bit code
didn't play nice in
the beginning. But I think I have rewritten all the code that I
borrowed from
you.
Be careful with that. A rewrite may still be considered a
translation, and the
On Sunday, 15 May 2016 at 15:09:17 UTC, Stefan Koch wrote:
You want it ?
Write it.
I don't «want» anything.
On Sunday, 15 May 2016 at 13:44:45 UTC, Martin Nowak wrote:
2^^15 | 3.7s | 4.8G | 0.13s | 10.0M
2^^16 | 5:30m | 15G | 0.13s | 10.8M
D's CTFE grows O(N^2) b/c it leaks for almost every operation.
We don't currently need a superfast interpreter, even the
simplest
possible interpreter will all
On Sunday, 15 May 2016 at 12:00:43 UTC, Martin Nowak wrote:
On 05/15/2016 01:55 PM, Ola Fosheim Grøstad wrote:
If you are going to have fast evaluation of loops/recursion
then you need to use a solver. And well, doing worse than
O(log N) at compile time is a very bad idea.
Why not start with
On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote:
On 05/10/2016 08:45 AM, Jacob Carlborg wrote:
overhead and complexity over an AST interpreter. If you want to
go really fast you need some sort of JIT anyhow, but a proper
interpreter will be orders of mangnitude faster than the
curre
On Thursday, 10 March 2016 at 17:59:21 UTC, Chris Wright wrote:
It's a little easier to write iterators in the Python style:
you don't have to cache the current value, and you don't have
to have a separate check for end-of-iteration. It's a little
easier to use them in the D style: you get more
Just pointing out the obvious:
For the simple iterators/generators that run on a non-changing
source you can basically break it up into:
1. iterators without lookahead
2. iterators with lookahead
Which is basically the same issues you deal with when
implementing a lexer.
Python-style itera
On Thursday, 10 March 2016 at 00:29:46 UTC, Jack Stouffer wrote:
It's a pretty straight forward standard iterator design and
quite different from the table pointers C++ uses.
I explain my grievances in the article.
They didn't make all that much sense to me, so I wondered what
Theo's issues
On Wednesday, 9 March 2016 at 22:17:39 UTC, H. S. Teoh wrote:
system for my personal projects), I can totally sympathize with
the annoyances of using a dynamically-typed language, as well
as dodgy iterator designs like __next__. (I've not had to deal
with __next__ in Python so far, but *have* w
On Sunday, 14 February 2016 at 19:29:54 UTC, Vladimir Panteleev
wrote:
I think that in the context of a render farm, disabling bounds
checking is completely reasonable. Bugs will manifest as
crashes or rendering artifacts, and there is no risk of code
execution exploits.
But nobody would writ
On Sunday, 14 February 2016 at 17:38:54 UTC, artemalive wrote:
Hi Adam, I'll check the influence of enabled bounds check on
benchmark result. Did not try this before.
If you do, then you should use bounds checks in C++ too. (STL
container.at(index) )
On Monday, 1 February 2016 at 20:14:42 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 1 February 2016 at 20:01:11 UTC, Chris Wright wrote:
What I would actually expect, instead of a C&D letter, is a
set of guidelines for using the D logo and other trademarked
material. That's pretty sta
On Monday, 1 February 2016 at 20:01:11 UTC, Chris Wright wrote:
What I would actually expect, instead of a C&D letter, is a set
of guidelines for using the D logo and other trademarked
material. That's pretty standard for open source projects. And
if those guidelines forbad using the D logo for
On Saturday, 30 January 2016 at 22:37:18 UTC, Adam D. Ruppe wrote:
I know quite a few css tricks... but I don't think I can
actually do this without adding a script or something, so I
just put an arbitrary fixed width on hover for now.
One trick is to set the width and clipping on "dt > *" ins
On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
In my perfect world, quality third party apps - as determined
just by usage stats or something - would be automatically
downloadable and their documentation searchable as if it was
standard.
I've noticed that curated lists of li
On Thursday, 28 January 2016 at 16:12:44 UTC, jmh530 wrote:
the standard library or not. As discussed elsewhere, there are
clearly benefits to putting some things in phobos (if only for
providing a framework for others), and there are costs as it
gets too large.
That's the maintenance costs,
On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
I do like the building-block idea you suggest, but one must
think about the deeper reasons for why things are owned by
which people.
It is much easier to get motivated if you have a certain level
autonomy. Clearly, the "D foun
This is what a good system programming standard library should
provide:
1. Types needed to specify library APIs.
2. Functionality for accessing hardware in a non-emulated fashion.
3. Functionality that most _libraries_ need to build on (like
arrays/iterators/ranges).
4. Functionality that i
On Wednesday, 27 January 2016 at 21:00:41 UTC, Martin Nowak wrote:
A good criteria is whether some area has an established and
hard to debate solution, then it can go into the standard
library. But if there are many different ways around the same
topic you should leave the decision to the users
On Wednesday, 27 January 2016 at 16:52:53 UTC, Laeeth Isharc
wrote:
your own argument. Of course there will be lots there that one
doesn't need and can't use. But over time things that were
once cutting edge become bog standard, and it makes sense to
have coherence and convenience rather than
On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc
wrote:
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim
Grøstad wrote:
I am not sure if that is the right motivation. Sounds like
recipe for bloat. Good libraries evolve from being used in
real applications. Many
Or let me put it this way. If the standard library requires
POSIX, then it isn't really a standard library, but a POSIX
abstraction library...
On Tuesday, 26 January 2016 at 23:04:57 UTC, tsbockman wrote:
This is why requiring modules to spend some time on DUB and/or
in `std.experimental` before freezing the API is important.
Well, there aren't enough D applications written to ensure the
usefulness of the API. Just take a look at wid
On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:
1) The prospect of getting something into the standard library
is a huge motivator for (at least some) potential contributors.
I am not sure if that is the right motivation. Sounds like recipe
for bloat. Good libraries evolve from b
On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:
Also, you skipped past the "uninterested" part - this is a
volunteer project, remember?
I didn't think it was a relevant argument as you can still write
libraries for distribution. Keep in mind that the standard
library has to be m
On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote:
It's not like you could just reallocate all the effort that
goes into Phobos towards the compiler and stuff.
My impression is that the majority of the contributors to Phobos
are capable D programmers.
DMD is implemented in D now,
On Tuesday, 26 January 2016 at 10:52:17 UTC, Russel Winder wrote:
Design patterns are not language agnostic. GoF patterns are 23
year old and many totally irrelevant with certain programming
languages. However that is a different debate for a different
place.
I found GoF underwhelming when I
On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote:
Ouch yes, seen that before. I just would prefer the base
library to be exactly that a base.
I agree. Imagine if all the effort put into Phobos' extras was
put into the compiler and tooling...
On Tuesday, 5 January 2016 at 18:09:57 UTC, Andrei Alexandrescu
wrote:
Again this goes back to Adam. Let's say we had a contributor
Eve who'd gladly take emailed questions and suggestions and
integrate them. Would that be as nice?
Ohoh... Keep Eve out of it, she's got an Apple.
On Wednesday, 9 December 2015 at 11:04:46 UTC, Tony wrote:
How are you defining "capitalizing"?
Climbing the ladder.
Many researchers don't want to climb the ladder (e.g. become head
of department or even group leader) because it means that they
spend 100% of their time on administration and
On Wednesday, 9 December 2015 at 10:26:03 UTC, Tony wrote:
I'd be swayed if you could link to interviews with older
scientists, mathematicians or computer scientists who said
their work declined with age because they became disillusioned
or they ran into social conditioning issues.
They are b
On Wednesday, 9 December 2015 at 10:33:33 UTC, Tony wrote:
On Wednesday, 9 December 2015 at 09:27:55 UTC, deadalnix wrote:
Later in life, either you were not talented and most likely
not made it, or you were talented and busy capitalizing and
what you made younger.
That's a very good point.
On Wednesday, 9 December 2015 at 07:49:58 UTC, Rory McGuire wrote:
The number of scarily intelligent people aged over 60 is most
likely a lot
higher than the number of 25 year olds that are so. Its just
the way our
brains work, your brain optimises its thought processes
continually, and
experi
On Sunday, 29 November 2015 at 17:36:47 UTC, Guillaume Piolat
wrote:
On Sunday, 29 November 2015 at 17:23:20 UTC, Ola Fosheim
Grøstad wrote:
Yes, so that will generate sidebands in the frequency
spectrum, like FM synthesis, right?
It won't because the vibrato frequency is too low, a
On Sunday, 29 November 2015 at 16:15:32 UTC, Guillaume Piolat
wrote:
There is also a sample-wise FFT I've came across, which is
expensive but avoids chunking.
Hm, I don't know what that is :).
Looking for similar grains is the idea behind the popular
auto-correlation pitch detection methods.
On Sunday, 29 November 2015 at 15:13:41 UTC, Guillaume Piolat
wrote:
The hard thing about live pitch-tracking is getting the minimal
latency keeping reliability. It's not that simple. You also
want "voicedness", which is more challenging than pitch.
I think they developed it for a specific wor
On Sunday, 29 November 2015 at 12:40:30 UTC, Guillaume Piolat
wrote:
On Sunday, 29 November 2015 at 12:28:49 UTC, Ola Fosheim
Grøstad wrote:
The sound samples sound quite a bit like the classic vocal
sound of Infected Mushroom to my ears, which is cool.
Infected Mushroom released another
On Sunday, 29 November 2015 at 11:58:20 UTC, Guillaume Piolat
wrote:
I've never said the GC is compatible with real-time, it isn't.
I said, we can avoid it in a small part of an application and
be real-time. So D can do real-time (audio).
Yes, but why say it if you don't use it after init?
It
On Sunday, 29 November 2015 at 11:15:41 UTC, Guillaume Piolat
wrote:
On Sunday, 29 November 2015 at 09:55:43 UTC, Ola Fosheim
Grøstad wrote:
On Sunday, 29 November 2015 at 09:12:42 UTC, deadalnix wrote:
I see that if that RT music thing doesn't pan out for you,
you can always bec
On Sunday, 29 November 2015 at 09:12:42 UTC, deadalnix wrote:
I see that if that RT music thing doesn't pan out for you, you
can always become a psychiatrist. You are a man a many talents,
congrats.
Maybe you and Guillaume Piolat should try to tone down your
french rhetorics? I don't think Po
On Sunday, 29 November 2015 at 06:18:13 UTC, Jonny wrote:
While, this doesn't prove you don't have a clue about jitter,
my guess is, you don't.
Yes, jitter is bad and worse than latency, but OS-X AudioUnits
run at a high priority thread where you cannot do system calls,
malloc or run a GC. So
On Saturday, 28 November 2015 at 21:39:06 UTC, Adam D. Ruppe
wrote:
On Saturday, 28 November 2015 at 21:30:38 UTC, Ola Fosheim
Grøstad wrote:
What is the better tool to bring to the top of a mountain?
Only maniacs go down mountains. The fun part is the ascent...
the descent is an exceedingly
On Saturday, 28 November 2015 at 21:05:24 UTC, Adam D. Ruppe
wrote:
On Saturday, 28 November 2015 at 20:27:02 UTC, Warwick wrote:
It's kind of like saying you can climb a mountain on a bycicle
if you get of an carry it on the bits that are too steep.
*snip*
The real story is how easy D makes it
On Friday, 27 November 2015 at 16:54:11 UTC, Guillaume Piolat
wrote:
Exactly, that's like all the talk about "scaling" or "big data"
on the Internet. Problems we wish we had.
All commercial websites can benefit from automatic scaling, load
balancing and fully managed systems:
1. You get rid
On Saturday, 17 October 2015 at 16:27:08 UTC, Sean Kelly wrote:
Oh absolutely. My issue with the benchmark is just that it
claims to be a JSON parser benchmark but the bulk of CPU time
is actually spent parsing floats.
Well, most of such language-comparison benchmarks are just for
fun/marketi
On Saturday, 17 October 2015 at 13:09:45 UTC, Marco Leise wrote:
Am Sat, 17 Oct 2015 11:12:08 +
schrieb Ola Fosheim Grøstad
:
[…] you could try to construct a simple benchmark where you
iterate over memory (M*cache 3 size) using a "realistic"
pattern like brownian motion in N t
On Saturday, 17 October 2015 at 09:30:47 UTC, Marco Leise wrote:
It is trivial to read into an allocated block when the file
size is below a threshold. I would just need a rough file size.
Are you talking about 4K pages or mega-bytes? 64 KiB maybe?
Maybe, I guess you could just focus on what y
On Saturday, 17 October 2015 at 08:20:33 UTC, Daniel N wrote:
On Saturday, 17 October 2015 at 08:07:57 UTC, Martin Nowak
wrote:
On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise
wrote:
- Data size limited by available contiguous virtual memory
Mmaping files for sequential reading i
On Friday, 16 October 2015 at 21:01:02 UTC, Steven Schveighoffer
wrote:
The distribution is implied in the comment. If there isn't
distribution, the license taint isn't important, why bring it
up?
That was not implied. You can have a license which is much more
limiting, the GPL is fairly libe
On Friday, 16 October 2015 at 18:53:39 UTC, Steven Schveighoffer
wrote:
And I don't disagree with your point, just that it was not a
correct response to "but you definitely can't link any
proprietary code aganist [sic] it."
That I don't understand. You can indeed build your executable
from a
On Friday, 16 October 2015 at 17:38:01 UTC, Steven Schveighoffer
wrote:
For example, let's say you have a product that doesn't use
JSON. It's proprietary, and you distribute it under a
proprietary license. You want to include JSON parsing, so you
incorporate this GPL'd library. Then you distrib
On Friday, 16 October 2015 at 15:36:26 UTC, Steven Schveighoffer
wrote:
You certainly can link with it, and then your code becomes GPL.
No, the code is code. It is an artifact. The GPL is a legal
document. The legal document says what rights you have to the
copy you received and what requirem
On Friday, 16 October 2015 at 14:09:13 UTC, Nick Sabalausky wrote:
This is the real reason I'm not a huge fan of *GPL. Nobody can
understand it!
It is really simple!! The basic idea is that people shouldn't
have to reverse engineer software they use in order to fix
it/modify it, so when you r
On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer
wrote:
No, you cannot link against GPL library without making your
code also GPL. "Services" I don't think have anything to do
with this, we are talking about binary linking.
Yes, you can. GPL is a copyright license which says th
On Friday, 16 October 2015 at 15:07:17 UTC, Ola Fosheim Grøstad
wrote:
GPL, on the other hand, gives the same right to users of a
service.
Typo, "AGPL", not "GPL"...
On Thursday, 15 October 2015 at 22:13:07 UTC, Jonathan M Davis
wrote:
On Thursday, October 15, 2015 14:51:58 Johannes Pfau via
Digitalmars-d-announce wrote:
BTW: Is there a reason why the code is GPL licensed? I
understand that people might want to use more restrictive
licenses, but isn't LGPL
On Friday, 16 October 2015 at 06:18:18 UTC, Jacob Carlborg wrote:
On 2015-10-15 23:27, Jack Stouffer wrote:
Xcode supports D? And I thought that LDC was the only compiler
that
outputs info for LLDB?
No, but it works as good as the underlying debugger that is
used. Which in this case is lack
On Monday, 12 October 2015 at 18:25:57 UTC, Iain Buclaw wrote:
On 12 October 2015 at 08:32, Ola Fosheim Grøstad via
Digitalmars-d-announce
wrote:
On Monday, 12 October 2015 at 06:07:16 UTC, Shriramana Sharma
wrote:
naah... [Is it even possible to write a Go/Rust compiler in
Go/Rust? Or
On Monday, 12 October 2015 at 06:07:16 UTC, Shriramana Sharma
wrote:
naah... [Is it even possible to write a Go/Rust compiler in
Go/Rust? Or have they tried?]
Go is implemented in Go.
Rust is implemented in Rust + C++.
On Sunday, 11 October 2015 at 17:57:54 UTC, Meta wrote:
Just a joke; I consider this a terrible aspect of D.
:) I never know what is a joke or not in the forums these days.
Anyway, a key difference is that a key inspiration for both BETA
and also the actor model is modelling physical (or ima
On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote:
On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad
wrote:
That also means that BETA does not distinguish between a
function call and an assignment.
Hey, neither does D!
writeln("Hello, World!");
writeln = &qu
On Sunday, 11 October 2015 at 01:52:12 UTC, deadalnix wrote:
On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg
wrote:
In Ruby, no one will ever use empty parentheses for calling a
method.
That's actuall
On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg
wrote:
In Ruby, no one will ever use empty parentheses for calling a
method.
That's actually the same as Simula. Functions/procedures with no
parameters is called without parentheses.
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
To me the whole property discussion looks like one of those
endless debates about an insignificant detail.
Scala and Ruby seem to do well with sloppy parens.
Strict typing and explicitness has a real effect on code
legibility a
On Sunday, 27 September 2015 at 16:54:52 UTC, Martin Nowak wrote:
On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote:
I haven't read the paper, but how does this solve collecting
things like strings, or other "leaf types" when you use
separate compilation units?
We'd
On Thursday, 24 September 2015 at 00:08:18 UTC, Martin Nowak
wrote:
The key to a low latency/high throughput GC is being able to
incrementally collect the heap. There is a very interesting
paper that uses the type system to perform incremental
collections.
http://forum.dlang.org/post/mcqr3s$c
On Tuesday, 22 September 2015 at 15:53:22 UTC, Kagamin wrote:
Of course you didn't. In C you can mutate const object without
cast. But it's not an issue because it's not what is usually
done and usually const works as expected.
No. Const objects are read only. Writing to read only objects
wou
On Tuesday, 22 September 2015 at 15:11:55 UTC, Kagamin wrote:
Another C feature you didn't know about: the standard allows to
create a mutable pointer to const data and mutate it.
I didn't? Of course I did. In C++ other threads can write to
const objects. The function receiving a const objects
On Tuesday, 22 September 2015 at 14:46:24 UTC, Kagamin wrote:
I believe I've seen const declarations in C incorrectly
declared as head const when transitive const was really wanted,
but it wasn't done because transitive const in C is so much
PITA. So the only real concern here is mangling.
Th
On Tuesday, 22 September 2015 at 09:01:07 UTC, Chris wrote:
But that's very annoying to work with and more pain than gain.
I don't know... unique_ptr in C++ is quite ok for managing
resources, but it does not track "borrowed pointers". But as I
point out one can:
1. do it in runtime in debu
On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote:
My understanding is that the key benefit of Rust's system is
that compile time checks don't have the runtime costs of smart
pointers.
+ aliasing information.
If the compiler can prove that two pointers point to
non-overlapping memor
201 - 300 of 319 matches
Mail list logo
