Vote started for std.uni
Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org
Re: Vote started for std.uni
On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ?
DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ Enjoy! Discuss!! Vote!!! Andrei
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This link on the YouTube page seems to not be online: http://dconf.org/2013/talks/lucarella.pdf Bye, bearophile
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 .. but it's not clear to me how useful this is for fork emulation or similar. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Visual D 0.3.36 released - support for Alex Bothe's semantic analysis, LDC and profiling
On 16/05/2013 17:58, Ali Çehreli wrote: On 05/16/2013 03:08 AM, Bruno Medeiros wrote: On 14/05/2013 06:45, TommiT wrote: Notice that alias this = id is not supposed to be valid syntax. Huh, what's this about? DMD does not seem to recognize it, but it's listed in the grammar. Is it an upcoming feature or is the grammar out of date? When the other use of alias has been changed from alias int NewName; // weird syntax to alias NewName = int; // welcome syntax 'alias this' has also been inadvertently changed from alias memberFunc this;// still valid syntax to alias this = memberFunc; // buggy syntax It has been a recent bug which has quickly been reverted. Here is a past discussion: http://forum.dlang.org/thread/aaflopktcjmljxdno...@forum.dlang.org Ali Ah I see. I was about to ask why was it put in the grammar documentation then, but it seems it is no longer there for the online version of the documentation: http://dlang.org/declaration.html#AliasThisDeclaration It is still present in the documentaton of the 2.062 DMD download though, hence my confusion. :S (I was looking at the download doc) -- Bruno Medeiros - Software Engineer
Re: Vote started for std.uni
20-May-2013 12:15, deadalnix пишет: On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? At compile-time? The short answer is it should be possible but not quite yet. The long answer is: enum myA = unicode.alphabetic.toTrie!4; --- Error: CTFE internal error: unsupported assignment this = p uni.d(1841):called from here: this.data.opAssign((Uint24Array!(GcPolicy) __ctmp6762 = 0; , __ctmp6762).this(flattened)) uni.d(6742):called from here: (InversionList!(GcPolicy) __ctmp6477 = 0; , __ctmp6477).this(decompressIntervals(compressed)) --- So I forgot to reduce a bug it seems (or maybe I filed it). Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source. This is actualy one of things I'd love to push as a separate feature Phobos-wide: serialization of objects to CTFE-able/mixin-able source code. Some of these done in std.uni weren't clean enough to fit into a public interface. Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ? I dunno. Technically I see no problem with std.unicode except that we have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own. We should probably split the discussion-while-voting in a separate thread in D.d. -- Dmitry Olshansky
Re: Vote started for std.uni
On Monday, 20 May 2013 at 08:15:48 UTC, deadalnix wrote: On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ? Please place this in the vote thread, or it will not be counted when I get to tallying.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Mon, 20 May 2013 08:50:25 -0400 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ Torrents up, as well as links: http://semitwist.com/download/misc/dconf2013/
Re: mysql-native: Seamlessly supports Phobos-only sockets
On Fri, 17 May 2013 02:08:05 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: If you want to use Phobos sockets, you can do it two ways: 1. Pass -version=MySQLN_NoVibeD to the compiler. This will completely eliminate all dependencies on Vibe.d (and remove all Vibe.d capabilities, naturally) and automatically use Phobos sockets. Everything else will be exactly the same (But see the caveat below). Since it makes a lot more sense for the default to be *no* external dependencies, I've flipped it around: By default, mysql-native is now Phobos-only and does *not* depend on Vibe.d (or any other third party lib). To enable the optional Vibe.d support (which also makes Vibe.d sockets the default instead of Phobos sockets, although you can explicitly choose either at runtime), then include the following compiler flag: -version=Have_vibe_d That flag above will be included automatically if you compile using DUB, and your project uses Vibe.d.
Re: mysql-native: Seamlessly supports Phobos-only sockets
Since it makes a lot more sense for the default to be *no* external dependencies, I've flipped it around: That's great thanks for your work on this.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote: On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 .. but it's not clear to me how useful this is for fork emulation or similar. R Fork isn't needed at all really in the technique described, this is all that's needed: - Map a copy of the memory using copy-on-write - Run some code concurrently It just happens that fork does both of these things, but you can equally well do the two things using separate calls. In fact you should be able to avoid the deadlock issue by not using fork but just remapping some shared memory using copy on write. The GC can exist in a separate thread which pauses itself after every run. To run the GC it's then just a case of: - stop the world - copy registers to stack - remap shared memory using COW - resume the world - resume the GC thread And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 20 May 2013 at 22:52:33 UTC, Diggory wrote: And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly. Copy on WRITE usually don't happen on immutable memory.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Tuesday, 21 May 2013 at 00:00:13 UTC, deadalnix wrote: On Monday, 20 May 2013 at 22:52:33 UTC, Diggory wrote: And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly. Copy on WRITE usually don't happen on immutable memory. I never said it did... I said that when using fork the immutable memory must be mapped into the new process, when using a thread it does not since threads share the same address space.
Re: Vote started for std.uni
On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote: 20-May-2013 12:15, deadalnix пишет: On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? At compile-time? The short answer is it should be possible but not quite yet. The long answer is: enum myA = unicode.alphabetic.toTrie!4; As long as it is doable, that sound good to me. Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source. I understand. To me a caching compiler is the solution here, but that is kind of off topic. I dunno. Technically I see no problem with std.unicode except that we have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own. We should probably split the discussion-while-voting in a separate thread in D.d. The problem wth that kind of naming convention is that names do not convey as much meaning. This can be an issue as the library get larger and larger, because you got to remember every single name and can't rely too much on autocompletion. uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
Re: Vote started for std.uni
On Tuesday, 21 May 2013 at 01:25:54 UTC, deadalnix wrote: On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote: 20-May-2013 12:15, deadalnix пишет: uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever. I support renaming to std.unicode; In the long run, std.uni is just unexpressive.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote: On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 Yes, basically. I can't find where I've read that mapping COW memory from within the same process is only supported on NT versions. However, doing it from within the same process is not practical anyway, since that would imply at least halving the address space.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Tuesday, 21 May 2013 at 04:26:18 UTC, Vladimir Panteleev wrote: On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote: On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 Yes, basically. I can't find where I've read that mapping COW memory from within the same process is only supported on NT versions. However, doing it from within the same process is not practical anyway, since that would imply at least halving the address space. Either way, at least on windows the separate process would have to be persistent as creating a new process has a lot more overhead attached to it than on posix systems. Implicitly creating a child process is also something a D programmer might not want, again this is more windows specific where processes do not have the same strict hierarchy as on posix. On 64-bit systems there shouldn't be a problem with address space, and even on 32-bit systems, the objects which take up the vast majority of the address space are usually arrays of primitive types which don't need to be scanned by the GC. Certainly for 64-bit systems I think it's worth at least doing some performance comparisons, and I think using a thread will turn out to be more efficient. If it turns out that there are merits to both options then having a GC option to use a process or a thread might make sense.
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
I know at least two cases which T.init is commonly used.
1. Inside predicate template for type T.
template isSomething(T) {
enum isSomething = is(typeof({
//T t1;// not good if T is nested struct, or has @disable this()
//T t2 = void; auto x = t2; // not good if T is non-mutable type
T t = T.init; // avoid default construct check
...use t...
}));
}
2. Some library utilities that treats object state directly, e.g.
std.conv.emplace
Kenji Hara
2013/5/20 Maxim Fomin ma...@maxim-fomin.ru
On Monday, 20 May 2013 at 00:55:14 UTC, Kenji Hara wrote:
Unfortunately this is currently not a bug.
T.init provides default initialized object image, and it *does not*
provide default constructed object. The difference is important.
That is already documented in lanugage reference.
http://dlang.org/property#init
Note: .init produces a default initialized object, not default
constructed. That means using .init is sometimes incorrect.
1. If T is a nested struct, the context pointer in T.init is null.
2. If T is a struct which has @disable this();, T.init might return a
logically incorrect object.
Kenji Hara
I think this should be fixed otherwise @disable this() is compromised.
What is rationale behind allowing .init?
Vote for std.uni
This is a replacement module for the current std.uni by Dmitry Olshansky. The std.uni module provides an implementation of fundamental Unicode algorithms and data structures. If you would like to see the proposed std.uni include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no. In summary, most discussion revolved around the string based functions for toLower/toUpper and where they should live. Please place any further comments in the official review thread leaving only your vote and a short comment (there should be no need to reply to anyone). Docs: http://blackwhale.github.io/phobos/uni.html Source: https://github.com/blackwhale/phobos/tree/new-std-uni Stand Alone: https://github.com/blackwhale/gsoc-bench-2012 Review Thread: http://forum.dlang.org/post/xbuphdghoyymjajpf...@forum.dlang.org Sunday April 26 PST will be the last day of voting.
Re: Ideal D GUI Toolkit
On Monday, May 20, 2013 07:25:49 Tyler Jameson Little wrote: I'd also like to know the likelihood of getting a GUI toolkit into Phobos. It's come up before, and I don't think that any sort of decision has ever been made on that, though personally, that strikes me as the sort of thing that doesn't really belong in the standard library. Certainly, if it did end up in there, it would probably have to be very minamalistic. Also, I thought that general consensus had been that while it would be awesome to have a GUI toolkit written in D at some point, that's the sort of thing that takes a ton of time and effort, and we have enough other stuff that needs doing that the time and effort of the community was better spent on other things and that wrapping a C++ GUI toolkit was a better move for the forseeable future (with a full D GUI toolkit being something that might happen once D is much larger). But anyone who wants to work on a GUI toolkit in D is welcome to do it. IIRC, there was at least one small one done in D1 using OpenGL. And having at least a minimal one so that very basic GUIs could be written fully in D would certainly be very cool. Personally, I have too much other stuff to do and not very much expertise in this area, so it's the sort of thing that I'm very unlikely to be involved in and am likely to leave most of the decisions up to others who are much more versed in this sort of thing. - Jonathan M Davis
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Monday, 20 May 2013 at 06:10:22 UTC, Kenji Hara wrote:
I know at least two cases which T.init is commonly used.
1. Inside predicate template for type T.
template isSomething(T) {
enum isSomething = is(typeof({
//T t1;// not good if T is nested struct, or has
@disable this()
//T t2 = void; auto x = t2; // not good if T is
non-mutable type
T t = T.init; // avoid default construct check
...use t...
}));
}
2. Some library utilities that treats object state directly,
e.g.
std.conv.emplace
Kenji Hara
I see. But unfortunately this undermines @disable and defeats
arguments for using it. @disable is another feature (like ref and
@safe) which cannot be fixed be design.
Re: Ideal D GUI Toolkit
On 2013-05-20 07:25, Tyler Jameson Little wrote: I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion. Personally, I want these features: * simple and extensible * minimal components (something like HTMLs feature-set) * custom components (embed OpenGL/direct frame buffer) * native window decorations by default, but can provide custom decorations * markup (like QML) or programmable (like SWT) Nice-to-haves: * hardware accelerated (2D OpenGL) * GUI designer (much easier with QML-esque markup) * part of Phobos I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos. Thoughts? Creating a new GUI toolkit is a huge amount of work. It's more than you can imagine. A GUI toolkit for creating a window with a button isn't that much work. But it's all the rest of the stuff, that a toolkit can do and people will expect from it. Like stuff you didn't think of or even didn't know they existed. A GUI toolkit in Phobos will probably not happen. -- /Jacob Carlborg
Re: I want to add a Phobos module with template mixins for common idioms.
On Monday, 20 May 2013 at 05:39:42 UTC, Diggory wrote: In your logic you're assuming that the order of operations is maintained - without the correct memory barriers or synchronisation both the compiler and CPU are free to completely reorder any operations you do. That's why it's always a bug to access mutable shared data without synchronisation - any read not using some form of synchronisation could give you back any value that the memory is ever set to during the course of the program. It can't be THAT chaotic. Neither the compiler nor the CPU will perform a check on a value and then go back in time to fetch an old version of that value and return it. This kind of behavior would break non-threaded code.
Re: Ideal D GUI Toolkit
It's come up before, and I don't think that any sort of decision has ever been made on that, though personally, that strikes me as the sort of thing that doesn't really belong in the standard library. Certainly, if it did end up in there, it would probably have to be very minamalistic. That's exactly what I want, something to build off of. I'm thinking modeling it on Clutter or something like this: http://swtch.com/~rsc/thread/cws.pdf. The link is to a simple, nested windowing system that serves as the basic architecture of the Plan9 GUI. It's super simple and flexible. Everything would be asynchronous, and only the most essential components would be provided. Also, I thought that general consensus had been that while it would be awesome to have a GUI toolkit written in D at some point, that's the sort of thing that takes a ton of time and effort, and we have enough other stuff that needs doing that the time and effort of the community was better spent on other things and that wrapping a C++ GUI toolkit was a better move for the forseeable future (with a full D GUI toolkit being something that might happen once D is much larger). But anyone who wants to work on a GUI toolkit in D is welcome to do it. IIRC, there was at least one small one done in D1 using OpenGL. And having at least a minimal one so that very basic GUIs could be written fully in D would certainly be very cool. That's the feeling I got. If it's designed well, it might be one of the major things that draws people to D, and everyone would benefit from that. I'm willing to work on one, but I don't want to duplicate effort if the community is already standardizing on something. I ran into that earlier when I tried to expand std.json, only to find out that a std.serialize was in the works, hence the question. I can't say I'm an expert, but I've got a little extra time and I want to eventually build a game in D, and I need something to build off of.
Re: RFC: mysql-native - Supporting both Vibe.d and Phobos sockets
Should be fixed now. ATM, I don't have any code that's using the prepared statements feature, and I need to head out, so can you verify it? Yes, with those changes everything I'm working with now works as expected.
Re: Request d.vim testing
On Monday, 20 May 2013 at 02:24:44 UTC, Jonathan M Davis wrote: On Saturday, May 18, 2013 20:12:16 Jesse Phillips wrote: Hello Vim users, Sadly I don't have a good set of unittests for highlighting. I've made some changes and think that it will be good to have them part of vim 7.4 I'm requesting that you check that the new file has not butchered highlighting for you. https://github.com/JesseKPhillips/d.vim * ASM blocks highlight comments * in/out contracts no longer highlighted as storage class * If a module name is the same as a keyword it will not be highlighted on module declaration or import. * scope highlights as a statement, as a storage class in parameter list * pragma will highlight known commands (lib,msg) Using this new d.vim file, I get whole piles of errors just opening an empty .di file - starting off with Error detected while processing /home/jmdavis/.vim/syntax/d.vim line 4: E477: No ! allowed: !DOCTYPE html line 5: E488: Trailing characters: html and so on and so forth. I'm using vim 7.3 on Arch Linux. Maybe I need 7.4 for it to work? Or maybe something else in my setup is messed up. I only grabbed the syntax/d.vim file from your repo, since I don't know what the others are and don't currently have anything like them, so that may or may not be a factor. But based on the errors, it looks like my local version of vim just plain can't handle the new d.vim syntax file. - Jonathan M Davis Are you sure you downloaded it correctly? From the error message you got, it seems like you have downloaded the source of the GitHub page that displays the `syntax/d.vim` file.
Re: Vote for std.uni
On 20/05/2013 07:18, Jesse Phillips wrote: This is a replacement module for the current std.uni by Dmitry Olshansky. The std.uni module provides an implementation of fundamental Unicode algorithms and data structures. I vote YES! A...
Re: C++ constructors, destructors and operator access
On Saturday, 18 May 2013 at 22:23:51 UTC, Igor Stepanov wrote:
At the current time D have powerful mechanism of access to C++
classes.
For access to methods of C++ classes (virtual and not) we can
use extern(C++) interface.
//С++
class CPPTest1
{
int a;
int b;
public:
virtual int boom();
int fun();
static int gun();
CPPTest1(int);
virtual ~CPPTest1();
int operator[](size_t);
};
class CPPTest2: public CPPTest1
{
int boom();
};
//D
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
}
extern(C++)interface CPPTest2: CPPTest1
{
//int boom();
}
As a rule, non-static fields are not public in C++ classes and
is not part of interface. Thus the most of C++ classes can be
bound without any glue c++ code.
However D dont support C++ overloaded operators and
constructors. Yes, we cannot make mapping C++ operators to D
operators and C++ constructors to D constructors). Nonetheless
С++ operators and constructors are the simple C++ functions or
methods with special mangling. Thus I've suggest next mechanism:
Allow special pragma(cppSymbol, string_arg), when string_arg is
the name of c++ thing.
Example:
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
///
pragma(cppSymbol, constructor) final void ctor(int);
//linked with CPPTest1(int);
pragma(cppSymbol, destructor) void dtor(); //linked with
virtual ~CPPTest1();
pragma(cppSymbol, []) ref int indexOf(size_t); //linked
with int operator[](size_t);
}
This pragma must apply to the function (or method), use natural
C++ mangle, but set operatror or constructor or destructor
mangled name instead of function name.
Is it useful idea?
you can do this yourself just with mixins and templates, but the
real problem is c++ abi and name mangling. so you will need to do
runtime search for c++ mangled names and which runtime used, get
it and call placement new and ctor(with the help of asm{} of
course), do the same for other operators. it is possible, but
this is never be safe at least due to non-standardized name
mangling.
you can write small library which would help doing this all if
you really want this.
Re: Request d.vim testing
On Saturday, 18 May 2013 at 18:12:17 UTC, Jesse Phillips wrote: Hello Vim users, Sadly I don't have a good set of unittests for highlighting. I've made some changes and think that it will be good to have them part of vim 7.4 Here's the test file for D highlighting for the colorer library: https://svn.code.sf.net/p/colorer/svn/trunk/schemes/hrc/test/other/d-sample.d Hope this helps.
Re: RFC: mysql-native - Supporting both Vibe.d and Phobos sockets
On Mon, 20 May 2013 07:28:29 +0200 dennis luehring dl.so...@gmx.net wrote: Am 18.05.2013 17:42, schrieb Gary Willoughby: Hi, i've tried using this library for a simple query and i run into an error. I wondered if this is a bug in the connection code. wouldn't it be a good idea to port the official mysql_client_test.c or parts of it into the unit test? its huge but seem to test every (corner) case around http://bazaar.launchpad.net/~mysql/mysql-server/5.7/view/head:/tests/mysql_client_test.c I'm assuming that's [L]GPL, right? If so, then I don't think it could be used in whole, in part, or in any modified form, in mysql-native (Boost license). However, maybe it could safely be done as a separate tester for mysql-native project? (Of course, IANAL, so I don't know what the hell I'm talking about. YMMV. OMG WTF BBQ. Etc...)
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sunday, 19 May 2013 at 21:36:17 UTC, Andrei Alexandrescu wrote: OK, this is sensible. One question - would you be willing to type symbols as NullType!T instead of T to avoid these issues? Good question. Probably not. I think it's one of those things were the awkwardness of it not being the default would lead to lack of use (in the same way usage of pure suffers from not being default).
Re: Request d.vim testing
On Monday, May 20, 2013 10:04:22 Idan Arye wrote: Are you sure you downloaded it correctly? From the error message you got, it seems like you have downloaded the source of the GitHub page that displays the `syntax/d.vim` file. LOL. Yeah, that looks like it's what I did. I think that I got it correctly now though, and it seems to work (or at least, it works well enough that I can open .d files using it now without any errors - I haven't messed around with it enough yet to determine if it's having any further issues). - Jonathan M Davis
Re: Binding D to C
On Sat, 18 May 2013 14:10:07 +0100, Jacob Carlborg d...@me.com wrote: On 2013-05-17 16:48, Regan Heath wrote: Done. http://wiki.dlang.org/Bind_D_to_C Hmm. I see you just copy pasted my answer. It fits as an answer in a newsgroup like this. But I don't think it fits in that format in the wiki. That's what I said I'd do.. it's all I have time for. I think having the info there, even if it doesn't necessarily follow is better than not. Someone with more time can improve upon it. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Request d.vim testing
On 20 May 2013 10:08, Vladimir Panteleev vladi...@thecybershadow.netwrote: On Saturday, 18 May 2013 at 18:12:17 UTC, Jesse Phillips wrote: Hello Vim users, Sadly I don't have a good set of unittests for highlighting. I've made some changes and think that it will be good to have them part of vim 7.4 Here's the test file for D highlighting for the colorer library: https://svn.code.sf.net/p/**colorer/svn/trunk/schemes/hrc/** test/other/d-sample.dhttps://svn.code.sf.net/p/colorer/svn/trunk/schemes/hrc/test/other/d-sample.d Hope this helps. Thanks Vladimir, I'll test this against cgdb as well. =) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: I want to add a Phobos module with template mixins for common idioms.
On Monday, 20 May 2013 at 06:53:34 UTC, Idan Arye wrote: On Monday, 20 May 2013 at 05:39:42 UTC, Diggory wrote: In your logic you're assuming that the order of operations is maintained - without the correct memory barriers or synchronisation both the compiler and CPU are free to completely reorder any operations you do. That's why it's always a bug to access mutable shared data without synchronisation - any read not using some form of synchronisation could give you back any value that the memory is ever set to during the course of the program. It can't be THAT chaotic. Neither the compiler nor the CPU will perform a check on a value and then go back in time to fetch an old version of that value and return it. This kind of behavior would break non-threaded code. Of course it's possible, for example the code may produce the expected result if some invariant holds which does in fact hold if there was a single thread running, but with multiple threads the invariant is broken. Or more simply - the fact remains that you are writing on one thread (correctly using synchronisation) and reading from another (not using synchronisation) and synchronisation is required on both the read and the write. The compiler/CPU is then free to reorder the reads under the assumption that the value won't change, and this assumption is clearly wrong. Basically most of your argument is just hoping that it will behave the way you want, but without having any real guarantees, and that's not the way to write thread-safe code, especially if it's going to be part of the standard library.
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sun, 19 May 2013 21:02:11 +0200, Idan Arye generic...@gmail.com wrote:
I don't see how Option and Maybe would have helped your bug. The problem
was that somewhere in the code the reference was perceived as null while
in fact it wasn't
What does that even mean?
- so now it will be perceived as `None`, and you will have the same
problem.
Except that now the code would be forced to handle the None case. In a way,
having nullable by default is like having a stringly typed system:
function foo( s ) {
return (s + 4) * 2; // Works great when s == 16, falls dead on its
// back when s == goobers.
}
function bar( int i ) {
return (i + 4) * 2;
}
These functions look very different. That's because they are. One of them
only takes valid parameters, the other takes any old garbage and barfs
when the wrong garbage is given to it.
Of course, if you have a string, and you want to call bar, you need to
convert the string to an int. So you end up with this:
function baz( string s ) {
return s.parseInt(
i = bar(i),
{ alert(error); });
}
Notice how the parseInt function takes two delegates? One of these
(the first) is only called when the string is valid. The other is only
called if the string is invalid. That way, we can be sure that the
failure case is handled.
Exactly the same would be the case for non-nullable pointers - if you
want to convert a nullable pointer to non-nullable, you *have* to
handle the failure case. No two ways about it.
Now, the same example with class references:
int foo(A a) {
return a.qux(); // Works great when a == new A(), falls dead on its
// back when a == null.
}
int bar(NonNull!A a) {
return a.qux();
}
See how one of these does not blow up in your face (unless you do
something stupid like create a special Nil value that will do exactly
that)? Now, for baz:
int baz(A a) {
return a.match(
(NonNull!A a) = bar(a),
(None) = -1
);
}
And this is the exact problem with nullable by default : plenty of
stuff ends up be null is some weird situation that almost never occurs
when they are assumed not to be and the program crashes.
NullPointerException now return 4 millions result on google, which is
probably around once per java developers.
This is not a problem with nullable by default - it is a problem with
implicit default values. null(or Nil, or None) are the only sane default
values for reference types - I think you would agree that having to
construct a new blank object as default value for every reference
variable would be far worse than null...
If you absolutely cannot initialize the pointer to something sensible,
then use a nullable pointer. But if non-nullable pointers are not
available, or are harder to use than nullable pointer, then people will
use nullable pointers even where non-nullable would have been a much
more fitting choice.
It does not solve the bug - it is something you HAVE to do given the
assumptions. If the reference is not nullable, and you can't set it to
it's real value until later in the code, then you have to initialize it
to some temporary value.
I don't know enough about the bug to say such things for sure, but I will
say this: If deadalnix solved the bug, he is likely in a much better
position to say anything about what would solve the problem than the rest
of us.
--
Simen
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sun, 19 May 2013 20:05:02 +0200, Idan Arye generic...@gmail.com wrote: These are the assumptions I'm working with: - We can't use a nullable reference - We can't initialize the reference upon declaration to it's real value. Indeed, if that's the case, then what you're doing is fairly sensible. But if #2 is true, then #1 should never be true. -- Simen
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sun, 19 May 2013 20:23:21 +0200, Walter Bright newshou...@digitalmars.com wrote: On 5/19/2013 5:02 AM, Simen Kjaeraas wrote: By definition? Pointer semantics are what we choose it to mean. Of course. But which definition is saner: For many types, it is extremely useful to have some sort of invalid value for it. null fills that role nicely for pointers, just as nan does for floating point types, and 0xFF does for UTF-8. There's not anything insane about it. The Nullable type constructor even exists in order to provide such an invalid state for types (like int) which normally do not have one. Yes, I do understand there's a role for pointers which cannot hold the invalid value. I contend that not only is there a role for them, but that most pointers should never be null. Here's two questions that convinced me: 1. How many functions that take a pointer or class reference make sense to call with null in that pointer/reference? 2. If pointers were non-nullable by default, how often would you need to reach for the nullable one? I argued in another post that nullable by default is analogous to using a string instead of an int - any number representable in an int is representable in a string, *and* the string can represent error states. But if you only want valid ints, there's no reason to use a string. -- Simen
Re: C++ constructors, destructors and operator access
Igor Stepanov wazar.leoll...@yahoo.com wrote in message news:pckdwxwvumenyzbuv...@forum.dlang.org... Yes, language shouldn't be modified for the sake of one goal. But do you think, that calling C++ constructors from D is not typical task? I sure, that we must get a common way to bind C++ classes to D. No templates, no exceptions. But operators and constructors/destructors is needed. It may be special tool, that eat C++ header and return D file + C++ glue file. This util should transform all fields and constructors to D final methods for extern(C++) interface. In addition to this tool we can make a D binding layer, which simplify typical operations such as creating C++ objects using ::operator new() (or class operator new() if in exists) and destroying with operator delete() (local or global). Mapping constructors is complicated... Do they have the same semantics in both languages? Both on the heap and on the stack? Eg. how on earth do you map a default constructor for a struct? Same problems with destructors. Which allocator do you use for the heap? etc Operator overloads are much worse, they just don't all map. Do we support part of the set? Or add the missing ones to D? eg comparison operators By the way: Why D disallow static __gshared C++ variables in classes? This is a principled feature (if yes: why?) or omission? It does? Is this problem linux only? I don't see any reason why it would be excluded on purpose. That said, extern(C++) is mostly untested. There are some truly awful bugs lurking if you try to use complicated types/declarations. This is slowly improving.
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
I'm surprised people still have problems with null pointers. I for one am glad D has null by default makes life easy coming from C++ and Java. I may have missed something but what happens with the following code if I could not have a null pointer? int*[] pntrs = new int*[10]; Would I need to write something like? Null!(int*)[] pntrs = new Null!(int*)[10]; Personally, I'd rather have null by default as I find it less noisy and I don't need it spelled out in the code, it is implied. No it sound like initalizing something to null, then initialize it properly, assume all over the place that it is initialized to something else, and in some rare code path it blows up. OK, so the D gurus kindly introduce for us NotNull!T, Maybe!T, Option!T and SegFault!T (just for me). Now I want to access a pointer, write code using it etc. But I need to manually track at development time whether it is NotNull!T, Null!T, Maybe!T, Option!T or whatever. I cannot just have a pointer anymore, knowing it's initialised to null. Now I realise it needs to change from NotNull!T to Maybe!T...great yet more refactoring. Ok refactoring done (yay sed!) but you know what, now I need to find every access to that pointer and check for null. More error prone than this: If you are in doubt (i.e. most multi-threaded apps) then check if null, with the added comfort that D has initialised all pointers to NULL for you. If still in doubt, don't use pointers. If you want non-null pointers (please no) then it is all or nothing. Allowing some pointers null and others not, via Nullable!T or NotNull!T, immediately adds another layer of complexity. I don't want to hear: D pointers cannot be null...well ok, they can sometimes, it depends, you'll have to read the code. But don't worry, D is very easy to read... My 1 cent. Disregard if I have totally misunderstood the thread, possible as it is very late! :-) Cheers, Stewart
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Monday, 20 May 2013 at 14:49:32 UTC, estew wrote: Now I want to access a pointer, write code using it etc. But I need to manually track at development time whether it is NotNull!T, Null!T, Maybe!T, Option!T or whatever. I cannot just have a pointer anymore, knowing it's initialised to null. Yes and this is awesome. This is correctness enforced by type system. Because if you _don't_ track this, you have a possible error in your code. Only difference between nullable and non-nullable pointers by default is that latter _force_ you to write correct code. Which is good.
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sun, 19 May 2013 17:36:17 -0400, Andrei Alexandrescu wrote:
On 5/19/13 4:30 PM, Peter Alexander wrote:
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote:
You are blowing it out of proportion. Null references are hardly even
on the radar of the bug classes I'm encountering in the style of
programming of the three groups I worked in at Facebook, and also my
previous employers. People I meet at conferences and consulting gigs
never mention null references as a real problem, although I very often
ask about problems. I find it difficult to agree with you just to be
nice.
Just because people don't mention them as a problem doesn't mean it
isn't a problem.
For what it's worth, null pointers are a real problem in the code I
work on (games). I don't know exactly what you work on, but I find that
they are more of a problem in highly stateful, interactive
applications. Things like generic libraries, utility programs,
compilers, etc. probably won't see the same problems because they
aren't very stateful or interactive.
In my experience, null pointers are easy to fix, but the risk of them
causes people to litter their code with if (ptr) tests, often with poor
handling of the failure case, which can cause subtle bugs (no crash,
but unintended code path).
Just my 2c.
OK, this is sensible. One question - would you be willing to type
symbols as NullType!T instead of T to avoid these issues?
Thanks,
Andrei
More boiler plate code for functions that take pointers.
void foo(T)(T t)
if(isPointer!T)
{
static if(isNullable!T)
if(!t) throw
}
May also introduce then need to check for objects in the init state
(default state)
outside of NonNull in stdlib, an attribute maybe a possible answer.
void bar(@nonnull SomeClass o)
{
o = foo(); // if foo returns @nonnull, then check is not needed,
else needs a check added during assignment
}
there are a few compile time checks that can be done to prove o is not
null, if not the compiler adds runtime checks.
But really, checking for valid input is part of programming, might be
better to have lint integration that can help find these types of problems
opDispatch and operator overloads
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if opDispatch could catch missing
operator overloads.
Also, would it be a good idea to have free functions of all the
operators (opOpAssign etc...) for builtin types somewhere? It's
occasionally useful in generic wrappers.
Re: DSoC + Kickstarter?
On Saturday, 18 May 2013 at 08:33:10 UTC, Mr. Anonymous wrote: As you probably know, the application of D to GSoC 2013 has been rejected. There was an idea about running the program nonetheless, minus the funding: http://forum.dlang.org/post/mailman.613.1365489754.4724.digitalmars-d-annou...@puremagic.com Can't we use Kickstarter to fund it? Seems like KolibriOS did exactly this: http://www.kickstarter.com/projects/kolibrios/kolibrios-help-us-hold-our-own-summer-of-code-2013 It's probably too late for D now, though.
Re: I want to add a Phobos module with template mixins for common idioms.
On Monday, 20 May 2013 at 11:19:44 UTC, Diggory wrote: Of course it's possible, for example the code may produce the expected result if some invariant holds which does in fact hold if there was a single thread running, but with multiple threads the invariant is broken. Or more simply - the fact remains that you are writing on one thread (correctly using synchronisation) and reading from another (not using synchronisation) and synchronisation is required on both the read and the write. The compiler/CPU is then free to reorder the reads under the assumption that the value won't change, and this assumption is clearly wrong. I do not assume that the compiler or the CPU will not change the order of reads in the unsynchronized thread - I showed that the result of `hasInstance()` is not affected by such reordering! `hasInstance()` has a single read to __gshared memory, and the only thing that can effect the result of that read is a write to that memory, which is done *once* in the synchronized thread. That means I should only care when the read in `hasInstance()` happens related to that write. I have shown that whether the read happens before the write, or the write happens before the read, or they happen at the same time, or the write is split and the read is done between the two parts of the write, or the other way around, or if both the read and write are split and their parts are performed alternately - no matter what, `hasInstance()` yields a result I can rely on. Since `hasInstance()` produces reliable results even if it gets mixed in the timeframe of the instantiation in another thread - I see no reason to do a costly synchronization to prevent the mixing. I have tried to form a similar proof for the static branch in `instance()` that handles the no-default-constructor case, and realized that this one does need synchronization, because the compiler might decide to set the reference before it runs the initialization of the object. Even though the result it will return will be the correct reference to the instance, the instance object itself might not be ready. So, I'm making that part synchronized, simply to force `instance()` to wait until the instance object has finished it's instantiation.
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On 5/19/13 8:46 PM, Steven Schveighoffer wrote: I just wanted to chime in with this understanding of the bug that I am reading from deadalnix's descriptions: SomeObj obj; shareTheObj(obj); // goes to other threads obj = new SomeObj; // initialize obj This is likely simpler than the actual problem, but I think this is the gist of it. A Non-Nullable solution WOULD solve the race: SomeObj obj; // Compiler: nope, can't do that, must initialize it. Now, with an invalid state not available like null, is the developer more likely to go through the trouble of building an invalid state for obj, in order to keep the racy behavior? No. He's just going to move the initialization: SomeObj obj = new SomeObj; shareTheObj(obj); In essence the point of the anecdote is that a Non-Nullable reference would have PROMOTED avoiding the race condition -- it would have been harder to keep the racy behavior. One can only assume the entire point was to delay initialization of the object to its first use/sharing point, so the changed pattern simply initializes the object eagerly, thus missing the benefits of the pattern. Otherwise that's an instance of the old adage initialize variables at the point of definition. That, granted, non-null references do help with. Andrei
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On 5/20/13 11:19 AM, Byron Heads wrote:
On Sun, 19 May 2013 17:36:17 -0400, Andrei Alexandrescu wrote:
OK, this is sensible. One question - would you be willing to type
symbols as NullType!T instead of T to avoid these issues?
Thanks,
Andrei
More boiler plate code for functions that take pointers.
void foo(T)(T t)
if(isPointer!T)
{
static if(isNullable!T)
if(!t) throw
}
But this goes both ways. Regardless of the default, you'd sometimes need
to distinguish between cases. You either hurt one half of your cases or
the other half. In fact you are now showing the case that assumes
non-nullable being the default.
May also introduce then need to check for objects in the init state
(default state)
outside of NonNull in stdlib, an attribute maybe a possible answer.
void bar(@nonnull SomeClass o)
{
o = foo(); // if foo returns @nonnull, then check is not needed,
else needs a check added during assignment
}
there are a few compile time checks that can be done to prove o is not
null, if not the compiler adds runtime checks.
I think a parameterized type is a better match for non-null because it
attaches to the type, not the symbol.
But really, checking for valid input is part of programming, might be
better to have lint integration that can help find these types of problems
Agreed.
Andrei
Re: Vote for std.uni
On Monday, 20 May 2013 at 06:18:15 UTC, Jesse Phillips wrote: Sunday April 26 PST will be the last day of voting. 2014? vote: yes
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Mon, 20 May 2013 11:43:35 -0400, Andrei Alexandrescu wrote:
On 5/20/13 11:19 AM, Byron Heads wrote:
On Sun, 19 May 2013 17:36:17 -0400, Andrei Alexandrescu wrote:
OK, this is sensible. One question - would you be willing to type
symbols as NullType!T instead of T to avoid these issues?
Thanks,
Andrei
More boiler plate code for functions that take pointers.
void foo(T)(T t)
if(isPointer!T)
{
static if(isNullable!T)
if(!t) throw
}
But this goes both ways. Regardless of the default, you'd sometimes need
to distinguish between cases. You either hurt one half of your cases or
the other half. In fact you are now showing the case that assumes
non-nullable being the default.
May also introduce then need to check for objects in the init state
(default state)
outside of NonNull in stdlib, an attribute maybe a possible answer.
void bar(@nonnull SomeClass o)
{
o = foo(); // if foo returns @nonnull, then check is not needed,
else needs a check added during assignment }
there are a few compile time checks that can be done to prove o is not
null, if not the compiler adds runtime checks.
I think a parameterized type is a better match for non-null because it
attaches to the type, not the symbol.
But really, checking for valid input is part of programming, might be
better to have lint integration that can help find these types of
problems
Agreed.
Andrei
What about dealing with externs you want to protect?
extern(C) void foo(@nonnull int* x);
other then that I think the library solution is fine
@nonnull Bar* b = NotNull!(NotNull!Bar) b
Re: Request d.vim testing
On Saturday, 18 May 2013 at 18:12:17 UTC, Jesse Phillips wrote: Hello Vim users, Sadly I don't have a good set of unittests for highlighting. I've made some changes and think that it will be good to have them part of vim 7.4 I'm requesting that you check that the new file has not butchered highlighting for you. Here are the results on my Vim 7.3 on Linux: http://postimg.org/image/cgtkbhr0t/ hybrid.vim was OK so I didn't put it in the screenshot(also I couldn't fit them all to screen height...) * ASM blocks highlight comments /* */ comments are good, but /+ +/ comments are not ended. This is also true outside ASM blocks. * in/out contracts no longer highlighted as storage class Works * If a module name is the same as a keyword it will not be highlighted on module declaration or import. Made worse - in the original syntax `assert` was not highlighted when used as module name. `string` and `void` are still highlighted as module names. * scope highlights as a statement, as a storage class in parameter list Works * pragma will highlight known commands (lib,msg) Doesn't work
Re: Request d.vim testing
On 20 May 2013 10:51, Iain Buclaw ibuc...@ubuntu.com wrote: On 20 May 2013 10:08, Vladimir Panteleev vladi...@thecybershadow.net wrote: On Saturday, 18 May 2013 at 18:12:17 UTC, Jesse Phillips wrote: Hello Vim users, Sadly I don't have a good set of unittests for highlighting. I've made some changes and think that it will be good to have them part of vim 7.4 Here's the test file for D highlighting for the colorer library: https://svn.code.sf.net/p/colorer/svn/trunk/schemes/hrc/test/other/d-sample.d Hope this helps. Thanks Vladimir, I'll test this against cgdb as well. =) First question that I have: Does 'Object' *need* to be syntax highlighted? Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: I want to add a Phobos module with template mixins for common idioms.
20-May-2013 19:28, Idan Arye пишет: On Monday, 20 May 2013 at 11:19:44 UTC, Diggory wrote: Of course it's possible, for example the code may produce the expected result if some invariant holds which does in fact hold if there was a single thread running, but with multiple threads the invariant is broken. Or more simply - the fact remains that you are writing on one thread (correctly using synchronisation) and reading from another (not using synchronisation) and synchronisation is required on both the read and the write. The compiler/CPU is then free to reorder the reads under the assumption that the value won't change, and this assumption is clearly wrong. I do not assume that the compiler or the CPU will not change the order of reads in the unsynchronized thread - I showed that the result of `hasInstance()` is not affected by such reordering! `hasInstance()` has a single read to __gshared memory, and the only thing that can effect the result of that read is a write to that memory, which is done *once* in the synchronized thread. That means I should only care when the read in `hasInstance()` happens related to that write. Long story short - re-read the discussion in the Low-lock thread again: http://forum.dlang.org/thread/pelhvaxwjzhehdjtp...@forum.dlang.org -- Dmitry Olshansky
Re: opDispatch and operator overloads
On Monday, May 20, 2013 17:15:32 John Colvin wrote: Also, would it be a good idea to have free functions of all the operators (opOpAssign etc...) for builtin types somewhere? It's occasionally useful in generic wrappers. Why would this be useful? I think that it's just begging for trouble to be able to add stuff like foo + bar to the language via free functions. We don't _want_ that to be legal. That's why we have ~ in the first place. If you need to do something that you want to work with built-in types, and their operators don't do what you want, then just use a normal function rather than an operator. If you can't model your overloaded operator after what an operator does for the built-in types, it's arguably a bad choice to use an overloaded operator for that in the first place. - Jonathan M Davis
Re: Ideal D GUI Toolkit
Tyler Jameson Little beatgam...@gmail.com wrote in message news:vtaufckbpdkpuxyzt...@forum.dlang.org... I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. [snip] Thoughts? I don't know much about Qt's source, but automatic conversion to D, like we are doing for the compiler, might be worth looking into. If it is written in modern-ish C++ (not too many preprocessor hacks), which from a quick look it appears to be, this might be a much more reasonable task than writing a new gui lib from scratch.
Re: Ideal D GUI Toolkit
On Tuesday, May 21, 2013 03:33:01 Daniel Murphy wrote: I don't know much about Qt's source, but automatic conversion to D, like we are doing for the compiler, might be worth looking into. If it is written in modern-ish C++ (not too many preprocessor hacks), which from a quick look it appears to be, this might be a much more reasonable task than writing a new gui lib from scratch. IIRC, they use macros quite a bit for various stuff (like signals and slots), and they have their own version of make to set up some stuff for you. So, my first guess is that conversion would be a bit of a beast. But it's been a while since I did much with Qt. - Jonathan M Davis
Re: Migrating D front end to D - post Dconf
On Thursday, 9 May 2013 at 10:15:42 UTC, Iain Buclaw wrote: I'll will very likely keep a branch with the C++ implemented front end for these purposes. But ideally we should get porting as soon as possible ahead of this move so that there are already D compilers available for said targets. Though it would be nice for the D implementation to be kept to a subset that is backwards compatible with 2.062 (or whatever version we decide to make the switch at), that is something I cannot guarantee. Regards Could compiling the D compiler in D to llvm bytecode on a working platform and then compiling the bytecode on target platform solve the issue (at least a part of it)?
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sun, 19 May 2013 05:17:57 +0200, Walter Bright newshou...@digitalmars.com wrote: On 5/18/2013 1:39 PM, Walter Bright wrote: Already reported: http://d.puremagic.com/issues/show_bug.cgi?id=10115 And Kenji has already posted a fix! What can I say, other than Awesome! Great! One more: http://d.puremagic.com/issues/show_bug.cgi?id=1528 -- Simen
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Mon, 20 May 2013 18:05:18 +0200, Byron Heads byron.he...@gmail.com wrote: What about dealing with externs you want to protect? extern(C) void foo(@nonnull int* x); There is nothing stopping you from declaring that with this signature: extern(C) void foo(NonNull!(int*) x); -- Simen
Re: Ideal D GUI Toolkit
On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little beatgam...@gmail.com wrote: I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion. Personally, I want these features: * simple and extensible * minimal components (something like HTMLs feature-set) * custom components (embed OpenGL/direct frame buffer) * native window decorations by default, but can provide custom decorations * markup (like QML) or programmable (like SWT) Nice-to-haves: * hardware accelerated (2D OpenGL) * GUI designer (much easier with QML-esque markup) * part of Phobos I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos. Thoughts? So I've been around D a while pushing for native D UI toolkit. And here are a few trends I've seen in the community. * There is a deep-seated distrust of any toolkit that does not use the OS Native UI widgets. The people in this community prefer native toolkits to the point of jihad. Now I am a XAML guy myself, and I saw the light a long time ago, but around here, the majority are still command line gurus. * There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there. GUI toolkits are too use-case specific to belong in a standard library. However, if we can make (and I think we can) a truly cross-platform UI toolkit, we can make a stronger case for using at a standard UI toolkit. * Nobody believes that we can do it, you'll hear a lot of moaning about how much work it is. My reply to that is: And Linux is such a piece of cake right? It's only the most widely used kernel on the planet. Here's the deal. Building a GUI toolkit, particularly a useful one, is a massive undertaking. WPF is the single largest library in all of .NET. IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will require something that D itself does not. A highly dedicated team of people with many diverse skills. The project is simply too big for a single person. Part of the problem with UI toolkits is the number of skills you'll need for the team. Graphics programmers who can make GPU's sing, API designers who can make it easy access, UI designers capable of replicating the looks of each OS. Experts for each targeted OS. And I can think of more. My point here is not to be discouraging, I want a UI toolkit with capabilities similar to WPF in D probably more than anybody else here. But I want to be realistic about the effort required. The dedication required is immense, you'll be writing code for months before you even get anything on the screen. Here is another factor to consider. A UI toolkit must be designed. You won't have the luxury of Phobos of design-by-iteration simply because you'll be throwing out entire systems. For example a fairly complete render path is required before you can show anything on the screen. But what happens when your render-path is too OS specific? Oops, you pitch months of work and start over from scratch. But now you have to rebuild everything you've built on top of it. Do that a few times and you'll give up because you can never seem to get anywhere. The smart thing to do is sit down with a knowledgeable group of people and design the system, the design doesn't have to be perfect or complete, but it does need to provide a framework to work within and vision to guide the team. Lastly, we'll need something that D doesn't have much of, but Linux does. Leadership. You can't pull together something this complex without someone or someones holding the bigger picture in their heads, otherwise you'll end up with a mish-mash of contradictory merged pulled requests. In my experience in Open-Source, it's never a problem to find people who have vision and want to lead a project. The problem is finding people who agree with the vision enough to help without wanting to be in charge because they really know better. FOSS's major drawback is the ridiculous amounts of duplication. I don't see a WPF-style UI toolkit as duplication because as near as I can tell there is nothing like WPF in the OSS world, but, everybody has their own opinion about HOW it should be done and almost nobody is willing to swallow their ego, quit sweating the small stuff, and work towards a common goal, even if they don't agree 100%. A UI
Re: I want to add a Phobos module with template mixins for common idioms.
On Monday, 20 May 2013 at 16:40:27 UTC, Dmitry Olshansky wrote: Long story short - re-read the discussion in the Low-lock thread again: http://forum.dlang.org/thread/pelhvaxwjzhehdjtp...@forum.dlang.org To sum up the discussion, there are three problems with unsynchronized access to the __gshared instance reference: 1) Unbaked object - the writer might write the __gshared reference before it finished the construction of the actual object. 2) Non-atomic read/write - this could result in a bad reference where the reader get some bytes from the old reference and some bytes from the new reference. 3) Unsynchronized cache - reader reads the reference, but the part of it's cache that is mapped to the memory containing the object instance itself is out of date and has not received the object yet. All these problems do not affect `hasInstance()` - which is the only part of my implementation that touches the __gshared reference without synchronization - simply because it does not touch the object and does not return the reference - it only checks if it's initialized: 1) It doesn't matter if the object is not ready, because when you want to actually access the object, you need to use `instance()` which has synchronization. 2) It does not matter if we get half a reference due to non-atomic read/write, because we only care if it's null or not. If the half reference we got is not null, that means the whole reference is not null and we have the correct answer. If the half reference we got is null - well, maybe the other half is not null, but the reference is only now being made not-null, so no harm is done it treating it as null for now(if we actually try to initialize it we will enter synchronization). 3) Since we don't try to access the object itself, we don't care that our local cache doesn't have it yet. Again - once we reach for the object itself, we will enter synchronization.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 07:25:49 +0200, Tyler Jameson Little wrote: I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion. Personally, I want these features: * simple and extensible * minimal components (something like HTMLs feature-set) * custom components (embed OpenGL/direct frame buffer) * native window decorations by default, but can provide custom decorations * markup (like QML) or programmable (like SWT) Nice-to-haves: * hardware accelerated (2D OpenGL) * GUI designer (much easier with QML-esque markup) * part of Phobos I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos. Thoughts? FLTK might be easier the Qt. Also libcairo maybe used if you build one yourself.
Re: Vote for std.uni
On Monday, 20 May 2013 at 06:18:15 UTC, Jesse Phillips wrote: Sunday April 26 PST will be the last day of voting. Err, May 26.
Re: opDispatch and operator overloads
On 05/20/2013 07:19 PM, Jonathan M Davis wrote: On Monday, May 20, 2013 17:15:32 John Colvin wrote: Also, would it be a good idea to have free functions of all the operators (opOpAssign etc...) for builtin types somewhere? It's occasionally useful in generic wrappers. Why would this be useful? I think that it's just begging for trouble to be able to add stuff like foo + bar to the language via free functions. We don't _want_ that to be legal. That's why we have ~ in the first place. If you need to do something that you want to work with built-in types, and their operators don't do what you want, then just use a normal function rather than an operator. If you can't model your overloaded operator after what an operator does for the built-in types, it's arguably a bad choice to use an overloaded operator for that in the first place. - Jonathan M Davis He just wants to be able to write: assert(2.opBinary!+(3) == 5); Which is entirely reasonable. This could be fixed by adding the corresponding built-in member function templates to the primitive types. (Note that this would also disallow adding eg. foo + bar even when the UFCS/op-overload incompatibility is fixed.)
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@gmail.com wrote: Graphics programmers who can make GPU's sing, [...] UI designers capable of replicating the looks [REPLYER'S EDIT: and feel] of each OS. Embrace native and those two concerns disappear. And that latter of those two is *NEVER* going to be pulled off successfully with a non-native toolkit anyway.
Re: opDispatch and operator overloads
On 05/20/2013 05:15 PM, John Colvin wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if opDispatch could catch missing operator
overloads.
Agreed. DMD arbitrarily refuses a combination of language features. I
think it is a compiler bug.
Also, would it be a good idea to have free functions of all the
operators (opOpAssign etc...) for builtin types somewhere?
I think built-in members are a better choice than free functions, as the
operators are built-in. (Also, note that operator overloading is
implemented in DMD in such a way that it is incompatible with UFCS,
which does not match the language specification either).
It's occasionally useful in generic wrappers.
Yes. Maybe you could file a bug report against the opDispatch part and
an enhancement request for the built-in members part.
http://d.puremagic.com/issues/
Re: I want to add a Phobos module with template mixins for common idioms.
20-May-2013 22:14, Idan Arye пишет:
On Monday, 20 May 2013 at 16:40:27 UTC, Dmitry Olshansky wrote:
Long story short - re-read the discussion in the Low-lock thread again:
http://forum.dlang.org/thread/pelhvaxwjzhehdjtp...@forum.dlang.org
To sum up the discussion, there are three problems with unsynchronized
access to the __gshared instance reference:
1) Unbaked object - the writer might write the __gshared reference
before it finished the construction of the actual object.
2) Non-atomic read/write - this could result in a bad reference where
the reader get some bytes from the old reference and some bytes from the
new reference.
3) Unsynchronized cache - reader reads the reference, but the part of
it's cache that is mapped to the memory containing the object instance
itself is out of date and has not received the object yet.
All these problems do not affect `hasInstance()` - which is the only
2 3 do.
part of my implementation that touches the __gshared reference without
synchronization - simply because it does not touch the object and does
not return the reference - it only checks if it's initialized:
It _reads_ the _shared_ reference without proper indication of this
intent to the writers.
1) It doesn't matter if the object is not ready, because when you want
to actually access the object, you need to use `instance()` which has
synchronization.
Then where you see hasInstance to fit the bill?
2) It does not matter if we get half a reference due to non-atomic
read/write, because we only care if it's null or not. If the half
reference we got is not null, that means the whole reference is not null
and we have the correct answer.
Or you may never get the reference updated until the cache got flushed.
It's generally not defined when you will see the update until then (or
some such hardware event). The word is *eventually*.
If the half reference we got is null -
well, maybe the other half is not null, but the reference is only now
being made not-null, so no harm is done it treating it as null for
now(if we actually try to initialize it we will enter synchronization).
So it doesn't matter if hasInstance is fulfilling it's questionable
contract properly only sometimes.
3) Since we don't try to access the object itself, we don't care that
our local cache doesn't have it yet. Again - once we reach for the
object itself, we will enter synchronization.
The big question is how you imagine somebody would want to use this
The false case may stay this way for unknown amount of time for instance
even after the initialization happened (on some architectures). At the
very least make that read atomicLoad that will make the operation
properly tied to the current view of memory.
Even if we assume it's atomic then the other big question is what is the
use case.
I argue that hasInstance only welcomes poor designs like:
while(!hasInstance()){
//busy wait for somebody else to init it?
}
inst = instance();
or:
if(hasInstance()){
//should be initialized then the call won't construct it
... //dunno what advantage it gets
}
else{
//might or might not initialize/block on call to instance()
...//again dunno
}
I'd say:
If you need to poke under it to avoid initialization then you shouldn't
be using lazy-init singleton in the first place.
If you need synchronization and coordination based on what the reference
happens to be right now then there are tools far better fit for the job
- mutexes, semaphore, condition vars etc.
The last but not least is the fact that LowLock returns TLS reference to
a (__g)shared instance make me worry about how the users code now is
full of hidden race conditions anyway. This applies to the pattern as
presented not only your implementation of it.
So the singleton itself would need some synchronization... and for that
it really should be marked shared. The alternative is to have a
per-thread singleton without any locking.
--
Dmitry Olshansky
Re: opDispatch and operator overloads
On Monday, 20 May 2013 at 15:15:33 UTC, John Colvin wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if opDispatch could catch missing
operator overloads.
This would also leads to bugs when invalid code is silently
accepted in each user-defined type where opDispatch is defined.
Also, would it be a good idea to have free functions of all the
operators (opOpAssign etc...) for builtin types somewhere? It's
occasionally useful in generic wrappers.
And this is pushing UFCS beyond its purpose for the sake of
temporal convenience at the expense of language.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@gmail.com wrote: Graphics programmers who can make GPU's sing, [...] UI designers capable of replicating the looks [REPLYER'S EDIT: and feel] of each OS. Embrace native and those two concerns disappear. And that latter of those two is *NEVER* going to be pulled off successfully with a non-native toolkit anyway. Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and WPF (retained mode GPU rendering) are pixel identical. Only way to tell the difference is if it doesn't use the default (native) styling. Nick, I work exclusively in WPF/XAML all day every day at work, but the last app I wrote was WinForms, what's your experience? -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Ideal D GUI Toolkit
20-May-2013 22:01, Adam Wilson пишет: On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little beatgam...@gmail.com wrote: I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion. Personally, I want these features: * simple and extensible * minimal components (something like HTMLs feature-set) * custom components (embed OpenGL/direct frame buffer) * native window decorations by default, but can provide custom decorations * markup (like QML) or programmable (like SWT) Nice-to-haves: * hardware accelerated (2D OpenGL) * GUI designer (much easier with QML-esque markup) * part of Phobos I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos. Thoughts? So I've been around D a while pushing for native D UI toolkit. And here are a few trends I've seen in the community. * There is a deep-seated distrust of any toolkit that does not use the OS Native UI widgets. The people in this community prefer native toolkits to the point of jihad. It's just one crazy Nick ;) Now I am a XAML guy myself, and I saw the light a long time ago, but around here, the majority are still command line gurus. Markup for GUI layout seems like a decent idea. * There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there. Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!) [snip] * Nobody believes that we can do it, you'll hear a lot of moaning about how much work it is. My reply to that is: And Linux is such a piece of cake right? It's only the most widely used kernel on the planet. If anything D community is full of people doing things close to impossible (esp given the limited spare time and other constraints). Here's the deal. Building a GUI toolkit, particularly a useful one, is a massive undertaking. WPF is the single largest library in all of .NET. IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will require something that D itself does not. A highly dedicated team of people with many diverse skills. The project is simply too big for a single person. I sure hope savings in amount of idiomatic D code vs C# idiomatic code OOP code could help here. Part of the problem with UI toolkits is the number of skills you'll need for the team. Graphics programmers who can make GPU's sing, API designers who can make it easy access, UI designers capable of replicating the looks of each OS. Experts for each targeted OS. And I can think of more. Well, then you'll also become an expert in a couple of cool fields ;) Seriously a few helping hands are sorely needed. [snip other good points] A UI toolkit in D would be a fantastic showcase for demonstrating just how powerful D is. But make no mistake, it will not be easy getting it done. -- Dmitry Olshansky
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: 20-May-2013 22:01, Adam Wilson пишет: On Sun, 19 May 2013 22:25:49 -0700, Tyler Jameson Little beatgam...@gmail.com wrote: I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion. Personally, I want these features: * simple and extensible * minimal components (something like HTMLs feature-set) * custom components (embed OpenGL/direct frame buffer) * native window decorations by default, but can provide custom decorations * markup (like QML) or programmable (like SWT) Nice-to-haves: * hardware accelerated (2D OpenGL) * GUI designer (much easier with QML-esque markup) * part of Phobos I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos. Thoughts? So I've been around D a while pushing for native D UI toolkit. And here are a few trends I've seen in the community. * There is a deep-seated distrust of any toolkit that does not use the OS Native UI widgets. The people in this community prefer native toolkits to the point of jihad. It's just one crazy Nick ;) Well, there are a couple vocal others. Now I am a XAML guy myself, and I saw the light a long time ago, but around here, the majority are still command line gurus. Markup for GUI layout seems like a decent idea. HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is markup. Android is markup. Realistically, the age of OS native toolkits has passed, markup is the future. *shrug* For me it's a practical thing, markup is extensible, OS widgets are not. * There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there. Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!) [snip] I would LOVE to see it included in Phobos, but making it multi-platform places an pretty hard requirement that it not be OS native widgets, some OS's have widgets that others don't, some OS's have incompatible UI declaration models, for example: WinForms is Win23 API calls where iOS is markup. It is workable, but it is even MORE work than building a GPU based UI toolkit from scratch. How big is Qt compared to WPF? * Nobody believes that we can do it, you'll hear a lot of moaning about how much work it is. My reply to that is: And Linux is such a piece of cake right? It's only the most widely used kernel on the planet. If anything D community is full of people doing things close to impossible (esp given the limited spare time and other constraints). Agreed. But as soon as you bring up UI toolkits then it's too much, it's impossible, it makes no sense, etc, etc, etc. That's kind of my point, D takes the impossible and makes is merely difficult. Here's the deal. Building a GUI toolkit, particularly a useful one, is a massive undertaking. WPF is the single largest library in all of .NET. IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will require something that D itself does not. A highly dedicated team of people with many diverse skills. The project is simply too big for a single person. I sure hope savings in amount of idiomatic D code vs C# idiomatic code OOP code could help here. You have no idea... Part of the problem with UI toolkits is the number of skills you'll need for the team. Graphics programmers who can make GPU's sing, API designers who can make it easy access, UI designers capable of replicating the looks of each OS. Experts for each targeted OS. And I can think of more. Well, then you'll also become an expert in a couple of cool fields ;) Seriously a few helping hands are sorely needed. Absolutely, but my point is that some of those are entire fields of study and bodies of knowledge that can take years or decades a too acquire. It's a bit unrealistic for first time GPU coder to write an efficient shader. UI design is a whole field unto itself. Etc. My point here is that no one person has a realistic shot of being able to acquire and maintain the required knowledge single-handedly. [snip other good points] A UI toolkit in D would be a fantastic showcase for demonstrating just how powerful D is. But make no mistake, it will not be easy getting it done. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project
Re: opDispatch and operator overloads
On 05/20/2013 09:26 PM, Maxim Fomin wrote:
On Monday, 20 May 2013 at 15:15:33 UTC, John Colvin wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if opDispatch could catch missing operator
overloads.
This would also leads to bugs when invalid code is silently accepted in
each user-defined type where opDispatch is defined.
This statement is wrong. As a counterexample, consider the following code:
struct S{
void opDispatch(string s)()if(s==foo){ }
}
Also, I'd claim that there is no way of constructing an example where
the change leads to actual problems. (It is always possible to manually
remove the syntax sugar to get an equivalent program without operator
overloading.)
The current situation where there exist types for which
a.opBinary!+(b) is valid but not a+b is confusing at best.
Also, would it be a good idea to have free functions of all the
operators (opOpAssign etc...) for builtin types somewhere? It's
occasionally useful in generic wrappers.
And this is pushing UFCS beyond its purpose for the sake of temporal
convenience at the expense of language.
He was assuming, based on the language spec I suppose, that UFCS is
compatible with operator overloading. His use case is orthogonal to that
issue.
Re: C++ constructors, destructors and operator access
Mapping constructors is complicated... Operator overloads are
much worse, they just don't all map.
You have misunderstood me.
I spoke out against the mapping. I spoke only about access.
For example if we automatically generate a binding extern(C++)
interface we can add a special methods to access to operators and
constructors/destructors.
For example:
С++:
class Foo
{
int operator(const Foo);
int operator(const Foo);
int operator[](size_t);
Foo();
~Foo();
};
D automatically generated interface:
extern(C++) interface Foo
{
final int __operator_lt(const Foo);
final int __operator_gt(const Foo);
final ref int __operator_index(size_t);
final void __constructor();
final void __destructor();
}
Those operator-access methods shouldn't have operator semantic in
D. If user want to use C++ __operator_lt for compare objects in
D, him cat manually create opCmp method and use __operator_lt in
it. But it is user task. I think, we should only provide access
to operators and constructors methods.
About constructors:
In addition those methods we can add some information methods.
For example size_t __sizeof() method which return size of this
object. After this we can provide some allocate+constructor
functions. For example:
auto foo = cppNewClass!Foo(args);
This template functions perform next actions:
1. Try to find overloaded operator new(). If overloaded new has
been finded then cppNewClass will use it, otherwise cppNewClass
will use default new.
2. Try to find constructor, which can called with specified args.
3. Allocate memory using __sizeof() method.
4. Call constructor over alloated memory.
for pair to cppNewClass can be provided cppDeleteClass function
with same semantic.
This support layer will very simplify interface with C++ code.
By the way: Why D disallow static __gshared C++ variables in
classes? This is a principled feature (if yes: why?) or
omission?
It does? Is this problem linux only? I don't see any reason
why it would
be excluded on purpose.
Ok. I've created pull request
https://github.com/D-Programming-Language/dmd/pull/2053
That said, extern(C++) is mostly untested. There are some
truly awful bugs
lurking if you try to use complicated types/declarations. This
is slowly
improving.
I've bumped two old bugzilla issues about extern(C++)
http://d.puremagic.com/issues/show_bug.cgi?id=1687
http://d.puremagic.com/issues/show_bug.cgi?id=4620
Please comment it and close if they are invalid.
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 19:41:09 UTC, Adam Wilson wrote: Well, there are a couple vocal others. My preference for native stuff is just simply that the alternative seems to be reinventing a gigantic wheel. Though, at the same time, for a while I was playing with the idea of using my simple htmlwidget.d as a gui thing. It can only handle simple html but that does include events, and we can get quite a bit done with crappy html. In theory, we could write up all kinds of tags and make something out of it. But I don't do enough gui stuff anymore to worry much about it personally.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:28:09 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@gmail.com wrote: Graphics programmers who can make GPU's sing, [...] UI designers capable of replicating the looks [REPLYER'S EDIT: and feel] of each OS. Embrace native and those two concerns disappear. And that latter of those two is *NEVER* going to be pulled off successfully with a non-native toolkit anyway. Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and WPF (retained mode GPU rendering) are pixel identical. Only way to tell the difference is if it doesn't use the default (native) styling. Nick, I work exclusively in WPF/XAML all day every day at work, but the last app I wrote was WinForms, what's your experience? WPF/XAML is first-party, therefore it's native by definition regardless of whether or not it internally hands off to the older UI code. Saying WPF isn't native is like saying that Quartz isn't native just because it doesn't use...uhh, whatever the UI was called in Mac OS 9. Besides, having access to all of MS's internal code, documents, probably even some of the original developers still around, etc., is naturally going to change the feasibility in a way that no third party toolkit (which is exactly what we're talking about here) is realistically going to be able to match. In other words, despite your antagonism, I was implicitly **agreeing** with your assertion that it's one a hell of an undertaking, *especially* if you don't make use of native APIs under-the-hood.
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 05:25:50 UTC, Tyler Jameson Little wrote: Thoughts? I don't think it will make it in Phobos. At least not for a long time. It will first need to be proven and show a strong use in the community/world. As said, it is a massive undertaking so people are skeptical and I like the point made that it will require collaboration from many knowledge areas. Linux was mentioned. Just remember Linus is just building an OS for fun, trying to see if he can mimic Unix on his system. He doesn't have any interest in supporting hardware non-SCSI (or something like that) since he doesn't have a machine with that hardware. The fact that others are providing support for those things and he is merging them in is irrelevant. I like DWT, but it is a lot to learn. I've been using DFL and wish to switch to DWT but re-writing my simple GUI isn't a priority. DWT could use a D face, but I'm ok with examples compiling with little change.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 23:28:16 +0400 Dmitry Olshansky dmitry.o...@gmail.com wrote: 20-May-2013 22:01, Adam Wilson пишет: * There is a deep-seated distrust of any toolkit that does not use the OS Native UI widgets. The people in this community prefer native toolkits to the point of jihad. It's just one crazy Nick ;) Heh :) It's really not just me, though. But, gee, it is nice to know I'm in people's thoughts...I think... ;) Now I am a XAML guy myself, and I saw the light a long time ago, but around here, the majority are still command line gurus. Markup for GUI layout seems like a decent idea. Indeed. XML wouldn't have been my choice though, but UI layout is an appropriate area for some DSL-ness. * There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there. Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!) [snip] There's interest, sure, but it'd have to be really, *really* freaking good. Enough to obviate most needs/desires for the other popular GUI toolkits. It'd have to do for us what WPF did for MS, *and* be cross-platform. Not impossible, strictly speaking, but a tall order even for us. Not saying it isn't worth attempting for those skilled and motivated enough, but I wouldn't have my hopes up. And I'm not sure how much we'd really gain by having it in phobos anyway: By the time any toolkit like that was built and ready, I'm sure DUB will have gotten big enough that being an external library won't be an issue.
Re: opDispatch and operator overloads
On Monday, 20 May 2013 at 19:48:48 UTC, Timon Gehr wrote:
On 05/20/2013 09:26 PM, Maxim Fomin wrote:
This would also leads to bugs when invalid code is silently
accepted in
each user-defined type where opDispatch is defined.
This statement is wrong. As a counterexample, consider the
following code:
struct S{
void opDispatch(string s)()if(s==foo){ }
}
Also, I'd claim that there is no way of constructing an example
where the change leads to actual problems. (It is always
possible to manually remove the syntax sugar to get an
equivalent program without operator overloading.)
The current situation where there exist types for which
a.opBinary!+(b) is valid but not a+b is confusing at best.
I refer to more complex cases where fear introduction of subtle
bugs caused by combination of buggy implementation and unintended
consequences which would be revealed as unexpected behavior
change of existing features. In some notorious cases such
artificiality created problems (for local convenience at the
expense of language consistency) are not easy to fix (ref), or
are unfixable by design (@disable), or are broken and dumped
without touch for ages (delegates).
Clearly, bugs should not stop from implementing a good feature,
but here I see low benefits and some problems.
Also, would it be a good idea to have free functions of all
the
operators (opOpAssign etc...) for builtin types somewhere?
It's
occasionally useful in generic wrappers.
And this is pushing UFCS beyond its purpose for the sake of
temporal
convenience at the expense of language.
He was assuming, based on the language spec I suppose, that
UFCS is compatible with operator overloading. His use case is
orthogonal to that issue.
Yes, it is separate story.
Re: C++ constructors, destructors and operator access
On Monday, 20 May 2013 at 20:11:27 UTC, nazriel wrote:
On Saturday, 18 May 2013 at 22:23:51 UTC, Igor Stepanov wrote:
At the current time D have powerful mechanism of access to C++
classes.
For access to methods of C++ classes (virtual and not) we can
use extern(C++) interface.
//С++
class CPPTest1
{
int a;
int b;
public:
virtual int boom();
int fun();
static int gun();
CPPTest1(int);
virtual ~CPPTest1();
int operator[](size_t);
};
class CPPTest2: public CPPTest1
{
int boom();
};
//D
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
}
extern(C++)interface CPPTest2: CPPTest1
{
//int boom();
}
As a rule, non-static fields are not public in C++ classes and
is not part of interface. Thus the most of C++ classes can be
bound without any glue c++ code.
However D dont support C++ overloaded operators and
constructors. Yes, we cannot make mapping C++ operators to D
operators and C++ constructors to D constructors). Nonetheless
С++ operators and constructors are the simple C++ functions or
methods with special mangling. Thus I've suggest next
mechanism:
Allow special pragma(cppSymbol, string_arg), when string_arg
is the name of c++ thing.
Example:
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
///
pragma(cppSymbol, constructor) final void ctor(int);
//linked with CPPTest1(int);
pragma(cppSymbol, destructor) void dtor(); //linked with
virtual ~CPPTest1();
pragma(cppSymbol, []) ref int indexOf(size_t); //linked
with int operator[](size_t);
}
This pragma must apply to the function (or method), use
natural C++ mangle, but set operatror or constructor or
destructor mangled name instead of function name.
Is it useful idea?
Isn't it possible already with something like:
extern(C++) interface Foo
{
pragma(mangle, typeof(this).mangleof ~
generateCPPMangle!myOwnFunctionMangling) void foo();
}
Of course I mean:
extern(C++) interface Foo
{
pragma(mangle, generateCPPMangle!(typeof(this).mangleof,
myOwnFunctionMangling)) void foo();
}
AFAIK, mangle pragma was merged recently.
Re: C++ constructors, destructors and operator access
On Saturday, 18 May 2013 at 22:23:51 UTC, Igor Stepanov wrote:
At the current time D have powerful mechanism of access to C++
classes.
For access to methods of C++ classes (virtual and not) we can
use extern(C++) interface.
//С++
class CPPTest1
{
int a;
int b;
public:
virtual int boom();
int fun();
static int gun();
CPPTest1(int);
virtual ~CPPTest1();
int operator[](size_t);
};
class CPPTest2: public CPPTest1
{
int boom();
};
//D
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
}
extern(C++)interface CPPTest2: CPPTest1
{
//int boom();
}
As a rule, non-static fields are not public in C++ classes and
is not part of interface. Thus the most of C++ classes can be
bound without any glue c++ code.
However D dont support C++ overloaded operators and
constructors. Yes, we cannot make mapping C++ operators to D
operators and C++ constructors to D constructors). Nonetheless
С++ operators and constructors are the simple C++ functions or
methods with special mangling. Thus I've suggest next mechanism:
Allow special pragma(cppSymbol, string_arg), when string_arg is
the name of c++ thing.
Example:
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
///
pragma(cppSymbol, constructor) final void ctor(int);
//linked with CPPTest1(int);
pragma(cppSymbol, destructor) void dtor(); //linked with
virtual ~CPPTest1();
pragma(cppSymbol, []) ref int indexOf(size_t); //linked
with int operator[](size_t);
}
This pragma must apply to the function (or method), use natural
C++ mangle, but set operatror or constructor or destructor
mangled name instead of function name.
Is it useful idea?
Isn't it possible already with something like:
extern(C++) interface Foo
{
pragma(mangle, typeof(this).mangleof ~
generateCPPMangle!myOwnFunctionMangling) void foo();
}
AFAIK, mangle pragma was merged recently.
Re: C++ constructors, destructors and operator access
On Monday, 20 May 2013 at 20:13:47 UTC, nazriel wrote:
On Monday, 20 May 2013 at 20:11:27 UTC, nazriel wrote:
On Saturday, 18 May 2013 at 22:23:51 UTC, Igor Stepanov wrote:
At the current time D have powerful mechanism of access to
C++ classes.
For access to methods of C++ classes (virtual and not) we can
use extern(C++) interface.
//С++
class CPPTest1
{
int a;
int b;
public:
virtual int boom();
int fun();
static int gun();
CPPTest1(int);
virtual ~CPPTest1();
int operator[](size_t);
};
class CPPTest2: public CPPTest1
{
int boom();
};
//D
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
}
extern(C++)interface CPPTest2: CPPTest1
{
//int boom();
}
As a rule, non-static fields are not public in C++ classes
and is not part of interface. Thus the most of C++ classes
can be bound without any glue c++ code.
However D dont support C++ overloaded operators and
constructors. Yes, we cannot make mapping C++ operators to D
operators and C++ constructors to D constructors).
Nonetheless С++ operators and constructors are the simple C++
functions or methods with special mangling. Thus I've suggest
next mechanism:
Allow special pragma(cppSymbol, string_arg), when string_arg
is the name of c++ thing.
Example:
extern(C++)interface CPPTest1
{
int boom();
static int gun();
final int fun();
///
pragma(cppSymbol, constructor) final void ctor(int);
//linked with CPPTest1(int);
pragma(cppSymbol, destructor) void dtor(); //linked with
virtual ~CPPTest1();
pragma(cppSymbol, []) ref int indexOf(size_t); //linked
with int operator[](size_t);
}
This pragma must apply to the function (or method), use
natural C++ mangle, but set operatror or constructor or
destructor mangled name instead of function name.
Is it useful idea?
Isn't it possible already with something like:
extern(C++) interface Foo
{
pragma(mangle, typeof(this).mangleof ~
generateCPPMangle!myOwnFunctionMangling) void foo();
}
Of course I mean:
extern(C++) interface Foo
{
pragma(mangle, generateCPPMangle!(typeof(this).mangleof,
myOwnFunctionMangling)) void foo();
}
AFAIK, mangle pragma was merged recently.
If we'll implement generateCPPMangle template, we'll can do all:)
This way one of the possible. There are another way to do it. I
don't know, what a best way now. But I think, this (simple
binding C++ code to D) is important issue and we should solve it
using one of the possible way.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:41:08 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: Markup for GUI layout seems like a decent idea. HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is markup. Android is markup. Realistically, the age of OS native toolkits has passed, markup is the future. *shrug* For me it's a practical thing, And what takes that markup and actually executes it? Magical GUI fairies? ;) Markup is, by necessity, nothing more than a front-end for a code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI toolkits will always be there whether it's the UI designers that use it directly or the markup developers that use it directly. markup is extensible, OS widgets are not. I don't know where you got that idea.
Re: Ideal D GUI Toolkit
20-May-2013 23:41, Adam Wilson пишет: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: [snip] * There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there. Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!) [snip] I would LOVE to see it included in Phobos, but making it multi-platform places an pretty hard requirement that it not be OS native widgets, some OS's have widgets that others don't, some OS's have incompatible UI declaration models, for example: WinForms is Win23 API calls where iOS is markup. It is workable, but it is even MORE work than building a GPU based UI toolkit from scratch. How big is Qt compared to WPF? Keep in mind that Qt as other frameworks basically bend the whole world into a certain ideology. They build everything anew from atoms (or rather quarks) up. Strings(!), smart pointers, events, semaphores, threads, containers, allocators, signals/slots, you name it - they build it ALL. Not to blame them - C++ std simply doesn't have it/cut it. D on the other hand can leverage the incredibly flexible (but incomplete currently) framework of Phobos. Note that all of GUI frameworks are pre C++11 (hint-hint). Here's the deal. Building a GUI toolkit, particularly a useful one, is a massive undertaking. WPF is the single largest library in all of .NET. IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will require something that D itself does not. A highly dedicated team of people with many diverse skills. The project is simply too big for a single person. I sure hope savings in amount of idiomatic D code vs C# idiomatic code OOP code could help here. You have no idea... Of course, I haven't seen the video yet :) [snip] Well, then you'll also become an expert in a couple of cool fields ;) Seriously a few helping hands are sorely needed. Absolutely, but my point is that some of those are entire fields of study and bodies of knowledge that can take years or decades a too acquire. I believe this is a fallacy as given the current pace of progress people can then no longer hope to become experts anymore ;) (Or at least in anything even remotely actual). A year or 2 is more then enough to get to the state of the art, and amount of experience is not proportional to inventing something new (and advancing the field). Another thing to understand is that for example it took years to develop classical analysis in math but nowadays it's just a couple of semesters. Stealing a good vision from other expert(s) is a good interim short-cut. Also believe it or not there is a quite large intersections between all of fields you just listed (at least pair-wise). It's a bit unrealistic for first time GPU coder to write an efficient shader. And these change often enough that 5-years old experience has little advantage - you still have to re-read all the specs again. UI design is a whole field unto itself. Etc. My point here is that no one person has a realistic shot of being able to acquire and maintain the required knowledge single-handedly. The only path is to develop even in teams is having a good taste (=vision) and lead others to follow it. If you don't understand UI design at all chances to succeed with you at head are low, ditto GPUs ditto everything else. [snip other good points] -- Dmitry Olshansky
Re: Ideal D GUI Toolkit
The following will take much less time and can achieve good, native results quickly: Design a user-code facing clean api using idiomatic D (front end code): windows, widgets, callbacks via delegates, etc. Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc. This is what python does with matplotlib: http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython, tkinter, qt, macosx, or fltk, and also non interactive backends) The user code stays clean, the results are native (depending on backend), and the wheel is not reimplemented. On Mon, May 20, 2013 at 1:20 PM, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 12:41:08 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: Markup for GUI layout seems like a decent idea. HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is markup. Android is markup. Realistically, the age of OS native toolkits has passed, markup is the future. *shrug* For me it's a practical thing, And what takes that markup and actually executes it? Magical GUI fairies? ;) Markup is, by necessity, nothing more than a front-end for a code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI toolkits will always be there whether it's the UI designers that use it directly or the markup developers that use it directly. markup is extensible, OS widgets are not. I don't know where you got that idea.
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 05:25:50 UTC, Tyler Jameson Little wrote: I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion. Personally, I want these features: * simple and extensible * minimal components (something like HTMLs feature-set) * custom components (embed OpenGL/direct frame buffer) * native window decorations by default, but can provide custom decorations * markup (like QML) or programmable (like SWT) Nice-to-haves: * hardware accelerated (2D OpenGL) * GUI designer (much easier with QML-esque markup) * part of Phobos I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos. Thoughts? What about D Forms Library (DFL)? I didn't try it yet, but I've heard it's not bad. https://github.com/Rayerd/dfl
Re: Ideal D GUI Toolkit
UI toolkits are a lot of work but they're not as unreasonably big as everyone seems to be suggesting... I've written a couple myself in a procedural language using Direct3D to draw everything. Had all the standard controls, various layout options, even a syntax highlighted code editor, clipboard interaction, keyboard focus, etc. The main difficulties with doing the same thing in opengl and making it cross platform seem to be: - Font rendering, especially with support for the combining unicode characters and RTL languages. It would probably be worth finding an existing library for this. - Making it consistent with the host OS, it would be possible to have a number of skins for each OS but that would probably be breaking all sorts of copyright rules. Generating the skin on the fly using the native drawing commands shouldn't be too hard... On the other hand you get the advantages of hardware acceleration and pretty much unlimited custom drawing capabilities and I'd expect to see a lot of interesting custom controls out there. I'd definitely favour this option! A native OS UI would be less work - although you'd effectively need to write an implementation specifically for each OS, the OS would take care of most of it for you. The main problems here would be getting consistent behaviour across all OSes and also it would be a lot of work to add controls that don't already exist in the OS. What would be neat is if there was a CTFE based compiler which took some form of markup describing part of the UI and converted it to D code. That way you could mixin bits of UI markup either from files or string literals, directly into your classes and it would be really easy to hook up events and things.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 12:52:39 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 12:28:09 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:09:47 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 11:01:35 -0700 Adam Wilson flybo...@gmail.com wrote: Graphics programmers who can make GPU's sing, [...] UI designers capable of replicating the looks [REPLYER'S EDIT: and feel] of each OS. Embrace native and those two concerns disappear. And that latter of those two is *NEVER* going to be pulled off successfully with a non-native toolkit anyway. Demonstrably untrue. Windows Aero in WinForms (native OS widgets) and WPF (retained mode GPU rendering) are pixel identical. Only way to tell the difference is if it doesn't use the default (native) styling. Nick, I work exclusively in WPF/XAML all day every day at work, but the last app I wrote was WinForms, what's your experience? WPF/XAML is first-party, therefore it's native by definition regardless of whether or not it internally hands off to the older UI code. Saying WPF isn't native is like saying that Quartz isn't native just because it doesn't use...uhh, whatever the UI was called in Mac OS 9. It's first party only insofar as it's Microsoft, but that's where it ends. WPF is DevDiv, Win32 (i.e. WinForms) is WinDiv, being completely separate divisions at a company like MS means they might as well be separate companies. And your Mac OS 9 analogy would be correct about the Win32/WinRT differences, but not WPF. WPF exists completely outside the scope of the OS. Besides, having access to all of MS's internal code, documents, probably even some of the original developers still around, etc., is naturally going to change the feasibility in a way that no third party toolkit (which is exactly what we're talking about here) is realistically going to be able to match. And my point is that your assertion that it can never be done is patently untrue. If MS can do it, there is no technical barrier to FOSS doing it, other than our own mental conception of what we are capable of. The point about WPF is that the system is so flexible in it's rendering that you can precisely emulate any native OS toolkit, or go off in a completely new direction. I prefer that flexibility as a UI designer. In other words, despite your antagonism, I was implicitly **agreeing** with your assertion that it's one a hell of an undertaking, *especially* if you don't make use of native APIs under-the-hood. Now that I think we all agree on. It is hard, but I think it might actually be more difficult to create a unified (standard) library on top of the native toolkits for each OS supported in Phobos. The OS requirements for a rendered UI such as WPF are actually far fewer, basically just a direct connection to the GPU and a windowing mechanism, virtually every OS provides those, for example, OpenGL and X. Therefore building the amount of shim building required is MUCH smaller. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Ideal D GUI Toolkit
The following will take much less time and can achieve good, native results quickly: Design a user-code facing clean api using idiomatic D (front end code): windows, widgets, callbacks via delegates, etc. Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc. This is what python does with matplotlib: http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython, tkinter, qt, macosx, or fltk, and also non interactive backends) The user code stays clean, the results are native (depending on backend), and the wheel is not reimplemented. The other advantage of this is we can have results early on (leveraging existing backends), but nothing prevents us to work in parallel on a backend that's purely written in D (written on top of opengl for example) if need be.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 13:20:22 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 12:41:08 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: Markup for GUI layout seems like a decent idea. HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is markup. Android is markup. Realistically, the age of OS native toolkits has passed, markup is the future. *shrug* For me it's a practical thing, And what takes that markup and actually executes it? Magical GUI fairies? ;) Depends on the system, in WPF the XAML is encoded into a binary form of XML and then the objects are deserialized at runtime. Note that given D's CTFE I would NOT choose this path for any D UI toolkit. D is perfect for a system where you use markup to declare your UI in a CTFE manner and then have the compiler do the dirty work of actually generating the code. Fast AND Simple, Go D! Markup is, by necessity, nothing more than a front-end for a code-based GUI engine/toolkit/whatever-we-want-to-call-it. The GUI toolkits will always be there whether it's the UI designers that use it directly or the markup developers that use it directly. markup is extensible, OS widgets are not. I don't know where you got that idea. I mean extensible in terms of look or style, sorry for the ambiguity. OS widgets require tons of custom coding to change the style, I've done it, and I hated every minute of it. But with WPF I don't even think twice, I just do it, because I can get the exact style in under an hour. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: I want to add a Phobos module with template mixins for common idioms.
On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote: OK, I implemented everything and made a pull request: https://github.com/D-Programming-Language/phobos/pull/1294 I've added this to the review queue. The module is in need of documentation (publishing not required) before it can be formally reviewed.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 13:58:04 -0700, Timothee Cour thelastmamm...@gmail.com wrote: The following will take much less time and can achieve good, native results quickly: Design a user-code facing clean api using idiomatic D (front end code): windows, widgets, callbacks via delegates, etc. Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc. This is what python does with matplotlib: http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython, tkinter, qt, macosx, or fltk, and also non interactive backends) The user code stays clean, the results are native (depending on backend), and the wheel is not reimplemented. The other advantage of this is we can have results early on (leveraging existing backends), but nothing prevents us to work in parallel on a backend that's purely written in D (written on top of opengl for example) if need be. Every design I've discussed with various people in the community relies on have a pluggable rendering backend. It's the only sensible way really, the best way to custom draw stuff on Windows is DirectX, whereas its OGL on Linux/Mac, or OpenGL ES on Android and iOS. And by going straight for the lowest level of GPU interaction for each platform we avoid an extra layer of abstraction in the rendering pipeline, which is very performance sensitive. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 13:40:06 -0700, Diggory digg...@googlemail.com wrote: UI toolkits are a lot of work but they're not as unreasonably big as everyone seems to be suggesting... I've written a couple myself in a procedural language using Direct3D to draw everything. Had all the standard controls, various layout options, even a syntax highlighted code editor, clipboard interaction, keyboard focus, etc. The main difficulties with doing the same thing in opengl and making it cross platform seem to be: - Font rendering, especially with support for the combining unicode characters and RTL languages. It would probably be worth finding an existing library for this. - Making it consistent with the host OS, it would be possible to have a number of skins for each OS but that would probably be breaking all sorts of copyright rules. Generating the skin on the fly using the native drawing commands shouldn't be too hard... On the other hand you get the advantages of hardware acceleration and pretty much unlimited custom drawing capabilities and I'd expect to see a lot of interesting custom controls out there. I'd definitely favour this option! A native OS UI would be less work - although you'd effectively need to write an implementation specifically for each OS, the OS would take care of most of it for you. The main problems here would be getting consistent behaviour across all OSes and also it would be a lot of work to add controls that don't already exist in the OS. What would be neat is if there was a CTFE based compiler which took some form of markup describing part of the UI and converted it to D code. That way you could mixin bits of UI markup either from files or string literals, directly into your classes and it would be really easy to hook up events and things. As far as I am concerned this is pretty much the only way to do it. D's CTFE gives us so much power in the markup-code translation phase we'd be terminally stupid not to use it. :-D -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: I want to add a Phobos module with template mixins for common idioms.
On Monday, 20 May 2013 at 21:01:36 UTC, Jesse Phillips wrote: On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote: OK, I implemented everything and made a pull request: https://github.com/D-Programming-Language/phobos/pull/1294 I've added this to the review queue. The module is in need of documentation (publishing not required) before it can be formally reviewed. http://wiki.dlang.org/Review_Queue Should have been more specific with this. The documentation looks to be sparse with few examples and little introduction. I'll have to do more examining of the specific functions/classes. Due to the nature of the module I may need to reconsider how much can actually go into an introduction.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 13:32:09 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: 20-May-2013 23:41, Adam Wilson пишет: On Mon, 20 May 2013 12:28:16 -0700, Dmitry Olshansky dmitry.o...@gmail.com wrote: [snip] * There is absolutely no chance of inclusion in Phobos, and to-be-honest I don't think it really belongs there. Where you take that from? I thought it was quite the opposite if written in D. Even C++ guys seem interested in GUIs in std library(!) [snip] I would LOVE to see it included in Phobos, but making it multi-platform places an pretty hard requirement that it not be OS native widgets, some OS's have widgets that others don't, some OS's have incompatible UI declaration models, for example: WinForms is Win23 API calls where iOS is markup. It is workable, but it is even MORE work than building a GPU based UI toolkit from scratch. How big is Qt compared to WPF? Keep in mind that Qt as other frameworks basically bend the whole world into a certain ideology. They build everything anew from atoms (or rather quarks) up. Strings(!), smart pointers, events, semaphores, threads, containers, allocators, signals/slots, you name it - they build it ALL. Not to blame them - C++ std simply doesn't have it/cut it. D on the other hand can leverage the incredibly flexible (but incomplete currently) framework of Phobos. Note that all of GUI frameworks are pre C++11 (hint-hint). Agreed, however, I think with D/Phobos we are in a situation where we can go the WPF route and just build on top of the existing work instead of having to create a whole new standard library to accompany it. Here's the deal. Building a GUI toolkit, particularly a useful one, is a massive undertaking. WPF is the single largest library in all of .NET. IIRC it weighs in at 40,000 classes. Building a UI toolkit in D will require something that D itself does not. A highly dedicated team of people with many diverse skills. The project is simply too big for a single person. I sure hope savings in amount of idiomatic D code vs C# idiomatic code OOP code could help here. You have no idea... Of course, I haven't seen the video yet :) [snip] Well, the video isn't NEARLY that broad in scope, but I do find on average that the D code is about 10% smaller than equivalent C#. Although for certain use cases like UI declaration with CTFE it could be a LOT smaller. Well, then you'll also become an expert in a couple of cool fields ;) Seriously a few helping hands are sorely needed. Absolutely, but my point is that some of those are entire fields of study and bodies of knowledge that can take years or decades a too acquire. I believe this is a fallacy as given the current pace of progress people can then no longer hope to become experts anymore ;) (Or at least in anything even remotely actual). A year or 2 is more then enough to get to the state of the art, and amount of experience is not proportional to inventing something new (and advancing the field). Another thing to understand is that for example it took years to develop classical analysis in math but nowadays it's just a couple of semesters. Stealing a good vision from other expert(s) is a good interim short-cut. Also believe it or not there is a quite large intersections between all of fields you just listed (at least pair-wise). There may be some truth to this, however, GPU's in particular remain an area where specialized knowledge is required. Ask Manu. ;-) That said, even if most of who we needed are generalists, we'd still need a small army of them. Now this is open-source, and we can actually find that small army. But organizing them is far more difficult than at a corporation, at least there you have some unifying vision from the top. Out here is FOSS land it's a free-for-all, and in projects of this scope that tends create many competing visions, and implementations. Subsequently teams fragment quickly and duplication settles in. It's a bit unrealistic for first time GPU coder to write an efficient shader. And these change often enough that 5-years old experience has little advantage - you still have to re-read all the specs again. Sadly this is true, but you still have your domain experience, yes the details changed, but the general processes and procedures you are used to don't generally change that fast. UI design is a whole field unto itself. Etc. My point here is that no one person has a realistic shot of being able to acquire and maintain the required knowledge single-handedly. The only path is to develop even in teams is having a good taste (=vision) and lead others to follow it. If you don't understand UI design at all chances to succeed with you at head are low, ditto GPUs ditto everything else. [snip other good points] Some days I wish I had the charisma and vision to develop that team, because I badly want a D UI toolkit that can do with WPF
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 13:36:42 -0700 Timothee Cour thelastmamm...@gmail.com wrote: The following will take much less time and can achieve good, native results quickly: Design a user-code facing clean api using idiomatic D (front end code): windows, widgets, callbacks via delegates, etc. Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc. This is what python does with matplotlib: http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython, tkinter, qt, macosx, or fltk, and also non interactive backends) The user code stays clean, the results are native (depending on backend), and the wheel is not reimplemented. Yea, that would definitely be my approach, too.
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 13:58:56 -0700 Adam Wilson flybo...@gmail.com wrote: On Mon, 20 May 2013 13:20:22 -0700, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Mon, 20 May 2013 12:41:08 -0700 Adam Wilson flybo...@gmail.com wrote: markup is extensible, OS widgets are not. I don't know where you got that idea. I mean extensible in terms of look or style, sorry for the ambiguity. Ahh, ok, I wasn't actually sure exactly what sort of extensible you meant. OS widgets require tons of custom coding to change the style, I've done it, and I hated every minute of it. But with WPF I don't even think twice, I just do it, because I can get the exact style in under an hour. Honestly, I'd consider that a major downside: Anything that helps/encourages developers to disregard a user's system settings (style or otherwise) is a very bad thing, IMO. Of course, if the toolkit automatically comes with a guaranteed user-selectable setting, outside of the app's control, to optionally disable any custom styling on a per-app or global basis, then that's the best solution of all: It attracts the To hell with the user's system settings because *I* deserve to be in control of my user's computer crowd and then uses that to hand control *back* to the user, where it belongs. I've often thought about developing a system like that.
Re: Ideal D GUI Toolkit
On Tue, 21 May 2013 00:32:09 +0400 Dmitry Olshansky dmitry.o...@gmail.com wrote: 20-May-2013 23:41, Adam Wilson пишет: Absolutely, but my point is that some of those are entire fields of study and bodies of knowledge that can take years or decades a too acquire. I believe this is a fallacy as given the current pace of progress people can then no longer hope to become experts anymore ;) (Or at least in anything even remotely actual). A year or 2 is more then enough to get to the state of the art, and amount of experience is not proportional to inventing something new (and advancing the field). With only a brief, cursory understanding of the current state-of-the-art, any attempts to advance the field automatically carry a high risk of *regression* under the false guise of advancement. And I strongly believe that's already been happening *a lot* over the past decade. Wheels are being reinvented, only this time most of them are squares. Another thing to understand is that for example it took years to develop classical analysis in math but nowadays it's just a couple of semesters. Stealing a good vision from other expert(s) is a good interim short-cut. Well, there *is* that, too.
Range for files by character
Hi,
I need an Input Range that iterates a file character by
character. In bioinformatics this is often important, and having
a D-range is of course preferable than any foreach-byLine
combination, since we can apply filters and other goodies from
std.algorithm. In this implementation, I am simply filtering out
new-lines, as an example.
import std.stdio;
import std.conv;
import std.algorithm;
void main() {
auto f = File(someFile.txt, r);
foreach(c; f.byChunk(1).filter!(a = to!char(a[0]) != '\n'))
write(to!char(c[0]));
}
Is this the right way to do it? I was a bit surprised that
std.stdio doesn't provide a byChar or byByte range. Is there
a reason for this, or is this a too special need?
Stephan
Re: Ideal D GUI Toolkit
On Mon, 20 May 2013 14:14:30 -0700 Adam Wilson flybo...@gmail.com wrote: Some days I wish I had the charisma and vision to develop that team, because I badly want a D UI toolkit that can do with WPF can. I may or may not have the right vision, but I am no charismatic. ;-) What would you say would be a good introduction to WPF?
Re: Range for files by character
On Monday, 20 May 2013 at 21:36:41 UTC, Stephan Schiffels wrote:
Hi,
I need an Input Range that iterates a file character by
character. In bioinformatics this is often important, and
having a D-range is of course preferable than any
foreach-byLine combination, since we can apply filters and
other goodies from std.algorithm. In this implementation, I am
simply filtering out new-lines, as an example.
import std.stdio;
import std.conv;
import std.algorithm;
void main() {
auto f = File(someFile.txt, r);
foreach(c; f.byChunk(1).filter!(a = to!char(a[0]) != '\n'))
write(to!char(c[0]));
}
Is this the right way to do it? I was a bit surprised that
std.stdio doesn't provide a byChar or byByte range. Is
there a reason for this, or is this a too special need?
Stephan
I would try f.byChunk(n).joiner. joiner is from std.algorithm and
it produces a range which joins a range of ranges, quite like
your typical array to string join function.
