Re: Naming things
On Saturday, 20 June 2015 at 09:27:16 UTC, Vladimir Panteleev wrote: Two examples of controversial name pairs: setExt/setExtension, and toLower/toLowerCase. These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which? Yikes! That should have never passed scrutiny in the pull request. I'm sorry I didn't see it, as I would have voiced opposition to it. I only just started monitoring Phobos this week. My work doesn't really require me to use Phobos much. It would be unfortunate if we were to have such warts in D, so I think we should at least not outright reject PRs which fix them. I totally agree. I was really excited about D a year and a half ago, and what really lit my fire was Andrei's talk about "Operational Professionalism" at DConf 2013. At that time, I thought, "Wow, this community really cares about getting things right". How naive of me :) But, I'm still here...perhaps foolishly. It makes me disappointed to see contributions that dot the 'i's and cross the 't's get turned away and belittled. But, I don't think there's anything I can do about it, and although you've made an excellent argument, I've gathered enough wisdom in my time here to make a reasonable prediction of the outcome. I also believe the relatively little response you've received in this thread is likely not an indication that few care, or that few support your argument, but rather that they've seen it before, and they know how it ends. Mike
Re: Naming things
On 22/06/2015 7:17 p.m., Mike wrote: On Saturday, 20 June 2015 at 09:27:16 UTC, Vladimir Panteleev wrote: Two examples of controversial name pairs: setExt/setExtension, and toLower/toLowerCase. These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which? Yikes! That should have never passed scrutiny in the pull request. I'm sorry I didn't see it, as I would have voiced opposition to it. I only just started monitoring Phobos this week. My work doesn't really require me to use Phobos much. It would be unfortunate if we were to have such warts in D, so I think we should at least not outright reject PRs which fix them. I totally agree. I was really excited about D a year and a half ago, and what really lit my fire was Andrei's talk about "Operational Professionalism" at DConf 2013. At that time, I thought, "Wow, this community really cares about getting things right". How naive of me :) But, I'm still here...perhaps foolishly. It makes me disappointed to see contributions that dot the 'i's and cross the 't's get turned away and belittled. But, I don't think there's anything I can do about it, and although you've made an excellent argument, I've gathered enough wisdom in my time here to make a reasonable prediction of the outcome. I also believe the relatively little response you've received in this thread is likely not an indication that few care, or that few support your argument, but rather that they've seen it before, and they know how it ends. Mike I haven't commented yet but you have half hit a nerve for me. Okay so, I'm in agreement about the point being made 100%. But there isn't really anything I can _do_ about it. I don't really review Phobos PR's. Just a thought, add a checklist to CONTRIBUTING.md on Github and have this as one of them for function/method names. It probably just slipped peoples minds. Problem solved.
Re: Naming things
On Monday, 22 June 2015 at 07:25:19 UTC, Rikki Cattermole wrote: But there isn't really anything I can _do_ about it. See the sentence before that. I don't really review Phobos PR's. That's not at all what I said.
Re: color library
On Sunday, 21 June 2015 at 15:42:39 UTC, Rikki Cattermole wrote:
interface IImage(COLOR) {
@property {
size_t width() @nogc nothrow;
size_t height() @nogc nothrow;
void* storage() @nogc nothrow;
}
COLOR pixelAt(size_t x, size_t y) @nogc;
void pixelStoreAt(size_t x, size_t y, COLOR value) @nogc;
// COLOR opIndex(size_t x, size_t y)
// void opIndexAssign(COLOR value, size_t x, size_t y)
}
What about alpha? I don't see it on "color" or "IImage".
Anyway I always hope to have something like antigrain (heavily
template based library for c++, really really fast!), implemented
in D. Maybe you should check it for some ideas.
Re: color library
On 22/06/2015 7:55 p.m., Andrea Fontana wrote:
On Sunday, 21 June 2015 at 15:42:39 UTC, Rikki Cattermole wrote:
interface IImage(COLOR) {
@property {
size_t width() @nogc nothrow;
size_t height() @nogc nothrow;
void* storage() @nogc nothrow;
}
COLOR pixelAt(size_t x, size_t y) @nogc;
void pixelStoreAt(size_t x, size_t y, COLOR value) @nogc;
// COLOR opIndex(size_t x, size_t y)
// void opIndexAssign(COLOR value, size_t x, size_t y)
}
What about alpha? I don't see it on "color" or "IImage".
Anyway I always hope to have something like antigrain (heavily template
based library for c++, really really fast!), implemented in D. Maybe you
should check it for some ideas.
Why would IImage support alpha? Shouldn't that be on the color?
If so, the PR does support it see RGBA8 and friends.
I just had a look at antigrain. It really is beyond this code. Well and
truly out of scope.
std.math.isIdentical and NaN
Docs for isIdentical say: Same as ==, except that positive and negative zero are not identical, and two NANs are identical if they have the same 'payload'. However, it returns false for NaN's with different signbits but same payload. Should this be the case? Ran into this because isIdentical is used in unittests to compare NaN's but I find an occassional test fails due to signbit for some operations on LDC ARM. I wrote an isNaNWithPayload() predicate for the failing tests, but wonder if isIdentical should ignore signbit for NaNs or have its docs changed. -- Dan
Re: color library
On Monday, 22 June 2015 at 07:55:16 UTC, Andrea Fontana wrote: Anyway I always hope to have something like antigrain (heavily template based library for c++, really really fast!), implemented in D. Maybe you should check it for some ideas. I agree, AGG (Anti-Grain Geometry) is an excellent model to follow, specifically for D. I've been using it in embedded systems running at 168MHz with less than 4MB of RAM. And that RAM is also running a lot of other stuff (libPNG, FreeType, Modbus, and even embedded TrueType fonts. Crazy! I was actually shocked when I got it working, and saw it perform so well. From http://www.antigrain.com/doc/introduction/introduction.agdoc.html "AGG allows you to replace any part of the library, if, for example, it doesn't fit performance requirements. Or you can add another color space if needed. All of it is possible because of extensive using of C++ template mechanism. 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 like that, instead, AGG consists of a number of loosely coupled algorithms that can be used together or separately. All of them have well defined interfaces and absolute minimum of implicit or explicit dependencies." It's architecture is what makes it so beautiful. You can configure your own graphics pipeline simply by passing the right template arguments. It would be an excellent showcase for D. Mike
Re: color library
On Monday, 22 June 2015 at 08:08:42 UTC, Rikki Cattermole wrote:
Why would IImage support alpha? Shouldn't that be on the color?
If so, the PR does support it see RGBA8 and friends.
I said "on color or IImage". Anyway transparency is a property
(mask) of an image ("material") rather than of the color itself.
A color has no transparency, there's no transparency on gamut. It
doesn't make sense for a color: transparency is used only when
you add an image over another in order to sum the *colors* of two
pixels. They used to pack alpha informations with other pixel
infos (color) just for simplicity and to have a convenient way to
store info inside a file, I guess.
I just had a look at antigrain. It really is beyond this code.
Well and truly out of scope.
I mean it would be useful to grab some ideas from it.
And that it would really wonderful to have something like this.
However I think it is useful to build the library and interfaces
thinking also to possible future developments.
Andrea
Re: color library
On Monday, 22 June 2015 at 08:45:38 UTC, Andrea Fontana wrote:
I said "on color or IImage". Anyway transparency is a property
(mask) of an image ("material") rather than of the color itself.
That would be a pair of images: Image!RGB8, Image!A8.
Re: color library
On 22/06/2015 8:45 p.m., Andrea Fontana wrote:
On Monday, 22 June 2015 at 08:08:42 UTC, Rikki Cattermole wrote:
Why would IImage support alpha? Shouldn't that be on the color?
If so, the PR does support it see RGBA8 and friends.
I said "on color or IImage". Anyway transparency is a property (mask) of
an image ("material") rather than of the color itself. A color has no
transparency, there's no transparency on gamut. It doesn't make sense
for a color: transparency is used only when you add an image over
another in order to sum the *colors* of two pixels. They used to pack
alpha informations with other pixel infos (color) just for simplicity
and to have a convenient way to store info inside a file, I guess.
I just had a look at antigrain. It really is beyond this code. Well
and truly out of scope.
I mean it would be useful to grab some ideas from it.
And that it would really wonderful to have something like this.
However I think it is useful to build the library and interfaces
thinking also to possible future developments.
Andrea
Humm, I can add it as an optional part of the interface like pixel offset.
Maybe. But it does feel a little less like other libraries out there.
The main reason I'm put off of antigrain is it feels a little too much
unwieldy to me.
But of course, I can't dismiss your guys suggestions so of course I'll
dig more deeper into it! Even if I do drag my heels a little bit.
Re: color library
Hey cool. Glad to hear you had no problems.
Sorry, I missed it. I had an early night last night (sunday night >_<)
.. Are there recordings to review?
It's an interesting idea; knowing if a colour is convertible to some
other colour without loss... it sounds like it leads to implicit
conversion, but I don't think we want that here.
I'll think on how to do it. It's not really trivial.
On 22 June 2015 at 18:55, Rikki Cattermole via Digitalmars-d
wrote:
> On 22/06/2015 8:45 p.m., Andrea Fontana wrote:
>>
>> On Monday, 22 June 2015 at 08:08:42 UTC, Rikki Cattermole wrote:
>>>
>>>
>>> Why would IImage support alpha? Shouldn't that be on the color?
>>> If so, the PR does support it see RGBA8 and friends.
>>
>>
>> I said "on color or IImage". Anyway transparency is a property (mask) of
>> an image ("material") rather than of the color itself. A color has no
>> transparency, there's no transparency on gamut. It doesn't make sense
>> for a color: transparency is used only when you add an image over
>> another in order to sum the *colors* of two pixels. They used to pack
>> alpha informations with other pixel infos (color) just for simplicity
>> and to have a convenient way to store info inside a file, I guess.
>>
>>> I just had a look at antigrain. It really is beyond this code. Well
>>> and truly out of scope.
>>
>>
>> I mean it would be useful to grab some ideas from it.
>> And that it would really wonderful to have something like this.
>>
>> However I think it is useful to build the library and interfaces
>> thinking also to possible future developments.
>>
>> Andrea
>
>
> Humm, I can add it as an optional part of the interface like pixel offset.
> Maybe. But it does feel a little less like other libraries out there.
>
> The main reason I'm put off of antigrain is it feels a little too much
> unwieldy to me.
>
> But of course, I can't dismiss your guys suggestions so of course I'll dig
> more deeper into it! Even if I do drag my heels a little bit.
Re: color library
On Monday, 22 June 2015 at 08:45:38 UTC, Andrea Fontana wrote:
On Monday, 22 June 2015 at 08:08:42 UTC, Rikki Cattermole wrote:
I said "on color or IImage". Anyway transparency is a property
(mask) of an image ("material") rather than of the color
itself. A color has no transparency, there's no transparency on
gamut. It doesn't make sense for a color: transparency is used
only when you add an image over another in order to sum the
*colors* of two pixels. They used to pack alpha informations
with other pixel infos (color) just for simplicity and to have
a convenient way to store info inside a file, I guess.
I think alpha being part of the color make perfect sense in many
contexts, seems kinda silly to try and separate them...
Re: color library
On Monday, 22 June 2015 at 08:45:38 UTC, Andrea Fontana wrote: They used to pack alpha informations with other pixel infos (color) just for simplicity and to have a convenient way to store info inside a file, I guess. Separate mask has an advantage of lower memory consumption: it can have 1-bit depth. It was important in 90s when you didn't have lots of RAM and HDD and didn't need transparency deeper than 1 bit, masks were used to only outline a crop region, which worked with RLE compression well further decreasing mask size, so it made no sense to waste space on 8-bit alpha channel.
Re: D could catch this wave: web assembly
On Sunday, 21 June 2015 at 18:51:41 UTC, Nick Sabalausky wrote: On 06/21/2015 05:07 AM, Joakim wrote: > > Simply dumping more features on top of the old web stack > is a recipe for failure. > Meh, it seems to be working for them so far ;) But I agree, it's a bad approach, and hopefully will finally collapse. What's amazing is how long this house of cards keeps jiggling on, and even worse, how many people actually think it's something worthwhile! It can't be destroyed soon enough. > Very responsive because they're made up of trivially simple line art, > perhaps. I happen to like that aesthetic style, really. :) But of course an image format needs to be more general. Actually, I like that "cartoon" style too, wish more people used it. I'm guessing they don't only because it's considered too simple or not as serious. But I bet SVG would be slow even for that, particularly if it was animated. I really liked the new Fisher-Price style of desktop Windows 8, along with better visualizations like the graph when copying files. Damn sight better than the OSX-aping Windows 7, with the unnecessary glass and reflections everywhere, though it was pretty at first. > On Sunday, 21 June 2015 at 07:38:02 UTC, Nick Sabalausky wrote: >> On 06/21/2015 01:42 AM, Joakim wrote: > I have almost 50 GBs of storage on my tablet, between the built-in flash > and an SD card, about half what I have on my ultrabook. 50GB? That's it? I have more than that in music alone. (And no, streaming music services is not an improvement. Although it is occasionally a nice supplement.) My two most recent laptops, I've upgraded to 1TB HDDs. Anything less than that in local storage feels cramped. Plus then I have an old desktop with about 2.5-3TB between three drives. And three USB3 drives ranging from a few hundred GB to 1TB. And a USB2 @ 250GB. Heh, I'd say you're pretty unusual. Whenever I ask normal people how much disk space they have, they have no idea, and when I check their devices for myself, they're inevitably only using around 10-20% of the 16-32 GBs on their tablets or 80-500 GBs on their laptops. > If I weren't > filling that 50 GBs up with many GBs of HD video, VMs also soak up a lot of space. (just sayin') I'm up to 22 GBs of VMs right now. > that's plenty of space for most people. To marginalize desktops/laptops, mobile doesn't need to win over "most people". Those are the people they've already won over. It exactly us dev and power users that they need to win over now. And they can't do that by settling for whatever works for "most people". The vast majority of current desktop/laptop users are only stuck with them because they bought them before mobile took off or they need a multi-window UI for certain apps or certain desktop software that hasn't been ported to mobile yet, ie there's no fundamental reason they couldn't use mobile devices instead. Of the 300 million PCs sold last year, I'd say 95+% could make the transition to mobile devices once they have multi-window UIs and all the same software. The remaining 3-5% may never make the transition. > As for peripherals, you're talking printers and > scanners? Do people even use those anymore? :) Yes. They're not sexy and don't generate "buzz", but that doesn't mean they aren't relied on. (Personal observation: The modern fashion-oriended tech sector seems to have major trouble recognizing that "buzzworthy" and "important" are not the same thing). Seems like most of those are going to wifi/bluetooth connections that are easily controlled by mobile devices also. > If there's any demand > for those at all, the dock for your smartphone will have a USB hub that > supports them. > Yea. ONE usb port (that needs an adapter to be able to use just about anything out there besides charging) for everything to get funneled and crammed into: charging, HDMI, external storage, printer/scanner, jtag (arduino and such are big these days), optical disc (yes, these are still useful), adpators for whatever new protocols and connectors inevitably come along, etc. And that one-port-only means that you *also* need a hub in addition to everything else. Rendering the whole mess considerably less convenient than an actual all-in-one device: the laptop. Well, if you're docking the smartphone at your desk anyway, having a USB hub with several ports built into the dock is not a big deal. As for on the go, yes, you'll need to bring some sort of adapter with you, but new connectors like USB Type-C are geared for that. I don't think this ports issue moves the needle for most people, and most peripherals these days are moving to wireless anyway. > As for devs, they're a small percentage of the computer-using public, You're looking at it wrong (IMO): Devs (and non-dev power users, don't forget there's a lot of them too) are a very significant portion of modern-day desktop/laptop users. They're the biggest re
Re: std.math.isIdentical and NaN
On Monday, 22 June 2015 at 08:10:20 UTC, Dan Olson wrote: Docs for isIdentical say: Same as ==, except that positive and negative zero are not identical, and two NANs are identical if they have the same 'payload'. However, it returns false for NaN's with different signbits but same payload. Should this be the case? Ran into this because isIdentical is used in unittests to compare NaN's but I find an occassional test fails due to signbit for some operations on LDC ARM. I wrote an isNaNWithPayload() predicate for the failing tests, but wonder if isIdentical should ignore signbit for NaNs or have its docs changed. Well, given the name of the function and the fact that it's clearly trying to check for NaN equality rather than treating their comparison as always false, I would have expected that it would be true for NaNs if they were absolutely identical, which presumably includes the signbit, but I really don't know much about how NaNs are implemented, so I don't know what the implications of that are. Still, it seems odd to compare part of the NaN for equality but not all of it. - Jonathan M Davis
Re: color library
On 22/06/2015 9:15 p.m., Kagamin wrote: On Monday, 22 June 2015 at 08:45:38 UTC, Andrea Fontana wrote: They used to pack alpha informations with other pixel infos (color) just for simplicity and to have a convenient way to store info inside a file, I guess. Separate mask has an advantage of lower memory consumption: it can have 1-bit depth. It was important in 90s when you didn't have lots of RAM and HDD and didn't need transparency deeper than 1 bit, masks were used to only outline a crop region, which worked with RLE compression well further decreasing mask size, so it made no sense to waste space on 8-bit alpha channel. Thank you. That use case does make sense. I think I might add it as an optional feature anyway. For e.g. embedded devices. The mutation algorithms can reasonably easily handle this specific case in image storage.
Re: color library
On 22/06/2015 9:11 p.m., Manu via Digitalmars-d wrote:
Hey cool. Glad to hear you had no problems.
Sorry, I missed it. I had an early night last night (sunday night >_<)
.. Are there recordings to review?
There is indeed!
I'll be streaming again tonight FYI.
It's an interesting idea; knowing if a colour is convertible to some
other colour without loss... it sounds like it leads to implicit
conversion, but I don't think we want that here.
I'll think on how to do it. It's not really trivial.
It shouldn't be implicit. Never implicit. Always must be asked for.
I just want functions to tell me if it is loosing or gaining precision
in the conversion. That way it can be e.g. logged.
On 22 June 2015 at 18:55, Rikki Cattermole via Digitalmars-d
wrote:
On 22/06/2015 8:45 p.m., Andrea Fontana wrote:
On Monday, 22 June 2015 at 08:08:42 UTC, Rikki Cattermole wrote:
Why would IImage support alpha? Shouldn't that be on the color?
If so, the PR does support it see RGBA8 and friends.
I said "on color or IImage". Anyway transparency is a property (mask) of
an image ("material") rather than of the color itself. A color has no
transparency, there's no transparency on gamut. It doesn't make sense
for a color: transparency is used only when you add an image over
another in order to sum the *colors* of two pixels. They used to pack
alpha informations with other pixel infos (color) just for simplicity
and to have a convenient way to store info inside a file, I guess.
I just had a look at antigrain. It really is beyond this code. Well
and truly out of scope.
I mean it would be useful to grab some ideas from it.
And that it would really wonderful to have something like this.
However I think it is useful to build the library and interfaces
thinking also to possible future developments.
Andrea
Humm, I can add it as an optional part of the interface like pixel offset.
Maybe. But it does feel a little less like other libraries out there.
The main reason I'm put off of antigrain is it feels a little too much
unwieldy to me.
But of course, I can't dismiss your guys suggestions so of course I'll dig
more deeper into it! Even if I do drag my heels a little bit.
Re: Naming things
On Saturday, 20 June 2015 at 09:27:16 UTC, Vladimir Panteleev wrote: Two examples of controversial name pairs: setExt/setExtension, and toLower/toLowerCase. These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which? I've taken a look at the offending PR (https://github.com/D-Programming-Language/phobos/pull/3370). Unfortunately, it was only up for review for about a day before it was merged, and only one person commented on it before it was merged. Given that some PRs are currently rotting for months, I hate to say that PRs should remain open for a minimum amount of time, but that's what I'm saying. We're all very busy, so give PRs a few days for reviewers to get to them. IMO, that PR should have never passed scrutiny, and probably wouldn't have if it was given a little more time. Mike
Re: auto ref is on the docket
On Monday, 22 June 2015 at 06:38:57 UTC, Andrei Alexandrescu
wrote:
On 6/21/15 11:31 PM, Andrei Alexandrescu wrote:
On 6/21/15 10:25 PM, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
I don't think that lowering is recommended - it prolongs the
lifetime of
the temporary through the end of the caller. But that may be
actually a
good thing.
On second thought - Walter's lowering, which makes the rvalue
last more than strictly necessary, may be the most flexible of
all at the cost of more resource consumption (for types that
define destructors). -- Andrei
Why would that be desirable? Resource consumption is the least of
the problems. It is simply surprising, inconsistent with the
lifetime of other temporaries, and it is unnecessary. Just lower
it to:
{
auto tmp = 5;
fun(tmp);
}
Re: Phobos addition formal review: std.experimental.allocator
Can I use these allocators in @nogc code too ?
Re: Future(s) for D.
On 22/06/15 01:43, Nick Sabalausky wrote: Curiosity, what libraries do you feel a lack of? For work, that would be: * Database drivers for Postgres and SQLite * ORM * Unit test framework. I want something like RSpec * RabbitMQ and ActiveMQ * Some way to interface with Selenium and PhantomJS For non work related things it would also be: * Sass * CoffeeScript * I would prefer HAML over that templates used in vibe.d but I guess there' close enough I haven't looked in a while for these things on code.dlang.org. I know some of them exist but I don't know the quality of them. In the Ruby world there's a lot of developers behind most of these libraries, there's no chance that these libraries would suddenly disappear overnight. These are the libraries I can think of right now, that are generally needed for most projects. Then there are of course special requirements for some projects. But in Ruby you can be pretty certain that most things are already available as a library. -- /Jacob Carlborg
Re: Naming things
On Saturday, 20 June 2015 at 09:27:16 UTC, Vladimir Panteleev wrote: Two examples of controversial name pairs: setExt/setExtension, and toLower/toLowerCase. These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which If I had to hazard a guess, I'd go with "the shorter one is lazy", but that presumes I'd notice there were two nearly-identical functions in the first place and pick up on the not-well-conveyed implication that one is lazy and the other is not. That's a Bad Thing. And it's a bad thing everyone seems to be tip-toeing around, too. None of the suggestions I've seen so far really call out to me "hey, this is lazy and has a non-lazy counterpart". Would it be so wrong to add "lazy" to the beginning or end so it's super obvious at a glance with zero cognitive overhead? -Wyatt
Re: Naming things
On Monday, 22 June 2015 at 11:45:31 UTC, Wyatt wrote: On Saturday, 20 June 2015 at 09:27:16 UTC, Vladimir Panteleev wrote: Two examples of controversial name pairs: setExt/setExtension, and toLower/toLowerCase. These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which If I had to hazard a guess, I'd go with "the shorter one is lazy", but that presumes I'd notice there were two nearly-identical functions in the first place and pick up on the not-well-conveyed implication that one is lazy and the other is not. Well, you'd be wrong. Although setExt is the lazy version of setExtension, toLowerCase is the lazy version toLower. Who needs consistency, eh? And it's a bad thing everyone seems to be tip-toeing around, too. None of the suggestions I've seen so far really call out to me "hey, this is lazy and has a non-lazy counterpart". Would it be so wrong to add "lazy" to the beginning or end so it's super obvious at a glance with zero cognitive overhead? Just to reiterate, I want to stress that finding a perfect name is of secondary concern to deciding to change the name in the first place. A big part of the argument against renaming things is "look how much debate there is about what it should be called, it's obvious there is no consensus, let's just leave things as they are".
Re: color library
On Monday, 22 June 2015 at 08:08:42 UTC, Rikki Cattermole wrote: I just had a look at antigrain. It really is beyond this code. Well and truly out of scope. I thought the color module is the first step to write AGG. Think of it as sort of std.graphics.algorithm.
Re: We need a typesystem-sanctioned way to cast qualifiers away
On Saturday, 20 June 2015 at 00:07:12 UTC, Andrei Alexandrescu wrote: I've gained a crapton of insight while working on collections. It's amazing. One interesting aspect is the interaction of mutable and functional collections with the type qualifiers "const" and "immutable". I managed to navigate around issues quite nicely, with two exceptions: 1. Reference counting: it's mutation underneath an immutable appearance. For a good while I'd been uncomfortable about that, until I figured that this is the "systems" part of D. Other languages do use reference counting, but at the compiler level which allows cheating the type system. It is somewhat fresh to attempt a principled implementation of both reference counting and safe functional collections, simultaneously and at library level. My conclusion is that changing the reference count in an otherwise immutable structure is an entirely reasonable thing to want do. We need a way to explain the type system "even though the payload is const or immutable, I'll change this particular uint so please don't do any optimizations that would invalidate the cast". The user is responsible for e.g. atomic reference counting in immutable data etc. A similar situation is hashing: Functional (immutable) collections could be used as hash keys. If you want to use non-trivial hash functions in a pure immutable collection, you either calculate up front "just in case" or reevaluate each time. Caching (lazy evaluation) is off the table. Then again, maybe you navigated around that one already.
Re: Future(s) for D.
On Monday, 22 June 2015 at 11:29:50 UTC, Jacob Carlborg wrote:
On 22/06/15 01:43, Nick Sabalausky wrote:
Curiosity, what libraries do you feel a lack of?
For work, that would be:
* Database drivers for Postgres and SQLite
https://github.com/etcimon/d2sqlite3
async with vibe.d :
https://github.com/pszturmaj/ddb/blob/master/examples/basic.d#L7
* ORM
https://github.com/buggins/hibernated
* Unit test framework. I want something like RSpec
I always got around fine with unittest { } and some imagination
* RabbitMQ and ActiveMQ
C=>D binding and register sockets in libasync?
* Some way to interface with Selenium and PhantomJS
You need to write the javascript to a file and use executeShell
or pipeShell.
I wanted to write a forward proxy in vibe.d though so that we can
actually handle the headers/cookies and analyze the contents over
the wire. I'm not sure if there's a language that does that
already
For non work related things it would also be:
* Sass
https://github.com/Lodin/sassed
* CoffeeScript
https://github.com/MartinNowak/diet-coffee/blob/master/source/diet_coffee.d#L23
* I would prefer HAML over that templates used in vibe.d but I
guess there' close enough
http://blog.seancarpenter.net/2013/05/24/using-haml-from-the-command-line/
You seem to be active member of the community. Why not attempt to
solve those? Doesn't seem like it would take that long (all the
primitives are there).
@rikki > I really do want to fix this. Unfortunately writing
everything from a an actual webserver to the template live
reloading is a lot harder then you'd think. Which is unfortunate.
You should have everything you need to write a D version of
Wordpress using its code as a reference. Maybe with vibe.d,
putting the data in Redis and using some lua scripting for themes
or configuration files. It would take some imagination but it's
not at all impossible to achieve it.
Re: color library
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 like that, instead, AGG consists of a number of loosely coupled algorithms that can be used together or separately. All of them have well defined interfaces and absolute minimum of implicit or explicit dependencies." It's architecture is what makes it so beautiful. You can configure your own graphics pipeline simply by passing the right template arguments. It would be an excellent showcase for D. Mike Thankfully we already have it: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ Data structures separated from algorithms with lazy range-like computations. It's just a matter of using it and improving on it.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 10:04:28 UTC, Marc Schütz wrote:
On Monday, 22 June 2015 at 06:38:57 UTC, Andrei Alexandrescu
wrote:
On 6/21/15 11:31 PM, Andrei Alexandrescu wrote:
On 6/21/15 10:25 PM, Walter Bright wrote:
The idea is that fun(5) would be lowered to:
auto tmp = 5;
fun(tmp);
I don't think that lowering is recommended - it prolongs the
lifetime of
the temporary through the end of the caller. But that may be
actually a
good thing.
On second thought - Walter's lowering, which makes the rvalue
last more than strictly necessary, may be the most flexible of
all at the cost of more resource consumption (for types that
define destructors). -- Andrei
Why would that be desirable? Resource consumption is the least
of the problems. It is simply surprising, inconsistent with the
lifetime of other temporaries, and it is unnecessary. Just
lower it to:
{
auto tmp = 5;
fun(tmp);
}
I see now that Andrei already wrote in the PR "creating a named
temporary in a scope immediately enclosing the call". I would
like to add that AFAIK other temporaries live until the end of
the entire statement they appear in, not just for the duration of
the call. In any case, the temporaries involved here should not
behave different from normal temporaries; in particular, they
should have the same lifetime as with pass-by-value.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu wrote: Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717. I have to concur with Manu's statement in the PR. IMO `auto ref` (i.e. the status quo) is a hack introduced because of the lack of usable `scope`. We shouldn't spread it to other parts of the language, at least not for rvalue references. `scope ref` is the perfect fit for those. (There may still be a use for `auto ref` with the meaning "pass this as efficiently as possible, I don't care whether it's a reference or not", but I'm not convinced of that either.)
Re: std.collection - changing the collection while iterating
On Monday, 22 June 2015 at 06:29:20 UTC, Andrei Alexandrescu wrote: The matter is very well understood. My point here is that leaving it to the user to make sure which ranges are still valid vs. not is not appropriate for D's container. -- Andrei Have you considered checking it at compile time? This is obviously the RCArray problem in disguise, and the same possible solutions apply here, too.
Re: std.collection - changing the collection while iterating
On 6/22/15 2:29 AM, Andrei Alexandrescu wrote: On 6/21/15 10:03 PM, Steven Schveighoffer wrote: An iterator remains valid as long as its target hasn't been removed. The matter is very well understood. My point here is that leaving it to the user to make sure which ranges are still valid vs. not is not appropriate for D's container. -- Andrei Then std.collection will be second fiddle to C++ and dcollections I'm afraid when it comes to usability. I won't be using such containers, and will continue to stick with a design that lacks training wheels. -Steve
Re: std.math.isIdentical and NaN
"Jonathan M Davis" writes: > On Monday, 22 June 2015 at 08:10:20 UTC, Dan Olson wrote: >> Docs for isIdentical say: >> >>Same as ==, except that positive and negative zero are not >> identical, >>and two NANs are identical if they have the same 'payload'. >> >> However, it returns false for NaN's with different signbits but same >> payload. Should this be the case? >> >> Ran into this because isIdentical is used in unittests to compare >> NaN's but I find an occassional test fails due to signbit for some >> operations on LDC ARM. I wrote an isNaNWithPayload() predicate for >> the failing tests, but wonder if isIdentical should ignore signbit >> for NaNs or have its docs changed. > > Well, given the name of the function and the fact that it's clearly > trying to check for NaN equality rather than treating their comparison > as always false, I would have expected that it would be true for NaNs > if they were absolutely identical, which presumably includes the > signbit, but I really don't know much about how NaNs are implemented, > so I don't know what the implications of that are. Still, it seems odd > to compare part of the NaN for equality but not all of it. Yeah, based on the name "isIdentical", its current behaviour assert(!isIdentical(-NaN(0xabc), NaN(0xabc)); does seem to correct. In that case the documentation could say "NaNs are identical if they have the same payload and signbit".
Re: std.collection - changing the collection while iterating
On 6/22/15 2:27 AM, Joseph Cassman wrote:
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/removing elements)
while iterating, we have the following possibilities:
1. Leave it undefined, like the STL does. Probably this is too extreme.
2. Throw an exception if a remove is attempted while ranges exist.
This works but it's conservative - e.g. it throws even if those ranges
are never to be used again etc.
3. Allow the removal but throw from the ranges if there's any attempt
to use a range following a remove.
4. Make it work such that ranges continue to be valid post removal.
Perhaps this is on the inefficient side.
Andrei
I was trying to understand how it could work with array slices. For
example, I was thinking of code similar to the following from TDPL p. 103:
import std.conv, std.stdio;
int main(string[] args) {
args = args[1 .. $];
while (args.length >= 2) {
if (to!int(args[0]) != to!int(args[$ - 1])) {
writeln("not palindrome");
return 1;
}
args = args[1 .. $ - 1];
}
writeln("palindrome");
return 0;
}
Is the slice above considered a range? If so then it seems that (4) is
already used a lot in existing D code. If it is not, then will slices of
the possible future library implementation of arrays be considered ranges?
I cannot see all difficulties arising from allowing (4), but I imagine
code complexity will increase as a result. Perhaps the compiler can
special case arrays to avoid possible issues making (4) allowable for
all containers?
No, what Andrei is referring to is modification of the referenced
structure (not just the elements). In other words, imagine removing 5
elements from the array while you are doing this iteration, and pushing
all the other elements up.
Modification of the range itself is not ever going to be illegal! A
range is for iterating, and if you need to iterate it, you must modify it.
Note also that although the above sample code uses a string which is
technically a range, it's not used with range primitives (front back,
popFront, popBack), and really it should be used that way to support UTF.
-Steve
Re: Naming things
On Monday, 22 June 2015 at 07:17:56 UTC, Mike wrote: It makes me disappointed to see contributions that dot the 'i's and cross the 't's get turned away and belittled. But, I don't think there's anything I can do about it, and although you've made an excellent argument, I've gathered enough wisdom in my time here to make a reasonable prediction of the outcome. I also believe the relatively little response you've received in this thread is likely not an indication that few care, or that few support your argument, but rather that they've seen it before, and they know how it ends. I agree with this, and given all the complaints by the leadership about lack of contribution, it's shocking to see the same individuals constantly putting down the work of others as not being of sufficient importance.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 13:23:47 UTC, Marc Schütz wrote: On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu wrote: Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717. I have to concur with Manu's statement in the PR. IMO `auto ref` (i.e. the status quo) is a hack introduced because of the lack of usable `scope`. We shouldn't spread it to other parts of the language, at least not for rvalue references. `scope ref` is the perfect fit for those. (There may still be a use for `auto ref` with the meaning "pass this as efficiently as possible, I don't care whether it's a reference or not", but I'm not convinced of that either.) I'm afraid that I don't understand this. What on earth does scope have to do with this issue? We need a way to indicate that a parameter should accept both lvalues and rvalues. auto ref was supposed to do that originally, but Walter misunderstood what Andrei was proposing and implemented what we have now, which is great for forwarding, but it doesn't solve the general case, because it only works with templates. That means that if we want that functionality we then need to either implement auto ref for non-templated functions as originally intended, or we need to come up with a new attribute which does that and which could be used with both templated and non-templated functions (thus not requiring the extra template bloat of the current auto ref implementation with templates if all you want is to accept both lvalues and rvalues, not have the refness of the argument forwarded). What on earth does _any_ of that have to do with scope? Theoretically, scope indicates that a variable isn't supposed to escape the function - whatever that really means (it's never actually been defined outside of delegates, and even there, I'm not sure that it's defined all that well). What does that have to do with accepting lvalues or rvalues? - Jonathan M Davis
Re: std.collection - changing the collection while iterating
On Monday, 22 June 2015 at 06:29:20 UTC, Andrei Alexandrescu wrote: The matter is very well understood. My point here is that leaving it to the user to make sure which ranges are still valid vs. not is not appropriate for D's container. -- Andrei If we mean that we don't want undefined behavior, and we want to do something like throw Errors when a programmer screws up and uses an invalidated range, then fine - especially if it's restricted to version(assert) like we've recently been doing with our checks for calling popFront or front on empty ranges in Phobos - then logic errors with containers can be caught more easily. But if you mean that the programmer shouldn't have to know what types of operations are going to invalidate a range for a specific container type, I don't see how that makes any sense at all. How can anyone expect to use a container without understanding it well enough to know what's going to happen when they start adding elements to it or removing elements from it while iterating over it? IIRC, Java tries to be nicer than C++ and throws an exception when you screw that up rather than treating it as undefined behavior, but even they don't try and make it work for you. You need to understand the container types that you're using if you expect your code to be correct or efficient. And remember that we're already dealing with undefined behavior with all ranges with stuff like what happens when you call front or popFront (or pretty much anything other than empty) on an empty range. So, it's not like we're not going to have undefined behavior involved here. You're just looking to avoid it in an additional case where folks have used a range incorrectly. I'd suggest that we do with containers what we've taken to doing with ranges in Phobos in the last year or so and add checks in version(assert) blocks which throw Errors when you screw up (which in the case of ranges in general would be throwing in functions like front or popFront when the range is empty, and in the case of ranges for containers would mean throwing an Error when you try and do something with them after they've been invalidated). But I don't think that it's at all unreasonable to consider code that tries to iterate over an invalidated range to be a logic error that the programmer needs to fix. Programmers should know when what they're doing to a container is going to invalidate its existing ranges. - Jonathan M Davis
Re: Future(s) for D.
On Monday, 22 June 2015 at 11:29:50 UTC, Jacob Carlborg wrote: On 22/06/15 01:43, Nick Sabalausky wrote: Curiosity, what libraries do you feel a lack of? For work, that would be: * Some way to interface with Selenium and PhantomJS It's not pretty, but for what I want to do I have found embedding Python calls to phantomjs code within a D program works quite well. The SQLite stuff looks okay, although I haven't used for a big project yet.
Re: Naming things
On Monday, 22 June 2015 at 11:51:27 UTC, Vladimir Panteleev wrote: Just to reiterate, I want to stress that finding a perfect name is of secondary concern to deciding to change the name in the first place. A big part of the argument against renaming things is "look how much debate there is about what it should be called, it's obvious there is no consensus, let's just leave things as they are". I think that it's abundantly clear that the names are not well chosen. It's a guarantee that you're going to have to look at the docs to have any clue as to which is lazy and which isn't. I completely agree with adding lazy versions of the functions like Walter is doing, and our naming situation sucks on some level given that we have never named things based on whether they were lazy or not, and so there really is no way that all of the names in Phobos are going to be consistent in that manner (not without breaking more code than we're willing to break anyway), but the new names do seem particularly bad. A function that starts with set doesn't even sound like it's lazy anyway - not to mention, wasn't setExt the old function that std.path had before it was revamped? Naming stuff is hard, but there is definitely a cost to poor names, which is something that Walter rarely seems to acknowledge, especially if it means changing an existing name - but since this is about functions that haven't even been released yet, I wouldn't think that it would be as big a deal to change them. - Jonathan M Davis
Re: Future(s) for D.
On Monday, 22 June 2015 at 14:03:47 UTC, Laeeth Isharc wrote:
On Monday, 22 June 2015 at 11:29:50 UTC, Jacob Carlborg wrote:
On 22/06/15 01:43, Nick Sabalausky wrote:
Curiosity, what libraries do you feel a lack of?
For work, that would be:
* Some way to interface with Selenium and PhantomJS
It's not pretty, but for what I want to do I have found
embedding Python calls to phantomjs code within a D program
works quite well.
The SQLite stuff looks okay, although I haven't used for a big
project yet.
This is how I use it as a persistent storage for property
get/setters. Takes some imagination at first, but it saves a huge
amount of time/headaches on the long run.
/// Opens the SQLite database from the data folder. The user must
call .close() when finished!
Database openDB(bool read = true) {
// DB is always created in static ctor
return Database(DATA_FOLDER_PATH() ~ "my.db", read ?
SQLITE_OPEN_READONLY : (SQLITE_OPEN_READWRITE |
SQLITE_OPEN_CREATE));
}
private T get(T)(string name, lazy T default_value = T.init) {
Database sqlite = openDB(READ);
scope(exit) sqlite.close();
T ret;
try {
auto results = sqlite.execute("SELECT value FROM config WHERE
name='" ~ name ~ "';");
auto val = results.oneValue!string;
ret = val.to!T;
}
catch { ret = default_value; }
return ret;
}
private void set(T)(string name, T value) {
Database sqlite = openDB(WRITE);
scope(exit) sqlite.close();
bool exists;
try {
ResultRange res = sqlite.prepare("SELECT value FROM config
WHERE name=?;").bind(1, name).execute();
string val = res.oneValue!string; // will throw if the value
is not there
// Update the existing value.
auto prep = sqlite.prepare("UPDATE TABLE config SET value=?
WHERE name=?;").bind(1, name).execute();
prep.bind(1, value.to!string);
res = prep.execute();
}
catch {
exists = false;
}
if (!exists) {
auto res = sqlite.prepare("INSERT INTO config (name, value)
VALUES (?, ?);").bind(1, name).bind(2, value.to!string).execute();
}
}
// usage:
@property Duration created() {
return get!ulong("created", 120).dur!"seconds";
}
@property void created(Duration val) {
set("created", val.total!"seconds");
}
Re: Naming things
On Monday, 22 June 2015 at 14:09:11 UTC, Jonathan M Davis wrote: Naming stuff is hard, but there is definitely a cost to poor names, which is something that Walter rarely seems to acknowledge, especially if it means changing an existing name - but since this is about functions that haven't even been released yet, I wouldn't think that it would be as big a deal to change them. 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 I failed to engage Walter Bright in this conversation; I don't think I should just reopen my pull request a second time, and I fear that if I merge someone else's pull request, I just might get my commit privileges revoked :)
Re: auto ref is on the docket
On 22 June 2015 at 23:49, Jonathan M Davis via Digitalmars-d wrote: > On Monday, 22 June 2015 at 13:23:47 UTC, Marc Schütz wrote: >> >> On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu wrote: >>> >>> Walter and I discussed what auto ref for templates should look like and >>> reached the conclusion that an approach based on lowering would be best. I >>> added a proposed lowering to >>> https://github.com/D-Programming-Language/dmd/pull/4717. >> >> >> I have to concur with Manu's statement in the PR. IMO `auto ref` (i.e. the >> status quo) is a hack introduced because of the lack of usable `scope`. We >> shouldn't spread it to other parts of the language, at least not for rvalue >> references. `scope ref` is the perfect fit for those. >> >> (There may still be a use for `auto ref` with the meaning "pass this as >> efficiently as possible, I don't care whether it's a reference or not", but >> I'm not convinced of that either.) > > > I'm afraid that I don't understand this. What on earth does scope have to do > with this issue? We need a way to indicate that a parameter should accept > both lvalues and rvalues. This is what I don't understand; why does this have anything to do with rvalues/lvalues specifically? An rvalue is just a temporary. It can safely be passed to anything that we can be sure won't keep a reference to it; that's why escape analysis seems to be the best approach. This problem extends beyond rvalues, there are other forms of temporaries which exhibit the exact same problem, ie, an rvalue written to the stack explicitly on the line prior to the function call: f(vec3(1,2,3)); // onoes, comple error! vec3 v = vec3(1,2,3); f(v); // no worries bro! This is accepted today, but the safety of the operation is identical to the rejected line above. This is the de facto means to 'work around' the problem, and it's just a pointless nuisance. Both problems should be dealt with in the same way. > auto ref was supposed to do that originally, but > Walter misunderstood what Andrei was proposing and implemented what we have > now, which is great for forwarding, but it doesn't solve the general case, > because it only works with templates. That means that if we want that > functionality we then need to either implement auto ref for non-templated > functions as originally intended, or we need to come up with a new attribute > which does that and which could be used with both templated and > non-templated functions (thus not requiring the extra template bloat of the > current auto ref implementation with templates if all you want is to accept > both lvalues and rvalues, not have the refness of the argument forwarded). It's been proposed repeatedly for years. 'scope' as a means of expressing borrowing or escape analysis would solve the problem elegantly, in addition to other uses. There was also an idea Walter had at dconf 13, where he could do runtime checking similar to range checking for safety validation, thereby allowing unqualified ref args to receive temporaries safely. > What on earth does _any_ of that have to do with scope? Theoretically, scope > indicates that a variable isn't supposed to escape the function - whatever > that really means (it's never actually been defined outside of delegates, > and even there, I'm not sure that it's defined all that well). What does > that have to do with accepting lvalues or rvalues? If a parameter was scope, it can safely receive an rvalue.
Re: std.experimental.testing PR review
On Friday, 19 June 2015 at 15:24:25 UTC, Atila Neves wrote: On Monday, 1 June 2015 at 16:38:06 UTC, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. Atila On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: [...] Methinks all comments have been addressed again, except for the multi-threading by default or not. Atila Bump. Personally I think this is ready for voting. Atila
Re: Future(s) for D.
On 23/06/2015 12:46 a.m., Etienne wrote:
On Monday, 22 June 2015 at 11:29:50 UTC, Jacob Carlborg wrote:
On 22/06/15 01:43, Nick Sabalausky wrote:
Curiosity, what libraries do you feel a lack of?
For work, that would be:
* Database drivers for Postgres and SQLite
https://github.com/etcimon/d2sqlite3
async with vibe.d :
https://github.com/pszturmaj/ddb/blob/master/examples/basic.d#L7
* ORM
https://github.com/buggins/hibernated
* Unit test framework. I want something like RSpec
I always got around fine with unittest { } and some imagination
* RabbitMQ and ActiveMQ
C=>D binding and register sockets in libasync?
* Some way to interface with Selenium and PhantomJS
You need to write the javascript to a file and use executeShell or
pipeShell.
I wanted to write a forward proxy in vibe.d though so that we can
actually handle the headers/cookies and analyze the contents over the
wire. I'm not sure if there's a language that does that already
For non work related things it would also be:
* Sass
https://github.com/Lodin/sassed
* CoffeeScript
https://github.com/MartinNowak/diet-coffee/blob/master/source/diet_coffee.d#L23
* I would prefer HAML over that templates used in vibe.d but I guess
there' close enough
http://blog.seancarpenter.net/2013/05/24/using-haml-from-the-command-line/
You seem to be active member of the community. Why not attempt to solve
those? Doesn't seem like it would take that long (all the primitives are
there).
@rikki > I really do want to fix this. Unfortunately writing everything
from a an actual webserver to the template live reloading is a lot
harder then you'd think. Which is unfortunate.
You should have everything you need to write a D version of Wordpress
using its code as a reference. Maybe with vibe.d, putting the data in
Redis and using some lua scripting for themes or configuration files. It
would take some imagination but it's not at all impossible to achieve it.
What can I say? I like doing things 100% or not at all. Design wise atleast.
Oh one more thing, my next web service framework will be using lua for
templates. The only thing not implemented is passing in data models. Its
just even with luad binding D models to it is quite hard. Doable within
a few days if the ORM is ready to go but when you add everything up. Ugh.
Re: std.collection - changing the collection while iterating
On Monday, 22 June 2015 at 13:42:41 UTC, Steven Schveighoffer
wrote:
On 6/22/15 2:27 AM, Joseph Cassman wrote:
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
[...]
I was trying to understand how it could work with array
slices. For
example, I was thinking of code similar to the following from
TDPL p. 103:
import std.conv, std.stdio;
int main(string[] args) {
args = args[1 .. $];
while (args.length >= 2) {
if (to!int(args[0]) != to!int(args[$ - 1])) {
writeln("not palindrome");
return 1;
}
args = args[1 .. $ - 1];
}
writeln("palindrome");
return 0;
}
Is the slice above considered a range? If so then it seems
that (4) is
already used a lot in existing D code. If it is not, then will
slices of
the possible future library implementation of arrays be
considered ranges?
I cannot see all difficulties arising from allowing (4), but I
imagine
code complexity will increase as a result. Perhaps the
compiler can
special case arrays to avoid possible issues making (4)
allowable for
all containers?
No, what Andrei is referring to is modification of the
referenced structure (not just the elements). In other words,
imagine removing 5 elements from the array while you are doing
this iteration, and pushing all the other elements up.
Modification of the range itself is not ever going to be
illegal! A range is for iterating, and if you need to iterate
it, you must modify it.
Note also that although the above sample code uses a string
which is technically a range, it's not used with range
primitives (front back, popFront, popBack), and really it
should be used that way to support UTF.
-Steve
Yeah, that's not the input range troika. Wasn't clear on how
slicing plays into the matter. Thanks Steve.
I think a developer should understand what is trying to do with a
particular type of collection and so am fine with undefined
behavior if a collection is modified while iterating. An error
resulting from such an invalid state does not seem exceptional to
me, rather a logic error on the part of the developer. So
exceptions do not seem a fit to me here. I don't like the
proliferation of try-catch blocks in Java. Would also like to use
collections in nogc code as well, as much as is possible.
If assistance is added from the compiler a la contracts or
asserts to catch such logic errors than that is pretty cool.
Compile-time is a nice plus but if too difficult it could be left
to the developer's responsibility just fine, IMO.
Joseph
Re: auto ref is on the docket
On 6/22/15 3:04 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
Just lower it to:
{
auto tmp = 5;
fun(tmp);
}
You need to lower an expression to an expression, not a statement. (e.g.
what if fun returns a result?)
I considered this lowering for "int fun(ref int);"
fun(42)
==>>
(function int(int a) { return fun(a); })(42)
This does work, but if fun returns a ref int, I found no way to
syntactically express that lambda. This does not parse:
(function ref int(int a) { return fun(a); })(42)
Is this a bug in the grammar?
Andrei
Re: Future(s) for D.
On Saturday, 20 June 2015 at 12:35:11 UTC, weaselcat wrote:
I recently read this facebook post on their future
implementation in their Folly library.
https://code.facebook.com/posts/1661982097368498
This made me slightly envious. Thoughts on a D implementation?
After having worked with Observables/RX[1], Futures look kind of
silly to me. I implemented some of them into D (with the help of
fibers).
Recently I made a small program that, on a merged pull-request on
bitbucket, looks if the branch contains fix123, bug-123, etc. and
toggles the ready-to-review status on the issue-tracker.
This is what the code looks like:
```
bitbucketObservable.filter((PullRequest pr)
{
return pr.destination == "master" && pr.type ==
PullRequest.Type.MERGED;
}).map((PullRequest pr)
{
auto r = regex(r"(fix|bug)[\/\-_]*([0-9]+)");
return match(pr.source, r);
}).filter((RegexMatch!(string, ThompsonMatcher) m)
{
return !m.empty();
}).map((RegexMatch!(string, ThompsonMatcher) m)
{
return m.captures[2].to!int;
}).concatMap((int bug)
{
return getCookie.fork(1).setReadyToReview(bug, "updated
from D");
}).subscribe((json)
{
writefln("Response from bontq: %s",json);
},(Exception e)
{
writeln("Error: %s",e);
});
```
[1] https://github.com/Reactive-Extensions/RxJS
Re: Naming things
I agree with Vladimir -- There should be a naming convention for identifying whether a function is eager or lazy. Learning a naming convention once and applying it repeatedly is a better process than repeatedly referencing documentation. A programming language should have built-in functionality that is named in such a way that it clearly expresses its intent. For newbies, it can be very off-putting to be introduced to a language where this is not the case. Perhaps some veterans of the D language can't clearly see this. There is no good reason that the new introduction of built-ins should not follow a well-defined naming scheme. I'd actually go a bit further and deprecate old functions that do not meet the scheme and phase them out over time. Bikeshedding is arguing over trivial naming schemes. Choosing to adhere to a naming scheme is not bikeshedding, IMHO. Thanks,
Re: auto ref is on the docket
Rather than raising the matter of scope again and again, we should be thankful that a solution for this nasty problem is accepted and could be merged. How scope and escape analysis could do a better job is unclear and if you want to solve the problem this way you will wait a very long time. So please let us concentrate and discuss how we could solve this problem with auto ref. :) To repeat my statement from the PR: I would also prefer to avoid the generation of further functions, because I want to avoid the code bloat. I like the way of the current implementation, because it is following the way C++ does and will be understandable for every person which comes from C++.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 13:49:31 UTC, Jonathan M Davis wrote: On Monday, 22 June 2015 at 13:23:47 UTC, Marc Schütz wrote: On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu wrote: Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717. I have to concur with Manu's statement in the PR. IMO `auto ref` (i.e. the status quo) is a hack introduced because of the lack of usable `scope`. We shouldn't spread it to other parts of the language, at least not for rvalue references. `scope ref` is the perfect fit for those. (There may still be a use for `auto ref` with the meaning "pass this as efficiently as possible, I don't care whether it's a reference or not", but I'm not convinced of that either.) I'm afraid that I don't understand this. What on earth does scope have to do with this issue? We need a way to indicate that a parameter should accept both lvalues and rvalues. `scope` is a precondition for doing this safely. As Manu pointed out, rvalues are merely a special case of a more general problem, but with them, the risk of misuse is much higher than with local variables. That was probably the reason why `ref` originally was designed not to accept rvalues. Given a working `scope` feature, that reason is no longer relevant, therefore `scope ref` can safely accept both rvalues and lvalues.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 15:39:38 UTC, Andrei Alexandrescu
wrote:
On 6/22/15 3:04 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
Just lower it to:
{
auto tmp = 5;
fun(tmp);
}
You need to lower an expression to an expression, not a
statement. (e.g. what if fun returns a result?)
I considered this lowering for "int fun(ref int);"
fun(42)
==>>
(function int(int a) { return fun(a); })(42)
This does work, but if fun returns a ref int, I found no way to
syntactically express that lambda. This does not parse:
(function ref int(int a) { return fun(a); })(42)
Is this a bug in the grammar?
Probably. But for lowering, the resulting AST doesn't really need
to be representable in the language's syntax. I'm sure the AST
_can_ express a lambda returning by reference.
Anway, I really think we should not deviate from the normal
lifetime rules for temporaries.
Re: D could catch this wave: web assembly
On 06/22/2015 05:16 AM, Joakim wrote: > I really liked the new Fisher-Price style of desktop Windows 8, Ugh, now *that* one I don't like. Simplicity is nice, but ugly is just ugly. It looks like a re-imagining of Win1 and Win2 drawn up by a hung-over unicorn ;) > along > with better visualizations like the graph when copying files. That graph is nice. Unnecessary perhaps, but certainly nice. I really like the new process manager, actually. I wish KDE's was more like that. On Sunday, 21 June 2015 at 18:51:41 UTC, Nick Sabalausky wrote: Not if you're just reinventing the form factor by propping up your monitor^H^H^H^H^H^H^Htablet and pulling out a keyboard+mouse. It's just the particular lineage that (might) go away. Heh, you're really reaching now. :) Most people wouldn't call a smartphone or tablet in a dock "reinventing the [desktop] form factor." Of course they won't *call* it that, because they're easily swayed by image and marketing. People refer to iPhone and such as "phones" even though they're obviously much more of a pocket computer (that happens to support cellular communications) than a telephone. Well, somebody was saying that mobile processors have been getting closer and closer in power to laptops. Which I have to strongly agree with. Maybe that wasn't you though. By that rationale, since desktop chips nowadays are as powerful as mainframes from a decade ago, desktops are really just mainframes, right? ;) You and Kagamin are really reaching with these assertions. You're twisting my words around here. My point right there was simply "the gap in mobile and PC's processing power is closing". You seem to be taking it as "Merely having the processing power of X is, by itself, enough to makes it actually BE X", which is obviously not my argument at all. Not "converged". "ConvergING" towards some point in between traditional iPhone (and clones) and traditional laptop. And yes, *partly* because connecting keyboard/mouse is not something people have normally done with smartphones (at least not typically). And also because the gap in processing power is shrinking. And because you can now connect them to an external monitor. And because they're gaining desktop UIs. Maybe some other things too I haven't thought of off the top of my head. Except that looking at that smartphone that has all those features that will allow them to kill off the desktop, they'll look exactly the same as smartphones do now. Really, the only difference will be the addition of the multi-window UI capability, nothing else will have "converged." I wouldn't call that convergence between iPhones and laptops, rather smartphones simply picking up yet one more feature that allows them to kill off the desktop/laptop PC. Hmmm, you're still outright ignoring most of what I've said about that. I'll repeat myself only one more time: "PARTLY because connecting keyboard/mouse is not something people have normally done with smartphones (at least not typically). And ALSO because the gap in processing power is shrinking. And ALSO because you can now connect them to an external monitor. And ALSO because they're gaining desktop UIs. And ALSO misc other stuff." Stop picking ONE aspect of all that and pretending my argument revolves purely around that one aspect alone. > A car still moves on wheels yet nobody would say > it "converged" with a horse and carriage. One feature, the wheels, > carried over, but most of it is completely different. There's really no parallel between that and what I'm talking about. Oh, it's pretty much the same. :) Replace wheels with multi-window UIs and that is exactly the point you're making. No, it isn't, but you seem to be misinterpreting nearly everything about my point anyway. > I think that > since the underlying device, a smartphone, is fairly different from a > mainframe or a PC, How so? *You're* the one saying (even more than I am anyway) that they are (or will soon be) suitable replacements for PCs. How do you reconcile that with now suddenly saying they're different in a big enough way to be meaningful? Because they're really only taking one feature from desktops/laptops, the multi-window UI, in order to replace them. Otherwise, they will be the same smartphones that they are now, which you don't call desktops. *One* feature? No. At least one *MORE* feature. That's on top of everything they've already borrowed. You're acting as if smartphones have ALWAYS had host-USB, HDMI-out, processors that approach PC-level power, storage that approaches low-end laptops, multi-processing, commonly getting used with an external keyboard/mouse, etc. A lot of the convergence has *already* been happening, and you never even noticed ;) In fact that's WHY people are starting to notice their potential for replacing traditional PCs. God I hope not. :) Touchscreen mini-chicklet keyboards (not to mention auto-correction) are already clunky and
Re: Naming things
On Monday, 22 June 2015 at 16:06:33 UTC, Kelet wrote: I agree with Vladimir -- There should be a naming convention for identifying whether a function is eager or lazy. Learning a naming convention once and applying it repeatedly is a better process than repeatedly referencing documentation. A programming language should have built-in functionality that is named in such a way that it clearly expresses its intent. For newbies, it can be very off-putting to be introduced to a language where this is not the case. Perhaps some veterans of the D language can't clearly see this. There is no good reason that the new introduction of built-ins should not follow a well-defined naming scheme. I'd actually go a bit further and deprecate old functions that do not meet the scheme and phase them out over time. Bikeshedding is arguing over trivial naming schemes. Choosing to adhere to a naming scheme is not bikeshedding, IMHO. Thanks, Well put. I don't like how often I have to refer to the documentation. And I have been trying to use D for a while. A naming convention expressing intent should reduce the need for frequenting the documentation. This would be a welcome addition. Even at the cost of dusruptive change. Joseph
Re: D could catch this wave: web assembly
On Sunday, 21 June 2015 at 11:56:13 UTC, Joakim wrote: importance of which Wyatt and I discussed above. Just by webasm being implemented in all major browsers, it would certainly lead to a _lot_ less javascript getting written, once devs actually have a choice of other languages, even if they'd still have to wrap javascript calls for DOM manipulation. People are already writing less javascript, but without a GC in webasm most languages are better of compiling to javascript or a mix. As for Java and Flash, they were very widely used, despite being slow and in their own little world inside the browser. They were used in very narrow domains. might help. I haven't messed with canvas much, but it's interesting how little it's been used, despite all the hype it got when it was first released. Well, you can often get more done in less time by using HTML5/CSS. That's the only reason. That's what you do when you mash a bunch of disparate technologies together: make them mixable and flexible and let the devs deal with all the complexity and bugs. :) In a way, yes, but that how things grow when you have an installed base. Evergreen browsers could in theory change it, but we rely on Apple and Microsoft to update browsers for old OSes to get there. If speed of parsing and analyzing weren't one of the main issues, why are they even taking this webasm binary approach? A binary SVG can be made part of the DOM too once it's parsed. I think the vendors have realized that they need to take babysteps in concert, because there is to much politics involved to accept a "whole-sale solution" like PNACL etc. IMO it basically means that they all want some kind of IR, but don't agree on the specifics. In the scripting API using text as values might be an issue, but that's a different topic. Nothing that couldn't be made to work with the appropriate binary encoding. Not sure what that means. You need to have a different type-system for values so that you can differentiate between units (px, em, etc).
Re: auto ref is on the docket
On Monday, 22 June 2015 at 16:10:10 UTC, Namespace wrote: Rather than raising the matter of scope again and again, we should be thankful that a solution for this nasty problem is accepted and could be merged. I disagree strongly with this. A bad solution is worse than no solution. How scope and escape analysis could do a better job is unclear and if you want to solve the problem this way you will wait a very long time. Not at all. `auto ref` without a working `scope` implementation is unsafe. If that is acceptable for now, then it should be just as acceptable to already use `scope ref` as a syntax for the same semantics, even if the required escape-proofing of `scope` is not yet implemented. If/when we will finally get a working `scope`, using those functions will then be actually verified by the compiler. In the meantime, the `scope` keyword will at least express the intention to the caller and will serve as a reminder to the callee's author. In contrast, with `auto ref` accepting rvalues, we will have the same keywords `auto ref` mean two very different things for templates and non-templates, we still won't have a way to write rvalue-ref-accepting template functions, and when we will finally get `scope`, `auto ref` will be a pointless alternative syntax for `scope ref` that will have to be kept around forever. So please let us concentrate and discuss how we could solve this problem with auto ref. :) Use `scope ref` instead of `auto ref` now, and just ignore that it's unsafe for the moment. Your PR will become even shorter with it, because you no longer need `STCrvref`. Conceptually, just do "#define STCrvref (STCref | STCscope)". To repeat my statement from the PR: I would also prefer to avoid the generation of further functions, because I want to avoid the code bloat. That's what my suggestion does, too. I like the way of the current implementation, because it is following the way C++ does and will be understandable for every person which comes from C++. With the difference that C++ requires const-ness.
Re: PHP verses C#.NET verses D.
On Monday, 22 June 2015 at 06:32:31 UTC, Nick B wrote: On Thursday, 18 June 2015 at 03:44:08 UTC, Etienne Cimon wrote: Etienne Would you like to detail what still needs to be completed/on the to-do list ? What would be the best way to learn it ? Does it need documentation as well ? Nick The docs should be the same as the ones on vibed.org As for the todo list, It's a little long to detail it. Depends also on where you want to go. Urgent: - Update libhttp2 and botan with recent changes from the original repos (nghttp2, botan). No stability issues, only new algorithms mostly. - Write a Windows/Mac/linux daemon utility with rights elevation to have support for desktop application development (currently finishing up windows) - The Mac daemon requires launchd, which compiles only with DMD pull request to be merged: https://github.com/D-Programming-Language/dmd/pull/4321 - Uses the http://diveframework.com/ to elevate - Test the live debugging features with third party applications (similar to packet-capturing but server-side). - This is completed and available on my fork of vibe.d and a reverse proxy request looks like this: http://htmlpreview.github.io/?https://github.com/etcimon/vibe.d/blob/master/views/capture.html => http://pastebin.com/raw.php?i=E51RXyt2 - Also includes json req/response or call stack in builds compiled with release - Try running with LDC and debug the libraries until everything completely compiles with it (2.067+) - Find a way to add a thread-local GC in druntime or at least make dub compile the projects with it. Less urgent: - Implement administration interface for the new redis 3.0 clustering feature - Write a DNS server with A-record scheduling for distribution - Adapt VibeDist to send requests to worker tasks - Add support for runtime loading of DLL plugins that auto-register/unregister to the router. - Test lua bindings to develop runtime themes I also have private application development on the todo list which ends up testing the library. Lots of testing is still needed but I think the server exceeds what I could make any other server do. It compiles in a single portable executable 2mb packed after all.
Re: auto ref is on the docket
We had this discussion already with DIP 36. A PR still exists AFAIK, but because it was rejected I don't think that's going to happen. :) So auto ref is obviously the choice. If you insist on scope/in ref, please make your own thread and ask why it was rejected or read the corresponding thread.
Re: Naming things
On Monday, 22 June 2015 at 11:45:31 UTC, Wyatt wrote: None of the suggestions I've seen so far really call out to me "hey, this is lazy and has a non-lazy counterpart". Would it be so wrong to add "lazy" to the beginning or end so it's super obvious at a glance with zero cognitive overhead? -Wyatt This would be my preferred option. When C# introduced asynchronous counterparts of existing methods, they appended "Async" to the names, which seems to have worked out well - eg, Wait/WaitAsync, Read/ReadAsync. So we'd have setExtension/setExtensionLazy etc.
Re: Naming things
On Saturday, 20 June 2015 at 20:43:21 UTC, Nick Sabalausky wrote: On 06/20/2015 05:27 AM, Vladimir Panteleev wrote: [...] +1kazillion +1 ;)
Re: auto ref is on the docket
I see no reasons why « ref in » is bad. Maybe someone explain ? It's also natural for those who came from C++. In C++ there's no problem with const&, so why they will be in D?
Re: auto ref is on the docket
On 6/22/15 9:54 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: `auto ref` without a working `scope` implementation is unsafe. I'm unclear on this. With the existence of the return attribute, what's unsafe about auto ref? -- Andrei
Re: auto ref is on the docket
On Monday, 22 June 2015 at 18:03:43 UTC, Temtaime wrote: I see no reasons why « ref in » is bad. Maybe someone explain ? It's also natural for those who came from C++. In C++ there's no problem with const&, so why they will be in D? Because const is transitive in D and therefore more restrictive.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 16:54:50 UTC, Marc Schütz wrote: On Monday, 22 June 2015 at 16:10:10 UTC, Namespace wrote: Rather than raising the matter of scope again and again, we should be thankful that a solution for this nasty problem is accepted and could be merged. I disagree strongly with this. A bad solution is worse than no solution. How scope and escape analysis could do a better job is unclear and if you want to solve the problem this way you will wait a very long time. Not at all. `auto ref` without a working `scope` implementation is unsafe. If that is acceptable for now, then it should be just as acceptable to already use `scope ref` as a syntax for the same semantics, even if the required escape-proofing of `scope` is not yet implemented. If/when we will finally get a working `scope`, using those functions will then be actually verified by the compiler. In the meantime, the `scope` keyword will at least express the intention to the caller and will serve as a reminder to the callee's author. In contrast, with `auto ref` accepting rvalues, we will have the same keywords `auto ref` mean two very different things for templates and non-templates, we still won't have a way to write rvalue-ref-accepting template functions, and when we will finally get `scope`, `auto ref` will be a pointless alternative syntax for `scope ref` that will have to be kept around forever. So please let us concentrate and discuss how we could solve this problem with auto ref. :) Use `scope ref` instead of `auto ref` now, and just ignore that it's unsafe for the moment. Your PR will become even shorter with it, because you no longer need `STCrvref`. Conceptually, just do "#define STCrvref (STCref | STCscope)". I definitely see your point and very much agree! I like the way of the current implementation, because it is following the way C++ does and will be understandable for every person which comes from C++. With the difference that C++ requires const-ness. Yep, so `in ref T` translating to `scope const ref T` would be D's convenient and safe counterpart to C++' `const T&` parameters, for their main use case: passing pure-input arguments of types which are or may be costly to copy (post-blit ctor, dtor, or simply big). I explicitly mention 'may be' here because in templates one often doesn't know (containers...). As I have already pointed out in another thread, I'd go one step further and propose an extremely convenient `in T` for this very common use case: * The argument is passed by value (`const T`) if the compiler assumes moving/copying is more efficient than passing a reference (with its indirection on the callee side) for the particular target environment (hardware, ABI), e.g., for plain-old-datatypes T fitting into 1-2 registers, and Object references obviously. * Otherwise, the argument is passed by-ref (`in ref T`). As `in T` doesn't mention any ref at all, it's clear that the hidden reference cannot escape. Let me give you an example. The Win64 ABI only allows passing POD types <= 64 bit by value (exception: vector/SSE types). All other types need to be passed by ref, which means that D's otherwise cool in-place construction of arguments on the callee's function parameters stack isn't possible. The current `auto ref` implementation for templates is in vain on Win64 for these byref-types, as the ABI forces both versions to take the argument byref anyway. I'm pretty sure I could live without an `auto ref` for templates once I can use `in T` for all my pure-input parameters. If the function may change the argument, I'd go with `scope ref T`, accepting rvalues too. If the function may even let the argument escape, it'll have to be `ref T` or `const/immutable ref T`. And if I just want to mutate the parameter inside my function, but not touch the argument, it'd be `T`. I can't think of any other use cases for function parameters atm.
What have you done with UDAs?
I never seem to use them for anything, has anyone else done anything interesting with them?
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? https://github.com/linkrope/dunit#user-defined-attributes
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? UDAs are very useful for IO libraries. You can find them in vibe.d web server: http://d.readthedocs.org/en/latest/examples.html#service (see last method)
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote:
I never seem to use them for anything, has anyone else done
anything interesting with them?
I'm writing a program that can accept subcommands via either the
command line (ex. `prog mycmd 1 2`) or via a shell. I represent
each command as a function, use UDAs to store the help text and
if they can be ran from the command line or shell. The command
list, full help text, and command dispatcher is generated at
compile time via templates, CTFE, and static foreach.
An example command:
@("") // arguments
@("Sets the amount of time to increment the clock on each
frame.") // description
@ShellOnly // can't be ran from command line
int cmd_set_time_per_frame(string[] args) {
// ...
}
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? I use them all the time: https://github.com/atilaneves/unit-threaded https://github.com/atilaneves/cerealed https://github.com/atilaneves/unencumbered https://github.com/D-Programming-Language/phobos/pull/3207 (std.experimental.testing proposal) Compile-time reflection seems to be my D hammer. Atila
Re: What have you done with UDAs?
On 06/22/2015 03:18 PM, Ilya Yaroshenko wrote: On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? UDAs are very useful for IO libraries. You can find them in vibe.d web server: http://d.readthedocs.org/en/latest/examples.html#service (see last method) Yea, I really like vibe's use of them. I've worked with web tools before that inferred URLs and querty string value names and visibility from the names/visibility of classes/functions/arguments. But I never liked that approach, how it conflates internal names/visibility with external interface. Too much implicit magic, and too much leaking of internals. UDA'a maintain the convenience of that approach, but keep a nice clean separation.
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? Like several others, I use them for generating command line interfaces to set variables / invoke methods using reflection. For example https://shardsoft.com/stash/projects/SHARD/repos/dap/browse/source/dap/Standalone.d#51 results in something like: D Asset Pipeline Converts assets into an intermediate post-processed format more efficiently loaded at runtime. Commands: [--init]: Initializes the folder structure for a dap repository using a Content subdirectory in this folder. [--clean]: Cleans the output directory, removing all built assets. [-h|--help]: Displays the help string. [-a|--add]: Adds the given raw asset to the asset store using the default processor and default settings. [-r|--remove]: Removes the asset with the specified qualified name from the asset store. [-l|--list]: Lists all assets currently stored. [-b|--build]: Builds all dirty assets using current settings. [-i|--inspect]: Shows all properties of the given asset. [-o|--open]: Opens the given asset in an external editor. [-m|--modify]: Modifies a property of a processor on an asset, or the processor used to build the asset. Options: [--input-folder]: The folder that assets should be read from and settings stored in. Default: Content/Input [--output-folder]: The folder that generated assets should be saved to. Default: Content/Output [--log-level]: The minimum severity for a message to be logged. Default: info
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? 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.
Re: Naming things
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 I failed to engage Walter Bright in this conversation; I don't think I should just reopen my pull request a second time, and I've been reading these things, but not engaging in them because it seemed best to let everyone have their say without interference from me. > I fear that if I merge someone else's pull request, I just might get my > commit privileges revoked :) I don't know where I get this terrible reputation - I've never revoked anyone's commit privileges. And certainly not yours - your track record of contributions and positive influence on D is impeccable.
Re: Future(s) for D.
On 22/06/15 14:46, Etienne wrote:
On Monday, 22 June 2015 at 11:29:50 UTC, Jacob Carlborg wrote:
* Database drivers for Postgres and SQLite
https://github.com/etcimon/d2sqlite3
async with vibe.d :
https://github.com/pszturmaj/ddb/blob/master/examples/basic.d#L7
* ORM
https://github.com/buggins/hibernated
* Unit test framework. I want something like RSpec
I always got around fine with unittest { } and some imagination
* RabbitMQ and ActiveMQ
C=>D binding and register sockets in libasync?
Seems I need to actually make a try on using these libraries.
For non work related things it would also be:
* Sass
https://github.com/Lodin/sassed
* CoffeeScript
https://github.com/MartinNowak/diet-coffee/blob/master/source/diet_coffee.d#L23
* I would prefer HAML over that templates used in vibe.d but I guess
there' close enough
http://blog.seancarpenter.net/2013/05/24/using-haml-from-the-command-line/
You seem to be active member of the community. Why not attempt to solve
those? Doesn't seem like it would take that long (all the primitives are
there).
In general I feel it hard to justify when everything is already
implemented in Ruby. At some point I just want to use a language and the
libraries without needing to reinvent the wheel. Back in 2006 when I
started with D I had some idea for an application I wanted to build. But
there were a lot of missing components (many still are), I still haven't
started building that application.
--
/Jacob Carlborg
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? They are great! see my post about one use case: http://extrawurst.github.io/dlang/metaprogramming/imgui/2015/05/28/dlang-annotations.html
Re: Phobos addition formal review: std.experimental.allocator
On 6/21/15 4:47 AM, Dicebot wrote:
1. I have already mentioned that there is neither module structure
overview in `package.d` nor actual module structure. This is still the
case for
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
Improved:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
2. `IAllocator` is defined inside `package.d` file. That means that it
is impossible to use interface without import ALL of allocator modules
Fixed, now interested users need to import
std.experimental.allocator.building_blocks.
3. Same concern is about
https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/package.d#L218-L228
- unless you actually import all stuff via package.d, those configured
allocators are not available.
Fixed per above.
4. There are no higher level usage examples and/or guidelines about how
this is supposed to fit in user applications. Intention behind the
library may be familiar to users coming from C++ but target D audience
is much more than that. Having std.allocator.showcase is nice but it is
still a bit too theoretical.
Coming soon.
5.
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_stats_collector.html
has no overview documentation at all
Coming soon.
6. Usage of ternary is not always clear / justified. In `IAllocator` it
is explained and makes sense but there are things like
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_bitmapped_block.html
("Ternary empty() - Returns true iff no memory is currently allocated
with this allocator"). I am still not sure why it is used there instead
of simple boolean.
Coming soon.
Andrei
Re: What have you done with UDAs?
On 22/06/15 21:09, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? Serialization: https://github.com/jacob-carlborg/orange/blob/master/tests/NonSerialized.d#L25-L39 Selectors in D/Objective-C. It's actually a compiler recognized UDA, but still a UDA: https://github.com/jacob-carlborg/dmd/blob/dobjc_instance_methods/test/runnable/objc_call.d#L7 -- /Jacob Carlborg
Re: D could catch this wave: web assembly
On Sunday, 21 June 2015 at 15:59:57 UTC, Nick Sabalausky wrote: On 06/21/2015 09:45 AM, Joseph Rushton Wakeling wrote: Threw what in the trash-bin? https://en.wikipedia.org/wiki/Ubuntu_for_Android Though I may very well be missing something. Yea, Ubuntu for Android was a cool idea that sadly, as I understand it, got no uptake from manufacturers. So Canonical just pushed ahead with their own full-Ubuntu phone and tablet OS and UI, and played everything much quieter until they'd actually landed hardware partners. It's obviously early days, but I think there's much to be quietly confident about: there's a lot to like in the OS and app design, and it is now by a long stretch the most free (as in freedom) phone OS available.
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote:
I never seem to use them for anything, has anyone else done
anything interesting with them?
I use a few in the deadcode editor e.g.:
Function can be called by a menu entry:
@MenuItem("Edit/Copy")
Function can be called by a shortcut:
@Shortcut(" + ")
Function should run in a fiber when called:
@InFiber
Re: Future(s) for D.
On Monday, 22 June 2015 at 19:45:57 UTC, Jacob Carlborg wrote: On 22/06/15 14:46, Etienne wrote: [...] [...] Seems I need to actually make a try on using these libraries. [...] In general I feel it hard to justify when everything is already implemented in Ruby. At some point I just want to use a language and the libraries without needing to reinvent the wheel. Back in 2006 when I started with D I had some idea for an application I wanted to build. But there were a lot of missing components (many still are), I still haven't started building that application. I can't really know how it would've been like back then. Today it looks like there might be a future in web dev for D, I'd think people are willing to invest their name on a library to be part of it.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 05:25:57 UTC, Walter Bright wrote: The idea is that fun(5) would be lowered to: auto tmp = 5; fun(tmp); But when talking to Andrei I didn't realize that it would be subtly different behavior than 'auto ref' for template functions, which makes me concerned that this is not a good idea. Considering we already have working 'Sealed references', why not simply allow rvalues for plain ref? Bonus: No risk of mixup with template auto ref after refactoring etc. Save auto for other potential future use.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 20:42:58 UTC, Daniel N wrote: On Monday, 22 June 2015 at 05:25:57 UTC, Walter Bright wrote: The idea is that fun(5) would be lowered to: auto tmp = 5; fun(tmp); But when talking to Andrei I didn't realize that it would be subtly different behavior than 'auto ref' for template functions, which makes me concerned that this is not a good idea. Considering we already have working 'Sealed references', why not simply allow rvalues for plain ref? Bonus: No risk of mixup with template auto ref after refactoring etc. Save auto for other potential future use. That would be horrible. How would you distinguish between lvalues and rvalues? What if you want to store a pointer to an lvalue? If ref accept both you cannot do that.
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? Semi-hijacking this thread: I recently made a few pull requests to get better support for UDAs into Phobos. https://github.com/D-Programming-Language/phobos/pull/3356 https://github.com/D-Programming-Language/phobos/pull/3421 https://github.com/D-Programming-Language/phobos/pull/3363 The last of the three is stuck because nobody's looking at it. Can those of you who use UDAs take a look at these and confirm that I haven't made any dumb mistakes before the 2.068 release goes out with them included?
Re: auto ref is on the docket
On Monday, 22 June 2015 at 20:42:58 UTC, Daniel N wrote: Considering we already have working 'Sealed references', why not simply allow rvalues for plain ref? Please, please, no. That would be horrible. ref indicates an intention to mutate the argument, which makes no sense with rvalues. And if ref is used simply so that you can accept both rvalues and lvalues without copying lvalues, then there's zero indication in the function signature when the point of the ref is to actually set what's being passed in. It works in C++ with const&, because you know that the function won't mutate the argument, but if you allow it with ref in general, then you stand no chance of being able to look at a function signature and deduce whether the function intends to mutate an argument or not. And even if Andrei wasn't so set against const ref that we could go that route in D as well, it wouldn't solve the problem either, because const in D is just too restrictive to use in many cases. We need a way to indicate that a parameter accepts both lvalues and rvalues without intending to mutate the argument but without actually guaranteeing it via const. And that does _not_ work with naked ref. - Jonathan M Davis
Re: auto ref is on the docket
On Monday, 22 June 2015 at 20:50:23 UTC, Namespace wrote: That would be horrible. How would you distinguish between lvalues and rvalues? What if you want to store a pointer to an lvalue? If ref accept both you cannot do that. storing requires 'return ref'
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? I use UDAs in my project to generate GTK UI for editing components in my ECS. (For things like marking string fields as filenames, or giving numeric fields upper and lower bounds) https://dl.dropboxusercontent.com/u/187059/Screenshot-sarah%20-%20Entity%20Editor.png
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote:
I never seem to use them for anything, has anyone else done
anything interesting with them?
I use them to annotate the setter/getter pairs in classes. Two
analyzers look for them to automatically create what i call a
"property descriptor".
https://github.com/BBasile/iz/blob/master/import/iz/properties.d#L362
Property descriptors are then used to
- bind/synchronize several properties together.
- serialize or deserialize classes.
This is directly inspired by Pascal's "published" property. All
the type information system is replaced with UDA and static
analysis:
Pascal:
---
published property myProp: integer read getMyProp write setMyProp;
---
D2 equivalent:
---
@SetGet private int _field; // solution 1: use directly the field
@Set void myProp(int value){} // solution 2: use explicit
accessors.
@Get int myProp(){return _field;}
---
The Annotations work very well with virtual methods. For example
the most derivated (overriden) anotated @Set/@Get is always took
by the analyzer, like expected.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 20:56:12 UTC, Jonathan M Davis wrote: won't mutate the argument, but if you allow it with ref in general, then you stand no chance of being able to look at a function signature and deduce whether the function intends to mutate an argument or not. - Jonathan M Davis It's no worse than auto ref. It's only by convention that auto ref functions doesn't mutate, at least I follow that convention, but when looking at someone else's function, all bets are off.
Re: Phobos addition formal review: std.experimental.allocator
On 6/21/15 4:47 AM, Dicebot wrote: 4. There are no higher level usage examples and/or guidelines about how this is supposed to fit in user applications. Intention behind the library may be familiar to users coming from C++ but target D audience is much more than that. Having std.allocator.showcase is nice but it is still a bit too theoretical. Done: https://github.com/D-Programming-Language/phobos/commit/fd7689ef1369e55252d2f6cfa5baddd5260aeb13 Will be coming forth with 5 and 6. Andrei
Re: Phobos addition formal review: std.experimental.allocator
On Monday, 22 June 2015 at 19:51:50 UTC, Andrei Alexandrescu wrote: 2. `IAllocator` is defined inside `package.d` file. That means that it is impossible to use interface without import ALL of allocator modules Fixed, now interested users need to import std.experimental.allocator.building_blocks. 3. Same concern is about https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/package.d#L218-L228 - unless you actually import all stuff via package.d, those configured allocators are not available. Fixed per above. Is it? I still see those symbols defined in package.d , 14ccc3a02f3dd332cb435abaf3c35cb8847797c0 does not seem to have affected that.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu
wrote:
Walter and I discussed what auto ref for templates should look
like and reached the conclusion that an approach based on
lowering would be best. I added a proposed lowering to
https://github.com/D-Programming-Language/dmd/pull/4717.
`For example, consider the declaration:`
ref int fun(auto ref int x);
`That should lower to:`
ref int fun(int' x); /* or */ ref int fun('int x);
Re: D could catch this wave: web assembly
On 06/22/2015 04:01 PM, Joseph Rushton Wakeling wrote: On Sunday, 21 June 2015 at 15:59:57 UTC, Nick Sabalausky wrote: On 06/21/2015 09:45 AM, Joseph Rushton Wakeling wrote: Threw what in the trash-bin? https://en.wikipedia.org/wiki/Ubuntu_for_Android Though I may very well be missing something. Yea, Ubuntu for Android was a cool idea that sadly, as I understand it, got no uptake from manufacturers. So Canonical just pushed ahead with their own full-Ubuntu phone and tablet OS and UI, and played everything much quieter until they'd actually landed hardware partners. It's obviously early days, but I think there's much to be quietly confident about: there's a lot to like in the OS and app design, and it is now by a long stretch the most free (as in freedom) phone OS available. Interesting. I'll have to look into that more. (Such as, will it run on Android phones or does it need separate hardware?)
Re: auto ref is on the docket
On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote: Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717. Andrei "@WalterBright auto ref for templates and non-templates do different things by necessity. ..." The proposed lowering also works for template functions. "... This is not an issue." Yes it is. Walter is right.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 18:34:37 UTC, Namespace wrote: On Monday, 22 June 2015 at 18:03:43 UTC, Temtaime wrote: I see no reasons why « ref in » is bad. Maybe someone explain ? It's also natural for those who came from C++. In C++ there's no problem with const&, so why they will be in D? Because const is transitive in D and therefore more restrictive. That's not a reason. It's just an additional restriction imposed by D and only prevents you from using the proposed `in ref T`/`const auto ref T` *shudder* equivalents if const-transitiveness would be violated. In my day-to-day C++ work, I almost never have to do that. C++ "simply" ;) relies on the callee not escaping rvalue references bound to `const T&`. D's `(const/immutable) ref` only allows lvalue arguments. It simply says: 'Hey stupid, don't give me an rvalue reference, it might escape!' So to circumvent this common problem, you'll currently have to either (a) create an `auto ref` template or (b) declare a new variable, potentially having to introduce a new scope. Is it ugly? (a) Leads to code bloat, but provides for in-place parameter construction (and no indirections) for rvalue arguments of suited types. (b) Definitely ugly. Is it safe now? (a) Ideally, the rvalue argument was in-place constructed in the function parameters stack. Noone but you, the dev, prevents the callee from escaping a reference to the parameter though. (b) Well, the code is more verbose and emphasizes the original function argument expression. But it's obviously still all your responsibility to take care of proper lifetime for escaping references. Just declaring the variable right before the function call isn't safer than passing the rvalue reference directly. So none of this really solves the underlying problem. One solution consists in classifying function parameter references as non-escaping ones (proposed `scope ref`/non-template `auto ref` accepting rvalues too, to be verified by compiler) and escaping ones (`ref`), the bad ones to watch out for. I'd like having to syntactically annotate an lvalue argument passed by non-scope ref, analog to C#, i.e., `foo(ref argument)`, to more easily catch the eye.
Re: Phobos addition formal review: std.experimental.allocator
On 6/22/15 2:40 PM, Dicebot wrote: On Monday, 22 June 2015 at 19:51:50 UTC, Andrei Alexandrescu wrote: 2. `IAllocator` is defined inside `package.d` file. That means that it is impossible to use interface without import ALL of allocator modules Fixed, now interested users need to import std.experimental.allocator.building_blocks. 3. Same concern is about https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/package.d#L218-L228 - unless you actually import all stuff via package.d, those configured allocators are not available. Fixed per above. Is it? I still see those symbols defined in package.d , 14ccc3a02f3dd332cb435abaf3c35cb8847797c0 does not seem to have affected that. Perhaps I misunderstood the request - currently the imports in allocator/package.d are: public import std.experimental.allocator.common, std.experimental.allocator.typed; import std.algorithm, std.conv, std.exception, std.range, std.traits, std.typecons, std.typetuple; version(unittest) import std.random, std.stdio; Is that okay, and if not what should change? Andrei
Re: auto ref is on the docket
On 6/22/15 3:06 PM, Timon Gehr wrote: On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote: Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717. Andrei "@WalterBright auto ref for templates and non-templates do different things by necessity. ..." The proposed lowering also works for template functions. "... This is not an issue." Yes it is. Walter is right. For templates, auto ref generates two copies of the function. Inside, which was generated can be interrogated by using is(param == ref). For non-templates, only one copy of the function is generated. Using is(param == ref) inside should be an error. The two mechanisms bear many similarities and some differences, too. Andrei
Re: Phobos addition formal review: std.experimental.allocator
On 6/21/15 4:47 AM, Dicebot wrote: 5. http://erdani.com/d/phobos-prerelease/std_experimental_allocator_stats_collector.html has no overview documentation at all https://github.com/D-Programming-Language/phobos/commit/ef6de891197db6d497df11c9350781eef38df196 Andrei
Re: auto ref is on the docket
On 06/23/2015 12:18 AM, kinke wrote: In C++ there's no problem with const&, so why they will be in D? Because const is transitive in D and therefore more restrictive. That's not a reason. Yes it is. It's just an additional restriction imposed by D and only prevents you from using the proposed `in ref T`/`const auto ref T` *shudder* equivalents if const-transitiveness would be violated. In my day-to-day C++ work, I almost never have to do that. Note "almost".
Re: auto ref is on the docket
On 06/23/2015 12:40 AM, Andrei Alexandrescu wrote: On 6/22/15 3:06 PM, Timon Gehr wrote: On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote: Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717. Andrei "@WalterBright auto ref for templates and non-templates do different things by necessity. ..." The proposed lowering also works for template functions. "... This is not an issue." Yes it is. Walter is right. For templates, auto ref generates two copies of the function. Inside, which was generated can be interrogated by using is(param == ref). For non-templates, only one copy of the function is generated. Using is(param == ref) inside should be an error. The two mechanisms bear many similarities and some differences, too. ... 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.
Re: auto ref is on the docket
On Monday, 22 June 2015 at 23:04:14 UTC, Timon Gehr wrote: On 06/23/2015 12:18 AM, kinke wrote: In C++ there's no problem with const&, so why they will be in D? Because const is transitive in D and therefore more restrictive. That's not a reason. Yes it is. It's just an additional restriction imposed by D and only prevents you from using the proposed `in ref T`/`const auto ref T` *shudder* equivalents if const-transitiveness would be violated. In my day-to-day C++ work, I almost never have to do that. Note "almost". Ah, I remember you from another rvalue discussion some years ago. ;) Care to share an example where transitive const is a problem apart from obvious lazily caching stuff? I don't think I've encountered any lately.
Re: What have you done with UDAs?
On 23 June 2015 at 05:09, weaselcat via Digitalmars-d wrote: > I never seem to use them for anything, has anyone else done anything > interesting with them? I've used them for attributing struct members with some information about their semantic meaning, which allows systems to automatically bind those structs to useful functions. For instance, I have attributed color structs with information about the D3D or OpenGL format spec's that represent, I have done the same with vertex data, expressing the semantic meaning of the elements in the vertex struct, so they can be bound automatically to the appropriate shader inputs. I've used it for control over serialisation of data in structs. I've used it to tag information to struct fields that are to be exported to editor environments, and control how those properties should be represented in editors (pretty-names, type of editor (select box, color picker, etc). I've used them for giving information to automated bindings for scripting systems. Particularly, I use them to tell automated systems to consider or ignore certain things.
Re: auto ref is on the docket
On 06/23/2015 01:27 AM, kinke wrote: On Monday, 22 June 2015 at 23:04:14 UTC, Timon Gehr wrote: On 06/23/2015 12:18 AM, kinke wrote: In C++ there's no problem with const&, so why they will be in D? Because const is transitive in D and therefore more restrictive. That's not a reason. Yes it is. It's just an additional restriction imposed by D and only prevents you from using the proposed `in ref T`/`const auto ref T` *shudder* equivalents if const-transitiveness would be violated. In my day-to-day C++ work, I almost never have to do that. Note "almost". ... Care to share an example where transitive const is a problem apart from obvious lazily caching stuff? One obvious problem ought to be enough. Some of the remaining cases are obvious as well. Others are not. One way to avoid non-obvious issues is to keep language features orthogonal. I don't think I've encountered any lately. The problems with transitive const to be encountered in day-to-day C++ work are few.
