Re: std.string.entabber, detabber, left/right/centerJustifier, soundexer
IMO, when naming things, generally we should lean towards representing semantics rather than mechanics (i.e. how is this function going to be used, rather than what this function does under the hood), as that will result in more readable code. +1
Re: version: multiple conditions
"Walter Bright" wrote in message news:mloslo$1o7v$1...@digitalmars.com...
I have yet to see a single case of "needing" boolean versions that could
not be refactored into something much more readable and maintainable that
did not use such.
Over time, I've gotten rid of most of that stuff from the dmd source code,
and the result has been quite pleasing.
Walter, how about a compromise?
If we allow setting versions to boolean expression then it becomes much
easier to use it the way you suggest, while still requiring a (hopefully)
sensible name and discouraging making a mess.
eg
version(A)
{
version(B)
{
}
else
{
version=NeedsSomeCode;
}
}
becomes
version NeedsSomeCode = A && !B
An example from real code would be
version valistIsCharPointer = (Linux && LP32) || Windows;
This pattern does appear frequently in your compiler code, are you for or
against seeing it in D?
Re: std.uni.toLowerCase / .toUpperCase
On 6/26/2015 5:04 AM, Tofu Ninja wrote: On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev wrote: So, one option is to stay consistent with these additions, and go with upperCaser and lowerCaser, even if those sound a bit odd. Why not upperCaseSetter/lowerCaseSetter? Bit longer but upper case and lower case don't have a good noun version. Personally upperCaser/lowerCaser sound really bad to me, though I like the idea of keeping it a noun because that matches every thing else. I think upperCaser and lowerCaser are just fine. And I'm saying that as someone who has been teaching English in Korea for a couple of decades :) No, these aren't words we would normally use. But a couple of points. 1. An -er suffix is immediately recognizable in most cases as "a thing that takes an action." Native English-speaking children and, in my experience, non-native speakers often tack it on to verbs to create a "doer" noun even when a different word already exists. A great example is "cooker" to refer to a "cook". It's well-understood from that perspective. 2. English is full of broken conventions, making it more onerous to learn vocabulary than it ought to be. I think we should pick an easily-understood convention that fits the usage of whatever category of functions we're dealing with and stick with it as zealously as possible, even if it means using words that aren't part of the language or that don't look so pretty when they are strung together. Doing so makes it much easier to reason at a glance about what's going on. upperCased/lowerCased work fine for strings that have already been transformed, but ranges that carry out the transformation are more accurately named upperCaser/lowerCaser. IMO, that's the simplest, most self-descriptive name these functions could have.
Re: I released my first library!
On Thursday, 25 June 2015 at 14:56:34 UTC, Vladde Nordholm wrote: For the past week I've been working on my first small cross-platform gamedev-ish console rendering library for d, and I call it clayers. It has been a fun learning process, as I've used many new programs and features. [...] Congrats! Maybe would be useful to grab some ideas from d-tui. https://github.com/klamonte/d-tui
Re: Presentation Intro to D: What works?
On 26/06/2015 1:46 p.m., rsw0x wrote: On Thursday, 25 June 2015 at 12:39:11 UTC, qznc wrote: Looks like I will give a talk about D to our local Functional Programming User Group in August. Feel free to join, if you can be in Karlsruhe, Germany: http://www.meetup.com/de/The-Karlsruhe-Functional-Programmers-Meetup-Group/events/22343/ As far as I know, pretty much nobody there knows anything about D. So I need to start with some general introduction. My current plan is to basically talk through the dlang.org frontpage. Modern convenience. Modeling power. Native efficiency. I guess others here have done such intros already. What works? What doesn't? What are the usually questions you get from newbies? Any evangelism tips? If it's a functional programming meetup, show off D's ranges combined with its functional programming style. I think this is what really sets it apart from every other C-based language, if D had pattern matching and destructuring it would probably have the ability to look pretty close to Ocaml. irk be careful when showing off ranges. Get some damn good background of what D is first. It took me well over a year before I started to get into them.
Re: I released my first library!
On 26/06/2015 12:45 p.m., Kelet wrote: On Thursday, 25 June 2015 at 14:56:34 UTC, Vladde Nordholm wrote: For the past week I've been working on my first small cross-platform gamedev-ish console rendering library for d, and I call it clayers. It has been a fun learning process, as I've used many new programs and features. The whole thing is written in vim, which I've never used until now. I got a better understanding of how git works by using the terminal, instead of a GUI. For the first time I used version() for different functions. Finally, I added a releasetag, and then registered it to dub. While I didn't think about it while writing the code, I've gotten a better knowledge of how all of these things work. And this extra stuff I learnt without even thinking about it. GC is something I've never though about before, but thanks to people from #d I now have a better understanding of how it works. Thanks! As for actually writing code: I've gotten to design the library myself, debugged it, and everything that comes with making an library. I've had discussions with people about the rendering and generally come to good terms with many in the #d channel. Thanks to the whole D community it became more fun than I'd ever imagine. Thanks for being here D-people! --- The dub package: http://code.dlang.org/packages/clayers Awesome, congrats on releasing your first library. If you intend to work on it further, I'd like to see: - A way to call a function when a specific key is pressed (key binding) Yes please! Can you say buttons + menus? - More portability, better support for other terminals; see termbox source code for a reasonable level of portability - Colors! But I guess we could probably combine your library with the "color" library for that, right? https://github.com/yamadapc/d-colorize I do enjoy the gif that shows the functionality. I bet using Unicode characters for borders and such would look nice. Another nice feature would be to lock and unlock able to have characters appear for input as part of the key binding. With that textboxs could be made.
Re: I'm outta here
On 26/06/2015 7:12 a.m., Andrei Alexandrescu wrote: Hi folks, We're in the final stages of moving house across the country so I'll be more or less out of commission for a few days. A few thoughts: Phew, you had me scared for a little bit!
Re: PHP verses C#.NET verses D.
On Thursday, 25 June 2015 at 13:48:38 UTC, Etienne wrote: On Wednesday, 24 June 2015 at 05:34:08 UTC, Nick B wrote: On Tuesday, 23 June 2015 at 11:22:40 UTC, Etienne Cimon wrote: Thanks for the responses and your details replies. I'm going to talk to the CEO of the company described, at the beginning of this long thread, and find out they are willing to consider a proof of concept web site based on your work. This could take a couple of weeks. What is the best way to get in touch with you if I have more questions ? Nick Skype: Etcimon or gmail the same username Thanks again. Nick
Re: Building DMD on SmartOS
It appears no syscall is generating EBADF.
Does writeln call into libc's printf() function? That can return EBADF
(bad file number) if the stream isn't enabled for writing.
I didn't look too closely (work issues) at the D code, but I did notice the
D libraries are trying to define the internal structure of FILE. It should
be treated as an opaque structure. I didn't look close enough to see if
any D library code is trying to manipulate any of its fields (IF it is,
that's very wrong).
On Thu, Jun 25, 2015 at 4:03 PM, flamencofantasy via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 25 June 2015 at 20:26:05 UTC, Jason King wrote:
>
>> The first thing I would suggest running the program via truss and see if
>> any calls to write() are returning EBADF.. If so, see what fd# is being
>> passed (or if something is calling close() on fd1).
>>
>> On Thu, Jun 25, 2015 at 2:57 PM, flamencofantasy via Digitalmars-d <
>> digitalmars-d@puremagic.com> wrote:
>>
>> On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:
>>>
>>> On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:
On Tuesday, 5 May 2015 at 05:42:33 UTC, Kai Nacke wrote:
>
> BTW: You can by-pass the Solaris ld by setting environment variable
>> LD_ALTEXEC to the ld binary you want to use.
>>
>>
> Thanks for the tip: I set that to the binutils ld and got almost all
> of druntime's tests to pass with a 64-bit binary.
> I only had to comment out the additional druntime tests having to do
> with exceptions. Maybe that's related to the link error flamencofantasy
> pasted.
>
> I also tried running the phobos unit tests, but I got a ton of link
> errors, seemingly for stuff that should be there. I'll let someone else
> track those down.
>
>
Before I chuck this large SmartOS VM on my external backup, I thought
I'd
take another shot at getting the phobos tests running. Turned out to be
pretty easy and I started hacking around the test failures until it got
too
tedious, when the std.path tests wouldn't run because "Memory allocation
failed."
Here's the last patch I used:
https://gist.github.com/joakim-noah/6094789851ba1db1170b
Some notes:
- I disabled the tests for std.datetime and std.parallelism in the test
runner because they were both failing somewhere.
- All it took to get the phobos test runner linked was to add all the
additional necessary libraries that curl needed on Solaris to posix.mak.
- getcwd will not accept a zero size on Solaris.
- Solaris seems to have similar issues to Android with formatting NaN
and
hex in std.format.
>>> Hello,
>>>
>>> This is my test program;
>>>
>>> import std.stdio;
>>>
>>> void main()
>>> {
>>> try
>>> {
>>> writeln("Hello");
>>> }
>>> catch (Exception e)
>>> {
>>> import core.stdc.stdio;
>>> printf(e.msg.ptr);
>>> }
>>> }
>>>
>>>
>>> The output is;
>>> Bad file number
>>>
>>> It has to do with stdout not being valid but I am unable to figure out
>>> why
>>> by reading the source code.
>>> I am new to unix in general and SmartOS/Solaris in particular.
>>>
>>> Long story short my fairly large project which builds and runs flawlessly
>>> on Windows and Linux, compiles successfully on SmartOS with no warnings
>>> but
>>> any invocation of writeln (and relatives) throws the exception above.
>>> If anyone is willing to help I have a smart zone with ssh access I can
>>> provide you with so you can play.
>>>
>>> Thanks!
>>>
>>
> Thanks, I've been trying truss and gdb but I wasn't able to spot anything
> useful.
>
> The exception is checked and thrown in user space so I don't think truss
> sees anything.
>
> But here is the full truss dump of the program above;
>
> [root@smartDmachine ~]# truss ./main
> execve("main", 0xFD7FFFDFFC88, 0xFD7FFFDFFC98) argc = 1
> sysinfo(SI_MACHINE, "i86pc", 257) = 6
> mmap(0x, 56, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON,
> 4294967295, 0) = 0xFD7FFF39
> mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF38
> mmap(0x, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON,
> 4294967295, 0) = 0xFD7FFF37
> mmap(0x, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON,
> 4294967295, 0) = 0xFD7FFF36
> memcntl(0xFD7FFF398000, 96976, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
> mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF35
> memcntl(0x0040, 6040, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
> resolvepath("/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18
> getcwd("/root", 1018) = 0
> resolvepath("/root/main", "/root/main", 1023) = 10
> stat("/root/main", 0xFD7FFFDFF960)
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 20:54:38 UTC, Walter Bright wrote: Please, no code breakage because of renaming. Well, the whole idea behind Adam's proposal to make functions like toLower return a struct which is a lazy range but uses alias this to do eager allocation is to allow us to switch to lazy by default with these functions without breaking code, because when you assigned it to a string, it would allocate just like it did before. So, in theory, there wouldn't be any code breakage. However, as appealing as I find the idea of silently converting eager functions into lazy functions without breaking code, I'm not at all convinced that it will really work and that it won't break code. As long as the type string is used explicitly in the caller, it should be fine, but with enough uses of auto and interacting with other templated functions that do who-knows-what, I'm no sure that it's actually going to do the implicit conversion to string in all of the cases that it really needs to (e.g. the resulting range type would fail isSomeString, and if the function that you passed it to required isSomeString via its template constraint but didn't have an overload for generic ranges of dchar, it would fail to compile). In general, implicit conversions are incredibly dangerous with generic code - particularly with regards to template constraints, because it's trivial to have a type which implicitly converts, but if the templated function doesn't actually force the conversion, then the function might not actually compile with the original type, and even if it does, you could get some weird, hybrid behavior where some of the operations in the function end up being done on the original type and some end up being done on the result of alias this. So, we need to be _very_ careful when using alias this in generic code. So, while I do like Adam's idea in principle - and it shows off D's power nicely - I think that the fact that we're talking about combining alias this and generic code is a very risky proposition. It probably will work in _almost_ all cases without breaking any code, but I seriously question that it will work in _all_ cases. - Jonathan M Davis
Re: D could catch this wave: web assembly
On Friday, 26 June 2015 at 01:16:37 UTC, Joakim wrote: On Thursday, 25 June 2015 at 18:38:59 UTC, deadalnix wrote: On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote: This appears to have involvement from all major browser vendors, which provides hope it might actually catch on properly. An llvm backend will be created which will compile to "wasm", hopefully LDC and/or SDC could glue to this. https://www.w3.org/community/webassembly/ https://github.com/WebAssembly In particular, see https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md So it has been 13 pages of heated debate, but no PR is to be seen for LDC or SDC... Well, first we have to decide if a PR would even be worthwhile... ;) By this time we'd have a PR and we could play with it to decide using first hand experience.
Re: Naming Voldemort Types
On Thursday, 25 June 2015 at 20:58:41 UTC, Walter Bright wrote: On 6/25/2015 11:54 AM, Andrei Alexandrescu wrote: Result. No stuttering please. -- Andrei Also, consider that the mangled name includes the parent algorithm name. Let's not make mangled names excessively large, even if it is an implementation problem that we should address on its own anyway. It makes sense when we've been forced to make it so that the type isn't actually Voldemort type (e.g. FilterResult is a private struct outside of filter), but when it's actually a Voldemort type, Result should work just fine. - Jonathan M Davis
Re: std.string.entabber, detabber, left/right/centerJustifier, soundexer
On Thursday, 25 June 2015 at 21:01:39 UTC, Vladimir Panteleev
wrote:
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff
So, there is some discussion about these here already:
http://forum.dlang.org/post/ubfmdrorjtasgeung...@forum.dlang.org
There seems to be varying opinion, so I'm going to formally
nominate them for renaming and get more opinions.
Rationale:
The merits of the verb-noun form ("xxxer") is that there exists
precedent (`joiner` and `splitter`), and that they do a good
job at describing what actually happens under the hood.
The downside is that they simply don't sound as good as some of
the other options when using it in the code. To reiterate on a
point from an earlier post, I think that this:
writeln(str.lowerCased.detabbed.transmogrified);
sounds better than this:
writeln(str.lowerCaser.detabber.transmogrifier);
IMO, when naming things, generally we should lean towards
representing semantics rather than mechanics (i.e. how is this
function going to be used, rather than what this function does
under the hood), as that will result in more readable code.
Anyway, this is extreme bikeshedding and I won't mind too much
leaving these alone.
Proposed new names: entabbed, detabbed,
left/right/centerJustified, soundexed. (Existing similar names:
`indexed`, `transposed`)
Well, I think that it's clear based on my previous posts that I'd
prefer that we keep the "xxxEr" scheme, particularly when you
consider that these functions are basically just wrappers around
constructors for the types that do these operations.
- Jonathan M Davis
Re: Presentation Intro to D: What works?
On Thursday, 25 June 2015 at 12:39:11 UTC, qznc wrote: Looks like I will give a talk about D to our local Functional Programming User Group in August. Feel free to join, if you can be in Karlsruhe, Germany: http://www.meetup.com/de/The-Karlsruhe-Functional-Programmers-Meetup-Group/events/22343/ As far as I know, pretty much nobody there knows anything about D. So I need to start with some general introduction. My current plan is to basically talk through the dlang.org frontpage. Modern convenience. Modeling power. Native efficiency. I guess others here have done such intros already. What works? What doesn't? What are the usually questions you get from newbies? Any evangelism tips? If it's a functional programming meetup, show off D's ranges combined with its functional programming style. I think this is what really sets it apart from every other C-based language, if D had pattern matching and destructuring it would probably have the ability to look pretty close to Ocaml.
Re: Presentation Intro to D: What works?
On Thursday, 25 June 2015 at 12:39:11 UTC, qznc wrote: Looks like I will give a talk about D to our local Functional Programming User Group in August. Feel free to join, if you can be in Karlsruhe, Germany: http://www.meetup.com/de/The-Karlsruhe-Functional-Programmers-Meetup-Group/events/22343/ As far as I know, pretty much nobody there knows anything about D. So I need to start with some general introduction. My current plan is to basically talk through the dlang.org frontpage. Modern convenience. Modeling power. Native efficiency. What specifically do you plan to mention for each? I guess others here have done such intros already. What works? What doesn't? What are the usually questions you get from newbies? Any evangelism tips? Never done an intro but watched several and have been thinking about doing an intro talk locally myself. One thing I don't often see in intros that I was thinking about adding is who is behind the language? Do a small bio of Walter with his C++ compiler background and Andrei with his modern C++ design background. That will help orient the newbie on where the language comes from.
Re: D could catch this wave: web assembly
On Thursday, 25 June 2015 at 18:38:59 UTC, deadalnix wrote: On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote: This appears to have involvement from all major browser vendors, which provides hope it might actually catch on properly. An llvm backend will be created which will compile to "wasm", hopefully LDC and/or SDC could glue to this. https://www.w3.org/community/webassembly/ https://github.com/WebAssembly In particular, see https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md So it has been 13 pages of heated debate, but no PR is to be seen for LDC or SDC... Well, first we have to decide if a PR would even be worthwhile... ;)
Re: I released my first library!
On Thursday, 25 June 2015 at 14:56:34 UTC, Vladde Nordholm wrote: For the past week I've been working on my first small cross-platform gamedev-ish console rendering library for d, and I call it clayers. It has been a fun learning process, as I've used many new programs and features. The whole thing is written in vim, which I've never used until now. I got a better understanding of how git works by using the terminal, instead of a GUI. For the first time I used version() for different functions. Finally, I added a releasetag, and then registered it to dub. While I didn't think about it while writing the code, I've gotten a better knowledge of how all of these things work. And this extra stuff I learnt without even thinking about it. GC is something I've never though about before, but thanks to people from #d I now have a better understanding of how it works. Thanks! As for actually writing code: I've gotten to design the library myself, debugged it, and everything that comes with making an library. I've had discussions with people about the rendering and generally come to good terms with many in the #d channel. Thanks to the whole D community it became more fun than I'd ever imagine. Thanks for being here D-people! --- The dub package: http://code.dlang.org/packages/clayers Awesome, congrats on releasing your first library. If you intend to work on it further, I'd like to see: - A way to call a function when a specific key is pressed (key binding) - More portability, better support for other terminals; see termbox source code for a reasonable level of portability - Colors! But I guess we could probably combine your library with the "color" library for that, right? I do enjoy the gif that shows the functionality. I bet using Unicode characters for borders and such would look nice.
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 23:20:13 UTC, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 23:18:13 UTC, Mike wrote: The .Net Framework has had deprecated names since 2.0 (10 years ago) and you can still use them today and likely will be able to in the far future. And the fact that deprecation warnings are off by default in D already makes it ultra-conservative. Deprecation warnings are on by default - though I think we should disable them by default, and start using `deprecated` as you suggested. I think I suggested this before as well. Deprecating the eager versions would go a long way to making it obvious which version should be used, probably such that ambiguous names wouldn't really matter anymore. Though I don't know if that would be something people would be ok with.
Re: I'm outta here
On Thu, 25 Jun 2015 15:12:27 -0400, Andrei Alexandrescu wrote: * I've been hard at work on std.collection and I think something good will come out of it. Will keep on hacking at it. Is this code online anywhere? Bit
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 23:20:13 UTC, Vladimir Panteleev wrote: Deprecation warnings are on by default Delighted to be wrong. though I think we should disable them by default Please don't
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 23:18:13 UTC, Mike wrote: The .Net Framework has had deprecated names since 2.0 (10 years ago) and you can still use them today and likely will be able to in the far future. And the fact that deprecation warnings are off by default in D already makes it ultra-conservative. Deprecation warnings are on by default - though I think we should disable them by default, and start using `deprecated` as you suggested. I think I suggested this before as well.
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 21:06:38 UTC, Walter Bright wrote: On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote: And he's right. It is really annoying to update to a new version and have perfectly valid and working code breaking because someone had a nice idea. Ideally, we should only ever break code that has a bug in it. I've also been willing to break code if it involves significant performance, usability, or correctness improvements. Renaming, though, doesn't provide that. Deprecation is *not* breakage. Removal is. This isn't like final-by-default where there can be only one default. We can have redundant names as long as the user can know why they exist (documentation comment) and which is preferred (deprecated attribute). I suggest deprecation without removal (i.e. removal by Walter only). The .Net Framework has had deprecated names since 2.0 (10 years ago) and you can still use them today and likely will be able to in the far future. And the fact that deprecation warnings are off by default in D already makes it ultra-conservative. Mike
Re: New names - 2.068 roundup
On 6/25/15 2:03 PM, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 20:55:36 UTC, Walter Bright wrote: Also, making PRs for this is fine, but please hold off on pulling until Andrei is back and can check. Do you know if Andrei will be back before RC1 (or the release, at least)? Missing the release defeats the entire point of this thread, and holding up the release because we need Andrei's permission to rename a few functions and he is moving seems rather silly as well. I should have enough time to review and approve a coherent proposal. Thanks for your consideration. -- Andrei
Re: I'm outta here
On Thursday, 25 June 2015 at 19:12:14 UTC, Andrei Alexandrescu wrote: Hi folks, We're in the final stages of moving house across the country so I'll be more or less out of commission for a few days. A few thoughts: * Review of std.allocator has been slow. I did my best to be responsive to feedback. There are a couple of remaining open issues regarding naming of things (what else?) which I think oughtn't block inclusion in std.experimental - then we'll get to experiment and see how it all feels. * I've been hard at work on std.collection and I think something good will come out of it. Will keep on hacking at it. * Please don't overdo The Grand Renaming. Find some good names for new things and call it a day. Please no breakages and no clever schemes and no overengineering. This is a good opportunity to create a good precedent of having the community have a word on introduced names and doing so in an orderly manner. Please let's not squander it. Find some good names and let's move on. * Thanks Martin for pushing the beta through, and let's make this a solid release! Cheers, Andrei I don't envy you. Moving house has to be the most stressful job there is. Though, I don't have kids so maybe I'm wrong on that :)
Re: Naming Voldemort Types
On Thursday, 25 June 2015 at 13:12:18 UTC, Nordlöw wrote: I've noticed that the namings of lazy range voldemort types are inconsistent in Phobos. Some are named `XResult` others just `Result`, given that `x` is the parenting algorithm. What's the policy here? I would prefer the verbose `XResult` as it's more self documenting when debugging or using for instance pragma(msg, typeof(r)) where `r` is an instance of a lazy range. What do you guys think? I always name my Voldemort Types tomRiddle...
Re: std.experimental.color, request reviews
On Thursday, 25 June 2015 at 21:06:59 UTC, Guillaume Chatelet wrote: On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote: How about HSx ? That's the best I've got! :P Not too bad :-) I'm not too excited about this but how about : HS!L HS!V .,. It could work with a good documentation. Or just an obscure struct and some aliases : alias HueSpace!(Type.xSL) HSL
Re: New names - 2.068 roundup
On 06/25/2015 11:06 PM, Walter Bright wrote: On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote: And he's right. It is really annoying to update to a new version and have perfectly valid and working code breaking because someone had a nice idea. Ideally, we should only ever break code that has a bug in it. I've also been willing to break code if it involves significant performance, usability, or correctness improvements. Renaming, though, doesn't provide that. It might support performance and usability, at least. Usability is obvious. For performance, just assume the eager version has a nicer, shorter or more memorable name than the lazy version. (which is the case now for e.g. join/joiner, split/splitter). The main issue is that all those name-describing adjectives have no precise, agreed upon meaning.
Re: New names - 2.068 roundup
On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote: And he's right. It is really annoying to update to a new version and have perfectly valid and working code breaking because someone had a nice idea. Ideally, we should only ever break code that has a bug in it. I've also been willing to break code if it involves significant performance, usability, or correctness improvements. Renaming, though, doesn't provide that.
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 21:06:38 UTC, Walter Bright wrote: On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote: And he's right. It is really annoying to update to a new version and have perfectly valid and working code breaking because someone had a nice idea. Ideally, we should only ever break code that has a bug in it. I've also been willing to break code if it involves significant performance, usability, or correctness improvements. Renaming, though, doesn't provide that. For the record, the goal of the breakage in this case is not renaming a function, but avoiding the need to introduce a newly-named alternative function in the first place.
Re: std.experimental.color, request reviews
On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote: How about HSx ? That's the best I've got! :P Not too bad :-) I'm not too excited about this but how about : HS!L HS!V .,. It could work with a good documentation.
Re: std.uni.toLowerCase / .toUpperCase
On 06/25/2015 10:42 PM, Vladimir Panteleev wrote:
On Thursday, 25 June 2015 at 20:41:13 UTC, Timon Gehr wrote:
On 06/25/2015 04:10 PM, Vladimir Panteleev wrote:
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
Definitely. The existing functions should have been named 'joined' and
'splitted'. :o)
I actually hypothesize that "joiner"/"splitter" were chosen because
"split" the verb's past tense is also "split", which was taken by the
eager function.
It was intended as a joke, but apparently the word exists/existed
https://en.wiktionary.org/wiki/splitted .
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 20:55:36 UTC, Walter Bright wrote: Also, making PRs for this is fine, but please hold off on pulling until Andrei is back and can check. Do you know if Andrei will be back before RC1 (or the release, at least)? Missing the release defeats the entire point of this thread, and holding up the release because we need Andrei's permission to rename a few functions and he is moving seems rather silly as well.
Re: Building DMD on SmartOS
On Thursday, 25 June 2015 at 20:26:05 UTC, Jason King wrote:
The first thing I would suggest running the program via truss
and see if
any calls to write() are returning EBADF.. If so, see what fd#
is being
passed (or if something is calling close() on fd1).
On Thu, Jun 25, 2015 at 2:57 PM, flamencofantasy via
Digitalmars-d < digitalmars-d@puremagic.com> wrote:
On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:
On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:
On Tuesday, 5 May 2015 at 05:42:33 UTC, Kai Nacke wrote:
BTW: You can by-pass the Solaris ld by setting environment
variable LD_ALTEXEC to the ld binary you want to use.
Thanks for the tip: I set that to the binutils ld and got
almost all of druntime's tests to pass with a 64-bit binary.
I only had to comment out the additional druntime tests
having to do with exceptions. Maybe that's related to the
link error flamencofantasy pasted.
I also tried running the phobos unit tests, but I got a ton
of link errors, seemingly for stuff that should be there.
I'll let someone else track those down.
Before I chuck this large SmartOS VM on my external backup, I
thought I'd
take another shot at getting the phobos tests running.
Turned out to be
pretty easy and I started hacking around the test failures
until it got too
tedious, when the std.path tests wouldn't run because "Memory
allocation
failed."
Here's the last patch I used:
https://gist.github.com/joakim-noah/6094789851ba1db1170b
Some notes:
- I disabled the tests for std.datetime and std.parallelism
in the test
runner because they were both failing somewhere.
- All it took to get the phobos test runner linked was to add
all the
additional necessary libraries that curl needed on Solaris to
posix.mak.
- getcwd will not accept a zero size on Solaris.
- Solaris seems to have similar issues to Android with
formatting NaN and
hex in std.format.
Hello,
This is my test program;
import std.stdio;
void main()
{
try
{
writeln("Hello");
}
catch (Exception e)
{
import core.stdc.stdio;
printf(e.msg.ptr);
}
}
The output is;
Bad file number
It has to do with stdout not being valid but I am unable to
figure out why
by reading the source code.
I am new to unix in general and SmartOS/Solaris in particular.
Long story short my fairly large project which builds and runs
flawlessly
on Windows and Linux, compiles successfully on SmartOS with no
warnings but
any invocation of writeln (and relatives) throws the exception
above.
If anyone is willing to help I have a smart zone with ssh
access I can
provide you with so you can play.
Thanks!
Thanks, I've been trying truss and gdb but I wasn't able to spot
anything useful.
The exception is checked and thrown in user space so I don't
think truss sees anything.
But here is the full truss dump of the program above;
[root@smartDmachine ~]# truss ./main
execve("main", 0xFD7FFFDFFC88, 0xFD7FFFDFFC98) argc = 1
sysinfo(SI_MACHINE, "i86pc", 257) = 6
mmap(0x, 56, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF39
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF38
mmap(0x, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF37
mmap(0x, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF36
memcntl(0xFD7FFF398000, 96976, MC_ADVISE, MADV_WILLNEED, 0,
0) = 0
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF35
memcntl(0x0040, 6040, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
resolvepath("/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18
getcwd("/root", 1018) = 0
resolvepath("/root/main", "/root/main", 1023) = 10
stat("/root/main", 0xFD7FFFDFF960) = 0
open("/var/ld/64/ld.config", O_RDONLY) = 3
fstat(3, 0xFD7FFFDFF6C0)= 0
mmap(0x, 160, PROT_READ, MAP_SHARED, 3, 0) =
0xFD7FFF34
close(3)= 0
stat("/opt/local/lib//libpthread.so.1", 0xFD7FFFDFF050) Err#2
ENOENT
stat("/opt/local/gcc47/x86_64-sun-solaris2.11/lib/amd64/libpthread.so.1",
0xFD7FFFDFF050) Err#2 ENOENT
stat("/opt/local/gcc47/lib/amd64/libpthread.so.1",
0xFD7FFFDFF050) Err#2 ENOENT
stat("/lib/64/libpthread.so.1", 0xFD7FFFDFF050) = 0
resolvepath("/lib/64/libpthread.so.1",
"/lib/amd64/libpthread.so.1", 1023) = 26
open("/lib/64/libpthread.so.1", O_RDONLY) = 3
mmapobj(3, MMOBJ_INTERPRET, 0xFD7FFF350C80,
0xFD7FFFDFEBAC, 0x) = 0
close(3)= 0
mmap(0x, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFD7FFF33
stat("/opt/local/lib//libm.so.2",
std.string.entabber, detabber, left/right/centerJustifier, soundexer
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev
wrote:
http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff
So, there is some discussion about these here already:
http://forum.dlang.org/post/ubfmdrorjtasgeung...@forum.dlang.org
There seems to be varying opinion, so I'm going to formally
nominate them for renaming and get more opinions.
Rationale:
The merits of the verb-noun form ("xxxer") is that there exists
precedent (`joiner` and `splitter`), and that they do a good job
at describing what actually happens under the hood.
The downside is that they simply don't sound as good as some of
the other options when using it in the code. To reiterate on a
point from an earlier post, I think that this:
writeln(str.lowerCased.detabbed.transmogrified);
sounds better than this:
writeln(str.lowerCaser.detabber.transmogrifier);
IMO, when naming things, generally we should lean towards
representing semantics rather than mechanics (i.e. how is this
function going to be used, rather than what this function does
under the hood), as that will result in more readable code.
Anyway, this is extreme bikeshedding and I won't mind too much
leaving these alone.
Proposed new names: entabbed, detabbed,
left/right/centerJustified, soundexed. (Existing similar names:
`indexed`, `transposed`)
Re: Naming Voldemort Types
On 6/25/2015 11:54 AM, Andrei Alexandrescu wrote: On 6/25/15 6:12 AM, "Nordlöw" wrote: I've noticed that the namings of lazy range voldemort types are inconsistent in Phobos. Some are named `XResult` others just `Result`, given that `x` is the parenting algorithm. What's the policy here? I would prefer the verbose `XResult` as it's more self documenting when debugging or using for instance pragma(msg, typeof(r)) where `r` is an instance of a lazy range. What do you guys think? Result. No stuttering please. -- Andrei Also, consider that the mangled name includes the parent algorithm name. Let's not make mangled names excessively large, even if it is an implementation problem that we should address on its own anyway.
Re: New names - 2.068 roundup
Also, making PRs for this is fine, but please hold off on pulling until Andrei is back and can check.
Re: std.path.toAbsolutePath / toNormalizedPath / toRelativePath
On 06/25/2015 04:24 PM, Jonathan M Davis wrote: On Thursday, 25 June 2015 at 13:35:30 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: - The eager versions are called absolutePath, normalizedPath, relativePath. If anything, the current naming scheme is opposite to some options we've been discussing (e.g. eager=toLowerCase, lazy=lowerCase[d|r]). Suggested new names: asAbsolutePath, asNormalizedPath, asRelativePath. Couldn't think of anything better, but I think this is an improvement. If we are to adopt the "as" prefix, we could also go with asLowerCase/asUpperCase for the std.uni ones. That seems like a reasonable idea for the cases where we really don't have a noun to act as the one doing the action. The situation is weird enough with uppercase and lowercase, since you end up with stuff like upperCaser and lowerCaser when caser isn't really a thing, but at least there, we at least have a fake noun that makes sense. For the path ones, I don't see any kind of noun that makes sense. So, asAbsolutePath, etc. definitely makes some sense, so maybe asLowerCase and asUpperCase would make more sense too. In general though, I'd prefer that we go with the noun naming scheme - particularly when they're basically constructors for ranges. But it obviously doesn't work in all cases. - Jonathan M Davis pathAbsolutizer, pathNormalizer, pathRelativizer. :-)
Re: New names - 2.068 roundup
Please, no code breakage because of renaming.
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 20:41:13 UTC, Timon Gehr wrote:
On 06/25/2015 04:10 PM, Vladimir Panteleev wrote:
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
Definitely. The existing functions should have been named
'joined' and 'splitted'. :o)
I actually hypothesize that "joiner"/"splitter" were chosen
because "split" the verb's past tense is also "split", which was
taken by the eager function.
Re: std.uni.toLowerCase / .toUpperCase
On 06/25/2015 04:10 PM, Vladimir Panteleev wrote:
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
Definitely. The existing functions should have been named 'joined' and
'splitted'. :o)
Re: auto ref is on the docket
On 06/25/2015 10:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: trying to expand it with "scope ref" as if that were simply an extension of scope makes no sense. Before we can even consider what something like scope ref might mean, we'd have to properly define what scope means. And all we have for it is the basic idea of what it's supposed to do - none of the details - and trying to define scope ref before defining what scope means in general could totally hamstring us when properly defining scope later. I can assure you that it will not limit us. The very concept of borrowing/scope already requires some very specific restrictions with regards to what a function is allowed to do with a scope parameter. These same restrictions guarantee that it's allowed to pass an rvalue to it. Every working scope proposal will always guarantee that, or it wouldn't be usable. If you still fear that it will impede us later, then at least this current proposal needs to be deferred until we have a scope proposal and have decided on it. I think the arguments against allowing rvalues with scope ref are the same as those against allowing rvalues with ref, modulo accidental escaping. (It has been argued that 'ref' signifies an intent to modify, which I wouldn't necessarily agree with.)
Re: Building DMD on SmartOS
The first thing I would suggest running the program via truss and see if
any calls to write() are returning EBADF.. If so, see what fd# is being
passed (or if something is calling close() on fd1).
On Thu, Jun 25, 2015 at 2:57 PM, flamencofantasy via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:
>
>> On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:
>>
>>> On Tuesday, 5 May 2015 at 05:42:33 UTC, Kai Nacke wrote:
>>>
BTW: You can by-pass the Solaris ld by setting environment variable
LD_ALTEXEC to the ld binary you want to use.
>>>
>>> Thanks for the tip: I set that to the binutils ld and got almost all of
>>> druntime's tests to pass with a 64-bit binary. I only had to comment out
>>> the additional druntime tests having to do with exceptions. Maybe that's
>>> related to the link error flamencofantasy pasted.
>>>
>>> I also tried running the phobos unit tests, but I got a ton of link
>>> errors, seemingly for stuff that should be there. I'll let someone else
>>> track those down.
>>>
>>
>> Before I chuck this large SmartOS VM on my external backup, I thought I'd
>> take another shot at getting the phobos tests running. Turned out to be
>> pretty easy and I started hacking around the test failures until it got too
>> tedious, when the std.path tests wouldn't run because "Memory allocation
>> failed."
>> Here's the last patch I used:
>>
>> https://gist.github.com/joakim-noah/6094789851ba1db1170b
>>
>> Some notes:
>>
>> - I disabled the tests for std.datetime and std.parallelism in the test
>> runner because they were both failing somewhere.
>> - All it took to get the phobos test runner linked was to add all the
>> additional necessary libraries that curl needed on Solaris to posix.mak.
>> - getcwd will not accept a zero size on Solaris.
>> - Solaris seems to have similar issues to Android with formatting NaN and
>> hex in std.format.
>>
>
> Hello,
>
> This is my test program;
>
> import std.stdio;
>
> void main()
> {
> try
> {
> writeln("Hello");
> }
> catch (Exception e)
> {
> import core.stdc.stdio;
> printf(e.msg.ptr);
> }
> }
>
>
> The output is;
> Bad file number
>
> It has to do with stdout not being valid but I am unable to figure out why
> by reading the source code.
> I am new to unix in general and SmartOS/Solaris in particular.
>
> Long story short my fairly large project which builds and runs flawlessly
> on Windows and Linux, compiles successfully on SmartOS with no warnings but
> any invocation of writeln (and relatives) throws the exception above.
> If anyone is willing to help I have a smart zone with ssh access I can
> provide you with so you can play.
>
> Thanks!
>
>
>
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 6/25/15 4:10 PM, Dmitry Olshansky wrote:
On 25-Jun-2015 23:06, Steven Schveighoffer wrote:
On 6/25/15 3:58 PM, Jacob Carlborg wrote:
On 25/06/15 18:46, Nick Sabalausky wrote:
Heh, that's awesome actually :) Got a source for that?
Windows 8 was a big failure. Windows 10 is looking much better, I think
it will get a much higher adaption rate.
With their track record of "every other release" cycle where one is
great (XP, 7, (perhaps) 10) and one is horrid (Vista, 8[.1]), I wonder
if they skipped 9 on purpose :)
AFAIK they found that way too many apps do checks like:
if(windowsVersion.startsWith("Windows 9"){
// use crappy legacy-compatible code
}
else{
// 2k/XP+ etc.
}
That. is. hilarious.
Instead they could have made it Windows Nine :)
-Steve
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 25-Jun-2015 23:06, Steven Schveighoffer wrote:
On 6/25/15 3:58 PM, Jacob Carlborg wrote:
On 25/06/15 18:46, Nick Sabalausky wrote:
Heh, that's awesome actually :) Got a source for that?
Windows 8 was a big failure. Windows 10 is looking much better, I think
it will get a much higher adaption rate.
With their track record of "every other release" cycle where one is
great (XP, 7, (perhaps) 10) and one is horrid (Vista, 8[.1]), I wonder
if they skipped 9 on purpose :)
AFAIK they found that way too many apps do checks like:
if(windowsVersion.startsWith("Windows 9"){
// use crappy legacy-compatible code
}
else{
// 2k/XP+ etc.
}
--
Dmitry Olshansky
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 6/25/15 3:58 PM, Jacob Carlborg wrote: On 25/06/15 18:46, Nick Sabalausky wrote: Heh, that's awesome actually :) Got a source for that? Windows 8 was a big failure. Windows 10 is looking much better, I think it will get a much higher adaption rate. With their track record of "every other release" cycle where one is great (XP, 7, (perhaps) 10) and one is horrid (Vista, 8[.1]), I wonder if they skipped 9 on purpose :) I'm definitely looking forward to upgrading to 10 to try it out for free, that alone is going to foster huge adoption. -Steve
Re: New names - 2.068 roundup
On 6/25/15 3:57 PM, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 19:55:41 UTC, Steven Schveighoffer wrote: Yeah, I agree for existing names, but these are unreleased new names. I thought the idea was to use this trick to avoid introducing the new names, and instead change the established names in a mostly-backwards-compatible way. Yeah, that is the idea. There should be no code breakage, or it won't fly. I took the "no clever schemes and no overengineering" as a rejection of this idea, only renaming is on the table. -Steve
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev wrote: So, one option is to stay consistent with these additions, and go with upperCaser and lowerCaser, even if those sound a bit odd. Why not upperCaseSetter/lowerCaseSetter? Bit longer but upper case and lower case don't have a good noun version. Personally upperCaser/lowerCaser sound really bad to me, though I like the idea of keeping it a noun because that matches every thing else.
Re: New names - 2.068 roundup
On 6/25/15 3:57 PM, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 19:55:41 UTC, Steven Schveighoffer wrote: Yeah, I agree for existing names, but these are unreleased new names. I thought the idea was to use this trick to avoid introducing the new names, and instead change the established names in a mostly-backwards-compatible way. To be clearer, my change would remove the newly-added toExt. I don't consider this a breakage since it wasn't released. Instead, we would rewrite toExtension to do what toExt does, but in a backwards compatible way. -Steve
Re: Building DMD on SmartOS
On Sunday, 17 May 2015 at 19:36:54 UTC, Joakim wrote:
On Tuesday, 5 May 2015 at 15:41:47 UTC, Joakim wrote:
On Tuesday, 5 May 2015 at 05:42:33 UTC, Kai Nacke wrote:
BTW: You can by-pass the Solaris ld by setting environment
variable LD_ALTEXEC to the ld binary you want to use.
Thanks for the tip: I set that to the binutils ld and got
almost all of druntime's tests to pass with a 64-bit binary.
I only had to comment out the additional druntime tests having
to do with exceptions. Maybe that's related to the link error
flamencofantasy pasted.
I also tried running the phobos unit tests, but I got a ton of
link errors, seemingly for stuff that should be there. I'll
let someone else track those down.
Before I chuck this large SmartOS VM on my external backup, I
thought I'd take another shot at getting the phobos tests
running. Turned out to be pretty easy and I started hacking
around the test failures until it got too tedious, when the
std.path tests wouldn't run because "Memory allocation failed."
Here's the last patch I used:
https://gist.github.com/joakim-noah/6094789851ba1db1170b
Some notes:
- I disabled the tests for std.datetime and std.parallelism in
the test runner because they were both failing somewhere.
- All it took to get the phobos test runner linked was to add
all the additional necessary libraries that curl needed on
Solaris to posix.mak.
- getcwd will not accept a zero size on Solaris.
- Solaris seems to have similar issues to Android with
formatting NaN and hex in std.format.
Hello,
This is my test program;
import std.stdio;
void main()
{
try
{
writeln("Hello");
}
catch (Exception e)
{
import core.stdc.stdio;
printf(e.msg.ptr);
}
}
The output is;
Bad file number
It has to do with stdout not being valid but I am unable to
figure out why by reading the source code.
I am new to unix in general and SmartOS/Solaris in particular.
Long story short my fairly large project which builds and runs
flawlessly on Windows and Linux, compiles successfully on SmartOS
with no warnings but any invocation of writeln (and relatives)
throws the exception above.
If anyone is willing to help I have a smart zone with ssh access
I can provide you with so you can play.
Thanks!
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 19:55:41 UTC, Steven Schveighoffer wrote: Yeah, I agree for existing names, but these are unreleased new names. I thought the idea was to use this trick to avoid introducing the new names, and instead change the established names in a mostly-backwards-compatible way.
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 25/06/15 18:46, Nick Sabalausky wrote: Heh, that's awesome actually :) Got a source for that? Windows 8 was a big failure. Windows 10 is looking much better, I think it will get a much higher adaption rate. -- /Jacob Carlborg
Re: New names - 2.068 roundup
On 6/25/15 3:48 PM, Mathias Lang via Digitalmars-d wrote: 2015-06-25 21:28 GMT+02:00 Steven Schveighoffer via Digitalmars-d mailto:digitalmars-d@puremagic.com>>: On 6/24/15 11:12 PM, Steven Schveighoffer wrote: So I actually implemented this. I made it a std.internal type so it can be used wherever you need to port string concatenation to a chain. Seems like Andrei has nixed this idea: "Please no breakages and no clever schemes and no overengineering." http://forum.dlang.org/post/mmhjqe$2mud$1...@digitalmars.com Oh well. I'm kind of done with the whole naming thing, there are better things I could (and probably should) be doing. Plus arguing against Walter and/or Andrei is kind of an uphill battle, especially if they both agree on something. I'll leave the branch up for anyone who wants to continue to try things with it, it was a very cool idea. And he's right. It is really annoying to update to a new version and have perfectly valid and working code breaking because someone had a nice idea. Ideally, we should only ever break code that has a bug in it. Yeah, I agree for existing names, but these are unreleased new names. -Steve
Re: New names - 2.068 roundup
2015-06-25 21:28 GMT+02:00 Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com>: > On 6/24/15 11:12 PM, Steven Schveighoffer wrote: > >> So I actually implemented this. I made it a std.internal type so it can >> be used wherever you need to port string concatenation to a chain. >> > > Seems like Andrei has nixed this idea: > > "Please no breakages and no clever schemes and no overengineering." > > http://forum.dlang.org/post/mmhjqe$2mud$1...@digitalmars.com > > Oh well. I'm kind of done with the whole naming thing, there are better > things I could (and probably should) be doing. Plus arguing against Walter > and/or Andrei is kind of an uphill battle, especially if they both agree on > something. > > I'll leave the branch up for anyone who wants to continue to try things > with it, it was a very cool idea. > > -Steve > And he's right. It is really annoying to update to a new version and have perfectly valid and working code breaking because someone had a nice idea. Ideally, we should only ever break code that has a bug in it.
Re: New names - 2.068 roundup
On 6/24/15 11:12 PM, Steven Schveighoffer wrote: So I actually implemented this. I made it a std.internal type so it can be used wherever you need to port string concatenation to a chain. Seems like Andrei has nixed this idea: "Please no breakages and no clever schemes and no overengineering." http://forum.dlang.org/post/mmhjqe$2mud$1...@digitalmars.com Oh well. I'm kind of done with the whole naming thing, there are better things I could (and probably should) be doing. Plus arguing against Walter and/or Andrei is kind of an uphill battle, especially if they both agree on something. I'll leave the branch up for anyone who wants to continue to try things with it, it was a very cool idea. -Steve
Re: New names - 2.068 roundup
On 6/25/15 2:37 PM, deadalnix wrote: I can do another PR to change the name. Let's already get the TupeTuple in the old module and remove it from std.meta so at least this monstrosity stay contained. Well, we should at least have the documentation for std.meta not referring to a symbol that doesn't exist there. -Steve
Re: std.uni.toCapitalized
On 6/25/15 12:00 PM, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 18:56:39 UTC, Andrei Alexandrescu wrote: On 6/25/15 6:45 AM, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: Same as toLowerCase/toUpperCase. Suggested new name: Following the same pattern as whatever new toLowerCase/toUpperCase names will be chosen. There was that PR with some logic for naming the casing functions. It's still relevant. -- Andrei Jacob's PR? https://github.com/D-Programming-Language/phobos/pull/3243 Yes, we've discussed lowerCaser/upperCaser a lot in this thread. Last post in that discussion: http://forum.dlang.org/post/mmh47u$28bu$1...@digitalmars.com Yah, that's the one. Glad it's under consideration - this is the only time it could ever be. -- Andrei
I'm outta here
Hi folks, We're in the final stages of moving house across the country so I'll be more or less out of commission for a few days. A few thoughts: * Review of std.allocator has been slow. I did my best to be responsive to feedback. There are a couple of remaining open issues regarding naming of things (what else?) which I think oughtn't block inclusion in std.experimental - then we'll get to experiment and see how it all feels. * I've been hard at work on std.collection and I think something good will come out of it. Will keep on hacking at it. * Please don't overdo The Grand Renaming. Find some good names for new things and call it a day. Please no breakages and no clever schemes and no overengineering. This is a good opportunity to create a good precedent of having the community have a word on introduced names and doing so in an orderly manner. Please let's not squander it. Find some good names and let's move on. * Thanks Martin for pushing the beta through, and let's make this a solid release! Cheers, Andrei
Re: std.uni.toCapitalized
On Thursday, 25 June 2015 at 18:56:39 UTC, Andrei Alexandrescu wrote: On 6/25/15 6:45 AM, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: Same as toLowerCase/toUpperCase. Suggested new name: Following the same pattern as whatever new toLowerCase/toUpperCase names will be chosen. There was that PR with some logic for naming the casing functions. It's still relevant. -- Andrei Jacob's PR? https://github.com/D-Programming-Language/phobos/pull/3243 Yes, we've discussed lowerCaser/upperCaser a lot in this thread. Last post in that discussion: http://forum.dlang.org/post/mmh47u$28bu$1...@digitalmars.com
Re: std.uni.toCapitalized
On 6/25/15 6:45 AM, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: Same as toLowerCase/toUpperCase. Suggested new name: Following the same pattern as whatever new toLowerCase/toUpperCase names will be chosen. There was that PR with some logic for naming the casing functions. It's still relevant. -- Andrei
Re: std.algorithm.sorting.ordered, strictlyOrdered
On Thursday, 25 June 2015 at 18:55:54 UTC, Andrei Alexandrescu wrote: Is that the function that just takes a few values? isOrdered(0, x, 100) is a bit grating seeing as the grammar requires "are ordered". -- Andrei Ah, true, I misread the documentation.
Re: std.algorithm.sorting.ordered, strictlyOrdered
On 6/25/15 6:31 AM, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: - The function is very closely related to "isSorted". - The "is" prefix strongly indicates that the return value is a bool, and removes ambiguity that this function might return an ordered view of something. - Would be nice to leave this naming scheme for lazy range operations, as is already used for indexed / transposed, which return ranges, not bools. Suggested new name: isOrdered / isStrictlyOrdered Is that the function that just takes a few values? isOrdered(0, x, 100) is a bit grating seeing as the grammar requires "are ordered". -- Andrei
Re: Naming Voldemort Types
On 6/25/15 6:12 AM, "Nordlöw" wrote: I've noticed that the namings of lazy range voldemort types are inconsistent in Phobos. Some are named `XResult` others just `Result`, given that `x` is the parenting algorithm. What's the policy here? I would prefer the verbose `XResult` as it's more self documenting when debugging or using for instance pragma(msg, typeof(r)) where `r` is an instance of a lazy range. What do you guys think? Result. No stuttering please. -- Andrei
Re: D could catch this wave: web assembly
On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote: This appears to have involvement from all major browser vendors, which provides hope it might actually catch on properly. An llvm backend will be created which will compile to "wasm", hopefully LDC and/or SDC could glue to this. https://www.w3.org/community/webassembly/ https://github.com/WebAssembly In particular, see https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md So it has been 13 pages of heated debate, but no PR is to be seen for LDC or SDC...
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 18:04:49 UTC, Steven Schveighoffer wrote: On 6/25/15 6:53 AM, Vladimir Panteleev wrote: On Wednesday, 24 June 2015 at 21:06:43 UTC, deadalnix wrote: I'd like to raise concern about the Arguments name in std.meta . That is not the first time I do so, but this still needs to change. I haven't participated with the discussion but I agree with the points in your post. Me too. Looking at Amaury's PR, there is still much of the documentation that refers to TypeTuple. It will be difficult/awkward to change to "Arguments". e.g.: Returns an Arguments [instance] created from TList with the first occurrence, if any, of T removed. Filters an Arguments [instance] using a template predicate. Returns an Arguments [instance] of the elements which satisfy the predicate. I think you are going to have to add "instance" anywhere you are talking about Arguments. And that "Arguments instance of" reads terrible. I don't know what the right name is, but I think it should be singular at least. -Steve I can do another PR to change the name. Let's already get the TupeTuple in the old module and remove it from std.meta so at least this monstrosity stay contained.
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 18:04:49 UTC, Steven Schveighoffer wrote: I don't know what the right name is, but I think it should be singular at least. Part of the core problem is that it can be used for either parameters or arguments - or it can simply be used in certain places as a compile-time entity separately from functions are templates (e.g. foreach). So, names like ParamList or ArgList come to mind, but they all have the problem of covering only one of the cases (just like TypeTuple has the problem of only covering the case where it has types in it when in fact it can have values in it as well as containing both at the same time). I don't think that I've ever seen a _good_ name for what TypeTuple represents. I really wish that we'd stop using the word tuple in regards to them though, since they _aren't_ tuples. But unfortunately, that's how the language spec refers to them... IIRC, Adam Ruppe defined them as being a CTList in his dconf talk (presumably for compile-time list). That seems like one of the better names that I've seen, and I'd certainly be up for that. - Jonathan M Davis
Re: New names - 2.068 roundup
On 6/25/15 6:53 AM, Vladimir Panteleev wrote: On Wednesday, 24 June 2015 at 21:06:43 UTC, deadalnix wrote: I'd like to raise concern about the Arguments name in std.meta . That is not the first time I do so, but this still needs to change. I haven't participated with the discussion but I agree with the points in your post. Me too. Looking at Amaury's PR, there is still much of the documentation that refers to TypeTuple. It will be difficult/awkward to change to "Arguments". e.g.: Returns an Arguments [instance] created from TList with the first occurrence, if any, of T removed. Filters an Arguments [instance] using a template predicate. Returns an Arguments [instance] of the elements which satisfy the predicate. I think you are going to have to add "instance" anywhere you are talking about Arguments. And that "Arguments instance of" reads terrible. I don't know what the right name is, but I think it should be singular at least. -Steve
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 17:23:17 UTC, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 17:21:49 UTC, deadalnix wrote: https://github.com/D-Programming-Language/phobos/pull/3440 Let's see what the autotester think about this. Well, that didn't take long. But at least it uncovered a DMD ICE :) I got it to work now :) This ICE still needs to be fixed.
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 17:21:49 UTC, deadalnix wrote: https://github.com/D-Programming-Language/phobos/pull/3440 Let's see what the autotester think about this. Well, that didn't take long. But at least it uncovered a DMD ICE :)
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 10:53:45 UTC, Vladimir Panteleev wrote: On Wednesday, 24 June 2015 at 21:06:43 UTC, deadalnix wrote: I'd like to raise concern about the Arguments name in std.meta . That is not the first time I do so, but this still needs to change. I haven't participated with the discussion but I agree with the points in your post. I discussed various names with many at DConf. The name that seemed to be, if not preferred by all, the one that nobody had any strong reason to be against is Sequence. Can we use that ? There is std.range.Sequence, though. Also, I'm not sure why TypeTuple is introduced in std.meta "for legacy compatibility" as the module is brand new. I think it can be moved back to std.typetuple? https://github.com/D-Programming-Language/phobos/pull/3440 Let's see what the autotester think about this.
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 6/25/15 12:46 PM, Nick Sabalausky wrote: On 06/25/2015 09:53 AM, Steven Schveighoffer wrote: XP still has more market share right now than Windows 8.1, and that was EOL in April 2014. Heh, that's awesome actually :) Got a source for that? http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 -Steve
Re: Range code and inference errors
On Thursday, 25 June 2015 at 13:27:23 UTC, Mathias Lang wrote: Hi everyone, I've been doing quite a lot of range-based code lately and I've been bugged with an UX problem that's IMHO a real bummer for range usage to new users. [...] This is part of a bigger issue involving error messages for compilation errors due to not implementing a compile-interface such as InputRange. I've been meaning to write a DIP for this for a year now, I just need to find the time. Atila
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 06/25/2015 09:53 AM, Steven Schveighoffer wrote: XP still has more market share right now than Windows 8.1, and that was EOL in April 2014. Heh, that's awesome actually :) Got a source for that?
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On Thursday, 25 June 2015 at 16:05:57 UTC, Steven Schveighoffer wrote: I mean people who are in charge of maintaining company-wide systems that are expensive to upgrade do not upgrade their equipment or OS as often as those who buy desktops/laptops. To upgrade from XP you need to upgrade hardware. Upgrading server OS is cheaper than upgrading all workstations in organization. All of our server systems are on Ubuntu LTS, and it's a major event to update the OS. We try to minimize that. Sure upgrades can't be done often, but for XP it's even less often, than for the server, it runs since 2002 :)
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 6/25/15 11:27 AM, Kagamin wrote: On Thursday, 25 June 2015 at 13:53:40 UTC, Steven Schveighoffer wrote: And server OS migration moves much slower usually. Is it so? Do you mean windows server OS specifically? I mean people who are in charge of maintaining company-wide systems that are expensive to upgrade do not upgrade their equipment or OS as often as those who buy desktops/laptops. All of our server systems are on Ubuntu LTS, and it's a major event to update the OS. We try to minimize that. Of course, this is my opinion, based on experience and logic. I haven't measured. -Steve
Re: End of life for Windows Server 2003 R2 is July 14, 2015
http://www.quora.com/What-is-the-windows-server-market-share-by-version Can't find any info on it.
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On Thursday, 25 June 2015 at 13:53:40 UTC, Steven Schveighoffer wrote: And server OS migration moves much slower usually. Is it so? Do you mean windows server OS specifically?
I released my first library!
For the past week I've been working on my first small cross-platform gamedev-ish console rendering library for d, and I call it clayers. It has been a fun learning process, as I've used many new programs and features. The whole thing is written in vim, which I've never used until now. I got a better understanding of how git works by using the terminal, instead of a GUI. For the first time I used version() for different functions. Finally, I added a releasetag, and then registered it to dub. While I didn't think about it while writing the code, I've gotten a better knowledge of how all of these things work. And this extra stuff I learnt without even thinking about it. GC is something I've never though about before, but thanks to people from #d I now have a better understanding of how it works. Thanks! As for actually writing code: I've gotten to design the library myself, debugged it, and everything that comes with making an library. I've had discussions with people about the rendering and generally come to good terms with many in the #d channel. Thanks to the whole D community it became more fun than I'd ever imagine. Thanks for being here D-people! --- The dub package: http://code.dlang.org/packages/clayers
Re: Naming Voldemort Types
On Thursday, 25 June 2015 at 13:59:14 UTC, Steven Schveighoffer wrote: iI would like to see pragma(msg, typeof(r)) print something like functionThatReturnsVoldemort.Result That doesn't sound like too hard to implement... :)
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On Thursday, 25 June 2015 at 13:53:40 UTC, Steven Schveighoffer wrote: On 6/24/15 12:10 PM, Iain Buclaw wrote: http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ Which means that (strictly speaking), in 3 weeks time, there will be *no* operating system that supports CodeView debugging. This is an elongated way of asking "Can I remove -gc yet?" But as I'm not a Windows user, I'll have to ask how you guys deal with debugging, and if you still rely on CV being emitted from DMD, you must hurry up to implement an alternative! XP still has more market share right now than Windows 8.1, and that was EOL in April 2014. I think it's safe to say the fact that the OS goes EOL doesn't mean we should stop supporting it. And server OS migration moves much slower usually. So I'd say no. We already dropped official support for XP some time ago. If someone really wants to use an older platform that isn't even supported by the folks that made it, I'd argue that they should just use an older version of the D compiler from when that OS actually was supported. It's enough of a burden trying to support all of the platforms that we support right now without worrying about platforms which aren't even supported by the folks that made them. And anyone who uses an OS that's not supported is just begging for trouble anyway given how the number of known security holes is just going to increase. Also, no new software is going to target unsupported platforms anyway, so why support it? The old stuff can continue to work with older compilers that were actually written for that platform, and the new stuff is going to be on current platforms. Personally, I'm all for dropping official support of a platform when the folks making it drop support for it. It's the simplest that way and helps reduce how much we have to worry about. - Jonathan M Davis
Re: std.uni.toLowerCase / .toUpperCase
On 6/25/15 7:10 AM, Vladimir Panteleev wrote:
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
I agree with Jonathan that the latter is clearer as to what the method
is doing--constructing something that will do the work. However, I agree
that the former reads much better. My bikeshed is painted the former
way, mainly because it encourages people to use the range-based style
because it reads so well.
With that said I'm hopeful that Adam's trick will obviate at least some
of this discussion.
Re: std.experimental.color, request reviews
On Thursday, 25 June 2015 at 13:36:57 UTC, Manu wrote: How about HSx ? That's the best I've got! :P HueBased?
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 14:10:45 UTC, Vladimir Panteleev
wrote:
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
Well, I have to disagree there, particularly when the "er"
version of things is much more indicative of what's actually
going on (a series of constructor calls, really - they're just
done via wrapper functions). I can get behind the "asXxx" scheme
when the "xxxer" scheme doesn't fit, but in general, I think that
going with the "xxxer" scheme fits in very well with what's
actually going on and will thus actually help make the code
clearer, whereas I really don't think that that's the case with
"xxxed".
- Jonathan M Davis
Re: std.path.toAbsolutePath / toNormalizedPath / toRelativePath
On Thursday, 25 June 2015 at 13:35:30 UTC, Vladimir Panteleev wrote: On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: - The eager versions are called absolutePath, normalizedPath, relativePath. If anything, the current naming scheme is opposite to some options we've been discussing (e.g. eager=toLowerCase, lazy=lowerCase[d|r]). Suggested new names: asAbsolutePath, asNormalizedPath, asRelativePath. Couldn't think of anything better, but I think this is an improvement. If we are to adopt the "as" prefix, we could also go with asLowerCase/asUpperCase for the std.uni ones. That seems like a reasonable idea for the cases where we really don't have a noun to act as the one doing the action. The situation is weird enough with uppercase and lowercase, since you end up with stuff like upperCaser and lowerCaser when caser isn't really a thing, but at least there, we at least have a fake noun that makes sense. For the path ones, I don't see any kind of noun that makes sense. So, asAbsolutePath, etc. definitely makes some sense, so maybe asLowerCase and asUpperCase would make more sense too. In general though, I'd prefer that we go with the noun naming scheme - particularly when they're basically constructors for ranges. But it obviously doesn't work in all cases. - Jonathan M Davis
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 13:48:41 UTC, Jonathan M Davis wrote:
Also, the less that we have to rename the better
Well, just to keep in mind, we're going to establish a convention
in this release even if we do not explicitly state so - because
in future naming decisions, we *will* be using precedent for
consistency, as we're using now.
So, I'm not saying we *should* go back and rename almost
everything added in 2.068 now, but I'm saying that we shouldn't
allow these hastily-chosen initial names to be a factor in
deciding how to name things from now on. I certainly wouldn't
mind renaming all of them.
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
Re: New names - 2.068 roundup
On Thursday, 25 June 2015 at 13:59:41 UTC, Vladimir Panteleev wrote: I just went through the list and found a few more candidates. I should've done that immediately, sorry about that - with the Beta out, this leaves little time to discuss those. I created new subthreads for all of them. Forgot to mention, I added them to the wiki page for some perspective: http://wiki.dlang.org/Naming_conventions
Re: New names - 2.068 roundup
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: 3. Change the names, with 2.068.0 RC1 being the deadline. I'll create and will be updating a PR after the first beta, and ask the release manager to merge it before the RC release. So, the first Beta is out. Here's a rough tally: -- std.path.setExt withExtension +3 -2 setExtensionLazy +1 -1 (not counting "xLazy" objections from toLowerCase subthread) I think withExtension is the "winner" here. There are a few arguments in favor of a "Lazy" suffix, but many arguments against. -- std.uni.toLowerCase (and toUpperCase) lowerCased +2 -? (all objections seem to be regarding anything that's not "fooLazy") asLowerCase +1 inLowerCase +1 toLowerLazy +4 -6 lowerCaser +2 -1 lowerCase +1 -1 willLowerCase +1 No consensus. My thoughts: - Appending "Lazy" has been argued for, but moreso against. I think the same arguments apply to "willLowerCase". - The goal (and reason for renaming this function in the first place) is to make the lazy name memorably distinguishable from its eager counterpart, toLower. This rules out "lowerCase". - Taking consistency as a factor, this leaves "lowerCaser" (consistent with e.g. "joiner" and "splitter"), "lowerCased" (consistent with e.g. "transposed" and "radial"), and "asLowerCase" (consistent with the only better name for "toAbsolutePath" that I could think of). - "asLowerCase" and "lowerCased" does sound a bit more like proper English than "lowerCaser". I'll go with "asLowerCase" for now, but there's still time for debate. -- I just went through the list and found a few more candidates. I should've done that immediately, sorry about that - with the Beta out, this leaves little time to discuss those. I created new subthreads for all of them. Here is a draft PR: https://github.com/D-Programming-Language/phobos/pull/3439
Re: Naming Voldemort Types
On 6/25/15 9:12 AM, "Nordlöw" wrote: I've noticed that the namings of lazy range voldemort types are inconsistent in Phobos. Some are named `XResult` others just `Result`, given that `x` is the parenting algorithm. What's the policy here? I would prefer the verbose `XResult` as it's more self documenting when debugging or using for instance pragma(msg, typeof(r)) where `r` is an instance of a lazy range. What do you guys think? I think the actual name you use for a voldemort type is of no importance. I would like to see pragma(msg, typeof(r)) print something like functionThatReturnsVoldemort.Result -Steve
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 13:48:41 UTC, Jonathan M Davis wrote:
I prefer the noun naming scheme to the adjective naming scheme.
We really haven't been using adjectives much, and I think that
nouns make more sense, since what you're basically doing is
constructing an object. So, I'd just as soon not start using
adjectives for functions which return lazy ranges.
What do you think of asLowerCase? I heard no objections, this one
actually sounds like proper English, and it's consistent with the
only better name for "toAbsolutePath" that I could think of
("asAbsolutePath").
Also, the less that we have to rename the better, so if many of
the newer functions are already nouns, then it makes sense to
continue that (and it wouldn't surprise me if some of the newer
ones were in 2.067, in which case, it's likely too late to
change them unless they're particularly bad).
No, I'm looking at the diff of functions between 2.067 and
master, and the only verb-noun names in 2.067 are "joiner" and
"splitter".
Re: std.uni.toLowerCase / .toUpperCase
On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev wrote: On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote: When adding lazy versions in the past, for better or worse, we've generally gone for using nouns, whereas you're suggesting adjectives based coming from the past tense of a verb (though the verb "to case" has nothing with the case of letters). OK, so I didn't really understand what were you referring to, since the only examples I found while looking through the *stable* documentation were joiner and splitter. But I went through the list of new symbols, and I found that a few more have been added after the last release to std.string: en/detabber, left/right/centerJustifier, soundexer So, one option is to stay consistent with these additions, and go with upperCaser and lowerCaser, even if those sound a bit odd. Another option would be to rename those additions as well, so we would have: en/detabbed, left/right/centerJustified, soundexed, upperCased, lowerCased I don't know if this counts as being outside of the scope of this thread. Any thoughts? Or is everyone bored to death already? :) I prefer the noun naming scheme to the adjective naming scheme. We really haven't been using adjectives much, and I think that nouns make more sense, since what you're basically doing is constructing an object. So, I'd just as soon not start using adjectives for functions which return lazy ranges. Also, the less that we have to rename the better, so if many of the newer functions are already nouns, then it makes sense to continue that (and it wouldn't surprise me if some of the newer ones were in 2.067, in which case, it's likely too late to change them unless they're particularly bad). - Jonathan M Davis
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On 6/24/15 12:10 PM, Iain Buclaw wrote: http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ Which means that (strictly speaking), in 3 weeks time, there will be *no* operating system that supports CodeView debugging. This is an elongated way of asking "Can I remove -gc yet?" But as I'm not a Windows user, I'll have to ask how you guys deal with debugging, and if you still rely on CV being emitted from DMD, you must hurry up to implement an alternative! XP still has more market share right now than Windows 8.1, and that was EOL in April 2014. I think it's safe to say the fact that the OS goes EOL doesn't mean we should stop supporting it. And server OS migration moves much slower usually. So I'd say no. -Steve
Re: New names - 2.068 roundup
On 6/24/15 11:40 PM, Adam D. Ruppe wrote: (An interesting point here though is since alias this DOES return a string, any duck-type checks or implicit conversion checks will also pass what it passes... and work, it'll just silently allocate the string. Which is no regression! The status quo is it allocates that string EVERY time anyway. But it also isn't ideal. Someone earlier said we can probably apply @nogc to everything but the eager method. I think that'd work, and then at least the allocations wouldn't be silent anymore - the @nogc attribute at the call site can catch them.) One thing that is troubling to me here is that doing an alias this to a string presents 2 range interfaces, but they are not "atomic". That is, something that is checking for elements of a range may find some properties satisfy by using the alias this, and other properties satisfy using the real type. For example, it would be alarming if it called r.eager.length to get the length, but then used the chainString to actually do a slicing operation. For this case, it's probably fine, but I never considered that alias this can present a "hybrid" between both types that may satisfy more than you want. An interesting drawback for alias this... -Steve
Re: PHP verses C#.NET verses D.
On Wednesday, 24 June 2015 at 05:34:08 UTC, Nick B wrote: On Tuesday, 23 June 2015 at 11:22:40 UTC, Etienne Cimon wrote: Nick I don't have current performance results because I've been focused on adding features, but these results were taken on a previous version: https://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/ Etienne Thanks for the responses and your details replies. I'm going to talk to the CEO of the company described, at the beginning of this long thread, and find out they are willing to consider a proof of concept web site based on your work. This could take a couple of weeks. What is the best way to get in touch with you if I have more questions ? Nick Skype: Etcimon or gmail the same username
std.uni.toCapitalized
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: Same as toLowerCase/toUpperCase. Suggested new name: Following the same pattern as whatever new toLowerCase/toUpperCase names will be chosen.
Re: New names - 2.068 roundup
On 6/24/15 11:40 PM, Adam D. Ruppe wrote:
On Thursday, 25 June 2015 at 03:12:47 UTC, Steven Schveighoffer wrote:
A curious thing though. All the tests for things like:
assert(setExtension("file", "ext") == "file.ext");
do not trigger a call to eager.
But it passes? That's bizarre. (My dmd is apparently too old to compile
this, it segfaults when I try!)
Let me clarify this -- it does not spout the deprecation for those
lines. I'm not sure exactly what the compiler is doing :) is there a
good way to determine how the compiler is resolving the call?
assert(setExtension("file", "ext").array == "file.ext");
I did experience this in my proof-of-concept because I didn't implement
.length. So when array checked hasLength, it found it through the alias
this, which called eager.
Hm... it should only define length if the underlying strings satisfy
hasLength. And AFAIK, strings and wstrings do not have length according
to Phobos. I can do some asserts to check.
(That's also why I did a foreach loop instead
of just returning array(this). Well, that and the auto-decode nonsense,
but array would be a recursive call and stack overflow anyway).
I actaully followed Walter's example and used std.conv.to :)
These two things are weird, but I'm sure they're just bugs that we can
handle. In the morning, I'll try a git dmd and see if I can play with it
a little, right now I'm just guessing since it won't build on my current
setup.
I'm interested to hear how it goes!
-Steve
Re: Phobos addition formal review: std.experimental.allocator
1 day remaining
std.path.toAbsolutePath / toNormalizedPath / toRelativePath
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: - The eager versions are called absolutePath, normalizedPath, relativePath. If anything, the current naming scheme is opposite to some options we've been discussing (e.g. eager=toLowerCase, lazy=lowerCase[d|r]). Suggested new names: asAbsolutePath, asNormalizedPath, asRelativePath. Couldn't think of anything better, but I think this is an improvement. If we are to adopt the "as" prefix, we could also go with asLowerCase/asUpperCase for the std.uni ones.
Re: std.experimental.color, request reviews
How about HSx ? That's the best I've got! :P On 25 June 2015 at 15:45, Manu wrote: > On 25 June 2015 at 15:18, Danni Coy via Digitalmars-d > wrote: >> I would probably go with "perceptual" or something like it > > That sounds like you're talking about Lab or CAM. > > >> On Thu, Jun 25, 2015 at 2:39 PM, Danni Coy wrote: >>> Wikipedia at least refer to these as cylindrical colour spaces
std.algorithm.sorting.ordered, strictlyOrdered
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff Rationale: - The function is very closely related to "isSorted". - The "is" prefix strongly indicates that the return value is a bool, and removes ambiguity that this function might return an ordered view of something. - Would be nice to leave this naming scheme for lazy range operations, as is already used for indexed / transposed, which return ranges, not bools. Suggested new name: isOrdered / isStrictlyOrdered
Range code and inference errors
Hi everyone,
I've been doing quite a lot of range-based code lately and I've
been bugged with an UX problem that's IMHO a real bummer for
range usage to new users.
Take the example code:
```
import std.algorithm;
void main()
{
auto foo = [ "foo": "foo", "bar": "bar", "foobar": "foobar" ];
assert(foo.byKeyValue.all!((kvp) => kvp.Key == kvp.Value));
}
```
Quite straightforward, right ? Some of you might already have
spotted the error, but here's what DMD think of it:
```
test.d(6): Error: template std.algorithm.searching.all cannot
deduce function from argument types !((kvp) => kvp.Key ==
kvp.Value)(Result), candidates are:
/dlang/dmd-2.067.0/linux/bin64/../../src/phobos/std/algorithm/searching.d(100):
std.algorithm.searching.all(alias pred = "a")
```
This happens because I got the delegate wrong. To get the right
error, you have to know errors are gagged and so, let's remove
the type inference error:
```
assert(foo.byKeyValue.all!((typeof(foo.byKeyValue.front) kvp) =>
kvp.Key == kvp.Value));
```
Which gives a proper error message:
```
test.d(6): Error: no property 'Key' for type 'Pair', did you mean
'key'?
test.d(6): Error: no property 'Value' for type 'Pair', did you
mean 'value'?
```
Any change we can fix that ?
std.path.defaultExt
On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote: [...] Same rationale as setExt/setExtension: the name difference from defaultExtension is abbreviating the word "Extension" to "Ext". Really should've been in the same thread, I simply missed it. Suggested new name: withDefaultExtension
