Re: Csmith - C compiler stress test

[Emil Madsen]

On 13 April 2011 17:27, David Nadlinger  wrote:

> On 4/13/11 5:16 PM, Trass3r wrote:
>
>> I think I also came across such a tool but I'm not sure if it was this
>> one.
>> Since it uses a grammar (subset) to generate the programs it should be
>> perfectly possible to adapt it for D.
>> Though it "is mainly intended to find bugs in the parts of a compiler
>> that perform transformations on an intermediate representation".
>>
>
> From what I recall from a quick look at the Csmith sources and Xuejun
> Yang's talk at the LLVM developer meeting, Csmith is tailored rather
> specifically to C, and isn't based on a grammar representation that could be
> easily swapped out…
>
> David
>

*Can Csmith be altered to emit programs in a language other than C or C++?* Not
easily.
http://embed.cs.utah.edu/csmith/using.html

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: http://lang-index.sourceforge.net/

[Emil Madsen]

On 11 April 2011 03:22, Andrei Alexandrescu
wrote:

> I wonder how accurate this language popularity index is.
>
> Andrei
>

I wouldn't belive it;
1
result
on youtube?
- atleast according to the table, but I'm getting 1410, thats 1409 new
youtube movies about C++ in 13days ;)
- I guess C++ is on its way back!

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: image processing in D

[Emil Madsen]

On 7 April 2011 17:55, Eric Poggel (JoeCoder) wrote:

> On 4/3/2011 6:35 PM, Emil Madsen wrote:
>
>> This about image processing, got me thinking, hows the shader support
>> for D currently? - Interfaceable though C?
>> Because for image processing, thats def. the way to go, at least in my
>> opinion, that is if you want acceptable processing speeds.
>>
>> And a more specific question; say one wants to blur a picture
>> with Gaussian blur, how would D ranges deal with the 2d array?
>>
>
> GL Shaders are perfectly usable via Derelict.  I use them in Yage (
> yage3d.net).
>


Thats nice :) - I have to spend some time with it then :D

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Code example on www.d-programming-language.org?

[Emil Madsen]

On 5 April 2011 00:02, bearophile  wrote:

> Andrei:
>
> > Clearly finding a good example with such conflicting requirements is not
> > easy and there's no need to restate that. If it were easy I would've
> > done it. What is needed is an example that successfully finds the sweet
> > spot.
>
> In my opinion what I have explained in my answer is not obvious stuff,
> seeing how many solutions/programmers on Rosettacode fail.
>
> My point was that in my opinion there is no such single example that
> satisfies your requests, and that your requests are bad. If you put too much
> stuff in a single example, the result is not what I will call a good example
> for very public D code. So you have to put only a limited amount of stuff in
> the example, or you have to show more than one example.
>
> If you want a single example, the second on Wikipedia is the one I like:
> http://en.wikipedia.org/wiki/D_language#Example_2
>
> Bye,
> bearophile
>


Honestly I would rather meet a site that has several simple examples
illustrating the capabilities of a language, instead of a single one, thats
messy.

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: image processing in D

[Emil Madsen]

On 3 April 2011 20:33, Andrei Alexandrescu wrote:

> On 4/3/11 7:25 AM, Fawzi Mohamed wrote:
>
>> On 2-apr-11, at 10:40, aman bansal wrote:
>>
>>  i was trying to chalk out a strategy to go for image processing in
>>> D.the closest reference i found was in the implementation of python
>>> imaging library.it  has modules for imaging,and
>>>
>>> input output of jpeg and bmp file formats.the data structures used
>>> also are quite accurate.i would like to ask developers what can be the
>>> possible problems in implementing image i/o in D on the lines of
>>> python imaging library.
>>>
>>
>> As I told you via email
>>
>> there are two main things, one is reading/writing several formats, I
>> would say that you should support at least one standard (simple) format
>> natively (the simplest would be netpbm format) but then you could rely
>> on libraries to support more.
>> Use of external libraries should be discussed with others also, because
>> one should rely only on libraries that are widely available,
>> cross-platform and with acceptable licensing.
>>
>> About the image processing itself you probably want to have a simple
>> flat representation of the image (as 2d array), and then be able to
>> apply several operations on it.
>> General convolution is probably something you want to have, masked
>> operation might also be very useful.
>> Not sure about which other operations you want to support.
>> In D1 as part of blip I have implemented nearest neighbor convolution,
>> it could be useful to you.
>>
>> Not sure which bit depth you want to support, one can build a wrapper to
>> access arbitrary bit depth/bitchannel contiguous block of memory as 1d
>> or 2d array (for example 4channel 12 bit images), this can be useful as
>> base type for operations with images that might have an extended bit
>> range.
>>
>> is this for a GSoC project?
>>
>
> Yes, that is a GSoC project.
>
> Aman, you may want to read the posts I wrote with advice to other students
> before completing your proposal.
>
> A strong proposal would convince us that you (a) understand your domain
> rather well, (b) you understand D's specifics enough to define a good API
> for it, (c) you have studied and absorbed similar endeavors in other
> languages and frameworks, and (e) you have what it takes to complete the
> project.
>
>
> Good luck!
>
> Andrei
>
>
This about image processing, got me thinking, hows the shader support for D
currently? - Interfaceable though C?
Because for image processing, thats def. the way to go, at least in my
opinion, that is if you want acceptable processing speeds.

And a more specific question; say one wants to blur a picture
with Gaussian blur, how would D ranges deal with the 2d array?

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: GSoC-2011 project:: Containers

[Emil Madsen]

On 30 March 2011 10:38, Jonathan M Davis  wrote:

> On 2011-03-30 01:18, Daniel Gibson wrote:
> > Am 30.03.2011 01:55, schrieb Jonathan M Davis:
> > > On 2011-03-29 14:50, dsimcha wrote:
> > >> == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> > >>
> > >>> The fancier stuff would be nice, but we don't even have a
> doubly-linked
> > >>> list yet. We should get the simpler stuff sorted out before we get
> > >>> particularly fancy, not to mention that it's usually the simple stuff
> > >>> that gets heavily used.
> > >>
> > >> For the most part I agree, but a doubly linked list might be **too**
> > >> simple. Linked lists are so trivial to implement that I'd tend to roll
> > >> my own that does exactly what I need with regard additional behavior
> on
> > >> insertion, etc. rather than wrapping a library solution to get these
> > >> features.
> > >
> > > A doubly-linked list is on the list of containers that every standard
> > > library should have or it's likely to be considered lacking. I can
> > > understand rolling your own for specific uses, but _I_ sure don't want
> > > to be doing that if I don't have to. If I want a doubly-linked list, I
> > > want to be able to just create a standard one and use it. C++, C#, and
> > > Java all have doubly-linked lists in their standard libraries.
> > >
> > > If no one else ever implements a doubly-linked list for Phobos, I'll
> > > probably do it eventually simply because it's one of the containers
> that
> > > is on the short list of containers that pretty much every standard
> > > library has.
> > >
> > > - Jonathan M Davis
> >
> > It may be feasible to enhance the single-linked list to support both
> > single- and double linking, via an additional template-parameter "bool
> > doubly" or something like that and some static-ifs in the implementation.
> > I once created a simple single/double-linked queue for D1 like that.
>
> To what end though? I don't think that that would save you much. While some
> of
> the implementation would be the same, so much of it would be different,
> that
> you'd practically have two complete types defined in one template. At that
> point, you might as well create a separate class/struct. It's just simpler
> to
> have them separate, and I don't see any real gain in combining them. Having
> both is great, since there are times that you want one and times when you
> want
> the other, but having both SList and DList (or whatever it would be called)
> as
> separate types makes sense.
>
> - Jonathan M Davis
>


