On Friday, 29 July 2016 at 22:44:04 UTC, Walter Bright wrote:
http://70sdisconights.com/
Yes, I listen to it while I work.
For a somewhat more...traditional genre:
http://musopen.org/radio
On Wednesday, 27 July 2016 at 07:59:54 UTC, Walter Bright wrote:
"The expression assert(0) is a special case; it signifies code
that should be unreachable. If it is reached at runtime, either
AssertError is thrown or execution is terminated in an
implementation-defined manner. Any code after th
On Wednesday, 6 April 2016 at 20:48:20 UTC, Lucian Radu
Teodorescu wrote:
Compared to CTFE, in Sparrow you can run at compile-time *any*
algorithm you like. No restrictions apply. Not only you can do
whatever your run-time code can do, but can also call external
programs at compile-time.
Imag
On Wednesday, 6 April 2016 at 18:25:11 UTC, BLM768 wrote:
Aside from the explicit annotations, I don't see how their
solution is more flexible than D's CTFE, but I might be missing
something.
Never mind. Just saw their language embedding example. Neat!
On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei Alexandrescu
wrote:
On the plus side Sparrow has a smoother integration of
compile-time vs. run-time computation, which makes it a bit
easier to transition from one to another.
Aside from the explicit annotations, I don't see how their
soluti
On Thursday, 31 March 2016 at 20:51:53 UTC, Jack Stouffer wrote:
Wouldn't just be better to use a std.allocator backed set
container instead over special casing the AA syntax like this?
Syntactically, that makes more sense.
Or there's always ubyte[0][T].
On Wednesday, 30 March 2016 at 22:20:02 UTC, John Colvin wrote:
import std.functional : pipe;
alias allThree = pipe!(foo, bar, baz);
:)
Interesting, but I'd call that a concatenative sub-language at
most. ;)
There's certainly some conceptual overlap between concatenative
languages and D un
On Wednesday, 30 March 2016 at 20:53:02 UTC, Shammah Chancellor
wrote:
I just stumbled on this wikipedia article:
https://en.wikipedia.org/wiki/Concatenative_programming_language
Seems like D falls under that category?
-S.
Not really. UFCS allows the syntax "x.foo.bar.baz", which is
similar
On Saturday, 19 March 2016 at 08:38:20 UTC, Basile B. wrote:
Otherwise there's something that's pretty in the syntax:
Very much so. My own "toy language" project uses (well, _will_
use once I have more than 5% of a parser) a similar syntax, so it
could just be my own biases talking, but I li
On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad
wrote:
I wonder what kind of programming people plan or _hope_ to use
D for in 2016?
8. or something else?
The toy language bug has bitten me, too. I'm going for maximum
modularity in the compiler to make it easy to hook in fanc
On Sunday, 3 January 2016 at 01:51:35 UTC, Jonathan M Davis wrote:
So, we have ELF binaries and DWARF exceptions. Are we going to
get something related to orcs or goblins next? ;)
- Jonathan M Davis
I don't know about that, but with better C++ interop, it might be
easier to bind to OGRE. (Se
On Monday, 21 December 2015 at 15:09:06 UTC, Adam D. Ruppe wrote:
Dedicated pages is a good idea and can be done trivially with
ddoc macros to avoid repetition of the content in the source.
It could also be a css :hover dropdown instead of JS, but I
hate drop downs on hover so I'd prefer the d
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg
wrote:
Thoughts?
The template constraints being on their own line is a nice touch.
Overall, the design looks very clean-cut. The only real issue I
see is that it could use a bit more contrast. Those light gray
lines fade into the
On Friday, 18 December 2015 at 00:03:06 UTC, extrawurst wrote:
What PR is that ? Link ?
--Stephan
https://github.com/D-Programming-Language/dmd/pull/5290
It adds some __traits that would make it easier for me to
introspect my binding modules and generate glue code. Right now,
I'm using seve
On Thursday, 17 December 2015 at 23:50:34 UTC, Andrei
Alexandrescu wrote:
* "Examples:" is a historical error. All instances should be
"Example:". Just one diff making that change throughout would
be a meaningful contribution.
Like so?
https://github.com/
On Thursday, 17 December 2015 at 19:50:40 UTC, Andrei
Alexandrescu wrote:
If you have some time and motivation to improve the
documentation, there's tremendous opportunity for impact. So
much low-hanging fruit, all well before we explore switching to
a different way of building the site. And wh
On Thursday, 17 December 2015 at 17:38:31 UTC, Ali Çehreli wrote:
I am stealing HerrDrFaust's question from the following Reddit
thread:
https://www.reddit.com/r/programming/comments/3wqt3p/programming_in_d_ebook_is_at_major_retailers_and/
Please answer here or there.
Thank you,
Ali
Well,
On Thursday, 17 December 2015 at 07:51:42 UTC, Jacob Carlborg
wrote:
On 2015-12-17 00:43, BLM768 wrote:
One is to make as much of it as possible in plain old
static HTML. Stuff like the articles rarely changes, after all.
This is an horrible idea. No sane person would use raw HTML.
The only
On Wednesday, 16 December 2015 at 23:49:52 UTC, Andrei
Alexandrescu wrote:
But I dislike typing HTML. DDoc improves on that significantly.
Fair enough. Vibe.d has diet templates, though. They're pretty
nice.
As long as the pages are mainly static anyway, though, it's all
plain boring HTML t
On Wednesday, 16 December 2015 at 23:43:41 UTC, BLM768 wrote:
[snip]
...and as I read some older posts, I see that mine is completely
redundant. ;)
Seriously, though, I'm willing to help prototype something. I've
got time before the next semester starts.
On Wednesday, 16 December 2015 at 23:01:47 UTC, Walter Bright
wrote:
Exactly.
We'll never get anywhere chasing people who say "I'll help only
if you convert to my way of doing things." I've done enough of
that in the past, and concluded they're just seeing how long
you'll dance to their tune
On Wednesday, 16 December 2015 at 21:00:55 UTC, Andrei
Alexandrescu wrote:
I should add I've argued for including some of the core vibe.d
stuff in Phobos. Sadly nobody is championing such a project for
the time being.
Andrei
Would that include its stream stuff? We've been needing a
std.str
On Sunday, 6 December 2015 at 03:30:51 UTC, Timon Gehr wrote:
log(x^2) = 2 log x.
Why do log rules have to make everything so simple? ;)
On Saturday, 5 December 2015 at 22:56:23 UTC, H. S. Teoh wrote:
Multi-term complexities arise from trivial graph algorithms.
They are not limited to the use of multiple containers. More
precisely, the multiple terms arise because of the structure of
the graph (being composed of nodes and edges)
On Saturday, 5 December 2015 at 20:48:16 UTC, Andrei Alexandrescu
wrote:
On 12/04/2015 10:24 PM, Timon Gehr wrote:
In fact I went through the implementation but soon I hit a
wall: what's the _relationship_ between the two growths? It may
be the sum O(m + n) but also the product O(m * n). So the
On Saturday, 5 December 2015 at 00:13:02 UTC, BLM768 wrote:
list.removeWithComplexity(Complexity.linear, 3);
Uh, I mean list.removeWithComplexity!(Complexity.linear)(3).
On Friday, 4 December 2015 at 22:17:21 UTC, Jonathan M Davis
wrote:
Either of those would be better than stableLinearRemove or
stable.linear.remove. The UDAs would be more documentation
friendly, though being able to pass around template arguments
could be valuable for the cases where you're tr
On Friday, 4 December 2015 at 18:21:41 UTC, Walter Bright wrote:
I suggested in the pseudo namespaces thread using template
parameters to express characteristics, as in:
remove!(stable, linear)
with sensible defaults so most of the time the user would just
use:
remove
The nice thi
On Tuesday, 1 December 2015 at 18:25:06 UTC, Bubbasaur wrote:
Really, do really believe in what you wrote?
So if you take a look right now, the "YES" option for the
question: "Do you like new
DUB config format?" Is somehow "magically" winning the poll
right now!
Bubba.
Huh. That changed
On Tuesday, 1 December 2015 at 17:26:13 UTC, Andrei Alexandrescu
wrote:
Independent on the topic at hand - wondering what your
reasoning is. I just took a look and there are 205 votes. Not a
large number, but quite a lot more than any voting we saw in
the past (when consensus was proclaimed aft
On Saturday, 28 November 2015 at 18:13:51 UTC, Kagamin wrote:
Then XML is clear winner, its support, spread, availability and
tooling is unmatched.
So is its complexity. ;)
Do we even have a good standard XML parser? std.xml has been
languishing for years...
On Thursday, 26 November 2015 at 23:16:59 UTC, BLM768 wrote:
[snip]
It lists a bunch of symbols that most certainly _aren't_ direct
ancestors of the "std" package: "object", "core", "std",
"KeepTerminator", "GCC_IO", "
On Friday, 27 November 2015 at 19:29:48 UTC, Jacob Carlborg wrote:
Just throwing it out there: CSON [1].
"CoffeeScript-Object-Notation. Same as JSON but for
CoffeeScript objects". It's used by the Atom editor.
[1] https://github.com/bevry/cson
Hmm. Pretty, standardized, similar to JSON. I li
On Thursday, 26 November 2015 at 20:56:39 UTC, Jonathan M Davis
wrote:
Yes, code can forward-reference an import. e.g. this code
compiles just fine:
void main()
{
writeln("Where's my import?");
}
import std.stdio;
Now, when the import is inside of a function, then it c
On Thursday, 26 November 2015 at 19:57:19 UTC, Jacob Carlborg
wrote:
Everyone will hate me for saying this, but in that case, just
go with Ruby (or some other similar language)
That was actually one of my first thoughts. It would be pretty,
but we'd have another dependency then. Also, Ruby doe
On Thursday, 26 November 2015 at 02:20:43 UTC, Daniel Murphy
wrote:
Unfortunately I have no idea. You'll have to have a look at
what other code that resolves packages is doing.
If you can't find it it might be worth emailing Kenji Hara,
since he knows everything.
Well, expression.d seems to
On Wednesday, 25 November 2015 at 22:20:39 UTC, Andrei
Alexandrescu wrote:
It's more like "Do this, no need to argue". There's really no
need, and we're arguing too much over too little. -- Andrei
Is anyone else having flashbacks to Phobos vs. Tango?
In this case, as much as I like how the SDL
On Wednesday, 25 November 2015 at 15:39:17 UTC, Daniel Murphy
wrote:
What you're seeing is just an artifact of how dmd's internals
work. 'std' is an 'import' (call Dsymbol.kind() for the
category of symbol) and you'll have to resolve it to work out
which module/package is being imported. It's
On Wednesday, 25 November 2015 at 15:39:17 UTC, Daniel Murphy
wrote:
What you're seeing is just an artifact of how dmd's internals
work. 'std' is an 'import' (call Dsymbol.kind() for the
category of symbol) and you'll have to resolve it to work out
which module/package is being imported. It'
to my test
program (https://gist.github.com/blm768/42f40aa5a0c49bb8bd16),
these are the "types" of various packages/modules in Phobos:
std:
std.stdio: package, module
std.algorithm: package
std.digest: package
In other words, "std" isn't a package _or_ module, and std.stdi
On Wednesday, 25 November 2015 at 01:06:55 UTC, BLM768 wrote:
In other words, "std" isn't a package _or_ module, and
std.stdio is both (even though it's just a single D source
file). This doesn't seem quite right.
I just confirmed that this also applies to other root
On Friday, 23 October 2015 at 12:42:08 UTC, w0rp wrote:
Does anyone have any thoughts on this topic?
A couple of years ago, I started playing with the idea. The basic
concept was to dump DB records into "dumb" (i.e. representing
just the basic aspects of the model object) structs, which can
On Wednesday, 9 October 2013 at 17:07:18 UTC, monarch_dodra wrote:
That was my point. Writting "Nullable!T == T" is the exact same
thing: Comparison of a value with the absence of a value. It's
neither equal nor different, it's an error.
Equality comparison is a bit different from properties s
On Wednesday, 9 October 2013 at 06:48:31 UTC, monarch_dodra wrote:
OK, so that's two functions already. What about opCmp? What
about toHash?
Since ordered comparisons make no sense with null values, opCmp
would need to throw an exception when working with null values
anyway. That's exactly
On Tuesday, 8 October 2013 at 19:04:33 UTC, BLM768 wrote:
* Making isNull() @property
Hmm... looks like it's already @property. I guess this happened
after the last update to the Phobos docs.
I'll still need to fix the other stuff, though.
On Tuesday, 8 October 2013 at 20:55:35 UTC, monarch_dodra wrote:
Or we could just nuke the alias this. A Nullable!T isn't a T.
It's a T handler. "alias this" allows implicit cast, which
should only happen with a "is a" relation. Using it in a
different context (such as nullable) is wrong, and
On Tuesday, 8 October 2013 at 19:20:05 UTC, Brad Anderson wrote:
The wiki has a pretty good guide of the overall process:
http://wiki.dlang.org/Pull_Requests
That answers most of my questions, but it seems a little...
informal. I guess the formal review process doesn't really apply
to minor
I've been working on a project that makes relatively heavy use of
nullable values. I've been using std.typecons.Nullable, and it
mostly works well, but there are some improvements that could be
made to the implementation:
* A toString() method (needed to fix bug #10915)
* An opEquals for compa
On Friday, 27 September 2013 at 15:36:12 UTC, Dmitry Olshansky
wrote:
I bet the reason is practicality: try using full names of
denominator/numerator in some involved numeric code. It's a
mess.
One may argue you need not access numerator and denominator
explicitly that much but I think it happ
On Monday, 23 September 2013 at 17:01:47 UTC, deadalnix wrote:
What you call safe really isn't. Allocate something on the GC,
store a pointer on a custom allocated location, collect, enjoy
the memory corruption. All operation are safe according to your
proposal. Allocation can only be safe if t
On Friday, 16 August 2013 at 07:48:52 UTC, QAston wrote:
You can put those functions into HasOtherMixins by using alias.
struct HasOtherMixins {
...
alias someMixin!int.abc abc;
alias someMixin!float.abc abc;
alias someOtherMixin abc;
}
Actually, that syntax only works for regular templates, n
The current behavior of placing identically-named functions from
separate mixins into separate overload sets works well most of
the time, but there are cases when the functions should be in the
same overload set, and the aliasing required to allow overloading
can quickly get tedious and clutter
On Saturday, 10 August 2013 at 17:48:34 UTC, BLM768 wrote:
On Saturday, 10 August 2013 at 10:29:51 UTC, Stian Pedersen
wrote:
To add to the mess - or maybe suggest a new approach, what
about:
class A
{
int foo();
void foo=(int a);
private foo_;
}
Then a.foo = 42; calls the foo
On Saturday, 10 August 2013 at 10:29:51 UTC, Stian Pedersen wrote:
To add to the mess - or maybe suggest a new approach, what
about:
class A
{
int foo();
void foo=(int a);
private foo_;
}
Then a.foo = 42; calls the foo= method. No other conversions
from a=b to a method invocation.
On Saturday, 13 July 2013 at 04:23:56 UTC, Walter Bright wrote:
A big problem with it would be the equivalent of the "SQL
Injection Exploit". Since the compiler can now execute
arbitrary code, someone passing around malicious source code
could do anything to your system.
Assuming that the u
On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
One can already choose their own memory model in their own
code. The issue is with the core library and pre-existing code
that forces you to use the GC model.
It's possible to use your own memory model, but that doesn't mean
it's necessa
Given all of this talk about memory management, it would seem
that it's time for people to start putting forward some ideas for
improved memory management designs. I've got an idea or two of my
own, but I'd like to discuss my ideas before I draft a DIP so I
can try to get everything fleshed out
On Wednesday, 26 June 2013 at 23:59:01 UTC, Adam D. Ruppe wrote:
On Wednesday, 26 June 2013 at 23:02:47 UTC, H. S. Teoh wrote:
Maybe a type distinction akin to C++'s auto_ptr might help?
It might not be so bad if we modified D to add a lent storage
class, or something, similar to some discuss
On Saturday, 15 June 2013 at 13:23:07 UTC, Carlos wrote:
OK but if developed it would be included in D ? Right ? It
would be very useful I think.
It could be useful, but only in a very specific type of program,
so it's unlikely that it would be bundled with the D compiler. It
would almost c
On Friday, 29 March 2013 at 06:35:10 UTC, js.mdnq wrote:
I guess that means none... :/
Unfortunately, there hasn't been a lot of focus on ARM platforms;
people are too busy improving the language and tools to work on
standard PC hardware. The DMD compiler definitely won't work for
Android d
One thing to remember is that streams need to be runtime
swappable. For instance, I should be able to replace stdout
with a stream of my choice.
That does make my solution a little tougher to implement. Hmmm...
It looks like a monolithic type is the easiest solution, but it
definitely shou
On Thursday, 7 March 2013 at 12:42:23 UTC, Steven Schveighoffer
wrote:
If the function is optimized, it can essentially bypass the
range layer and operate directly on the buffer while using the
same interface it would use if it were operating on the range.
As I understand it, some of the oper
That certain specific types of range can't implement a given
operation efficiently isn't a reason to reject the idea.
If somebody tries using takeArray on a range that by its very
nature can only pick off elements one by one, they should
expect it to be as slow as a for loop. OTOH, when u
On Wednesday, 6 March 2013 at 16:36:38 UTC, Steven Schveighoffer
wrote:
On Tue, 05 Mar 2013 18:24:22 -0500, BLM768
wrote:
Ranges aren't necessarily higher- or lower-level than streams;
they're completely orthogonal ways of looking at a data
source. It's completely possible to
On Tuesday, 5 March 2013 at 16:12:24 UTC, Steven Schveighoffer
wrote:
On Tue, 05 Mar 2013 03:22:00 -0500, Jonathan M Davis
wrote:
In general, a stream _is_ a range, making a lot of "stream"
stuff basically
irrelevant. What's needed then is a solid, efficient range
interface on top of
I/O
While working on a project, I've started to realize that I miss
streams. If someone's not already working on bringing std.stream
up to snuff, I think that we should start thinking about to do
that.
Of course, with ranges being so popular (with very good reason),
the new stream interface would p
On Monday, 4 February 2013 at 04:00:28 UTC, David Nadlinger wrote:
On Monday, 4 February 2013 at 03:15:51 UTC, David Nadlinger
wrote:
And how often do you think you'll find yourself in the
situation of needing to get a delegate from a property anyway?
Can't we just make »@property getter expr
Ack! I just realized that this doesn't work because D isn't
dynamically typed. I've had way too much Ruby on the brain
lately...
You could use std.variant to simulate dynamic typing, but can be
a bit of a mess.
You also could do something like this:
int[][] a = [[1], [2, 3, 4], [5]];
That's
On Saturday, 27 October 2012 at 21:16:56 UTC, xfiles wrote:
Hi everybody!
I want create a multi array like python.
For example(in python):
a=[1,2]
a.append([1234],3)
a.append([[4],5],6)
and result is = [1,2,[1234],3,[[4],5],6]
How can I do this in D
If you want to create it with one line, you
And what about _transparent substitution_ of AA literals for a
custom hash
implementation?
That would also be an excellent way to sidestep the current
issues with AAs. The AA code would have to be heavily refactored,
which could clean up the mess and probably get rid of a lot of
bugs. It c
I've been thinking about writing an interface inspired by
ActiveRecord. It would probably be relatively simple and
lightweight, but it should be enough for simple REST
applications, and the interface would (hopefully) be extremely
nice to use.
Of course, with all the other projects I want to do
Looking at Rust's concurrency model, it does have some great
ideas.
I wonder what would happen if D used thread-local heaps...
As far as syntax goes, the "shared" keyword could be used to
distinguish between the heap types. I'm not sure how all this
would work with "new", but I'm sure someone
Is there any chance of this code being added to Phobos? I think
it would get a fair bit of use.
73 matches
Mail list logo
