On Tuesday, 23 June 2015 at 19:03:14 UTC, ketmar wrote:
1. cassowary is dynamic solver, it can continuously adjust it's
solution as more and more constraints are added. actually, that
is one of it's core features.
Ah ok, but I suppose that would also mean that things may jump
around during lo
On Tuesday, 23 June 2015 at 19:42:53 UTC, Nick Sabalausky wrote:
Progressive rendering made sense back when you could literally
watch each image on the page gradually get pulled in over the
wire (and when the layout more or less matched the HTML as it
came in over-the-wire). But now it's mostly
On Wed, Jun 24, 2015 at 05:24:26AM +, Jonathan M Davis via Digitalmars-d
wrote:
> On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
> >Moreover, with this, some old code will *automatically* be upgraded
> >to laziness without needing to change at all too. Tell me that
> >doesn't
On Tuesday, 23 June 2015 at 11:22:40 UTC, Etienne Cimon wrote:
Nick
I don't have current performance results because I've been
focused on adding features, but these results were taken on a
previous version:
https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-l
On 24 June 2015 at 03:11, Adam D. Ruppe via Digitalmars-d
wrote:
> On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
>>
>> But that's more an argument against putting anything _except_ the basic
>> definitions into package.d, no? Then you can always exclude the more
>> specific stuff wh
On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
Moreover, with this, some old code will *automatically* be
upgraded to laziness without needing to change at all too. Tell
me that doesn't at least tempt you!
I very much like this approach. I don't know that it'll work in
the g
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
A rename can be proposed by creating a subthread: [...]
Rationale:
As with setExt, std.uni already contains functions called
toLower/toUpper, thus the only
On Wednesday, 24 June 2015 at 03:29:28 UTC, Walter Bright wrote:
On 6/23/2015 4:49 PM, Vladimir Panteleev wrote:
IMHO, in this case, the "Lazy" suffix is a distracting
technicality that doesn't
carry its weight. Am I the only one?
Nope. For the reasons you mentioned.
Agreed. It would be hor
On Tuesday, 23 June 2015 at 22:51:08 UTC, Vladimir Panteleev
wrote:
Proposed new name: withExtension
I'm fine with withExtension. Certainly, I don't think that
anything starting with "set" really makes sense given that it's a
lazy operation.
- Jonathan M Davis
On Wednesday, 24 June 2015 at 04:48:28 UTC, Manu wrote:
I just don't want to write all the others which will mirror
this set of API decisions almost verbatim until the API is
stabilised.
A wise decision. I understand.
They work fine. Just cast between color structs with different component orders:
BGR8 a = Color.white;
RGB8 b = a; // <- did swizzle
Is there a specific api you miss?
On 24 June 2015 at 05:34, Tofu Ninja via Digitalmars-d
wrote:
> On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:
>>
>> htt
On 24 June 2015 at 08:46, Mike via Digitalmars-d
wrote:
> On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:
>
>> It'd be great to get some reviews from here.
>
>
> I would like to see the packed implementatiin finished before this is
> pulled, but I won't stand in its way.
I just don't want t
On 6/23/15 6:11 PM, Mike wrote:
It seems there is already precedent with std.digest.digest
(http://dlang.org/phobos/std_digest_digest.html). I'm sorry I wasn't
aware of this at the time. std.allocator.porcelain couldn't stand, and
I suggested what seemed most natural to me. I've spend a number
On 6/23/2015 4:49 PM, Vladimir Panteleev wrote:
IMHO, in this case, the "Lazy" suffix is a distracting technicality that doesn't
carry its weight. Am I the only one?
Nope. For the reasons you mentioned.
On 24/06/2015 7:05 a.m., Laeeth Isharc wrote:
On Tuesday, 23 June 2015 at 12:28:00 UTC, Rikki Cattermole wrote:
Please come onto https://www.livecoding.tv/alphaglosined/ and hang out
for half an hour. I want to show you something related.
what times GMT or BST are good for you?
12pm UTC+0 is
On Tuesday, 23 June 2015 at 23:13:11 UTC, Mike wrote:
`setExtensionLazy`
Mike
I really don't like the Lazy suffix. Ignoring the issue of making
things somewhat uglier solely for the purpose of ambiguity, it
also leads to confusion regarding whether you should be invoking
foo or fooLazy. Is
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
I really hate this naming scheme for functions that take lazy
parameters. I still don't see why we don't do the (IMO)
simplest and most intuitive thing and name them lazyToL
On Monday, 22 June 2015 at 12:52:36 UTC, ponce wrote:
On Monday, 22 June 2015 at 08:21:44 UTC, Mike wrote:
Anti-Grain Geometry is not a solid graphic library and it's
not very easy to use. I consider AGG as a “tool to create
other tools”. It means that there's no “Graphics” object or
something
FWIW, I'm cool with any of the proposed options, as long as it isn't
what's in master right now. They all have their downsides, but I can
live with any of them.
On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu
The "import std.allocator" is already minimal - only contains
the high level stuff. -- Andrei
So you have chosen worst of both worlds - neither give power
users ability t
On Wednesday, 24 June 2015 at 00:16:49 UTC, Tofu Ninja wrote:
On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev
wrote:
Another point: the range-ification of Phobos is only going to
continue. This means that, should this scheme be followed, the
number of functions with "Lazy" in the s
We disagreed on this on irc, but I ask you to consider the
following which limits the code breakage a lot more than my first
proposal in chat:
---
import std.range;
struct ToLowered(R) if(isInputRange!R) {
R inputRange;
this(R r) {
static if(isForwardRange!R)
On 06/23/2015 03:01 AM, Andrei Alexandrescu wrote:
On 6/22/15 4:09 PM, Timon Gehr wrote:
There is no reason to prevent templates from using the mechanism that
generates only one copy. The two mechanisms shouldn't share the same
syntax, because then there is no way to tell them apart for template
On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev
wrote:
- Ultimately, we want to encourage use of the lazy versions,
in the same way that e.g. std.algorithm and std.range are
encouraged over eager operations for arr
On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev
wrote:
- Ultimately, we want to encourage use of the lazy versions,
in the same way that e.g. std.algorithm and std.range are
encouraged over eager operations for arr
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev
wrote:
- Ultimately, we want to encourage use of the lazy versions, in
the same way that e.g. std.algorithm and std.range are
encouraged over eager operations for arrays.
Another point: the range-ification of Phobos is only going to
On Tue, Jun 23, 2015 at 4:33 PM, Mike via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
>
> Sounds good?
>>
>
> Yes, please note that although I suggested a `Lazy` suffix, I don't want
> it to be a convention. It should
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
1. Leave it undefined, like the STL does. Probably this is too
extreme.
I don't think this is too extreme at all. If std.collections is
slow, nobody will use it.
If you don't believe me, go to code.dlang.org and ctrl+f json
On Tue, Jun 23, 2015 at 4:49 PM, Vladimir Panteleev via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
>
>> I really hate this naming scheme for functions that take lazy parameters.
>> I still don't see why we don't do the (IMO) simplest
On Tue, Jun 23, 2015 at 4:27 PM, Tofu Ninja via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
>
>> On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote:
>>
>>>
>>> Proposed new name: lowerCased / upperCased
>>>
>>
>> I rea
On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
I really hate this naming scheme for functions that take lazy
parameters. I still don't see why we don't do the (IMO)
simplest and most intuitive thing and name them lazyToLower /
lazyToUpper (or toLowerLazy / toUpperLazy). There is preceden
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
Sounds good?
Yes, please note that although I suggested a `Lazy` suffix, I
don't want it to be a convention. It should only be used as a
disambiguator when ambiguity arises.
Mike
On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
A rename can be proposed by creating a subthread: [...]
Rationale:
As with setExt, std.uni already con
`toLowerLazy`/`toUpperLazy`
Rationale
* sorts well with `toUpper/Lower` for tooling
* implies that it is related to `setUpper/Lower` in some way
* at-a-glance disambiguates it from `toUpper/Lower` with a clue
as to how it is differrent
Mike
On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
A rename can be proposed by creating a subthread: [...]
Rationale:
As with setExt, std.uni already contains functions called
toLower/toUpper, thus the only
`setExtensionLazy`
Rationale
* sorts well with `setExtension` for tooling
* implies that it is related to `setExtension` in some way
* at-a-glance disambiguates it from `setExtension` with a clue as
to how it is differrent
The disadvantage is that its a little long, but that's due to the
leng
On Tue, 23 Jun 2015 13:30:52 -0700, Jeremy Powers via Digitalmars-d wrote:
> Well I don't like assertions either, for specifically that reason. An
> error is an error, I don't want something to be caught and handled in
> debug to then be ignored and explode on release. If my release isn't
> chec
Ok, if you feel so strongly about it, let's not waste time in
arguing. You are not obliged to agree to any of reviewer comments
so as long as everyone is clear about their opinion, the eventual
voting will decide. I am simply pointing out things that catch my
attention.
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
A rename can be proposed by creating a subthread: [...]
Rationale:
As with setExt, std.uni already contains functions called
toLower/toUpper, thus the only difference in name is that the
implied word "Case" is omitted. The d
On 6/23/15 6:18 PM, Andrei Alexandrescu wrote:
On 6/23/15 3:17 PM, Steven Schveighoffer wrote:
we need to redo
no
Yeah, so then it becomes import std.somepackage means import all the
modules in that package, except for std.allocator. But that's fine, if
we want that type of inconsistency,
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
A rename can be proposed by creating a subthread: reply to this
post, but change the name to the fully-qualified name of the
identifier you'd like to see renamed. Please include a
rationale and a proposed new name in your post.
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:
It'd be great to get some reviews from here.
I would like to see the packed implementatiin finished before
this is pulled, but I won't stand in its way.
Mike
On Monday, 22 June 2015 at 19:43:30 UTC, Walter Bright wrote:
On 6/22/2015 7:22 AM, Vladimir Panteleev wrote:
It seems everyone in this thread is in agreement, so what
would be the next
step? It is a time-sensitive matter as preparations for
2.068's release are
already underway. After two pings
In continuation of the "Naming things" thread, Andrei proposed
the following plan:
[andralex] 1. Collect all names ADDED to Phobos since 2.067
[andralex] these are names that we have ONE shot in eternity to
get right before they’re frozen
[andralex] 2. Lead a community discussion on choosing th
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
While I work on making std.allocator better, here's some food
for thought regarding std.collection.
Consider a traditional container with reference semantics,
Java-style. Regarding changing the collection (e.g.
adding/removin
On 6/23/15 6:07 PM, Andrei Alexandrescu wrote:
On 6/23/15 2:12 PM, Dicebot wrote:
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
There is functionality in std.allocato
On 6/23/15 3:17 PM, Steven Schveighoffer wrote:
we need to redo
no
On Tuesday, 23 June 2015 at 19:16:33 UTC, Andrei Alexandrescu
wrote:
The case with std.allocator is not everything is imported in
it, so no bloating no nothing. -- Andrei
My assumption with D libraries is that "import std.thing;"
imports everything in the the whole package.
Not that I've
On 6/23/15 2:29 PM, Dmitry Olshansky wrote:
I'm not sure if that's the case with std.allocator but importing package
IMHO should import _typical_ set of submodules.
Things that are more niche and rare (power user oriented) shouldn't
really be in package.d
Yah, that attitude describes std.alloc
On 6/23/15 2:12 PM, Dicebot wrote:
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
There is functionality in std.allocator to get anyone started who
doesn't want to sit
On 6/23/15 2:14 PM, Tofu Ninja wrote:
On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
If anything, that will be
On 24-Jun-2015 00:12, Dicebot wrote:
On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu wrote:
On 6/23/15 10:16 AM, Dicebot wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick con
On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 10:16 AM, Dicebot wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't
think a
package.d shoul
On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
So you have chosen worst of both worlds - neither give power
users ability to fine tune imports nor allow casual users
always go with `import std.allocator` and be happy? :)
If anything, that will be the first package.d in Phobos (AFAIK)
On Tue, Jun 23, 2015 at 12:31 PM, Jonathan M Davis via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote:
>
>> Different behavior between release and non is not something to be desired.
>>
>
> It's perfectly normal if we're talking
On Tuesday, 23 June 2015 at 16:33:29 UTC, Dominikus Dittes
Scherkl wrote:
On Wednesday, 17 June 2015 at 09:28:00 UTC, Tofu Ninja wrote:
I actually thought about it more, and D does have a bunch of
binary operators that no ones uses. You can make all sorts of
weird operators like +*, *~, +++,
On Tuesday, 23 June 2015 at 17:05:41 UTC, John Colvin wrote:
On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis
wrote:
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
[...]
And how does it introduce a hidden performance issue. You'd
end up with some template bloat, but that
On Tuesday, 23 June 2015 at 17:05:41 UTC, John Colvin wrote:
On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis
wrote:
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis
wrote:
[...]
Thus the solution cannot require co
On 06/23/2015 03:03 PM, ketmar wrote:
2. actually, we should drop that "progressive rendering". so-called "web
apps" already dropped that, drawing rotating shit icon instead while they
are loading megabytes of js. there is no sense to support progressive
rendering anymore: it's either not working
On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote:
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
I think the best approach is the following:
* Throw exceptions on debug (usability)
* Leave undefined on release (performance)
On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
And I still think Timon's statement is untrue. There is a
reason, which is that the new auto ref syntax forces reference
parameters for all types(even primitives), where the old
template approach does not.
Timon suggested using another
On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:
https://github.com/D-Programming-Language/phobos/pull/2845
I'm getting quite happy with it.
I think it's a good and fairly minimal but useful starting
point.
It'd be great to get some reviews from here.
Swizzels would be a nice addition.
On 06/23/2015 03:19 PM, ketmar wrote:
On Tue, 23 Jun 2015 15:04:49 -0400, Nick Sabalausky wrote:
Even that intrinsic passion in the field itself isn't strictly necessary
to be a good programmer. I know that sounds wrong, but hear me out: All
that's REALLY needed at the bare minimum is the basic
On 06/23/2015 04:49 AM, Chris wrote:
Yeah. A guy I know had a hard time finding a job with Java. HR would
always demand experience with this or that build tool and stuff like
this. As if you couldn't learn this in a week or less, at least enough
to be able to contribute to a project. Actual prog
On Tuesday, 23 June 2015 at 14:06:38 UTC, Sönke Ludwig wrote:
As I understand it, there is a gap between what you can
currently do
with std.json (and indeed vibed json) and what you can do with
stdx.data.json. And the capability falls short of what can be
done in
other standard libraries such
On Tue, 23 Jun 2015 15:04:49 -0400, Nick Sabalausky wrote:
> Even that intrinsic passion in the field itself isn't strictly necessary
> to be a good programmer. I know that sounds wrong, but hear me out: All
> that's REALLY needed at the bare minimum is the basic integrity to say
> "If this is wha
On 6/23/15 10:16 AM, Dicebot wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dlang.org/
On 6/23/15 10:15 AM, Adam D. Ruppe wrote:
On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote:
But that doesn't apply to packages that do NOT originate as big
modules, so they have no backward compatibility issue.
My thought isn't really about backward compatibility but about
m
On Tuesday, 23 June 2015 at 06:43:21 UTC, Rikki Cattermole wrote:
I am currently writing a ui system that defines the majority
of the
layout in a dsl. The ui element types are defined in D code
and I use
uda's to mark which fields can be accesses by the dsl.
Got a repo yet?
Would be intereste
On Tue, 23 Jun 2015 14:33:49 -0400, kinke wrote:
On Tuesday, 23 June 2015 at 18:11:21 UTC, bitwise wrote:
On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr
wrote:
There is no reason to prevent templates from using the mechanism that
generates only one copy. The two mechanisms shouldn't shar
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
>
> I think the best approach is the following:
> * Throw exceptions on debug (usability)
> * Leave undefined on release (performance)
>
Please no.
Different behavior between release and non is no
On Tuesday, 23 June 2015 at 12:28:00 UTC, Rikki Cattermole wrote:
Please come onto https://www.livecoding.tv/alphaglosined/ and
hang out for half an hour. I want to show you something related.
what times GMT or BST are good for you?
On 06/23/2015 02:15 PM, ketmar wrote:
On Sun, 21 Jun 2015 13:24:14 +, Tobias Müller wrote:
For many programmers, programming is just a job, not more. They don't
program in their spare time and are not really interested in programming
languages as you are.
that people called "code monkeys"
On Sat, 20 Jun 2015 19:40:35 +, Ola Fosheim Grøstad wrote:
> On Saturday, 20 June 2015 at 16:20:31 UTC, ketmar wrote:
>> On Sat, 20 Jun 2015 16:14:43 +, Ola Fosheim Grøstad wrote:
>>
>>> On Saturday, 20 June 2015 at 15:36:45 UTC, ketmar wrote:
it was designed to ignore that fact a
Chris wrote:
"This already started in the 1990ies and got worse and worse,
this business of looking for the "perfect" candidate. A lot of
skills can be acquired in the first weeks (or months, depending).
It's better to train someone who's intelligent and innovative
than someone who's worked wi
On Sat, 20 Jun 2015 17:00:43 +, Kagamin wrote:
> Well, it's just windows api was simple enough to be usable directly,
> while X11 didn't fly that way and didn't receive development since
> everybody used toolkits and all features were implemented in toolkits,
> which in the end used X11 as pla
On 06/23/2015 12:37 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Tuesday, 23 June 2015 at 11:09:31 UTC, Joakim wrote:
This is nonsense. They're just dumping in everything they can think
of, that has nothing to do with backwards-compatibility.
Web tech is pretty good at backwards-comp
On Tue, 23 Jun 2015 18:26:07 +, deadalnix wrote:
> I'm not sure of your use case, but wayland is clearly a huge step
> forward compared to X.
yep, they reinvented DirectFB and dropped alot of libs on top of it.
really a huge step.
signature.asc
Description: PGP signature
Am 23.06.2015 um 16:58 schrieb Manu via Digitalmars-d:
https://github.com/D-Programming-Language/phobos/pull/2845
I'm getting quite happy with it.
I think it's a good and fairly minimal but useful starting point.
It'd be great to get some reviews from here.
From a quick glance, looks very ni
On Tuesday, 23 June 2015 at 18:11:21 UTC, bitwise wrote:
On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr
wrote:
There is no reason to prevent templates from using the
mechanism that generates only one copy. The two mechanisms
shouldn't share the same syntax, because then there is no way
to t
On Sun, 21 Jun 2015 23:08:07 +, rsw0x wrote:
> No, there really are no libraries for D. And it's 1000x worse if you
> attempt to use D for anything related to system's programming aka no GC
> available.
>
> I got so fed up that I ported my project from D to C. I'll gladly trade
> a worse lang
On Tuesday, 23 June 2015 at 16:36:21 UTC, Adam D. Ruppe wrote:
On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
Although I wouldn't put too much reliance on X, what with
Wayland on the way.
meh, wayland doesn't look very interesting to me, especially in
this use case where I'd
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:
Isn't this what selective imports are for?
Not quite the same thing: selective imports control which symbols
you pull into the current namespace, but not which code gets
pulled into the binary.
If you do `import foo : bar;`, the c
On Sun, 21 Jun 2015 13:24:14 +, Tobias Müller wrote:
> For many programmers, programming is just a job, not more. They don't
> program in their spare time and are not really interested in programming
> languages as you are.
that people called "code monkeys", not "programmers". it's simply
i
On Mon, 22 Jun 2015 19:09:45 -0400, Timon Gehr wrote:
There is no reason to prevent templates from using the mechanism that
generates only one copy. The two mechanisms shouldn't share the same
syntax, because then there is no way to tell them apart for template
functions.
You would be lo
On 6/23/15 1:59 PM, Meta wrote:
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:
Isn't this what selective imports are for? Admittedly it's not quite
as convenient, but it does let you choose exactly what you want. You
can even make a module that wraps a manually selected set of impo
On Tuesday, 23 June 2015 at 17:59:48 UTC, Meta wrote:
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:
Isn't this what selective imports are for? Admittedly it's not
quite as convenient, but it does let you choose exactly what
you want. You can even make a module that wraps a manual
On Tuesday, 23 June 2015 at 17:53:43 UTC, John Colvin wrote:
Isn't this what selective imports are for? Admittedly it's not
quite as convenient, but it does let you choose exactly what
you want. You can even make a module that wraps a manually
selected set of imports, e.g. you do your own basic
On Sat, 20 Jun 2015 15:38:29 -0700, Walter Bright wrote:
> https://github.com/rollbear/basicpp
this is doable with Adam's "jsvar.d" and compile-time parser. parser
needs to be written, though. i did that once, but found BASIC too
complicated and retreated to D.
signature.asc
Description: PGP s
On Tuesday, 23 June 2015 at 17:11:57 UTC, Adam D. Ruppe wrote:
On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
But that's more an argument against putting anything _except_
the basic definitions into package.d, no? Then you can always
exclude the more specific stuff whenever you ne
On Mon, 22 Jun 2015 09:41:08 +, Jonathan M Davis wrote:
> Still, it seems odd to compare
> part of the NaN for equality but not all of it.
it's very useful for NaN-boxing.
signature.asc
Description: PGP signature
On Tue, Jun 23, 2015 at 03:24:41PM +, John Colvin via Digitalmars-d wrote:
> On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote:
> >Just a quick concern, I don't think a package.d should ever have
> >anything except imports in it. Put all the actual aliases and color
> >lists in some
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't
think a
package.d should ever have anything except imports in it"
(see
http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dla
On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu
wrote:
But that doesn't apply to packages that do NOT originate as big
modules, so they have no backward compatibility issue.
My thought isn't really about backward compatibility but about
minimizing dependencies with sibling module
On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
But that's more an argument against putting anything _except_
the basic definitions into package.d, no? Then you can always
exclude the more specific stuff whenever you need it, and those
modules themselves can publicly import package
On Tuesday, 23 June 2015 at 16:27:34 UTC, Jonathan M Davis wrote:
On Tuesday, 23 June 2015 at 13:52:19 UTC, Daniel N wrote:
On Tuesday, 23 June 2015 at 11:03:10 UTC, Jonathan M Davis
wrote:
[...]
Thus the solution cannot require const.
auto is worse because, if you later decide you need to a
On 06/23/2015 12:36 PM, Adam D. Ruppe wrote:
On Tuesday, 23 June 2015 at 16:18:01 UTC, Nick Sabalausky wrote:
Yea, I'll have to take a closer look at that. My first impression is
that "Linux VM" sounds very heavy-weight, but I supposed it need not
necessarily be.
Well, keep in mind that I want
On 6/23/15 9:53 AM, extrawurst wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dlang.or
Am 23.06.2015 um 18:53 schrieb extrawurst:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dla
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't
think a
package.d should ever have anything except imports in it"
(see
http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dla
1 - 100 of 152 matches
Mail list logo