Just a question that popped into my mind, how does D's std.container handle
cyclic lists? using static if?

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Is D more complex than C++?

[Emil Madsen]

On 29 March 2011 11:30, ToNyTeCh  wrote:

> Francisco Almeida wrote:
> > == Quote from ToNyTeCh (t...@nospam.net)'s article
> >
> >> It doesn't matter to me. I was just posting when I wasn't drunk.
> >
> > Good for you. It certainly explains a lot.
>
> fuck you
>
>
> Can we keep the mailing list in a sober tone, please?


-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Pretty please: Named arguments

[Emil Madsen]

On 9 March 2011 13:22, Gareth Charnock  wrote:

> Named arguments are useful when you have a function that takes a large
> number of parameters, the vast majority of which have default values. For
> example, have a look at this constructor in wxWidgets:
>
>
> http://docs.wxwidgets.org/trunk/classwx_frame.html#01b53ac2d4a5e6b0773ecbcf7b5f6af8
>
> wxFrame::wxFrame(   wxWindow *  parent,
> wxWindowID  id,
> const wxString &title,
> const wxPoint & pos = wxDefaultPosition,
> const wxSize &  size = wxDefaultSize,
> longstyle = wxDEFAULT_FRAME_STYLE,
> const wxString &name = wxFrameNameStr
> )
>
> If you want to change the name argument you need to call
>
> new wxFrame(a_parent,wxANY,"Hello
> world",wxDefaultPosition,wxDefaultSize,wxDEFAULT_FRAME_STYLE,"My Custom name
> str")
>
> Which meant I had to look up what the default values of pos,size and style
> where even though I was happy with those default values. The more arguments
> the more of a pain this setup is without named arguments. Contrast to a
> hypothetical C++ syntax:
>
> new wxFrame(a_parent,wxANY,"Hello world",name = "My Custom name str")
>
> I haven't bothered with the arguments I don't care about and my function
> call has ended up less sensitive to changes in the wxFrame constructor.
>
>
> On 28/02/11 21:50, Jonathan M Davis wrote:
>
>> On Monday, February 28, 2011 13:38:34 Don wrote:
>>
>>> spir wrote:
>>>
 On 02/28/2011 07:51 PM, Jonathan M Davis wrote:

> I'm not entirely against named arguments being in D, however I do
> think that any
> functions that actually need them should be refactored anyway.
>

>>> I agree.
>>> CreateFont() in the Windows API, I'm looking at you. (For Linux people,
>>> that function has about 12 parameters).
>>>
>>>  ???

  In actuality, if I were to vote on whether named arguments should be
> in the
> language, I would definitely vote against it (I just plain don't want
> the code
> clutter,  [...]
>

 Just don't use them!

>>>
>>> You don't have that option. At least, if you're a library developer, you
>>> don't. (I'm a bit sick of people saying "you don't have to use it if you
>>> don't want to" in language design. If it is in the language, you don't
>>> have a choice. You will encounter it).
>>>
>>> There are a couple of things that I really, really don't like about the
>>> names argument idea:
>>> 1. It makes parameter names part of the API.
>>> Providing no way for the function writer to control whether it is part
>>> of the API or not, and especially, doing it retrospectively, strikes me
>>> as extremely rude.
>>>
>>> 2. It introduces a different syntax for calling a function.
>>> foo(4, 5);
>>> foo(x: 4, y: 5);
>>> They look different, but they do exactly the same thing. I don't like
>>> that redundancy.
>>>
>>>
>>> Especially since, as far as I can tell, the named arguments are just
>>> comments (which the compiler can check).
>>> If so, a syntax like this would be possible, with no language change at
>>> all:
>>>
>>> pragma(namedarguments); // applies to whole module
>>>
>>> foo(/*x*/ 4, /*y*/ 5);
>>>
>>> --->  if a function parameter has a comment which forms a valid
>>> identifier, it's a named parameter.
>>>
>>> But I still don't see the need for this feature. Aren't people using
>>> IDEs where the function signature (with parameter names) pops up when
>>> you're entering the function, and when you move the mouse over the
>>> function call?
>>> And if you really want to see them all the time, why not build that
>>> feature into the IDE?
>>> ("hit ctrl-f9 to show all parameter names, hit it again to hide them").
>>>
>>
>> I agree with pretty much everything said here. However, as I understand
>> it,
>> named parameters (at least as they work in Python) would allow for you to
>> reorder parameters and give values for paramters which are normally
>> default
>> parameters without giving values for the default paramters before them,
>> and
>> those changes could not be dealt with by comments. However, I consider
>> them to
>> be a big _problem_, not a feature - _especially_ the ability to rearrange
>> the
>> function arguments. All of a sudden you could have
>>
>>
>> foo(4, 5);
>> foo(x : 4, y : 5);
>> foo(y : 5, X : 4);
>>
>> all making _exactly_ the same function call. That seem _very_ bug-prone
>> and
>> confusing to me. foo(x : 4, y : 5) was bad enough, but allowing foo(y : 5,
>> x :
>> 4)? Not good. The amount of effort to understand the code becomes
>> considerably
>> higher. You could be very familiar with foo and know exactly what
>> parameters it
>> takes and totally mistake what it's really getting passed, because the
>> arguments
>> were flipped in comparison to the function parameters.
>>
>> I agree with Don. I think that named parameters would cause far more
>> intellectual overhead and problems than they'd solve.
>>
>> - Jonathan M Davis
>>
>> - Jonathan M Davis
>>
>
>
I actually li

Re: Naming convention in Phobos

[Emil Madsen]

On 6 March 2011 12:38, Jonathan M Davis  wrote:

