On 11.08.2012 18:13, bearophile wrote:
David:
Thanks! I thought modulo should alawys yield the same ... seems like I
was wrong ;)
It's C design that's wrong.
And it's the processor design that makes it inefficient to correct it
nowadays.
Python's definition of modulo is far more useful t
In my experience, TortoiseGIT is rather awkward to use. Anyone looking
for a GUI for git should have a look at SmartGIT. It is commercial but
zero cost for non-commercial use, available for Win/Mac/Linux and I
don't know any other GUI that comes even close in quality.
I guess there will always
I fully agree! I wonder why the comma operator made it into D at all.
This would have been exactly the kind of nasty language details that D
could have cleaned out.
On 21.04.2012 14:23, Benjamin Thaut wrote:
Hi,
I just had a bug due to the unitentional usage of the comma operator. So
I'm won
On 16.04.2012 05:22, Mehrdad wrote:
So we're removing it to reduce the number of keywords? ...Why?
Is the keyword-ness of "cdouble" and "ifloat", etc. causing problems for
people?
Not problems, but serious eye sores: Personally, I am really happy that
"ireal" and "creal" are going to drop out
On 24.03.2012 17:18, "Timo Westkämper" " wrote:
I am trying to get started with D programming. My target is to write LV2
plugins (http://lv2plug.in/trac/) with it, but it seems there aren't any
ready made bindings.
Do you know of anyone else who would have gone into this direction?
I did some
On 10.02.2012 22:04, Andrei Alexandrescu wrote:
On 2/10/12 12:54 PM, Tim Krimm wrote:
On Friday, 10 February 2012 at 20:21:53 UTC, Andrei Alexandrescu wrote:
On 2/10/12 11:02 AM, Tim Krimm wrote:
We have C and C++
How about D- and D?
No please.
Andrei
Please elaborate.
The last thing w
On 12.01.2012 23:10, Peter Alexander wrote:
On 12/01/12 8:13 PM, Norbert Nemec wrote:
Considering these hardware details of the SSE architecture alone, I fear
that portable low-level support for SIMD is very hard to achieve. If you
want to offer access to the raw power of each architecture, it
On 06.01.2012 02:42, Manu wrote:
I like v128, or something like that. I'll use that for the sake of this
document. I think it is preferable to float4 for a few reasons...
I do not agree at all. That way, the type looses all semantic
information. This is not only breaking with C/C++/D philosoph
On 07.12.2011 18:14, Sean Cavanaugh wrote:
On 12/5/2011 3:22 PM, Norbert Nemec wrote:
On 05.12.2011 21:40, Tobias Pankrath wrote:
Right - thanks for the hint!
That would leave the following rules for real-time audio code in D:
[snip]
What's about message passing? Is message passing
On 05.12.2011 21:40, Tobias Pankrath wrote:
Right - thanks for the hint!
That would leave the following rules for real-time audio code in D:
[snip]
What's about message passing? Is message passing hard real time ready?
The issue actually came up for me a few weeks ago.
In principle, all yo
On 04.12.2011 21:04, Walter Bright wrote:
You're right, except for one point. If we ever do a moving GC, then the
GC has to either know about all the pointers (so it can modify them) or
the pointers must be 'pinned' (the pointed to object cannot be moved).
The way to 'pin' an object in D is to h
Dec 4, 2011, at 5:08 AM, Norbert Nemec wrote:
On 04.12.2011 09:10, Marco Leise wrote:
Am 03.12.2011, 19:47 Uhr, schrieb Andrej Mitrovic
:
On 12/3/11, Marco Leise wrote:
Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic
:
+1 on interest on having this. Back when I was attempting to port VST
t
On 04.12.2011 09:10, Marco Leise wrote:
Am 03.12.2011, 19:47 Uhr, schrieb Andrej Mitrovic
:
On 12/3/11, Marco Leise wrote:
Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic
:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can
On 04.12.2011 12:53, Jacob Carlborg wrote:
On 2011-12-03 19:05, Andrej Mitrovic wrote:
+1 on interest on having this. Back when I was attempting to port VST
to D I got asked by a Steinberg dev how I can guarantee that D plugins
will work. But I couldn't guarantee it, if a GC collection were to r
Actually, I find a newsgroup far superior to a mailing list for this
purpose. Reading and Archiving integrated in the same system and
accessible with the same client. Far less total traffic, since only
those contributions need to be transmitted that are actually read.
It is a pity that newsgro
On 21.11.2011 13:16, Kagamin wrote:
Norbert Nemec Wrote:
On 20.11.2011 21:07, Andrei Alexandrescu wrote:
On 11/20/11 10:41 AM, Norbert Nemec wrote:
[snip]
Why not follow the patter of isXxx in the standard library?
Andrei
Actually, that was my starting point. However, this approach does
On 21.11.2011 09:24, Tobias Pankrath wrote:
Actually, that was my starting point. However, this approach does not
scale up:
A concept typically is a collection of requirements that have to be met
individually. A huge boolean statement inside an assertion does not give
any clue as to which part o
On 20.11.2011 21:07, Andrei Alexandrescu wrote:
On 11/20/11 10:41 AM, Norbert Nemec wrote:
[snip]
Why not follow the patter of isXxx in the standard library?
Andrei
Actually, that was my starting point. However, this approach does not
scale up:
A concept typically is a collection of
On 20.11.2011 21:03, Ali Çehreli wrote:
On 11/20/2011 11:36 AM, Norbert Nemec wrote:
Collecting individual requirements as an AND expression of booleans does
not allow any helpful error message. If just one of the requirements is
not met, there is just one failure of the global assertion.
dmd
Nice! That really improves things! Looking forward to playing with it a
little more...
On 20.11.2011 20:31, Denis Shelomovskij wrote:
Your example, a bit improved:
---
// In std.concept, e.g.
template verify(alias concept, T) {
//static assert(isConcept!concept, concept.stringof ~ " is not a
On 20.11.2011 19:58, Denis Shelomovskij wrote:
void myfunction(A)(A arr)
if(__traits(compiles, verifyMyConcept!(A)))
{
}
It should be
---
void myfunction(A)(A arr)
{
verifyMyConcept!A;
}
---
to see the error messages.
Indeed - that way you win a meaningful error message but you loose the
pos
al library.
Greetings,
Norbert
On 20.11.2011 19:47, Ali Çehreli wrote:
On 11/20/2011 08:41 AM, Norbert Nemec wrote:
> Hi there,
>
> back in the discussions about C++-"concepts" it was argued that
> D-template-parameter constraints allow you to achieve the same goal.
Ha
Hi there,
back in the discussions about C++-"concepts" it was argued that
D-template-parameter constraints allow you to achieve the same goal.
Now, I find it fairly difficult to come up with a clean solution for
this that actually scales up for complex libraries. My best attempt so
far is as
On 08.11.2011 05:40, Caligo wrote:
On Mon, Nov 7, 2011 at 7:51 PM, bearophile wrote:
Bartosz talks a bit about the very nicely designed Chapel language:
http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/
(But my appreciation for Chapel design is on other things).
Bye
Strided ranges could be a tertiary operator
similar to
x ? a : b
one could also parse
a .. b : c
as one entity.
About the efficiency issue, once again: for multi-dimensional arrays,
strides have less overhead than for one-dimensional arrays: All but one
dimension need run-time
Have you considered how this mechanism should handle crossing of scope
boundaries?
On 28.10.2011 18:30, Manu wrote:
Hi people.
I'd like to propose support for taking the address of code labels, and
supporting variable goto statements.
This is a feature I have found extremely useful, implement
Where is the fundamental advantage compared to the following?
if(x == "foo") writeln("got foo")
else if(x == "foo") writeln("got foo")
else if(x == "foo") writeln("got foo")
else assert(false);
On 27.10.2011 14:05, Alex Rønne Petersen wrote:
Hi,
Many functional languages have what is called
Excellent! I have toying around with similar ideas for years. Never
found the time to really get into it. :-(
Some ideas below inline.
On 25.10.2011 13:52, Denis Shelomovskij wrote:
What does D already have: build-in rectangular static arrays, dynamic
arrays of arrays, std.range.frontTransvers
On 21.10.2011 06:06, Jonathan M Davis wrote:
It's this very problem that leads some people to argue that string should be
its own type which holds an array of code units (which can be accessed when
needed) rather than doing what we do now where we try and treat a string as
both an array of chars
Do you mean in the sense of symbolic algebraic transformations at
compile time? D would be the prime candidate for that.
If you just want to go for a small solution for your specific problem,
it should actually be quite straightforward to hack up.
A more generic approach like a library should
On 17.10.2011 14:54, Steven Schveighoffer wrote:
Your best bet is to close the application, and possibly print a stack
trace. Trying to continue is like continuing to drive when you get a
flat tire. You are just going to keep damaging your car!
To stick with this nice analogy:
Trying to recove
On 16.10.2011 18:49, Trass3r wrote:
Well it's probably a bug if type is recognized but not rank.
But in general it's really bad code style to use external stuff in a mixin.
True, but it is also quite powerful if used with care. After all the
whole point of "mixin template" is to be able to acc
In fact, I have been wondering about the very same issue. Indeed, it
seems to be possible to catch SIGSEGV in userspace, there even is a
library for this
http://libsigsegv.sourceforge.net/
I have never used it myself, but it would certainly be interesting to
hear about any experience
Hi there,
can anyone give an explanation for the following or is it simply a
compiler bug?
The code below does not compile. I don't see why the enum cannot be
forward referenced across mixin boundaries while the other two forward
references are no problem. (Ordering the mixing statement belo
On 13.10.2011 23:55, Marco Leise wrote:
> I recently wrote JavaScript code that generates a Greek letter starting
> with α (alpha) from an integer. It's just the shortest way to do it that
> works in most languages based on C syntax. I assume I could do it
> another way. Like initializing with a ch
On 11.10.2011 17:48, Gor Gyolchanyan wrote:
> I don't think strides are necessary. You can always opApply your image
> in a certain way. Define a private struct, which has an opApply, which
> iterates over every third channel of each pixel.
> lazy ranges are generally better, then arrays, because w
On 11.10.2011 09:05, Don wrote:
> On 10.10.2011 20:03, Norbert Nemec wrote:
>>
>> Inefficient?! For multidimensional arrays, all but one dimension have
>> non-trivial, runtime-dependent strides anyway.
>
> The problem is with built-in arrays.
Sure. For one-dimensional
On 11.10.2011 15:35, Andrei Alexandrescu wrote:
> On 10/11/11 2:56 AM, bearophile wrote:
>> Since years some people (among them there is me too) are asking for
>> this syntax:
>>
>> int arr[$] = [1,2,3,4];
>>
>> Vote for it here (an enhancement request from 2006!):
>> http://d.puremagic.com/issues/
On 10.10.2011 08:58, Gor Gyolchanyan wrote:
> There is a huge difference between a static and a dynamic array.
> Dynamic array is an indirected type (objects of that type are pointers
> to the actual data), while static arrays are PODs (directly refers to
> the data).
> Dynamic arrays are always si
On 10.10.2011 07:34, Don wrote:
> On 10.10.2011 04:41, kenji hara wrote:
>> 2011/10/10 bearophile:
>>> So is this:
>>> y[$-6, 0..$:2]
>>>
>>> Translated like this?
>>> y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2))
>>
>> I have no thought about it.
>> I'm not sure that the additional
On 10.10.2011 03:18, bearophile wrote:
> kenji hara:
>
>> I got an idea for multidimentional indexing and slicing.
>> http://d.puremagic.com/issues/show_bug.cgi?id=6798
>
> Thank you, you are good.
>
> So is this:
> y[$-6, 0..$:2]
>
> Translated like this?
> y.opIndex(y.opDollar!0 - 6, y.opSlic
Hi there,
after a very busy and eventful year in my personal life, I have now
finally found some time to play with D2. I am very impressed by the
progress!
One thing I noticed was that static arrays are somehow strangely limited:
It is possible to overload based on the length:
void f(i
A language that is adequate for systems programming.
This leaves "adequate" and "systems programming" for definition...
On 10/14/2010 02:30 PM, Justin Johansson wrote:
Touted often around here is the term "systems language".
May we please discuss a definition to be agreed upon
for the usage
On 10/10/2010 09:16 PM, %u wrote:
Basically: because 1GB=infinity for all purposes of logical reasoning.
No no no! :D
If you'd left out logical it would have been just fine :D
I'm not even going to give ridiculous logical proof with this assumption.. no I
will not..
..
assume inf is 1GB.. No!
On 10/12/2010 03:09 AM, Daniel Gibson wrote:
I don't like the name "join" - especially for general ranges.
When I hear join I think of database like joins. These may not be
horribly interesting for strings but certainly are for general ranges (*).
union() or concat() would be better names for doi
On 10/10/10 19:36, %u wrote:
== Quote from Norbert Nemec (norb...@nemec-online.de)'s article
In language design, the theoretical halting problem actually is often an
argument because the compiler does not know the memory limitation at run
time. The finite memory of the machine can therefor
On 10/10/10 17:06, %u wrote:
I am not sure where exactly the line lies where people tend to use impossible
as a
synonym for a hard problem, but I agree that np might well be around that
border.
It depends on "trivial", but I wouldn't call integer factorization impossible.
The point I was tryin
"Impossible to solve" is often used synonymous to "exponentially hard to
solve" meaning, as the problem size (e.g. size of finite memory) grows
as N, the cost for solution grows as exp(N). Of course, the actual cost
of an actual problem always depends on the pre-factor, but experience
shows tha
04, bearophile wrote:
Norbert Nemec:
Which confirms my original position: the final three tests in the
contest are flawed by concept.
Those tree tests may be impossible to do, but they are not flawed (and they are
not impossible to do, see below).
If the actions of eating and slaughtering
are s
Idea: rather than trying to change state, one could attempt a different
approach:
When "food" is "eaten", this action could define a new compile time
object "eater(food)" as some value. When eating something twice, this
would attempt to define the same object as two different values, causing
On 09/29/2010 09:32 AM, Denis Koroskin wrote:
On Wed, 29 Sep 2010 11:21:11 +0400, Norbert Nemec
wrote:
IMHO, the test misses the point of compile-time metaprogramming: The
concept of "state" belongs to run-time. The D compile-time language is
purely functional and does not know
IMHO, the test misses the point of compile-time metaprogramming: The
concept of "state" belongs to run-time. The D compile-time language is
purely functional and does not know a state or even an "order of execution".
The conditions "cannot die or be eaten twice" are, at their core, issues
of s
On 12/09/10 14:48, bearophile wrote:
Norbert Nemec:
Thank you for your clear explanations of the situation.
With FP/DG, this breaks
down and I believe the best one can do is to implement contracts as
run-time checks in the callee, just as it is done in D.
There is also a mixed strategy: to
On 11/09/10 08:18, Jay Byrd wrote:
Contracts do not belong to function pointers or any other
dynamic state -- they apply to the invoker, and thus the static type.
Isn't that obvious?
In fact, it is yet one step more complex than that: as the name itself
suggests, contracts are "between" the ca
On 29/08/10 19:19, Sean Kelly wrote:
Norbert Nemec wrote:
Hi there,
I just spent most of this weekend digging into the DMD compiler code
and came up with a set of patches that might be of interest:
http://d.puremagic.com/issues/show_bug.cgi?id=4713
All started out with the attempt to
Yippie-yeah! My favorite topic is being mentioned! I have to give a
comment... :-)
On 26/08/10 22:38, bearophile wrote:
> [...]
So far in D code I have had need of (and I have seen some people need) some
other kinds of arrays, not (well) supported by D:
C) nD rectangular dynamic arrays;
[...]
On 25/08/10 08:27, Yao G. wrote:
On Wed, 25 Aug 2010 02:09:20 -0500, Norbert Nemec
wrote:
Greetings,
are the ddoc sources of the official D documentation available
somewhere? Ideally as a repository? I thought about trying conversion
to SGML or something similar that would allow various
Greetings,
are the ddoc sources of the official D documentation available
somewhere? Ideally as a repository? I thought about trying conversion to
SGML or something similar that would allow various output formats, a
structured TOC and -- most importantly -- indices!
Norbert
On 24/08/10 13:14, igabrieL wrote:
- the language shootout included ALL other relevant languages, but hated D.
This is very bad
I recall that this was due to the lack of 64bit support and the lack of
a Debian package that would work out of the box. The latter problem may
be solved by now, bu
On 20/08/10 03:22, dsimcha wrote:
3. Is there any good reason to avoid just templating everything to work with
all 9 string types (mutable/const/immutable char/wchar/dchar[]) or whatever
subset is reasonable for the given function?
Wouldn't it be sufficient to take const as input? IIRC, both m
On 24/08/10 08:56, Peter Alexander wrote:
Proposal: Make a..b a literal that evaluates to iota(a, b) or some
built-in equivalent.
Indeed, this has been discussed before and I believe people were
generally in favor of this idea. I agree that it should still be
considered for DMD2. As I see it,
Hi there,
I just spent most of this weekend digging into the DMD compiler code and
came up with a set of patches that might be of interest:
http://d.puremagic.com/issues/show_bug.cgi?id=4713
All started out with the attempt to create .di interface files for
phobos2. The resulting .di fil
I really appreciated the way Peter Langtangen handled this for his book
"Python Scripting for Computational Science": There is an encrypted PDF
for download for which you need a password like "Enter the first word on
page XXX".
Of course such a measure can still be worked around, but it is
su
On 17/08/10 02:49, Andrei Alexandrescu wrote:
bearophile wrote:
This post is about this enhancement request of mine that recently
David Simcha has closed as wontfix:
http://d.puremagic.com/issues/show_bug.cgi?id=4165
[snip]
Phobos functions are meant as the most simpler bricks, that you may
co
I usually do the same thing with a shell pipe
expand | sed 's/ *$//;s/\r$//;s/\r/\n/'
On 07/08/10 02:34, Walter Bright wrote:
I wrote these two trivial utilities for the purpose of canonicalizing
source code before checkins and to deal with FreeBSD's inability to deal
with CRLF line end
May be a (likely) coincidence. I could imagine that any memory that is
freshly acquired from the operating system is initialized somehow before
it is handed over to the application. If the OS left the data written by
some other application, this might cause security problems.
In fact, I verfie
On 03/08/10 22:56, Walter Bright wrote:
bearophile wrote:
27.50, "transactional file copy": this example was script-like, and as
short
as possible to fit into one single slide, so in this case I think using
enforce() is OK. But in true programs I suggest all D programmers to use
DesignByContract
I agree that contracts offer too much liberty. However, I would actually
go one step further than bearophile:
I find the need for "assert" statements not only superfluous but
actually misleading. A contract violation is something conceptionally
different from a broken assertion. Assertions and
In fact, the code contains a bug inside the A_Parser.get function which
implicitely converts stuff from type Report to type A_Report. If you
change the declaration of stuff to
A_Report[string] stuff;
everything should be fine.
Furthermore, your comments seems to confuse the terms co- an
On 25/07/10 23:23, Tomek Sowiński wrote:
If foo is private but its public alias poo exists, should you be able to use
poo? (currently you can't)
Visibility is a property of each symbol, not the object behind it. I see
nothing wrong with allowing aliases as a way to offer public access to
obje
On 02/07/10 13:41, Steven Schveighoffer wrote:
This isn't really the reason for "mangling". The issue is that the C
linker requires symbols to be the same as source symbols. That is, made
up only of A-Z,a-z,0-9 and _. I'd much rather see symbol names like this:
foo(int,string)
than
fooIvS45wha
Not quite sure: Page 189, bullet points 3 and 4 seem to be turned around.
The imported module runs before the importing module. Testing DMD
confirms my understanding. Am I understanding the text correctly?
Greetings,
Norbert
On 30/06/10 17:45, Sean Kelly wrote:
Norbert Nemec Wrote:
On 28/06/10 12:59, bearophile wrote:
Norbert Nemec:
[...] to place code for input contract checking in the *calling* code. [...]
Output contract checks, on the other hand should be compiled inside the
returning routine.
Is this a
he
problem. An anonymous "enforce" on the other hand is a quick-and-dirty
solution that does not help the developer very much to identify the real
problem.
Norbert Nemec says some good things.
I think it's an area where reasonable people may disagree.
Thanks bearophile, thanks An
On 28/06/10 12:59, bearophile wrote:
Norbert Nemec:
[...] to place code for input contract checking in the *calling* code. [...]
Output contract checks, on the other hand should be compiled inside the
returning routine.
Is this a positive thing to do? Can this be done? (D must support
On 20/06/10 22:17, Walter Bright wrote:
An input to a dll is user input, and should be validated (for the sake
of security, and other reasons). Validating it is not debugging.
In that case, feel free to compile DLLs with external contract checking
switched on, but please do not blur the concep
On 19/06/10 22:46, Andrei Alexandrescu wrote:
On 06/19/2010 03:55 PM, bearophile wrote:
Inside Phobos2 I have counted about 160 usages of the "body" keyword.
I think contract programming can be used more often inside Phobos2
(and maybe some usages of enforce() can be turned into contract
program
Hi there,
I just encountered a few issues with array expressions (2.047)
* Implicit type conversion does not work. On the snippet
-
auto a = [1,2,3];
auto b = [2.5,3.5,4.5];
auto d = new real[2];
d[] = a[]+d[];
-
the compiler first
On 22/06/10 00:35, Leandro Lucarella wrote:
Andrei Alexandrescu, el 21 de junio a las 17:43 me escribiste:
If efficiency is still sub-par, retro could detect that it's working
with iota and generate specialized code. That's not too difficult;
for integers, retro(iota(a, b)) could actually be a r
On 28/04/10 19:34, Andrei Alexandrescu wrote:
On 04/28/2010 12:50 PM, Ezneh wrote:
Andrei Alexandrescu Wrote:
I put a countdown on my website (http://erdani.com/) displaying the
days left to final bound dead-tree copies of TDPL. Also, the book
cover (front and back) is now available for previe
On 08/05/10 14:24, Lutger wrote:
3: The C++ and meta-object compiler are not the core of it's success, but
rather the combination of:
- well-designed
- HUGE coherent framework
- good cross-platform capability
- both open source and commercial
- used by KDE, sponsored by Nokia
Add to this:
- exc
On 27/04/10 16:57, bearophile wrote:
@manifest int x = 2010; // we use this. :-) :D
I don't like that a lot :-) It's almost worse than "enum". Try again.
I have seen other languages use "param" for compile time constants. This
follows the ancient Fortran tradition where "parameter" has alway
I still do not think that there is a need for loop invariants as an
explicit language feature. Putting an assertion at the beginning of a
loop achieves the same purpose. The difference in clarity is marginal,
in my opinion.
This does not say anything about their use in helping designing a loop
I am less worried about the size than about the quality.
Replacing any part of the standard library is an act similar to changing
the language definition, so including new modules into the library
should be done with as much care as including new features into the
language.
Apart from that,
bearophile wrote:
Norbert Nemec:
D is clearly designed as language that can be compiled to a static binary.<
Just to be sure you have understood: the solution number 5 is for a statically
compiled language. It doesn't need a JIT. You just need normal objects, a
virtual table, e
bearophile wrote:
4) C# avoids code bloat because it has a JIT and templates are instantiated at
run-time. D can of course do the same if it uses the LLVM backend, but let's
ignore this possibility for now.
5) Java generics don't cause code bloat because it removes the types at runtime
and us
Just out of curiosity: Which aspect of D do you find interesting enough
to make it worth spending your own time to discuss on the D mailing
list? From your message it seems that you find the whole concept of D
pointless. Personally, if I find a project pointless, I typically
choose to ignore it
bearophile wrote:
This Go syntax is cute:
Pointer to int: *int
Array of ints: []int
Array of pointer to ints: []*int
Pointer to array of ints: *[]int
In D it becomes:
Pointer to int: int*
Array of ints: int[]
Array of pointer to ints: int*[]
Pointer to array of ints: int[]*
Here I think I like
Sure: whatever problem you want to solve in D can be solved by any other
turing-complete language just as well...
Still, there are many problems that can be solved in D far more
elegantly than in other languages. And since programmers are humans,
elegance is essential for correctness and manag
Walter Bright wrote:
Norbert Nemec wrote:
Walter Bright wrote:
The trouble with a generator using the caller's stack is that then
the generator cannot recursively call itself (such as if it was
walking a tree). In order to work properly in the general case, a
generator has to allocat
Walter Bright wrote:
The trouble with a generator using the caller's stack is that then the
generator cannot recursively call itself (such as if it was walking a
tree). In order to work properly in the general case, a generator has to
allocate all its local variables on the heap.
Which concep
Walter Bright wrote:
Norbert Nemec wrote:
Regan Heath wrote:
So, these generators are essentially inline functions?
No. They may be inlined, but this is just an optimization just like
for regular functions. If they are not inlined, these generators are
simply functions with a special
Regan Heath wrote:
So, these generators are essentially inline functions?
No. They may be inlined, but this is just an optimization just like for
regular functions. If they are not inlined, these generators are
simply functions with a special calling convention that allows them to
retain th
I really like that simplified, "yield"-based syntax. However, I believe
that it conflicts fundamentally with D's confusing concept of generators.
Most other languages that offer generators (e.g. Python) view the
generator as an object that spits out values one-by-one. This is very
similar to a
bearophile wrote:
Michel Fortin:
This compiles, but should it?
I think the @safe attribute is not significant here, because that code is
wrong, in unsafe code too.
I think DMD lets it pass because it's not able to spot the bug. I don't know if
and when it will be able to trace such situation
Don wrote:
Multidimensional slices normally result in appallingly inefficient use
of caches.
Indeed, cache usage is a challenge. My general approach would be fairly
conservative: give the user full control over memory layout, but do this
as comfortably as possible. Provide good performance fo
Andrei Alexandrescu wrote:
Norbert Nemec wrote:
Multidimensional arrays are the essence of the interfaces of most
numerical libraries. Having several incompatible standards is a major
roadblock for acceptance in the numerical community.
I'm not so sure about that. I was very enthusi
Fawzi Mohamed wrote:
On 2010-03-09 09:47:17 +0100, Norbert Nemec said:
Ellery Newcomer wrote:
On 03/08/2010 08:49 PM, bearophile wrote:
Admitted, the last case does not work quite as nicely with ".." as it
does with Python's ":". Still, the point should be clear.
Ellery Newcomer wrote:
On 03/08/2010 08:49 PM, bearophile wrote:
Admitted, the last case does not work quite as nicely with ".." as it
does with Python's ":". Still, the point should be clear.
I have never understood why Walter has adopted .. for slices instead
of the better :
I'd like to
bearophile wrote:
D won't be frozen forever, eventually few new things will be added, for example
in D3. For example probably some of the limits of CTFE will be removed. Even C
language and Fortran keep having changes every ten years or so.
What will be hard to do are changes/removals. It's imp
1 - 100 of 135 matches
Mail list logo
