Re: A real Forum for D
On Tue, 29 Nov 2011 09:06:06 +0200, Unknown W. Brackets wrote: Walter, Well, having authored web forum software, I suppose I'll make a few remarks here. I seem to have gotten hit by a stray "forum software writers (that's me) just don't get it." 1. Well, I get threads, I really do. I understand their usefulness, and how sometimes it's beneficial to completely ignore a branch - for example, someone reporting an issue with a release on FreeBSD, that doesn't affect me and I don't care about. That said, I must say it's a relatively artificial form of conversation. It's annoying, quite frankly. It's not that I don't get it, I just don't *like* it. Aren't you contradicting yourself? All merits of using some alternatives may become fully apparent only after extended use, and attempts to switch back. Productivity gains are often hard to quantify, thus reports of such can be easily confused with bias (it goes both ways, of course). I don't see how you can objectively say that linear conversations are less "artificial" than threaded ones. I'm not alone. Tons of other people have abandoned this artificial communication format, not because they're stupid or "the masses" or they don't get it, but simply because the cost benefit is not, generally there. What cost? Perhaps this is all about suboptimal UIs? Nevertheless, I'll point out that vBulletin does, in fact, have this feature, although I can't even remember that last time I saw someone use it. Instead they often try "hybrid" mode, which is a joke. If you saw that, you'd assume no one gets it. I just tried the threaded mode. Compared to a real newsreader, it is also a joke. 2. I can't speak to all forum software, since several years ago I'm pretty sure they just remembered the latest timestamp of the latest post when you last visited. But the forum software I was involved in, SMF, absolutely stores more detail than just the topic being read or not. And I'd imagine vBulletin, as well, stores it per post in threaded mode. It does not. Major forum software, including SMF (I just checked the source), store the last post ID that you've seen in a thread. 3. Ignoring the comments about email replies (since they are easy fodder), and returning to the original: many forum softwares (including my own) due indeed provide a way to easily see which posts or topics you have or have not read. Why do you even mention topics? It's clear as day that major forums save which threads you haven't read in their entirety, but not individual posts. I'll note that I use Gmail proudly and often these days. Be careful with that pride. They say it blinds. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Website message overhaul, pass 2
On 2011-11-29 08:40, Caligo wrote: BTW, something is wrong with the class section of the language reference: http://d-programming-language.org/new/class.html It's been like that for months. There's a pull request available but it hasn't been merged. -- /Jacob Carlborg
Re: wxC & wxD
On 2011-11-29 07:37, Gour wrote: On Mon, 28 Nov 2011 22:55:10 +0100 Anders F Björklund wrote: I'm no fan of either, and prefer plain import modules and libs over function pointers and complex tools. Well, my belief is that tools can help when maintaining bindings, iow. when one has to keep the API up-to-date. Of course, my experience was with c2hs (Haskell) where it was easy to notice change in the upstream's API. However, we'll try with SWIG. But I guess that was obvious. It is. Well, I believe you had the officially supported DWT I'm not so sure DWT is either officially supported or in the same league as other toolkits. World of SWT is not thrilling... BTW, I don't understand what people has against DWT/SWT. In my experience it's the toolkit that offers best native look and feeling. Note that I have no experience with wx but the screenshots on the site looks really bad. -- /Jacob Carlborg
Re: wxC & wxD
On 2011-11-29 07:37, Gour wrote: On Mon, 28 Nov 2011 22:55:10 +0100 Anders F Björklund wrote: I'm no fan of either, and prefer plain import modules and libs over function pointers and complex tools. Well, my belief is that tools can help when maintaining bindings, iow. when one has to keep the API up-to-date. Of course, my experience was with c2hs (Haskell) where it was easy to notice change in the upstream's API. However, we'll try with SWIG. But I guess that was obvious. It is. Well, I believe you had the officially supported DWT I'm not so sure DWT is either officially supported or in the same league as other toolkits. World of SWT is not thrilling... DWT is not officially supported. A couple of years ago Walter announced that DWT was going to be the official GUI library for D but that was one of the previous attempts to port SWT to D. When that happened the development of DWT stopped. I guess it was just bad timing but since that Walter has been very reluctant in doing something similar again. -- /Jacob Carlborg
Re: Website message overhaul, pass 2
BTW, something is wrong with the class section of the language reference: http://d-programming-language.org/new/class.html It's been like that for months.
Re: SQL/database server capabilities NO ODBC please
On Sat, 26 Nov 2011 15:31:33 -0800, bls wrote: > Picking up ODBC in order to figure out how an generic database Interface > may look like is a very bad idea. > > Creating an ODBC Interface at all is pretty useless. NOBODY is using > ODBC at all. Just a point of clarification. It is not my intention to write a D wrapper around ODBC. I'm simply saying that D's DB implementations for particular DBs might need to use ODBC. Steve
Re: SQL/database server capabilities NO ODBC please
On 2011-11-29 05:21, Steve Teale wrote: On Mon, 28 Nov 2011 19:48:37 +0100, Jacob Carlborg wrote: On 2011-11-28 15:34, Steve Teale wrote: On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote: On 2011-11-27 07:13, Steve Teale wrote: You may detest ODBC, but it is very soon going to be the only way to communicate with SQL Server short of writing another wire protocol effort. There was the alternative of OLE DB, but MS is dumping that. FreeTDS can be used directly. True. I was thinking Windows at the time (very unusual). Steve I'm pretty sure FreeTDS works on Windows. There's a RubyGem, TinyTDS and works on Windows and uses FreeTDS. https://github.com/rails-sqlserver/tiny_tds All that said, I think we must still cover ODBC. MS ODBC will be the official standard interface to SQL Server, and they are doing Linux versions - the 64 bit one is already available. Steve Of course we can still cover ODBC, I just don't think ODBC should be the only, or primary, interface to SQL Server. -- /Jacob Carlborg
Re: Documentation 'quick index'
On 2011-11-28 23:22, Mike Wey wrote: On 11/28/2011 09:38 PM, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Thanks CandyDoc comes with class, struct and other images: http://www.dsource.org/projects/helix/browser/trunk/doc/candydoc/img/outline They are quite close to what Eclipse and Descent uses, but I think the ones Descent uses looks better. -- /Jacob Carlborg
Re: A real Forum for D
Am 29.11.2011, 08:08 Uhr, schrieb Unknown W. Brackets : In contrast, I haven't a clue how to use NNTP on my iPhone. Go figure. The first iPhone didn't even support copy&paste iirc. On the other hand, this app may work for you: http://www.caledonia.net/blog/?p=173
Re: Documentation 'quick index'
On 2011-11-28 22:18, Steven Schveighoffer wrote: On Mon, 28 Nov 2011 15:38:49 -0500, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Just an FYI, this does not render properly on opera. I have only have a top-level index that does not operate (and yes, I have javascript on). My personal opinion is that the index should not rely on javascript whatsoever. If anything, a collapsable index of everything should be available at the top (expanded by default if javascript is disabled). There should only be one level -- show all or hide all. In general, DDoc suffers from so many deficiencies, fixing the index seems like wasted effort. I'd prefer improvements like have one page per item (class, function, etc) similar to doxygen. This would turn behemoths such as std.datetime into manageable doc pages. I also think a vastly important (and for some reason ignored by ddoc) feature of documentation generators is cross referencing. The whole benefit of having a computer generate documentation from source is that it knows how the source is related. That should all be reflected. For instance, I should be able to have a clickable inheritance tree for a class, and be able to have clickable links to overridden methods. Any examples should have clickable links to the items being used. These improvements would improve the docs by 2 orders of magnitude, whereas fixing the index is a trivial improvement. Not that the index couldn't use improvement, however I understand the reluctance to take up the bigger ddoc tasks, I would not be able to do it. -Steve I completely agree. Descent has quite a good ddoc generator, I think it cross references everything. But on the other hand it uses frames. -- /Jacob Carlborg
Re: Documentation 'quick index'
On 2011-11-28 21:38, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Thanks Have a look at the icons Eclipse uses. You can also take a look at the icons used by Descent: http://dsource.org/projects/descent/browser/trunk/descent.ui/icons -- /Jacob Carlborg
Re: Documentation 'quick index'
On 2011-11-28 21:38, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html That starts to look like CandyDoc. -- /Jacob Carlborg
Re: A real Forum for D
On 2011-11-28 20:43, Walter Bright wrote: On 11/28/2011 5:33 AM, Jacob Carlborg wrote: I know that most of the forums look like this. But what says that they have to? I'm just trying to say that a forum doesn't have to look like these examples. You also complained how the forum sites doesn't work on a small screen. Have a look at this site: http://upperdog.se/ I know this site is not a forum but the content flows really nice when you resize the browser window to a smaller size and it works great on mobile devices. I don't see any reason why these techniques can't be implemented on a forum. I don't see any reason, either. It's why I said that forum software writers just don't get it :-) Hehe :) -- /Jacob Carlborg
Re: A real Forum for D
That's just designers who don't get it. They're starting to nowadays. I remember the WAP, I-mode, and etc. interfaces in SMF worked just fine on small screens. Nowadays there are specialized iPhone interfaces. And of course skins that scale fine. In contrast, I haven't a clue how to use NNTP on my iPhone. Go figure. -[Unknown] On 11/28/2011 11:43 AM, Walter Bright wrote: On 11/28/2011 5:33 AM, Jacob Carlborg wrote: I know that most of the forums look like this. But what says that they have to? I'm just trying to say that a forum doesn't have to look like these examples. You also complained how the forum sites doesn't work on a small screen. Have a look at this site: http://upperdog.se/ I know this site is not a forum but the content flows really nice when you resize the browser window to a smaller size and it works great on mobile devices. I don't see any reason why these techniques can't be implemented on a forum. I don't see any reason, either. It's why I said that forum software writers just don't get it :-)
Re: A real Forum for D
Walter, Well, having authored web forum software, I suppose I'll make a few remarks here. I seem to have gotten hit by a stray "forum software writers (that's me) just don't get it." 1. Well, I get threads, I really do. I understand their usefulness, and how sometimes it's beneficial to completely ignore a branch - for example, someone reporting an issue with a release on FreeBSD, that doesn't affect me and I don't care about. That said, I must say it's a relatively artificial form of conversation. It's annoying, quite frankly. It's not that I don't get it, I just don't *like* it. I'm not alone. Tons of other people have abandoned this artificial communication format, not because they're stupid or "the masses" or they don't get it, but simply because the cost benefit is not, generally there. Nevertheless, I'll point out that vBulletin does, in fact, have this feature, although I can't even remember that last time I saw someone use it. Instead they often try "hybrid" mode, which is a joke. If you saw that, you'd assume no one gets it. 2. I can't speak to all forum software, since several years ago I'm pretty sure they just remembered the latest timestamp of the latest post when you last visited. But the forum software I was involved in, SMF, absolutely stores more detail than just the topic being read or not. And I'd imagine vBulletin, as well, stores it per post in threaded mode. 3. Ignoring the comments about email replies (since they are easy fodder), and returning to the original: many forum softwares (including my own) due indeed provide a way to easily see which posts or topics you have or have not read. In fact, for a long while, I'm pretty sure SMF was the *only* one that remembered topics you hadn't read between visits. Maybe FUDforum too. Now a bunch do it, I think. Possibly all. (cross-branch reply) I'll also mention that most any web forum software does, in fact, have authenticated moderation controls, easy to use ones in fact. They could use client SSL certificates as security (RSA keys would be a hard fit, I'd suggest a VPN with an authenticated IP range in that case), but generally browser interfaces to this aren't ideal, and difficult to transfer or recover. That said, it's not that hard to use, and I've wondered myself why it's not done more often. (another cross-branch reply that is useful in context...) Anyway, an NNTP bridge to a forum could certainly be written, and I'm relatively sure there are already some available. Unfortunately, it's typical that they succumb to the same problems as #1, especially if the interface doesn't enforce threading. I'll note that I use Gmail proudly and often these days. I'm happy that it has adopted a *linear conversation format*, which makes sense to me, works well, and simplifies reviewing past and future conversations. I'm not aware of any threaded message display format, despite the fact the emails are ostensibly (though note cross replies and such) threaded. And let's be honest. When people ask for web based forums, they're not talking about putting a threaded interface up. -[Unknown] On 11/27/2011 10:12 PM, Walter Bright wrote: On 11/27/2011 5:40 PM, Jude wrote: //quote cause I'm lazy Those are all desirable properties. But the forum software I've seen throws out what's good about NNTP news forums: 1. Threaded view 2. Being able to mark messages as "read" 3. Being able to quickly scan read vs unread //end quote 1. Forums can have threaded view too, Generally, they suck. They just don't get what a threaded view is. Newsreaders solved this problem decades ago. A thread is not a topic. It's a view showing who replied to which message. Click to expand at each branching point, click to contract, click to see a particular message. At each point, you can see which messages you've read, and which you haven't. I've never, ever seen forum software that can do that. If there is one, point me to an example. Every newsreader does this. 2. I thought that that was pretty standard for forums? Highlighting for threads you've seen and threads you haven't... not for individual messages, but the last number (25 or so) messages you've seen. Again, the forum software writers just don't get it. It has to be per message. Why? So in a larger thread, you can instantly see what is read and what isn't. This is NOT equivalent to a chronological sort. I do not read threads linearly. 3. click the nice little subscribe to thread button and it tells you if anyone else submits something. Sorry, but that's not it. I want to see if someone replied to a *particular* message. These are all things that forums have had for a while... I've used many forum softwares. They all just DON'T GET IT.
Re: A real Forum for D
Am 29.11.2011, 06:51 Uhr, schrieb Mike Parker : Consider this. I've been using web-based mail for years, so had no mail/newsgroup client installed. Why would I want to install one just for one little project? With a forum, I don't have to install anything. I've been using them for years, am quite used to them, and think the newsgroup interface is antiquated. I hated it even back in 1995 when it was all we had. Forums are in my comfort zone. I always thought that here is a high percentage of Opera users. It may be the case that browsers with integrated news/mail reader make a higher percentage here than in the open. Likewise I never questioned the technology, although news.digitalmars.com is my only news groups as well. (Discounting mailing lists and RSS feeds from other sources.)
Re: wxC & wxD
Gerrit Wichert wrote: So, is wxD going to continue like now, or do you envision some change how to proceed for wx-2.9/3.=? I don't plan to do anything with it, I put it up on github so that it could be forked and maintained if there are any bugfixes etc needed... So if i understand you right, the way to keep wxD alive ist to fork your repository and continue it as an independent project ? The way to keep the project alive was to contribute to SourceForge, moving the repository to github is to connect with the D community. Either way, to keep it alive you just need to use it. By using git, it doesn't matter to which repository the commits are actually done. --anders
Re: wxC & wxD
On Tue, 29 Nov 2011 00:53:20 +0100
Andrej Mitrovic wrote:
> Honestly I can't even get a simple SWIG project working (the demo from
> klickverbot's announcement on his blog). Apparently there's some
> const-related issues.
Hmm...have you reported the issue to klickverbot?
> Building the examples that come with swig windows binary doesn't work,
> tried it via mingw32-make and via MSYS. Apparently there's a missing
> "Makefile" in the root dir. Building SWIG from source doesn't work on
> Windows anymore either. ("Swig/misc.c:1119:18: fatal error: pcre.h: No
> such file or directory").
Have you submitted report to SWIG devs?
> So you have a project that is only maintained on some platforms. (this
> is the swig-2.0.4 release).
I'll install dev env on my Windows under vbox to check it out.
> The question is, what if you end up finding a bug in the generated
> code? Worst case scenario - you have to fix SWIG itself.
What's the difference if you find bug in DMD?
> Btw, Johannes Pfau wrapped most of TagLib with SWIG and said the
> wrapping process was frustrating.
Well, I'd like to hear more about his experiences...Which version of
SWIG he used?
Otoh, is there better tool for providing bindings which can automate
(some of) the work?
> I quite like the 'wxc' wrapper library, if you screw something up it
> doesn't look like too much work to fix it. Obviously you have to write
> everything by hand, so it's repetitive work.
wxC also has to be maintained...As I wrote in another thread, it would
be nice to have stable wxC project so that all language bindings can
profit from it.
> But at least you get a
> readable codebase + you get to statically link with the library.
Let's hope something will change in regard to the linking process.
At the end, the purpose of my posting was to find out what's the status
of current GUI-bindings-related projects in terms of current &
near-future support, so, this is something which one has to take into
consideration despite of upstream status which is OK for the main 3
toolkits (somehow, I do not count much on SWT/DWT.)
Moreover, although wxWidgets has some advantage over the other two related
to offering native look, seeing there is not much initiative to push wxD
forward in the short-term, this thread is closed for me (except if I
don't get signal that using wxWidgets is optimal toolkit for our use in
the *longer-term*.)
Thank you to all for your input.
Sincerely,
Gour
--
You have a right to perform your prescribed duty,
but you are not entitled to the fruits of action.
Never consider yourself the cause of the results
of your activities, and never be attached to not doing your duty.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
signature.asc
Description: PGP signature
Re: wxC & wxD
On Mon, 28 Nov 2011 22:55:10 +0100 Anders F Björklund wrote: > I'm no fan of either, and prefer plain import modules and libs over > function pointers and complex tools. Well, my belief is that tools can help when maintaining bindings, iow. when one has to keep the API up-to-date. Of course, my experience was with c2hs (Haskell) where it was easy to notice change in the upstream's API. However, we'll try with SWIG. > But I guess that was obvious. It is. > Well, I believe you had the officially supported DWT I'm not so sure DWT is either officially supported or in the same league as other toolkits. World of SWT is not thrilling... > and QtD plus the also available GtkD and wxD. Didn't seem like a bad > selection ? I already wrote about that in another thread...nice selection, but not so great support. > All four of those are well supported toolkits, _upstream_ that is. > Either GUI should do the trick for writing a desktop application. Upstream was never meant as part of the problem which is on the D-side. :-) > But even if Phobos/Deimos would have something like Tk (or FLTK) > integrated, it probably wouldn't be accepted as a real solution. Right. > That is, just for being too ugly or too grey or something similar. Or too light perhaps. ;) > Now, why would you want to use D as your language(s) rather than > C, Python, Java ? Or even C++. That was the real question for me. Because I want to work on open-source project in my spare time and that should have some component of 'fun'...C & C++ are not falling into that category, I don't know nor like Java, not inspired about Lisp-languages, Haskell is too-theoretical...which leaves me with the Python, but I find D as sweet spot between scripting languages & C(++). Moreover, it will be bigger project which would need longer maintainance and we believe that although D is not maybe completely ready today, it will be soon enough, so we can start working by writing non-GUI libs for the project. > There has to be enough advantages to overcome the shortcomings, > which in the end wasn't true when making desktop apps (or games). "De gustibus non est disputandum..." Sincerely, Gour -- One who is able to withdraw his senses from sense objects, as the tortoise draws its limbs within the shell, is firmly fixed in perfect consciousness. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: A real Forum for D
On 11/29/2011 8:36 AM, Johannes Totz wrote: PHP forum? Noo!1 If D had a web-based forum only I would not bother reading it or ever coming back to it. I would not have bothered trying to learn any D. I like how these "ancient" newsgroups sort and organise individual messages. I get a nice threaded view, I can see what I've read already, who replied to what. Very efficient. Conversely, there are people who see a newsgroup and run away screaming. There have been several projects I've looked into over the years and where I didn't get involved with the community precisely because they had a newsgroup and not a forum. Consider this. I've been using web-based mail for years, so had no mail/newsgroup client installed. Why would I want to install one just for one little project? With a forum, I don't have to install anything. I've been using them for years, am quite used to them, and think the newsgroup interface is antiquated. I hated it even back in 1995 when it was all we had. Forums are in my comfort zone. Obviously, I made an exception for D because I think it rocks. I went and downloaded Thunderbird. To date, the D newsgroups are all I use it for. But I wonder how many people didn't make an exception? Obviously, we can't please everyone. And I think common sense dictates that in a newsgroup, we will see more people who prefer newsgroups. But I really believe that if we had a proper forum, we'd have a great many more users in the community (for better or worse). Anyway, this horse has been beat to death more than once here. Forum? barf... I hate having to sign up here and register there. I opportunistically want to reply to messages. All this clutter around it, avatars, annoying formatting. Please, pretty please, no. A nice web-based interface to the newsgroup? Yeah could do (I wouldn't use it though).
Re: SQL/database server capabilities NO ODBC please
On Mon, 28 Nov 2011 19:48:37 +0100, Jacob Carlborg wrote: > On 2011-11-28 15:34, Steve Teale wrote: >> On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote: >> >>> On 2011-11-27 07:13, Steve Teale wrote: You may detest ODBC, but it is very soon going to be the only way to communicate with SQL Server short of writing another wire protocol effort. There was the alternative of OLE DB, but MS is dumping that. >>> >>> FreeTDS can be used directly. >> >> True. I was thinking Windows at the time (very unusual). >> >> Steve > > I'm pretty sure FreeTDS works on Windows. There's a RubyGem, TinyTDS and > works on Windows and uses FreeTDS. > > https://github.com/rails-sqlserver/tiny_tds All that said, I think we must still cover ODBC. MS ODBC will be the official standard interface to SQL Server, and they are doing Linux versions - the 64 bit one is already available. Steve
Re: Compile-time Interfaces
On Sun, 27 Nov 2011 12:54:48 +0100, Timon Gehr wrote:
> That is an overly restrictive interface because the element type is
> fixed.
>
> The interface should be usable like this:
> void foo(R : Range)(R input) { /* ... * / }
void foo(T, R : Range!T)(R input) {} // ?
Re: Doom3 (id tech 4) port/binding in D ?
On Thu, 24 Nov 2011 12:18:50 +, Regan Heath wrote: > The source for Minecraft (written primarily in > Java) was going to be released Hasn't been yet, but it wasn't going to be released as OSS and only intended for modding. So I don't know what the licensing rules would entail, but there is a clone in C++ being created: https://github.com/celeron55/minetest it likely won't get traction. The community exists, maybe a small subset can be captured, but a community following really won't happen until Notch is behind it (which might actually be doable). Doom 3 is a massive undertaking and not really feasible. What I would suggest making D usable for modding. And like many here, this task isn't for me.
Re: boost crowd.
Am 28.11.2011, 14:42 Uhr, schrieb Maxim Fomin :
2011/11/28 Marco Leise :
Am 28.11.2011, 11:02 Uhr, schrieb Jude <10equa...@gmail.com>:
I tried to write a lib and a project, which used that lib
separately, but came to conclusion that the best choice it to pull
lib code to project one. And it is not a biggest problem, because
dmd produces 700 kb executable for hello word program.
what..?
I don't know how you are managing to get 700kb for hello world...
mine clocks in a 283.7kb with dmd with no optmizations, and holy crap
1.6MB for same file with gdmd.
WTF is going on there I wonder...?
*drum roll*
148,2 kB (dmd 2.054, Linux)
*tadaa*
- 8< - - - - - - - - - - - - - - - - - - -
import std.stdio;
void main() {
writeln("Hello, world!");
}
- 8< - - - - - - - - - - - - - - - - - - -
--
import std.stdio;
class dummy
{
this() { writeln("ctor");}
~this() { writeln("dtor"); }
}
void main()
{
auto dm = new dummy();
}
---
dmd main.d -o
377,9 kb
It is not 700 as i told, but yesterday i upgraded to 2.056. But
definitely i saw that it produces 700 kb elf for a small program.
Anyway, is 400 kb for dummy program too much?
Be aware that classes and structs have .init blocks that can grow huge if
you declare large static arrays in them. So the source code may be small,
but the executable bloats. And every template instantiation adds to it as
well. I think even just using writeln with different parameters all over
the place adds up, but thats a vague guess.
Re: boost crowd.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 12:37 PM, Kagamin wrote: > so Wrote: > >> http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ > > o.O > > overload a lambda? And now I see what all the hype is about with D's template system. Good lord. I've never really looked at C++ templates before. 0.0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1CWQAAoJENcHIWLyQiSlIIcH/A56cclkWm+4F42AWGUNvCmt sMffKN+1BbPc4ksEmRbPBwA4EzpAsaxMHpYaWW/OvHnoKqX578WAy3IWWOzp2xnn AKK5gocJ700DRgdKqPR1sv4wIrBGzk2a23YWmckV0bWCGi+JCtNiCjbRbLwIPF81 wyYAc2FgBYaj2P4lfKhvVuFMw5YP+uSaROkyVIiekWFR5XNOlhPPWVnq2FoaqlWi V6Xd6k/ry/QbmE0Dszmyybhvawc78hXfCwFgwv9NvwdDNhHUFfIw+hJipo7ObY3P dsN56yH8XFYY3NIzLMjRZGMaGWxhbnx61QWB1P4n1HvSR1agpFe2kowTjnt3/Zo= =03q7 -END PGP SIGNATURE-
Re: wxC & wxD
Honestly I can't even get a simple SWIG project working (the demo from
klickverbot's announcement on his blog). Apparently there's some
const-related issues.
Building the examples that come with swig windows binary doesn't work,
tried it via mingw32-make and via MSYS. Apparently there's a missing
"Makefile" in the root dir. Building SWIG from source doesn't work on
Windows anymore either. ("Swig/misc.c:1119:18: fatal error: pcre.h: No
such file or directory"). So you have a project that is only
maintained on some platforms. (this is the swig-2.0.4 release).
Funnily enough the SVN version from a year ago worked perfectly, but
now an official release doesn't work.
The question is, what if you end up finding a bug in the generated
code? Worst case scenario - you have to fix SWIG itself.
Btw, Johannes Pfau wrapped most of TagLib with SWIG and said the
wrapping process was frustrating.
I quite like the 'wxc' wrapper library, if you screw something up it
doesn't look like too much work to fix it. Obviously you have to write
everything by hand, so it's repetitive work. But at least you get a
readable codebase + you get to statically link with the library.
Re: Concurrency.
On Mon, 28 Nov 2011, Debdatta wrote: > >>1. Your variables are thread local. This guarantees some nice > >>properties, like code that was intended to run in a single-threaded > >>environment when it was written will behave nicely in a multi-threaded > >>environment too, because every thread gets a copy of all global data. > >>This is a sane default. > > Now I understand your reasoning a lot better. :D this is one case where D's > defaults will come very handy. Its very different from what I have seen > so far, so maybe its a culture shock. > > >>There is one to one feature correspondence. > > Of course. That is obvious.:D It just seemed counter intuitive to have every > variable I declare to be thread local. Will experiment with it some > more and see if I can get used to the concept. You seem to have very good > reasons to prefer it, and I hope I can see them too. :D > > -Debdatta If _most_ of your variables are thread local, then I think you might well be doing something wrong. Since that means that you're using a lot of what would be global variables in C/C++. In my experience, MOST variables are function scoped, and thus stack variables. My 2 cents, Brad
Re: A real Forum for D
On 27/11/2011 17:41, alex wrote: Hi folks, I just wondered why there still is this uncomfortable and obviously outdated newsgroup software in use. Perhaps it'd be more contemporary to have a 'real' browser-based forum to which everyone can register and post D-related questions&answers. So, my recommendation would be to establish a forum based on phpBB or a similar framework software (btw, it's free and open source, so don't worry about possible costs!) at forum.d-programming-language.org To give D a further community 'push', I and a friend of mine really would like to set up all required things if wanted. The reason I'm asking the newsgroup directly is to have the forum that can be reachedunder the official D internet URL, so that it won't be a 'third-party' driven one or something like that. Even if this idea should be a bit too 'large', please do fix the http interface for the D main newsgroup thread - it's not working for me and only gives back a connection timeout. Ok, so there was already lots of discussion. Just let me add my 2 cents... PHP forum? Noo!1 If D had a web-based forum only I would not bother reading it or ever coming back to it. I would not have bothered trying to learn any D. I like how these "ancient" newsgroups sort and organise individual messages. I get a nice threaded view, I can see what I've read already, who replied to what. Very efficient. Forum? barf... I hate having to sign up here and register there. I opportunistically want to reply to messages. All this clutter around it, avatars, annoying formatting. Please, pretty please, no. A nice web-based interface to the newsgroup? Yeah could do (I wouldn't use it though).
Re: A real Forum for D
On 11/28/2011 09:27 PM, Kagamin wrote: Walter Bright Wrote: On 11/27/2011 11:55 PM, Jacob Carlborg wrote: On 2011-11-27 23:30, Walter Bright wrote: Those are all desirable properties. But the forum software I've seen throws out what's good about NNTP news forums: 1. Threaded view 2. Being able to mark messages as "read" 3. Being able to quickly scan read vs unread Just because this may be true for most of the forums doesn't mean it needs to be true if d-p-l.org gets a new forum. BTW, most forum software is pretty much unreadable on small, mobile screens because all the real estate is consumed by the borders, avatars, decorations, gee-gaws, etc. Even text-only reddit blows on the small screen because the text refuses to reflow. Then that's just bad design. If the forum is designed correctly there won't be any problem. Here's a typical example: http://www.cuda-challenger.com/cc/index.php?topic=72850.0 Check out all of the vertical space consumed by a 2 word message. http://article.gmane.org/gmane.comp.lang.d.general/70244 - and this is not a limit, I've seen a 2 word message three times as bigger. I have two windows, one to browse the messages and one to display the messages.
Re: Documentation 'quick index'
On Monday, November 28, 2011 22:17:02 Piotr Szturmaj wrote: > Jonathan M Davis wrote: > > On Monday, November 28, 2011 22:45:17 Vladimir Panteleev wrote: > >> On Mon, 28 Nov 2011 22:38:49 +0200, Piotr > >> Szturmaj > >> > >> wrote: > >>> Hi, > >>> > >>> I'm trying to make ddoc index more readable. Here are some early > >>> results: > >>> > >>> http://bot.neostrada.pl/dpl.org/std.datetime.html > >> > >> I think that for something like this to have full benefit, DDoc would > >> need to be fixed so that generated anchors include their context. > > > > Yeah. I'd have made std.datetime's links similar to what's in > > std.algorithm, but as long as anchors aren't unique, there's not much > > point. > > I think that would be the best approach. This > would make tree generation easier (currently it parses text near to > anchor) and all anchors would be unique. Using the mangled name would help deal with overloaded functions but would be completely unnecessary for classes and structs. Simply doing something like #SysTime.year would make it unique enough for them. But the manged names may be preferable, since then overloaded functions could be distintguished (though the anchors would then be a lot less human-readable). > > Whether this specific proposal is really the best way to go or not, I > > don't know, but there's no question that the links should represent the > > hierarchy of the module. > > Do you mean sort order? This can be made switchable with single checkbox. No. I mean the hierarchy - as in understanding the difference between free functions and member functions. The links at the top should show member functions (and member variables if they're not private) as being part of the type that they're part of, not as free functions. The example that the OP gives does that, whereas the current situation just gives a list of links with no regard to what they point to. So, while some of the details of his presentation may not be the best, the basic idea is solid. Unfortunately, as long as the links are non-unique, it doesn't help much - particularly for std.datetime. - Jonathan M Davis
Re: wxC & wxD
So, is wxD going to continue like now, or do you envision some change how to proceed for wx-2.9/3.=? I don't plan to do anything with it, I put it up on github so that it could be forked and maintained if there are any bugfixes etc needed... So if i understand you right, the way to keep wxD alive ist to fork your repository and continue it as an independent project ?
Re: Compile-time Interfaces
On 11/28/11 2:39 AM, Marco Leise wrote: Sounds familiar :D http://www.digitalmars.com/d/archives/digitalmars/D/static_interface_for_structs_146478.html Not to mention http://lists.puremagic.com/pipermail/digitalmars-d/2009-April/053098.html. Andrei
Re: Documentation 'quick index'
On 11/28/2011 09:38 PM, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Thanks CandyDoc comes with class, struct and other images: http://www.dsource.org/projects/helix/browser/trunk/doc/candydoc/img/outline -- Mike Wey
Re: wxC & wxD
Gour wrote: Just that I won't have much time to actually maintain it, myself. I'm also not capable to lead such project and would have to take that into consideration when deciding which GUI toolkit to use with D. In any case, for now, I plan to learn more D, master some CMake and start playing with SWIG in order to provide bindings for 3rd party C library which we'll use. I'm no fan of either, and prefer plain import modules and libs over function pointers and complex tools. But I guess that was obvious. Then, in the meantime, maybe there will be more clear which toolkit is optimal to use when writing desktop app in D *today*. Well, I believe you had the officially supported DWT and QtD plus the also available GtkD and wxD. Didn't seem like a bad selection ? All four of those are well supported toolkits, _upstream_ that is. Either GUI should do the trick for writing a desktop application. But even if Phobos/Deimos would have something like Tk (or FLTK) integrated, it probably wouldn't be accepted as a real solution. That is, just for being too ugly or too grey or something similar. Something like "MinWin" or Lucid seemed like a good idea to have in the standard D library, just a small native wrapper for GUI... But before that happens, you're stuck with the third party efforts. Now, why would you want to use D as your language(s) rather than C, Python, Java ? Or even C++. That was the real question for me. There has to be enough advantages to overcome the shortcomings, which in the end wasn't true when making desktop apps (or games). --anders
Re: boost crowd.
bearophile Wrote: > And this is positive because? You say it as if it's negative.
Re: boost crowd.
Walter: > On 11/28/2011 4:00 AM, Alexey Veselovsky wrote: > > Compiler doesn't know anything about "specification" files. So, he > > did't check specification&implementation conformance. > > Yes, that's correct. And this is positive because? See also Timon answer: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=150164 Bye, bearophile
Re: A real Forum for D
so Wrote: > As i was thinking it can't get any worse, you proved me wrong. For linear chronological view it's a natural thing. Also: 1. Messy software screws your threads for real. In a forum a post ends up right where it belongs to: messy clients are not a problem for chronological order. 2. "Oops, I deleted your post in my Pan client and don't know how to get it back, I'll just post reply somewhere". With forum this is just impossible: posts are on the server.
Re: is D ncurses-only language?
On 11/28/2011 05:08 PM, Gour wrote: On Wed, 23 Nov 2011 22:58:00 +0100 Mike Wey wrote: Yes, I'll probably update GtkD to the latest 2.x release before looking at GTK+ 3. Have you considered using SWIG to provide GtkD bindings? I'll have to check it out, currently updating the lookup files will be the easiest way to update GtkD. btw, do you have any influence @dsource forums? I registered 8 days ago and still neither received confirmation email that my account was activated nor I can login. You'll probably have to contact Brad. Sincerely, Gour -- Mike Wey
Re: Documentation 'quick index'
On Mon, 28 Nov 2011 15:38:49 -0500, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Just an FYI, this does not render properly on opera. I have only have a top-level index that does not operate (and yes, I have javascript on). My personal opinion is that the index should not rely on javascript whatsoever. If anything, a collapsable index of everything should be available at the top (expanded by default if javascript is disabled). There should only be one level -- show all or hide all. In general, DDoc suffers from so many deficiencies, fixing the index seems like wasted effort. I'd prefer improvements like have one page per item (class, function, etc) similar to doxygen. This would turn behemoths such as std.datetime into manageable doc pages. I also think a vastly important (and for some reason ignored by ddoc) feature of documentation generators is cross referencing. The whole benefit of having a computer generate documentation from source is that it knows how the source is related. That should all be reflected. For instance, I should be able to have a clickable inheritance tree for a class, and be able to have clickable links to overridden methods. Any examples should have clickable links to the items being used. These improvements would improve the docs by 2 orders of magnitude, whereas fixing the index is a trivial improvement. Not that the index couldn't use improvement, however I understand the reluctance to take up the bigger ddoc tasks, I would not be able to do it. -Steve
Re: Documentation 'quick index'
Jonathan M Davis wrote: On Monday, November 28, 2011 22:45:17 Vladimir Panteleev wrote: On Mon, 28 Nov 2011 22:38:49 +0200, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html I think that for something like this to have full benefit, DDoc would need to be fixed so that generated anchors include their context. Yeah. I'd have made std.datetime's links similar to what's in std.algorithm, but as long as anchors aren't unique, there's not much point. I think that would be the best approach. This would make tree generation easier (currently it parses text near to anchor) and all anchors would be unique. Whether this specific proposal is really the best way to go or not, I don't know, but there's no question that the links should represent the hierarchy of the module. Do you mean sort order? This can be made switchable with single checkbox.
Re: A real Forum for D
so Wrote: > Except it has noting remotely resembles a novel, where the author plots to > a final common goal, > which happens to be written/thought long before the actual writing. There's no visible difference if the novel runs for decades. > > Chronological order also helps to understand people. This way posts tend > > to be grouped by author (remember you've posted 4 messages in a row to > > this topic). This way one can better understand you as your thoughts are > > concentrated in one place rather than scattered all over sub-threads: > > will all information at hands it's easier to figure out your viewpoint > > in all details. > > A suggestion, use threaded view and you don't need to "understand" any of > this, > you just see them without any effort. This is not a solution even for this particular problem, and people do not speak only about theaded and linear views anyway.
Re: Documentation 'quick index'
On Monday, November 28, 2011 22:45:17 Vladimir Panteleev wrote: > On Mon, 28 Nov 2011 22:38:49 +0200, Piotr Szturmaj > > wrote: > > Hi, > > > > I'm trying to make ddoc index more readable. Here are some early > > results: > > > > http://bot.neostrada.pl/dpl.org/std.datetime.html > > I think that for something like this to have full benefit, DDoc would need > to be fixed so that generated anchors include their context. Yeah. I'd have made std.datetime's links similar to what's in std.algorithm, but as long as anchors aren't unique, there's not much point. Whether this specific proposal is really the best way to go or not, I don't know, but there's no question that the links should represent the hierarchy of the module. - Jonathan M Davis
Re: A real Forum for D
On Mon, 28 Nov 2011 22:44:51 +0200, Kagamin wrote: Some forums even have plugins that merge consecutive posts from the same author. As i was thinking it can't get any worse, you proved me wrong. In Soviet Russia... errm... I mean with linear chronological view you do. Think of it as a novel: it has a linear structure, a bunch of plot threads and they intertwine in chronological order. And it's usually not a problem to track them simultaneously. Except it has noting remotely resembles a novel, where the author plots to a final common goal, which happens to be written/thought long before the actual writing. Chronological order also helps to understand people. This way posts tend to be grouped by author (remember you've posted 4 messages in a row to this topic). This way one can better understand you as your thoughts are concentrated in one place rather than scattered all over sub-threads: will all information at hands it's easier to figure out your viewpoint in all details. A suggestion, use threaded view and you don't need to "understand" any of this, you just see them without any effort.
Re: Documentation 'quick index'
Vladimir Panteleev wrote: On Mon, 28 Nov 2011 22:38:49 +0200, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html I think that for something like this to have full benefit, DDoc would need to be fixed so that generated anchors include their context. Yes, DDoc may be changed to inject mangled names. With javascript demangler they may be very helpful. Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Try looking at some FOSS IDEs: Eclipse, CodeBlocks, KDevelop, etc. Will do, thanks.
Re: Documentation 'quick index'
On Mon, 28 Nov 2011 22:38:49 +0200, Piotr Szturmaj wrote: Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html I think that for something like this to have full benefit, DDoc would need to be fixed so that generated anchors include their context. Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Try looking at some FOSS IDEs: Eclipse, CodeBlocks, KDevelop, etc. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: A real Forum for D
Walter Bright Wrote: > On 11/27/2011 5:40 PM, Jude wrote: > > //quote cause I'm lazy > > Those are all desirable properties. But the forum software I've seen > > throws out what's good about NNTP news forums: > > > > 1. Threaded view > > 2. Being able to mark messages as "read" > > 3. Being able to quickly scan read vs unread > > //end quote > > > > 1. Forums can have threaded view too, > > Generally, they suck. They just don't get what a threaded view is. > Newsreaders > solved this problem decades ago. A thread is not a topic. It's a view showing > who replied to which message. It's not a contract, it's just a convention. I can easily imagine how to reply to two messages in one posting. Some forums even have plugins that merge consecutive posts from the same author. > Click to expand at each branching point, click to > contract, click to see a particular message. At each point, you can see which > messages you've read, and which you haven't. In forum you already have all messages before your eyes. > > 2. I thought that that was pretty standard for forums? Highlighting > > for threads you've seen and threads you haven't... not for individual > > messages, but the last number (25 or so) messages you've seen. > > Again, the forum software writers just don't get it. It has to be per > message. > Why? So in a larger thread, you can instantly see what is read and what > isn't. > This is NOT equivalent to a chronological sort. I do not read threads > linearly. In Soviet Russia... errm... I mean with linear chronological view you do. Think of it as a novel: it has a linear structure, a bunch of plot threads and they intertwine in chronological order. And it's usually not a problem to track them simultaneously. Chronological order also helps to understand people. This way posts tend to be grouped by author (remember you've posted 4 messages in a row to this topic). This way one can better understand you as your thoughts are concentrated in one place rather than scattered all over sub-threads: will all information at hands it's easier to figure out your viewpoint in all details.
Documentation 'quick index'
Hi, I'm trying to make ddoc index more readable. Here are some early results: http://bot.neostrada.pl/dpl.org/std.datetime.html Do you know some free icons of class, enum, function, etc? I'm thinking of something like this: http://msdn.microsoft.com/en-us/library /y47ychfe%28v=vs.80%29.aspx Thanks
Re: wxC & wxD
On Mon, 28 Nov 2011 21:01:38 +0100 Anders F Björklund wrote: > Of course, you don't *have* to wrap all the classes or methods ? > One could start with the ones that are likely to be used from D. Well, it is still big project and not so easy to say what needed. In any case, substantial part has to be bound in order to get into writing multi-platform desktop app. > Automation is surely the way to go, the only question is whether it > should be a custom script or if a (patched?) SWIG would be better. That's hard for me to say. > If it helps, there's a Doxygen parser (for the XML output) in the > docs/doxygen/scripts directory that could be used to start it off: > > cd docs/doxygen > ./regen.sh xml > python scripts/make_bindings.py --swig --output_dir=bindings \ > out/xml/classwx_app.xml > > The generated SWIG bindings are for wxPython, but I suppose you > could adopt the swig_tools.SWIGBuilder to generate some D SWIG ? I'll take a look to see if it makes sense to me. :) > Just that I won't have much time to actually maintain it, myself. I'm also not capable to lead such project and would have to take that into consideration when deciding which GUI toolkit to use with D. In any case, for now, I plan to learn more D, master some CMake and start playing with SWIG in order to provide bindings for 3rd party C library which we'll use. Then, in the meantime, maybe there will be more clear which toolkit is optimal to use when writing desktop app in D *today*. Sincerely, Gour -- One who restrains his senses, keeping them under full control, and fixes his consciousness upon Me, is known as a man of steady intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: A real Forum for D
Walter Bright Wrote: > On 11/27/2011 11:55 PM, Jacob Carlborg wrote: > > On 2011-11-27 23:30, Walter Bright wrote: > >> Those are all desirable properties. But the forum software I've seen > >> throws out what's good about NNTP news forums: > >> > >> 1. Threaded view > >> 2. Being able to mark messages as "read" > >> 3. Being able to quickly scan read vs unread > > > > Just because this may be true for most of the forums doesn't mean it needs > > to be > > true if d-p-l.org gets a new forum. > > > >> BTW, most forum software is pretty much unreadable on small, mobile > >> screens because all the real estate is consumed by the borders, avatars, > >> decorations, gee-gaws, etc. Even text-only reddit blows on the small > >> screen because the text refuses to reflow. > > > > Then that's just bad design. If the forum is designed correctly there won't > > be > > any problem. > > > Here's a typical example: > > http://www.cuda-challenger.com/cc/index.php?topic=72850.0 > > Check out all of the vertical space consumed by a 2 word message. http://article.gmane.org/gmane.comp.lang.d.general/70244 - and this is not a limit, I've seen a 2 word message three times as bigger. > No threading > view that I can find. There's a "Mark Unread" button, but that applies to the > entire thread, not individual messages. > > Here's another: > > http://www.gamedev.net/topic/615737-concave-polygon-to-convex-polygons/page__pid__4887554#entry4887554 > > Same problems. > > http://community.seattletimes.nwsource.com/reader_feedback/public/display.php?source_id=2016875109&source_name=mbase > > Note the teeny tiny amount of the screen that is for message text. > > http://science.slashdot.org/story/11/11/28/0050228/muslim-medical-students-boycott-darwin-lectures > > At least it's got a real threaded view. But no way to tell what you've read, > so > if you come back to an active topic after an hour or two, it's a real pain > trying to figure out what you've read and what you haven't. I rarely bother > to > load a topic more than once because of this. Same goes for reddit.
Re: boost crowd.
so Wrote: > On Mon, 28 Nov 2011 21:12:32 +0200, Kagamin wrote: > > > In Java separation is done with interfaces. I think it is right. > > For Java, yes. Java, D or C++, classes and structs are not a separation. Want a real separation? See COM: it doesn't even have notion of a field.
Re: wxC & wxD
Gour wrote: Here's a more complete example of what it would look like in the end: http://svn.wxwidgets.org/svn/wx/wxPython/trunk/src/ http://wxruby.rubyforge.org/svn/trunk/wxruby/swig/classes/ Thank you. Of course, you don't *have* to wrap all the classes or methods ? One could start with the ones that are likely to be used from D. Even using SWIG, there's a whole lot of code that needs to be written. Sure. We just wonder if using route will be more effective in the long run? Automation is surely the way to go, the only question is whether it should be a custom script or if a (patched?) SWIG would be better. BTW: If it helps, there's a Doxygen parser (for the XML output) in the docs/doxygen/scripts directory that could be used to start it off: cd docs/doxygen ./regen.sh xml python scripts/make_bindings.py --swig --output_dir=bindings \ out/xml/classwx_app.xml The generated SWIG bindings are for wxPython, but I suppose you could adopt the swig_tools.SWIGBuilder to generate some D SWIG ? python scripts/doxymlparser.py --report out/xml/classwx_app.xml I don't plan to do anything with it, I put it up on github so that it could be forked and maintained if there are any bugfixes etc needed... OK. It's perfectly doable to continue to use the current wxd.sourceforge.net even with wx 3.0 and D 2.0, so I think I will just leave that up as-is. OK. Just that I won't have much time to actually maintain it, myself. When starting up the "wxD2" or "$deity" - or whatever the new project would be named, it could probably do more changes than just use SWIG ? Thank you for making it clear. ;) Whether it's about hosting or organization, or something different. --anders
Re: boost crowd.
On 11/28/2011 4:00 AM, Alexey Veselovsky wrote:
ok. I just removed from test.di all non public entities.
// D import file generated from 'test.d'
module test;
public
{
void foo();
struct Boo
{
public
{
void boo();
}
}
}
Now, let's build it:
$ dmd test.di test.d main.d
test.d: Error: module test from file test.d conflicts with another
module test from file test.di
di file not specification, but just another version of implementation?
You cannot compile with both the di and d file.
Compiler doesn't know anything about "specification" files. So, he
did't check specification&implementation conformance.
Yes, that's correct.
Re: A real Forum for D
On 11/28/2011 5:33 AM, Jacob Carlborg wrote: I know that most of the forums look like this. But what says that they have to? I'm just trying to say that a forum doesn't have to look like these examples. You also complained how the forum sites doesn't work on a small screen. Have a look at this site: http://upperdog.se/ I know this site is not a forum but the content flows really nice when you resize the browser window to a smaller size and it works great on mobile devices. I don't see any reason why these techniques can't be implemented on a forum. I don't see any reason, either. It's why I said that forum software writers just don't get it :-)
Re: boost crowd.
On 11/28/2011 3:41 AM, Alexey Veselovsky wrote:
ok. What about:
struct Foo {
int a;
int b;
// 100 more fields
...
void foo();
}
Did I must write in implementation all this 100+ fields in implementation?
Yes. (Unless you decide to use the PIMPL idiom.)
Re: boost crowd.
On Mon, 28 Nov 2011 21:12:32 +0200, Kagamin wrote: In Java separation is done with interfaces. I think it is right. For Java, yes.
Re: Concurrency.
On 11/28/2011 07:41 PM, Debdatta wrote: 1. Your variables are thread local. This guarantees some nice properties, like code that was intended to run in a single-threaded environment when it was written will behave nicely in a multi-threaded environment too, because every thread gets a copy of all global data. This is a sane default. Now I understand your reasoning a lot better. :D this is one case where D's defaults will come very handy. Its very different from what I have seen so far, so maybe its a culture shock. Probably that is the case. =) There is one to one feature correspondence. Of course. That is obvious.:D It just seemed counter intuitive to have every variable I declare to be thread local. Will experiment with it some more and see if I can get used to the concept. You seem to have very good reasons to prefer it, and I hope I can see them too. :D -Debdatta
Re: boost crowd.
Alexey Veselovsky Wrote:
> ok. What about:
>
> struct Foo {
> int a;
> int b;
> // 100 more fields
> ...
> void foo();
> }
>
> Did I must write in implementation all this 100+ fields in implementation?
>
> In Ada and Modula there is 2 languages: one for implementation and
> another for specification. (specification language not subset of
> implementation language). I think it is right.
In Java separation is done with interfaces. I think it is right.
Re: Concurrency.
On Monday, November 28, 2011 18:41:46 Debdatta wrote: > >>There is one to one feature correspondence. > > Of course. That is obvious.:D It just seemed counter intuitive to have every > variable I declare to be thread local. Will experiment with it some more > and see if I can get used to the concept. You seem to have very good > reasons to prefer it, and I hope I can see them too. :D It's only counter-intuitive because most languages share everything by default. Well-written multi-threaded code already separates everything such that threads communicate only at key points in the program, so while it's atypical to make much thread-local in other languages, good programs in other lanuages generally wouldn't care if most of their variables became thread- local. D just takes it to the next level by actually making them thread-local and enforcing it with the type system. So now, each of those points where threads are supposed to communicate either use message passing or shared, and the rest of the program is protected from having its pieces stomp on each other unless you go out of your way to make it happen. Ultimately, D's basic approach makes more sense IMHO, but it's just not what has typically been done in other languages, so it requires mental shift, but since most good programs essentially already follow D's model in other languages (just without usually actually making the data thread-local), ultimately, it's not really all that big a shift. I've had to deal with programs where any thread can be anywhere in the code, and it's horrific. D's allows such an approach, but it makes it a lot harder, so the default approach ends up being much more sane. - Jonathan M Davis
Re: SQL/database server capabilities NO ODBC please
On 2011-11-28 15:34, Steve Teale wrote: On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote: On 2011-11-27 07:13, Steve Teale wrote: You may detest ODBC, but it is very soon going to be the only way to communicate with SQL Server short of writing another wire protocol effort. There was the alternative of OLE DB, but MS is dumping that. FreeTDS can be used directly. True. I was thinking Windows at the time (very unusual). Steve I'm pretty sure FreeTDS works on Windows. There's a RubyGem, TinyTDS and works on Windows and uses FreeTDS. https://github.com/rails-sqlserver/tiny_tds -- /Jacob Carlborg
Re: Concurrency.
>>1. Your variables are thread local. This guarantees some nice >>properties, like code that was intended to run in a single-threaded >>environment when it was written will behave nicely in a multi-threaded >>environment too, because every thread gets a copy of all global data. >>This is a sane default. Now I understand your reasoning a lot better. :D this is one case where D's defaults will come very handy. Its very different from what I have seen so far, so maybe its a culture shock. >>There is one to one feature correspondence. Of course. That is obvious.:D It just seemed counter intuitive to have every variable I declare to be thread local. Will experiment with it some more and see if I can get used to the concept. You seem to have very good reasons to prefer it, and I hope I can see them too. :D -Debdatta
Re: boost crowd.
so Wrote: > http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ o.O overload a lambda?
Re: boost crowd.
On 11/28/2011 06:41 PM, Maxim Fomin wrote:
2011/11/28 Timon Gehr:
On 11/28/2011 09:01 AM, so wrote:
On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
wrote:
On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
"D has a true module system that supports separate compilation and
generates and uses module summaries (highbrowspeak for "header files")
automatically from source, so you don't need to worry about
maintaining redundant files separately, unless you really wish to, in
which case you can. Yep, that stops that nag right in mid-sentence."
But it is not true...
How is it not true?
I don't know if .di generation from .d or .h is any good or bad,
but the comparison of auto-generated .di files to hand crafted .h files
doesn't make sense.
Nobody stops you from hand crafting *.di files.
And what sense is in hand crafting .di files? What would you do different?
Remove method definitions/private members?
The main point is that some people want to have separate specification
and implementation. If you don't separate the two, they risk being
confused. (as is often the case with the D programming language and its
reference implementation.)
In such a setting, the .di file can eg. act as a contract between
library implementer and library user.
Eg:
// .di, this is the specification
module awesomeLibrary;
/**
* Documentation comment
*/
int foo(in int x)
/// maybe documentation comment on in contract
in{assert(xx);}
class Bar {
int foo(int x)
in{...}
out{...}
}
// .d, the implementation
int foo(int x) { // (contract automatically read from .di file)
return x+1;
}
class Bar{
int foo(int x){
return x + y;
}
private int y;
}
And that is the kind of stuff that does not work yet.
Re: Structs on private section.
On 28/11/11 1:56 AM, deadalnix wrote:
Le 28/11/2011 03:29, Alexey Veselovsky a écrit :
D's private is different than some other languages (e.g. C++).
'private' provides access to the entire module.
public: no access limitation
private: access by the module
package: access by the modules of the package
protected: access by the inheriting classes
But it works even if class Foo declarated in dufferent module.
Also this code works:
module a;
private { struct S {int a;}}
module b:
import a:
void f() {S s; s.a=42;}
So you now have discovered a bug.
A bug that has been known about for quite some time. I also created a
pull request for a fix quite some time ago (June), but hasn't been
pushed yet.
https://github.com/D-Programming-Language/dmd/pull/163
+
https://github.com/D-Programming-Language/druntime/pull/32
Unfortunately, the druntime changes are required due to issue 314. For
example, with the private type fix, the following code would not compile:
---
module A;
struct Foo {}; // public
---
module B;
import A : Foo; // private selective import
---
module C;
import B;
import A;
Foo f; // error: B.Foo is private
---
Due to bug 314, the private import in module B causes Foo to become a
private symbol of module B (rather than just importing it). When module
C tries to use Foo, it first looks in module B, finding the private Foo
and complains of access violation. It doesn't even look at the Foo in
module A because access checks are done before overload resolution.
It's quite ugly that access checks are not considered in overload
resolution because it means I can break user code by adding private
symbols to my library. It won't be a silent break, but it will break
nonetheless.
Re: boost crowd.
On 11/28/2011 05:07 PM, Maxim Fomin wrote:
2011/11/28 Max Samukha:
On 11/28/2011 02:29 PM, so wrote:
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha
wrote:
How would you write libraries?
The way they do, for example, in C# - interface definitions are stored
in the library, no need for separate headers.
Are we talking about the same thing?
Something like
http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx?
So it does what auto-generated .di files does, and turns it into an
abomination, it relies on an IDE feature?
No, it has nothing to do with the IDE. The article describes a visual tool
for viewing meta-data stored in a .NET binary. You don't have to use it.
Specially for you, die-hard IDE haters, this is how to use the terminal to
create a mono app and library:
1. Library:
nano lib.cs
using System;
public class Lib
{
public static void hello() { Console.WriteLine("We don't need no header
crap"); }
}
Compile that into a library, lib.dll:
dmcs lib.cs -target:library
2. Host:
nano app.cs
class App
{
public static void Main()
{
Lib.hello();
}
}
Compile and run the app:
dmcs app.cs -reference:lib.dll
./app.exe
We don't need no header crap
[skipped]
Probably i am mistaken that this post supports D modules
(in a way, showing that header files are crap), but ...
In C# no headers are required, because it includes metadata in dynamic library.
In your example you link code to compiled library without header files.
However, this is not possible in D. Programmer have to compile his
code with library code,
which also should include all private members, which supposed to be hidden.
In attempt to eliminate "header crap" D breaks modularization.
Some comparison of C/C++/C#/D writing libraries.
C: write in separate .c file, declare exported object as opaque
structure/void*. No need to recompile program,
when library implementation changes. Program does not know
anything about private members.
Lib files are no longer required on program compilation. Code can
be separated though many files.
Negative: make changes in min 3 files (program, header, library)
when interface is changed.
C++ : one negative difference comparing with C is that private
members are known, and you need recompilation, when you change
something
related to them.
C#: as example above. No headers. Private members are not known. Just
link program upon compiling to already compiled .dll
No GC issues across libraries/program.
Actually, this is the best modularization support comparing these 4
languages.
D: currently difficulties when generating dynamic libraries in linux.
Also GC issue when calling D code from D
(from http://d-programming- language.org/dll.html). Programmer
should ship library code with program (Walter Bright showed simple
example
with function exporting. And what about a class, its methods and
private members?). Recompile everything when implementation/interface
is changed. No way to put class code in separate files. Wired
"interface file" generation which knows implementation better than its
author.
In conclusion, I find D module support the worst one.
This is in no way related to the D module system, which is quite nicely
designed. You are describing issues with the tool chain. Those indeed
hamper modular compilation, and should be sorted out eventually. You
might want to file a bug report.
Re: boost crowd.
On 11/28/2011 05:41 PM, Alexey Veselovsky wrote: Separate hand written specification is rulez for human. It is best short module description (with some useful manually written comments). I like it more then autogenerated docs (by doxygen and so on). Autogenerated specifications (headers and so on) are worst and ugly. But in language like java and C# it is last chance if there is no autogenerated docs and sources. The compiler _should_ enforce consistence between *.d and *.di files when compiling the *.d file. It just does not because nobody has implemented it. That is possibly because separate hand written specification is rarely used in D development. (alternatively, it could be the case that hand written specification is used rarely because DMD does not check .d and .di for consistence.) Autogeneration of *.di files does not have to be the normal case (and currently it is so buggy that I managed to find a segfault bug in the compiler while compiling a mis-generated *.di file!) Also, auto generation can hardly even work satisfactory in the general case, when there are many static if's/version statements or string mixin declarations on module scope.
Re: boost crowd.
2011/11/28 Timon Gehr : > On 11/28/2011 09:01 AM, so wrote: >> >> On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright >> wrote: >> >>> On 11/27/2011 4:44 PM, Alexey Veselovsky wrote: "D has a true module system that supports separate compilation and generates and uses module summaries (highbrowspeak for "header files") automatically from source, so you don't need to worry about maintaining redundant files separately, unless you really wish to, in which case you can. Yep, that stops that nag right in mid-sentence." But it is not true... >>> >>> How is it not true? >> >> I don't know if .di generation from .d or .h is any good or bad, >> but the comparison of auto-generated .di files to hand crafted .h files >> doesn't make sense. > > Nobody stops you from hand crafting *.di files. > And what sense is in hand crafting .di files? What would you do different? Remove method definitions/private members?
Re: Doom3 (id tech 4) port/binding in D ?
Am 28.11.2011, 18:21 Uhr, schrieb Benjamin Thaut : I don't think porting any game to D is a good idea right now. I've did some major game developement on D. Half my code uses manual memory management and still the D garbage collector is a major performance issue. Unless you want to do all of the memory management yourself, which pretty much results in not using phobos and most of the cool features in D I wouldn't recommend porting a bigger game to D. We really need to get CDGC up and running.
Re: boost crowd.
On Mon, 28 Nov 2011 19:26:23 +0200, Timon Gehr wrote: Nobody stops you from hand crafting *.di files. My point exactly.
Re: wxC & wxD
On Mon, 28 Nov 2011 16:18:33 +0100 Anders F Björklund wrote: > At this point in time it doesn't matter, the generated files are > different even if the scripts to generate them are somewhat similar. > The API is also different, from the different languages used and > from this recent push to rename things to be more like rest of .NET. OK. > Easiest way to tell is to start wrapping a couple of classes, to see ? [...] > Here's a more complete example of what it would look like in the end: > > http://svn.wxwidgets.org/svn/wx/wxPython/trunk/src/ > http://wxruby.rubyforge.org/svn/trunk/wxruby/swig/classes/ Thank you. > Even using SWIG, there's a whole lot of code that needs to be written. Sure. We just wonder if using route will be more effective in the long run? > I don't plan to do anything with it, I put it up on github so that it > could be forked and maintained if there are any bugfixes etc needed... OK. > Both wxWidgets and Code::Blocks are Open Source, so if you want to > continue to base the GUI and IDE for the D programming language on > those there's plenty of things that could be improved for either... Well, for IDE, I'll probably use Geany. As far as GUI-part is concerned, depending on the toolkit we choose. we'd just use some GUI builder (each toolkit has some.) > The wxWidgets roadmap says "We hope to make 3.0 in the spring of > 2012." But as mentioned earlier, using 2.9 should be just fine before > that ? Yes. Afaik, the major part of new wx-3.0 stuff is already in 2.9. > It's perfectly doable to continue to use the current > wxd.sourceforge.net even with wx 3.0 and D 2.0, so I think I will > just leave that up as-is. OK. > When starting up the "wxD2" or "$deity" - or whatever the new project > would be named, it could probably do more changes than just use SWIG ? Thank you for making it clear. ;) Sincerely, Gour -- When your intelligence has passed out of the dense forest of delusion, you shall become indifferent to all that has been heard and all that is to be heard. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: boost crowd.
On 11/28/2011 09:01 AM, so wrote: On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright wrote: On 11/27/2011 4:44 PM, Alexey Veselovsky wrote: "D has a true module system that supports separate compilation and generates and uses module summaries (highbrowspeak for "header files") automatically from source, so you don't need to worry about maintaining redundant files separately, unless you really wish to, in which case you can. Yep, that stops that nag right in mid-sentence." But it is not true... How is it not true? I don't know if .di generation from .d or .h is any good or bad, but the comparison of auto-generated .di files to hand crafted .h files doesn't make sense. Nobody stops you from hand crafting *.di files.
Re: Doom3 (id tech 4) port/binding in D ?
Am 23.11.2011 17:16, schrieb deadalnix: Hi, I want to suggest a project to the community. Doom3 source code has just been released, and I think we may want to do a port in D. Here are the reasons : 1/ I think D is suitable and pertinent for video games. 2/ This would make a solid code base to promote D. 3/ Id software is very popular, and porting one of their engine is free advertisement for D. 4/ The build system for doom engine is scons, and it support D too. 5/ The code base is an high quality one. (for exemple, the _t suffix is used to differenciate what we call struct and classes in D - and that has no difference in C++ except in the usage you make of it). 6/ It's an interesting project. 7/ Many people in the D community are interested in video game projects. 8/ Doom's story take place on mars, phobos and deimos (well and on earth, but who care ?). In addition, this is a good occasion to produce some code for deimos and can enlight us on D future evolutions backed with solid fact. On my knowledge, such a big project (big in size, but also in technicity) don't exist in D yet. Anyway, don't expect this to be easy. We are talking here about 500 000 lines of C++ (not including headers). And the code is performance critical. We may have 2 approachs : a complete port or a binding (so translation of doom's headers in D + some glue code between D and C++ - which isn't as easy as it seems). This is definitively not a one man job, but I'm sure we have some skilled dev here and we all want to promote D. If some of you do think that it's a good idea and want to spend some time on it (this is definitively a critical point). I'm definitively in. And you ? I don't think porting any game to D is a good idea right now. I've did some major game developement on D. Half my code uses manual memory management and still the D garbage collector is a major performance issue. Unless you want to do all of the memory management yourself, which pretty much results in not using phobos and most of the cool features in D I wouldn't recommend porting a bigger game to D. -- Kind Regards Benjamin Thaut
Re: Concurrency.
On 11/28/2011 01:57 PM, Debdatta wrote: @Michael, Thanks for clearing that up. Your post was very informative. :) Actually, the private data of your thread object could be used by other threads if the MyThread object is accessible from another thread and someone calls a method on it. Absolutely! However I presume that any self respecting programmer will not manipulate shared data without planning it, or at least thinking about it. :D Any self respecting coder would know about memory boundaries, and not arbitrarily modify shared data. Any self respecting coder only writes correct code. That is why there are never software bugs. Not having default sharing is about providing guaranties, it's about making thread-safety checkable by the compiler. Nope, it is mostly about providing safe, efficient and convenient _defaults_ (that is why it is called no sharing _by default_). In C#/Java you have those three options: 1. Your variables are shared, but not that much, because you have no clue when or if at all or in what order changes to a variable in one thread get propagated to other threads. This is the default, of course! 2. Your variables are shared, and the language guarantees sequential consistency of the memory location across threads. To get that you need to annotate your variables with volatile. That makes sense because variables that are not intended to be shared would suffer from a severe and pointless performance hit if they would have to behave the same. Now, well then those should not be shared at all, right? 3. Thread Local Storage. This is the most obscure of the three. In D you have those three options: 1. Your variables are thread local. This guarantees some nice properties, like code that was intended to run in a single-threaded environment when it was written will behave nicely in a multi-threaded environment too, because every thread gets a copy of all global data. This is a sane default. 2. Your variables are shared and the language guarantees sequential consistency (not implemented in DMD yet afaik). This is the 'shared' type modifier. shared is transitive (as opposed to volatile in C#/Java), but if you feel like it, you can just cast away shared. (preferably you should know that it is safe, but as I understand that is the kind of stuff you enjoy a lot.) 3. Your variables are shared, but there is no sequential consistency. This is __gshared. If you have a closer look, you will see that there is a 1 to 1 feature correspondence there. Nothing to complain about. No piece of code can absolutely guarantee threading errors. When you start a thread you are most likely doing it because you want to manipulate shared data. If you wanted complete memory isolation, with the only means of communication being messages, you would create processes, not threads. I understand that this is an over generalization, and the current no default sharing idiom provides less isolation than processes, yo get the drift. :D Threads within a process, by definition(in this case the os defines them), operate within a shared memory space. As soon as those threads run on different cores with separate deeply nested caching hierarchies, that is just an illusion established by message passing on the hardware level. I don't understand the need to add an extra level of complexity in the code, as well as the compiler, by abstracting something thats inherant to the os. There is no extra level of complexity. On the contrary. TLS by default is a very easy concept and it accurately reflects the ideal mental model for the hardware. The only thing that gets added is a tiny bit of explicitness. Its like const correctness. You can write more concise, perfectly working programs without it. and all it gives you is an extra check on whether a function will modify something, which I, as a programmer, already know. Nope, it does not do that. In C++, const correctness means that you cannot call a non-const method on a const reference and that const methods cannot assign to fields of the 'this' reference (unless they are marked as 'mutable', that is). And that is it. D const can provide some guarantees, especially in pure function signatures that enable some compiler optimizations. There is also 'immutable', that gives much stronger guarantees than const. Furthermore shared is not like const correctness because it (should) actually affect the generated code. You may interpret my comments as me not wanting to give up control to the compiler. In that sense, even a GC is abstracting something thats inherant to the os. :D But the GC gives a huge return on investment, and I don't see how the no default sharing rule does. Nobody is giving up control here. You can use type casts to make the compiler shut up, or use __gshared data.
Re: boost crowd.
Do you think it'd be a good thing to put the .di file in the generated compiled lib? That'd be somewhat similar to the c# example. dmd myprog.d something.dll searches something.dll for a .di reference, and adds it to the compile command line if it's there.
Re: boost crowd.
On Mon, 28 Nov 2011 18:41:30 +0200, Alexey Veselovsky wrote: Separate hand written specification is rulez for human. It is best short module description (with some useful manually written comments). I like it more then autogenerated docs (by doxygen and so on). I agree for C/C++ and even for D, but D's module capabilities make auto-generation of the same thing possible, which is a very good thing. Now we need to make it work :)
Re: boost crowd.
On 11/28/2011 06:07 PM, Maxim Fomin wrote: In conclusion, I find D module support the worst one. Sad but true.
Re: boost crowd.
Separate hand written specification is rulez for human. It is best short module description (with some useful manually written comments). I like it more then autogenerated docs (by doxygen and so on). Autogenerated specifications (headers and so on) are worst and ugly. But in language like java and C# it is last chance if there is no autogenerated docs and sources.
Re: boost crowd.
On Mon, 28 Nov 2011 18:21:03 +0200, Max Samukha wrote:
Could you clarify what is the most important part?
As i tried in the above post, header files are specs, a contract between
library writer and the user.
A dll itself is not a spec, it is the implementation.
If you want to use a library, you would need to read its docs anyway.
The interface files won't be of much help (D's ones will, since dmd
liberally pours implementations into them). If the docs are unavailable
or outdated, you can always extract the declarations from the library:
monop -a -r:lib.dll
lib
Version=0.0.0.0
Culture=neutral
PublicKeyToken=null
public class Lib {
public Lib ();
public static void hello ();
}
Creating separate interface files, taking trouble to push them around
along with the library and then feeding them to the compiler are
needlessly redundant steps. Or what am I missing?
Well if you think that is redundant, you should neither comment nor
document your code,
Because i think they are less important than what header files trying to
solve, they don't even give you any guaranties.
The fact is that apps with tight real-time requirements cannot be
developed in C# for obvious reasons, and compilation models are
irrelevant to the fact.
They are mostly libraries so it is more than relevant.
Re: boost crowd.
On 11/28/2011 04:05 PM, so wrote: For the second part if library writer changes anything with "implementation", that would not affect the user. In your case it does, because there is no distinction between specification and implementation There is, but the specification is bundled with the implementation.
Re: is D ncurses-only language? (dsource forums)
On Mon, Nov 28, 2011 at 10:08 AM, Gour wrote: > btw, do you have any influence @dsource forums? > > I registered 8 days ago and still neither received confirmation email > that my account was activated nor I can login. > "To register as a dsource user, head over to Forums and use the Register link. Because of spam, please also send an email to 'brad AT dsource DOT org' so I will know to activate the account. Sorry for the extra steps, but the forums are better for this change." (from http://dsource.org/) The owner of the website (Brad) recently made some changes to how accounts get created due to an onslaught of spam in the forums. jcc7
Re: boost crowd.
On 11/28/2011 03:52 PM, so wrote:
On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha wrote:
No, it has nothing to do with the IDE. The article describes a visual
tool for viewing meta-data stored in a .NET binary. You don't have to
use it.
Specially for you, die-hard IDE haters, this is how to use the
terminal to create a mono app and library:
I started to use vim/cmake "after" years of using IDEs, and one of the
best if not the best VisualStudio.
1. Library:
nano lib.cs
using System;
public class Lib
{
public static void hello() { Console.WriteLine("We don't need no
header crap"); }
}
Compile that into a library, lib.dll:
dmcs lib.cs -target:library
2. Host:
nano app.cs
class App
{
public static void Main()
{
Lib.hello();
}
}
Compile and run the app:
dmcs app.cs -reference:lib.dll
./app.exe
We don't need no header crap
Now how do you know you have a "Lib", and it implements "hello", what
rule enforces that?
If this is all it does, you are overlooking the most important point of
header files.
Could you clarify what is the most important part? If you want to use a
library, you would need to read its docs anyway. The interface files
won't be of much help (D's ones will, since dmd liberally pours
implementations into them). If the docs are unavailable or outdated, you
can always extract the declarations from the library:
monop -a -r:lib.dll
lib
Version=0.0.0.0
Culture=neutral
PublicKeyToken=null
public class Lib {
public Lib ();
public static void hello ();
}
Creating separate interface files, taking trouble to push them around
along with the library and then feeding them to the compiler are
needlessly redundant steps. Or what am I missing?
Your information about "serious" programming is a bit outdated.
What i mean by "serious" is that, if you "need" a specific language for
some task what you are doing is serious.
Because you are falling back to a less known and probably more complex
tools/languages, it is much harder to replace you.
I am still waiting for the next-gen game engine, next-gen video
decoder/encoder, next-gen ... from those serious languages you mention.
I am not ridiculing anything, aren't these the facts?
The fact is that apps with tight real-time requirements cannot be
developed in C# for obvious reasons, and compilation models are
irrelevant to the fact.
Ok, I am not a C# advocate. I hate it no less than C++ or D. It just
happens that its compilation model is superior.
Re: boost crowd.
2011/11/28 Max Samukha :
> On 11/28/2011 02:29 PM, so wrote:
>>
>> On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha
>> wrote:
>>
How would you write libraries?
>>>
>>> The way they do, for example, in C# - interface definitions are stored
>>> in the library, no need for separate headers.
>>
>> Are we talking about the same thing?
>> Something like
>> http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx?
>>
>> So it does what auto-generated .di files does, and turns it into an
>> abomination, it relies on an IDE feature?
>
> No, it has nothing to do with the IDE. The article describes a visual tool
> for viewing meta-data stored in a .NET binary. You don't have to use it.
>
> Specially for you, die-hard IDE haters, this is how to use the terminal to
> create a mono app and library:
>
> 1. Library:
>
> nano lib.cs
>
> using System;
>
> public class Lib
> {
> public static void hello() { Console.WriteLine("We don't need no header
> crap"); }
> }
>
>
> Compile that into a library, lib.dll:
>
> dmcs lib.cs -target:library
>
> 2. Host:
>
> nano app.cs
>
> class App
> {
> public static void Main()
> {
> Lib.hello();
> }
> }
>
> Compile and run the app:
>
> dmcs app.cs -reference:lib.dll
> ./app.exe
> We don't need no header crap
>
[skipped]
Probably i am mistaken that this post supports D modules
(in a way, showing that header files are crap), but ...
In C# no headers are required, because it includes metadata in dynamic library.
In your example you link code to compiled library without header files.
However, this is not possible in D. Programmer have to compile his
code with library code,
which also should include all private members, which supposed to be hidden.
In attempt to eliminate "header crap" D breaks modularization.
Some comparison of C/C++/C#/D writing libraries.
C: write in separate .c file, declare exported object as opaque
structure/void*. No need to recompile program,
when library implementation changes. Program does not know
anything about private members.
Lib files are no longer required on program compilation. Code can
be separated though many files.
Negative: make changes in min 3 files (program, header, library)
when interface is changed.
C++ : one negative difference comparing with C is that private
members are known, and you need recompilation, when you change
something
related to them.
C#: as example above. No headers. Private members are not known. Just
link program upon compiling to already compiled .dll
No GC issues across libraries/program.
Actually, this is the best modularization support comparing these 4
languages.
D: currently difficulties when generating dynamic libraries in linux.
Also GC issue when calling D code from D
(from http://d-programming- language.org/dll.html). Programmer
should ship library code with program (Walter Bright showed simple
example
with function exporting. And what about a class, its methods and
private members?). Recompile everything when implementation/interface
is changed. No way to put class code in separate files. Wired
"interface file" generation which knows implementation better than its
author.
In conclusion, I find D module support the worst one.
Re: is D ncurses-only language?
On Wed, 23 Nov 2011 22:58:00 +0100 Mike Wey wrote: > Yes, I'll probably update GtkD to the latest 2.x release before > looking at GTK+ 3. Have you considered using SWIG to provide GtkD bindings? btw, do you have any influence @dsource forums? I registered 8 days ago and still neither received confirmation email that my account was activated nor I can login. Sincerely, Gour -- When your intelligence has passed out of the dense forest of delusion, you shall become indifferent to all that has been heard and all that is to be heard. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Doom3 (id tech 4) port/binding in D ?
On Sat, 26 Nov 2011 21:04:28 -, Paulo Pinto wrote: Am 25.11.2011 00:33, schrieb Somedude: Le 25/11/2011 00:14, Andrej Mitrovic a écrit : I remember reading this ages ago: http://fabiensanglard.net/quakeSource/index.php Besides there has already been a FPS written in D, and that hasn't had much effect on the gaming community either. The gamming community has actually been moving to Java and C# in what concerns workflow tools and server side code, while leaving the game engine core features in C/C++/Assembly. Not sure if D would still make have an impact there. As you could use D for both aspects I think that would be an advantage in code sharing, and developer training etc. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: float.min, double.min, int.min
Andrea Fontana:
> writeln("int.max: ", int.max);
> writeln("int.min: ", int.min);
> writeln("float.max: ", float.max);
> writeln("float.min: ", float.min);
> }
>
> it prints:
> int.max: 2147483647 <-- no int > int.max
> int.min: -2147483648 <-- no int < int.min
> float.max: 3.40282e+38 <-- no float > float.max
> float.min: 1.17549e-38 <-- this shoud be -float.max (or -inf?). It's
> not a min...
FP.min is deprecated in D, it just causes confusion. Please Kenji Hara make it
available with -d only soon :-)
Bye,
bearophile
Re: float.min, double.min, int.min
D fixed a lot of predecessor's mistakes :)
Il giorno lun, 28/11/2011 alle 16.59 +0200, so ha scritto:
> On Mon, 28 Nov 2011 16:53:11 +0200, Andrea Fontana
> wrote:
>
> > dmd 2.056.
> >
> > void main(string[] args)
> > {
> > writeln("int.max: ", int.max);
> > writeln("int.min: ", int.min);
> > writeln("float.max: ", float.max);
> > writeln("float.min: ", float.min);
> > }
> >
> > it prints:
> > int.max: 2147483647 <-- no int > int.max
> > int.min: -2147483648 <-- no int < int.min
> > float.max: 3.40282e+38 <-- no float > float.max
> > float.min: 1.17549e-38 <-- this shoud be -float.max (or -inf?). It's
> > not a min...
> >
> > assert(-1 < float.min); // passed!
> > This drives me crazy on neural network...
> >
>
> D doing exactly same thing what it's predecessor doing.
> For example, everyone mostly define their own FLOAT_MIN, in C/C++.
Re: struct and default constructor
On Sun, 27 Nov 2011 21:39:05 +0100, Andrej Mitrovic wrote: > That's not a workaround, that ctor never gets called unless you pass an > argument. But it lets you pass a Range test.
Re: wxC & wxD
Gour wrote:
If you were to use SWIG, you would still have the same two libraries ?
Just that files would be: example.d + example_im.d, example_wrap.cxx
(as generated by SWIG from your example.i source file and the headers)
whereas they are currently called: wx/Example.d and wxc/example.cpp
OK; but do you consider it would be better not to depend on wx.NET?
At this point in time it doesn't matter, the generated files are
different even if the scripts to generate them are somewhat similar.
The API is also different, from the different languages used and
from this recent push to rename things to be more like rest of .NET.
So it's not really dependent on wx.NET now, even if the wx-c-gen.pl
script and a few other translation details were reused and adapted ?
Other bindings, for instance for SDL and for OpenGL, were generated
by similar perl scripts operating on the original C/C++ header files.
The classes already grow an annoying filename addition to their name
anyway, unless you add all the classes to the main wx.d file directly.
So it probably doesn't matter if wxApp is called "deity.wx_.app.App",
as long as you have a top module to import and some reasonable
aliases.
Right. My main concern is just whether it is more feasible to provide
wxD directly using SWIG'S D capability.
Easiest way to tell is to start wrapping a couple of classes, to see ?
%module object
%{
#include "include/wx/object.h"
%}
%include "interface/wx/object.h"
And then use `swig -d -d2 -c++ -outcurrentdir wx/object.i` to generate.
Probably need some kind of namespace workaround to create the modules
as "wx.object" rather than just "object" or to convert the "wxObject".
Eventually it should use and copy/fix the interface, but.
Here's a more complete example of what it would look like in the end:
http://svn.wxwidgets.org/svn/wx/wxPython/trunk/src/
http://wxruby.rubyforge.org/svn/trunk/wxruby/swig/classes/
Even using SWIG, there's a whole lot of code that needs to be written.
When you do the SWIG interface files, you should not use the includes
directly since those have a *lot* of platform/implementation details:
I believe that those things should be taken care of by e.g. cmake.
Linking is a whole other issue, this was "just" for determining the
interface files for SWIG (the .i). Probably by combining both wx/*.h ?
Instead it's better to use the Doxygen interfaces as the basis for .i
Those should focus more on the actual wx API you want to export to D:
Yes. WxPython will also use info from Doxygen.
I think it would be needed to translate it to DDoc for it to be allowed,
but wxD also makes use of Doxygen as can be seen from the API reference.
So, is wxD going to continue like now, or do you envision some change
how to proceed for wx-2.9/3.=?
I don't plan to do anything with it, I put it up on github so that it
could be forked and maintained if there are any bugfixes etc needed...
Both wxWidgets and Code::Blocks are Open Source, so if you want to
continue to base the GUI and IDE for the D programming language on
those there's plenty of things that could be improved for either...
The same goes for GCC (and LDC), of course. Maybe even for DMD too.
The wxWidgets roadmap says "We hope to make 3.0 in the spring of 2012."
But as mentioned earlier, using 2.9 should be just fine before that ?
It's perfectly doable to continue to use the current wxd.sourceforge.net
even with wx 3.0 and D 2.0, so I think I will just leave that up as-is.
Ditto for the GDC binaries there, that probably need updating both for
64-bit and for D 2 as well as for newer versions of GCC and of the OS.
When starting up the "wxD2" or "$deity" - or whatever the new project
would be named, it could probably do more changes than just use SWIG ?
--anders
Re: float.min, double.min, int.min
On Mon, 28 Nov 2011 16:53:11 +0200, Andrea Fontana
wrote:
dmd 2.056.
void main(string[] args)
{
writeln("int.max: ", int.max);
writeln("int.min: ", int.min);
writeln("float.max: ", float.max);
writeln("float.min: ", float.min);
}
it prints:
int.max: 2147483647 <-- no int > int.max
int.min: -2147483648 <-- no int < int.min
float.max: 3.40282e+38 <-- no float > float.max
float.min: 1.17549e-38 <-- this shoud be -float.max (or -inf?). It's
not a min...
assert(-1 < float.min); // passed!
This drives me crazy on neural network...
D doing exactly same thing what it's predecessor doing.
For example, everyone mostly define their own FLOAT_MIN, in C/C++.
float.min, double.min, int.min
dmd 2.056.
void main(string[] args)
{
writeln("int.max: ", int.max);
writeln("int.min: ", int.min);
writeln("float.max: ", float.max);
writeln("float.min: ", float.min);
}
it prints:
int.max: 2147483647 <-- no int > int.max
int.min: -2147483648 <-- no int < int.min
float.max: 3.40282e+38 <-- no float > float.max
float.min: 1.17549e-38 <-- this shoud be -float.max (or -inf?). It's
not a min...
assert(-1 < float.min); // passed!
This drives me crazy on neural network...
Re: Phobos Wish List/Next in Review Queue?
On Mon, 28 Nov 2011 15:32:23 +0200, Steven Schveighoffer wrote: Yes, but let's not call this a "range", since it does not work in functions that use ranges or with foreach (this is Walter's goal). How bout strange? (Yes, i am bored)
Try Expression
Instead of having to write if(is(typeof(exp))), how about if(try(exp)) ?
Re: SQL/database server capabilities NO ODBC please
On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote: > On 2011-11-27 07:13, Steve Teale wrote: >> You may detest ODBC, but it is very soon going to be the only way to >> communicate with SQL Server short of writing another wire protocol >> effort. There was the alternative of OLE DB, but MS is dumping that. > > FreeTDS can be used directly. True. I was thinking Windows at the time (very unusual). Steve
Re: boost crowd.
On Mon, 28 Nov 2011 15:52:51 +0200, so wrote: Now how do you know you have a "Lib", and it implements "hello", what rule enforces that? If this is all it does, you are overlooking the most important point of header files. It was obscure. A header enforces its contents for both library writer and library user. If library writer needs a change in header. Both writer and the user needs to change their code. For the second part if library writer changes anything with "implementation", that would not affect the user. In your case it does, because there is no distinction between specification and implementation, every implementation is the new spec.
Re: A real Forum for D
On Mon, 28 Nov 2011 14:37:38 +0100 Somedude wrote: > The main drawback of newsgroups is the absence of a search feature. > Apart from that, I like it. It's the drawback of your *newsreader* and not of the newsgroups itself. I use Claws-mail and have powerful search features included. Sincerely, Gour -- One who is able to withdraw his senses from sense objects, as the tortoise draws its limbs within the shell, is firmly fixed in perfect consciousness. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: boost crowd.
On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha wrote:
No, it has nothing to do with the IDE. The article describes a visual
tool for viewing meta-data stored in a .NET binary. You don't have to
use it.
Specially for you, die-hard IDE haters, this is how to use the terminal
to create a mono app and library:
I started to use vim/cmake "after" years of using IDEs, and one of the
best if not the best VisualStudio.
1. Library:
nano lib.cs
using System;
public class Lib
{
public static void hello() { Console.WriteLine("We don't need no
header crap"); }
}
Compile that into a library, lib.dll:
dmcs lib.cs -target:library
2. Host:
nano app.cs
class App
{
public static void Main()
{
Lib.hello();
}
}
Compile and run the app:
dmcs app.cs -reference:lib.dll
./app.exe
We don't need no header crap
Now how do you know you have a "Lib", and it implements "hello", what rule
enforces that?
If this is all it does, you are overlooking the most important point of
header files.
Your information about "serious" programming is a bit outdated.
What i mean by "serious" is that, if you "need" a specific language for
some task what you are doing is serious.
Because you are falling back to a less known and probably more complex
tools/languages, it is much harder to replace you.
I am still waiting for the next-gen game engine, next-gen video
decoder/encoder, next-gen ... from those serious languages you mention.
I am not ridiculing anything, aren't these the facts?
Re: Concurrency.
> >>>Not having default sharing is about providing guaranties, it's about >>>making thread-safety checkable by the compiler. > > No piece of code can absolutely guarantee threading errors. When you start Threading errors and thread-safety checks are different things... It is pretty much possible to do thread-safety checks perhaps not all, but compiler tries what it can do to "shout" back at developer when an error is made. :)
Re: boost crowd.
2011/11/28 Marco Leise :
> Am 28.11.2011, 11:02 Uhr, schrieb Jude <10equa...@gmail.com>:
>
>>> I tried to write a lib and a project, which used that lib
>>> separately, but came to conclusion that the best choice it to pull
>>> lib code to project one. And it is not a biggest problem, because
>>> dmd produces 700 kb executable for hello word program.
>>
>> what..?
>>
>> I don't know how you are managing to get 700kb for hello world...
>> mine clocks in a 283.7kb with dmd with no optmizations, and holy crap
>> 1.6MB for same file with gdmd.
>>
>> WTF is going on there I wonder...?
>
> *drum roll*
>
> 148,2 kB (dmd 2.054, Linux)
>
> *tadaa*
>
> - 8< - - - - - - - - - - - - - - - - - - -
> import std.stdio;
>
> void main() {
> writeln("Hello, world!");
> }
> - 8< - - - - - - - - - - - - - - - - - - -
>
--
import std.stdio;
class dummy
{
this() { writeln("ctor");}
~this() { writeln("dtor"); }
}
void main()
{
auto dm = new dummy();
}
---
dmd main.d -o
377,9 kb
It is not 700 as i told, but yesterday i upgraded to 2.056. But
definitely i saw that it produces 700 kb elf for a small program.
Anyway, is 400 kb for dummy program too much?
Re: A real Forum for D
Le 27/11/2011 20:31, Gour a écrit : > On Sun, 27 Nov 2011 18:25:20 + (UTC) > alex wrote: > >> That's it. To be more beginner-friendly. Not to be that unnecessarily >> complicated and opaque. > > What is not beginner-friendly in this group? > > My mailer allows reading news, I selected digitalmars server, was > offered list of groups, subscribed to the desire ones and that's it. > > Forum will just divide not-too-big community and with dozen of forums > it's so difficult to know what to follow etc. > > Here I can quickly skip over non-interesting threads, quickly mark the > whole tread as read, mark thread as (un)ignore, (un)watch etc. > > However, if you make newsgroup <--> forum gateway, then I don't care for > those wanting to read forums, but I'd say that the problem is not in > 'uncomfortable and obviously outdated newsgroup software', but > 'uncomfortable and obviously incapable newsgroup reader software'. ;) > > > Sincerely, > Gour > > > The main drawback of newsgroups is the absence of a search feature. Apart from that, I like it.
Re: A real Forum for D
On 2011-11-28 11:55, Walter Bright wrote: On 11/27/2011 11:55 PM, Jacob Carlborg wrote: Then that's just bad design. If the forum is designed correctly there won't be any problem. Here's a typical example: http://www.cuda-challenger.com/cc/index.php?topic=72850.0 Check out all of the vertical space consumed by a 2 word message. No threading view that I can find. There's a "Mark Unread" button, but that applies to the entire thread, not individual messages. Here's another: http://www.gamedev.net/topic/615737-concave-polygon-to-convex-polygons/page__pid__4887554#entry4887554 Same problems. http://community.seattletimes.nwsource.com/reader_feedback/public/display.php?source_id=2016875109&source_name=mbase Note the teeny tiny amount of the screen that is for message text. http://science.slashdot.org/story/11/11/28/0050228/muslim-medical-students-boycott-darwin-lectures At least it's got a real threaded view. But no way to tell what you've read, so if you come back to an active topic after an hour or two, it's a real pain trying to figure out what you've read and what you haven't. I rarely bother to load a topic more than once because of this. Same goes for reddit. I know that most of the forums look like this. But what says that they have to? I'm just trying to say that a forum doesn't have to look like these examples. You also complained how the forum sites doesn't work on a small screen. Have a look at this site: http://upperdog.se/ I know this site is not a forum but the content flows really nice when you resize the browser window to a smaller size and it works great on mobile devices. I don't see any reason why these techniques can't be implemented on a forum. -- /Jacob Carlborg
Re: boost crowd.
On 11/28/2011 02:29 PM, so wrote:
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha wrote:
How would you write libraries?
The way they do, for example, in C# - interface definitions are stored
in the library, no need for separate headers.
Are we talking about the same thing?
Something like
http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx?
So it does what auto-generated .di files does, and turns it into an
abomination, it relies on an IDE feature?
No, it has nothing to do with the IDE. The article describes a visual
tool for viewing meta-data stored in a .NET binary. You don't have to
use it.
Specially for you, die-hard IDE haters, this is how to use the terminal
to create a mono app and library:
1. Library:
nano lib.cs
using System;
public class Lib
{
public static void hello() { Console.WriteLine("We don't need no
header crap"); }
}
Compile that into a library, lib.dll:
dmcs lib.cs -target:library
2. Host:
nano app.cs
class App
{
public static void Main()
{
Lib.hello();
}
}
Compile and run the app:
dmcs app.cs -reference:lib.dll
./app.exe
We don't need no header crap
.
Amazing, so now "programmer" means VisualStudio user? Probably this is
why everyone using only C/C++ for serious library development.
Your information about "serious" programming is a bit outdated.
(Please don't take it personal, this is my usual tone)
No problem.