> On Sunday 06 March 2011 02:59:25 Jim wrote:
> > Okay, so there's a discussion about identifier names in the proposed
> > std.path replacement -- should they be abbreviated or not? Should we
> > perhaps seek to have a consistent naming convention for all identifier
> > names in Phobos?
> >
> >
> > Some of the potential benefits:
> >
> >   Legibility, understandability and clarity (reduce ambiguity).
> >   Ease in finding a suitable function/class by name.
> >   Knowing if it's a cheap or costly function call.
> >   Aesthetics and professional appearance.
> >
> >
> > Some properties that I can think of for discussion:
> >
> >   Abbreviation (and if so, what to abbreviate and how much)?
> >   Preference of commonly used terms in other languages, contexts?
> >   Use of get and set prefixes or not (getName() or simply name())?
> >   Explicit use of a prefix (example: calc or calculate) for costly
> > operations?   Naming of function and template arguments?
> >   Uppercase, lowercase, camelcase, underscore in multi-word names? All
> caps
> > for constants, or different appearance for different types (types,
> > functions, arguments, constants...). What about acronyms: TCP, Tcp?
> >
> > Are there other concerns?
>
> The general naming convention as far as variable names go is camelcased
> with the
> name starting with a lower case letter - this includes constants. Most of
> Phobos
> follows this, and the parts that haven't been have been moving towards it.
> There
> are likely to be a few exceptions, but on the whole, that's how it's
> supposed to
> be. Type names are the same, except they start with an upper case letter
> (this
> includes enum names - the enum values are capitalized the same as any other
> variables however). That's the way it has been, and that's the way that
> it's
> pretty much guaranteed to stay.
>
> Generally speaking, we want descriptive names, and I think that it's safe
> to say
> that we don't want overly long names, so if we can have descriptive but
> short
> names, that's generally best. get and set prefixes are likely to be rare,
> because
> most of such functions will be properties, and properties will normally
> have
> nouns for names and won't use get or set, but I don't think that we want to
> say
> that we'll _never_ have function names prefixed with get or set. Normally,
> we
> won't, but it's going to be very situation-dependent.
>
> Now, as for the rest of it, I don't really want to get into a big
> discussion of
> the best way to name everything. It's far too context-dependent and very
> quickly
> turns towards bike shedding. I think that it's appropriate for anyone who's
> developing a module for Phobos to come up with names that they think are
> reasonable and which follow the very basic naming conventions that we
> follow,
> and then have names adjusted as needed during the review process. I really
> don't
> think that we're going to get much of value by having a big discussion over
> general naming conventions. It seems to me like it's just going to be a
> classic
> situation for bike shedding and generally useless discussion. What we've
> been
> doing generally works just fine.
>
> - Jonathan M Davis
>

Just a thought, is there some sort of tool whats able to check if a code
follow these standards?
And if its the case, why isn't it used? - so people are forced to conform to
the coding standard before being able to commit anything.

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Andrei's "Sealed Containers"

[Emil Madsen]

On 3 December 2010 05:18, Eric Poggel  wrote:

> On 12/2/2010 11:00 PM, Craig Black wrote:
>
>> Still working on some details. Thanks for the interest.
>>>
>>
>> Thanks for the response. I would be interested to know how far you have
>> gotten and what details are holding up progress, if you don't mind
>> sharing.
>>
>> -Craig
>>
>
> What are sealed containers?  I guess we're not talking about tupperware?
>

We are talking tupperware, just in code :) - or sealed nuclear waste
containers, whatever you prefer :)

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: GCC 4.6

[Emil Madsen]

On 25 November 2010 01:15, Iain Buclaw  wrote:

> == Quote from Emil Madsen (sove...@gmail.com)'s article
> > --90e6ba539f3ee121840495d5033f
> > Content-Type: text/plain; charset=ISO-8859-1
> > On 25 November 2010 00:25, Walter Bright 
> wrote:
> > > Emil Madsen wrote:
> > >
> > >> And yea, bearophile brings up a lot of nice features, and Walter would
> > >> never have a chance to implement all of them himself, which might be
> good,
> > >> if everything bearophile suggests got into the language, we would have
> this
> > >> major language noone would ever be able to learn, nor use. However, if
> we
> > >> succeed in implementing the best ideas I do think we'll end up with a
> superb
> > >> output, however I do think we need to discuss a lot of issues and
> features,
> > >> and thats why I love bearophiles postings, simply because it gives the
> > >> community a lot to discuss.
> > >>
> > >> Just my opinion. - But I do think discussing a lot of features, even
> the
> > >> ones not really related, will help out the language in the end.
> > >>
> > >
> > > I think bearophile does a valuable service to us by bringing up
> discussion
> > > topics.
> > >
> > > My gripe is when he lists things that he wishes D did when D already
> does
> > > them and has for years. Case in point: D imports. It's irksome when he
> often
> > > writes from the perspective of assuming that D does it wrong while
> other
> > > languages are assumed to do it right. Case in point: design by
> contract, and
> > > his assumption that dmd was a primitive compiler that did not do data
> flow
> > > analysis while praising llvm's.
> > >
> > > My concern about that is that with the volume of his posts, I will miss
> > > some of them, and people inexperienced with D will presume those
> mistakes
> > > and misunderstandings are correct.
> > >
> > > I have no issue at all with bringing up factual shortcomings of D, even
> > > when I disagree about whether they are actual shortcomings or not. For
> > > example, it is a fact that D does not check for integer arithmetic
> overflow.
> > > Whether that's a problem or not is a fine topic for discussion.
> > >
> > Well I must agree with you, atleast on the part, about how he sometimes
> > seems negative about what dmd does. - And that tune, is obviously not
> nice
> > towards you, as your the one doing the hard work, but lets just try to
> > remember, that bearophile just wants D to be the best, eh?
> > What really is an issue for me currently, is that the mailing list seems
> > like its going a tad into war, that is between you and bearophile
> sometimes;
> > wheres you should instead be joining forces. - As it seems to me, D got
> > about the best compiler writer out there, and one of the best feature
> > requester/discusser :).
> > And I can understand you concerns, about how newcomers to D, might react
> > reading about all of these things bearophile complains about, and wants
> to
> > change/add.
> > - Just curious, how much of your time do you spend on reading this
> mailing
> > list a day?
> > (Excuse my somewhat bad english tonight (its 3am))
>
> He's started peeking an interest at GDC too, which was both amusing and
> heartening
> to see. I don't honestly think any of his comments can really be seen as
> complaints. As has already been echoed, most are very informative, he
> always seems
> to pick up on things you don't commonly think about. Then again, I can see
> it can
> get a bit tiring how he almost always starts off with "Language/Compiler
>  does
> ", then goes on to explain that yours doesn't. This is where I
> see
> myself going terse over things very quickly.
>
> I think you wrongly see things as war-like. It's all really just healthy
> discussion and competition.
>

