wxC & wxD (was Re: moving wxd to github)
On Mon, 28 Nov 2011 02:11:24 +0100 Andrej Mitrovic wrote: > It has a dependency on the Display class, and it seems wxd is compiled > with this class but you can't use it because it depends on > wxc\display.cpp, which has a whole section idfef'd out (via #if > wxUSE_DISPLAY). So naturally there's linker errors. I haven't build wxD yet, but just curious...you say that the sample depends on wxc\display.cpp, but I thought that wxc stuff belonged to wx.NET port, while the wxD site says: "Newer wxD version (0.10) has been updated to wxWidgets 2.6.4 and linkable with wxWidgets 2.8.4 as well, and is now based directly on the original wx classes since the previously used wx.NET was not being maintained anymore." Please advise? Edit: Now I see that wxC is/was project meant to provide basis for wxEiffel (& wxHaskell) bindings...but seeing it's not really maintained it seems to be dead end. My proposition is research about the possibility to do wxD straight from the SWIG and its D support since present approaches does not, I'm afraid, promise bright future. Morever, I believe there are not so many wxD-2.8.x applications written and it's reasonable to start working on 2.9/3.0 not caring much about older releases. Sincerely, Gour -- A person who is not disturbed by the incessant flow of desires — that enter like rivers into the ocean, which is ever being filled but is always still — can alone achieve peace, and not the man who strives to satisfy such desires. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: boost crowd.
WB> How is it not true?
J> dmd -H [file] -c generates the header file for you quite nicely.
ok. Let's a see:
C++ code.
Specification:
// test.hpp file
#ifndef _test_hpp_
#define _test_hpp_
void foo();
struct Boo
{
public:
void boo();
private:
struct S {};
};
#endif
Implementation:
// file test.cpp
#include "test.hpp"
struct HelperStruct {}; // private struct for this module only
static void foo_helper() {HelperStruct s;}
void foo() { foo_helper(); }
void Boo::boo() { S ss; foo_helper(); } // method implementation in
implementation side, not in specification!
Module usage:
// file main.cpp
#include "test.hpp"
int main() {
foo(); // ok
Boo b; // ok
b.boo();// ok
Boo::S ss; // error: struct Boo::S is private
HelperStruct s; // error: HelperStruct was not declared in this scope
return 0;
}
Now, let's try this on D:
// Implementation
module test;
public {
void foo() {foo_helper();}
struct Boo
{
public:
void boo() {S ss; foo_helper();}
private:
struct S {};
}
}
private {
struct HelperStruct {};
void foo_helper() {HelperStruct s;}
}
// Specification (generated by dmd -H test.d -c) -- test.di file
// D import file generated from 'test.d'
module test;
public
{
void foo() {foo_helper();}
struct Boo
{
public
{
void boo() {S ss; foo_helper();}
private struct S{}
}
}
}
private
{
struct HelperStruct{}
void foo_helper(){HelperStruct s;}
}
Usage:
import test;
void main() {
foo(); // ok
Boo b; // ok
b.boo();// ok
Boo.S ss; // ok (wtf?)
HelperStruct s; // ok (wtf?!)
}
First of all I can't see difference between D's implementation and
generated specification. It looks like copy&paste. At second private
section not protect types from usage from other modules. Also I can't
write method implementation in different (implementation) file
(without inheritance).
Also there are no compiler check for test.di & test.d conformance.
In D I expect real module system like in Modula or Ada. Or at least as
in C++ (or way to emulate it). But...
PS. DMD32 D Compiler v2.056
Re: A real Forum for D
On Mon, 28 Nov 2011 09:11:35 +0200, Jude <10equa...@gmail.com> wrote: I must apologize, the rant is over. Walter.respect--; Woah, dude. Where did Walter say that his personal opinion on forum software has anything to do with what gets used/linked from d-p-l.org etc.? I'm not even sure what you're arguing about - are you trying to disprove a subjective opinion? I, for one, respect his opinion regarding threaded views as much as yours, and value such feedback highly. It's very insightful when you're writing something that tries to make both camps happy. I think you've mistaken genuine frustration for arrogance. Imagine being used to a user interface idiom which you perceive as vastly more productive, and then have most of the world use a dumbed-down alternative due to the common denominator / established conventions (which, btw, I think is the cause here - apathy rather than ignorance). -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Concurrency.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 01:05 AM, Debdatta wrote: > Jude, > > Yes, it is similar, but not exactly the same. The difference is in > the way tasks are managed. There is no global task queue, and each > thread has its own. Each thread operates on its own task queue, and > each task can recursively add tasks to the owning thread's head. > The head exclusively belongs to the thread, hence no locking is > required. When a thread is out of tasks, it steals a task from the > tail of another queue in a round robin fashion. In this case, > locking is required. :D It has substantially lower overhead than > global task pools. > > This allows us to efficiently map recursive algorithms with non > uniform work loads to the task queuing scheme. > > But that's not important to the current discussion, as the language > mechanisms that allow us to implement the current task pool can > also be used for task stealing based approaches. > > What I would like to know, is how does the no default sharing idiom > apply to that? I have seen the examples already, and its not > particularly clear to me how this could be done without explicitly > adding and managing @shared tags. > Debdatta, Nice response, very informative. Now I'm intrigued. - -Jude -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0zXzAAoJENcHIWLyQiSlIjgH/jcRcxoikWeKp80ab6iNROua d8ByGCe+kOJIUmx0zToqEbaJAQ+D8+1W6uAUPp9Hu+946LYtDDs+eh5jdVcUBcCj blRGUFfR1gstzVDjJlYocDc2AjKSbo4mlti+XEGCTPb2rWm0ykDEcobpKf2LJx5A G5gbB1fRKtFcYUOeWapZc94bYlqOege+KH0DaQ90Li7wzu7SGlcACaQ3VW7D8AyM zKJBpODJw7qy5WKQLVsCH5pQbfwfQ1J1JV8tY91+cpnjrv+A713EsGaM3P0QfQxa fFVHE/eVlrhtHKUxgVrQ5nW3GEATs/SB40jOM+JmZWcA8b6QSHgiVyurpslSl30= =Ic1l -END PGP SIGNATURE-
Re: A real Forum for D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 12:12 AM, Walter Bright wrote: > > 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. That's nice. You're just forgetting the fact that oh, you know, there are a lot of people who just don't care about "proper" threading. > > >> 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. I for one am glad they "DON'T GET IT." I can't stand threaded view. Tried it, too much work for so little gain. What I don't get is why you are soo vocal about such a tiny, little thing. Check the thread with your threaded views. No one has suggested that we need to REPLACE the current newsgroup. No one has suggested anything more than "hey, maybe we should try to cater to a larger audience, instead of just those who agree that a NG is the best way to communicate ever." I've noticed that you haven't made an appearance on irc in a while. It doesn't have threaded views either, but I don't think that you would doubt it's usefulness. People like it, and I for one really appreciate it's existence. It has helped me out quite a bit, and I definitely would not have learned as much as I know(very little btw) about d if it didn't exist. - From my point of view, we have a few people who think that it would be nice to have another method of communication, and people who would like to restrict other peoples choice based on nothing more than an antiquated black and white view of the world. I have yet to see a 'valid' reason against having a forum. If you don't want to have an official forum, that is fine. If you refuse to allow it on d-p-l, that's fine too. If you won't use it, that's fine. If you don't think that it would gain enough attraction to be worthwhile, great. Say so. If you think that it would split the community too much, speak your mind. Those are all valid reasons to disagree. "Forums are lame and just "DON'T GET IT" and I don't like them and EVERYONE must agree that my method is superior and use my preferred method" is NOT a valid reason. Most people don't care about your holy wars. I'm done with this topic, it just makes me lose faith in humanity. I must apologize, the rant is over. Walter.respect--; Jude out. PS - forget the giant wall of text. Brad says it much nicer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0zQnAAoJENcHIWLyQiSlGGAIAJhzRM91g+s//Krw8fCkeR8q 0AwozwIn7G9+PI7oVSIUHuCdj0bVMj8pccpQad5QKumzRj1YgMnnLKtRB8X7XO33 tZOWCnp0vin1HPNC09IJj/BAh/DjhAtgr+AcncB7D3DOXvJaH8QnoUvC7rLhe0hc 6mTY8Hb9WXEEuAF6wAy5CtrMDuSmkktkDBF5zDr68fAyh4WONDfpsZ0maA0rtSK+ nFp+Pblbv7h4ay42Z7MBG3sx5lQBrY2jiWxPK9CHUtSUDQdp2qZNH1F2rfgwnf0D C0vaHcplhK/ae/hvlX8FrN1Bcm19mKzkLO3ePd1MKk8EN4Q0eEqx9De1lJAbSwI= =HvPD -END PGP SIGNATURE-
Re: Concurrency.
Jude, Yes, it is similar, but not exactly the same. The difference is in the way tasks are managed. There is no global task queue, and each thread has its own. Each thread operates on its own task queue, and each task can recursively add tasks to the owning thread's head. The head exclusively belongs to the thread, hence no locking is required. When a thread is out of tasks, it steals a task from the tail of another queue in a round robin fashion. In this case, locking is required. :D It has substantially lower overhead than global task pools. This allows us to efficiently map recursive algorithms with non uniform work loads to the task queuing scheme. But that's not important to the current discussion, as the language mechanisms that allow us to implement the current task pool can also be used for task stealing based approaches. What I would like to know, is how does the no default sharing idiom apply to that? I have seen the examples already, and its not particularly clear to me how this could be done without explicitly adding and managing @shared tags. - Debdatta
Re: A real Forum for D
On 11/27/2011 10:24 PM, Adam D. Ruppe wrote: > Walter Bright Wrote: >> They just don't get what a threaded view is. > > It's not a difficult concept. Maybe there's some web forum > authors who don't get it, but I'm sure a lot of them do. > > And they probably also know why it is a godawful misfeature, > which is why they didn't implement it. > > > Sometimes, people are well aware of a concept, and reject > it on technical grounds or other issues of merit. It really doesn't > help any discussion when you assume the other side are just > a bunch of idiots who obviously haven't seen the light. That goes both ways. I too greatly prefer threaded views. I use it exclusively when reading all my mail, which also fully (short of buggy mail senders) maintains the 'proper' threading. Clearly this is a matter of personal choice and not something that's clearly right or clearly wrong. Pretending it is just perpetuates the argument. Not allowing the user to choose their preferred navigation / reading / browsing style necessarily restricts the audience to the set of people that prefer the tool author's preferred style. Later, Brad
Re: Concurrency.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/27/2011 11:51 PM, Debdata wrote:
> Hi,
>
> I have been evaluating D for the past week, and have some concerns
> regarding the No Default sharing rule. I have been reading the D
> book by Andrei as well. This particular feature has been very
> confusing to me as I come from the c++ world.
>
> I agree that message passing and resource hiding are a great way to
> go for a lot of cases, but there are an equally large (Larger?)
> number of cases that would benefit from global sharing. Especially
> when threading for performance rather than convenience. The cutting
> edge of high performance threading is really the task stealing
> approach. See intel's TBB, cilk, etc. Implementing things like that
> would become unnecessarily verbose as most things will be shared
> and we have to keep tagging.
>
> Unless I am missing something. :D
>
> -Debdatta Basu
Just wanted to make sure you know, there is a keyword to force global
storage: __gshared
Also D has std.parallelism, which seems to implement what you are
talking about... Would this not be considered [the same as|close
enough to] task stealing?
wikipedia seems to think so...
TBB is a collection of components for parallel programming:
Basic algorithms: parallel_for, parallel_reduce, parallel_scan
void main() {
// Parallel reduce can be combined with std.algorithm.map to
interesting
// effect. The following example (thanks to Russel Winder) calculates
// pi by quadrature using std.algorithm.map and TaskPool.reduce.
// getTerm is evaluated in parallel as needed by TaskPool.reduce.
//
// Timings on an Athlon 64 X2 dual core machine:
//
// TaskPool.reduce: 12.170 s
// std.algorithm.reduce: 24.065 s
immutable n = 1_000_000_000;
immutable delta = 1.0 / n;
real getTerm(int i) {
immutable x = ( i - 0.5 ) * delta;
return delta / ( 1.0 + x * x );
}
immutable pi = 4.0 * taskPool.reduce!"a + b"(
std.algorithm.map!getTerm(iota(n)));
}
But I must admit that I really don't have much experience in this
regard and am more interested in hearing your responses. =P
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO0yqrAAoJENcHIWLyQiSljswIAOQUG/jxDD6XjplV8vhhxkWQ
plxpAVZWv1Oi9TBpK6QB9PMP9qka+BGAPMmEFyoKv4EozcJHxYda3gfqZm+jKdEb
j2rcE/5ZSWvgcr2NcPiwhYIraYGGb4TqzhhHcN8mbebze3/Lnjf1tWpT9X9QEDLG
eSe/wNMagYHTYAzv1Q1ubbYzawyeyNPclPDDbEEdTVUsJhl02QxKFUxJTX0M2N6a
mHhd6DxOf9Pss9iZfjmegLe3Sz5/xxhZfwrYEisTirvRpElNOvzc2JttznFa7wEe
wVgUVQ844IHvcg06ecY8XFVbIbPUJMia5J6JGofcr4JmLbEDcXBydH33ffa4rAI=
=APH6
-END PGP SIGNATURE-
Re: A real Forum for D
Walter Bright Wrote: > They just don't get what a threaded view is. It's not a difficult concept. Maybe there's some web forum authors who don't get it, but I'm sure a lot of them do. And they probably also know why it is a godawful misfeature, which is why they didn't implement it. Sometimes, people are well aware of a concept, and reject it on technical grounds or other issues of merit. It really doesn't help any discussion when you assume the other side are just a bunch of idiots who obviously haven't seen the light.
Re: A real Forum for D
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.
Concurrency.
Hi, I have been evaluating D for the past week, and have some concerns regarding the No Default sharing rule. I have been reading the D book by Andrei as well. This particular feature has been very confusing to me as I come from the c++ world. I agree that message passing and resource hiding are a great way to go for a lot of cases, but there are an equally large (Larger?) number of cases that would benefit from global sharing. Especially when threading for performance rather than convenience. The cutting edge of high performance threading is really the task stealing approach. See intel's TBB, cilk, etc. Implementing things like that would become unnecessarily verbose as most things will be shared and we have to keep tagging. Unless I am missing something. :D -Debdatta Basu
Re: Announcement list for breaking language changes?
On Sun, 27 Nov 2011 14:15:28 +0100, Xinok wrote: On 11/27/2011 7:01 AM, Dejan Lekic wrote: D ChangeLog gives all such information, I believe. They are, but they're mixed with other changes and bug fixes. You have to read each item in the changelog to find the breaking changes. Listing them separately would help greatly when updating code. And they are not focused on what needs to be changed in your code. But on a second thought it would be difficult to synchronize mails with pull requests. Richer changelog entries could be of a help, submitted with the pull requests.
Re: boost crowd.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 06:44 PM, Alexey Veselovsky wrote: > I'm trying to switch from C++ to D. But I can't find some things > that I love in C++. For example in C++ I can separate module > specification and implementation. Advertising article "The Case for > D" says that it is real in D too: > > "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... dmd -H [file] -c generates the header file for you quite nicely. no offense, I think you need a little help.. if you are on linux, man dmd is your friend. tells you all of the options and what they do. if you are not on linux, get on linux. (or use dmd --help... but mainly get linux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0ur5AAoJENcHIWLyQiSljU4IAOpT+UzenxvZwh5VGItoGJRV XGea9f0hZkgOUe9+5ajnEOybDa83//e/WEABfjKPfHMea+I1lLySzLlUEbMAbuiD 6kELOEEc+cBAwLTdAb7h/Hmfj2jhfMimWZFeOD5bLBq9ZqMXSw7zOs7PPHc9iXXl CHSvdYTL5Xlvs5e/ELTrF7Dh/gj6pdjHWvBXaPbKbeWWklzzU+SLM/VCwRR2L7EK qz6p5knCxQbASECt6zrB2hWrMMHzhNpEZ2R7tZHxTRPN3YAKwcJxzBxAWdF+T/qq cNSM0dMzmuUfJMjIADdiekjx681AQ8REQpzU7NW08MXSKhavyyTCcVYVsl+qb5Y= =VF74 -END PGP SIGNATURE-
Re: Structs on private section.
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.
Re: boost crowd.
On 11/27/2011 9:53 AM, so wrote: Even Herb Sutter broke his silence and mentioned D here and there, Herb is a very nice (and very smart) guy, and when I've heard him talk about D he's been very complimentary about our efforts.
Re: boost crowd.
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?
Re: A real Forum for D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 04:14 PM, Timon Gehr wrote: > On 11/27/2011 10:18 PM, Bane wrote: >> Walter Bright Wrote: >> >>> On 11/27/2011 11:08 AM, Bane wrote: And with registred usernames there would be less/no trolls ? >>> >>> Required registration is a barrier for people who want to be >>> onetime posters. (And onetime posters often become regular >>> posters!) >> >> Yeah, I hate that too. Then anonymous access and >> FunnyCaptchas(tm) might work? > > How do you create a captcha that reliably discriminates between > trolls and non-trolls? have something similar to /.'s anonymous coward. with a hide anonymous preference in the settings. Voila. easy to post, you wanna ignore them you can. Or have one specific forum for anonymous. A q-and-a type deal. There are probably a hundred ways around this. One specific forum I was a member of had a rank system based on number of posts and time since joined. anonymous and newbies get one or two small spots to post, and can still see the rest. Shrugs. It's not NG vs. forum here guys... Both have their benefits, so we should have the best of both worlds. //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, 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. 3. click the nice little subscribe to thread button and it tells you if anyone else submits something. These are all things that forums have had for a while... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0uZxAAoJENcHIWLyQiSl5PUIAM7yy4DG4WDTnxRER5zTKL0L EoB8saJJacyIByuXmZRkLF56MMHIKhaLdmq/YfVGoe4M7GYeRZRqqPrYI6ny/7UH Yt6Tm/qE75avgwuq2kDsaMf5bmfAmRk5206q6v8VxIXRMG7uZpuI+feGHcHQyoWH DZccH9H3Ig1UMU3CywxbdKxYlqmlJyZpdG67nBvif9hXr9lbviVqCbmq4C9FxnDc xc/ZrB4s/x574TZBSDVJDriwU6YyC6wc0tAvSBSyQMVZhXyenf9+FoXC5LgSeJaI MS61W1IoeobrIGLoPTsxZw2444zjUFJiX0O1fhC2p5/8ZkWoBQlIkFyeki5SXdc= =rFfd -END PGP SIGNATURE-
Re: Structs on private section.
>>
>>
>>
>>
>>
> 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;}
Re: Structs on private section.
On 11/27/2011 03:57 PM, Alexey Veselovsky wrote:
Hi!
It seems like structs in private section (module or class) remains public:
class A {
private:
struct B {int b;}
}
void foo() {A.B b; b.b=10;}
this code compiles ok.
WTF?
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
Ali
Re: moving wxd to github
FWIW I've got the StyledText sample fixed for D2 (it wasn't compiling for D1 either). It has a dependency on the Display class, and it seems wxd is compiled with this class but you can't use it because it depends on wxc\display.cpp, which has a whole section idfef'd out (via #if wxUSE_DISPLAY). So naturally there's linker errors. I tried but I couldn't compile the wxc\display.cpp file when I defined wxUSE_DISPLAY, I kept getting weird DMC errors. Anywho the sample only used it for priting so I just disabled that functionality.
Re: boost crowd.
I'm trying to switch from C++ to D. But I can't find some things that I love in C++. For example in C++ I can separate module specification and implementation. Advertising article "The Case for D" says that it is real in D too: "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...
Re: boost crowd.
On 11/27/11 10:32 AM, so wrote: Whenever i see articles like http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep wondering why they are so silent in this newsgroup, I am sure they keep an eye on D. I would expect some kind of contribution (as in suggestions, proposes...). They are the top C++ developers, pushing language's capabilities. So, if someone is annoyed by the limits of C++, that would be them. Forget everything, i was thinking that the generic capabilities of D alone is enough to attract all the boost crowd. Phew, had to get it out. The dynamics and psychology at play are, IMHO, a fair amount more complex. I'm saying this as one who has lived such. Mastering a difficult language (and probably skill in general) is to some extent like acquiring some power or money - it puts the subject in a conservative position where she'd try to expand the use of the language for tasks not playing into the language's strength, as opposed to achieving the tasks by escaping the language. That explains e.g. why people are willing to use C++'s preprocessor for tasks that would be trivial for m4 or even bash, or that people try all sorts of systems-level coding in languages not adequate for that. I've had a sort of awakening during my first year in grad school. A professor was teaching constraint logic programming (CLP) and I noted to him that many CLP constructs could be expressed in C++ templates quite nicely. (That prediction was correct, see http://www.mpprogramming.com/cpp.) He (knowing my past) suggested kindly that I'd do good to think more broadly instead of trying to emulate everything I come across in C++. And right he was. Many C++ programmers have heard about D, but it would be naive to think they'd just stop looking solutions to problems in C++, just because those problems have a good solution in D. Andrei
Structs on private section.
Hi!
It seems like structs in private section (module or class) remains public:
class A {
private:
struct B {int b;}
}
void foo() {A.B b; b.b=10;}
this code compiles ok.
WTF?
Re: A real Forum for D
On 11/27/2011 1:05 PM, Russel Winder wrote: So if you want to get any traction at all in this debate only propose an integrated forum/email system any other choice leads to #fail. Yup. A decent web interface to NNTP is just the ticket.
Re: A real Forum for D
Walter Bright Wrote: > On 11/27/2011 2:14 PM, Timon Gehr wrote: > > How do you create a captcha that reliably discriminates between trolls and > > non-trolls? > > You can't. > > But a nice feature would be the addition of a button that only moderators can > see & use, that would simply delete the corresponding posting. Moderators can > be > identified using the same scheme as ssh uses. Yeah, that's the idea, just to make deleting garbage more efficient.
Re: A real Forum for D
On 11/27/2011 12:34 PM, Jimmy Cao wrote: Why are online bulletin boards/forums attractive? * The entire interface is designed for message board communication. You can navigate easily as the interface organizes conversations into pages. For example, you can just click on a link and you will find all the that you yourself started. * The interface allows you to permalink individual posts and share them. * The capability to edit posts. This is extremely useful and a major advantage. * Sticky posts - Posts that are very important and should be locked at the top so that they are easily accessible. * Profiles - you can visit a person's profile to learn more about him. This person can set his own avatar, his contact details, and even his website. * Convenient and fully-featured searching - you can do a search even if you are a new member of the forum. A good web interface or search engine on a NG allows this, but not with the same capabilities. * Post count (friendly competition and statistics) * Better hierarchy of forums - you have forums and subforums. * Private messaging. Sure, you can do this via email, but with a forum, you have your own private message inbox for better organization and access. * Easier moderation - I would imagine that admins can delete or move posts much easier on a forum. * Sometimes the interface will tell you if someone is online or not. You can also see the amount of people who are viewing a subforum or a thread. * Extensive formatting options - colors, graphic smilies, quotes, code highlighting with GeSHi, etc. By the way, a while back I submitted an updated D syntax highlighting guide to GeSHi, so eventually Wikipedia and Wikibooks might highlight D2 fully, too. 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 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.
Re: A real Forum for D
On 11/27/2011 2:14 PM, Timon Gehr wrote: How do you create a captcha that reliably discriminates between trolls and non-trolls? You can't. But a nice feature would be the addition of a button that only moderators can see & use, that would simply delete the corresponding posting. Moderators can be identified using the same scheme as ssh uses.
Re: A real Forum for D
On 11/27/2011 10:18 PM, Bane wrote: Walter Bright Wrote: On 11/27/2011 11:08 AM, Bane wrote: And with registred usernames there would be less/no trolls ? Required registration is a barrier for people who want to be onetime posters. (And onetime posters often become regular posters!) Yeah, I hate that too. Then anonymous access and FunnyCaptchas(tm) might work? How do you create a captcha that reliably discriminates between trolls and non-trolls?
Re: struct and default constructor
Le 27/11/2011 22:24, Simen Kjærås a écrit :
On Sun, 27 Nov 2011 21:19:38 +0100, deadalnix wrote:
In addition, here is a workaround :
// Wonderfull !
@disable this();
// Default constructor workaround.
this(int dummy = 0) { ... }
But that look very dirty and it feels like working against the language.
I believe your "workaround" will disappoint you, as it simply does not run.
import std.stdio;
struct A {
int value;
@disable this();
this(int dummy = 0) {
value = 3;
writeln("Hello from struct default constructor!"); // Never happens.
}
}
void main() {
A a = A();
writeln( a.value ); // Writes 0
}
More importantly, this shows a bug in DMD - namely that structs with
@disabled default constructors can be created without a call to any
constructor and with no error message. In fact, if one removes the
constructor with dummy arguments, the program still compiles.
http://d.puremagic.com/issues/show_bug.cgi?id=7021
So that is even worse that what I though. This struct situation is very
messy and inconsistent. We should definie what we want for that and have
a descent spec.
I just found something new : if you disable this(this), then opAssign
should be allowed (it is allowed, according to the website, when
implicit cast doesn't exists). The copy don't work with opAssign and
disabled postblit . . .
Re: Early std.crypto
On 11/27/2011 12:15 PM, Piotr Szturmaj wrote: Jude Young wrote: On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote: On 11/26/2011 04:19 PM, Brad Anderson wrote: How about putting a disclaimer on the module warning the code hasn't been through a rigorous security audit and point them at well established C libraries if they need that sort of assurance. What does that gain over implementing the first itteration in terms of well established C libraries and then replacing that with native implementations as the code goes been through a rigorous security audit? Or how about do both as API compatible implementations? That would work for people who need the proven security and people who can't afford external dependencies as well as allow them to be swapped out for each other with minimal effort once the native code is proven. I do like this idea. swap implementations by simply swapping import and linking? nice. This was my goal... to write native implementation along with OpenSSL wrapper and add 'useOpenSSL' version identifier. Would that satisfy everyone? Yes, though I'd prefer to see them distinct and non-mutually exclusive. For one things, someone may well consider the native implementation of one primitive vetted before they consider another to be. Both results could be had by the suitable application of aliases.
Re: struct and default constructor
On Sun, 27 Nov 2011 21:19:38 +0100, deadalnix wrote:
In addition, here is a workaround :
// Wonderfull !
@disable this();
// Default constructor workaround.
this(int dummy = 0) { ... }
But that look very dirty and it feels like working against the language.
I believe your "workaround" will disappoint you, as it simply does not run.
import std.stdio;
struct A {
int value;
@disable this();
this(int dummy = 0) {
value = 3;
writeln("Hello from struct default constructor!"); // Never
happens.
}
}
void main() {
A a = A();
writeln( a.value ); // Writes 0
}
More importantly, this shows a bug in DMD - namely that structs with
@disabled default constructors can be created without a call to any
constructor and with no error message. In fact, if one removes the
constructor with dummy arguments, the program still compiles.
http://d.puremagic.com/issues/show_bug.cgi?id=7021
Re: Early std.crypto
On 11/27/2011 12:14 PM, Brad Anderson wrote: That's even better but isn't the issue over bundling incompatibly licensed libraries with phobos? Nothing is stopping someone from writing bindings for these libraries as some random library on D Source or Github already. If we can't find something with a licence allowing bundling then we just include the D language bits (including bindings) and note that along with where to get the lib. An agreed upon API would be very nice in any case. That is necessary (or at least very desirable) in any case as it would allow swapping one cipher for another just as easily as it would allow swapping one implementation for another.
Re: A real Forum for D
On Sun, 2011-11-27 at 15:12 -0600, Jude wrote: > Your a little late with your predictions.. So I have now discovered. My excuse is that trying to do anything related to the Internet on the end of a 2G TCP/IP connection leads to discontinuities of flow. I.e. I had written and send my answer before I knew about the (somewhat predictable) response. The work on a NG bride to browser usage looks interesting for the forum-oriented folk though. But being an email oriented person... -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A real Forum for D
Walter Bright Wrote: > On 11/27/2011 11:08 AM, Bane wrote: > > And with registred usernames there would be less/no trolls ? > > Required registration is a barrier for people who want to be onetime posters. > (And onetime posters often become regular posters!) Yeah, I hate that too. Then anonymous access and FunnyCaptchas(tm) might work?
Re: A real Forum for D
so Wrote: > On Sun, 27 Nov 2011 21:08:46 +0200, Bane > wrote: > > > And with registred usernames there would be less/no trolls ? > > Quite the contrary. After you introduce read/write web interfaces based on > popular frameworks, > you open doors to new kind of trolls and worse... spams. Since this is a > programmer related area, it might be worse. But funny captchas can fix it! And it will be fun :) > > Mind you, we have "zero" moderation yet we have "almost" no spam, no troll. I don't know specifics. Maybe it is the risk worth taking if benefits are that more people will read this.
Re: A real Forum for D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Your a little late with your predictions.. On 11/27/2011 03:05 PM, Russel Winder wrote: > On Sun, 2011-11-27 at 17:41 +, alex wrote: >> Hi folks, >> >> I just wondered why there still is this uncomfortable and >> obviously outdated newsgroup software in use. > > What is outdated about with a mail list based system? > >> Perhaps it'd be more contemporary to have a 'real' browser-based >> forum to which everyone can register and post D-related >> questions&answers. > > Why is a browser-based system better -- as opposed to just being > trendy? > >> 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. > > There will be warfare if this thread continues for mor that about > 0.6 ms. > > It seems every community has to have this mail vs forum debate > every three years or so, and it is completely futile. There are > people who like and can use forums and there are people who abhor > them because they are anathema. The onlt sane system is to have a > synthesis of the two: forum interface for those who like forums > and a mail list for those who only work with email based systems. > Any other choice is a discrimination against personal choice of > workflow. > > I am in the mail list camp. I will not use forums as it means > stuff does not appear in my email system. > > Communities that choose non-email based forums loose a lot of high > quality input. Systems that are purely email based fail to > attract a lot of high quality input. Communities that use an > integrated system win since UI is personal choice. > > So if you want to get any traction at all in this debate only > propose an integrated forum/email system any other choice leads to > #fail. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0qe6AAoJENcHIWLyQiSlGscIAO6UDAkE+A+JA4BNVZ34EsDS 4+ur1UgJCEnCV19m+vLSmFpPGayy4FCPwaDwNF/L65P2PD89HFfQ83jv3klV4WAt 5IbUYPtcGual6UNpWG+R5vaxWpT76jx+AXdESvIr7GiaHf33aFAXCdc2h4o9CMfb 2wJQrmtG0jgogG/WUrEfvQkbaDgKxYt+SthAldkLdw3W7YigPqhjBpN4QrMRM5ke AYCzk9uY1cI+azMySir0AZCFYBqxJHe7Y4AZeomhPdNVrUvRGthyKHI9uNdSLn1I X+wvKucfDxT7Ve0VoZmiEh8QGN2lDe06OiMXtP/Bhh7N+dz+XBBaLOMoa/UCj78= =qFsz -END PGP SIGNATURE-
Re: A real Forum for D
On Sun, 2011-11-27 at 13:01 -0500, Nick Sabalausky wrote: [...] > > phpBB is crap. Actually, anything PHP is crap. [...] Isn't that demeaning to crap which has the ability to fertilize things and allow new life to spring forth. Unlike PHP which leads to websites that are always open to hacking? ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A real Forum for D
On Sun, 2011-11-27 at 17:41 +, alex wrote: > Hi folks, > > I just wondered why there still is this uncomfortable and obviously outdated > newsgroup software in use. What is outdated about with a mail list based system? > Perhaps it'd be more contemporary to have a 'real' browser-based forum to > which everyone can register and post D-related questions&answers. Why is a browser-based system better -- as opposed to just being trendy? > 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. There will be warfare if this thread continues for mor that about 0.6 ms. It seems every community has to have this mail vs forum debate every three years or so, and it is completely futile. There are people who like and can use forums and there are people who abhor them because they are anathema. The onlt sane system is to have a synthesis of the two: forum interface for those who like forums and a mail list for those who only work with email based systems. Any other choice is a discrimination against personal choice of workflow. I am in the mail list camp. I will not use forums as it means stuff does not appear in my email system. Communities that choose non-email based forums loose a lot of high quality input. Systems that are purely email based fail to attract a lot of high quality input. Communities that use an integrated system win since UI is personal choice. So if you want to get any traction at all in this debate only propose an integrated forum/email system any other choice leads to #fail. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: struct and default constructor
Le 27/11/2011 21:39, Andrej Mitrovic a écrit : That's not a workaround, that ctor never gets called unless you pass an argument. So if you @disable this(); you shouldn't get an error. Actually, you have an implicit constructor, even if it's only to set the variable as equal to .init property of the struct.
Re: A real Forum for D
But on mobile devices (such as smartphone) the mainstream is not web-apps via browser. Mainstream is small usable native apps for each services. For example: newsreader :-)
Re: struct and default constructor
Wait nevermind, I thought you mean't the ctor *actually runs*. What you meant was disable this() doesn't work with that ctor in place. On 11/27/11, Andrej Mitrovic wrote: > That's not a workaround, that ctor never gets called unless you pass > an argument. >
Re: struct and default constructor
That's not a workaround, that ctor never gets called unless you pass an argument.
Re: A real Forum for D
2011/11/27 Nick Sabalausky > "alex" wrote in message > news:jatsnd$f71$1...@digitalmars.com... > > Hi folks, > > > > I just wondered why there still is this uncomfortable and obviously > > outdated newsgroup software in use. > > > > old != outdated > > NGs are better. > > Seriously, what's with people's "old == outdated" bullshit these days? What > is this, the goddamn fashion industry? Certainly feels like it half the > time. > > > 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 > > > > phpBB is crap. Actually, anything PHP is crap. > > > > > 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. > > People are working on a better web interface for the NG. But bear in mind, > *any* web interface is going to be inherently inferior to a real NG client > simply due to *being* a web interface. > > > Everything is moving to the cloud and to the web. Many people, including me, only use the web interface for webmail providers like Gmail now. To me, Thunderbird and Outlook are less desirable now that there's a web interface that you can access with all the computers that you use every day. Now, your "all-in-one" browser can replace all those scattered background processes. Why are online bulletin boards/forums attractive? - The entire interface is designed for message board communication. You can navigate easily as the interface organizes conversations into pages. For example, you can just click on a link and you will find all the that you yourself started. - The interface allows you to permalink individual posts and share them. - The capability to edit posts. This is extremely useful and a major advantage. - Sticky posts - Posts that are very important and should be locked at the top so that they are easily accessible. - Profiles - you can visit a person's profile to learn more about him. This person can set his own avatar, his contact details, and even his website. - Convenient and fully-featured searching - you can do a search even if you are a new member of the forum. A good web interface or search engine on a NG allows this, but not with the same capabilities. - Post count (friendly competition and statistics) - Better hierarchy of forums - you have forums and subforums. - Private messaging. Sure, you can do this via email, but with a forum, you have your own private message inbox for better organization and access. - Easier moderation - I would imagine that admins can delete or move posts much easier on a forum. - Sometimes the interface will tell you if someone is online or not. You can also see the amount of people who are viewing a subforum or a thread. - Extensive formatting options - colors, graphic smilies, quotes, code highlighting with GeSHi, etc. By the way, a while back I submitted an updated D syntax highlighting guide to GeSHi, so eventually Wikipedia and Wikibooks might highlight D2 fully, too.
Re: A real Forum for D
Vladimir Panteleev wrote: On Sun, 27 Nov 2011 19:41:01 +0200, alex wrote: 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. I am working on a new web interface. In its default view, it looks a bit like a forum. It's not yet finished, but you can preview it here: http://dfeed.kimsufi.thecybershadow.net/discussion/ I intend to finish it within the coming week. You may want to save your comments until then. This is the best web ng interface I have seen so far. Keep up good work! :)
Re: A real Forum for D
On 11/27/2011 11:08 AM, Bane wrote: And with registred usernames there would be less/no trolls ? Required registration is a barrier for people who want to be onetime posters. (And onetime posters often become regular posters!)
Re: Phobos Wish List/Next in Review Queue?
Manu wrote: On 26 November 2011 23:39, Walter Bright mailto:newshou...@digitalmars.com>> wrote: On 11/26/2011 5:46 AM, Steven Schveighoffer wrote: Ranges are not good for reading N bytes from a file descriptor. Why not? Isn't that exactly what a range is supposed to be good for? It sounds like a bad idea to me... I can imagine ending up with a whole pile of allocations of short ranges, and then people doing bunches of range concatenations to re-assemble the buffer. That's a lot of pointless allocation and memcopying. D's apis should discourage inefficient usage like that. I think ranges are here to avoid memcopying and pointless allocations.
Re: Compile-time Interfaces
Le 27/11/2011 21:14, Andrei Alexandrescu a écrit : What I meant to say was that since we need restricted templates anyway and compile-time interfaces would be a redundant addition to the language, we may as well question their usefulness. I do think that this is not helping the language itself, that's a point. But this would help IDE or any other thrid party tool. This also open the door to more understandable error message when it comes to template.
Re: Early std.crypto
Jude Young wrote: On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote: On 11/26/2011 04:19 PM, Brad Anderson wrote: How about putting a disclaimer on the module warning the code hasn't been through a rigorous security audit and point them at well established C libraries if they need that sort of assurance. What does that gain over implementing the first itteration in terms of well established C libraries and then replacing that with native implementations as the code goes been through a rigorous security audit? Or how about do both as API compatible implementations? That would work for people who need the proven security and people who can't afford external dependencies as well as allow them to be swapped out for each other with minimal effort once the native code is proven. I do like this idea. swap implementations by simply swapping import and linking? nice. This was my goal... to write native implementation along with OpenSSL wrapper and add 'useOpenSSL' version identifier. Would that satisfy everyone?
Re: struct and default constructor
In addition, here is a workaround :
// Wonderfull !
@disable this();
// Default constructor workaround.
this(int dummy = 0) { ... }
But that look very dirty and it feels like working against the language.
Re: Compile-time Interfaces
On 11/27/11 12:36 PM, "Jérôme M. Berger" wrote: 1. Right now we have "function applies to any type R that is a range". With the other approach, there'd be "function applies to any type T such that the given type R is a Range!T". That roundabout approach is likely to scale poorly to more complex cases. It's arguably inferior because often the range-ness is of interest, not naming T. Debatable, what kind of useful function can be built operating on the above interface without reference to T (at least through auto)? It is simpler syntactically and semantically to say "function works for any range R" and then optionally use ElementType!R, than to compulsively express both in one shot. 2. Restrictions can be any Boolean expression, whereas interfaces only apply to types. Strawman! Nothing says that adding compile-time interfaces would remove boolean restrictions. What I meant to say was that since we need restricted templates anyway and compile-time interfaces would be a redundant addition to the language, we may as well question their usefulness. 3. In an interface-based approach, everything must be named; there are no optional properties such as hasLength or isInfinite. That could, of course, be added as restricted templates, which means interfaces must coexist with restricted templates, a more powerful feature. So in the end interfaces are redundant. Strawman again! This is not helping the exchange. Everything can be done in straight assembly so in the end so-called higher-level constructs are redundant. This reduction of a reasonable argument doesn't, either. It should come down to a question of balance between individual feature simplicity, power, and overall language complexity. Adding a feature that is simpler and easier to use despite being less powerful may be a good thing (e.g. "foreach" vs. "while") although it increases the overall language complexity (additional keywords and concepts to understand and remember). Of course. But compile-time interfaces would need to stand on their own. We can't add such just because foreach makes things easier than while. Instead of ridiculing my arguments or engaging in fruitless comparisons, you may as well come with valid arguments in favor of compile-time interfaces. Thanks, Andrei
Re: Early std.crypto
On Sun, Nov 27, 2011 at 9:27 AM, bcs wrote: > On 11/26/2011 04:19 PM, Brad Anderson wrote: > >> >> How about putting a disclaimer on the module warning the code hasn't >> been through a rigorous security audit and point them at well >> established C libraries if they need that sort of assurance. >> > > What does that gain over implementing the first itteration in terms of > well established C libraries and then replacing that with native > implementations as the code goes been through a rigorous security audit? > > Or how about do both as API compatible implementations? That would work > for people who need the proven security and people who can't afford > external dependencies as well as allow them to be swapped out for each > other with minimal effort once the native code is proven. > That's even better but isn't the issue over bundling incompatibly licensed libraries with phobos? Nothing is stopping someone from writing bindings for these libraries as some random library on D Source or Github already. An agreed upon API would be very nice in any case.
Re: moving wxd to github
Ah right, sizers. I forgot to set a sizer for the tab. Now it works: http://codepad.org/Kc5TxXjU Thanks!
struct and default constructor
Hi, I wonder why struct can't have a default constructor. TDPL state that it is required to allow every types to have a constant .init . That is true, however not suffiscient. A struct can has a void[constant] as a member and this doesn't have a .init . So this limitation does not ensure that the benefit claimed is garanteed. Additionnaly, if it is the only benefit, this is pretty thin compared to the drawback of not having a default constructor. We already have @disable this(); for structs. This cause the struct to behave differently and cause the error « initializer required for type xxx » when a variable of type xxx is defined without initialization. This doesn't prevent the struct to get a constant .init and to use it (even if this .init is probably garbage in this case, the whole point of the @disable is to force the user to use a constructor or to copy). The whole stuff seems very unclear and limitations arbitrary. Note that a static opCall and a @disabel default constructor doesn't do the trick as opCall can't be used with new to allocate on the heap. This is only a cheap workaround. Note also that xxx myvar = xxx.init; worls and doesn't trigger postblit. So the @disable this(); is also a structure thatd oesn't garantee anything. The point of classes and struct beeing different in D is slicing. Default constructor is unrelated to that problem. Why not allow both @disable this(); and default constructor construct, both triggering the error « initializer required for type xxx » ? This would make much more sense. Postblit should also be triggered on assiagnation with .init to ensure the consistency of the whole construct.
Re: A real Forum for D
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 senses are so strong and impetuous, O Arjuna, that they forcibly carry away the mind even of a man of discrimination who is endeavoring to control them. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: A real Forum for D
Actually, I find a newsgroup far superior to a mailing list for this purpose. Reading and Archiving integrated in the same system and accessible with the same client. Far less total traffic, since only those contributions need to be transmitted that are actually read. It is a pity that newsgroups are used so rarely! On 27.11.2011 18: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.
Re: A real Forum for D
On Sun, 27 Nov 2011 17:41:01 + (UTC) alex wrote: > Hi folks, > > I just wondered why there still is this uncomfortable and obviously > outdated newsgroup software in use. -1 What is outdated in using mailer, getting nice threaded discussuion, easy searching of archives, automatic archives... Forums require launching browsers, login, almost impossible to find something etc. > 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. Use more capable mailer/newsreader... /me uses claws-mail -- 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
On Sun, 27 Nov 2011 21:08:46 +0200, Bane wrote: And with registred usernames there would be less/no trolls ? Quite the contrary. After you introduce read/write web interfaces based on popular frameworks, you open doors to new kind of trolls and worse... spams. Since this is a programmer related area, it might be worse. Mind you, we have "zero" moderation yet we have "almost" no spam, no troll.
Re: A real Forum for D
> It's not really a matter of "either/or" imo... > I think that everyone will admit that having an 'official' forum would > probably boost popularity. > > A good place to post questions and search the archives EASILY would > definitely be a boon. True. Most people have some experiance with forums, much less of them with newsgroups. It would be user friendly and more "in" (as oposed of old geeks using old software) :) And with registred usernames there would be less/no trolls ?
Re: A real Forum for D
On Sun, 27 Nov 2011 20:29:50 +0200, so wrote: On Sun, 27 Nov 2011 20:19:48 +0200, Vladimir Panteleev wrote: On Sun, 27 Nov 2011 19:41:01 +0200, alex wrote: 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. I am working on a new web interface. In its default view, it looks a bit like a forum. It's not yet finished, but you can preview it here: http://dfeed.kimsufi.thecybershadow.net/discussion/ I intend to finish it within the coming week. You may want to save your comments until then. Great work Vladimir! Just a suggestion. For topics, wouldn't tree view be the best choice for viewing threads? When you open a thread, you would see two frames, like newsgroup readers (pan, opera..) _ | | | Tree| |_| _ | | | Content | |_| Oh, you already have it! "Message goes here"
Re: A real Forum for D
On 11/27/2011 10:19 AM, Vladimir Panteleev wrote: I am working on a new web interface. In its default view, it looks a bit like a forum. It's not yet finished, but you can preview it here: http://dfeed.kimsufi.thecybershadow.net/discussion/ I intend to finish it within the coming week. You may want to save your comments until then. I think it is a vast improvement over the previous one. I like how it uses the gravatar pictures.
Re: Compile-time Interfaces
Andrei Alexandrescu wrote:
> On 11/27/11 5:36 AM, Jacob Carlborg wrote:
>> "auto" cannot be used here. Just like it can't be used in any place
>> where there is no implementation of a function.
>>
>> Seems to me it needs to look something like this:
>>
>> enum interface Range (T)
>> {
>> void popFront();
>> @property bool empty() const;
>> @property T front();
>> }
>
> That seems helpful, but it doesn't lead on a good path, for several
> reasons.
>
> 1. Right now we have "function applies to any type R that is a range".
> With the other approach, there'd be "function applies to any type T such
> that the given type R is a Range!T". That roundabout approach is likely
> to scale poorly to more complex cases. It's arguably inferior because
> often the range-ness is of interest, not naming T.
>
Debatable, what kind of useful function can be built operating on
the above interface without reference to T (at least through auto)?
> 2. Restrictions can be any Boolean expression, whereas interfaces only
> apply to types.
>
Strawman! Nothing says that adding compile-time interfaces would
remove boolean restrictions.
> 3. In an interface-based approach, everything must be named; there are
> no optional properties such as hasLength or isInfinite. That could, of
> course, be added as restricted templates, which means interfaces must
> coexist with restricted templates, a more powerful feature. So in the
> end interfaces are redundant.
>
Strawman again! Everything can be done in straight assembly so in
the end so-called higher-level constructs are redundant.
It should come down to a question of balance between individual
feature simplicity, power, and overall language complexity. Adding a
feature that is simpler and easier to use despite being less
powerful may be a good thing (e.g. "foreach" vs. "while") although
it increases the overall language complexity (additional keywords
and concepts to understand and remember).
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: A real Forum for D
On Sun 27 Nov 2011 12:25:20 PM CST, alex wrote: >> post questions and search the archives EASILY > > That's it. To be more beginner-friendly. Not to be that unnecessarily > complicated and opaque. > If you make a forum, I would join. I like the NG. and let's face it, it's generally the people that make the community. D has a nice community. but damn if they don't like their "holy wars." =P (http://en.wikipedia.org/wiki/Holy_war#See_also)
Re: A real Forum for D
On Sun, 27 Nov 2011 20:19:48 +0200, Vladimir Panteleev wrote: On Sun, 27 Nov 2011 19:41:01 +0200, alex wrote: 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. I am working on a new web interface. In its default view, it looks a bit like a forum. It's not yet finished, but you can preview it here: http://dfeed.kimsufi.thecybershadow.net/discussion/ I intend to finish it within the coming week. You may want to save your comments until then. Great work Vladimir! Just a suggestion. For topics, wouldn't tree view be the best choice for viewing threads? When you open a thread, you would see two frames, like newsgroup readers (pan, opera..) _ | | | Tree| |_| _ | | | Content | |_|
Re: A real Forum for D
> post questions and search the archives EASILY That's it. To be more beginner-friendly. Not to be that unnecessarily complicated and opaque.
Re: A real Forum for D
Vladimir Panteleev Wrote: > I am working on a new web interface. In its default view, it looks a bit > like a forum. That's awesome! Curious: using D for it?
Re: A real Forum for D
On Sun, 27 Nov 2011 20:24:04 +0200, Adam D. Ruppe wrote: Vladimir Panteleev Wrote: I am working on a new web interface. In its default view, it looks a bit like a forum. That's awesome! Curious: using D for it? Of course :) https://github.com/CyberShadow/DFeed -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: A real Forum for D
On Sun, 27 Nov 2011 19:41:01 +0200, alex wrote: 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. I am working on a new web interface. In its default view, it looks a bit like a forum. It's not yet finished, but you can preview it here: http://dfeed.kimsufi.thecybershadow.net/discussion/ I intend to finish it within the coming week. You may want to save your comments until then. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: A real Forum for D
"Jude Young" <10equa...@gmail.com> wrote in message news:mailman.1127.1322417735.24802.digitalmar...@puremagic.com... > On Sun 27 Nov 2011 12:01:24 PM CST, Nick Sabalausky wrote: >> "alex" wrote in message >> news:jatsnd$f71$1...@digitalmars.com... >>> Hi folks, >>> >>> I just wondered why there still is this uncomfortable and obviously >>> outdated newsgroup software in use. >>> >> >> old != outdated >> >> NGs are better. >> >> Seriously, what's with people's "old == outdated" bullshit these days? >> What >> is this, the goddamn fashion industry? Certainly feels like it half the >> time. >> >>> 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 >>> >> >> phpBB is crap. Actually, anything PHP is crap. >> >>> >>> 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. >> >> People are working on a better web interface for the NG. But bear in >> mind, >> *any* web interface is going to be inherently inferior to a real NG >> client >> simply due to *being* a web interface. >> >> >> > It's not really a matter of "either/or" imo... > I think that everyone will admit that having an 'official' forum would > probably boost popularity. > > A good place to post questions and search the archives EASILY would > definitely be a boon. > A web forum isn't needed for that, just a better web interface to the existing NG.
Re: A real Forum for D
On Sun 27 Nov 2011 12:01:24 PM CST, Nick Sabalausky wrote: > "alex" wrote in message > news:jatsnd$f71$1...@digitalmars.com... >> Hi folks, >> >> I just wondered why there still is this uncomfortable and obviously >> outdated newsgroup software in use. >> > > old != outdated > > NGs are better. > > Seriously, what's with people's "old == outdated" bullshit these days? What > is this, the goddamn fashion industry? Certainly feels like it half the > time. > >> 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 >> > > phpBB is crap. Actually, anything PHP is crap. > >> >> 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. > > People are working on a better web interface for the NG. But bear in mind, > *any* web interface is going to be inherently inferior to a real NG client > simply due to *being* a web interface. > > > It's not really a matter of "either/or" imo... I think that everyone will admit that having an 'official' forum would probably boost popularity. A good place to post questions and search the archives EASILY would definitely be a boon.
Re: A real Forum for D
On Sun, 27 Nov 2011 20:04:14 +0200, Jude Young <10equa...@gmail.com> wrote: I would definitely be interested in a forum. But only if it has the following: a separate off topic area definite rules about what is and what is not allowed. permabans if it was associated with d-p-l, keep with the colors and general theme (just a preference) support threaded and flat views. and I'd prefer a way to turn off emoticons. Permabans, turn off emotions... Even with the recent trolls, this newsgroup rocks. Again, we should keep the newsgroups, if you want to ban, filter... do it on the web interface. Thanks.
Re: A real Forum for D
nntp is more flexible then "real" web forum.
Re: Early std.crypto
On Sun 27 Nov 2011 10:27:58 AM CST, bcs wrote: > On 11/26/2011 04:19 PM, Brad Anderson wrote: >> >> How about putting a disclaimer on the module warning the code hasn't >> been through a rigorous security audit and point them at well >> established C libraries if they need that sort of assurance. > > What does that gain over implementing the first itteration in terms of > well established C libraries and then replacing that with native > implementations as the code goes been through a rigorous security audit? > > Or how about do both as API compatible implementations? That would > work for people who need the proven security and people who can't > afford external dependencies as well as allow them to be swapped out > for each other with minimal effort once the native code is proven. > I do like this idea. swap implementations by simply swapping import and linking? nice.
Re: A real Forum for D
"alex" wrote in message news:jatsnd$f71$1...@digitalmars.com... > Hi folks, > > I just wondered why there still is this uncomfortable and obviously > outdated newsgroup software in use. > old != outdated NGs are better. Seriously, what's with people's "old == outdated" bullshit these days? What is this, the goddamn fashion industry? Certainly feels like it half the time. > 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 > phpBB is crap. Actually, anything PHP is crap. > > 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. People are working on a better web interface for the NG. But bear in mind, *any* web interface is going to be inherently inferior to a real NG client simply due to *being* a web interface.
Re: A real Forum for D
On Sun, 27 Nov 2011 19:41:01 +0200, 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. I like what we have (newsgroups), probably because i use opera. On the http interface, slow as hell. There are no images, no videos, just a few lines of text, i don't understand why.
Re: A real Forum for D
On Sun 27 Nov 2011 11:41:01 AM CST, 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. > I would definitely be interested in a forum. But only if it has the following: a separate off topic area definite rules about what is and what is not allowed. permabans if it was associated with d-p-l, keep with the colors and general theme (just a preference) support threaded and flat views. and I'd prefer a way to turn off emoticons. just ideas: ideone has support for D(2.042 not too far behind), it'd be great if there was some kind of integration with that (post a code snippet, post the output, if that is possible then it shouldn't be too hard to hide everything outside of main()) http://ideone.com/apiyeah i know, but it you have to admit that it would be awesome.
Re: boost crowd.
On Sun, 27 Nov 2011 19:13:46 +0200, Paulo Pinto wrote: Why switch state of the art C++ compilers with years of optimizations built-in and tooling by D? Tool and compilers come eventually, especially after big players attend in discussions. I don't understand this reasoning really, what everyone expect from language evolution? Are we expecting some big company do this? Without any feedback from programmer community, in their inner circles? We know there are many like that and none of them fulfilling our needs. This is the type of questions I sometimes have to answer, and as much as I would like to have a language like D replace C++, myself I end up using C++ when the need for native code on our applications arise. So do i, but that doesn't mean one should remain silent at the time of big developments to very problems C++ is facing. Even Herb Sutter broke his silence and mentioned D here and there, considering his position on the development of another language/compiler, shouldn't others be more vocal? This is not a fantasy anymore, we have working compilers and a grand community.
A real Forum for D
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.
Re: boost crowd.
Am 27.11.2011 17:32, schrieb so: Whenever i see articles like http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep wondering why they are so silent in this newsgroup, I am sure they keep an eye on D. I would expect some kind of contribution (as in suggestions, proposes...). They are the top C++ developers, pushing language's capabilities. So, if someone is annoyed by the limits of C++, that would be them. Forget everything, i was thinking that the generic capabilities of D alone is enough to attract all the boost crowd. Phew, had to get it out. Why switch state of the art C++ compilers with years of optimizations built-in and tooling by D? This is the type of questions I sometimes have to answer, and as much as I would like to have a language like D replace C++, myself I end up using C++ when the need for native code on our applications arise. -- Paulo
boost crowd.
Whenever i see articles like http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep wondering why they are so silent in this newsgroup, I am sure they keep an eye on D. I would expect some kind of contribution (as in suggestions, proposes...). They are the top C++ developers, pushing language's capabilities. So, if someone is annoyed by the limits of C++, that would be them. Forget everything, i was thinking that the generic capabilities of D alone is enough to attract all the boost crowd. Phew, had to get it out.
Re: Early std.crypto
On 11/26/2011 04:19 PM, Brad Anderson wrote: How about putting a disclaimer on the module warning the code hasn't been through a rigorous security audit and point them at well established C libraries if they need that sort of assurance. What does that gain over implementing the first itteration in terms of well established C libraries and then replacing that with native implementations as the code goes been through a rigorous security audit? Or how about do both as API compatible implementations? That would work for people who need the proven security and people who can't afford external dependencies as well as allow them to be swapped out for each other with minimal effort once the native code is proven.
Re: Compile-time Interfaces
On Sun, 27 Nov 2011 02:40:08 +0200, Kapps wrote:
Which brings in, compile-time interfaces. It seems like a natural thing
to include when you have the above tools. Instead of having a method
such as:
auto DoSomething(T)(T Data) if(isInputRange!(T)) { }
You could simply do:
auto DoSomething(Range Data) { }
where Range is defined as:
enum interface Range {
void popFront() const;
@property bool empty() const;
@property auto front();
}
Much nicer than this very confusing looking statement (taken from
std.range):
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}()));
}
I sort of like the current solution, (it uses the language's most powerful
feature) but for such common use the syntax is ugly.
As it was suggested many times (std.meta), we really need to simplify this
to at least something like:
template isInputRange(R)
{
enum bool isInputRange = compiles
{
R r; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}
}
Re: Compile-time Interfaces
On 11/27/11 10:03 AM, Jacob Carlborg wrote: For the simpler cases an interface is easier to reason about. But yes, template constraints are more powerful. I've reached the same conclusion. Symbolic interfaces explode quite quickly. Fortunately, the experimentation in that direction has been already done in the context of C++ concepts. We designed restricted templates as a simple method to address the same problem that C++ concepts do, and restricted templates have served D exceedingly well. There are ways to address the issue "why did type X not satisfy constraint E on a template?" at both compiler and library level. The compiler could e.g. explain which expressions in a combination of conjunctions and disjunctions has failed. A library could define a catch-all function that issues the appropriate error message (though this is rather laborious). I personally think the compiler-based approach can be very fertile. Andrei
Re: Compile-time Interfaces
On 2011-11-27 16:47, Andrei Alexandrescu wrote:
On 11/27/11 5:36 AM, Jacob Carlborg wrote:
"auto" cannot be used here. Just like it can't be used in any place
where there is no implementation of a function.
Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
That seems helpful, but it doesn't lead on a good path, for several
reasons.
1. Right now we have "function applies to any type R that is a range".
With the other approach, there'd be "function applies to any type T such
that the given type R is a Range!T". That roundabout approach is likely
to scale poorly to more complex cases. It's arguably inferior because
often the range-ness is of interest, not naming T.
I was missinterpreting the isInputRange template.
2. Restrictions can be any Boolean expression, whereas interfaces only
apply to types.
3. In an interface-based approach, everything must be named; there are
no optional properties such as hasLength or isInfinite. That could, of
course, be added as restricted templates, which means interfaces must
coexist with restricted templates, a more powerful feature. So in the
end interfaces are redundant.
For the simpler cases an interface is easier to reason about. But yes,
template constraints are more powerful.
--
/Jacob Carlborg
Re: Compile-time Interfaces
On 2011-11-27 12:56, Timon Gehr wrote:
On 11/27/2011 12:36 PM, Jacob Carlborg wrote:
"auto" cannot be used here. Just like it can't be used in any place
where there is no implementation of a function.
Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
The element type is not a parameter to the range interface. See
'isInputRange'.
Ah, you're right, my bad.
--
/Jacob Carlborg
Re: Compile-time Interfaces
On 11/27/11 5:36 AM, Jacob Carlborg wrote:
"auto" cannot be used here. Just like it can't be used in any place
where there is no implementation of a function.
Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
That seems helpful, but it doesn't lead on a good path, for several reasons.
1. Right now we have "function applies to any type R that is a range".
With the other approach, there'd be "function applies to any type T such
that the given type R is a Range!T". That roundabout approach is likely
to scale poorly to more complex cases. It's arguably inferior because
often the range-ness is of interest, not naming T.
2. Restrictions can be any Boolean expression, whereas interfaces only
apply to types.
3. In an interface-based approach, everything must be named; there are
no optional properties such as hasLength or isInfinite. That could, of
course, be added as restricted templates, which means interfaces must
coexist with restricted templates, a more powerful feature. So in the
end interfaces are redundant.
Andrei
Re: extern(C++) and shared
Le 27/11/2011 01:20, deadalnix a écrit : I have this function : extern(C++) void* __dsfml_start_thread(EntryPoint entryPoint, void* userData); If EntryPoint is defined as follow : alias extern(C++) void* function(void*) EntryPoint; The function mangle in _Z20__dsfml_start_threadPFPvS_ES_ if alias extern(C++) void* function(shared void*) EntryPoint; _Z20__dsfml_start_threadPFPvPvES_ Both demangle using c++filt in __dsfml_start_thread(void* (*)(void*), void*), which is what is expected. But the definition without shared will be the only one to link successfully. Is the mangling of shared types is consistent in C++ ? shared doesn't exists in C++, so I guess we should expect the same mangling in both cases. Unless it exists some magic on the C++ side that I'm not aware of ? According to this document : http://www.scribd.com/doc/57293807/18/Gnu3-name-mangling S_ is used for template parameters, which is not correct here.
Re: Compile-time Interfaces
On 27-11-2011 01:40, Kapps wrote:
One of the great things about D is the ability to do so much work at
compile-time, including static verification. An example is the amount of
constraints available for templates, static ifs, etc. But at some point,
it starts getting very problematic to just figure out what something
does, and what something can do. An example for this, is ranges. They
can be very confusing, and you don't know what they can do without
actually going and looking up the exact definition of them. Even then,
you have to know that the templated type a function expects is a range.
Again, very confusing, and arguably messy. Finally, even now that you
know what methods you can call on this mysterious type T, and you see
that there's a clause isInputRange!(T) on the method, your IDE still has
no clue about any of these things making it impossible to have
semi-decent code completion for that type.
Which brings in, compile-time interfaces. It seems like a natural thing
to include when you have the above tools. Instead of having a method
such as:
auto DoSomething(T)(T Data) if(isInputRange!(T)) { }
You could simply do:
auto DoSomething(Range Data) { }
where Range is defined as:
enum interface Range {
void popFront() const;
@property bool empty() const;
@property auto front();
}
Much nicer than this very confusing looking statement (taken from
std.range):
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}()));
}
And then instead of returning auto, you could return Range if you wanted
to, or OutputRange, etc. This gives much more info by just looking at
the signature of the method, as opposed to comb through the
documentation to find out what this mysterious type is that it returns.
Another useful thing is that new types could now actually have it be
statically verified that they implement this feature:
struct MyRange(T) {
T popFront() const { }
@property bool empty() const { }
@property ref T front() { }
}
When you try to use this in a method that takes in a type T where
isInputRange!(T), you would get a confusing message saying no suitable
overloads found. If you had, this however:
struct MyRange(T) : (static|enum)? Range {
T popFront() const { }
@property bool empty() const { }
@property ref T front() { }
}
You would see a message saying that it can't implement Range because
popFront returns T instead of void. Not only that, but a good IDE will
also offer to implement the Range signatures for you, like Visual Studio
does for C#.
The main issue I can think of is when a method takes in multiple
different types that implement the same static interface. An example:
Range Zip(Range First, Range Second);
Would First/Second be the same type? Does it matter? Should the compiler
handle it? What about the return type?
An alternate way though would just be to (when there are multiple types
of the same interface) force the use of:
Range Zip(R1 : Range, R2 : Range)(R1 First, R2) Second;
An IDE will still know that these are ranges. You still get the
readability of it. You still get all the benefits of the ranges. You
just have to make Zip a template method anyways.
The other issue I can think of is that this could potentially make
someone believe that methods that take in / return a Range aren't
template methods when they actually are. Of course, in order for that to
matter, they have to realize in the first place that a template method
creates multiple instances of the method while caring about the overhead
that creates.
Overall though, I think that this would be a huge benefit to D's compile
time capability (not to mention learning ranges), while incurring no
run-time cost. It also makes it much nicer when your IDE now knows what
the types you're working with are. There are already IDEs that can take
advantage of the above benefits, and only more will come. Plus, it's
much much nicer to just be able to look at the interface rather than
figuring out the documentation for, say, a range (and many editors/ides
will offer a go-to-definition to do this for you). Template types /
figuring out what they are is the messiest thing in D at the moment
(IMO), and this would be a nice way of solving it for many situations.
Thoughts?
I think 'static interface' or 'template interface' or something like
that would make more sense. 'enum interface' just doesn't really make
sense in this context. Other than that, seems like a reasonable idea to me.
- Alex
Re: Compile-time Interfaces
On 27-11-2011 02:32, Caligo wrote: It's almost 2012, and people are still using IDE's? Let's not go there. - Alex
Re: Announcement list for breaking language changes?
On 11/27/2011 7:01 AM, Dejan Lekic wrote: D ChangeLog gives all such information, I believe. They are, but they're mixed with other changes and bug fixes. You have to read each item in the changelog to find the breaking changes. Listing them separately would help greatly when updating code.
Re: extern(C++) and shared
Le 27/11/2011 13:16, Martin Nowak a écrit : On Sun, 27 Nov 2011 01:20:35 +0100, deadalnix wrote: alias extern(C++) void* function(void*) EntryPoint Can you please file a reduced test case as bug stating exactly what in the mangling went wrong. Not sure about the current policy of passing shared data to C++ functions. It seems to work on a promise base, then stripping the qualifiers. martin module fail; extern(C++) void foo1(void*); extern(C++) void bar1(shared void*); pragma(msg, foo1.mangleof); pragma(msg, bar1.mangleof); // shared is ignored here, because C++ doesn't have shared, this make sense. extern(C++) void foo2(void function(void*)); extern(C++) void bar2(void function(shared void*)); pragma(msg, foo2.mangleof); pragma(msg, bar2.mangleof); // shared is ignored here, because C++ doesn't have shared, this make sense. extern(C++) void foo3(void function(void*), void*); extern(C++) void bar3(void function(shared void*), void*); pragma(msg, foo3.mangleof); pragma(msg, bar3.mangleof); // shared generate a different mangling here. extern(C++) void foo4(void function(void*), shared void*); extern(C++) void bar4(void function(shared void*), shared void*); pragma(msg, foo4.mangleof); // Same mangling as bar3. pragma(msg, bar4.mangleof); // back to correct mangling (the one expected by g++). extern(C++) void foo5(void* function(void*), void*); extern(C++) void bar5(void* function(shared void*), void*); pragma(msg, foo5.mangleof); pragma(msg, bar5.mangleof); // shared generate a different mangling here. extern(C++) void foo6(void* function(void*), shared void*); extern(C++) void bar6(void* function(shared void*), shared void*); pragma(msg, foo6.mangleof); // shared generate a different mangling here. pragma(msg, bar6.mangleof); // function pointer mangled as in bar5, but second parameter get a "0" in the mangling that none of the mangling above had. Give the following output : _Z4foo1Pv _Z4bar1Pv _Z4foo2PFvPvE _Z4bar2PFvPvE _Z4foo3PFvPvES_ _Z4bar3PFvPvEPv _Z4foo4PFvPvEPv _Z4bar4PFvPvES_ _Z4foo5PFPvS_ES_ _Z4bar5PFPvPvES_ _Z4foo6PFPvS_EPv _Z4bar6PFPvPvES0_ Comment describe what is inconsistent (or what require something on C++ side that I'm not aware of). None is generating any warning. GDC and G++ are used here, both in 4.6.2 version (and frontend v2.055, the last supported by GDC) on linux amd64.
Re: extern(C++) and shared
Le 27/11/2011 13:17, Jude Young a écrit :
On Sun 27 Nov 2011 05:54:27 AM CST, deadalnix wrote:
Le 27/11/2011 12:02, Jacob Carlborg a écrit :
On 2011-11-27 01:20, deadalnix wrote:
I have this function :
extern(C++) void* __dsfml_start_thread(EntryPoint entryPoint, void*
userData);
If EntryPoint is defined as follow :
alias extern(C++) void* function(void*) EntryPoint;
The function mangle in _Z20__dsfml_start_threadPFPvS_ES_
if alias extern(C++) void* function(shared void*) EntryPoint;
_Z20__dsfml_start_threadPFPvPvES_
Both demangle using c++filt in __dsfml_start_thread(void* (*)(void*),
void*), which is what is expected.
But the definition without shared will be the only one to link
successfully.
Is the mangling of shared types is consistent in C++ ? shared doesn't
exists in C++, so I guess we should expect the same mangling in both
cases. Unless it exists some magic on the C++ side that I'm not aware
of ?
Have you tried with __gshared instead?
It doesn't compile at all with __gshared. I have the following error :
basic type expected, not __gshared
extern (C++)
{
__gshared type function(blah) blah;
alias foo bar;?
}
that doesn't work?
That does work. But isn't what is failing here.
Re: extern(C++) and shared
On Sun 27 Nov 2011 05:54:27 AM CST, deadalnix wrote:
> Le 27/11/2011 12:02, Jacob Carlborg a écrit :
>> On 2011-11-27 01:20, deadalnix wrote:
>>> I have this function :
>>> extern(C++) void* __dsfml_start_thread(EntryPoint entryPoint, void*
>>> userData);
>>>
>>> If EntryPoint is defined as follow :
>>> alias extern(C++) void* function(void*) EntryPoint;
>>>
>>> The function mangle in _Z20__dsfml_start_threadPFPvS_ES_
>>>
>>> if alias extern(C++) void* function(shared void*) EntryPoint;
>>> _Z20__dsfml_start_threadPFPvPvES_
>>>
>>> Both demangle using c++filt in __dsfml_start_thread(void* (*)(void*),
>>> void*), which is what is expected.
>>>
>>> But the definition without shared will be the only one to link
>>> successfully.
>>>
>>> Is the mangling of shared types is consistent in C++ ? shared doesn't
>>> exists in C++, so I guess we should expect the same mangling in both
>>> cases. Unless it exists some magic on the C++ side that I'm not aware
>>> of ?
>>
>> Have you tried with __gshared instead?
>>
>
> It doesn't compile at all with __gshared. I have the following error :
> basic type expected, not __gshared
>
extern (C++)
{
__gshared type function(blah) blah;
alias foo bar;?
}
that doesn't work?
Re: extern(C++) and shared
On Sun, 27 Nov 2011 01:20:35 +0100, deadalnix wrote: alias extern(C++) void* function(void*) EntryPoint Can you please file a reduced test case as bug stating exactly what in the mangling went wrong. Not sure about the current policy of passing shared data to C++ functions. It seems to work on a promise base, then stripping the qualifiers. martin
Re: Announcement list for breaking language changes?
D ChangeLog gives all such information, I believe.
Re: Compile-time Interfaces
On 11/27/2011 12:36 PM, Jacob Carlborg wrote:
On 2011-11-27 02:03, Andrei Alexandrescu wrote:
On 11/26/11 6:40 PM, Kapps wrote:
One of the great things about D is the ability to do so much work at
compile-time, including static verification. An example is the amount of
constraints available for templates, static ifs, etc. But at some point,
it starts getting very problematic to just figure out what something
does, and what something can do. An example for this, is ranges. They
can be very confusing, and you don't know what they can do without
actually going and looking up the exact definition of them. Even then,
you have to know that the templated type a function expects is a range.
Again, very confusing, and arguably messy. Finally, even now that you
know what methods you can call on this mysterious type T, and you see
that there's a clause isInputRange!(T) on the method, your IDE still has
no clue about any of these things making it impossible to have
semi-decent code completion for that type.
Which brings in, compile-time interfaces. It seems like a natural thing
to include when you have the above tools. Instead of having a method
such as:
auto DoSomething(T)(T Data) if(isInputRange!(T)) { }
You could simply do:
auto DoSomething(Range Data) { }
where Range is defined as:
enum interface Range {
void popFront() const;
@property bool empty() const;
@property auto front();
}
What's "auto" here? This thing alone pretty much destroys the idea;
we've considered it very seriously.
Andrei
"auto" cannot be used here. Just like it can't be used in any place
where there is no implementation of a function.
Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
The element type is not a parameter to the range interface. See
'isInputRange'.
Re: Compile-time Interfaces
On 11/27/2011 12:33 PM, Jacob Carlborg wrote:
On 2011-11-27 02:13, Timon Gehr wrote:
On 11/27/2011 02:03 AM, Andrei Alexandrescu wrote:
On 11/26/11 6:40 PM, Kapps wrote:
One of the great things about D is the ability to do so much work at
compile-time, including static verification. An example is the
amount of
constraints available for templates, static ifs, etc. But at some
point,
it starts getting very problematic to just figure out what something
does, and what something can do. An example for this, is ranges. They
can be very confusing, and you don't know what they can do without
actually going and looking up the exact definition of them. Even then,
you have to know that the templated type a function expects is a range.
Again, very confusing, and arguably messy. Finally, even now that you
know what methods you can call on this mysterious type T, and you see
that there's a clause isInputRange!(T) on the method, your IDE still
has
no clue about any of these things making it impossible to have
semi-decent code completion for that type.
Which brings in, compile-time interfaces. It seems like a natural thing
to include when you have the above tools. Instead of having a method
such as:
auto DoSomething(T)(T Data) if(isInputRange!(T)) { }
You could simply do:
auto DoSomething(Range Data) { }
where Range is defined as:
enum interface Range {
void popFront() const;
@property bool empty() const;
@property auto front();
}
What's "auto" here? This thing alone pretty much destroys the idea;
we've considered it very seriously.
Andrei
I would solve that similar to this:
enum interface Range {
private alias T; // could also use 'static' instead of 'private' :o)
void popFront();
@property bool empty() const;
@property T front();
}
Where "T" does not actually contribute to the imposed interface.
Then what would "T" be?
Any symbol. It is determined by deduction.
Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
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) { /* ... * / }
Re: extern(C++) and shared
Le 27/11/2011 12:02, Jacob Carlborg a écrit : On 2011-11-27 01:20, deadalnix wrote: I have this function : extern(C++) void* __dsfml_start_thread(EntryPoint entryPoint, void* userData); If EntryPoint is defined as follow : alias extern(C++) void* function(void*) EntryPoint; The function mangle in _Z20__dsfml_start_threadPFPvS_ES_ if alias extern(C++) void* function(shared void*) EntryPoint; _Z20__dsfml_start_threadPFPvPvES_ Both demangle using c++filt in __dsfml_start_thread(void* (*)(void*), void*), which is what is expected. But the definition without shared will be the only one to link successfully. Is the mangling of shared types is consistent in C++ ? shared doesn't exists in C++, so I guess we should expect the same mangling in both cases. Unless it exists some magic on the C++ side that I'm not aware of ? Have you tried with __gshared instead? It doesn't compile at all with __gshared. I have the following error : basic type expected, not __gshared
Re: Compile-time Interfaces
On 2011-11-27 02:03, Andrei Alexandrescu wrote:
On 11/26/11 6:40 PM, Kapps wrote:
One of the great things about D is the ability to do so much work at
compile-time, including static verification. An example is the amount of
constraints available for templates, static ifs, etc. But at some point,
it starts getting very problematic to just figure out what something
does, and what something can do. An example for this, is ranges. They
can be very confusing, and you don't know what they can do without
actually going and looking up the exact definition of them. Even then,
you have to know that the templated type a function expects is a range.
Again, very confusing, and arguably messy. Finally, even now that you
know what methods you can call on this mysterious type T, and you see
that there's a clause isInputRange!(T) on the method, your IDE still has
no clue about any of these things making it impossible to have
semi-decent code completion for that type.
Which brings in, compile-time interfaces. It seems like a natural thing
to include when you have the above tools. Instead of having a method
such as:
auto DoSomething(T)(T Data) if(isInputRange!(T)) { }
You could simply do:
auto DoSomething(Range Data) { }
where Range is defined as:
enum interface Range {
void popFront() const;
@property bool empty() const;
@property auto front();
}
What's "auto" here? This thing alone pretty much destroys the idea;
we've considered it very seriously.
Andrei
"auto" cannot be used here. Just like it can't be used in any place
where there is no implementation of a function.
Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
--
/Jacob Carlborg
Re: Compile-time Interfaces
On 2011-11-27 02:13, Timon Gehr wrote:
On 11/27/2011 02:03 AM, Andrei Alexandrescu wrote:
On 11/26/11 6:40 PM, Kapps wrote:
One of the great things about D is the ability to do so much work at
compile-time, including static verification. An example is the amount of
constraints available for templates, static ifs, etc. But at some point,
it starts getting very problematic to just figure out what something
does, and what something can do. An example for this, is ranges. They
can be very confusing, and you don't know what they can do without
actually going and looking up the exact definition of them. Even then,
you have to know that the templated type a function expects is a range.
Again, very confusing, and arguably messy. Finally, even now that you
know what methods you can call on this mysterious type T, and you see
that there's a clause isInputRange!(T) on the method, your IDE still has
no clue about any of these things making it impossible to have
semi-decent code completion for that type.
Which brings in, compile-time interfaces. It seems like a natural thing
to include when you have the above tools. Instead of having a method
such as:
auto DoSomething(T)(T Data) if(isInputRange!(T)) { }
You could simply do:
auto DoSomething(Range Data) { }
where Range is defined as:
enum interface Range {
void popFront() const;
@property bool empty() const;
@property auto front();
}
What's "auto" here? This thing alone pretty much destroys the idea;
we've considered it very seriously.
Andrei
I would solve that similar to this:
enum interface Range {
private alias T; // could also use 'static' instead of 'private' :o)
void popFront();
@property bool empty() const;
@property T front();
}
Where "T" does not actually contribute to the imposed interface.
Then what would "T" be? Seems to me it needs to look something like this:
enum interface Range (T)
{
void popFront();
@property bool empty() const;
@property T front();
}
--
/Jacob Carlborg
Re: SQL/database server capabilities NO ODBC please
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. -- /Jacob Carlborg
