Re: c style casts
On Friday, 15 January 2016 at 15:13:37 UTC, Jacob Carlborg wrote: On 2016-01-15 11:16, Warwick wrote: I though C style casts were not supported? But when I accidentaly did int i; if (uint(i) < length) it compiled and worked fine. Whys that? Wouldn't a C style cast be: int i; if ((uint)i < length) Yeah bad memory on my part, it's C++ cast, or one of them.
c style casts
I though C style casts were not supported? But when I accidentaly did int i; if (uint(i) < length) it compiled and worked fine. Whys that?
Re: Graillon 1.0, VST effect fully made with D
On Sunday, 29 November 2015 at 09:12:18 UTC, Any wrote: On Sunday, 29 November 2015 at 06:18:13 UTC, Jonny wrote: um, come on, you sit here and preach that I don't know what I'm talking about yet you can't even be right on the first sentence? jitter is the standard deviation of the timings. Do you know what standard deviation is? It is the square root of the sum of the squares... Jitter is any deviation in, or displacement of, the signal pulses in a high-frequency digital signal. The deviation can be in terms of amplitude, phase timing or the width of the signal pulse. The units of jitter measurement are picoseconds peak-to-peak (ps p-p), rms, and percent of the unit interval (UI). See google. We're talking about whether a plugin / audio code / runtime environment can deliver audio to a soundcard in a reliable manner so that you don't get audio drop outs. We're not talking about the jitter of a digital clock source that's used to control the actual sampling stream. It's similar but at the level of the audio buffer timeslice, not the unit delta of the sample stream. The jitter of an audio clock source is for electronic engineers not audio plugin developers. In general terms of delivering audio to a soundcard jitter would be the variation in the time take to deliver each buffers worth of audio data to the soundcard. If the sound card has 5ms latency, then you need to make sure your audio processing never takes more than that. The point is that it is better to have an algorithm that always takes 3ms, than one that usually takes 2ms but occasionally takes 6ms. Because those times when it takes 6ms it cant feed the soundcard in time for the next audio buffer to be delivered. In more precise terms jitter is the variation in the time a given algorithm takes to process. I mean if the code is identical and doesn't change from one buffer to the next, the variation in time take to produce a each buffers worth of data. It's important to remember that a typical DAW user may have 10, 20, or 100+ plugins loaded, and it may be hitting 80 or 90 percent CPU usage in places. With constantly changing loads on the plugins. IE. If you are at 90% cpu usage with 5ms timeslice you can only tollerate 0.5ms jitter before the shit hits the fan. So the important question is not "does it work", it's "does it work under heavy load".
Re: Graillon 1.0, VST effect fully made with D
On Saturday, 28 November 2015 at 11:35:56 UTC, Guillaume Piolat wrote: On Saturday, 28 November 2015 at 02:37:40 UTC, Marco Leise wrote: We can probably agree that we don't know about the impact on a large multimedia application written in D. What you can communicate is: Create a @nogc thread routine and don't register it with the GC to write real-time VSTs. Guillaume did a good job, taking the GC out of the real-time thread. It's D, it is a bit of a hack, it's the correct way to do it and works. But I don't see it debunking any myths about GC and real time... A) It doesn't mix them to begin with. B) "Realtime GCs" are a thing. D's GC is not optimized for such a use case. C) With a small heap it doesn't matter. (We need more complex multimedia projects.) But the claim we hear on Internet forums is: - "can't do realtime with a GC language" (wat) - "GC leads to GC pauses" (only if you let them happen) Which is imho a shortcut. Just to play devils advocate... you haven't proved GC can do real time if you achieve it by quarantining the real time code from the GC. It's kind of like saying you can climb a mountain on a bycicle if you get of an carry it on the bits that are too steep. That said, the basic idea is that you shouldn't do anything that might take too long or use any mutex / locks. That is the same whether you use C++, Pascal, or D. The real story is how easy D makes it to achieve that.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 11:44:02 UTC, Chris wrote: On Friday, 20 November 2015 at 08:51:13 UTC, Warwick wrote: But keep burying you heads in the ground. Would you bother to define "beginners"? The getting started page says.. "absolute begginners" and IIRC "does not assume any prior programming experience". Or something like that. It's not my definition.
Re: Here's looking at you, kid
On Friday, 20 November 2015 at 01:28:00 UTC, rsw0x wrote: On Friday, 20 November 2015 at 00:47:17 UTC, Warwick wrote: On Thursday, 19 November 2015 at 12:28:44 UTC, Andrei Alexandrescu wrote: On 11/18/2015 11:02 PM, Saurabh Das wrote: [...] Generally a language reference is not good for learning a language. -- Andrei IE. There's nothing on the D website that is "good for learning" D. There's an offsite tutorial aimed at "absolute begginers". ing great set of options aint it. Ali's book is not a tutorial or aimed at absolute beginners, it's /the/ material for learning D and in my opinion a great reference book. It says on the website and I quote... "a great starting point for absolute beginners" But the fundamental problem and what everyone seems to be refusing to acknowledge is that in spite of what *you think people should be doing* many visitors are ending up using language reference to learn D. Or they use that reference to get their first impressions. It's like going to a restaurant and being given the recipes instead of the menu. But keep burying you heads in the ground.
Re: Here's looking at you, kid
On Thursday, 19 November 2015 at 12:28:44 UTC, Andrei Alexandrescu wrote: On 11/18/2015 11:02 PM, Saurabh Das wrote: On Thursday, 19 November 2015 at 02:22:14 UTC, Jeremy DeHaan It is a decent reference for you because you understand it. For programmers who aren't as experienced / knowledgeable as you, it's looks like gibberish. We have to put ourselves in the shoes of those who are just getting into the language / less experienced and thus reduce the level of difficulty in the documentation. ie: Make it more verbose, less technical, friendlier. Generally a language reference is not good for learning a language. -- Andrei IE. There's nothing on the D website that is "good for learning" D. There's an offsite tutorial aimed at "absolute begginers". ing great set of options aint it.
Re: Here's looking at you, kid
On Sunday, 15 November 2015 at 11:46:54 UTC, Saurabh Das wrote: On Friday, 13 November 2015 at 22:34:18 UTC, Andrei Alexandrescu wrote: Hi everyone, Recently there's been an uptick of site visits on dlang.org and also dmd downloads (http://erdani.com/d/downloads.daily.png). Amid increased scrutiny it's important to focus on improving documentation. I suggest everyone in the community to consider improving dlang.org in any way. For Phobos in particular, the lack of documentation and examples for some really useful artifacts is damaging. Sometimes all it takes is adding "///" to one unittest. Thanks, Andrei This is slightly off-topic, but: I've been encouraging my friends and colleagues to use Dlang over the last year and the one pain point they constantly tell me about is that the documentation website is "difficult to use" and "looks intimidating". The problem is you click on "Language Reference" and what you actually get is a "Language Specification". For example you click on "Modules" and you get this... = Module: ModuleDeclaration DeclDefs DeclDefs DeclDefs: DeclDef DeclDef DeclDefs DeclDef: AttributeSpecifier Declaration Constructor Destructor Postblit Allocator Deallocator Invariant UnitTest AliasThis StaticConstructor StaticDestructor SharedStaticConstructor SharedStaticDestructor ConditionalDeclaration DebugSpecification VersionSpecification StaticAssert TemplateDeclaration TemplateMixinDeclaration TemplateMixin MixinDeclaration ; === Who is that a reference for? I mean what user needs that information in that format? Sure if your actually writing a D compiler yourself that is probably useful... but if your a user?
Re: Here's looking at you, kid
On Sunday, 15 November 2015 at 14:27:50 UTC, Jonathan M Davis wrote: On Sunday, 15 November 2015 at 13:50:36 UTC, Warwick wrote: Who is that a reference for? I mean what user needs that information in that format? Sure if your actually writing a D compiler yourself that is probably useful... but if your a user? Honestly, I do think that that's useful as a user, but I'm also familiar with how a compiler works and tend to look at a language form a very technical perspective, whereas many others tend to try and figure out the bare minimum to get stuff done and don't care much about the details. Funilly enough that's exactly how it comes over... as a reference written for experienced D users or compiler guys. The average user / programmer coming from another language? Where's the reference for them?
Re: -> and :: operators
On Sunday, 11 October 2015 at 09:43:04 UTC, Idan Arye wrote: On Friday, 9 October 2015 at 19:48:39 UTC, Dmitry Olshansky wrote: This is the innovation in D(regarding this issue) - that on struct types, the same operator is used for BOTH the value type and the pointer to it. At the risk of sounding like a broken record the Delphi variant of Object Pascal started doing that some time around Delphi 4 or Delphi 5 IIRC. (So mid to late 90s). IE. You accessed members with the dot operator whether it was an object (like D Delphi's objects are heap based / reference semantics), a struct, or a pointer to a struct.
Re: -> and :: operators
On Sunday, 11 October 2015 at 13:50:18 UTC, Idan Arye wrote: On Sunday, 11 October 2015 at 13:05:41 UTC, Warwick wrote: On Sunday, 11 October 2015 at 09:43:04 UTC, Idan Arye wrote: On Friday, 9 October 2015 at 19:48:39 UTC, Dmitry Olshansky wrote: At the risk of sounding like a broken record the Delphi variant of Object Pascal started doing that some time around Delphi 4 or Delphi 5 IIRC. (So mid to late 90s). IE. You accessed members with the dot operator whether it was an object (like D Delphi's objects are heap based / reference semantics), a struct, or a pointer to a struct. You should have elaborated then. The other guys talked about the invention of reference types, so I assumed you did as well. Sorry I've been on pills to prevent premature elaboration. :-)
Re: -> and :: operators
On Friday, 9 October 2015 at 19:48:39 UTC, Dmitry Olshansky wrote: On 09-Oct-2015 21:44, Freddy wrote: Stole from D? You mean java right? There is no value type objects in Java so no. More likely C#. Delphi / Object Pascal had it in the mid 90s IIRC. Long before C#, and possibly before Java was released.
Re: Casting double to ulong weirdness
On Tuesday, 25 August 2015 at 20:00:11 UTC, bachmeier wrote: On Tuesday, 25 August 2015 at 18:15:03 UTC, Ola Fosheim Grøstad wrote: I'm pretty sure Walter has stated the reason that you cannot count on exact precision, but I don't remember what it is. Probably because DMD is spewing out x87 code. The x87 FPU converts everything to its internal working bit depth before it does the math op. You can set it to work at different bit depths but IIRC it's a fairly expensive operation to change the FPU flags. You really dont want to be doing it every time some mixes a double and a float. The compilers that dont exhibit this problem might set the x87 to work at 64 bit at startup or more likely they are using scalar SSE. You cant mix different depth operands in SSE. You cant multiply a float by double for example, you have to convert one of them so they have the same type. So in SSE the bit depth of every op is always explicit.
Re: Casting double to ulong weirdness
On Monday, 24 August 2015 at 18:16:44 UTC, Justin Whear wrote: On Mon, 24 Aug 2015 18:06:07 +, rumbu wrote: BTW, 1.2 and 12.0 are directly representable as double In C++: printf(%.20f\r\n, 1.2); printf(%.20f\r\n, 12.0); will output: 1.2000 12. Either upcasting to real is the wrong decision here, either the writeln string conversion is wrong. No it's not, this must be some sort of constant-folding or precision increase. Maybe the constant folding is using a different rounding mode to the runtime?
Re: Weird error message.
Decided to do a fresh install of windows, and problem has one away. It seems no matter how careful you are to keep your system lean and clean windows eventually starts grinding gears. Thanks,
Weird error message.
Dont know what to make of this, I pretty much get it every other time I call rdmd. It'll alternate between running fine and then giving me this error... C:\Program Files (x86)\Notepad++rdmd J:\Code\statproc.d std.process.ProcessException@std\process.d(550): Failed to spawn new process (The process cannot access the file because it is being used by another process.) 0x00434C59 0x00426F47 0x00403C9C 0x00403D17 0x0042F60B 0x0042F521 0x0042258C 0x76B533CA in BaseThreadInitThunk 0x775A9ED2 in RtlInitializeExceptionChain 0x775A9EA5 in RtlInitializeExceptionChain Any ideas?