Sure it can get tiring when hes like saying 'Language/Compiler 
does', but while he does so, he also brings up a discussion
whether its something to add or not. - And I must say, a lot of the features
he points out in other language seem like good things :) - however pointing
it out, and being like; 'Why doesn't D do this?', might not be the right
tune, where it should be; 'Would it be an idea if D did this?', and I can
understand why the first tune might seem a tad hard on people like Walter,
when it already does.

About GDC, I think the dmd community should be watching whats happening at
LDC and GDC, they might come up with something good, before we do, eh?

I might be right about the way thing, its just, sometimes people seem a
little bit hostile if you ask me, but that might just me me thats a tad off.

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: GCC 4.6

[Emil Madsen]

On 25 November 2010 00:25, Walter Bright  wrote:

> Emil Madsen wrote:
>
>> And yea, bearophile brings up a lot of nice features, and Walter would
>> never have a chance to implement all of them himself, which might be good,
>> if everything bearophile suggests got into the language, we would have this
>> major language noone would ever be able to learn, nor use. However, if we
>> succeed in implementing the best ideas I do think we'll end up with a superb
>> output, however I do think we need to discuss a lot of issues and features,
>> and thats why I love bearophiles postings, simply because it gives the
>> community a lot to discuss.
>>
>> Just my opinion. - But I do think discussing a lot of features, even the
>> ones not really related, will help out the language in the end.
>>
>
> I think bearophile does a valuable service to us by bringing up discussion
> topics.
>
> My gripe is when he lists things that he wishes D did when D already does
> them and has for years. Case in point: D imports. It's irksome when he often
> writes from the perspective of assuming that D does it wrong while other
> languages are assumed to do it right. Case in point: design by contract, and
> his assumption that dmd was a primitive compiler that did not do data flow
> analysis while praising llvm's.
>
> My concern about that is that with the volume of his posts, I will miss
> some of them, and people inexperienced with D will presume those mistakes
> and misunderstandings are correct.
>
> I have no issue at all with bringing up factual shortcomings of D, even
> when I disagree about whether they are actual shortcomings or not. For
> example, it is a fact that D does not check for integer arithmetic overflow.
> Whether that's a problem or not is a fine topic for discussion.
>

Well I must agree with you, atleast on the part, about how he sometimes
seems negative about what dmd does. - And that tune, is obviously not nice
towards you, as your the one doing the hard work, but lets just try to
remember, that bearophile just wants D to be the best, eh?

What really is an issue for me currently, is that the mailing list seems
like its going a tad into war, that is between you and bearophile sometimes;
wheres you should instead be joining forces. - As it seems to me, D got
about the best compiler writer out there, and one of the best feature
requester/discusser :).

And I can understand you concerns, about how newcomers to D, might react
reading about all of these things bearophile complains about, and wants to
change/add.

- Just curious, how much of your time do you spend on reading this mailing
list a day?

(Excuse my somewhat bad english tonight (its 3am))

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: shorter foreach syntax - C++0x range-based for

[Emil Madsen]

On 1 November 2010 16:14, Andrei Alexandrescu  wrote:

> On 11/1/10 9:09 AM, Gary Whatmore wrote:
>
>> Nick Treleaven Wrote:
>>
>>  There's a C++0x proposal for a range-based 'for' statement:
>>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html
>>>
>>> The upcoming GCC 4.6 C++ compiler changes list support for this:
>>> http://gcc.gnu.org/gcc-4.6/changes.html
>>>
>>> I think the syntax could be useful for D to shorten and improve on the
>>> status quo a little. Here's the C++ example:
>>>
>>> int array[5] = { 1, 2, 3, 4, 5 };
>>> for (int&  x : array)
>>>   x *= 2;
>>>
>>> Currently D has:
>>>
>>> int array[5] = [1, 2, 3, 4, 5];
>>> foreach (ref x; array)
>>>   x *= 2;
>>>
>>> I think this is better:
>>>
>>> for (ref x : array)
>>>   x *= 2;
>>>
>>> Apart from being 4 chars shorter, I think it looks more natural using the
>>> ':' instead of ';'. A lesser benefit is it allows reuse of the 'for'
>>> keyword, making the 'foreach' keyword unnecessary.
>>>
>>> Maybe this would be acceptable for D?
>>>
>>
>> No, 1) it's too late to change it. 2) the syntax comes from Java. It would
>> be embarrasing to admit that Java did something right.
>>
>>  - G.W.
>>
>
> Java did a lot of things right (be they novel or not) that are present in
> D, such as reference semantics for classes, inner classes with outer object
> access etc.
>
> Andrei
>

Why is reference semantics for classes the right thing to do? - Just curious
about it, because to me it seems counter intuitive to have to semantics.

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: GCC 4.6

[Emil Madsen]

On 24 November 2010 21:40, Bruno Medeiros wrote:

