Re: Template currying
On Friday, 6 May 2016 at 00:08:01 UTC, Yuxuan Shui wrote: On Thursday, 5 May 2016 at 23:46:59 UTC, Ed wrote: On Thursday, 5 May 2016 at 23:33:07 UTC, Yuxuan Shui wrote: It'd really nice if this just works, That's clear that you've never been stuck in the fat mud of imperative and OO programming styles. You don't realize (anymore ?) how lucky we are with D templates, compared to other languages! Maybe you come from C++, so that's not so obvious for you but with my background I'm still amused when I see people complaining about such details. ^^ Yes, I do appreciate the power of D, I just want it to be BETTER. Anyway, you can open a enhancement request and pray... I'll do that, but I just want to see some feedback on this idea Sorry, I don't know why I thought this thread was on d.learn, I didn't get this was a general discussion.
Re: Template currying
On Thursday, 5 May 2016 at 23:33:07 UTC, Yuxuan Shui wrote: It'd really nice if this just works, That's clear that you've never been stuck in the fat mud of imperative and OO programming styles. You don't realize (anymore ?) how lucky we are with D templates, compared to other languages! Maybe you come from C++, so that's not so obvious for you but with my background I'm still amused when I see people complaining about such details. ^^ Anyway, you can open a enhancement request and pray...
Re: Template currying
On Thursday, 5 May 2016 at 23:19:59 UTC, Yuxuan Shui wrote:
On Thursday, 5 May 2016 at 23:12:40 UTC, Ed wrote:
On Thursday, 5 May 2016 at 22:53:01 UTC, Yuxuan Shui wrote:
On Thursday, 5 May 2016 at 21:54:29 UTC, Ed wrote:
On Thursday, 5 May 2016 at 20:17:08 UTC, Yuxuan Shui wrote:
[...]
It's hard to help without a minimal working example (maybe
something with just the body).
If you mean that "alias new_parser = Comb!(a, b);" generates
an error maybe that's because the correct syntax is "alias
new_parser(Range) = Comb!(a, b);" ?
One issue you may encounter is that template parameter
deduction (that's called IFTI I think) can fail with an
alias (so partially specialized template/templatized
function, etc).
Simple example:
int a(int b, T)(T c){return 0;}
It's fine to:
a!1(2);
But:
alias A = a!1;
Would fail.
alias aa(T) = a!(1,T);
aa!ubyte(2);
Your alias declaration is not correct.
As you can see in my first post, I know how to make this work.
I just think it'd be nice if compiler can do this automatically.
Anothor point is that, what if I want to use partially
instantiated templates as template arguments?
My bad, I didn't read carefully "or not use alias:".
With alias template parameter you can pass template:
--
import std.stdio;
template Foo(T,U){ T pop(){return T.max;}}
alias Partial(U) = Foo!(U, string);
auto bar(alias Whatever)()
{
alias instance = Whatever!int;
return instance.pop;
}
void main(string[] args)
{
writeln(bar!(Partial)());
}
--
for example.
Re: Template currying
On Thursday, 5 May 2016 at 22:53:01 UTC, Yuxuan Shui wrote:
On Thursday, 5 May 2016 at 21:54:29 UTC, Ed wrote:
On Thursday, 5 May 2016 at 20:17:08 UTC, Yuxuan Shui wrote:
[...]
It's hard to help without a minimal working example (maybe
something with just the body).
If you mean that "alias new_parser = Comb!(a, b);" generates
an error maybe that's because the correct syntax is "alias
new_parser(Range) = Comb!(a, b);" ?
One issue you may encounter is that template parameter
deduction (that's called IFTI I think) can fail with an alias
(so partially specialized template/templatized function, etc).
Simple example:
int a(int b, T)(T c){return 0;}
It's fine to:
a!1(2);
But:
alias A = a!1;
Would fail.
alias aa(T) = a!(1,T);
aa!ubyte(2);
Your alias declaration is not correct.
Re: Template currying
On Thursday, 5 May 2016 at 20:17:08 UTC, Yuxuan Shui wrote:
So I was working on a parser combinator library, where the
combinators take parsers as template argument. It works well
until recently I decided to change the parsers so they would
take Ranges instead of just strings.
The combinator used to look like:
template Comb(alias parser1, alias parser2)
Now it looks like
template Comb(alias parser1, alias parser2, Range)
And I want to have the compile deduce the Range template
arguments, so I don't need to change the code that uses them.
But I found out it's hard to partially instantiate templates.
It's OK to do that at the call site, e.g. Comb!(a, b)(range)
works without specifying the Range. But sometimes I want to
alias the result parser so I can use it at multiple places, but
alias new_parser = Comb!(a, b);
doesn't work.
I need either to define Comb differently:
template Comb(alias p1, alias p2) {
template Comb(Range) {
or not use alias:
template new_parser(alias p1, alias p2){
alias new_parser(Range) = Comb!(p1, p2, Range);
//Something like this, not tested
}
I think it would be really nice if alias can be automatically
translated to the latter one. Or maybe we can have something
like
template Curry(alias tmpl, Args1...) {
alias Curry(Args2...) = tmpl!(Args1~Args2); //Pseudocode
}
in the phobos.
It's hard to help without a minimal working example (maybe
something with just the body).
If you mean that "alias new_parser = Comb!(a, b);" generates an
error maybe that's because the correct syntax is "alias
new_parser(Range) = Comb!(a, b);" ?
One issue you may encounter is that template parameter deduction
(that's called IFTI I think) can fail with an alias (so partially
specialized template/templatized function, etc).
Re: Inheritance of mixin
On Saturday, 30 April 2016 at 01:06:18 UTC, Andrew Benton wrote: On Friday, 29 April 2016 at 19:11:24 UTC, tsbockman wrote: Rare as in, "effecting only a very small amount of real world code" - not as in "effecting only a very small number of people". [...] Additionally, any libraries that provide a base class with a mixin require inheritors to know about that mixin and provide it in their own code. [...] It looks like you miss the solution proposed above, using a template this parameter. It's very clear and consise ! Actually the mixin is even not necessary.
Re: GSoC 2016 - A replacement of std.xml for the Phobos standard library
On Saturday, 23 April 2016 at 08:30:32 UTC, Lodovico Giaretta wrote: This is my first experience at GSoC and also my first collaboration with a big open source project, so if you have any suggestion about my proposal or my early implementation, feel free to tell me. Thank you very much to everybody. Lodovico Giaretta Your D style is 90% Phobos compatible. There are few details you need to fix before writing more: you tend to forget the space after "if", "foreach" and "while". You'll see that actually this space makes the things more beautiful because the identifier used after the opening parenthesis and the first identifier used after the indentation are aligned. if (wellAligned) wellAligned++; You can fix existing work with Dfmt if you dont want to process manually.
Re: Optimizing Java using D
On Thursday, 3 July 2014 at 07:29:42 UTC, Wanderer wrote: Nobody, never, measures sort algorithms by amount of swaps. What if you're sorting a large database with large records?
Re: Worrying attitudes to the branding of the D language
On Wednesday, 2 July 2014 at 03:15:20 UTC, Nick Sabalausky wrote: On 7/1/2014 5:15 PM, Gary Willoughby wrote: On Tuesday, 1 July 2014 at 19:50:15 UTC, David Nadlinger wrote: Care to share any work samples/your la(te)st portfolio? David In the past i worked on purely traditional packaging so everything you saw in the supermarkets i had a hand in. Food, clothing, magazines, etc. Now i've moved into software. Here's my current employers and our public client list: http://www.9xb.com/digital-agency/client-list/ Believe me branding is everything do not take this stuff so lightly. I do easily believe that such companies are convinced branding is everything (although, as I'm sure you well know, "branding" encompasses far, far more than whether or not a logo gets modified), but I'm unconvinced that such beliefs, while certainly prevalent, are actually valid. Keep in mind, too, a lot of those brands are mass-market brands aimed at everyday "Average Joes". The thing is, a LOT of Average Joes are SEVERELY stupid and easily swayed by nonsensical reasons. D isn't a mass-market brand, it's a programmer brand. Still some dumb people in programming of course, but not to the extent of, for example, Pepsi's overall target market. But that said, I think we have far better things to do (even within the site redesign) than waste time debating and rejiggering the logo to hop onboard silicon valley's "*this* week, tech stylings should be *flat*" train. Seriously, mark my words: Within a few months after Android "L" drops (thus unifying the last major brand under the "flat" bandwagon), somebody in Apple, MS, or other west-coast-US firm is going to make yet another "now it must be all rounded/gradients/shading" push, and for about the tenth time (that I can remember) the whole damn industry will switch right back to what we had a couple years ago (*cough* Win3), and "flat" (*cough* Win2/Win95) will become "passe" and "old fashioned" for the umpteenth time. Then we'll have to hop onboard that shit too. Just pick a logo and leave it. Leave the neverending "sharp vs round"/"flat vs shaded" bullcrap for Silicon Valley to continue jerking themselves into red ink with. +1 Maybe it's just me but quite frankly I don't care what the logo or web site looks like as long as I can read content and navigate the links easily. bye, uri
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 07:21:00 UTC, Don wrote: On Monday, 30 June 2014 at 04:15:46 UTC, Walter Bright wrote: On 6/29/2014 8:22 PM, Manu via Digitalmars-d wrote: Well, here's the thing then. Consider that 'real' is only actually supported on only a single (long deprecated!) architecture. In x64's case, it is deprecated for over a decade now, and may be removed from the hardware at some unknown time. The moment that x64 processors decide to stop supporting 32bit code, the x87 will go away, and those opcodes will likely be emulated or microcoded. Interacting real<->float/double means register swapping through memory. It should be treated the same as float<->simd; they are distinct (on most arch's). Since they are part of the 64 bit C ABI, that would seem to be in the category of "nevah hoppen". What I think is highly likely is that it will only have legacy support, with such awful performance that it never makes sense to use them. For example, the speed of 80-bit and 64-bit calculations in x87 used to be identical. But on recent Intel CPUs, the 80-bit operations run at half the speed of the 64 bit operations. They are already partially microcoded. For me, a stronger argument is that you can get *higher* precision using doubles, in many cases. The reason is that FMA gives you an intermediate value with 128 bits of precision; it's available in SIMD but not on x87. So, if we want to use the highest precision supported by the hardware, that does *not* mean we should always use 80 bits. I've experienced this in CTFE, where the calculations are currently done in 80 bits, I've seen cases where the 64-bit runtime results were more accurate, because of those 128 bit FMA temporaries. 80 bits are not enough!! This is correct and we use this now for some time critical code that requires high precision. But anything non-time critical (~80%-85% of our code) we simply use a software solution when precision becomes an issue. It is here that I think the extra bits in D real can be enough to get a performance gain. But I won't argue with you think I'm wrong. I'm only basing this on anecdotal evidence of what I saw from 5-6 apps ported from C++ to D :-) Cheers, ed
Re: std.math performance (SSE vs. real)
On Monday, 30 June 2014 at 06:21:49 UTC, Walter Bright wrote: When precision is an issue we always choose a software solution. This has been my experience in both geophysics and medical device development. It is cheaper, faster (dev. time), and better tested than anything we would develop within a release time frame. But D "real" is a winner IMO. At my last workplace we ported some geophysics C++ apps to D for fun. The apps required more precision than double could offer and relied on GMP/MPFR. It was a nice surprise when we found the extra bits in D's real were enough for some of these apps to be correct without GMP/MPFR and gave a real performance boost (pun intended!). We targeted x86/x86_64 desktops and clusters running linux (windows and MAC on desktops as well). We did not consider the lack of IBM 360 support to be an issue when porting to D :-P Cheers, ed
Re: Designing a matrix library for D
On Tuesday, 24 June 2014 at 07:01:14 UTC, Mason McGill wrote:
On Tuesday, 24 June 2014 at 04:36:04 UTC, ed wrote:
On Monday, 23 June 2014 at 21:08:03 UTC, Mason McGill wrote:
[snip]
Concepts:
InputGrid: anything with a size (size_t[n]) and n-dimensional
opIndex.
OutputGrid: anything with a size (size_t[n]) and
n-dimensional opIndexAssign.
[snip]
Cheers,
Mason
I don't think 'Grid' is not a good name for the type. The term
Grid is generally used to refer to any sort of grid; regular,
semiregular, irregular, unstructured, curvilinear etc. etc.
grids.
When you're talking about sampling on a grid, warping can
either be thought of as warping the grid, or warping the
function to be sampled. My library happens to work in terms of
the second approach, so it is (pedantically) consistent. I see
your point, though.
They are all very different in their use and internal
representations. Often a grid will have support for metadata
at each point (GIS etc.) whereas a matrix will not.
I think the word Matrix is a better fit, because that is what
they these types are.
Not quite. "Matrix" connotes 2-dimensional tensors (in the
linear algebra sense). The library I'm developing at work is
for manipulating multidimensional arrays, which don't have the
same semantics people expect from matrices (representing linear
operators). However, the name "Array" already refers to at
least 3 data structures in D, so it was out. I picked "Grid"
because the library is for processing data sampled regularly on
n-dimensional grids (mostly vision). With my library, you could
represent complex data in a GIS via a grid of structures, or
multiple grids ("layers").
Well you could but there are well established data structures
that are optimal for each grid type so it would be better to just
use one of those.
If you're not convinced, I intend to release my work under a
liberal license, so feel free to download it and find/replace
"Grid" -> "Matrix" :)
Fair enough and I am only nitpicking. Your library sounds
promising so I'll definitely give it a whirl when released.
Also, check out this other option if you haven't already:
http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html
Yep, this is nice and I use it already, along with Sci-D.
Cheers,
ed
Re: Designing a matrix library for D
On Monday, 23 June 2014 at 21:08:03 UTC, Mason McGill wrote: [snip] Concepts: InputGrid: anything with a size (size_t[n]) and n-dimensional opIndex. OutputGrid: anything with a size (size_t[n]) and n-dimensional opIndexAssign. [snip] Cheers, Mason I don't think 'Grid' is not a good name for the type. The term Grid is generally used to refer to any sort of grid; regular, semiregular, irregular, unstructured, curvilinear etc. etc. grids. They are all very different in their use and internal representations. Often a grid will have support for metadata at each point (GIS etc.) whereas a matrix will not. I think the word Matrix is a better fit, because that is what they these types are.
Re: Swift does away with pointers == pervasive ARC
On Tuesday, 17 June 2014 at 11:59:23 UTC, Manu via Digitalmars-d wrote: On 17 June 2014 18:36, Nick Sabalausky via Digitalmars-d wrote: On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad" " wrote: On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote: Well, I think interesting part we're trying to look at here is the ARC's impact on speed. ARC without deep whole program analysis is bound to be slow.[...] Right, but what I'm mainly curious about is "How much slower?" Depending how the numbers play out, then as Manu has mentioned, it could be that the relaxed memory requirements and amortized cost are enough to make it a good tradeoff for a lot of people (Like Manu, I have some interest in soft-realtime as well). But I'm new to ARC, never even used ObjC, so I don't really even have much frame of reference or ballpark ideas here. So that's why I'm interested in the whole "How much slower?" Your descriptions of the ins and outs of it, and Apple's motivations, are definitely interesting. But even if nothing else, Manu's certainly right about one thing: What we need is some hard empirical data. Andrei posted a document some time back comparing an advanced RC implementation with "the best GC", and it performed remarkably well, within 10%! D does not have 'the best GC'. I doubt D's GC is within 10% of 'the best GC'. In addition, my colleagues have reported no significant pain working with ARC on iOS, whereas Android developers are always crying about the GC by contrast. I can visualise Walter's criticisms, but what I don't know is whether his criticisms are actually as costly as they may seem? I also haven't seen the compilers ability to eliminate or simplify that work, and the circumstances in which it fails. It's conceivable that simply rearranging an access pattern slightly may offer the compiler the structure it needs to properly eliminate the redundant work. The thing is, I don't know! I really don't know, and I don't know any practical way to experiment with this. D theoretically offers many opportunities for ARC optimisation that other languages don't via it's rich type system, so direct comparisons via O-C could probably be reasonably considered to be quite conservative. Here's what I do know though; nobody has offered conception of a GC that may be acceptable on a memory limited device, and it's also not very acceptable just by nature (destructors are completely broken; should be removed (like C#), concentrated cost as opposed to amortised cost). As far as I know, there is NO OTHER CHOICE. Either somebody invents the fantasy GC, or we actually *experiment* with ARC... We know: GC is unacceptable, and nobody has any idea how to make one that is. We don't know: ARC is acceptable/unacceptable. Why. What other position can I take on this issue? Check out the compiler and start the experiment you keep talking about. Cheers, ed
Re: Out of sight out of mind
On Tuesday, 17 June 2014 at 06:07:22 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-06-17 at 02:24 +, ed via Digitalmars-d wrote: […] I agree, but it is rather pricey for OSS. JIRA is free for FOSS projects if you apply to them and they agree. Groovy, GPars and Gant all use the Codehaus infrastructure that has a free JIRA and Bamboo. Cool, I wasn't aware of this.
Re: Out of sight out of mind
On Monday, 16 June 2014 at 13:53:39 UTC, Byron Heads wrote: Does github link issues with pull requests (and the conversation) and commits? Does it link issues with sub issues/tasks? Can Issues link to other repos (link issues that are in both runtime and std lib)? If it does have these features (and they are easy to use) then I would back it. I have found jira to be one of the best trackers out there. -Byron I agree, but it is rather pricey for OSS.
Re: SurveyMonkey for D users OS - Results
On Friday, 6 June 2014 at 22:04:35 UTC, Paulo Pinto wrote: Am 06.06.2014 22:24, schrieb Dicebot: On Friday, 6 June 2014 at 19:44:53 UTC, Paulo Pinto wrote: Battery usage is still a common problem. Everything has been working perfectly for years now. Not really, case in point my Netbook Asus EEE PC 1215B, which was sold in Germany via Amazon with GNU/Linux support pre-installed. After one year usage, the wireless card stopped working with IPv4 routers, because Ubuntu devs decided to replace the proprietary driver in the LTS distribution, although the open source version was still work in progress. LTS distribution This is the problem. Don't use LTS releases for desktops and your Linux experience will be much more pleasant. It is natural but wrong approach simply because kernel and driver support is evolving so fast that LTS versions can never really catch up. Bleeding edge distros have best h/w support, though that may cost some time wasted of system tinkering once in a while. I got tired of tinkering. It must work out of the box, otherwise I have better things to do with my life. -- Paulo I gave up on Ubuntu due to bugs, crashes and general instability that started to appear around 9.10. I switched to Fedora 16 after Ubuntu 12.04 still had not resolved all the stability issues, X crashes every package upgrade etc. Fedora has never given me any real problems... I switched to Arch about 12 months ago because I wanted the latest clang, gcc et. al. and didn't want to wait 3-4 months for the next Fedora release. I've never looked back. Arch is by far the most stable and up to date Linux I've ever used.
Re: Will std.experimental be shipped with DMD zip package?
On Thursday, 5 June 2014 at 16:57:53 UTC, Andrei Alexandrescu wrote: On 6/5/14, 1:08 PM, uri wrote: I assume it will but thought I'd ask all the same... I only use the latest official release and would still like to bash on std.experimental modules so I hope it will be in 2.066.zip. Thanks, uri std.experimental should come with the default installation. -- Andrei That's what I guessed but it never hurts to ask :) Cheers, uri
Re: Will std.experimental be shipped with DMD zip package?
On Thursday, 5 June 2014 at 16:57:53 UTC, Andrei Alexandrescu wrote: On 6/5/14, 1:08 PM, uri wrote: I assume it will but thought I'd ask all the same... I only use the latest official release and would still like to bash on std.experimental modules so I hope it will be in 2.066.zip. Thanks, uri std.experimental should come with the default installation. -- Andrei terrific, thanks
Re: D's gui controls need a cool control for DataBase Programming
On Wednesday, 4 June 2014 at 02:25:29 UTC, ed wrote: On Wednesday, 4 June 2014 at 02:02:38 UTC, FrankLike wrote: There's no GUI builder for DWT, if that's what you're looking for. But there is a plugin for Eclipse called WindowBuilder [1]. That will output Java code for SWT (which DWT is a port of). [1] http://www.eclipse.org/windowbuilder/ Will add it to VisualD? If do it,very cool. Thank you. This will not happen. There is nothing stopping you from using VisualD and WindowBuilder side-by-side. You may also like to check out DDT if you're thinking of working with DWT. https://github.com/bruno-medeiros/DDT/ note: I have not tried DWT or DDT before. I have used WindowBuilder for commercial Java apps (Swing and SWT) and found it very quick and easy to get a GUI. Cheers, ed Sorry, this is a better DDT link: https://code.google.com/p/ddt/
Re: D's gui controls need a cool control for DataBase Programming
On Wednesday, 4 June 2014 at 02:02:38 UTC, FrankLike wrote: There's no GUI builder for DWT, if that's what you're looking for. But there is a plugin for Eclipse called WindowBuilder [1]. That will output Java code for SWT (which DWT is a port of). [1] http://www.eclipse.org/windowbuilder/ Will add it to VisualD? If do it,very cool. Thank you. This will not happen. There is nothing stopping you from using VisualD and WindowBuilder side-by-side. You may also like to check out DDT if you're thinking of working with DWT. https://github.com/bruno-medeiros/DDT/ note: I have not tried DWT or DDT before. I have used WindowBuilder for commercial Java apps (Swing and SWT) and found it very quick and easy to get a GUI. Cheers, ed
Re: [OT] Extra time spent
On Monday, 2 June 2014 at 03:08:33 UTC, John wrote: On Sunday, 1 June 2014 at 19:22:44 UTC, Walter Bright wrote: On 5/30/2014 8:08 AM, Chris wrote: I like to re-invent the wheel too, because existing wheels might not be fit for your purpose. A few years back I invented a triangular wheel, which was an improvement over the square ones because it had one less bump. RTFL!! From my experience on both large and small teams reinvention has always been a fools paradise. When you factor in maintenance, documentation, testing, API and code quality and internal training it rarely pays off. Cheers, ed
Re: Web based NG/forum error "Don't know how parse text/html message"
On Friday, 30 May 2014 at 00:57:36 UTC, Jonathan M Davis via Digitalmars-d wrote: On Thu, 29 May 2014 01:49:49 + ed via Digitalmars-d wrote: This is just recent and only seems to be affecting posts by J M Davies, which are often enlightening so it is a bit frustrating. I get the following error in the web interface: > "Don't know how parse text/html message" I have switched to email for now but I actually prefer the web interface. All D documentation is close to hand while I'm reading messages that very often go way above my level. Is there a bug tracker for the web interface? Is this still happening (like with this e-mail)? My current employer blocks SMTP, so when I'm at work, I'm forced to post via the web interface (instead of my local client, which I'd much prefer to use), and my e-mail provider just changed their web interface recently, which made it so that they were sending really munged messages (which were probably html). I think that I've managed to force it to be plaintext again, and my messages seem to no longe be munged, but maybe there are still problems. Certainly, if my messages ever show up as anything other than plaintext, I'd like to know so that I can fix it. - Jonathan M Davis Nope, thanks for making the change :) Cheers, ed
Re: Web based NG/forum error "Don't know how parse text/html message"
On Friday, 30 May 2014 at 02:10:56 UTC, ed wrote: On Friday, 30 May 2014 at 00:57:36 UTC, Jonathan M Davis via Digitalmars-d wrote: On Thu, 29 May 2014 01:49:49 + ed via Digitalmars-d wrote: This is just recent and only seems to be affecting posts by J M Davies, which are often enlightening so it is a bit frustrating. I get the following error in the web interface: > "Don't know how parse text/html message" I have switched to email for now but I actually prefer the web interface. All D documentation is close to hand while I'm reading messages that very often go way above my level. Is there a bug tracker for the web interface? Is this still happening (like with this e-mail)? My current employer blocks SMTP, so when I'm at work, I'm forced to post via the web interface (instead of my local client, which I'd much prefer to use), and my e-mail provider just changed their web interface recently, which made it so that they were sending really munged messages (which were probably html). I think that I've managed to force it to be plaintext again, and my messages seem to no longe be munged, but maybe there are still problems. Certainly, if my messages ever show up as anything other than plaintext, I'd like to know so that I can fix it. - Jonathan M Davis Nope, thanks for making the change :) Cheers, ed (that is no as in it is no longer happening.) All fixed.
Re: D Users Survey: Primary OS?
On Thursday, 29 May 2014 at 18:24:57 UTC, Tom Browder via Digitalmars-d wrote: Has anyone done a survey of the primary OS of D users? I (a D newbie) use Debian Linux (64-bit), but I get the feeling that many (if not most) users are on some version of Windows. Thanks. Best regards, -Tom Archlinux 64 & 32 bit machines
Re: Web based NG/forum error "Don't know how parse text/html message"
On Thursday, 29 May 2014 at 06:28:13 UTC, Vladimir Panteleev wrote: On Thursday, 29 May 2014 at 01:49:51 UTC, ed wrote: This is just recent and only seems to be affecting posts by J M Davies, which are often enlightening so it is a bit frustrating. I get the following error in the web interface: "Don't know how parse text/html message" I have switched to email for now but I actually prefer the web interface. All D documentation is close to hand while I'm reading messages that very often go way above my level. Is there a bug tracker for the web interface? This is not a bug in the web interface, but a misconfiguration on the poster's part. Newsgroup messages are expected to contain a text part, since many clients will ignore any other text formats. That includes DFeed, because displaying HTML messages securely is not trivial. Thanks for clarifying. Cheers, ed
Web based NG/forum error "Don't know how parse text/html message"
This is just recent and only seems to be affecting posts by J M Davies, which are often enlightening so it is a bit frustrating. I get the following error in the web interface: "Don't know how parse text/html message" I have switched to email for now but I actually prefer the web interface. All D documentation is close to hand while I'm reading messages that very often go way above my level. Is there a bug tracker for the web interface? Cheers, ed
Re: DConf Recommendation
On Wednesday, 28 May 2014 at 21:05:13 UTC, Chris Williams wrote: My first day at DConf, during lunch, I ended up sitting next to the CTO/CEO of a startup company that was considering D as their language of choice. He commented to me, and which makes sense to me, that the format of the conference wasn't very well geared to people who are just interested in figuring out what the language is like and how to get started with it. His recommendation was to offer two tracks over two days (instead of one over three), whith one track focussing on things like how to get a development environment set up on different platforms, how to debug, overview of language features, etc. That way a CTO or other interested party could use the conference as a way to evaluate the language for use at their companies. I also got the sense that he was hiring, should anyone be interested. Apakau.com Does it have to split the entire DConf? What if a half-day was set aside for two streams: a) a workshop for new D users with entry-level talks and maybe even hands-on sessions (would require attendees bring a laptop) b) A set of very technical low-level language talks for hardcore D language developers. If there are not enough for a) people are less likely to mind because it is only a half-day with the alternative listening to interesting D talks anyway. Cheers, ed
Re: Mass-enabling D => License question
On Wednesday, 21 May 2014 at 00:16:07 UTC, Max Barraclough wrote: The DMD frontend is licensed under the GPL, which is 'viral': if your code links against it, you'll have to release your code as GPL. Strictly, John is right in that the GPL doesn't prevent you from charging for your code, but seeing as that code will be GPL'ed, anyone who buys it will then be free to share it publicly free of charge. (You're also required to provide source.) John's idea of having the user provide DMD, rather than bundling it, may or may not be against the letter of the GPL (I'm unsure, but I don't think it's exactly safe ground - your code is still written to the DMD ABI, after all), but it's certainly against the spirit. Here is the official GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html If I were you, I'd be asking: are there working D frontends available other than DMD (from other IDE/compiler/tooling projects)? If so, what's their licence? (I'm afraid I don't know the answer to either.) Usual disclaimer: I'm not a lawyer, certainly not a copyright lawyer, certainly not your lawyer, etc. Yet more GPL bashing? This is getting very boring these days. A GPL'd toolchain should not be a blocker for a commercial IDE. I have such an IDE compiling my C++ code as I am typing this out. GPL is not perfect but it's currently a good middle ground license that allows developers to release code open source but protect their rights to earn a living from it. Or put it another way, if you want to make money from source code that cost the original author a lot of time and effort, then the original author deserves the right to *choose* GPL and receive something in return. Either way the original author chose Open Source and that is what's important. GPL does not hinder open source development, nor the use of open source software in a commercial setting. Cheers, ed
Re: API
On Tuesday, 6 May 2014 at 00:10:36 UTC, Andrei Alexandrescu wrote: So I'm looking at creation functions and in particular creation functions for arrays. 1. Follow the new int[n] convention: auto a = allok.make!(int[])(42); assert(a.length == 42); assert(a.equal(repeat(0, 42)); 2. Follow the [ literal ] convention: auto a = allok.make!(int[])(42); assert(a.length == 1); assert(a[0] == 42); For the second option, to create longer arrays: auto a = allok.make!(int[])(42, 43, 44); assert(a.length == 3); assert(a.equal(iota(42, 45)); Nice ways to repeat things: auto a = allok.make!(int[])(42, repeat(43, 5), 44); And even nice ways to create holes for efficiency: auto a = allok.make!(int[])(42, uninitialized(5), 44); Destroy. Andrei Does it have to be one function? allok.makeLength!(int[])(42) as per new int[n] convention allok.makeUsing!(int[])(42, 43, 44) as per literal convention s/makeUsing/makeFilled -- or just makeFill s/makeUsing/makeFrom s/makeUsing/makeWith etc. etc. Cheers, Ed
Re: More radical ideas about gc and reference counting
On Thursday, 1 May 2014 at 22:18:59 UTC, H. S. Teoh via Digitalmars-d wrote: [snip] 6) Since class dtors were the only thing that cleaned up the struct member variables by invoking their dtors, that means the struct dtor will *never* get invoked. [snip] I might be mistaken but isn't it the case now that class dtors may never get invoked by the GC anyway? In which case having class dtors is pointless because one cannot rely on them. But dtors for structs I thought would still be useful. The dtor might not be called by the class dtor as it no longer exists, but it is called if I reassign the struct member by value. C c = new C(); // some code auto s = SomeStruct(/*with some parms*/); c.setStruct(s); // the existing c.struct dtor will be called, releasing whatever resources it needs Cheers, ed
