Re: A Few thoughts on C, C++, and D
On 2017-05-30 17:50, Swoorup Joshi wrote: How difficult is it to turn C++ headers usable for D? Currently DStep doesn't support C++ headers at all. If think it's quite some work to support that. Of course it's possible to start simple, i.e. C++ free functions and continue from there. -- /Jacob Carlborg
Re: A Few thoughts on C, C++, and D
On 2017-05-30 21:42, Ola Fosheim Grøstad wrote:
On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote:
Currently DStep cannot handle #if or #ifdef.
Oh, that is often required…
Yes, but it's very difficult to do.
Say there's some code looking like this:
#ifdef Windows
#include
DWORD foo();
#else
int foo();
#endif
Ideally that should be translated to:
version (Windows)
{
import core.sys.windows.windows;
DWORD foo();
}
else
{
int foo();
}
But trying to compile the code in the "body" for Windows, on any other
platform will fail because windows.h is not available.
My impression is that there is no consensus? So still a possibility then.
Good look convincing Walter that DMD should depend on DStep and LLVM.
--
/Jacob Carlborg
Re: abstract class information
On 05/31/2017 12:19 AM, Jonathan M Davis via Digitalmars-d wrote: Note that marking a class as abstract is equivalent to marking all of its member functions with abstract, just like marking class with @safe would make all of its member functions @safe. So, there isn't really any special handling of marking the class itself as abstract. That's not true. A class's `abstract` attribute does not transfer to its methods. It's the other way around: Having an abstract method makes the class abstract.
Re: [OT] I-frame cutting in H.264
On Tuesday, 30 May 2017 at 11:32:21 UTC, Marco Leise wrote: Ok, but even then your source material would ideally have to be encoded with the same codec and parameters. A different resolution would not work, while a change in frame rate is tolerable. I agree, however when VirtualDub barfs, it then goes down to hacking and hex editing the container to trick it into working, this is something i haven't done yet, so i don't know how well it works, if there's sync issues, etc.
Re: abstract class information
On Tuesday, 30 May 2017 at 22:13:54 UTC, Wulfklaue wrote: I am just looking up abstract class information and i notice that there is no information on dlang.org/spec They are defined where the abstract attribute is defined[1], but there is not much to them. [1] http://dlang.org/spec/attribute.html#abstract
Re: abstract class information
On Tuesday, May 30, 2017 22:13:54 Wulfklaue via Digitalmars-d wrote: > I am just looking up abstract class information and i notice that > there is no information on dlang.org/spec > > Yet using this as a resource: > > https://www.tutorialspoint.com/d_programming/d_programming_abstract_classe > s.htm > > It can be found, with a proper example. Am i blind and not seeing > it in the specs? > > Even Ali's book barely mentions it ( 55 ). > > And yet abstract classes exit and function in D. So strange. http://dlang.org/spec/attribute.html#abstract That part of the spec talks about the class becoming abstract if any of its members are. Note that marking a class as abstract is equivalent to marking all of its member functions with abstract, just like marking class with @safe would make all of its member functions @safe. So, there isn't really any special handling of marking the class itself as abstract. - Jonathan M Davis
abstract class information
I am just looking up abstract class information and i notice that there is no information on dlang.org/spec Yet using this as a resource: https://www.tutorialspoint.com/d_programming/d_programming_abstract_classes.htm It can be found, with a proper example. Am i blind and not seeing it in the specs? Even Ali's book barely mentions it ( 55 ). And yet abstract classes exit and function in D. So strange.
Re: std.functional.memoize : thread local or __gshared memoization?
On Tuesday, May 30, 2017 19:00:12 Kagamin via Digitalmars-d wrote: > On Saturday, 27 May 2017 at 16:27:46 UTC, Ola Fosheim Grøstad > > wrote: > > If the semantics in C is that everything is typed shared then > > it should also be treated as such when D interfaces with C and > > C like type-semantics. > > Then you would need to laboriously mark everything related to C > as shared, which would be quite different from C workflow. Everything is shared is C, but it's not marked as shared, so even though almost all of it is used as if it were thread-local, it isn't actually guaranteed to be so. This means that if you were being paranoid about it, you'd have to treat every C API as shared, but that is completely impractical and rarely fits what the C API actually does. In the vast majority of cases, if the C code were translated to D code, it would be translated as thread-local and be just fine. Well-behaved C code acts like D code in that it segregates code that operates on data as if it's on one thread and code that operates on data that's shared across threads, even if C doesn't have the helper attributes that D does. So, when dealing with a C API and shared, it's a bit like dealing with @system/@trusted and C APIs. With @system/@trusted, it's up to the programmer to figure out what's safe and what isn't based on what the API does. If it's appropriately memory-safe, then it's okay to mark it as @trusted, and if there's a problem, then you know that you need to dig into the C code to fix it. If it's not memory-safe, then it needs to be marked with @system (or nothing), and the programmer needs to make sure that they use it correctly in order to make the code that uses it memory-safe. With C APIs and shared, the programmer needs to be sure of whether it's thread-safe to treat that API call as if it's operating on thread-local data, or whether it needs to be treated as operating on shared data, and then mutexes need to be used as appropriate. Fortunately, it's usually clear, and in the vast majority of cases, treating the C function as operating on thread-local data is just fine. But it is true that you need to be a bit careful when binding to C APIs to make sure that something which isn't thread-safe is not treated as thread-local. - Jonathan M Davis
Re: A Few thoughts on C, C++, and D
On Monday, May 29, 2017 13:58:54 Brad Roberts via Digitalmars-d wrote: > On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote: > > On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote: > >> IMO, the most important thing is getting the job done. > > > > * getting the job done right. > > Otherwise, you are just going to accumulate patchy code for which you > > will pay down the line continuously. > > At least as important as getting the job done, is doing jobs. As much > fun as it is to debate and discuss what could or needs to be done to > attract one group of developers or another, actually using and releasing > systems built with D are going to contribute to accumulating to the > total mass of code. Each time someone wraps a new library, each time > someone fixes some bug because it affects them, etc.. these all push > things forward inch by inch. > > Eventually that mass might actually reach critical. But even if it > doesn't, things continue to get incrementally easier for those that > already use D and it's ecosystem. +1000 - Jonathan M Davis
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 15:50:01 UTC, Swoorup Joshi wrote: On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote: On 2017-05-30 14:27, Ola Fosheim Grøstad wrote: Maybe even turning some macros into functions? DStep can do that today. How difficult is it to turn C++ headers usable for D? Interfacing with D for giant libraries like Physx is what is holding me back utilizing D. Ha ha. I wonder what the decision makers think when all of us are like: "this is what D needs", "this hold me back", "kill GC", "I can't live without in-built RAII", ...
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 19:12:28 UTC, Jacob Carlborg wrote: Currently DStep cannot handle #if or #ifdef. Oh, that is often required… What were the objections to integration with DMD? I don't recall exactly, I recommend reading the post I linked to [1]. My impression is that there is no consensus? So still a possibility then.
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
Hello everyone, I recently started learning D (I come from a
Modern C++ background) and I was curious about closures that
require GC allocation. I wrote this simple example:
auto bar(T)(T x) @nogc
{
return x(10);
}
auto foo(int x) @nogc
{
return bar((int y) => x + y + 10);
}
int main() @nogc
{
return foo(10);
}
It doesn't compile with the following error:
Error: function example.foo is @nogc yet allocates closures
with the GC
example.foo.__lambda2 closes over variable x at [...]
Live example on godbolt: https://godbolt.org/g/tECDh4
I was wondering whether or not D could provide some syntax that
allowed the user to create a "value closure", similar to how
C++ lambdas work. How would you feel about something like:
auto bar(T)(T x) @nogc
{
return x(10);
}
auto foo(int x) @nogc
{
return bar([x](int y) => x + y + 10);
}
int main() @nogc
{
return foo(10);
}
The syntax:
[x](int y) => x + y + 10
would mean "create a 'value closure' that captures `x` by value
inside it". It would be equivalent to the following program:
struct AnonymousClosure
{
int captured_x;
this(int x) @nogc
{
captured_x = x;
}
auto opCall(int y) @nogc
{
return captured_x + y + 10;
}
}
auto foo(int x) @nogc
{
return bar(AnonymousClosure(x));
}
Which is very similar to how C++ lambdas work. This would allow
closures to be used in @nogc contexts with minimal syntactical
overhead over classical closures.
Live example on godbolt: https://godbolt.org/g/ML2dlP
What are your thoughts? Has something similar been proposed
before?
https://wiki.dlang.org/DIP30
Also, while no syntax is provided, this is how SDC works
internally and this is how it can handle multiple context
pointers.
Re: A Few thoughts on C, C++, and D
On 2017-05-30 17:15, Ola Fosheim Grostad wrote:
That's cool! How robust is in practice on typical header files (i.e
zlib and similar)?
I would say ok. I did try to run DStep on zlib.h just now. It got quite
confused when translating the comments. But disabling that it looked a
lot better. For example, all #defines which are for constants are
properly translated to enums (manifest constants). The following macros:
#define deflateInit(strm, level) \
deflateInit_((strm), (level), ZLIB_VERSION, (int)sizeof(z_stream))
#define inflateInit(strm) \
inflateInit_((strm), ZLIB_VERSION, (int)sizeof(z_stream))
#define deflateInit2(strm, level, method, windowBits, memLevel, strategy) \
deflateInit2_((strm),(level),(method),(windowBits),(memLevel),\
(strategy), ZLIB_VERSION, (int)sizeof(z_stream))
#define inflateInit2(strm, windowBits) \
inflateInit2_((strm), (windowBits), ZLIB_VERSION, \
(int)sizeof(z_stream))
#define inflateBackInit(strm, windowBits, window) \
inflateBackInit_((strm), (windowBits), (window), \
ZLIB_VERSION, (int)sizeof(z_stream))
Are translate to:
extern (D) auto deflateInit(T0, T1)(auto ref T0 strm, auto ref T1 level)
{
return deflateInit_(strm, level, ZLIB_VERSION, cast(int)
z_stream.sizeof);
}
extern (D) auto inflateInit(T)(auto ref T strm)
{
return inflateInit_(strm, ZLIB_VERSION, cast(int) z_stream.sizeof);
}
extern (D) auto deflateInit2(T0, T1, T2, T3, T4, T5)(auto ref T0 strm,
auto ref T1 level, auto ref T2 method, auto ref T3 windowBits, auto ref
T4 memLevel, auto ref T5 strategy)
{
return deflateInit2_(strm, level, method, windowBits, memLevel,
strategy, ZLIB_VERSION, cast(int) z_stream.sizeof);
}
extern (D) auto inflateInit2(T0, T1)(auto ref T0 strm, auto ref T1
windowBits)
{
return inflateInit2_(strm, windowBits, ZLIB_VERSION, cast(int)
z_stream.sizeof);
}
extern (D) auto inflateBackInit(T0, T1, T2)(auto ref T0 strm, auto ref
T1 windowBits, auto ref T2 window)
{
return inflateBackInit_(strm, windowBits, window, ZLIB_VERSION,
cast(int) z_stream.sizeof);
}
Currently DStep cannot handle #if or #ifdef.
What were the objections to integration with DMD?
I don't recall exactly, I recommend reading the post I linked to [1].
[1] http://forum.dlang.org/post/ks3kir$1ubq$1...@digitalmars.com
--
/Jacob Carlborg
Re: std.functional.memoize : thread local or __gshared memoization?
On Saturday, 27 May 2017 at 16:27:46 UTC, Ola Fosheim Grøstad wrote: If the semantics in C is that everything is typed shared then it should also be treated as such when D interfaces with C and C like type-semantics. Then you would need to laboriously mark everything related to C as shared, which would be quite different from C workflow.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Tuesday, May 30, 2017 06:13:39 Stanislav Blinov via Digitalmars-d wrote: > On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: > > That definition currently there is more precise than the > > definition on that page has been historically... > > Apparently, it is not. Do you have a reference to Walter's change > regarding `in` becoming just `const`? Because a change like that > should get reflected in the spec, otherwise we might just > continue to ignore said spec and expect our grievances to be > "gracefully" resolved later. What I mean is I'd rather see/make > the change reflected there... There was a thread discussing it here: http://forum.dlang.org/post/zskxjpctdipbqalpw...@forum.dlang.org with Walter's main response being here: http://forum.dlang.org/post/o6m17i$1jh7$1...@digitalmars.com - Jonathan M Davis
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Tuesday, 30 May 2017 at 16:19:26 UTC, Andrei Alexandrescu wrote: Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? ... Unfortunately, `in` was never implemented as `scope const`. Why would it need to be `const`? Thanks! -- Andrei What do you mean? I think `scope` would be enough. People should still be able to modify the value. -- Andrei I'm puzzled. I was talking about https://dlang.org/spec/function.html#parameters : `in` - `const scope`. Jonathan mentioned that Walter effectively reverted it to `const`. Petar provided links to that effect. Now you're saying it should be simply `scope`? %-O
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On 05/30/2017 12:19 PM, Andrei Alexandrescu wrote: On 05/30/2017 12:11 PM, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 15:59:04 UTC, Andrei Alexandrescu wrote: On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote: On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: That definition currently there is more precise than the definition on that page has been historically... Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? ... Unfortunately, `in` was never implemented as `scope const`. Why would it need to be `const`? Thanks! -- Andrei What do you mean? I think `scope` would be enough. People should still be able to modify the value. -- Andrei Oh, I'm in a different movie - thought it's the associative array "in". Sorry! -- Andrei
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On 05/30/2017 12:11 PM, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 15:59:04 UTC, Andrei Alexandrescu wrote: On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote: On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: That definition currently there is more precise than the definition on that page has been historically... Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? ... Unfortunately, `in` was never implemented as `scope const`. Why would it need to be `const`? Thanks! -- Andrei What do you mean? I think `scope` would be enough. People should still be able to modify the value. -- Andrei
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Tuesday, 30 May 2017 at 15:59:04 UTC, Andrei Alexandrescu wrote: On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote: On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: That definition currently there is more precise than the definition on that page has been historically... Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? ... Unfortunately, `in` was never implemented as `scope const`. Why would it need to be `const`? Thanks! -- Andrei What do you mean?
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote: On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: That definition currently there is more precise than the definition on that page has been historically... Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? Because a change like that should get reflected in the spec, otherwise we might just continue to ignore said spec and expect our grievances to be "gracefully" resolved later. What I mean is I'd rather see/make the change reflected there... Unfortunately, `in` was never implemented as `scope const`. Why would it need to be `const`? Thanks! -- Andrei
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote: On 2017-05-30 14:27, Ola Fosheim Grøstad wrote: Maybe even turning some macros into functions? DStep can do that today. How difficult is it to turn C++ headers usable for D? Interfacing with D for giant libraries like Physx is what is holding me back utilizing D.
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 15:06:19 UTC, Jacob Carlborg wrote: On 2017-05-30 14:27, Ola Fosheim Grøstad wrote: Maybe even turning some macros into functions? DStep can do that today. That's cool! How robust is in practice on typical header files (i.e zlib and similar)? What were the objections to integration with DMD?
Re: Another "D is cool" post
On 2017-05-30 07:14, H. S. Teoh via Digitalmars-d wrote: OK, this is the 3rd or 4th time somebody asked about this. What exactly is involved in making a post on the D blog? Hopefully it would not require too much more effort, because I usually wouldn't have much time to spend on top of the time I already spent writing the original post. If it's just a matter of copy-n-pasting the text somewhere, then perhaps somebody could do that for me? When I wrote my blog post [1] I wrote it in without much thought, I just describe how DVM works, I didn't even have an ending. I wrote it in Markdown and emailed it to Mike Parker. He gave me some input on the text which I fixed. He then added an ending, added the bio and converted the Markdown to whatever the blog site is using. [1] http://dlang.org/blog/2016/08/17/inside-d-version-manager -- /Jacob Carlborg
Re: A Few thoughts on C, C++, and D
On 2017-05-30 14:27, Ola Fosheim Grøstad wrote: Maybe even turning some macros into functions? DStep can do that today. -- /Jacob Carlborg
Re: A Few thoughts on C, C++, and D
On 2017-05-30 14:26, Ola Fosheim Grøstad wrote: What happend to that Calypso project? I suppose libclang also would allow you to inspect C header-files and then maybe it would be possible to synthesize Dish bindings from it on the fly? Not that I have given it much thought. I did that by integrating DStep in DMD as a proof of concept [1]. But at that time, IIRC, it was preferred to run DStep as a separate step to generate the bindings. http://forum.dlang.org/post/ks3kir$1ubq$1...@digitalmars.com -- /Jacob Carlborg
Re: Built-in RAII in D
On Tuesday, 30 May 2017 at 10:30:13 UTC, qznc wrote: Currently, a good answer is to direct people to the "Don't fear the reaper" [0] article, but I feel it does not really address all concerns of people. Concerns like: That was the introductory post in what I hope will be a long series where many of those concerns *will* be addressed, though I don't have the breadth of knowledge to write them all. My next one is going to cover the basics of @nogc (looking like next week). I hope to have a few guest posters contributing to the series on topics I'm not well-versed in. * How much of Phobos does not work with @nogc? A good answer would probably be case studies of larger programs/companies. Does Weka use @nogc a lot? Been reading my TODO list? I have a shortlist of people I plan to ask about a Phobos @nogc post. And I'm planning a series of company profiles where that sort of thing will probably be discussed. I had one company lined up to start before DConf, but it never panned out. But during DConf and since I've gotten some tentative commitments. I intend to kick that off in July. * How to work around the GC? The reaper article does not mention RefCounted. A future post will. I expect to have a few posts related to more specialized strategies (Atila's post on automem is in that vein). Currently, I'm planning a post about something I call "Terminator" (which is essentially RefCounted, but calling a `terminate` method rather than the destructor) to introduce the concept, and will talk about RefCounted there. But that's going to come after a post about how the GC interacts with destructors, and that will come after my @nogc post. * Limitations of @nogc? It does not prevent *another* thread to call the GC, which might then stop the world. We have to mention the trick to create threads which are not tracked by GC. * How good is the D GC? Will it improve in the foreseeable future? Information about the performance of the current GC is quite dated, although I guess not much has changed. The GC implementation is another thing I hope to have a post about, but it will again require a guest author to write it. [0] https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
Re: [OT] I-frame cutting in H.264
On Tuesday, 30 May 2017 at 11:32:21 UTC, Marco Leise wrote: So unless you know that every I-frame is an IDR in your sources it is not advisable to use them as cut points. I'll assume that Sociomantic doesn't have the original video source. Pretty much what Marco Leise said. While video packaged for internet streaming will have IDR very regularly (between every 2 to 10 sec for example), there are a lot of technical hurdles. Anyway, multiple video reencodings aren't as bad as it sounds. You are basically capped to the lowest bitrate it was encoded with, but subsequent higher encodings. The typical football match being broadcast has been encoded sometimes thrice over the full chain, albeit with high bitrates. Youtube has low bitrates but manages to do well with it, which means one can upload a higher bitrate to Youtube which means on total For this reason cutting fragments of H.264 would not really achieve anything against the following solution: keep the same resolution, same chroma subsampling than the source you have, no framerate change, and upload to Youtube a remixed video _with a higher bitrate_. Youtube will reencode anything you upload it to anyway. Multiple encodings are much more objectionable with sound.
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote: One of the things I hated when I started using D was links to dsource libraries. I think that writing new libraries in D is often a mistake for that very reason. Bindings to C libraries is what we need. Put everything into one D file if possible, wrapping just the stable core functionality with a few convenience features tossed in, and maintenance is no longer an issue. There's nothing sexy abut that approach, and that's kind of the point. I do not see anything massive wrong with that idea, beyond that your are open to libraries written in C. Potential unsafe memory function call inside the libraries...
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 12:26:22 UTC, Ola Fosheim Grøstad wrote: What happend to that Calypso project? I suppose libclang also would allow you to inspect C header-files and then maybe it would be possible to synthesize Dish bindings from it on the fly? Not that I have given it much thought. Maybe even turning some macros into functions?
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 11:22:29 UTC, bachmeier wrote: One of the things I hated when I started using D was links to dsource libraries. I think that writing new libraries in D is often a mistake for that very reason. Bindings to C libraries is what we need. Put everything into one D file if possible, wrapping just the stable core functionality with a few convenience features tossed in, and maintenance is no longer an issue. There's nothing sexy abut that approach, and that's kind of the point. What happend to that Calypso project? I suppose libclang also would allow you to inspect C header-files and then maybe it would be possible to synthesize Dish bindings from it on the fly? Not that I have given it much thought.
Re: A Few thoughts on C, C++, and D
And in good news, despite Dub's inability to understand the way things are on Debian, and using some egregious hacks, I have a DStep build on Debian Sid that appears to work. No such luck on Fedora but that is a "known issue" for DStep (*). It seems libdvbv5 D wrapper generation may be working. Me TV may yet become a D code. I shall also have to try librtlsdr. (*) What DStep needs is some folk knowledgeable about libclang 3.9, 4.0, and 5.0 to help moving up from 3.7 (and 3.8). -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
[OT] I-frame cutting in H.264
Am Sat, 27 May 2017 22:19:11 + schrieb Era Scarecrow : > Only if you have to recompress it. Some tools like VirutalDub > allow you to chop and copy without altering the data stream (it's > good for taking out commercials or shortening clips). Although I > wouldn't be surprised if you wanted to add a logo, do some fading > or some fancy stuff, at which point direct stream copying won't > work. Ok, but even then your source material would ideally have to be encoded with the same codec and parameters. A different resolution would not work, while a change in frame rate is tolerable. H.264 also makes cutting on I-frames more difficult than previous codecs as they don't clear the reference frame buffer. So following frames could still reference frames before the cut, resulting in artifacts. An actual keyframe for the start of the video, jumping to chapters or seeking is now called IDR (Instantaneous Decoder Refresh), which is also an I-frame, hence why old cutting tools like VirtualDub don't see the difference. Another low cost video editor that offers "smart rendering" without re-encoding is PowerDirector. They provide an option to use only IDR-frames or any I-frame for cuts (as you would do in VirtualDub), for cases where in your source material they are _actually_ proper keyframes with no cross-references. I tried the latter on footage shot with a Sony digicam and it resulted in a broken video stream. So unless you know that every I-frame is an IDR in your sources it is not advisable to use them as cut points. -- Marco
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 05:50:13 UTC, Ola Fosheim Grostad wrote: Focusing on getting many libraries won't work, because you need to maintain them. I never use unmaintained libraries... Having many unmaintained libraries is in a way worse than having a few long-running ones that improve at a steady pace. One of the things I hated when I started using D was links to dsource libraries. I think that writing new libraries in D is often a mistake for that very reason. Bindings to C libraries is what we need. Put everything into one D file if possible, wrapping just the stable core functionality with a few convenience features tossed in, and maintenance is no longer an issue. There's nothing sexy abut that approach, and that's kind of the point.
Re: Built-in RAII in D
On Sunday, 28 May 2017 at 18:50:02 UTC, Nerve wrote: On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote: All in all, I see little to no benefit to what you propose, while requiring significant work on the language spec. Point taken. My only remaining reservation then is the communication problem D has with the wider prospective programming world in conveying that the GC has alternatives that work. I agree. Currently, a good answer is to direct people to the "Don't fear the reaper" [0] article, but I feel it does not really address all concerns of people. Concerns like: * How much of Phobos does not work with @nogc? A good answer would probably be case studies of larger programs/companies. Does Weka use @nogc a lot? * How to work around the GC? The reaper article does not mention RefCounted. * Limitations of @nogc? It does not prevent *another* thread to call the GC, which might then stop the world. We have to mention the trick to create threads which are not tracked by GC. * How good is the D GC? Will it improve in the foreseeable future? Information about the performance of the current GC is quite dated, although I guess not much has changed. Also, p0nce has some more GC tricks: https://p0nce.github.io/d-idioms/ [0] https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Tuesday, 30 May 2017 at 09:55:14 UTC, Petar Kirov [ZombineDev] wrote: Unfortunately, `in` was never implemented as `scope const`. I think it was only when Walter started working actively on scope that he found out that it's too late to change this - https://github.com/dlang/dmd/pull/5898. Here are some more references: https://github.com/dlang/druntime/pull/1740 https://github.com/dlang/druntime/pull/1749 Going forward, I think it would be best for the language if `in` would work as Q. Schroll described here: http://forum.dlang.org/post/medovwjuykzpstnwb...@forum.dlang.org. This can also nicely fix the the problems with rvalues (with auto ref you may end with up to 2^N template instantiations where N is the number of parameters and 2 is because you get one by value and one by ref instance; doesn't play nice with delegates etc). See also https://github.com/dlang/dmd/pull/4717. Another interesting link: http://dgame.github.io/dneeds/ Thanks for the links. I have to wonder though, does this go further than dormant discussions? Because apparently, when things like that are actively put on the backburner, we have good chances ending up with "too much code would break", and in the end, nothing would be changed, at least for the better. D seems to be gaining momentum, and having things half-working-not-necessarily-as-is-was-intended looks less and less like an acceptable "for the time being" state of affairs.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Tuesday, 30 May 2017 at 09:48:09 UTC, Petar Kirov [ZombineDev] wrote: On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: That definition currently there is more precise than the definition on that page has been historically... Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? Because a change like that should get reflected in the spec, otherwise we might just continue to ignore said spec and expect our grievances to be "gracefully" resolved later. What I mean is I'd rather see/make the change reflected there... Unfortunately, `in` was never implemented as `scope const`. I think it was only when Walter started working actively on scope that he found out that it's too late to change this - https://github.com/dlang/dmd/pull/5898. Here are some more references: https://github.com/dlang/druntime/pull/1740 https://github.com/dlang/druntime/pull/1749 Going forward, I think it would be best for the language if `in` would work as Q. Schroll described here: http://forum.dlang.org/post/medovwjuykzpstnwb...@forum.dlang.org. This can also nicely fix the the problems with rvalues (with auto ref you may end with up to 2^N template instantiations where N is the number of parameters and 2 is because you get one by value and one by ref instance; doesn't play nice with delegates etc). See also https://github.com/dlang/dmd/pull/4717. Another interesting link: http://dgame.github.io/dneeds/
Re: GPGPU progess
On Tuesday, 30 May 2017 at 08:14:16 UTC, Manu wrote:
On 30 May 2017 at 17:33, Nicholas Wilson via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
On Thursday, 18 May 2017 at 05:39:52 UTC, Manu wrote:
How far are we from integration into LDC without using forked
compilers?
The future is now!
https://forum.dlang.org/thread/zcfqujlgnultnqfks...@forum.dlang.org
https://github.com/ldc-developers/ldc/commit/69ad69e872f53c1
4c101e2c029c4757c4073f487
is the final commit from the stuff I've done prior to dconf.
Awesome stuff! That was fast :)
You're right, I'm using kernel<<<...>>>, and it's very
convenient.
Yep, thats (one of the reasons) why CUDA is more successful than
OpenCL and therefore one of the more powerful draws for those
poor sods using OpenCL.
I looked briefly and realised that I had a lot of work to get
running (as
you describe), so I stuck with my current setup for the moment
:(
I figured, I'll get you using it eventually.
Is a <<<...>>> equivalent going to be possible in D, with
kernel object fragments built into the binary together with the
CPU code?
As I explained in my dconf presentation: the idea is to have
Queue q = ... ; // the equivalent of a CUDA stream
q.enqueue!kernel(sizes)(kernel_arguments);
where q.enqueue returns a callable that you then call with the
arguments. It was modelled directly after CUDAs <<<...>>>
as for embedding in the binary a post build step that does
ubyte[] ptx_code = import("kernels_cuda620_64.ptx");
should be doable as should invoking ptxas and doing the same.
Then proving a consistent naming convention is used the code can
do its magic.
Or the files could just be read from disk.
I'm definitely looking forward to action in this space, and the
wiki to come online :)
Yeah once my thesis is done thing should start moving. Any input
with your expertise with CUDA will be much appriciated.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote: On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: That definition currently there is more precise than the definition on that page has been historically... Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? Because a change like that should get reflected in the spec, otherwise we might just continue to ignore said spec and expect our grievances to be "gracefully" resolved later. What I mean is I'd rather see/make the change reflected there... Unfortunately, `in` was never implemented as `scope const`. I think it was only when Walter started working actively on scope that he found out that it's too late to change this - https://github.com/dlang/dmd/pull/5898. Here are some more references: https://github.com/dlang/druntime/pull/1740 https://github.com/dlang/druntime/pull/1749 Going forward, I think it would be best for the language if `in` would work as Q. Schroll described here: http://forum.dlang.org/post/medovwjuykzpstnwb...@forum.dlang.org. This can also nicely fix the the problems with rvalues (with auto ref you may end with up to 2^N template instantiations where N is the number of parameters and 2 is because you get one by value and one by ref instance; doesn't play nice with delegates etc). See also https://github.com/dlang/dmd/pull/4717.
Re: Another "D is cool" post
On Tuesday, 30 May 2017 at 05:14:21 UTC, H. S. Teoh wrote: On Tue, May 30, 2017 at 01:44:58AM +, Mike Parker via Digitalmars-d wrote: On Monday, 29 May 2017 at 19:51:26 UTC, David Gileadi wrote: > On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: > > [snip an excellent post] > I think a longish post like this would make an excellent > shortish post for the D blog. Yes, please. OK, this is the 3rd or 4th time somebody asked about this. What exactly is involved in making a post on the D blog? Hopefully it would not require too much more effort, because I usually wouldn't have much time to spend on top of the time I already spent writing the original post. If it's just a matter of copy-n-pasting the text somewhere, then perhaps somebody could do that for me? For a more general audience, I would suggest to expand the first paragraph and tell more about your pet project. Some parts should be extended, so non-D-programmers can understand it. For example, the mention of `pragma` is probably confusing for C/C++ people. Inserting a few links would be nice (e.g. for std.array.split). If you really want to put in work, insert lots of code examples with C and D versions. Finally, a question: Did you count lines of code C vs D? Or better yet, number of tokens? Anyways, I was tempted to send the forum link around, so it is already a nice blog post as it is.
Re: [Semi-OT] DoS with hashing
The attack relies on many collisions. I wonder if it would be enough to just count the number of collisions and rehash the hashtable with new hash seed on some threshold number.
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 07:56:43 UTC, Wulfklaue wrote: Its been my firm believe that lose packages are a detriment to a language. It isn't good if many of the interesting packages are unmaintained, as it gives an sense of being in the past. Half baked solutions are no solutions. Packages need to be part of the language standard or "extended" library. Standard libraries should stay small as they are hard to deprecate. Have official lists instead. One can simply look at Go. 100.000 packages, 98% are junk, unfinished, not maintained, etc. And people are forced to dive into the junk to find the good ones. Its the same with other languages and there unenforced third party packages. There is a solution for this: "awesome lists" https://github.com/avelino/awesome-go The problem for a small language is more when a very useful library become unmaintained, then people wonder why not somebody else took over.
Re: GPGPU progess
On 30 May 2017 at 17:33, Nicholas Wilson via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, 18 May 2017 at 05:39:52 UTC, Manu wrote: > >> How far are we from integration into LDC without using forked compilers? >> > > The future is now! > > https://forum.dlang.org/thread/zcfqujlgnultnqfks...@forum.dlang.org > > https://github.com/ldc-developers/ldc/commit/69ad69e872f53c1 > 4c101e2c029c4757c4073f487 > is the final commit from the stuff I've done prior to dconf. > Awesome stuff! That was fast :) You're right, I'm using kernel<<<...>>>, and it's very convenient. I looked briefly and realised that I had a lot of work to get running (as you describe), so I stuck with my current setup for the moment :( Is a <<<...>>> equivalent going to be possible in D, with kernel object fragments built into the binary together with the CPU code? I'm definitely looking forward to action in this space, and the wiki to come online :)
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 07:15:08 UTC, Russel Winder wrote: Others have mentioned widening D's appeal by widening the number of C APIs there are wrappers for. This is a good idea, I agree – in my case libdvbv5 and librtlsdr are the beasties of interest. I argue Deimos is the wrong direction since it is about manually managing evolving API, DStep is the right direction since it is about creating the API of the moment. However DStep may not yet be ready. I need to tinker more. libdvbv5 effectively includes the whole Linux DVB API, there are a lot of C header files. It's alla question of how best to do the wrapping. The problem is, that wrappers alone is not the solution. Lets say i write a wrapper, have no more time and abandon the project. Later people see these half finished and not maintain wrapper ( and others ). How does this reflect on the language itself. Its been my firm believe that lose packages are a detriment to a language. There is no controle over the quality of the work and yet the use of those third party packages can have a impact on the language perception ( unsupported, badly written, licencing issues ). Half baked solutions are no solutions. Packages need to be part of the language standard or "extended" library. Having the ownership under the language. Allowing people who are dissatisfied to grieve there bugs or issues, directly to the language maintainers. It also adds oversight to the packages. You mention Debian and look how they manage there packages. Code has issue: Rejected. Not maintained: Rejected. Licencing issues: Rejected. Simply trowing wrappers around C libraries does not make a language more interesting. Quality, standardization, one location, supported, ... those are the keywords. One can simply look at Go. 100.000 packages, 98% are junk, unfinished, not maintained, etc. And people are forced to dive into the junk to find the good ones. Its the same with other languages and there unenforced third party packages. This applies to enterprise users and normal users, everybody wants to have the quality and security that packages are maintained, have a standard, have the same API structure, ... But this requires a lot of coordination and manpower. Frankly, i do not see this happening any time soon in D ( and other languages ) that work with volunteers.
Re: GPGPU progess
On Thursday, 18 May 2017 at 05:39:52 UTC, Manu wrote: How far are we from integration into LDC without using forked compilers? The future is now! https://forum.dlang.org/thread/zcfqujlgnultnqfks...@forum.dlang.org https://github.com/ldc-developers/ldc/commit/69ad69e872f53c14c101e2c029c4757c4073f487 is the final commit from the stuff I've done prior to dconf.
Re: Another "D is cool" post
On 5/29/2017 6:44 PM, Mike Parker wrote: On Monday, 29 May 2017 at 19:51:26 UTC, David Gileadi wrote: On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: [snip an excellent post] I think a longish post like this would make an excellent shortish post for the D blog. Yes, please. I agree. Do it!
Re: A Few thoughts on C, C++, and D
On Tue, 2017-05-30 at 08:39 +0200, Jacob Carlborg via Digitalmars-d wrote: > On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote: > > > My biggest problem of the moment is libdvbv5 and librtlsdr. DStep > > seemingly cannot help as yet. > > I know you have reported a few bugs for DStep. Are those all or > anything > else that has not been reported yet? I am leading up to working more on this – but I need a statically linked executable that will run on Debian Sid and Fedora Rawhide. Looking at the problem of wrapping libdvbv5, what is in Deimos, etc., manually wrapping C libraries strikes me as a dead-end of dead-ends. As with GtkD and GStreamerD automated (or at least mostly automated) generation of wrappers is the only way forward. So if I cannot automatically generate libdvbv5 D wrappers, then I am not sure I can progress with D for Me TV. So DStep becomes a crucial factor. Except I cannot build it (as we discussed elsewhere, hence I need pre-built executables). Others have mentioned widening D's appeal by widening the number of C APIs there are wrappers for. This is a good idea, I agree – in my case libdvbv5 and librtlsdr are the beasties of interest. I argue Deimos is the wrong direction since it is about manually managing evolving API, DStep is the right direction since it is about creating the API of the moment. However DStep may not yet be ready. I need to tinker more. libdvbv5 effectively includes the whole Linux DVB API, there are a lot of C header files. It's alla question of how best to do the wrapping. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