> On 31/10/2010 02:47, bearophile wrote:
>
>> Walter:
>>
>>  You post lists of features every day.
>>>
>>
>> I hate wasting your time, so please ignore my posts you aren't interested
>> in. I write those things because I like to think and discuss about new ways
>> to explain semantics to computers. Most of those things are for discussion,
>> not for inclusion in D2 (few of them may be included in D3, in the future).
>>
>>
> And how does Walter (or anyone else for that matter), determine if they are
> interested in your posts or not (or anyone else's for that matter) without
> reading them first?
> This is often the case for me regarding posts and threads that discuss
> changes or additions to language features. In these kinds of threads the
> title alone is very little indication of the quality or interest of the
> thread.
>
>
> --
> Bruno Medeiros - Software Engineer
>

I must say; I think bearophile usually brings up some good issues, and
things to discuss, and I do like reading his posts. - About not being
interrested in reading his posts, really if you dont wanna read posts, why
are you on a mailing list? - if its the amount thats the issue, then find
some community with low activity instead >.<'.

And yea, bearophile brings up a lot of nice features, and Walter would never
have a chance to implement all of them himself, which might be good, if
everything bearophile suggests got into the language, we would have this
major language noone would ever be able to learn, nor use. However, if we
succeed in implementing the best ideas I do think we'll end up with a superb
output, however I do think we need to discuss a lot of issues and features,
and thats why I love bearophiles postings, simply because it gives the
community a lot to discuss.

Just my opinion. - But I do think discussing a lot of features, even the
ones not really related, will help out the language in the end.

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Template performance

[Emil Madsen]

2010/11/23 Stanislav Blinov 

> 23.11.2010 2:23, bearophile wrote:
>
>> Time ago I have found a little C++ program that computes the number of
>> solutions to the N Queens problem at compile-time using just templates. I
>> have translated it into CTFE code and I have shown in this newsgroup that if
>> your purpose is to compute a result at compile-time, then D CTFE allows you
>> to write much simpler (and faster) code compared to the C++ template
>> mataprogramming.
>>
>> This time I have translated that C++ code to D code that uses just
>> templates. This is not idiomatic D code, because for this purpose CTFE is
>> better, but templates are used in D too, so it may be a performance
>> benchmark for templates in general.
>>
>> I am not very good with C++ templates yet, so if you spot an error in my D
>> translation please tell me that I will redo the timings.
>>
>> Compilation time: G++ 0.96 seconds, dmd 12.4 seconds.
>>
>> With N=7 G++ uses about 34 MB RAM, DMD about 130+ MB RAM.
>>
>> I have used MinGW 4.5.1 and DMD 2.050.
>>
>>
> It'd be good if you also posted the machine specs. I ran the benchmark on
> Intel i5 750 with 8Gb RAM under Windows7 Pro x64.
>
> I don't have G++ right now, but I tried cl from Visual Studio 2008 and dmc
> 8.42n instead
>
> Here are the timings (compiler-version-seconds):
>
> dmd 2.0502.97958
> cl  15.00.30729.01   3.65038
> dmc 8.42n11.6375
>
> So at least on this system dmd doesn't look that bad at all.
>

I'm getting:
MinGW G++ (source code modified):  744 miliseconds
MinGW G++ (usual version):   924 miliseconds
Dmd:  4275 miliseconds
(i7 720QM, 4GB ram)

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Some new LLVM slides/videos

[Emil Madsen]

So these sliders are empty - I take it?

On 19 November 2010 22:29, bearophile  wrote:

>
>


-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Ruling out arbitrary cost copy construction?

[Emil Madsen]

Make the syntax ugly? - so you cant avoid seeing it?

On 29 October 2010 19:40, Andrei Alexandrescu  wrote:

> On 10/29/10 12:18 CDT, dsimcha wrote:
>
>> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
>> article
>>
>>> To recap:
>>> 1. Arbitrary cost copy construction:
>>> + Makes value types easy to define: just hook the copying code into
>>> this(this)
>>> + Is familiar to programmers coming from C++
>>> + If it fails, fails early, not surprisingly during a later operation
>>>
>>
>> BTW, I don't see why failing during a variable assignment is any less bad
>> than
>> failing during any other seemingly innocuous operation.
>>
>
> One problem is that copying is often implicit and as such more difficult to
> see with the naked eye.
>
> Andrei
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: The Next Big Language

[Emil Madsen]

Nahh, its just him, he apparently likes you the most (^ . ^)
(jk)

On 19 October 2010 21:53, Andrei Alexandrescu  wrote:

> On 10/19/10 14:04 CDT, Max Samukha wrote:
>
>> On 10/19/2010 09:06 PM, Walter Bright wrote:
>>
>>> bearophile wrote:
>>>
 The point I was trying to express is that from what I have seen people
 are
 able to learn to program Python (this means quite more than just the
 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.

>>>
>>> Time will tell how long it will take people to become idiomatically
>>> proficient in D. But also consider that Andrei's book "Modern C++
>>> Design" completely changed the idiomatic way people wrote C++ programs.
>>> A 1990's state of the art C++ program is very different from a 2010 one.
>>>
>>> We've only just begun figuring out the right way to write D programs.
>>>
>>
>> That is funny. Now and then you and Andrei talk so confidently about Go,
>> C#, Haskell and other D competitors, without having written more than a
>> couple of lines in those languages. At the same time, you are claiming
>> that it takes years to even start to learn a programming language. Sure,
>> it is not problems with D that make it difficult to use. We simply don't
>> know how to program in D yet, after several years of doing just that.
>>
>
> I agree this seems to be a contradiction. Haskell is a fairly mature
> language building on a staunch pure functional base so many of its idioms
> have been established. C# uses rather conservative features so it's not
> difficult to learn from the perspective of the languages that influence it.
> Go is a small language that has one defining feature (the implicit signature
> conformance) that does add a certain flavor but is understood and has been
> experimented with in other languages.
>
> D has added a lot in the direction of generics, and by their nature
> generics interact heavily with the rest of the language. I agree it is
> taking time to get to best use of such, but it's not wasted time because it
> marks real progress. For example, code using the relatively new template
> constraints is better than code that didn't use them.
>
>
>  With all due respect for Andrei, I doubt that it is his book that
>> completely changed the way people wrote C++ programs. It was
>> influential, right, but it was really not a single factor. And some of
>> ideas presented in that book are avoided by reasonable programmers.
>>
>> Please stop so shamelessly advertising each other. Thanks!
>>
>
> Sorry. Do I advertise Walter that frequently?
>
>
> Andrei
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: [due diligence] std.xml

[Emil Madsen]

I agree with so, be polite, tho the code might not be as good as one would
wish.

2010/10/19 so 

> Man, you sure getting on my nerves, on your last strike i lost it and gone
> berserk in one of your threads. Now this... You know a human being wrote it,
> have some respect until you come up with something better.
>
> Thanks!
>
>
> On Tue, 19 Oct 2010 16:06:31 +0300, Justin Johansson  wrote:
>
>  This module should be removed altogether from Phobos forthwith.
>>
>> The code was obviously submitted and accepted without peer
>> review, either that or the peers were idiots as well.
>>
>> It would be better to say that Phobos does not have an
>> XML library yet, and to seek submissions, rather than
>> maintain this piece of codswallop in the latest distribution.
>>
>> Let's not even talk of deprecation.  Any D user currently
>> using std.xml is completely misguided.
>>
>> Justin
>>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Ddoc to PDF

[Emil Madsen]

Having two modes? - the basic standart one, and a flag switched one?

On 19 October 2010 15:14, Gerrit Wichert  wrote:

> Am 17.10.2010 19:45, schrieb Walter Bright
>
> > Apparently, it is fairly simple to convert plain text files to PDF.
> >
> > http://re-factor.blogspot.com/2010/10/text-to-pdf.html
> >
> > Which suggests to me it should be equally simple to create a Ddoc
> > macro file to allow Ddoc to emit pdf files directly.
> >
> > Anyone want a nice weekend project to product this?
> >
>
> I don't think that it is the best idea to produce a pdf in one step.
> First PDF is really complicated (and also evolves over time).
> Second this would require dmd to determine the layout of the generated
> documentation.
>
> We could easily avoid the frist point. When we just make ddoc generating
> xsl-fo a tool like apache fop can be used to generate pdf or html from
> it. This is what xsl-fo is designed for. It's not rocket science to
> create a xsl-fo layout. But the second problem remains. If i where a
> company or community writing libraries in d i would like to have some
> corporate identity in it. This means that I want to decide over the
> layout. So i would really prefer if ddoc were *additionaly* able to
> generate a pure semantical version of the document data that is easy to
> mess with an external tool. This can be a simple xml file which i can
> feed into my own transformation pipline. This way ddoc does the part it
> can really shine on, extracting the information, and delegates the rest
> to something that knows more about the wishes of the actual user.
>
> This shuoldn't  mean that ddoc should stop generating unified standart
> documentation. But i think it is worth a thought to generate semantic
> data files on request.
>
> Gerrit
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: The Next Big Language

[Emil Madsen]

So... When are you writing a book?
Emil Madsen

On 19 October 2010 13:49, bearophile  wrote:

> Andrej Mitrovic:
>
> > Knowing the syntax and knowing how to use a language are two very
> > different things. If you're a newbie you can learn the C syntax in a
> > couple of weeks, but you would be very wrong to assume that you know
> > e.g. "70%" of C, and that you could read any C project and understand
> > it well.
>
> To become a fluent Python programmer, that knows the Python style well and
> uses well the standard library, you need quite more than one month, probably
> many months (the more you exercise daily the faster you get there, but
> there's often a speed limit), you may even need two years.
>
> The point I was trying to express is that from what I have seen people are
> able to learn to program Python (this means quite more than just the syntax)
> in *much* less time it takes to learn C++/D. And this has precise causes.
>
>
> Regarding C, it's a bit like learning Scheme, you need only few months to
> learn C syntax even if you don't know a prior language. Then you may need
> two years to write some bigger C programs. And then you have just started
> learning C. Learning to program in C feels a bit like a ladder of Initiation
> Levels, even after many years you are able to find more advanced ways to use
> C.
>
> Few years ago I have found the good "C tips" (
> http://users.bestweb.net/~ctips/ ) that I have shown in this newsgroup
> too. They have taught me that there are ways to write very large C programs
> that work. Those tips show ways to tame C and turn it into a more reliable
> language. But they require very rigorous C programmers.
>
> Despite the advanced contents of those tips, later I have found ways to
> write good C programs less hairy too (see the C source code of the Python
> deque in the collections module, written by the very good Raymond Hettinger,
> that avoids many of the complexities seen in those C tips, designed for far
> bigger programs:
> http://svn.python.org/view/*checkout*/python/trunk/Modules/_collectionsmodule.c?content-type=text%2Fplain).
>  Along the way you probably understand why the classic C Unix tools are so
> small.
>
> Later I have found the very good "performance engineering" lectures (
> http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall-2009/lecture-notes/),
>  plus I have heavily performance-tuned some small C programs, all this has
> shown me new ways to program in C. And thanks to dlibs1 (and std.algorithm
> of Phobos2) I've seen that while those optimizations are sometimes useful,
> you usually want to use them only in a small percentage of the code of a
> program, all the other parts of a C program are better written in a higher
> level. And yes, you may write higher level style code even in C. Recently I
> have even written C code in D-style. And I guess you may write C code
> composed just of pure functions that manage immutable data (despite I've
> never seen such C programs), or you may write quite pure OOP programs in C
> (I have seen a bit of this kind of code), just like you may use good
> structured programming in assembly.
>
> So now I presume there is one even higher level of C programming that I'm
> not seeing yet :-)
>
> In the end C is a computationally complete language, you may use it to
> encode any algorithm, so probably there's no end in the number of
> abstractions or ways to write programs in C. Two hundred years from now
> Alien people coming from a far away star may use a C-style language to write
> code in ways we can't even think about today :-)
>
> Bye,
> bearophile
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: The Next Big Language

[Emil Madsen]

I see a lot of applications going into the browser, in the future, but thats
maybe just me :)

On 18 October 2010 16:10, Jeff Nowakowski  wrote:

> On 10/18/2010 07:11 AM, bearophile wrote:
>
>>
>> The "Next Big Language" will probably be JavaScript.
>>
>
> I see JavaScript as being stuck in the browser for the foreseeable future.
> It does have some usage outside the browser, but not much.
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: [nomenclature] What is a bug?

[Emil Madsen]

This is a bug:
http://www.ent.iastate.edu/images/hemiptera/stinkbug/brown_stink_bug_adult.jpg
Atleast for people who gets outside. - or well.. thats what I'm told :)

On 13 October 2010 15:51, Iain Buclaw  wrote:

> == Quote from Nick Sabalausky (a...@a.a)'s article
> > "Lutger"  wrote in message
> > news:i92j0v$co...@digitalmars.com...
> > >
> > > Note that bugs may actually be wanted behavior. One such case is
> uniform
> > > function call syntax on arrays, which started life as a compiler bug.
> > > Afterwards, the spec was changed and thus the bug was solved.
> > >
> > Wanted behavior that you didn't know you wanted :) Funny how bugs will
> > occasionally inspire features.
> > Legend has it that combos in fighting games started out as a bug in the
> > original Street Fighter 2 (it would let you perform a new move while you
> > were already in the middle of certain other moves.) The "coin boxes with
> > multiple coins" in the original Super Mario Bros were added because an
> early
> > bug did that and it turned out to be fun. Happened to me once to: a
> > game-like demo I made for a hobbyist embedded system (Hydra) has a faked
> 3D
> > effect which I only thought to put in because an early bug in my
> rendering
> > code resulted in a similar (but less polished) 3D-like effect.
>
> In case somebody hasn't already realised the distinction.
> http://faux-rebonds.net/wp-content/uploads/2008/10/bug_vs_feature.gif
>
>
>


-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: What would you rewrite in D?

[Emil Madsen]

I would love to rewrite the copybyvalue and copybyreference schematics, to
one, and then keep that one. I think its counter intuitive that the same
syntax is used for both, and tbh, if everything was just copybyvalue, one
would be able to use by reference, if they wanted to by explicitly declaring
so, using pointers/references/ect., this is the one thing that bugged me
mostly in Java, when coming from C, and the thing that bugs me the most
about D.

On 6 October 2010 00:27, sybrandy  wrote:

> Just asking out of curiosity.  With all the great language features, I'm
> sure that many of you have thought about this.
>
>  For me, I figured a good start would be your basic Unix/Linux/BSD
> utilities, like cat and grep.  I figure it may make the code easier to read
> and maintain as well as potentially improve the quality of the software.  Of
> course, most of these are so old they're probably quite bug free, but some
> probably could use a rewrite.  Some may even benefit for threading.
>
> Anyone else?
>
> Casey
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: struct field alignment

[Emil Madsen]

About the 16byte alignment, of 4floats, its mostlikely for SSE :)

On 18 October 2010 04:16, Denis Koroskin <2kor...@gmail.com> wrote:

> On Mon, 18 Oct 2010 06:00:49 +0400, Walter Bright <
> newshou...@digitalmars.com> wrote:
>
>  http://www.digitalmars.com/d/2.0/attribute.html#align
>>
>> Over time, it has become clear to me that there are only two useful
>> alignments:
>>
>>   align // set to whatever the C ABI alignment is
>>   align(1)  // pack everything in, no alignment padding
>>
>> I think any other alignments should be deprecated. Note that with
>> align(1), any alignment is achievable simply by adding in byte fields where
>> desired.
>>
>
> On some platforms it is desired to align struct Vec { float[4] data; } on
> 16 bytes. I don't recall why now, but I know for sure we do that for all
> platforms (other than PC maybe). I guess that has something to do with
> vector operations.
>
> Bikeshed note: how about align(C) to be consistent with both align(1) and
> extern(C)?
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Am I doing it wrong?

[Emil Madsen]

So I've been told, but havn't been able to find it, so I rechecked, and
there it was, apperently I'm getting blind >.<
I'll make sure not to pollute this mailing list with these questions again
then :) - Thanks once again

On 3 October 2010 23:28, Ali Çehreli  wrote:

> Emil Madsen wrote:
>
>> ah ofc! I shoulda know :) - So I were doing it wrong :)
>>
>
> Thanks for the question; I learned something too. :)
>
> But in case you don't already know, there is also the D.learn newsgroup.
> This question might be more useful there.
>
> Ali
>
>  Say I'm doing that enum a = calcPrimes();
>> then a will be an enum with 1 element, that I can use as an int right?
>> - or is there something special to be aware of?
>>
>> On 3 October 2010 13:20, Torarin  wrote:
>>
>>  2010/10/3 Emil Madsen :
>>>
>>>> Well the result is assigned to an immutable int, shouldn't that be a
>>>>
>>> compile
>>>
>>>> const too?
>>>>
>>> Immutable means that the variable, or the memory it points to, will
>>> not change. You can still assign run-time values to it:
>>> void main(string[] args)
>>> {
>>>  immutable string a = args[0];
>>>  writeln(a);
>>> }
>>>
>>>
>>
>>
>>


