Re: SDL2 texture blend help
On Tuesday, 12 December 2017 at 06:27:30 UTC, Ivan Trombley wrote: This isn't a scaling problem (which is totally solved by Scaling is not a prerequisite for this problem. pre-multiplying the alpha with the colors BTW). This is a gamma How did you this? Using editor or using shader? If shder, show the code. Can you share both images? I want to check. correction problem which is solved only by converting the color values to linear color space before compositing and then converting the final pixel back to sRGB. Are you sure in that? Because what I see is typical alpha blending problem.
Re: Adding Markdown to Ddoc
On Tuesday, December 05, 2017 20:11:33 Walter Bright via Digitalmars-d wrote: > https://help.github.com/articles/basic-writing-and-formatting-syntax/ > > Anyone interested in picking up the flag? > > (I know this has come up before, and I've been opposed to it, but I've > changed my mind.) I confess that looking over that page, I don't see much reason to add any of it to ddoc. It all seems like stuff that we can already trivially do in ddoc, and most (all?) of it is stuff that already has built-in macros. What are we really trying to gain here? In my experience, the problems with ddoc tend to stem from the fact that it's a general purpose macro language and not just intended for documentation generation - there's nothing built-in for generating links to symbols or a navigation bar like dlang.org has, and while some of it can be done in ddoc with a bit of work, some of it requires additional scripts or programs to do it (e.g. while you can add a macro to create a link for a symbol if you have a website layout designed for it, no macro will be able to generate a navigation bar with the list of modules in the project; you need a separate program to generate the list for you, even if that list is then in ddoc). I really do like ddoc as a macro language, but the fact that that's all it is does hamper it for documentation generation, and while you can get decent, basic documentation out of the box, you can't get anything like doxygen or ddox gives you. You just have separate modules pages without any links to anything or anything indicating what the list of modules is. And you can't even take what's done for Phobos and sanely reuse it, because it's gotten so complicated and is so thoroughly tied to dlang.org. At the moment, I'm actually trying to put together a basic set of ddoc files with a simple program for using dmd to generate the documentation (as opposed to using a separate generator like ddox does) so that I have something relatively simple that I can reuse across projects that will allow my to link documentation with macros like we do in Phobos and have the navigation bar out of the box - hopefully in a way that's reasonably understood and customizable as opposed to the mess that Phobos' documentation generation has become. I suspect that 90+% of folks that generate documentation just use ddox at this point, because making straight ddoc look good is a royal pain right now - at least if you want to be able to reasonably navigate among the documentation pages (or even within a page) as opposed to just reading the documentation for a single module from top to bottom. As for markdown, I fail to see how adding any of it to ddoc would really help anything, since as far as I can tell, ddoc already does what markdown does just with macros instead of whatever combination of stray syntax that markdown uses for different things. And I certainly don't want to have to fight ddoc because it suddenly decided that some stray bit of syntax which isn't a macro is suddenly significant and does something special. There already complaints for how ddoc does special stuff under some circumstances instead of being purely a question of the macros used: https://issues.dlang.org/show_bug.cgi?id=16068 That particular problem can be solved by using $(COLON), but the more magic syntax there is in ddoc, the more landmines it has. It reminds me of how annoying it is when a piece of software decides that it wants to translate any emojis you type into a graphical image, and it thinks that parts of a piece of code that you type are emojis, so your code gets messed up in the process. Obviously, we're not going to be looking to add emoji support to ddoc, but any magical syntax we add risks similar problems. - Jonathan M Davis
Re: SDL2 texture blend help
On Tuesday, 12 December 2017 at 03:34:51 UTC, Dmitry wrote: On Tuesday, 12 December 2017 at 03:32:05 UTC, Ivan Trombley wrote: It turns out that it's an issue with the color channels being in sRGB color space and the alpha channel being linear. I verified this by doing a software blend of the images and then doing another software blend using gamma corrected values. There's a setting in opengl to correct for it, glEnable(GL_FRAMEBUFFER_SRGB), but I haven't tried this yet. BTW, also you could use bleeding (for example, https://github.com/dmi7ry/alpha-bleeding-d ) This isn't a scaling problem (which is totally solved by pre-multiplying the alpha with the colors BTW). This is a gamma correction problem which is solved only by converting the color values to linear color space before compositing and then converting the final pixel back to sRGB.
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 15:45:07 UTC, Guillaume Piolat wrote: On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz wrote: And to add more, CommonMark on the other hand has a full spec written and several test that covers the difficult to get right parts of Markdown/CommonMark. I'm sure I don't need to tell you the virtues of a good test suit. The CommonMark approach is to just take the union of all possible features and call it a day. Standards without opinions don't deserve to be implemented by anyone. To me, it sounds more to that https://xkcd.com/927/
Re: Post about comparing C, C++ and D performance with a real world project
Thanks, I will try that. On Mon, Dec 11, 2017 at 7:34 PM, German Diago via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, 7 December 2017 at 14:09:35 UTC, Steven Schveighoffer wrote: > >> On 12/7/17 6:46 AM, Daniel Kozak wrote: >> >>> Not much helpful, still does not know which compiler flags have been >>> used, or how I can reproduce this. It would be nice to have some shell >>> script which will compile it and run it in a same manner as a original >>> author >>> >> > You can see the compilation command line if you compile with ninja -v >
Re: Adding Markdown to Ddoc
On Tuesday, 12 December 2017 at 02:30:39 UTC, Walter Bright wrote: It's apparently written in Volt: https://github.com/VoltLang/Watt But the two links there to Volt are dead: https://github.com/VoltLang/Watt/blob/master/volt-lang.org Ah, the joys of forgetting too ensure URLs in Markdown READMEs are absolute. The correct link is volt-lang.org -- I have fixed that README also, thanks for pointing it out.
Re: SDL2 texture blend help
On Tuesday, 12 December 2017 at 03:32:05 UTC, Ivan Trombley wrote: It turns out that it's an issue with the color channels being in sRGB color space and the alpha channel being linear. I verified this by doing a software blend of the images and then doing another software blend using gamma corrected values. There's a setting in opengl to correct for it, glEnable(GL_FRAMEBUFFER_SRGB), but I haven't tried this yet. BTW, also you could use bleeding (for example, https://github.com/dmi7ry/alpha-bleeding-d )
Re: SDL2 texture blend help
It turns out that it's an issue with the color channels being in sRGB color space and the alpha channel being linear. I verified this by doing a software blend of the images and then doing another software blend using gamma corrected values. There's a setting in opengl to correct for it, glEnable(GL_FRAMEBUFFER_SRGB), but I haven't tried this yet.
Re: Druntime and non-D threads
On Friday, 8 December 2017 at 09:33:03 UTC, Ali Çehreli wrote:
I'm trying to use D as a library to be called from a non-D
environment e.g. Java runtime. If I'm not mistaken, it's quite
difficult and perhaps impossible to use GC in such a scenario.
It works as long as attached threads don't go away either by
themselves or by thread_detachThis.
I've been doing this for some time, by running all the D stdlib
tests in a shared library that's called from Android's Java
runtime, no problem with the GC or threads, if I set it up right
and with a tweak or two:
https://wiki.dlang.org/Build_D_for_Android#Changes_for_Android
However, I go the other way and call Java methods from D, so it
does depend on whether the process running the D shared library
is long-running or not, as I've had issues when a D function or
two are called periodically from a Java app instead.
My setup is Linux (Ubuntu-based), dmd 2.077.1, 64-bit build. D
is used in a shared library that is called by non-D threads.
(Tested with C and Java.)
1) The following newsgroup topic is about calling
thread_attachThis() for threads created outside of D:
http://forum.dlang.org/post/ounui4$171a$1...@digitalmars.com
As suggested in that thread, I think I have to call
thread_detachThis but I'm not sure when that can be safely
done. One idea was to attach and detach in every api function
something to the effect of
extern(C) my_api_func() {
thread_attachThis();
scope(exit) thread_detachThis();
// Do work, potentially producing garbage...
}
Does that make sense? Wouldn't garbage produced by that thread
leaked after detaching? However, failing to detach would be bad
as well as the calling thread can terminate without our
knowledge. (More on that below.)
2) Obviously, Runtime.initialize() must be called for Druntime
to work at all. Question: Is the thread that calls
Runtime.initialize() special compared to the other threads? Can
this thread disappear and the Druntime still work?
3) An attached non-D thread can exit without any notice
(gracefully or otherwise) while it's still attached to D's GC,
causing segmentation faults or deadlock.
I failed to find a way for Druntime to be resilient when such
threads disappear. For example, the registered cleanup handler
in thread.d is called only for cancelled threads, not the ones
that exit simply by returning from their thread functions.
(This is according to cleanup handler spec.)
I haven't had to try all these thread registration methods,
perhaps because the apps I'm testing are much simpler or because
I'm going the other way from D to Java most of the time.
4) Druntime uses pthread_kill to signal threads to suspend (and
resume) threads. However, successful return of this function
does not mean that the thread will respond to that signal. So,
we have a couple of bugs in Druntime as the number of
sem_wait() calls we make depends on the unreliable return value
of pthread_kill. Perhaps that's the reason for bugs like the
following:
https://issues.dlang.org/show_bug.cgi?id=15939
I don't see a way out of this POSIX limitation.
(pthread_key_create may help as a "thread destructor" but I
haven't played with it yet. thread.d beat me up pretty bad for
more than two days; I'm too tired to do anything else right
now. :) )
5) We depend on SIGUSR1 (and SIGUSR2, which may not be
necessary but it's a different topic) to suspend non-D threads.
Does that work with all threads? What if the calling framework
has other uses for those signals? Would we be interfering with
them?
Those signals are used for D threads, should work fine unless
they're being intercepted somewhere, as they are by the Android
runtime. However, you can always change the signals used, as I
did by swapping them on Android, and as others are trying to for
other reasons:
https://github.com/dlang/druntime/pull/1851#discussion_r123886260
https://github.com/dlang/druntime/pull/1565
So, what are the rules of using D as a library for a non-D
framework? I have the following so far but I'm not sure on all
points:
- SURE: One thread must make a call to Runtime.initialize()
- SURE: Every D api call must call thread_attachThis
- SURE: Attached threads must *not* terminate gracefully, due
to error, or by cancellation. (As there is no way of
guaranteeing this in POSIX, I think using D as a library in a
framework is best-effort at best.)
- NOT SURE: thread_detachThis must *not* be called as the
thread may have uncollected garbage.
- NOT SURE: SIGUSR1 and SIGUSR2 should be available.
I have tried to avoid all these problems by having the D shared
library be the starting point of the app and calling Java
functions occasionally instead, so haven't delved into all this.
Re: Adding Markdown to Ddoc
On 12/11/2017 2:30 PM, Jakob Bornecrantz wrote: It is not written in D, but the language is close enough in concepts that it can be mechanically ported into D, and is licensed under BOOST. Feel free to do what ever to it[1]. Thank you for Boost licensing it! We first used the markdown parser from vibe.d, when we threw the CommonMark testsuit, 10 tests segfaulted and 1 infinite-spun in a loop somewhere in the code. We then rewrote from scratch using the recommended practices from the CommonMark spec and the XML output from cmark as a guide. The code is used in our documentation system. Both doc-comments and outside documentation files are written in CommonMark. The doc-comments uses Doxygen tags which is then run through CommonMark, most of the time it does nothing to the comments, but if you want to write long comments it makes it much more natural and enjoyable. [1] https://github.com/VoltLang/Watt/tree/master/markdown/src/watt/markdown It's apparently written in Volt: https://github.com/VoltLang/Watt But the two links there to Volt are dead: https://github.com/VoltLang/Watt/blob/master/volt-lang.org
Re: Adding Markdown to Ddoc
On 12/11/2017 2:30 PM, Jakob Bornecrantz wrote: What I'm trying to get at is, use the testsuit and spec, it will save you lot of other problems down the road. And you will be making the world of Markdown a better place because there will be one less implementation that does things slightly differently. Perhaps you missed that I wrote this twice now: "Don't get me wrong, I think commonmarkdown is a worthy effort, and is definitely in the running to be a standard. Certainly a lot more effort seems to have been put into it vs other markdowns. It is entirely reasonable to refer to it to answer questions about whether some detail should yin or yang."
Re: Supporting musl libc
On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote: As an alternative to glibc there's a C standard library called musl [1]. This is the C standard library used by ELLCC [2], a cross-compiler based on Clang. This cross-compiler makes it very easy to target other platforms and can be used as the C compiler when building with LDC. The issue is that musl doesn't support the functions defined by execinfo.h: backtrace, backtrace_symbols_fd and backtrace_symbols, since these are glibc extensions. As far as I can see, these functions are used in two places in druntime: src/rt/backtrace/dwarf.d [3] and src/core/runtime.d [4]. The imports of execinfo is guarded by version(CRuntime_Glibc). I see that CRuntime_Glibc is a predefined version identifier defined by the compiler on Linux. I'm not sure how to best handle different C standard libraries when it comes to choosing which one to use. Is it best to choose that when building the compiler or when building druntime? Or can it be a runtime option? [1] https://www.musl-libc.org [2] http://ellcc.org [3] https://github.com/dlang/druntime/blob/master/src/rt/backtrace/dwarf.d#L41 [4] https://github.com/dlang/druntime/blob/master/src/core/runtime.d#L433-L434 I tried to build dmd on musl, and it seems to work relatively well. I need to build dmd 2.067 for bootstrapping. It doesn't build out-of-box, but there's patches floating around. There're some missing symbols in druntime: a couple math related, backtrace() and backtrace_symbols(). The former ones can be workaround, but and proper solution is needed. The latter ones can be solved by linking in libbacktrace().
Re: Druntime and non-D threads
On 12/11/2017 08:58 AM, Mengu wrote:
> On Monday, 11 December 2017 at 16:25:42 UTC, Ali Çehreli wrote:
>> On 12/08/2017 02:54 AM, Nemanja Boric wrote:
>>> [...]
>>
>> So, in cases where D is just a portable library, the only sane thing
>> to do seems to be what Kagamin suggested: create a D thread and send
>> requests to it.
>>
>> That way, we would be in total control of our threads, making
>> entry-attach/exit-detach calls unnecessary. Agreed?
>>
>> Ali
>
> care to explain what exactly that means for the rest of us who are
> n00bs? :-)
A recent issue made me spend quite a bit of time in core/thread.d, which
improved my understanding of that code. As soon as I feel confident, I
would like to write a document about my understanding. (Not necessarily
thread.d's implementation but how to use D runtime with non-D threads.)
In the case of a D library that will be called by user threads with
unknown attributes (e.g. some detachable threads some not; some joinable
threads, some not), it's clear that a D function must attach and detach
upon entry and exit to the API function:
// D library function, called on a non-D thread:
extern(C) void foo() {
// Both of these calls involve locks:
thread_attachThis();
scope(exit) thread_detachThis();
// Do D work by freely using the GC ...
}
We have to detach because we don't know whether we will ever be called
from the same thread again or even whether the thread is about to
terminate or not.
What Kagamin recommended is another way: Create threads in the D code,
which obviates attach/detach calls and removes all questions about
thread lifetimes. So, the API function could be the following:
void foo() @nogc {
// Dispatch work to one of the D threads without doing
// any complicated work here:
enqueue_task();
}
Ali
Re: Platform-dependent tests for druntime
On Monday, 11 December 2017 at 23:24:02 UTC, Ali Çehreli wrote:
Since I don't have access to Windows, OS X, etc. systems nor
have I expertise in them, I don't trust myself to write
core.thread tests for anything but Posix.
What to do for non-Posix systems? I'm tempted to wrap the
entire test code with version(Posix) but it will give the wrong
impression that the code passes for all other systems as well.
For example, inside
druntime/test/thread/src/attach_detach.d I can do this:
version (Posix) {
// Real test ...
} else {
void main() {}// Deceptive code
}
How can I seek testers for a pull request that I'm ready to
post? Post PR, hopefully get merged, and then open issues for
platforms that don't have those tests?
It would be easier if test/thread/Makefile had a way of running
platform-specific tests. Yes, probably I'm volunteering but
again, I couldn't do much without other platforms.
I have a feeling our automated test harness already has such
machines. If so, where are they? :)
Ali
Ali, you haven't made a PR to a dlang repository before, so you
weren't approved for the auto-tester. I just approved you and in
the future all PRs will trigger builds on all build hosts of the
auto-tester:
https://auto-tester.puremagic.com/hosts/
For an example, have a look here:
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1&repoid=1&pullid=7420
How can I seek testers for a pull request that I'm ready to
post? Post PR, hopefully get merged, and then open issues for
platforms that don't have those tests?
It's a very common practice for contributors to use the
auto-tester to test on other platforms.
As there aren't many core D devs who use Windows, you will
probably have a hard time to seek testers.
Platform-dependent tests for druntime
Since I don't have access to Windows, OS X, etc. systems nor have I
expertise in them, I don't trust myself to write core.thread tests for
anything but Posix.
What to do for non-Posix systems? I'm tempted to wrap the entire test
code with version(Posix) but it will give the wrong impression that the
code passes for all other systems as well. For example, inside
druntime/test/thread/src/attach_detach.d I can do this:
version (Posix) {
// Real test ...
} else {
void main() {}// Deceptive code
}
How can I seek testers for a pull request that I'm ready to post? Post
PR, hopefully get merged, and then open issues for platforms that don't
have those tests?
It would be easier if test/thread/Makefile had a way of running
platform-specific tests. Yes, probably I'm volunteering but again, I
couldn't do much without other platforms.
I have a feeling our automated test harness already has such machines.
If so, where are they? :)
Ali
Re: is there any plan to support shared libraries in OSX?
On 2017-12-10 22:00, Timothee Cour wrote: Is it on the roadmap? It's been a very long standing issue. I don't think it's on the roadmap. Nobody has needed it badly enough to implement it. I could probably give it a shot if someone implements constructors, i.e. __attribute__((constructor)), which is basically what this PR is doing [1]. [1] https://github.com/dlang/dmd/pull/7182 -- /Jacob Carlborg
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 20:45:38 UTC, Walter Bright wrote: On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote: There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations They appear to be libraries that offer an implementation. Does the Markdown used in github, reddit, wikipedia, doxygen, etc., use any of those libraries? Github in the past used something called Github Flavored Markdown, which was Markdown + whatever quirks where in the ruby implementation of Markdown + Tables. Not Markdown. The same with all of the others, they all had different quirks because the markdown "spec" was bad. Let me use a different technology as a analogy. Walter: We should use HTML for DDOC! Others: Cool, but can you use CommonTML (HTML5), it has this cool spec and actual tests that make sure it looks the same, and that the code you have written is robust. HTML isn't really a standard as such, you are not sure what you get and there is no agreed upon testsuit, so you aren't even sure you get the same results with different versions of your own code. Walter: Is this used elsewhere? I really want HTML. Others: Here is the spec and a bunch of implementations. Walter: But HTML is more common, its used in Netscape Navigator and IE6. Others: *collective headdesk* What I'm trying to get at is, use the testsuit and spec, it will save you lot of other problems down the road. And you will be making the world of Markdown a better place because there will be one less implementation that does things slightly differently. the one I have written is not listed. That covers 1 and 2. I didn't know you wrote one. There are 3 Markdown packages on Dub: https://code.dlang.org/search?q=markdown and I don't see your name on them. I strongly recommend you register yours with Dub (if it is in D) and on the commonmark site! It is not written in D, but the language is close enough in concepts that it can be mechanically ported into D, and is licensed under BOOST. Feel free to do what ever to it[1]. We first used the markdown parser from vibe.d, when we threw the CommonMark testsuit, 10 tests segfaulted and 1 infinite-spun in a loop somewhere in the code. We then rewrote from scratch using the recommended practices from the CommonMark spec and the XML output from cmark as a guide. The code is used in our documentation system. Both doc-comments and outside documentation files are written in CommonMark. The doc-comments uses Doxygen tags which is then run through CommonMark, most of the time it does nothing to the comments, but if you want to write long comments it makes it much more natural and enjoyable. [1] https://github.com/VoltLang/Watt/tree/master/markdown/src/watt/markdown
Re: Adding Markdown to Ddoc
On 12/11/17 1:45 PM, Walter Bright wrote: On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote: There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations They appear to be libraries that offer an implementation. Does the Markdown used in github, reddit, wikipedia, doxygen, etc., use any of those libraries? It appears that github now uses their own fork of cmark, which adds support for tables, etc. [1] [1] https://githubengineering.com/a-formal-spec-for-github-markdown/
Re: Extending D to support per-class or per-instance user-defined metadata
I realize that I focused too much on the how, and not enough on the why. By "metadata" I mean the data that is "just there" in any object, in addition to user defined fields. An example of per-class metadata is the pointer to the the virtual function table. It is installed by the compiler or the runtime as part of object creation. It is the same for all the instances of the same class. Just like virtual functions, my openmethods library uses "method tables" and needs a way of finding the method table relevant to an object depending on its class. I want the library to work with objects of any classes, without requiring modifications to existing classes. Thus, there is a need to add that information to any object, in an orthogonal manner. Openmethods has two ways of doing this (one actually hijacks the deprecated 'deallocator' field in ClassInfo) but could profit from the ability to plant pointers right inside objects. Examples of per-object metadata could be: a reference count, a time stamp, an allocator, or the database an object was fetched from.
Re: Adding Markdown to Ddoc
On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote: There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations They appear to be libraries that offer an implementation. Does the Markdown used in github, reddit, wikipedia, doxygen, etc., use any of those libraries? the one I have written is not listed. That covers 1 and 2. I didn't know you wrote one. There are 3 Markdown packages on Dub: https://code.dlang.org/search?q=markdown and I don't see your name on them. I strongly recommend you register yours with Dub (if it is in D) and on the commonmark site!
Re: Adding Markdown to Ddoc
On 12/11/2017 11:29 AM, John Gabriele wrote: Right. That said, if you want to add a handful of markdown-ish features, I think it would be most useful to draw your very limited markdown subset from the CommonMark markdown spec. The other option takes you down the road of unintentionally creating yet another variant for users to contend with. That's basically what I said :-)
Extending D to support per-class or per-instance user-defined metadata
I just had a discussion with Walter, Andrei and Ali about open
methods. While Andrei is not a great fan of open methods, he
likes the idea of improving D to better support libraries that
extend the language - of which my openmethods library is just an
example. Andrei, correct me if I misrepresented your opinion in
this paragraph.
Part of the discussion was about a mechanism to add user-defined
per-object or per-class metadata (there's another part that I
will discuss in another thread).
Andrei's initial suggestion is to put it in the vtable. If we
know the initial size of the vtable, we can grow it to
accommodate new slots. In fact we can already do something along
those lines...sort of:
import std.stdio;
class Foo {
abstract void report();
}
class Bar : Foo {
override void report() { writeln("I'm fine!"); }
}
void main() {
void*[] newVtbl;
auto initVtblSize = Bar.classinfo.vtbl.length;
newVtbl.length = initVtblSize + 1;
newVtbl[0..initVtblSize] = Bar.classinfo.vtbl[];
newVtbl[initVtblSize] = cast(void*) 0x123456;
byte[] newInit = Bar.classinfo.m_init.dup;
*cast(void***) newInit.ptr = newVtbl.ptr;
Bar.classinfo.m_init = newInit;
Foo foo = new Bar();
foo.report(); // I'm fine!
writeln((*cast(void***)foo)[initVtblSize]); // 123456
}
This works with dmd and gdc, not with ldc2. But it gives an idea
of what the extension would like.
A variant of the idea is to allocate the user slots *before* the
vtable and access them via negative indices. It would be faster.
Of course we would need a thread safe facility that libraries
would call to obtain (and release) slots in the extended vtable,
and return the index of the allocated slot(s). Thus a library
would call an API to (globally) reserve a new slot; then another
one to grow the vtable of the classes it targets (automatically
finding and growing all the vtables is unfeasible because nested
classes are not locatable via ModuleInfo).
Walter also reminded me of the __monitor field so I played with
it too. Here is prototype of what per-instance user defined slots
could look like.
import std.stdio;
class Foo {
}
void main() {
byte[] init;
init.length = Foo.classinfo.m_init.length;
init[] = Foo.classinfo.m_init[];
(cast(void**) init.ptr)[1] = cast(void*) 0x1234;
Foo.classinfo.m_init = init;
Foo foo = new Foo();
writeln((cast(void**) foo)[1]); // 1234 with dmd and gdc, null
with ldc2
}
This works with dmd and gdc but not with ldc2.
This may be useful for implementing reference-counting schemes,
Observers, etc.
In both cases I use the undocumented 'm_init' field in ClassInfo.
The books and docs do talk about the 'init' field that is used to
initialize structs, but I have found no mention of 'm_init' for
classes. Perhaps we could document it and make it mandatory that
an implementation uses its content to pre-initialize objects.
Also here I am using the space reserved for the '__monitor'
hidden field. This is a problem because 1/ it will go away some
day 2/ it is only one word. Granted, that word could store a
pointer to a vector of words, where user-defined slots would
live; but that would be at the cost of performance.
Finally, note that if you have per-instance user slots and a way
of automatically initializing them when an object is created,
then you also have per-class user-defined metadata: just allocate
a slot in the object, and put a pointer to the data in it.
Please send in comments, especially if you are a library author
and have encountered a need for this kind of thing. Eventually
the discussion may lead to the drafting of a DIP.
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote: Don't get me wrong, I think commonmarkdown is a worthy effort, and is definitely in the running to be a standard. Certainly a lot more effort seems to have been put into it vs other markdowns. Note that CommonMark isn't simply a markdown implementation. It's a: * spec * test suite * two reference implementations * collection of community implementations and also includes an active community forum. The people involved are dedicated. The spec is conservative, uncontroversial, and detailed. But implementing commonmarkdown in Ddoc is not what we're going to do, at least for the near term. Right. That said, if you want to add a handful of markdown-ish features, I think it would be most useful to draw your very limited markdown subset from the CommonMark markdown spec. The other option takes you down the road of unintentionally creating yet another variant for users to contend with.
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 15:45:07 UTC, Guillaume Piolat wrote: The CommonMark approach is to just take the union of all possible features and call it a day. Standards without opinions don't deserve to be implemented by anyone. I disagree. If anything, it's more of a subset of features common to the most widely-used markdown implementations, with corner cases ironed out (see lots of discussion on the [CommonMark forum](https://talk.commonmark.org/), and also comparisons of output from different implementations at [Babelmark2](http://johnmacfarlane.net/babelmark2/) (linked to from commonmark.org)).
Re: Post about comparing C, C++ and D performance with a real world project
On Thursday, 7 December 2017 at 14:09:35 UTC, Steven Schveighoffer wrote: On 12/7/17 6:46 AM, Daniel Kozak wrote: Not much helpful, still does not know which compiler flags have been used, or how I can reproduce this. It would be nice to have some shell script which will compile it and run it in a same manner as a original author You can see the compilation command line if you compile with ninja -v
D, Dub, and SCons
Is anyone out there interested in Dub support for D builds using SCons? If there is, then I have begun to do a bit more work on https://github.com/russel/SCons_D_Experiment and would be pleased to have others helping ready the dub.py tool and it's tests to get into the SCons distribution. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 41 Buckmaster Road m:+44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 15:45:07 UTC, Guillaume Piolat wrote: On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz wrote: And to add more, CommonMark on the other hand has a full spec written and several test that covers the difficult to get right parts of Markdown/CommonMark. I'm sure I don't need to tell you the virtues of a good test suit. The CommonMark approach is to just take the union of all possible features and call it a day. Standards without opinions don't deserve to be implemented by anyone. It's crazy to see that the most basic HTML features still cause issues in Markdown. CommonMark can be seen as a pragmatic approach but may suffer from the "Babel tower" problem: try to assemble all the languages tend to make everybody disagree, leading exactly to the opposite of the initial goal, that is unification (it's probably not exactly that but i'm not a theologist after all, 😂).
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz wrote: There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations the one I have written is not listed. That covers 1 and 2. Also Markdown is not a standard, it started out as a pearl script and the a short documentation on how to write text for it. It has several ambiguities, leading to a lot of implementations do things differently. So they don't agree on the authority of Markdown. Which makes Markdown a mess because you don't know what behaviour you will get from the different implementation. So that covers 3. And to add more, CommonMark on the other hand has a full spec written and several test that covers the difficult to get right parts of Markdown/CommonMark. I'm sure I don't need to tell you the virtues of a good test suit. Cheers, Jakob. If there is a desire to add CommonMark support, it is best to output ddoc to commonmark and call an external tool specified by the user. The proposal to add a few markdown features to ddoc is a reasonable short run goal. If you set commonmark support as a goal, it will probably never get done.
Re: Druntime and non-D threads
On Monday, 11 December 2017 at 16:25:42 UTC, Ali Çehreli wrote: On 12/08/2017 02:54 AM, Nemanja Boric wrote: [...] So, in cases where D is just a portable library, the only sane thing to do seems to be what Kagamin suggested: create a D thread and send requests to it. That way, we would be in total control of our threads, making entry-attach/exit-detach calls unnecessary. Agreed? Ali care to explain what exactly that means for the rest of us who are n00bs? :-)
Re: SDL2 texture blend help
On Monday, 11 December 2017 at 04:57:44 UTC, Ivan Trombley wrote: Experimenting with compositing images in SDL2, I get a dark edge around my textures. In the image below, you can see the top example where I composite the cyan image on top of the blue/magenta image looks correct but the bottom example, which is done using SDL_RenderCopy is not correct. http://a4.pbase.com/o10/09/605909/1/166698494.lCoVTgcI.example.png I tried premultiplying the the colors in the cyan image and setting the blend function as such... SDL_SetTextureBlendMode(texture, SDL_ComposeCustomBlendMode( SDL_BlendFactor.SDL_BLENDFACTOR_ONE, SDL_BlendFactor.SDL_BLENDFACTOR_ONE_MINUS_SRC_ALPHA, SDL_BlendOperation.SDL_BLENDOPERATION_ADD, SDL_BlendFactor.SDL_BLENDFACTOR_ONE, SDL_BlendFactor.SDL_BLENDFACTOR_ONE, SDL_BlendOperation.SDL_BLENDOPERATION_ADD)); ...but that produces the exact same thing. Any SDL experts out there that can give me a clue? I dont know SDL but what your describing sounds like the cyan image already has premultiplied alpha and the blend operation is doubling down on that. Have you tried the above blend op without premultiplying the cyan image?
Re: Druntime and non-D threads
On 12/08/2017 02:54 AM, Nemanja Boric wrote: On Friday, 8 December 2017 at 09:33:03 UTC, Ali Çehreli wrote: 5) We depend on SIGUSR1 (and SIGUSR2, which may not be necessary but it's a different topic) to suspend non-D threads. Does that work with all threads? What if the calling framework has other uses for those signals? Would we be interfering with them? As the signal handlers are setup per-process, having the non-D threads setup `SIGUSR1/2` will probably screw the entire GC, not just for these threads. I feel you must ensure that the non-D threads don't try to setup these handlers after the `rt_init` (which in turns calls `thread_init`) is called, otherwise you're screwed. This is also valid in inverse - you shouldn't use SIGUSR1/2 in non-D threads, since after calling `rt_init` the signal handlers will be replaced with druntime's ones. So, in cases where D is just a portable library, the only sane thing to do seems to be what Kagamin suggested: create a D thread and send requests to it. That way, we would be in total control of our threads, making entry-attach/exit-detach calls unnecessary. Agreed? Ali
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 14:22:37 UTC, Jakob Bornecrantz wrote: And to add more, CommonMark on the other hand has a full spec written and several test that covers the difficult to get right parts of Markdown/CommonMark. I'm sure I don't need to tell you the virtues of a good test suit. The CommonMark approach is to just take the union of all possible features and call it a day. Standards without opinions don't deserve to be implemented by anyone.
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote: On 12/10/2017 6:22 AM, meppl wrote: I think these are wrong criterias to estimate the value of commonmark. Commonmark doesn't need to list anyone and doesn't need to be listed by anyone to be a standard. commonmark is a standard proven by following "facts": 1) whenever a language feature is used by all popular markdown languages, it is standard 2) there are markdown features who are used by all popular markdown languages 3) everyone can reveal this matter of fact - e.g. by writing it down as a specification 4) any language feature published by the commonmark-spec is used by all popular markdown languages ergo: commonmark == standard markdown well, at least, if the commonmark people did their homework right I have a more pragmatic definition of a standard: 1. Products that implement it say they adhere to it and defer to it as the authority on correct behavior. 2. There's more than one such product. 3. There's more products adhering to that standard than some other competing standard. So far as I know, commonmarkdown satisfies zero of those. Don't get me wrong, I think commonmarkdown is a worthy effort, and is definitely in the running to be a standard. Certainly a lot more effort seems to have been put into it vs other markdowns. It is entirely reasonable to refer to it to answer questions about whether some detail should yin or yang. But implementing commonmarkdown in Ddoc is not what we're going to do, at least for the near term. There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations the one I have written is not listed. That covers 1 and 2. Also Markdown is not a standard, it started out as a pearl script and the a short documentation on how to write text for it. It has several ambiguities, leading to a lot of implementations do things differently. So they don't agree on the authority of Markdown. Which makes Markdown a mess because you don't know what behaviour you will get from the different implementation. So that covers 3. And to add more, CommonMark on the other hand has a full spec written and several test that covers the difficult to get right parts of Markdown/CommonMark. I'm sure I don't need to tell you the virtues of a good test suit. Cheers, Jakob.
Re: SDL2 texture blend help
On Monday, 11 December 2017 at 04:57:44 UTC, Ivan Trombley wrote: Experimenting with compositing images in SDL2, I get a dark edge around my textures. In the image below, you can see the top example where I composite the cyan image on top of the blue/magenta image looks correct but the bottom example, which is done using SDL_RenderCopy is not correct. Won't this help? https://stackoverflow.com/questions/45781683/how-to-get-correct-sourceover-alpha-compositing-in-sdl-with-opengl
Re: Druntime and non-D threads
On 12/08/2017 04:23 AM, Guillaume Piolat wrote: >> Every D api call must call thread_attachThis > I advise to make a RAII struct you will put in any accessible callback, which deals with this Of course. :) That's how I've been trying to use. > IMHO thread_detachThis *must* be called at entry-point exit. > Detach these threads at scope(exit), and avoid sorrow and call stacks > with pthread_kill inside. Agreed. My troubles turned out to be due to a druntime bug, which I think I've managed to fix: https://issues.dlang.org/show_bug.cgi?id=18063 Ali
Re: Druntime and non-D threads
On 12/08/2017 02:53 AM, Kagamin wrote: You can create a D thread an send request to it. That's a good idea. Thanks. Ali
Re: bootable vibed
On Friday, 8 December 2017 at 07:54:11 UTC, Suliman wrote: I found very interesting project https://github.com/hioa-cs/IncludeOS But by description it's target to C++ "IncludeOS is an includable, minimal unikernel operating system for C++ services running in the cloud". I think that would be a lot of people interesting to get same for D and vibed. What about https://github.com/solo-io/unik ?
Re: bootable vibed
On Saturday, 9 December 2017 at 05:07:46 UTC, Elronnd wrote: Note to anyone trying to implement this (I might try, but I don't have the expertise to...): http://wiki.osdev.org/D_Bare_Bones, http://wiki.osdev.org/D_barebone_with_ldc2, and https://github.com/PowerNex/PowerNex None of D's OSes supports networking.
Re: SDL2 texture blend help
On Monday, 11 December 2017 at 07:04:19 UTC, Mike Parker wrote: On Monday, 11 December 2017 at 04:57:44 UTC, Ivan Trombley wrote: Any SDL experts out there that can give me a clue? I've used SDL quite a bit, but can't help with your specific problem. However, I suggest you try the new(ish) SDL forums for stuff like this. It's particularly off topic here. https://discourse.libsdl.org Thanks for the link.
