thanks for sharing
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu
wrote:
to fully focus on pushing D forward.
insert dick joke here
Could you share your experience with us? How it compares to go
implementation? Did D made it harder or easier to implement
emulator?
On Sunday, 4 February 2018 at 20:56:32 UTC, blahness wrote:
2. DMD just doesn't produce fast code compared to other modern
compilers. It's a shame LDC or GDC isn't the default D compiler.
For the core team improving DMD codegen is not a priority
On Wednesday, 7 November 2018 at 00:01:13 UTC, Walter Bright
wrote:
On 11/6/2018 3:00 PM, H. S. Teoh wrote:
What sort of refactoring are we looking at? Any low-hanging
fruit here
that we non-compiler-experts can chip away at?
Simply going with foreach loops is a nice improvement.
Thas
On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:
I don't know why you think that would matter: I'm using the
same compilers to build each DMD version and comparing the
build times as the backend was translated to D
What did you compared is whether clang or DMD compiles code
On Tuesday, 6 November 2018 at 19:01:58 UTC, H. S. Teoh wrote:
It looks like it would be really useful one day when I try to
tackle the dmd-on-lowmem-system problem again.
Based on my profiling it seems that most memory is allocated in
void importAll(Scope* sc) found in attrib.d . A person
On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov
wrote:
One keystroke (well ok, two keys because it's *) ;)
https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png
What sorcery is this? I need to know. I guess its vim but how
does it highlight symbols?
On Thursday, 8 November 2018 at 18:52:02 UTC, H. S. Teoh wrote:
length is getting ridiculous
Having better editor support is nice but by "use better editor"
you meant use vim dont you? And even if I switch to vim it wont
solve my initial objection to one letter variable names. Its
needless
On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote:
I don't speak for the compiler devs, but IMO, one-letter
variables are OK if they are local, and cover a relatively
small scope.
By saying more descriptive I should have clarified that I meant
to change them to 3-7 letter
On Wednesday, 7 November 2018 at 22:03:20 UTC, Walter Bright
wrote:
Single letter names are appropriate for locally defined
symbols. There's also an informal naming convention for them,
changing the names would disrupt that.
And where can i read about naming convention? My guess its not
On Tuesday, 15 January 2019 at 11:59:58 UTC, Atila Neves wrote:
He's not saying "kill classes in D", he's saying an OOP system
in D could be implemented from primitives and classes don't
need to be a language feature, similar to CLOS in Common Lisp.
For some people writing OOP means writing
On Friday, 23 November 2018 at 16:21:53 UTC, welkam wrote:
If you want to read data from that bool CPU needs to fetch 8
bytes of data(cache line of 64 bits). What this means is that
for one bit of information CPU fetches 64 bits of data
resulting in 1/64 = 0.015625 or ~1.6 % signal to noise
On Tuesday, 4 December 2018 at 11:02:11 UTC, Jacob Carlborg wrote:
On 2018-12-02 17:57, welkam wrote:
What a timing. I am working on (slowly) on a tool that would
get all struct and class declarations and for each of them get
functions in which they are used. Then combine them with
profiling
On Friday, 30 November 2018 at 20:10:05 UTC, Jacob Carlborg wrote:
I would like to announce a new project I've started, called DLP
(D Language Processing). Currently it's quite experimental but
the idea is that it would contain a collection of commands for
inspecting D code in various ways. It
On Friday, 23 November 2018 at 14:32:39 UTC, Vladimir Panteleev
wrote:
On Friday, 23 November 2018 at 13:23:22 UTC, welkam wrote:
If we run these steps in different thread on the same core
with SMT we could better use core`s resources. Reading file
with kernel, decoding UTF-8 with vector
On Wednesday, 21 November 2018 at 10:56:02 UTC, Walter Bright
wrote:
Wouldn't it be awesome to have the lexing/parsing of the
imports all done in parallel?
From my testing lexing/parsing takes small amount of build time
so running it in parallel might be small gain. We should consider
On Thursday, 22 November 2018 at 04:48:09 UTC, Vladimir Panteleev
wrote:
Sorry about that. I'll have to think of two titles next time,
one for the D community and one for everyone else.
If it's of any consolation, the top comments in both discussion
threads point out that the title is
On Friday, 23 November 2018 at 19:21:03 UTC, Walter Bright wrote:
On 11/23/2018 5:23 AM, welkam wrote:
Currently D reads the all files that are passed in command
line before starting lexing/parsing, but in principle we could
start lexing/parsing after first file is read. In fact we
could
I just updated DMD on my windows and tried to compile hello
world. It took 7.4 sec. Something is not right. Can anyone
reproduce? On the same mashine running linux it compiles and runs
in 0.1 sec
PS C:\Users\Welkam\Desktop\Projects> Measure-Command {dmd -run
main.d}
Days : 0
On Saturday, 17 November 2018 at 12:36:30 UTC, rikki cattermole
wrote:
Just in case, did you disable your anti-virus first?
Had to edit registry to turn that thing off and it still some
times popup. Microsoft is so annoying.
https://imgur.com/a/x3cKjZm
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
Libc implementations of fundamental operations, esp. memcpy,
are usually optimized to next > week and back for the target
architecture, taking advantage of the target arch's quirks to >
maximize performance
Yeah about that...
Level1
On Sunday, 8 March 2020 at 03:56:35 UTC, Era Scarecrow wrote:
From what i've researched, it's more or less the flu... a
somewhat more contagious, over-hyped, genetically modified,
potentially respiratory infection cold/flu; And likely a tool
by government(s) to force unwanted policies down
On Friday, 1 May 2020 at 10:54:55 UTC, zoujiaqing wrote:
<...>
I did a quick look and it looks like http server + some goodies.
Is this a correct assessment? If yes what is the status of http
2.0, ssl and bzip support?
On Monday, 4 May 2020 at 17:30:41 UTC, Arine wrote:
On Monday, 4 May 2020 at 17:01:01 UTC, Robert M. Münch wrote:
Besides getting the work done, there is one constraint: The
work needs to get into Phobos. It doesn't make sense to have
it sit around, because it's not being merged. I don't have
On Thursday, 7 May 2020 at 09:18:04 UTC, Ali Çehreli wrote:
Because D is a re-engineering of C++
I thought it was re-engineering of C
On Thursday, 14 May 2020 at 08:42:43 UTC, ShadoLight wrote:
On Wednesday, 13 May 2020 at 19:25:43 UTC, welkam wrote:
On Thursday, 7 May 2020 at 09:18:04 UTC, Ali Çehreli wrote:
Because D is a re-engineering of C++
I thought it was re-engineering of C
This opinion seems quite common in the
On Friday, 15 May 2020 at 14:42:47 UTC, Dmitry Olshansky wrote:
compiler usually explodes trying to swallow it
https://media.giphy.com/media/tfxgAK370HzEY/giphy.gif
On Tuesday, 19 May 2020 at 09:54:38 UTC, Iain Buclaw wrote:
Walter raised a pull request to merge the and and and or or AST
nodes into a logical logical operator, and the initial rebuttal
was that he's used log log for and and or or or operators for a
very (very) long time.
Now this is gold.
On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote:
Hi everyone,
as the subject states, you can find it here,
https://codefence.io/
The current version is 2.092.0 with dmd.
Regards,
Why such thing is free? Who pays for the servers?
On Friday, 1 May 2020 at 16:32:27 UTC, Heromyth wrote:
On Friday, 1 May 2020 at 13:11:23 UTC, welkam wrote:
On Friday, 1 May 2020 at 10:54:55 UTC, zoujiaqing wrote:
<...>
I did a quick look and it looks like http server + some
goodies. Is this a correct assessment? If yes what is the
status
On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote:
To be honest the analysis doesn't quite stack up. Because
compatibility is not the reason for the success of Go, or Rust.
I would say the success of a language depends on many factors:
Think of a reasons of why people are
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all comments and didnt saw any mockery
On Saturday, 19 December 2020 at 05:08:56 UTC, Max Haughton wrote:
This will soon support Linux's perf_event so you will be able
to measure cache misses (and all the other thousands of pmc's
intel expose), use LBR msrs etc.
Are you going to read stdout from calling perf or are you going
to
On Sunday, 3 January 2021 at 06:35:23 UTC, 9il wrote:
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves
wrote:
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32
On Monday, 4 January 2021 at 22:55:28 UTC, Ola Fosheim Grøstad
wrote:
It is a name, e.g.:
alias BarInt = Bar!int;
"BarInt", "Bar!int" and "Foo!int" are all names, or labels, if
you wish. And they all refer to the same object: the nominal
type. Which you can test easily by using
On Tuesday, 5 January 2021 at 15:10:29 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 January 2021 at 15:04:34 UTC, welkam wrote:
Also how "i'm like you" is an insult?
I don't think I should reply to this…
Then dont replay to this sentence. My post had more than one
sentence.
Also the
On Wednesday, 23 December 2020 at 22:13:09 UTC, Ola Fosheim
Grøstad wrote:
The big picture that the DIP suggested was that when stuff like
this fails to compile:
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
auto foo = Bar!int();
f(foo);
}
On Tuesday, 5 January 2021 at 21:46:34 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 January 2021 at 21:43:09 UTC, welkam wrote:
Replace alias Bar(T) = Foo!T; with alias Bar = Foo;
struct Foo(T) {}
alias Bar = Foo;
void f(T)(Bar!T x) {}
void main() {
auto foo = Bar!int();
f(foo);
}
On Sunday, 3 January 2021 at 22:50:16 UTC, Ola Fosheim Grøstad
wrote:
YOU DO HAVE TO ACKNOWLEDGE A TYPE SYSTEM BUG!
If an indirection through an alias causes type unification to
fail then that is a serious type system failure. No excuses
please...
Different people have different definitions
On Monday, 4 January 2021 at 01:19:12 UTC, jmh530 wrote:
it makes things overly complicated
Just because a feature makes something simpler is not enough of
an argument of why it should be added. Case and point C, lua and
Go languages. They are popular in part because they are simple.
That's
41 matches
Mail list logo