-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Am I doing it wrong?

[Emil Madsen]

perfect :), thanks :)

On 3 October 2010 13:39, Jonathan M Davis  wrote:

> On Sunday 03 October 2010 04:34:31 Emil Madsen wrote:
> > can the enum be a float? if calcprimes returned a float? - and if so,
> will
> > the enum be a float or an int? (will it be casted, or will it work as an
> > auto type?)
>
>
> auto, enum, immutable, and const all use type inference. So, you can
> declare
>
> auto a = 7;
> enum b = 7.7;
> immutable c = "hello";
> const d = false;
>
> enum, however, is the only one which is a compile-time constant.
>
> - Jonathan M Davis
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Am I doing it wrong?

[Emil Madsen]

Okay I had a misunderstanding of pure, now I get it, thanks :)

and when I changed the code to enum int, the compiler complained about the
delete statement too :)
so once again thanks :)

On 3 October 2010 13:35, Jonathan M Davis  wrote:

> On Sunday 03 October 2010 03:54:06 Emil Madsen wrote:
> > So I wrote a program, to find prime numbers, just to check out this pure
> > thing;
> >
> > http://gist.github.com/608493
> >
> > However, the program has a runtime of about 5 seconds? - in my mind, if
> the
> > function is pure, shouldn't the compiler insure that it was evaluated at
> > compiletime? - or am I doing it wrong?
>
> pure != CTFE
>
> If a function is pure, then it's result can be cached if it's called again
> with
> the same arguments. So, if you hade a pure sqrt() in an expression like so
>
> auto x = sqrt(2) + sqrt(2) + sqrt(4);
>
> then the compiler could choose to do the sqrt(2) call only once and use the
> result of the first call again instead of calling it again (though it would
> still
> have to call do the sqrt(4) call since it's a different argument). It's an
> optimization that the compiler may or may not choose to do. I don't know
> when
> the compiler currently chooses to do it. But regardless, the function is
> _not_
> called at compile time. What if it wasn't 2 and 4 but rather function
> arguments?
>
> void myfunc(int x, int y)
> {
>//...
>auto x = sqrt(x) + sqrt(x) + sqrt(y);
>//...
> }
>
> The compiler could cache the result of sqrt(x), but it can't do it at
> compile
> time. If you want a function to be called at compile time, it needs to be
> forced. That is, you have to assign the result to a constant. So,
>
> enum x = sqrt(x) + sqrt(x) + sqrt(y);
>
> would be done at compile time - assuming that x and y can be known at
> compile
> time (if they can't then that line won't compile).
>
> Regardless, purity has _nothing_ to do with CTFE (compile-time function
> evaluation). It doesn't even necessarily make it easier for the compiler to
> run
> the function at compile time if it's pure.
>
> Now, for your program, assuming that your calcPrimes() function is
> CTFE-able, if
> you change immutable int to enum or enum int, then it will be run at
> compile
> time and your program will be a lot faster than 5 seconds because primes
> will be
> a constant. Of course, if calcPrimes() is _not_ CTFE-able, then you're out
> of
> lock unless you manage to alter it so that it _is_ CTFE-able.
>
> Oh, and by the way, don't use delete. It's going to be removed from the
> language
> and is completely unnecessary. D is garbage collected. If you want to avoid
> the
> garbage collector, you're going to need to use malloc() and free()  (which
> definitely are _not_ CTFE-able).
>
> - Jonathan M Davis
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: SSE in D

