Re: What allocators do you want in std.allocator.showcase?
On Saturday, 6 June 2015 at 05:33:24 UTC, Andrei Alexandrescu wrote: I've put together http://erdani.com/d/phobos-prerelease/std_experimental_allocator_showcase.html, which is a module containing typical, ready-to-use allocator instantiations. The basic idea of showcase is to offer allocators that are as easy to use as calling a function or using a type - no assembly required. I've seeded it with a super simple stack front and a mmapped list of regions. I have about half a dozen more of usual suspects. What would you like to see in there? Andrei are there any plans for a reap-based allocator?
We need to have a way to say "convert this nested function into a struct"
Nested functions that allocate their environment dynamically can be quite useful. However, oftentimes the need is to convert the code plus the data needed into an anonymous struct that copies the state inside, similar to C++ lambdas that capture by value. I wonder how to integrate that within the language nicely. Andrei
Re: Code behaves incorrectly if it is compiled in std.functional
On Fri, 05 Jun 2015 20:36:19 +, Mafi wrote:
> On Friday, 5 June 2015 at 10:56:36 UTC, ketmar wrote:
>
>
>> p.s. if "auto" is a storage class, the following code should be
>> accepted (while it isn't):
>>
>> int foo () { return 42; }
>>
>> void main () {
>> auto auto i = foo();
>> }
>>
>> as it's logically "an auto-typed var with "auto" storage class".
>
> Here lies your mistake. There is no such thing as "auto"-typed (leaving
> aside function signatures, which might be special-cased and are
> different beast altogether). Auto is not a type. auto* or auto[] aren't
> valied either. Auto is just a storage class, no more, no less. You use
> it if the grammar needs a storage class but you don't want to give
> special attributes to the variable (like const or static). To make a
> declaration with inferred type you need at least one storage class. To
> make it work with "normal" variables you use "auto".
p.s. even more samples: `foreach (auto n; 0..10)`. this doesn't work at
all. why? `foreach (immutable n; 0..10)` works perfectly. so `auto`
clearly is not a "storage class", as it is forbidden where storage
classes are allowed.
signature.asc
Description: PGP signature
Re: Code behaves incorrectly if it is compiled in std.functional
On Fri, 05 Jun 2015 20:36:19 +, Mafi wrote:
> On Friday, 5 June 2015 at 10:56:36 UTC, ketmar wrote:
>
>
>> p.s. if "auto" is a storage class, the following code should be
>> accepted (while it isn't):
>>
>> int foo () { return 42; }
>>
>> void main () {
>> auto auto i = foo();
>> }
>>
>> as it's logically "an auto-typed var with "auto" storage class".
>
> Here lies your mistake. There is no such thing as "auto"-typed (leaving
> aside function signatures, which might be special-cased and are
> different beast altogether). Auto is not a type. auto* or auto[] aren't
> valied either. Auto is just a storage class, no more, no less. You use
> it if the grammar needs a storage class but you don't want to give
> special attributes to the variable (like const or static). To make a
> declaration with inferred type you need at least one storage class. To
> make it work with "normal" variables you use "auto".
so either `const auto` should not be accepted, or `auto auto` should be
accepted. if `auto` plays a role of "default storage class", the `const
auto` should trigger the error about redundant storage specifier. if
`auto` can play a role of type placeholder, then `auto auto` should be
accepted, as it's clearly the "default storage class with type
placeholder".
current situation is inconsistent and that inconsistency must be fixed.
signature.asc
Description: PGP signature
Re: Code behaves incorrectly if it is compiled in std.functional
On Fri, 05 Jun 2015 18:35:49 +, Marc Schütz wrote: > On Friday, 5 June 2015 at 17:50:55 UTC, ketmar wrote: >> `const int` works, so i can't see why `auto auto` is failing. > > Wrong analogy. Try `const const`, and it will fail with the same error > as `auto auto`: "redundant attribute". nope. in `auto auto` one `auto` is storage type, and another `auto` is a type placeholder. see, `const auto` works, so `auto` can play role of a type placeholder. so `auto auto` should be accepted, if you insists that it can play a role of storage class. signature.asc Description: PGP signature
Re: Code behaves incorrectly if it is compiled in std.functional
On Sat, 06 Jun 2015 00:28:51 +0200, Timon Gehr wrote: > On 06/05/2015 02:33 PM, ketmar wrote: >> i agree, i think it was a keyword used 'cause it was already used in C. >> but it's meaning is completely redefined in D. > > The meaning is exactly the same. It's the default storage class. then i'll fill a bug about `auto auto` and will reopen it until it's fixed. signature.asc Description: PGP signature
What allocators do you want in std.allocator.showcase?
I've put together http://erdani.com/d/phobos-prerelease/std_experimental_allocator_showcase.html, which is a module containing typical, ready-to-use allocator instantiations. The basic idea of showcase is to offer allocators that are as easy to use as calling a function or using a type - no assembly required. I've seeded it with a super simple stack front and a mmapped list of regions. I have about half a dozen more of usual suspects. What would you like to see in there? Andrei
Re: Proposal for new dlang.org fonts
On Friday, 5 June 2015 at 23:10:33 UTC, Andrei Alexandrescu wrote: Take a look at https://github.com/D-Programming-Language/dlang.org/pull/1009. Preview: http://erdani.com/d/phobos-prerelease/ ... Well if you increase the font size I think it will looks better, see: http://i.imgur.com/RzoVSRs.jpg And like I said on the other thread (About the new Forum layout) please remember that some people uses Tablet/Phone to access, and tiny fonts is horrible on tiny screens like 7" both to read or touch (links). Matheus.
Re: Attempt to get rid of phobos Makefiles, using reggae
On Friday, 5 June 2015 at 15:03:27 UTC, Atila Neves wrote: On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote: BTW, why are some Linux specific files ignored? No clue, I just went with the output of `make -f posix.mak`. It's the kind of thing that'd be more explicit if the build description were in D. It was one of my questions in the original post ;) Oh, I can answer that, std.c.* has been deprecated: https://github.com/D-Programming-Language/phobos/pull/2337 It is unused in phobos, so it doesn't need to be built. It's only around for users who might still be employing it, giving them time to phase it out of their code.
Re: Daily downloads in decline
On Friday, 5 June 2015 at 20:23:17 UTC, David Nadlinger wrote: On Monday, 1 June 2015 at 18:14:40 UTC, Andrei Alexandrescu wrote: As much as I want it, ddmd seems to not be happening for 2.068 because of, simply put, insufficient resources. Why is that? A first test release does not seem to be further away than, say, full rangeification of Phobos. Answered earlier in the thread: http://forum.dlang.org/post/mkibq1$aj9$1...@digitalmars.com
Re: Getting Started
I've seen this linked on the forum fairly recently: http://d.readthedocs.org/en/latest/ Maybe it can be used?
Re: Getting Started
On Saturday, 6 June 2015 at 01:13:38 UTC, anonymous wrote: On Friday, 5 June 2015 at 20:18:59 UTC, tcak wrote: I am looking at the main page of dlang.org, and really there is no page to warm up a new comer to D language. Sure, there are book links, details of language as "D Reference" etc, but those are not suitable for a new starting guy. http://dlang.org/getstarted.html should be that page. Unfortunately, it's not very good. I made a pull request to feature Ali's "Programming in D" more prominently there: https://github.com/D-Programming-Language/dlang.org/pull/1010 Because as far as I know that's the best we have for absolute newbies. Showing the features of language with SIMPLE examples in many pages could be very useful in my opinion. Yeah, for somewhat advanced people that are just new to D that could be nice. Ali's book should promoted far more than it is, it's the most up to date comprehensive tutorial/book D has(I consider TDPL more of a reference manual.)
Re: Getting Started
On Saturday, 6 June 2015 at 01:24:42 UTC, Israel wrote: Except my getting started page idea was supposed to cater to both new programmers and people who are just new to D... If you ever get around to realize it, that would be great. In the meantime, linking to Ali's tutorial and example pages are improvements over what's there, which is nothing really.
Re: Working on new binary serialization module for phobos (hopefully)
On Friday, 5 June 2015 at 14:55:24 UTC, Atila Neves wrote: Cerealed has more features than this as well. I'd struggle to write code as short as I did when using it to implement networking protocols. I also only encoded bytes as big-endian since binary serialization is usually followed by sending those bytes over the wire. Given you check the endianess of the system here, how would that work? I don't know what you mean bytes by themselves don't have an endianness, do they? I thought is was only anything that was larger than a byte had endianness Yes. And sometimes mixed endianess depending on the architecture. I might be wrong, but it seems to me that it'd be hard to send the bytes over the wire with this. Atila if you mean bit numbering then it dosen't matter because its managed by the hardware anyway http://en.wikipedia.org/wiki/Endianness#.22Bit_endianness.22 but just to be sure i'll do some tests
Re: Getting Started
On Saturday, 6 June 2015 at 01:13:38 UTC, anonymous wrote: On Friday, 5 June 2015 at 20:18:59 UTC, tcak wrote: [...] http://dlang.org/getstarted.html should be that page. Unfortunately, it's not very good. I made a pull request to feature Ali's "Programming in D" more prominently there: https://github.com/D-Programming-Language/dlang.org/pull/1010 Because as far as I know that's the best we have for absolute newbies. [...] Yeah, for somewhat advanced people that are just new to D that could be nice. Except my getting started page idea was supposed to cater to both new programmers and people who are just new to D...
Re: Getting Started
On Friday, 5 June 2015 at 20:18:59 UTC, tcak wrote: I am looking at the main page of dlang.org, and really there is no page to warm up a new comer to D language. Sure, there are book links, details of language as "D Reference" etc, but those are not suitable for a new starting guy. http://dlang.org/getstarted.html should be that page. Unfortunately, it's not very good. I made a pull request to feature Ali's "Programming in D" more prominently there: https://github.com/D-Programming-Language/dlang.org/pull/1010 Because as far as I know that's the best we have for absolute newbies. Showing the features of language with SIMPLE examples in many pages could be very useful in my opinion. Yeah, for somewhat advanced people that are just new to D that could be nice.
Re: Getting Started
On Friday, 5 June 2015 at 20:18:59 UTC, tcak wrote: I am looking at the main page of dlang.org, and really there is no page to warm up a new comer to D language. Sure, there are book links, details of language as "D Reference" etc, but those are not suitable for a new starting guy. Showing the features of language with SIMPLE examples in many pages could be very useful in my opinion. I liked rust's example page: http://rustbyexample.com/hello.html but it is still not for a new comer. Too much writing is there. It should be like "Do those things, and see what value you will see.". Now, as always the question is, "Who is going to prepare those?". We need: 1. A link to example pages on left side of web page. 2. 5 simple examples those are written in separate pages. 3. Give link to each page for next example. By the time, people can contribute to there. When there is no base, nobody is taking any steps. Ill be honest, that Getting Started page was my idea. Its a great start no matter what programming experience youre going through. It is supposed to be a simple and proper tutorial which guides new users/programmers through the most essential parts. The problem is that we didnt have the time to make it happen. But ill run down a simple timeline from beginning to end: -Simple Hello World / simple Compiler usage tutorial -Variable types / auto (auto needs to be explained because we see it often) -Integers/numbers/floats etc... -Simple number mathematical operators and examples -some string functions -some array samples -some string / array manipulation -loops -imports / modules -Object oriented projects and structure -io file and path functions -Extras and Useful functions (This serves as a small tutorial for extremely useful functions that we use often) Thread.sleep(), etc... -Dub Tutorial and using third party libraries -Ahli Cerellis Book for more advanced programming detail, techniques and schemes
Re: Proposal for new dlang.org fonts
On Friday, 5 June 2015 at 23:55:34 UTC, Andrei Alexandrescu wrote: On 6/5/15 4:47 PM, Mike wrote: On Friday, 5 June 2015 at 23:42:05 UTC, Andrei Alexandrescu wrote: Roboto Mono does have a number of problems. I switched to Inconsolata, which aligns nicer. -- Andrei Added image to the pull request: https://github.com/D-Programming-Language/dlang.org/pull/1009#issuecomment-109483797 Looks a little weird. Mike Thanks! Those weird artifacts around monospace characters... my eyes going bad, image conversion error, or is that the actual look of it? -- Andrei That's actually the way it looks for me.
Re: Proposal for new dlang.org fonts
On 6/5/15 4:47 PM, Mike wrote: On Friday, 5 June 2015 at 23:42:05 UTC, Andrei Alexandrescu wrote: Roboto Mono does have a number of problems. I switched to Inconsolata, which aligns nicer. -- Andrei Added image to the pull request: https://github.com/D-Programming-Language/dlang.org/pull/1009#issuecomment-109483797 Looks a little weird. Mike Thanks! Those weird artifacts around monospace characters... my eyes going bad, image conversion error, or is that the actual look of it? -- Andrei
Re: Proposal for new dlang.org fonts
On Friday, 5 June 2015 at 23:42:05 UTC, Andrei Alexandrescu wrote: Roboto Mono does have a number of problems. I switched to Inconsolata, which aligns nicer. -- Andrei Added image to the pull request: https://github.com/D-Programming-Language/dlang.org/pull/1009#issuecomment-109483797 Looks a little weird. Mike
Re: Proposal for new dlang.org fonts
The bikeshed looks fine the way it is, thanks. But it should be green. Seriously though, updating the website is probably a good idea. My thoughts comparing: * New font is smaller, harder to read than existing. Have to bump it up one in my browser. * Bold doesn't look bold. Did the bold unbold? * The page needs more love than just a new font to be easily usable. Blocks of lines run together.
Re: Proposal for new dlang.org fonts
On 6/5/15 4:26 PM, Mike wrote: On Friday, 5 June 2015 at 23:19:20 UTC, Andrei Alexandrescu wrote: On 6/5/15 4:18 PM, Mike wrote: On Friday, 5 June 2015 at 23:10:33 UTC, Andrei Alexandrescu wrote: Take a look at https://github.com/D-Programming-Language/dlang.org/pull/1009. Preview: http://erdani.com/d/phobos-prerelease/ Destroy. Andrei Didn't turn out like I had hoped. Sorry. Thumbs down. Code, text, or both? -- Andrei Both, actually. I can't put my finger on it exactly, but the font seems look a little "fuzzier" than the current font, and appears less crisp. The font sizes though are throwing me off. It looks like you should reduce the code font size, but increase the text font size to give it an apples-to-apples comparison. If you can do that I'll give it another look. Mike Roboto Mono does have a number of problems. I switched to Inconsolata, which aligns nicer. -- Andrei
Re: dmd makes D appear slow
On 6 June 2015 at 01:20, weaselcat via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Friday, 5 June 2015 at 22:07:48 UTC, Iain Buclaw wrote: > >> On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d" < >> digitalmars-d@puremagic.com> wrote: >> >>> >>> On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote: >>> [...] >This isn't the first time I've seen this, in basically >every > benchmark > >featuring D I have to submit a patch/make a comment that >dmd > shouldn't > >be used. Make no mistake, this is damaging to D's >reputation - how > >well does D's "native efficiency" go over when people are >saying it's > >slower than Scala and F#(mono)? > > > >LDC and GDC need promoted more. > [...] This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. >>> >>> >>> It should be more than just LDC/GDC being the default download on >>> >> dlang.org, the DM backend and related toolchain should be phased out >> altogether in favor of LLVM. >> >>> >>> Walter might have written great compiler tools in the 90s or so, but in >>> >> today's internet and FOSS online-collaborative era, how can the Digital >> Mars toolchain hope to compete with toolchains having teams of multiple >> full-time developers working on it? (plus a plethora of occasional >> volunteer contributors). The difference in manpower and resources is >> astonishing! And it's only gonna get bigger since LLVM is having more and >> more people and companies supporting it. By this rate, it may well one day >> make even GCC old and obsolete, left to be used by FSF zealots only. >> >>> >>> >> At the risk of speaking with lack of foresight, are you on the gcc mailing >> list too? If not, get on it. Otherwise you will enter this kind of >> polarised view of X will dominate all. >> > > Slightly off topic, but I recently started digging into GDC( on your > personal fork, anyways.) I find the code pleasantly easy to navigate and > understand. I don't think I've given gdc its due credit in this thead. > > Bye, > If you've been following the 2.067 re-work, that is really the way things are going right now. More encapsulation, less of the flat hierachal structure is the key securing future interest. My hope is that GDC will fall into the "what a good frontend shoudl do" category after I'm done.
Re: Proposal for new dlang.org fonts
On Friday, 5 June 2015 at 23:26:46 UTC, Mike wrote: Both, actually. I can't put my finger on it exactly, but the font seems look a little "fuzzier" than the current font, and appears less crisp. No hinting, I guess. That's not good for readability. Andrei has a high-DPI display, hinting isn't as important there. The font sizes though are throwing me off. It looks like you should reduce the code font size, but increase the text font size to give it an apples-to-apples comparison. If you can do that I'll give it another look. If it looks fine on one machine now, I wonder if such a change would make it look bad on that machine but fix it on others?
Re: Proposal for new dlang.org fonts
On Friday, 5 June 2015 at 23:19:20 UTC, Andrei Alexandrescu wrote: On 6/5/15 4:18 PM, Mike wrote: On Friday, 5 June 2015 at 23:10:33 UTC, Andrei Alexandrescu wrote: Take a look at https://github.com/D-Programming-Language/dlang.org/pull/1009. Preview: http://erdani.com/d/phobos-prerelease/ Destroy. Andrei Didn't turn out like I had hoped. Sorry. Thumbs down. Code, text, or both? -- Andrei Both, actually. I can't put my finger on it exactly, but the font seems look a little "fuzzier" than the current font, and appears less crisp. The font sizes though are throwing me off. It looks like you should reduce the code font size, but increase the text font size to give it an apples-to-apples comparison. If you can do that I'll give it another look. Mike
Re: dmd makes D appear slow
On Friday, 5 June 2015 at 22:07:48 UTC, Iain Buclaw wrote: On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote: [...] >This isn't the first time I've seen this, in basically >every benchmark >featuring D I have to submit a patch/make a comment that >dmd shouldn't >be used. Make no mistake, this is damaging to D's >reputation - how >well does D's "native efficiency" go over when people are >saying it's >slower than Scala and F#(mono)? > >LDC and GDC need promoted more. [...] This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. It should be more than just LDC/GDC being the default download on dlang.org, the DM backend and related toolchain should be phased out altogether in favor of LLVM. Walter might have written great compiler tools in the 90s or so, but in today's internet and FOSS online-collaborative era, how can the Digital Mars toolchain hope to compete with toolchains having teams of multiple full-time developers working on it? (plus a plethora of occasional volunteer contributors). The difference in manpower and resources is astonishing! And it's only gonna get bigger since LLVM is having more and more people and companies supporting it. By this rate, it may well one day make even GCC old and obsolete, left to be used by FSF zealots only. At the risk of speaking with lack of foresight, are you on the gcc mailing list too? If not, get on it. Otherwise you will enter this kind of polarised view of X will dominate all. Slightly off topic, but I recently started digging into GDC( on your personal fork, anyways.) I find the code pleasantly easy to navigate and understand. I don't think I've given gdc its due credit in this thead. Bye,
Re: Proposal for new dlang.org fonts
On 6/5/15 4:18 PM, Mike wrote: On Friday, 5 June 2015 at 23:10:33 UTC, Andrei Alexandrescu wrote: Take a look at https://github.com/D-Programming-Language/dlang.org/pull/1009. Preview: http://erdani.com/d/phobos-prerelease/ Destroy. Andrei Didn't turn out like I had hoped. Sorry. Thumbs down. Code, text, or both? -- Andrei
Re: Proposal for new dlang.org fonts
On Friday, 5 June 2015 at 23:10:33 UTC, Andrei Alexandrescu wrote: Take a look at https://github.com/D-Programming-Language/dlang.org/pull/1009. Preview: http://erdani.com/d/phobos-prerelease/ Destroy. Andrei Didn't turn out like I had hoped. Sorry. Thumbs down. Mike
Proposal for new dlang.org fonts
Take a look at https://github.com/D-Programming-Language/dlang.org/pull/1009. Preview: http://erdani.com/d/phobos-prerelease/ Destroy. Andrei
Re: [website] Fonts Roboto and Roboto Mono
On Friday, 5 June 2015 at 22:19:01 UTC, Andrei Alexandrescu wrote: These are made by Google and are optimized for the Web. On https://www.google.com/fonts#UsePlace:use/Collection:Roboto it seems like downloading a few of them keeps that gauge in the green region. Right, but Google doesn't know about all the other resources we already use on dlang.org (CodeMirror / "Edit and run", sidebar resources, Disqus for DDox etc.). Not sure what I'm looking at, but point taken. Perhaps I should try that on the main site. We control the content on dlang.org, and we don't have much Unicode, so it might be fine there. The issue is then with consistency across websites. Well yah but our interior design has grown long in the tooth. Time for a change. I'll ask a trusted lieutenant (myself) to try Roboto and Roboto Mono on the site. Here is an alternative: http://www.cssfontstack.com/ It allows choosing font sets that are already available on most machines out there.
Re: Code behaves incorrectly if it is compiled in std.functional
On 06/05/2015 02:33 PM, ketmar wrote: i agree, i think it was a keyword used 'cause it was already used in C. but it's meaning is completely redefined in D. The meaning is exactly the same. It's the default storage class.
Re: rvalue references
On Friday, 5 June 2015 at 21:31:22 UTC, Namespace wrote: I start working on a Pull (https://github.com/D-Programming-Language/dmd/pull/4717), but it fails the first check. The reason seems to be this: https://github.com/D-Programming-Language/dmd/pull/4717/files#diff-ffafa03255a57832dd09031af6cb915dR5945 I guess that this error happens because I cannot distinguish between template and non template auto ref. Does anyone have an idea? Hmm, the only problematic code is std.algorithm.mutation.swap on line 1956 - 1959 which calls doesPointTo from std.exception which is nothrow pure and @nogc, but shouldn't. Without it, everything works.
Re: [website] Fonts Roboto and Roboto Mono
On 6/5/15 3:07 PM, Vladimir Panteleev wrote: On Friday, 5 June 2015 at 21:46:05 UTC, Andrei Alexandrescu wrote: Just found these on reddit: https://www.google.com/fonts/specimen/Roboto https://www.google.com/fonts/specimen/Roboto+Mono I'm thinking to use them instead of Verdana and Lucida Mono respectively. 1. Web fonts come with cost of increased page load time and resource utilization. These are made by Google and are optimized for the Web. On https://www.google.com/fonts#UsePlace:use/Collection:Roboto it seems like downloading a few of them keeps that gauge in the green region. 2. You can't use a custom (web) font for any content which you can't ensure contains only glyphs supported by the font. Which implies that you cannot use it for user-submitted content (forum and wiki), unless you want some glyphs to be in a different font. Which implies that if we do use a different font for the website, the forum may need to use a different, standard font. Examples: http://dump.thecybershadow.net/2ef53dfe00fc112e3418913348bebdf0/0173.png http://dump.thecybershadow.net/686026fbe38bab61e21631f6fb1f6f64/0174.png Not sure what I'm looking at, but point taken. Perhaps I should try that on the main site. 3. Just because a font looks bad on your machine, doesn't mean it looks as bad on others. (Conversely, just because a web font looks good on your machine, doesn't mean it'll look as good on others.) Fonts are hard. Well yah but our interior design has grown long in the tooth. Time for a change. I'll ask a trusted lieutenant (myself) to try Roboto and Roboto Mono on the site. I'm not sure there is a problem that needs to be fixed here, especially considering the caveats. In fact: https://github.com/D-Programming-Language/dlang.org/pull/995 Alrighty. Andrei
Re: [website] Fonts Roboto and Roboto Mono
On Friday, 5 June 2015 at 21:46:05 UTC, Andrei Alexandrescu wrote: Just found these on reddit: https://www.google.com/fonts/specimen/Roboto https://www.google.com/fonts/specimen/Roboto+Mono I'm thinking to use them instead of Verdana and Lucida Mono respectively. 1. Web fonts come with cost of increased page load time and resource utilization. 2. You can't use a custom (web) font for any content which you can't ensure contains only glyphs supported by the font. Which implies that you cannot use it for user-submitted content (forum and wiki), unless you want some glyphs to be in a different font. Which implies that if we do use a different font for the website, the forum may need to use a different, standard font. Examples: http://dump.thecybershadow.net/2ef53dfe00fc112e3418913348bebdf0/0173.png http://dump.thecybershadow.net/686026fbe38bab61e21631f6fb1f6f64/0174.png 3. Just because a font looks bad on your machine, doesn't mean it looks as bad on others. (Conversely, just because a web font looks good on your machine, doesn't mean it'll look as good on others.) Fonts are hard. I'm not sure there is a problem that needs to be fixed here, especially considering the caveats. In fact: https://github.com/D-Programming-Language/dlang.org/pull/995
Re: dmd makes D appear slow
On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote: >> >> [...] >> >>> >This isn't the first time I've seen this, in basically every benchmark >>> >featuring D I have to submit a patch/make a comment that dmd shouldn't >>> >be used. Make no mistake, this is damaging to D's reputation - how >>> >well does D's "native efficiency" go over when people are saying it's >>> >slower than Scala and F#(mono)? >>> > >>> >LDC and GDC need promoted more. >> >> [...] >> >> >> This will probably offend some people, but I think LDC/GDC should be the >> default download on dlang.org, and dmd should be provided as an >> alternative for those who want the latest language version and don't >> mind the speed compromise. > > > It should be more than just LDC/GDC being the default download on dlang.org, the DM backend and related toolchain should be phased out altogether in favor of LLVM. > > Walter might have written great compiler tools in the 90s or so, but in today's internet and FOSS online-collaborative era, how can the Digital Mars toolchain hope to compete with toolchains having teams of multiple full-time developers working on it? (plus a plethora of occasional volunteer contributors). The difference in manpower and resources is astonishing! And it's only gonna get bigger since LLVM is having more and more people and companies supporting it. By this rate, it may well one day make even GCC old and obsolete, left to be used by FSF zealots only. > At the risk of speaking with lack of foresight, are you on the gcc mailing list too? If not, get on it. Otherwise you will enter this kind of polarised view of X will dominate all.
Re: Attempt to get rid of phobos Makefiles, using reggae
On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer wrote: This sounds like a job for CAPTAIN RANGE!!! Seriously though, the thought of using ranges to allow specifying files fits perfectly. Imagine the power! "std/c/windows/".allSubFiles.filter!(a => a.name.extension == ".d"); Need that allSubFiles range, it probably already exists :) https://github.com/atilaneves/reggae/issues/1 :)
Re: [website] Fonts Roboto and Roboto Mono
On Friday, 5 June 2015 at 21:46:05 UTC, Andrei Alexandrescu wrote: Just found these on reddit: https://www.google.com/fonts/specimen/Roboto https://www.google.com/fonts/specimen/Roboto+Mono I'm thinking to use them instead of Verdana and Lucida Mono respectively. Andrei Immediately pleasant on the eyes. You had me at "Grumpy wizards make toxic brew for the evil Queen and Jack." Mike
[website] Fonts Roboto and Roboto Mono
Just found these on reddit: https://www.google.com/fonts/specimen/Roboto https://www.google.com/fonts/specimen/Roboto+Mono I'm thinking to use them instead of Verdana and Lucida Mono respectively. Andrei
Re: rvalue references
I start working on a Pull (https://github.com/D-Programming-Language/dmd/pull/4717), but it fails the first check. The reason seems to be this: https://github.com/D-Programming-Language/dmd/pull/4717/files#diff-ffafa03255a57832dd09031af6cb915dR5945 I guess that this error happens because I cannot distinguish between template and non template auto ref. Does anyone have an idea?
Re: Daily downloads in decline
On Friday, 5 June 2015 at 20:41:39 UTC, Bruno Medeiros wrote: And toolchain always wins. If won't matter if the language is superior. Yes, official support for IOS and Android already in Rust, as far as I know. Toolchain for Rust created MUCH faster than D. D is a very good language, but because of the confrontation turns tolchain not `Rust vs D`, and `Digital Mars vs Mozilla` :) The situation can be dramatically reversed in favor of the D: Digital Mars + Google = Win We need some way to attract a large company to develop toolchain for D. Is it really impossible...
Re: Daily downloads in decline
On 05/06/2015 21:41, Bruno Medeiros wrote: But more importantly: when I finally started looking into Rust, was also what caused me to look into LLVM properly, particularly by subscribing the LLVM weekly newsletter. And that's when I gradually realized all the work LLVM having done, with so many people working on it. Some things I forgot to add: It's not just the amount of resources they have, but also the direction they are going to. In particular, unlike GCC, they are not shying away from Windows and are doing a lot of work to support it natively (not just compiling obviously, but linking with Visual Studio artifacts, and Windows debugging). Once that work matures, I reckon other toolchains will just be left in the dust. (Windows native support is not the only reason LLVM is so promising - but it is the only one I could think of, at the moment, that could be considered a hard blocker for phasing out the DM backend) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: 6-weeks release cycle
On 6/5/15 4:31 PM, Andrei Alexandrescu wrote: On 6/5/15 12:28 PM, David Soria Parra wrote: On Friday, 5 June 2015 at 19:19:33 UTC, Steven Schveighoffer wrote: OK, good, this needs an executive decision. We need a process to be blessed first before we talk about release frequency. Then everything backfills from there. We need a champion to do this and stay with it, not an executive decision. _Then_ everything backfills from there. I wasn't aware the DIP was approved, but I see now that it was. Sorry about that question! -Steve
Re: Daily downloads in decline
On 05/06/2015 20:09, Andrei Alexandrescu wrote: On 6/5/15 12:02 PM, Bruno Medeiros wrote: The traction and support that Rust gained, even before 1.0, showed that having your primary toolchain based on GCC or LLVM is the only sustainable way forward Well I'm wondering how that inference works. -- Andrei Indeed I wasn't clear on that reasoning. It's not the traction that Rust gained that is the *cause* for LLVM "being the only sustainable way forward". Rather, it's simply what showed me that this was the case. Let me be more clear. First when I said "traction and support", I wasn't referring to the Rust user base, but rather the number of *paid* developers[1] that Mozilla has working on the Rust project. Besides the core team, they also seem to be willing to also hire programmers on a contract basis to work one certain aspects of the toolchain (see for example: https://michaelwoerister.github.io/2014/02/28/mozilla-contract.html). But more importantly: when I finally started looking into Rust, was also what caused me to look into LLVM properly, particularly by subscribing the LLVM weekly newsletter. And that's when I gradually realized all the work LLVM having done, with so many people working on it. The recent news that Microsoft is going to work on a LLVM based compiler (http://developers.slashdot.org/story/15/04/14/1529210/microsoft-starts-working-on-an-llvm-based-compiler-for-net), is another sign of this tidal wave we are seeing in the horizon: the future for non-proprietary languages is to be based on LLVM or GCC, or they won't be able to compete. And toolchain always wins. If won't matter if the language is superior. [1]: Note the point here isn't that paid developers are better than volunteer ones, the point they will usually will have more time to work on things than volunteer. The point is about the time and effort they are able to dedicate, not that they are paid per se. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 10:56:36 UTC, ketmar wrote:
p.s. if "auto" is a storage class, the following code should be
accepted
(while it isn't):
int foo () { return 42; }
void main () {
auto auto i = foo();
}
as it's logically "an auto-typed var with "auto" storage class".
Here lies your mistake. There is no such thing as "auto"-typed
(leaving aside function signatures, which might be special-cased
and are different beast altogether). Auto is not a type. auto* or
auto[] aren't valied either. Auto is just a storage class, no
more, no less. You use it if the grammar needs a storage class
but you don't want to give special attributes to the variable
(like const or static). To make a declaration with inferred type
you need at least one storage class. To make it work with
"normal" variables you use "auto".
Re: 6-weeks release cycle
On 6/5/15 12:28 PM, David Soria Parra wrote: On Friday, 5 June 2015 at 19:19:33 UTC, Steven Schveighoffer wrote: On 6/5/15 2:03 PM, Dicebot wrote: Martin was going for http://wiki.dlang.org/DIP75 OK, good, this needs an executive decision. We need a process to be blessed first before we talk about release frequency. Then everything backfills from there. -Steve The important bit is to have someone stand up and build the necessary testing infrastructure. I am to blame for not having done much on this front yet, due to heavy work load. Time base release schedules work fine, no matter how tight, but you require good infrastructure to find regressions and revert if necessary. If people accept that deltas can be very small and that reverts will happen to remove an unstable feature, than a 6-week time based release schedule is fine. In fact I believe there is a lot to gain from it. I agree. To put this in context: OK, good, this needs an executive decision. We need a process to be blessed first before we talk about release frequency. Then everything backfills from there. We need a champion to do this and stay with it, not an executive decision. _Then_ everything backfills from there. Andrei
Re: Daily downloads in decline
On Friday, 5 June 2015 at 19:02:15 UTC, Bruno Medeiros wrote: On 01/06/2015 20:47, weaselcat wrote: at the risk of sounding like a broken record, if ldc/gdc not being 2.067 stops a DDMD release due to dmd's generated code being too slow, maybe it's time to phase dmd out ;) It's past the time. The traction and support that Rust gained, even before 1.0, showed that having your primary toolchain based on GCC or LLVM is the only sustainable way forward (and even of those two, GCC might not be able to keep with LLVM). Nice work on the RustDT IDE btw. (https://users.rust-lang.org/t/rustdt-0-1-0-released-a-new-eclipse-rust-ide)
Re: Daily downloads in decline
On Monday, 1 June 2015 at 18:14:40 UTC, Andrei Alexandrescu wrote: As much as I want it, ddmd seems to not be happening for 2.068 because of, simply put, insufficient resources. Why is that? A first test release does not seem to be further away than, say, full rangeification of Phobos. - David
Getting Started
I am looking at the main page of dlang.org, and really there is no page to warm up a new comer to D language. Sure, there are book links, details of language as "D Reference" etc, but those are not suitable for a new starting guy. Showing the features of language with SIMPLE examples in many pages could be very useful in my opinion. I liked rust's example page: http://rustbyexample.com/hello.html but it is still not for a new comer. Too much writing is there. It should be like "Do those things, and see what value you will see.". Now, as always the question is, "Who is going to prepare those?". We need: 1. A link to example pages on left side of web page. 2. 5 simple examples those are written in separate pages. 3. Give link to each page for next example. By the time, people can contribute to there. When there is no base, nobody is taking any steps.
Re: Attempt to get rid of phobos Makefiles, using reggae
On 6/5/15 4:01 PM, Meta wrote: On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer wrote: This sounds like a job for CAPTAIN RANGE!!! Seriously though, the thought of using ranges to allow specifying files fits perfectly. Imagine the power! "std/c/windows/".allSubFiles.filter!(a => a.name.extension == ".d"); Need that allSubFiles range, it probably already exists :) http://dlang.org/phobos/std_file.html#.dirEntries ? "std/c/windows/".dirEntries(SpanMode.breadth).filter!(/* etc. */); Nice, I was too lazy to look it up :) -Steve
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 03:15:46 UTC, anonymous wrote:
On Friday, 5 June 2015 at 02:38:39 UTC, ketmar wrote:
here's dustmited source:
Further reduced:
void unaryFun()(auto int a) pure nothrow @safe @nogc {}
alias Identity(F) = F;
void main()
{
unaryFun!()(41);
static void fun(int n) pure nothrow @safe @nogc {}
alias F = typeof(fun);
pragma(msg, F); /* ...(int n) */
pragma(msg, Identity!F); /* ...(auto int) */
}
Filed two issues:
https://issues.dlang.org/show_bug.cgi?id=14656
https://issues.dlang.org/show_bug.cgi?id=14657
Re: Attempt to get rid of phobos Makefiles, using reggae
On Friday, 5 June 2015 at 19:17:14 UTC, Steven Schveighoffer wrote: This sounds like a job for CAPTAIN RANGE!!! Seriously though, the thought of using ranges to allow specifying files fits perfectly. Imagine the power! "std/c/windows/".allSubFiles.filter!(a => a.name.extension == ".d"); Need that allSubFiles range, it probably already exists :) -Steve http://dlang.org/phobos/std_file.html#.dirEntries ? "std/c/windows/".dirEntries(SpanMode.breadth).filter!(/* etc. */);
Re: Make dub part of the standard dmd distribution
On 06/05/2015 12:45 PM, Nick Sabalausky wrote: https://github.com/D-Programming-Language/dub/pull/572 Working example: -- $ cd /home/nick/proj/dub $ dub describe --data=main-source-file --data=options \ --data=versions --data=import-paths '/home/nick/proj/dub/source/app.d' -debug -g -w -version=DubUseCurl -version=Have_dub '-I/home/nick/proj/dub/source/' $ dub describe --compiler=ldc --data=options --data=versions -d-debug -g -w -oq -od=.dub/obj -oq -od=.dub/obj -d-version=DubUseCurl -d-version=Have_dub $ dub describe --data-list --data=options --data=versions debugMode debugInfo warningsAsErrors DubUseCurl Have_dub -- It also works even if your project doesn't have a dub.json :) $ mkdir ~/my-proj $ cd ~/my-proj $ dub fetch vibe-d $ dub describe vibe-d --data=versions --data=import-paths -version=VibeLibeventDriver -version=Have_vibe_d -version=Have_libevent -version=Have_openssl '-I/home/nick/.dub/packages/vibe-d-0.7.23-beta.1/source/' '-I/home/nick/.dub/packages/libevent-2.0.1_2.0.16/' '-I/home/nick/.dub/packages/openssl-1.1.4_1.0.1g/'
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 19:45:18 UTC, krzaq wrote: const auto ans = 42; compiles fine for me, so auto clearly can be used as a type. So does "auto immutable" or "auto pure" or "pure a". They're all storage classes and any storage class can kick off a declaration: @nogc a = 10; // compiles! dmd is just not really consistent on when it issues errors on redundant, conflicting, or useless storage classes.
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 19:38:06 UTC, Steven Schveighoffer wrote: On 6/5/15 12:19 PM, Meta wrote: On Friday, 5 June 2015 at 12:32:03 UTC, ketmar wrote: but it does! both with 2.067.1 downloaded from dlang.org and with git HEAD. it may not do what you expect it to do (i don't know what it should do anyway), but dmd happily accepts that code. Hmm, maybe I'm only on 2.070 then. I'll upgrade and see if it still fails to compile. Hello from the future!!! When I use auto int a in a normal function, I get this: Error: auto can only be used for template function parameters But unaryFun()(auto int a) is a template. Perhaps your blocker is for non-templates? -Steve Yes, this is a non-template function that is auto-generated.
Re: 6-weeks release cycle
On 6/5/15 3:19 PM, Steven Schveighoffer wrote: On 6/5/15 2:03 PM, Dicebot wrote: Martin was going for http://wiki.dlang.org/DIP75 OK, good, this needs an executive decision. We need a process to be blessed first before we talk about release frequency. Then everything backfills from there. I re-read this. I think I'd prefer something like this: 1. A bugfix *or* feature release is done every month. 2. A feature release should be planned for every 2 months, but can extend up to 3 months if necessary. Exceptions are allowed to this rule, but only with extenuating circumstances. Just because sometimes features are not really added or ready. I hate to be a slave to the schedule, but we should commit to releasing *something* every month. -Steve
Re: Daily downloads in decline
On Friday, 5 June 2015 at 19:09:46 UTC, Andrei Alexandrescu wrote: On 6/5/15 12:02 PM, Bruno Medeiros wrote: The traction and support that Rust gained, even before 1.0, showed that having your primary toolchain based on GCC or LLVM is the only sustainable way forward Well I'm wondering how that inference works. -- Andrei I have to say i agree with the conclusion, but I'm only puzzled by the reasoning used to come to that conclusion.
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 18:35:51 UTC, Marc Schütz wrote: On Friday, 5 June 2015 at 17:50:55 UTC, ketmar wrote: `const int` works, so i can't see why `auto auto` is failing. Wrong analogy. Try `const const`, and it will fail with the same error as `auto auto`: "redundant attribute". const auto ans = 42; compiles fine for me, so auto clearly can be used as a type.
Re: Make dub part of the standard dmd distribution
On 06/05/2015 02:56 PM, Bruno Medeiros wrote: On 01/06/2015 04:48, Manu via Digitalmars-d wrote: Please declare a standard unix location for D 'includes'. Nobody agrees where in the filesystem D files should be. I use /usr/include/d2/ for my stuff (I saw it precedented a few times before, but it doesn't seem that great), but I want a standard place that stuff bundled by linux package managers can agree on. If you use DUB to build, isn't this transparent anyways? Yes, but dub's buildsystem isn't always suitable for all projects.
Re: Code behaves incorrectly if it is compiled in std.functional
On 6/5/15 12:19 PM, Meta wrote: On Friday, 5 June 2015 at 12:32:03 UTC, ketmar wrote: but it does! both with 2.067.1 downloaded from dlang.org and with git HEAD. it may not do what you expect it to do (i don't know what it should do anyway), but dmd happily accepts that code. Hmm, maybe I'm only on 2.070 then. I'll upgrade and see if it still fails to compile. Hello from the future!!! When I use auto int a in a normal function, I get this: Error: auto can only be used for template function parameters But unaryFun()(auto int a) is a template. Perhaps your blocker is for non-templates? -Steve
Re: 6-weeks release cycle
On Friday, 5 June 2015 at 19:19:33 UTC, Steven Schveighoffer wrote: On 6/5/15 2:03 PM, Dicebot wrote: Martin was going for http://wiki.dlang.org/DIP75 OK, good, this needs an executive decision. We need a process to be blessed first before we talk about release frequency. Then everything backfills from there. -Steve The important bit is to have someone stand up and build the necessary testing infrastructure. I am to blame for not having done much on this front yet, due to heavy work load. Time base release schedules work fine, no matter how tight, but you require good infrastructure to find regressions and revert if necessary. If people accept that deltas can be very small and that reverts will happen to remove an unstable feature, than a 6-week time based release schedule is fine. In fact I believe there is a lot to gain from it.
Re: Lets talk about fibers
On 6/5/15 10:17 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Friday, 5 June 2015 at 13:20:27 UTC, Steven Schveighoffer wrote: I think I'll go with Liran's experience over your hypothetical anecdotes. You seem to have a lot of academic knowledge, but I'd rather see what actually happens. If you have that data, please share. There is absolutely no reason to go personal. I didn't, actually. Your arguments seem well crafted and persuasive, but I've seen so many arguments based on theory that don't always pan out. I like to see hard data. That's what Liran's experience provides. Perhaps you have it too? Please share if you do. -Steve
Re: Attempt to get rid of phobos Makefiles, using reggae
On 6/5/15 11:03 AM, Atila Neves wrote: On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote: On 2015-06-04 23:50, Atila Neves wrote: http://dpaste.dzfl.pl/562f1ddc1aad Reggae doesn't support shell globbing of files? Something like: ExcludeFiles(["std/c/windows/**/*.d"]); Not right now, no. The good thing about how it's designed is you could write your own. Of course, the whole point is to have usable high-level builtins as well. It's a good idea, but like I said before, I hardly ever have to exclude anything in my own projects. Feel free to open an enhancement request. This sounds like a job for CAPTAIN RANGE!!! Seriously though, the thought of using ranges to allow specifying files fits perfectly. Imagine the power! "std/c/windows/".allSubFiles.filter!(a => a.name.extension == ".d"); Need that allSubFiles range, it probably already exists :) -Steve
Re: 6-weeks release cycle
On 6/5/15 2:03 PM, Dicebot wrote: Martin was going for http://wiki.dlang.org/DIP75 OK, good, this needs an executive decision. We need a process to be blessed first before we talk about release frequency. Then everything backfills from there. -Steve
Re: Daily downloads in decline
On 6/5/15 12:02 PM, Bruno Medeiros wrote: The traction and support that Rust gained, even before 1.0, showed that having your primary toolchain based on GCC or LLVM is the only sustainable way forward Well I'm wondering how that inference works. -- Andrei
Re: Daily downloads in decline
On 01/06/2015 20:47, weaselcat wrote: at the risk of sounding like a broken record, if ldc/gdc not being 2.067 stops a DDMD release due to dmd's generated code being too slow, maybe it's time to phase dmd out ;) It's past the time. The traction and support that Rust gained, even before 1.0, showed that having your primary toolchain based on GCC or LLVM is the only sustainable way forward (and even of those two, GCC might not be able to keep with LLVM). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Make dub part of the standard dmd distribution
On 01/06/2015 04:48, Manu via Digitalmars-d wrote: Please declare a standard unix location for D 'includes'. Nobody agrees where in the filesystem D files should be. I use /usr/include/d2/ for my stuff (I saw it precedented a few times before, but it doesn't seem that great), but I want a standard place that stuff bundled by linux package managers can agree on. If you use DUB to build, isn't this transparent anyways? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: dmd makes D appear slow
On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote: [...] >This isn't the first time I've seen this, in basically every benchmark >featuring D I have to submit a patch/make a comment that dmd shouldn't >be used. Make no mistake, this is damaging to D's reputation - how >well does D's "native efficiency" go over when people are saying it's >slower than Scala and F#(mono)? > >LDC and GDC need promoted more. [...] This will probably offend some people, but I think LDC/GDC should be the default download on dlang.org, and dmd should be provided as an alternative for those who want the latest language version and don't mind the speed compromise. It should be more than just LDC/GDC being the default download on dlang.org, the DM backend and related toolchain should be phased out altogether in favor of LLVM. Walter might have written great compiler tools in the 90s or so, but in today's internet and FOSS online-collaborative era, how can the Digital Mars toolchain hope to compete with toolchains having teams of multiple full-time developers working on it? (plus a plethora of occasional volunteer contributors). The difference in manpower and resources is astonishing! And it's only gonna get bigger since LLVM is having more and more people and companies supporting it. By this rate, it may well one day make even GCC old and obsolete, left to be used by FSF zealots only. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 17:50:55 UTC, ketmar wrote: `const int` works, so i can't see why `auto auto` is failing. Wrong analogy. Try `const const`, and it will fail with the same error as `auto auto`: "redundant attribute".
Re: Lets talk about fibers
On Friday, 5 June 2015 at 17:28:39 UTC, Ola Fosheim Grøstad wrote: On Friday, 5 June 2015 at 14:51:05 UTC, Chris wrote: I agree, but I dare doubt that a slight performance edge will make the difference. There are load of factors (knowledge base, infrastructure, complacency, C++-Guruism, marketing etc.) why D is an underdog. But everybody loves the underdog when it catches up to the pack and beats the pack on the finish line. ;^) I now follow Pony because of this self-provided benchmark: http://ponylang.org/benchmarks_all.pdf They are communicating a focus for a domain, a good understanding of their area, and it makes me want to give it a spin even at this early stage where I obviously can't actually use it. I am not saying Pony is good, but it makes a good case for itself IMO. no sugar, thanks." I know, as usual I simplify things and exaggerate! He he he. But programming languages are like everything else, only because something is good doesn't mean that people will buy it. Sure, but it is also important to make people take notice. People take notice of benchmark leaders. And too often benchmarks measure throughput while latency is just as important. End user don't notice peak throughput (which is measurable as a bleep on the cloud server instance-count logs), they notice reduced latency. So to me latency is the most important aspect of a web-service (+ programmer productivity). I don't find Go exciting, but they show concern for latency (concurrent GC etc). Communicating that concern is good, even before they reach whatever goals they have. As regard compiler-based features, as soon as features are compiler-based people will complain "Why is it built-in? That should be handled by a library! I want more freedom!" I know for sure. Heh, not if it is getting you an edge, but if it is a second citizen addition. Yes, then I agree. Cheers! Thanks for showing me Pony. Languages like Nim and Pony keep popping up which shows a) how important native compilation is and b) that there are still loads of issues in standard languages (C/C++/Python/Java/C#). But D is already there, it's already usable, and new languages often re-invent D.
Re: 6-weeks release cycle
On Friday, 5 June 2015 at 14:11:06 UTC, Steven Schveighoffer wrote: On 6/5/15 1:53 AM, Andrei Alexandrescu wrote: Rust will do it: http://opensource.com/business/15/6/rust-6-week-release-cycle Would be so nice if we had the resources to do that. There have been a couple of initiatives in the past, but the folks who wanted to do the release just got busy with other things. I am fine with putting a time limit on adding features, but I'd rather release based on minimized regressions. We have to get better as a group with insisting to use release/stable branches. Do we have a plan written somewhere of how we want to do branching? I know we did some this last release cycle, but I don't remember it being formally written. -Steve Martin was going for http://wiki.dlang.org/DIP75
Re: 6-weeks release cycle
On Friday, 5 June 2015 at 12:21:20 UTC, Dicebot wrote: On Friday, 5 June 2015 at 12:20:06 UTC, Jonathan M Davis wrote: On Friday, 5 June 2015 at 11:09:27 UTC, Dicebot wrote: By the way dub master has been broken with dmd master for ages : https://jenkins.dicebot.lv It usually is, which usually means that I'm forced to install a release version of the compiler just to build dub, since I'm almost always using dmd master. I wish that it were kept up-to-date with dmd master, but I guess that Sonke has enough to do that he doesn't want to put in that effort. - Jonathan M Davis It is a wrong way to put it. dub is part of D-Programming-Language organization now. It must be tested by auto-tester and no pull request that breaks dub should have ever been merged. I don't disagree, but that's the way that it's been historically, and nothing seems to have changed once it got put into the D-Programming-Language organization. Similarly, I don't think that any of the stuff in the tools repo is built as part of the autotester either (e.g. when the change to if(arr) was made recently, dustmite was broken until the change was reverted). So, our approach there is bad. - Jonathan M Davis
Re: Code behaves incorrectly if it is compiled in std.functional
On Fri, 05 Jun 2015 16:42:25 +, Mafi wrote: > On Friday, 5 June 2015 at 16:26:34 UTC, ketmar wrote: >> On Fri, 05 Jun 2015 15:17:50 +, Mafi wrote: >> >>> auto int x = 10; >>> >>> should work. It's just consistent. >> >> then `auto auto` should work too. it's a "declaration mark" + >> "storage class". > > Well, no. Any storage class marks a declaration just by itself. You > don't use it as a "declaration mark" or "storage class", just use a > storage class which definitely declares something new. See also > http://dlang.org/declaration.html > > A declaration is either or > . An AutoDeclaration is the one with type inference. > And it is marked by any storage class, not just auto > (http://dlang.org/declaration.html#AutoDeclaration): AutoDeclarationX>. Well admittently > http://dlang.org/declaration.html#StorageClass does not feature 'auto' > as a storage class but this must be an error because the description of > AutoDeclaration uses 'auto' in the place of StorageClasses. > > It is just about grammar. A declaration needs a type, a storage class or > both to not be mistaken for a statement with an assign expression. You > use the 'auto' storage class so the statement cannot possibly be an > expression when leaving out the type and not using any meaningful > storage class. `const int` works, so i can't see why `auto auto` is failing. signature.asc Description: PGP signature
Re: Lets talk about fibers
On Friday, 5 June 2015 at 15:06:04 UTC, Dmitry Olshansky wrote: You choose to ignore the point about duplicating the same memory in each core's cache. To me it seems like throwing Not sure what you mean by this. 3rd level cache is shared. Die-level cache is shared. Primary caches are small and are shared between pairs of hyper-threaded cores. If a task has been suspended for 100ms you can just assume that primary cache is cold. Adaptive load-balancing is quite possible with fibers sticking to a thread and is a question of application design. Then you should not have fibers at all since an event based solution is even faster (but more work). Coroutines is a convenience feature, not a performance feature. You need control over workload scheduling to optimize to prevent 3rd level cache pollution. Random fine grained scheduling is not good for memory intensive workloads because you push out data from the caches prematurely. I bet it still helps some workloads and hurts others without "me" scheduling anything. Hyperthreading requires two cores to run specific workloads at the same time. If not you are better off just halting that extra core. The idea with hyperthreading is that one thread fills in holes in the pipeline when the other thread is stalled. Not sure if this is English, When people pick on typos the debate is essentially over... EOD
Re: Lets talk about fibers
On Friday, 5 June 2015 at 15:18:59 UTC, Dan Olson wrote: On TLS and migrating Fibers - these were posted elsewhere, and want to make sure that when you read TLS Fiber problem here, it is understood to be something that could be solved by compiler solution. What I meant is that I don't have a use case for TLS in my own programs. I think TLS is primarily useful for runtime-level issues like thread local allocators. I either read from global immutables or use lock-free datastructures for sharing...
Re: Lets talk about fibers
On Friday, 5 June 2015 at 14:51:05 UTC, Chris wrote: I agree, but I dare doubt that a slight performance edge will make the difference. There are load of factors (knowledge base, infrastructure, complacency, C++-Guruism, marketing etc.) why D is an underdog. But everybody loves the underdog when it catches up to the pack and beats the pack on the finish line. ;^) I now follow Pony because of this self-provided benchmark: http://ponylang.org/benchmarks_all.pdf They are communicating a focus for a domain, a good understanding of their area, and it makes me want to give it a spin even at this early stage where I obviously can't actually use it. I am not saying Pony is good, but it makes a good case for itself IMO. no sugar, thanks." I know, as usual I simplify things and exaggerate! He he he. But programming languages are like everything else, only because something is good doesn't mean that people will buy it. Sure, but it is also important to make people take notice. People take notice of benchmark leaders. And too often benchmarks measure throughput while latency is just as important. End user don't notice peak throughput (which is measurable as a bleep on the cloud server instance-count logs), they notice reduced latency. So to me latency is the most important aspect of a web-service (+ programmer productivity). I don't find Go exciting, but they show concern for latency (concurrent GC etc). Communicating that concern is good, even before they reach whatever goals they have. As regard compiler-based features, as soon as features are compiler-based people will complain "Why is it built-in? That should be handled by a library! I want more freedom!" I know for sure. Heh, not if it is getting you an edge, but if it is a second citizen addition. Yes, then I agree. Cheers!
Re: User defined statements for D like seed have?
http://seed7.sourceforge.net/index.htm seed7 is also a compiler! and i use it, after comming from D, with great pleasure. On Wednesday, 7 March 2007 at 22:02:00 UTC, dennis luehring wrote: example how a for statement is declared http://seed7.sourceforge.net/examples/declstat.htm ok i know that seed is an interpreter language but maybe there is a way walter can allow something like this for his buildin statements or even better the case statement http://seed7.sourceforge.net/manual/stats.htm#case-statement as a statement-template wich can produce (with the help of the awaited static foreach) a nice objectfactory from a tuple or something like this ciao denni
Re: Make dub part of the standard dmd distribution
On 06/01/2015 02:20 AM, Nick Sabalausky wrote: On 05/31/2015 11:48 PM, Manu via Digitalmars-d wrote: As for dub, I'd use it if it worked like a package manager; dub get libcurl-d libqt-d zlib-d libsdl2-d etc I have no use for it as a build system, and therefore it's expression of dependencies is no use to me. I just want something that works the same way as '-dev' packages already work perfectly well in linux, that is, they fetch headers and libs, and put them in a standard location that all the tooling can find. Ditto. Dub's great if you let it be your buildsystem, but as soon as you want to use it as a package-manager-only it becomes an uphill battle with dub fighting back every step of the way (I speak from experience). That problem is worse if your project is a library that you want fetchable through dub. That's why I've been working on some PRs to fix all that. The first step is here (building/expanding on a flag another contributer recently added): https://github.com/D-Programming-Language/dub/pull/572 (Although I think I may need to change --data=libs and separate system libs from dependency libs since linkers expect those to be passed in differently.) The next step will be to add a flag to have that data get output in a compiler-ready argument list (your choice of compiler, of course). That'll let you do something comparable to "pkg-config --cflags --libs". All the above is now included in the PR: https://github.com/D-Programming-Language/dub/pull/572 Working example: -- $ cd /home/nick/proj/dub $ dub describe --data=main-source-file --data=options \ --data=versions --data=import-paths '/home/nick/proj/dub/source/app.d' -debug -g -w -version=DubUseCurl -version=Have_dub '-I/home/nick/proj/dub/source/' $ dub describe --compiler=ldc --data=options --data=versions -d-debug -g -w -oq -od=.dub/obj -oq -od=.dub/obj -d-version=DubUseCurl -d-version=Have_dub $ dub describe --data-list --data=options --data=versions debugMode debugInfo warningsAsErrors DubUseCurl Have_dub -- Of course, "dub describe --help" for the full list of options. Only thing not included yet is this: Then finally, a shortcut flag so you can just do something kinda like: rdmd --build-only `dub describe --cmdargs=rdmd` src/main.d And all your dependencies will be properly referenced (-I..., linker flags, etc).
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 16:26:34 UTC, ketmar wrote: On Fri, 05 Jun 2015 15:17:50 +, Mafi wrote: auto int x = 10; should work. It's just consistent. then `auto auto` should work too. it's a "declaration mark" + "storage class". Well, no. Any storage class marks a declaration just by itself. You don't use it as a "declaration mark" or "storage class", just use a storage class which definitely declares something new. See also http://dlang.org/declaration.html A declaration is either Declarators> or . An AutoDeclaration is the one with type inference. And it is marked by any storage class, not just auto (http://dlang.org/declaration.html#AutoDeclaration): . Well admittently http://dlang.org/declaration.html#StorageClass does not feature 'auto' as a storage class but this must be an error because the description of AutoDeclaration uses 'auto' in the place of StorageClasses. It is just about grammar. A declaration needs a type, a storage class or both to not be mistaken for a statement with an assign expression. You use the 'auto' storage class so the statement cannot possibly be an expression when leaving out the type and not using any meaningful storage class.
Re: Code behaves incorrectly if it is compiled in std.functional
On Fri, 05 Jun 2015 15:17:50 +, Mafi wrote: > auto int x = 10; > > should work. It's just consistent. then `auto auto` should work too. it's a "declaration mark" + "storage class". signature.asc Description: PGP signature
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 12:32:03 UTC, ketmar wrote: but it does! both with 2.067.1 downloaded from dlang.org and with git HEAD. it may not do what you expect it to do (i don't know what it should do anyway), but dmd happily accepts that code. Hmm, maybe I'm only on 2.070 then. I'll upgrade and see if it still fails to compile.
Scaling rdmd up: build package at a time
This is a self-contained and really fun project: https://issues.dlang.org/show_bug.cgi?id=14654 It requires an understanding of how rdmd currently works (<1KLOC in a single module!) and is of huge impact. Who'd want to get into it? I would if I didn't already have std.allocator to have fun with. (Speaking of which: regions that grow upwards or downwards depending on stack growth direction for cache hotness, yum! http://erdani.com/d/phobos-prerelease/std_experimental_allocator_region.html) Andrei
Re: What's the deal with http://dconf.org/2015/talks/zvibel.pdf?
On 6/5/15 4:11 AM, Vladimir Panteleev wrote: On Friday, 5 June 2015 at 08:36:54 UTC, Jonathan M Davis wrote: It works fine for me too, though glancing around online about file permissions in github, I'm seeing really mixed messages on what happens with them. So, maybe there's some github-specific weirdness. Why is this? AFAIK Git only allows 644 and 755 permissions for files (i.e. executable or not). I doubt Git is to blame here. rsync is in the mix as well. Anyhow, for now (after I deleted and rsync'ed it again) the file seems to have stayed readable. -- Andrei
Re: Code behaves incorrectly if it is compiled in std.functional
On Friday, 5 June 2015 at 12:33:35 UTC, ketmar wrote: On Fri, 05 Jun 2015 11:53:29 +, Marc Schütz wrote: My understanding is that `auto` is just C legacy, and originally had the same meaning as in C. But apparently the language has moved away from that over time. i agree, i think it was a keyword used 'cause it was already used in C. but it's meaning is completely redefined in D. AFAIK auto is a stotage class (like in C). It is the no-op storage and therefore does not not change the stotage or type etc. But in a statement it definitely marks as a declaration because only those can contain storage classes. In D any declaration can omit the type so let it be inferred. That's why this also works: const x = 10; static y = 20; enum z = 30; Auto is only needed to unambigiously mark a statement as declaration when the lack of type would make it look like an ExpressionStatement. But still auto int x = 10; should work. It's just consistent.
Re: Lets talk about fibers
"Ola Fosheim "Grøstad\"" writes: > No, there were no performance related reasons, only TLS (which is a > questionable feature to begin with). On TLS and migrating Fibers - these were posted elsewhere, and want to make sure that when you read TLS Fiber problem here, it is understood to be something that could be solved by compiler solution. David has a good overview of the problem here: https://github.com/ldc-developers/ldc/issues/666 And Boost discussion to show D is not alone here: http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thread.html
Re: Lets talk about fibers
On 05-Jun-2015 17:04, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Friday, 5 June 2015 at 13:44:16 UTC, Dmitry Olshansky wrote: If there is affinity and we assume that OS schedules threads on the same cores* then each core has it's cache loaded with (some of) stacks of its fibers. If we assume sharing fibers across all cores, then each core will have to cache stacks for all of fibers which is wasteful. If you cannot control affinity then you can't take advantage of hyper-threading either? You choose to ignore the point about duplicating the same memory in each core's cache. To me it seems like throwing random CPU technologies won't help make your argument stronger. However I stand corrected - there are sys-calls to confine thread to specifics subset of cores. The point about cache stays as is as it assumed each thread prefers to run the same core vs e.g. always running on the same core. I need to think of this in terms of _smart_ scheduling and adaptive load balancing. Can't help you there, especially w/o definition of the first. Adaptive load-balancing is quite possible with fibers sticking to a thread and is a question of application design. Moving fibers across threads have no effect on all of the above even if there is some truth. In order to get benefits from hyper-threading you need pay close attention how you schedule, or you should turn it off. I bet it still helps some workloads and hurts others without "me" scheduling anything. There are some things OS can do just fine. There is simply no way to control what core executes which thread to begin with, this assignment is the OS territory. If your OS is does not support hyper-threading level control you should turn it off... Not sure if this is English, but I stand corrected in that one may set thread affinity for each thread manually. What I argued for is that default is mostly the same and the point stands as is. The only good reason for not switching is that you lack resources/know-how. Reasons were presented, but there is nothing in your answer that at least acknowledges that. No, there were no performance related reasons, I haven't said performance. Fast and incorrect is cheap. only TLS (which is a questionable feature to begin with). Aye, no implicit data-races by default is questionable design. What questions do you have? -- Dmitry Olshansky
Re: Attempt to get rid of phobos Makefiles, using reggae
On Friday, 5 June 2015 at 09:22:14 UTC, Jacob Carlborg wrote: On 2015-06-04 23:50, Atila Neves wrote: http://dpaste.dzfl.pl/562f1ddc1aad Reggae doesn't support shell globbing of files? Something like: ExcludeFiles(["std/c/windows/**/*.d"]); Not right now, no. The good thing about how it's designed is you could write your own. Of course, the whole point is to have usable high-level builtins as well. It's a good idea, but like I said before, I hardly ever have to exclude anything in my own projects. Feel free to open an enhancement request. Or just specifying a directory. I think somebody else mentioned that already. BTW, why are some Linux specific files ignored? No clue, I just went with the output of `make -f posix.mak`. It's the kind of thing that'd be more explicit if the build description were in D. It was one of my questions in the original post ;) Atila
Re: Working on new binary serialization module for phobos (hopefully)
I hope you can get the third review process done because Phobos needs serialization and it would be much better to use tried and tested code like orange rather than something I've pulled together over a couple of weeks Does phobos really _need_ it? It'd be nice, sure, but given there's more than one option available on dub right now I don't think it's a massive deal. Atila
Re: Working on new binary serialization module for phobos (hopefully)
Cerealed has more features than this as well. I'd struggle to write code as short as I did when using it to implement networking protocols. I also only encoded bytes as big-endian since binary serialization is usually followed by sending those bytes over the wire. Given you check the endianess of the system here, how would that work? I don't know what you mean bytes by themselves don't have an endianness, do they? I thought is was only anything that was larger than a byte had endianness Yes. And sometimes mixed endianess depending on the architecture. I might be wrong, but it seems to me that it'd be hard to send the bytes over the wire with this. Atila
Re: Lets talk about fibers
On Friday, 5 June 2015 at 14:17:35 UTC, Ola Fosheim Grøstad wrote: On Friday, 5 June 2015 at 13:20:27 UTC, Steven Schveighoffer wrote: I think I'll go with Liran's experience over your hypothetical anecdotes. You seem to have a lot of academic knowledge, but I'd rather see what actually happens. If you have that data, please share. There is absolutely no reason to go personal. I address weak arguments when I see them. Liran claimed there were no benefits to migrating fibers. That's not true. He is speaking for his particular use case, that is fine. It is easy to create a benchmark where locking fibers to a thread is beneficial. But it is completely orthogonal to my most likely D use case which is in low-latency web-services. There will be no data that benefits D until D is a making itself look like a serious contender and do it well in aggressive external benchmarking. You don't get the luxury to choose what workload D's performance is benchmarked with! D is an underdog compared to C++/Rust/Go. That means you need to get that 10-20% performance edge in benchmarks to make D look attractive. I agree, but I dare doubt that a slight performance edge will make the difference. There are load of factors (knowledge base, infrastructure, complacency, C++-Guruism, marketing etc.) why D is an underdog. If you want D to succeed you need to figure out what is D's main selling point and make it a compiler-based feature. If it is a library only solution, then any language can steal your thunder... The "problem" D has is that it has loads of selling points. Rust and Go were designed with very specific goals in mind, thus it's easy to sell them "You want X? We have X!". D has been developed over the years by a community not a committee. D is more like "You want X? Yeah, we have X, actually a slightly improved version of X we call it EX, and Y and Z on top of that. And A B C too! And templates!" - "Sorry, man! Too complicated for me! Can I just have a for-loop, please? Milk, no sugar, thanks." I know, as usual I simplify things and exaggerate! He he he. But programming languages are like everything else, only because something is good doesn't mean that people will buy it. As regard compiler-based features, as soon as features are compiler-based people will complain "Why is it built-in? That should be handled by a library! I want more freedom!" I know for sure.
Re: 6-weeks release cycle
On Friday, 5 June 2015 at 14:11:06 UTC, Steven Schveighoffer wrote: On 6/5/15 1:53 AM, Andrei Alexandrescu wrote: Rust will do it: http://opensource.com/business/15/6/rust-6-week-release-cycle Would be so nice if we had the resources to do that. There have been a couple of initiatives in the past, but the folks who wanted to do the release just got busy with other things. I am fine with putting a time limit on adding features, but I'd rather release based on minimized regressions. We have to get better as a group with insisting to use release/stable branches. Do we have a plan written somewhere of how we want to do branching? I know we did some this last release cycle, but I don't remember it being formally written. -Steve I agree that releases could sometimes be more frequent. However, to release for the sake of releasing is not a good idea, in my opinion (that is based on bad experience). Maybe Rust will do it, because they still have so much stuff to fix, dunno. D is more mature and fixes/improvements have to be pondered on and tested thoroughly. High quality releases you can rely on are more important than frequent releases. I use Manjaro Linux (ArchLinux based) at home and I appreciate their efforts to test things thoroughly before passing possibly buggy things on to users. If certain bug fixes are a priority for a given project, I'd recommend offering nightly (or weekly) builds with a well-documented change log.
Re: Lets talk about fibers
On Friday, 5 June 2015 at 13:20:27 UTC, Steven Schveighoffer wrote: I think I'll go with Liran's experience over your hypothetical anecdotes. You seem to have a lot of academic knowledge, but I'd rather see what actually happens. If you have that data, please share. There is absolutely no reason to go personal. I address weak arguments when I see them. Liran claimed there were no benefits to migrating fibers. That's not true. He is speaking for his particular use case, that is fine. It is easy to create a benchmark where locking fibers to a thread is beneficial. But it is completely orthogonal to my most likely D use case which is in low-latency web-services. There will be no data that benefits D until D is a making itself look like a serious contender and do it well in aggressive external benchmarking. You don't get the luxury to choose what workload D's performance is benchmarked with! D is an underdog compared to C++/Rust/Go. That means you need to get that 10-20% performance edge in benchmarks to make D look attractive. If you want D to succeed you need to figure out what is D's main selling point and make it a compiler-based feature. If it is a library only solution, then any language can steal your thunder...
Re: 6-weeks release cycle
On 6/5/15 1:53 AM, Andrei Alexandrescu wrote: Rust will do it: http://opensource.com/business/15/6/rust-6-week-release-cycle Would be so nice if we had the resources to do that. There have been a couple of initiatives in the past, but the folks who wanted to do the release just got busy with other things. I am fine with putting a time limit on adding features, but I'd rather release based on minimized regressions. We have to get better as a group with insisting to use release/stable branches. Do we have a plan written somewhere of how we want to do branching? I know we did some this last release cycle, but I don't remember it being formally written. -Steve
Re: 6-weeks release cycle
On 2015-06-05 08:10, Dicebot wrote: Picking random commit and calling it a version is not really "releasing". For me release implies strict regression testing and nice changelog at the very least. Very good point. -- /Jacob Carlborg
Re: Lets talk about fibers
On Friday, 5 June 2015 at 13:44:16 UTC, Dmitry Olshansky wrote: If there is affinity and we assume that OS schedules threads on the same cores* then each core has it's cache loaded with (some of) stacks of its fibers. If we assume sharing fibers across all cores, then each core will have to cache stacks for all of fibers which is wasteful. If you cannot control affinity then you can't take advantage of hyper-threading either? I need to think of this in terms of _smart_ scheduling and adaptive load balancing. Moving fibers across threads have no effect on all of the above even if there is some truth. In order to get benefits from hyper-threading you need pay close attention how you schedule, or you should turn it off. There is simply no way to control what core executes which thread to begin with, this assignment is the OS territory. If your OS is does not support hyper-threading level control you should turn it off... The only good reason for not switching is that you lack resources/know-how. Reasons were presented, but there is nothing in your answer that at least acknowledges that. No, there were no performance related reasons, only TLS (which is a questionable feature to begin with). Then it's a good chance for you to prove your design by experimentation. That if we all accept concurrency issues with moving fibers that violate some language guarantees. There is nothing to prove. You either perform worse or better than a carefully scheduled event-based solution in C++. You either perform worse or better than Go 1.5 in scheduling and GC. However, doing well in externally designed and executed benchmarks on _language_ _features_ is good marketing (even if that 10-20% edge does not matter in real world applications). Right now, neither concurrency or GC are really D language features, they are more like library/runtime features. That makes it difficult to excel in those areas. In languages like Go, Erlang and Pony concurrency is a language feature.
Re: What's the deal with http://dconf.org/2015/talks/zvibel.pdf?
On Friday, 5 June 2015 at 01:12:25 UTC, Andrei Alexandrescu wrote: So this is the sixth time or so I change permissions for http://dconf.org/2015/talks/zvibel.pdf manually. I make it world-readable, someone within a matter of hours it becomes world-unreadable. Attributes and owner are fine on my github dir. We use rsync. Does any other contributor update dconf.org and has the wrong attributes? Could there be something more odd at work? Andrei Works for me. A few things from the slide: "Developing in D for over a year: Getting a huge productivity boost" I second that. With D programming is not just a chore, it actually makes you want to do things. It's not the same for-loop all over again ;) "We have a lot of library/utility functions we can donate" Please do. Input/code/findings from people who use D in real life scenarios is priceless.
Re: Lets talk about fibers
On 05-Jun-2015 14:29, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Thursday, 4 June 2015 at 22:28:52 UTC, Jonathan M Davis wrote: anyone give a reason why we need to. deadalnix talked about load balancing that way, but you gave good reasons as to why that didn't make sense, What good reasons? By the time you get response from your shared memcache or database the x86 cache level 1 and possibly 2 is cold. Cache arguments are hard to get right w/o experiment. That "possibly" may be enough compared to certainly cold. However I'll answer theoretically to equally theoretical argument. If there is affinity and we assume that OS schedules threads on the same cores* then each core has it's cache loaded with (some of) stacks of its fibers. If we assume sharing fibers across all cores, then each core will have to cache stacks for all of fibers which is wasteful. So fiber affinity => that much less burden on each of core's caches, making them that much hotter. * You seem to assume the same. Fine assumption given that OS usually tries to keep the same cores working on the same threads, for the similar reasons I believe. Add to this that two-and-two cores share primary caches so if you don't pair tasks that address the same memory you loose up to 10-20% performance in addition to unused capacity and increased latency. Smart scheduling matters, both at the OS level and at the application level. That's not a controversial statement (only in these forums…)! Moving fibers across threads have no effect on all of the above even if there is some truth. There is simply no way to control what core executes which thread to begin with, this assignment is the OS territory. The only good reason for not switching is that you lack resources/know-how. Reasons were presented, but there is nothing in your answer that at least acknowledges that. But then you probably should not make it a language feature in the first place...? Then it's a good chance for you to prove your design by experimentation. That if we all accept concurrency issues with moving fibers that violate some language guarantees. -- Dmitry Olshansky
Re: Working on new binary serialization module for phobos (hopefully)
On Friday, 5 June 2015 at 13:05:55 UTC, Sean Campbell wrote: On Friday, 5 June 2015 at 12:53:45 UTC, Basile Burg wrote: On Friday, 5 June 2015 at 12:21:19 UTC, Sean Campbell wrote: [...] No, you don't get my point with setters: if a during the deserialization you restore, let's say, the _width field and that 12 children controls rely on this field then they won't be aware of the change. But if the deserializer restores using the width(int value) setter, the children can be resized if the the setter contain a sub method like updateChildren()... just add @customSerialized to _width and make deserialize_width call updateChildren() or whatever thank you, it's good to know.
Re: Lets talk about fibers
On 6/5/15 7:29 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Thursday, 4 June 2015 at 22:28:52 UTC, Jonathan M Davis wrote: anyone give a reason why we need to. deadalnix talked about load balancing that way, but you gave good reasons as to why that didn't make sense, What good reasons? By the time you get response from your shared memcache or database the x86 cache level 1 and possibly 2 is cold. And cache level 3 is shared, so there is no cache penalty for switching cores. Add to this that two-and-two cores share primary caches so if you don't pair tasks that address the same memory you loose up to 10-20% performance in addition to unused capacity and increased latency. I think I'll go with Liran's experience over your hypothetical anecdotes. You seem to have a lot of academic knowledge, but I'd rather see what actually happens. If you have that data, please share. -Steve
Re: Make dub part of the standard dmd distribution
On 6/5/15 5:07 AM, Jacob Carlborg wrote: On 2015-06-04 19:44, Steven Schveighoffer wrote: The use case I'm thinking of is basically: import somepackage.somemodule; ... compile -> can't find somepackage.somemodule. did you mean somepackage.somemodule from libgeneric on code.dlang.org? (url) to add: dub depend add libgeneric dub depend add libgeneric => found it, added it, added dependency I don't have to look up anything on code.dlang.org, I don't have to do anything, dub figures it all out from the description file online. Sounds like a nice feature but how would that work in practice? I mean, there's nothing that connects a particular D module or package to a particular Dub package. The source of the package does. code.dlang.org can create this automatically. -Steve
Re: Working on new binary serialization module for phobos (hopefully)
On Friday, 5 June 2015 at 12:53:45 UTC, Basile Burg wrote: On Friday, 5 June 2015 at 12:21:19 UTC, Sean Campbell wrote: On Tuesday, 2 June 2015 at 10:32:25 UTC, Basile Burg wrote: [...] using property setters and getters doesn't seem like the best idea as they may either: they are used to get live data e.g. setter calls hashing function for an object that isn't part of the class/struct property may only have setter or getter not both. but in case you need to store anything that __traits() can find I added support for custom serialized fields and types. just annotate a type with @customSerialized and define the static methods serialize[membername] and deserialize[membername] where [membername] is the name of the field or have full custom serialization by defining the static methods serializeThis and deserializeThis. [...] thank you, it's good to know [...] No, you don't get my point with setters: if a during the deserialization you restore, let's say, the _width field and that 12 children controls rely on this field then they won't be aware of the change. But if the deserializer restores using the width(int value) setter, the children can be resized if the the setter contain a sub method like updateChildren()... just add @customSerialized to _width and make deserialize_width call updateChildren() or whatever