[Emil Madsen]

>uses SSE registers too if your CPU (detected at runtime) supports them.
How is this done? - using codepaths after a call to cpuid?

and I can see the idea in cleaning up syntax, by replacing intrinsics with
array operators, however, what if I want to for instance shuffle? - would it
be possible to overload >> for that, or something? and how would it shuffle?
4 elements or the entire thing? - Say I want to shuffle elements once to the
right like this:
a b c d --> d a b c
(_mm_shuffle_ps(array, array, _MM_SHUFFLE(2, 1, 0, 3));)

Its just because I'm in need of such functionality to implement matrixes,
and such using SSE. - what would my alternative be? implementing
"xmmintrin.h" using bits of small inline asm? - that however wouldn't yield
any speed, if its not getting inlined?

On 3 October 2010 03:34, bearophile  wrote:

> Emil Madsen:
>
> You are asking many different things, let's disentangle your questions a
> little.
>
> >Is there a D equivalent of the "xmmintrin.h", or any other convenient way
> of doing SSE in D?<
>
> D2 language is not designed to be an academic language, it's designed to be
> a reasonably practical language (despite some of its feature are not just
> buggy or unfinished, but also contain new design ideas, that far from being
> "battle tested", so no one knows if they will actually turn out to be good
> in large or very large D2 programs).
>
> But its implementation is not fully practical yet. In a compiler like GCC
> you may see a ton of dirty or smelly little features that turn out being
> practically useful or even almost necessary for real-world code, that are
> absent from the C standard. The D2 compiler lacks a big amount of such dirty
> utility corner cases. Even the (D1) compiler LDC shows some of such
> necessary dirty little features, like the allow_inline pragma to allow
> inlining of functions that contain asm, and so on. I guess that when D2 will
> be more finished, and some people will write a more efficient implementation
> of D2, those little smelly things will be added in abundance.
>
> The xmmintrin little dirty intrinsics are absent from DMD and D, both in
> practice and by design. GCC C is not designed much, they just add those SIMD
> operations to the ball of mud named GNU C (plus handy operator overloading
> if you want to sum or mult two registers represented as special arrays of
> doubles or floats or ints). D here is designed in a bit more idealistic way,
> and it tries to be semantically cleaner, so instead of those intrinsics, you
> are supposed to use vectorial operations done on arrays (both static and
> dynamic).
>
> Many of such operations are already implemented and more or less they work,
> but unless your arrays are large, they actually usually slow down your code,
> because they are chunks of pre-written asm (that use SSE+ registers too)
> designed for large arrays, are they are not inlined. In theory in future the
> D front-end will be able to replace a sum of two 4-float static arrays with
> a single SSE instruction (or little more) (if you have compiled the code for
> SSE-enabled CPUs). In practice DMD is far from this point, and the
> development efforts are (rightly!) focused on finishing core features and
> removing the worst implementation (or even design) bugs. Optimization of
> code generation matters are for later.
>
>
> > - I've been looking into the Array Operators, but will those work, for
> > instance if I'm doing something alike:
> > a[3], b[4]
> > c[4] = a+b;
>
> The right D syntax is:
>
> float[4] a, b, c;
> c[] = a[] + b[];
>
> You must always use [] after the array name. Arrays must have the same
> length.
>
> And currently you can't use this syntax:
>
> void main() {
>float[4] a, b;
>float[4] c[] = a[] + b[];
> }
>
>
> That gives the error:
>
> test.d(3): Error: cannot implicitly convert expression (a[] + b[]) of type
> float[] to float[4u][]
>
> Probably because of a unforeseen design bug that causes such collision
> between D and C syntax that is accepted still in D.
>
> See this bug report for more info about this design problem, that so far
> most people (including the main designers) seem to happily ignore:
> http://d.puremagic.com/issues/show_bug.cgi?id=3971
> Here I have suggested a possible solution, the introduction of a -cstyle
> compiler flag, that was ignored even more:
> http://d.puremagic.com/issues/show_bug.cgi?id=4580
>
> So this code works:
>
> void main() {
>float[4] a, b, c;
>c[] = a[] + b[];
> }
>
> But it performs a call to the asm routine that performs the vector c=a+b in
> assembly, that uses SSE registers too if your CPU (detecte

Re: Am I doing it wrong?

[Emil Madsen]

can the enum be a float? if calcprimes returned a float? - and if so, will
the enum be a float or an int? (will it be casted, or will it work as an
auto type?)

thanks btw :)

On 3 October 2010 13:28, Torarin  wrote:

> 2010/10/3 Emil Madsen :
> > ah ofc! I shoulda know :) - So I were doing it wrong :)
> > Say I'm doing that enum a = calcPrimes();
> > then a will be an enum with 1 element, that I can use as an int right?
>
> Yes, effectively you are declaring an anonymous enum with one element.
> By default an int.
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Am I doing it wrong?

[Emil Madsen]

ah ofc! I shoulda know :) - So I were doing it wrong :)
Say I'm doing that enum a = calcPrimes();
then a will be an enum with 1 element, that I can use as an int right?
- or is there something special to be aware of?

On 3 October 2010 13:20, Torarin  wrote:

> 2010/10/3 Emil Madsen :
> > Well the result is assigned to an immutable int, shouldn't that be a
> compile
> > const too?
>
> Immutable means that the variable, or the memory it points to, will
> not change. You can still assign run-time values to it:
> void main(string[] args)
> {
>  immutable string a = args[0];
>  writeln(a);
> }
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Am I doing it wrong?

[Emil Madsen]

Well the result is assigned to an immutable int, shouldn't that be a compile
const too?

2010/10/3 Denis Koroskin <2kor...@gmail.com>

> On Sun, 03 Oct 2010 14:54:06 +0400, Emil Madsen  wrote:
>
>  So I wrote a program, to find prime numbers, just to check out this pure
>> thing;
>>
>> http://gist.github.com/608493
>>
>> However, the program has a runtime of about 5 seconds? - in my mind, if
>> the
>> function is pure, shouldn't the compiler insure that it was evaluated at
>> compiletime? - or am I doing it wrong?
>>
>>
> Make your result an "enum" (i.e. compile-time constant) if you really want
> to calculate it in compile-time:
>
> enum primes = calcPrimes();
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Am I doing it wrong?

[Emil Madsen]

So I wrote a program, to find prime numbers, just to check out this pure
thing;

http://gist.github.com/608493

However, the program has a runtime of about 5 seconds? - in my mind, if the
function is pure, shouldn't the compiler insure that it was evaluated at
compiletime? - or am I doing it wrong?

-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: The Many Faces of D - slides

[Emil Madsen]

Interesting, would have loved to be there :)

On 3 October 2010 12:28, Walter Bright  wrote:

> The slides for my Sep. 15 talk at NWCPP:
>
> http://nwcpp.org/images/stories/nwcpp-2010-09.pdf
>



-- 
// Yours sincerely
// Emil 'Skeen' Madsen

SSE in D

[Emil Madsen]

Is there a D equivalent of the "xmmintrin.h", or any other convenient way of
doing SSE in D?
- I've been looking into the Array Operators, but will those work, for
instance if I'm doing something alike:
a[3], b[4]
c[4] = a+b;
and when will the compiler write SSE asm for the array operators? - is there
a target=architecture for the compiler? or will it simply write SSE if one
defines something alike -msse4? - I'm having a bit of trouble finding stuff
about SSE for D, sources on the subject anyone?

-- 
// Yours sincerely
// Emil 'Skeen' Madsen