Re: Why is there no or or and ?

[Kevin Cox]

Vb yes, python kinda.  Vb is designed for people who don't want to
program.  The idea is to create a quick application that gets two job
done.  Python is slightly different.  It has a ton of syntax and all the
libraries that it needs to be used in moderately sized project.  Python
comes across as being easy to learn because it is simple in the most
beautiful way.  I doubt many large programs are written in python but of
course it is finding a home on the web.  I think that python stretches
close to the line but I doubt it was designed for beginners.
On Feb 19, 2012 10:20 AM, "Stewart Gordon"  wrote:

> On 17/02/2012 06:09, bcs wrote:
> 
>
>> Any language that is designed to be easy for amateurs to use will be used
>> by amateurs, and
>> only by amateurs.
>>
> 
>
> Do you consider either VB or Python to fall under that category?
>
> Stewart.
>

Re: size_t + ptrdiff_t

[Kevin Cox]

What if te compiler was allowed to optimist to larger types?  The only
issue is if pulled rely on overflowing.  That could be fixed by add in a
type with a minimum size specified.  This is kind of like C's fast int type.
On Feb 20, 2012 8:20 AM, "Regan Heath"  wrote:

> On Mon, 20 Feb 2012 11:28:44 -, Manu  wrote:
>
>  On 20 February 2012 13:16, Walter Bright 
>> wrote:
>>
>>  On 2/20/2012 3:02 AM, Manu wrote:
>>>
>>>  ? I must have misunderstood something... I've never seen a 64bit C
 compiler
 where 'int' is 64bits.


>>> What are you using in C code for a most efficient integer type?
>>>
>>>
>> #ifdef. No 2 C compilers ever seem to agree.
>> It's a major problem in C, hence bringing it up here. Even size_t is often
>> broken in C. I have worked on 64bit systems with 32bit pointers where
>> size_t was still 64bit, but ptrdiff_t was 32bit (I think PS3 is like this,
>> but maybe my memory fails me)
>>
>> I want to be confident when I declare a numeric type that can interact
>> with
>> pointers, and also when I want the native type.
>>
>
> I can imagine situations where you want to explicitly have a numeric type
> that can hold/interact with pointers, or you need /more/ width than the
> native/efficient int type.
>
> But, in /all/ other cases surely we want the **compiler** to pick/use the
> native/most efficient int type/size.  Further, why should we state this
> explicitly, why shouldn't "int" just /be/ the native/most efficient type
> (as determined by the compiler during compilation of each/every block of
> code)... I know, I know, this goes in the face of one of D's initial design
> decisions - being sure of the width of your types without having to guess
> or dig in headers for defines etc.. but, remind me why this is a bad idea?
>
> Because, it just seems to me that we want "int" to be the native/most
> efficient type and we want fixed sized types for special/specific cases
> (like in struct definitions where alignment/size matters, etc), i.e.
>
> int a;   // native/efficient type
> int16 b; // 16 bit int
> int32 c; // 32 bit int
> int64 d; // 64 bit int
> ..and so on..
>
> But.. assuming that's not going to change any time soon, we might be able
> to go the other way.  What if we had a built-in "nint" type, which we could
> use everywhere we didn't care about integer type width, which resulted in
> the compiler picking the most efficient/native int width on a case by case
> basis (code inspection, etc.. not sure of the limits of this).
>
> Regan
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>

Re: dmd -c behaviour doesn't take account of packages.

[Kevin Cox]

Although I agree that sources and objects should be sperated there are some
benifits.  All tools know where to look for the objects.  And is not
dificult to keep out of scm.  A great example of this is Haskell.  To
compile an app you only need to specify the main file and it finds all the
included modules, only recompiling if nessary.  And if I remember correctly
it also spits out a "definition list" type file that is great for things
like code completion.
On Feb 22, 2012 7:15 PM, "Jonathan M Davis"  wrote:

> On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:
> > On Wed, Feb 22, 2012 at 05:05:40PM -0500, Jonathan M Davis wrote:
> > > On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:
> > > > A discussion on the Mono-D IRC channel just made me realise
> > > > something.
> > > >
> > > > dmd -c foo/a.d bar/a.d
> > > >
> > > > The second module overwrites the first. This makes using 'pass
> > > > everything at once' with Mono-D (IDE plugin) difficult/impossible.
> > > > As far as I'm concerned, it's just a bug that's never come up. The
> > > > solution is trivial, of course. Prepend package names so you get
> > > > foo_a.o and bar_a.o. Either that or allow specific output paths to
> > > > be specified per-object.
> >
> > [...]
> >
> > The real solution is that when creating object files, dmd should put the
> > .o files in the modules' respective subdirectories. I.e., it should keep
> > the pathname component of every source file and use that for the object
> > file. Then you have a 1-to-1 mapping between source files and object
> > files.
>
> Yuck. Yuck. Source should _always_ be separated from object files. It's
> incredibly messy otherwise.
>
> > Either that, or duplicate the source tree structure in an object tree
> > (if you like that kind of compile structure -- some projects do that).
>
> That's definitely the way to organize things.
>
> - Jonathan M Davis
>

Re: Conclusions of the exception discussion

[Kevin Cox]

I think there should also be multiple catches so that you can deal with
different exceptions different ways without trying to upcast them over and
over again.
On Feb 25, 2012 1:30 AM, "Daniel Murphy"  wrote:

> "Jonathan M Davis"  wrote in message
> news:mailman.93.1330149312.24984.digitalmar...@puremagic.com...
> > However, regardless of which we choose, someone is going to have to take
> > the
> > time to implement it, since odds are that Walter isn't going to do it.
> So,
> > whether we end up with a feature along these lines is highly dependent on
> > whether anyone is willing to take the time to implement it and get it
> > accepted
> > by Walter.
>
> Wy ahead of you here.
>
> https://github.com/D-Programming-Language/dmd/pull/738
>
> It's currently 'catch(auto e : E1, E2, E3)' but changing the syntax is
> trivial if everyone decides they want it.
>
>
>

Re: Poll of the week: main OS and compiler

[Kevin Cox]

On Mar 1, 2012 11:11 AM, "Manu"  wrote:
>
> Windows leads. Amazing!
>
> COFF + 64bit plz! ;)
>
>
> On 1 March 2012 16:40, Marco Leise  wrote:
>>
>> Since everyone loves polls, and the question comes up now and then: What
is your main development platform for D ?
>>
>> http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494
>
>

Right now its tired between BSD/Linux and windoze.

My Issues with Slices and AAs

[Kevin Cox]

After learning and using D for a little while I have discovered some (in my
opinion) problems with the slices and associative array built-ins (for now
I will just say slice).  The main issue I have is that there is no way to
pass around something that looks like and acts like a slice.  This is
because there is no class or interface to which slices adhere.  I think
this is a very simple concept and it could be easily remedied by creating
an Array interface which slices implement.  This way you could create
things like lazy and asynchronously filled arrays.

I have to admit that I am a little at a loss for examples where a slice
could be used this way but I would like to have the power because that is
the heart of polymorphism.  I could design a class/function/... that takes
an "object that implements Array" and if later I find out that I would like
to pass a slightly different array I could do that without any changes to
my code.  An example of this is an old issue from C++.  RapidXML (you
guessed it, an XML library) was initially only able to read from a file.
This means that if you were doing something (like a webserver application)
you would have to write the incoming XML to disk before parsing it, losing
all of the speed on RapidXML.  The thing was that this design choice was
because it was a lot of work to support both efficiently and requiring
strings as input meant that most users would have to load a whole file into
memory before starting the parsing process.  If we were to write DXML we
could instead require an input that is an array of characters and we could
pass in either a string or a file (or file reader, or whatever) that read
more of the file as it was accessed.  (of course doing some nice buffering
and the like)  This is because all DXML wants is a bunch of characters, it
doesn't care where they are coming from.

An example for AAs is if you want to do something like live translation in
your app.  It makes sense to have an AA of strings for every language.
But, if every language is not complete you end up with holes.  Instead you
decide you wish to fallback to a complete language.  Now, you have to
rewrite your app so that every function that displays stuff to the User
takes both the locale and the fallback.  Or, you create an AA class that
handles lookup for you.  But you still can't pass this around because your
program is wired for AAs.

In, conclusion. (Tl:Dr) slices and AAs do not allow polymorphism and
therefore are decreasing the power and flexibility of D.

I hope to hear your opinions,
Kevin.

Re: My Issues with Slices and AAs

[Kevin Cox]

On Mar 2, 2012 10:30 AM, "Andrei Alexandrescu" <
seewebsiteforem...@erdani.org> wrote
>
> Slices are primitive, concrete components that are close to the metal and
are best for implementing abstractions, not defining them. You can always
build and use abstract interfaces (that may or may not use slices
internally). But at a point the turtles must end, and that's where the
slices are.
>
> Andrei
>

Thanks for all of the replies.  I will read up and see what I think.

Although if slices are still built-in but act as if they are part of an
interface will that slow them down?  And, if so where is the slowdown?  Is
it in the interfaces?

-Kevin

Re: My Issues with Slices and AAs

[Kevin Cox]

On Sat, Mar 3, 2012 at 12:09 AM, Xinok  wrote:

> http://ddili.org/ders/d.en/**ranges.html
>

Thanks for the great link.

And thanks everyone for your help.  I can't believe I missed ranges as they
are exactly what I wanted.

Kevin

Re: Whats up with the domains?

[Kevin Cox]

On Mar 3, 2012 5:26 AM, "David Nadlinger"  wrote:
>
> On Saturday, 3 March 2012 at 05:12:31 UTC, Kevin wrote:
>>
>> AFAIK they are mirrors of each other, would it be best to make one a
redirect (smart, on a per-page level).
>
>
> This already happened after the discussion at
https://github.com/D-Programming-Language/d-programming-language.org/pull/80#issuecomment-3939792,
and Google seems to have already picked it up.
>
> There are still quite a few links on the site pointing to the old
domains, though, see:
https://github.com/D-Programming-Language/d-programming-language.org/pull/94
>
> David

Wow, beat me to it.

And google has picked it up

Re: Multiple return values...

[Kevin Cox]

On Mar 9, 2012 10:28 AM, "H. S. Teoh"  wrote:
>
> On Fri, Mar 09, 2012 at 03:27:14PM +0100, Timon Gehr wrote:
> > On 03/09/2012 01:23 AM, Manu wrote:
> [...]
> > >int x; ... (x, float y) = func(); // assign to predeclared
variable(/s)?
> > >(x, , z) = func(); // ignore the second result value (elimination of
the
> > >second result's code path)
> > >
> >
> > Those two would work, but (x,y) = func(); conflicts with the comma
> > operator. (I'd prefer (,) to be a tuple constructor though.)
>
> Just out of curiosity, *why* does D have a comma operator? It's one of
> those obscure things about C that can be really, really, nasty if you're
> unaware of it. And C++ makes it worse by making the comma operator
> *overloadable

The comma operator can be worked around by using braces instead.  Of course
it is very breaking and quite arguably ugly.

for ({int I; float j;} ; ) ;

But then you have to worry about what it returns.  The sequence operator is
actually useful it is just unfortunate that they used it for function
parameters also.

I think that the best work around is either the braces which can be quite
elegant because it fits the rest of the language and say it returns the
return value of the last statement.  Or pick a new character for the
sequence operator.

This is actually kinds nice because you get "tuple" in "tuple" out.  Of
course they don't need to be tuples that can be passed around they can be
values that must be unpacked right away.

Re: DDoc and logically structured HTML

[Kevin Cox]

On Mar 10, 2012 8:10 PM, "Stewart Gordon"  wrote>
> I don't know how far we can go short of a doclet system like JavaDoc has.
 Nor even how exactly a doclet system would work under a language that
compiles to native code
>
> Stewart.

I hate to say it but I think the ddoc system was way overthought.  It would
be better to use a markup language such as Creole that is meant to look
nice and you can convert that into anything you want.  You could leave the
default html but provide an api for accessing a parsed tree.

Re: How about colors and terminal graphics in std.format?

[Kevin Cox]

On Mar 12, 2012 7:55 PM, "Damian Ziemba"  wrote
> And yea, I think like others that it should have its own module like
std.terminal/std.console or maybe somekind of spot in std.stdio.

Python has a great lib for this.  I can't remember what package it is in
but it has things like isTty() and all of the colors as well ad querying
for different color support.  For a name may I recommend std.term.

Re: Tuple unpacking syntax [Was: Re: Multiple return values...]

[Kevin Cox]

Kind of unrelated but I think that it is important to have a way to ignore
values also.  Leaving them bank would sufice.

(int i,,float f) = intBoringFloat();

Re: Changing the name of the language?

[Kevin Cox]

On Mar 15, 2012 9:25 PM, "ixid"  wrote:
>
> D is a very poor name for a language

I like dpl and post tagged with it would turn up pretty well in google.
But, as dlang is the website I think that is the best.  Most blogs and
fourms have a tag feature and you could always just say it in your post. "D
(dlang.org)"  google will pick up the url really nicely.  I don't think the
name is a problem, people who write about D just have to get system going
and search engines will catch on.  Especially now that the dlang.org site
is official the problem will only fade.

Re: Interesting Memory Optimization

[Kevin Cox]

On Mar 16, 2012 7:45 AM, "Alex Rønne Petersen"  wrote
>
> I don't see any reason why c couldn't point to element number 3 of b, and
have its length set to 3...
>
> --
> - Alex

And the previous examples were language agnostic.  In D and other languages
where the length of a string is stored we can nest strings anywhere inside
other strings.

const char[] a = "foofoo";
const char[] b = "oof";

Those can't be nested in null terminated strings, bit they can where
strings have an explicit length.

Re: Implicit integer casting

[Kevin Cox]

On Mar 18, 2012 3:09 PM, "Manu"  wrote
> int x = 123456;
> x &= 0xFF; // x is now in range 0..255; now fits in a ubyte
> ubyte y = x; // assign silently, cast can safely be implicit

This is related to Go's infinitely sized constants.  If an expression
produces a value out of range then brings it back in range in a constant it
still works.

int i = 1 << 100 >> 98;
assert( i == 4);

Not exactly related but similar idea.

Re: Interesting Memory Optimization

[Kevin Cox]

On Mar 18, 2012 4:50 PM, "Peter Alexander" 
wrote:

> Neither do I, but it's more work for the compiler, and even if the
compiler does string pooling, it may not look for common suffixes.

It would be more work but it would have memory and cache benefits.  If you
stored created a set of strings ordered lexographicaly by their reverse it
would not be that much overhead.

Re: How to use D for cross platform development?

[Kevin Cox]

On Mar 25, 2012 7:34 PM, "Jonathan M Davis"  wrote:
>
> On Monday, March 26, 2012 09:55:00 James Miller wrote:
> > On 26 March 2012 09:44, Iain Buclaw  wrote:
> > > A spork of druntime, yes.
> >
> > A spork? I've never heard that before...
>
> http://en.wikipedia.org/wiki/Spork
>
> Not that it has anything to do with software...
>
> - Jonathan M Davis

I like it.  Not separated just a set of patches.

Re: Poll of the week - How long have you been in the D world?

[Kevin Cox]

>
> Looks like a fairly even spread so far, (27 votes). The higher bracket
> is low, but it is also 6-10 years, D hasn't been around much longer
> than that <.<
>
> --
> James Miller
>

I like the spread.  Most new users and a gradual decline until we get to 6+
where a group of people are sitting.

Re: Poll of the week - How long have you been in the D world?

[Kevin Cox]

On Wed, Mar 28, 2012 at 7:35 PM, Jesse Phillips
wrote:

> Seems the old timers are less representative now (142 votes).
>
> Nice poll, thanks.
>

I was factoring out the different number of years in each category.  I'm
gonna try to create a bar graph with normalized years.

1 - ==
2 - ==
3 - ==
4 - 
5 - 
6 - ===
7 + ==

And with a little rounding

1 - ==
2 - ===
3 - =
4 - =
5 - 
6 - ==
7 + ==

Of course 7+ is not very informative.

Please note those graphs were very quick.

Re: Mascot for D

[Kevin Cox]

On Apr 5, 2012 4:24 PM, "Zbigniew Radosz"  wrote
>
> How about a (digital) martian? :)

Lol it took me a second to get it.  Great one :)

Re: D projects list

[Kevin Cox]

On Apr 5, 2012 5:04 PM, "Nick Sabalausky"  wrote
> I would suggest though, that it be separated into two main parts:
>
> 1. Some sort of central database with a documented, publically-accessible
> machine interface, not a human interface. (And for the love of god, not
> XML.)
>
> 2. A human-usable frontend.
>
> That way, alternative frontends can be created. We could even create a D
> module (maybe in phobos?) to access the list.
>
> (IMO, that's how most web apps should work. And then backends that deal
with
> the same type of data should use standardized interfaces. Hell, that's how
> *real* apps already work (standard file formats, network protocols, etc) -
> that's how computing finally achieved interoperability decades ago, before
> web apps sunk us back into the "no interoperability" dark ages again...But
> now I'm ranting, I'll stop.)
>
> Captcha and/or user management for write-access would be built into #1,
not
> #2. If captcha, then a frontend would tell the backend "I want to write
> access to X resource, or everything (whatever)" and the backend would send
> back a captcha image. The front end would then show it to the user, and
> relay the answer back to the backend.
>
> Actually, better yet, the backend would be user accounts only, but then
> there'd be a special account for anonymous captcha users. It's be one
"anon
> captcha user" account for *each* frontend that wanted to allow captcha.
The
> frontend would then use whatever the hell captcha system it wanted and, if
> the user succeeds, the frontend would transparently communicate with the
> backend via its own "anon captcha user" account. And if the captcha system
> used by the frontend turns out to suck, or be bypassable, or isn't even
> being used by the frontend, then the backend could disable or revoke that
> frontend's "anon captcha user" account. The backend could still,
optionally,
> provide its own "official" captcha system to any frontends that wanted to
> use it

I for one, absolutely love the way you think.  This is a great idea and the
way it should be done.  But, what is wrong with xml when used correctly.

Re: IDE Support for D

[Kevin Cox]

On Fri, Apr 6, 2012 at 7:15 PM, Brad Roberts  wrote:

> It doesn't take a lot of help to greatly improve both the quality of a
> product and the liklihood that it'll survive much longer, but it does take
> some.
>
> My 2 cents,
> Brad
>
>
I agree and understand with what you are saying but sometimes it is useful
to draw attention to topics even when it is outside of your area of
expertise or you don't have the time.  (Athough this horse has been beat to
death.)

Re: Issue with module destructor order

[Kevin Cox]

On Mar 26, 2012 5:11 AM, "Benjamin Thaut"  wrote:
> Is this intended behaviour or is this a bug? I assume this happens
because of the mixin template and the public import.
> I'm using dmd 2.058.
>
> --
> Kind Regards
> Benjamin Thaut

I don't think the order of destructors is defined. There would be no way to
have semantic control because it wouldn't work when you link different
files together.  The only solution would be to have the compiler analyse
the code and figure out what should be destructed first which would be and
impressive feat.

The solution to solving your problem is not to close the file object in the
destructor and let the OS clean it up when your program terminates.

Re: Documentation improvements

[Kevin Cox]

I would just like to say that I like having the grammar there.  It helps me
see the relations in the syntax.  And I thought there were enough syntax
examples.

Re: Documentation improvements

[Kevin Cox]

On Apr 8, 2012 4:54 PM, "Jonas H."  wrote
> Sure but when people click on a link and weird grammar definitions are
the only thing that's on the screen they're likely to think "that's not
what I looked for" and try other pages.

For sure. I think there should be both.

Re: x32-abi + D = fat pointers?

[Kevin Cox]

On Apr 8, 2012 6:24 PM, "Tove"  wrote:
>
> I just stumbled upon this:
> https://sites.google.com/site/x32abi/home
>
> /rant
>
> I remember back in the glorious MC68000 days(24bit addressing)... leaving
8bits for creative optimizations... until 68020 took away all the fun that
is.
>
> So... I was kinda upset that x86-64 was explicitly designed not to permit
such tricks despite having a 48bit addressing mode... hmpf shooting oneself
in the foot is the fun part of programming.
>
> /end rant
>
> Anyway... x32-abi to the rescue, access to 64bit registers just as
normal... but using efficient 32bit pointers, suddenly there are 32 bits
free to play with, D-slices passed around in a single normal 64bit register
anyone? actually 32bits is a lot... one could also possibly imagine
creative flags for the GC.
>

There could also be a mode where if you need more than 32bits you could use
slow odd-sized pointers.

Foreach Closures?

[Kevin Cox]

I was wondering about the foreach statement and when you implement
opApply() for a class it is implemented using closures.  I was wondering if
this is just how it is expressed or if it is actually syntatic sugar.  The
reason I aski is because if you have a return statement inside a foreach it
returns from the outside function not the "closure".

I was just wondering if anyone could spill the implementation details.

Thanks,
Kevin

Re: Foreach Closures?

[Kevin Cox]

On Apr 8, 2012 7:49 PM, "Timon Gehr"  wrote:
>
> On 04/09/2012 01:26 AM, Kevin Cox wrote:
>>
>> I was wondering about the foreach statement and when you implement
>> opApply() for a class it is implemented using closures.  I was wondering
>> if this is just how it is expressed or if it is actually syntatic
>> sugar.  The reason I aski is because if you have a return statement
>> inside a foreach it returns from the outside function not the "closure".
>>
>> I was just wondering if anyone could spill the implementation details.
>>
>> Thanks,
>> Kevin
>
>
> Since opApply has to hand through the return code if it is non-zero, I
assume that DMD simply generates a custom exit code for each possible way
the foreach body can be exit from.
>
> eg:
>
> start:
> foreach(x; foo){
>if(x==1) break;
>else if(x==2) return 10;
>else if(x==3) goto start;
>else if(x==4) continue;
>...
> }
>
> ==>
>
> int __result;
> start:
> switch(foo.opApply((x){
>if(x==1) return 1;
>else if(x==2){__result = 10; return 2;}
>else if(x==3) return 3;
>else if(x==4) return 0;
>...
> }){
>case 0, 1: break;
>case 2: return __result;
>case 3: goto start;
> }

Cool, so it basically translates break and continue to returns and returns
to black magic.  Cool.

Re: Foreach Closures?

[Kevin Cox]

On Apr 9, 2012 5:59 AM, "Ary Manzana"  wrote:

> In this video you can see what foreach with opApply gets translated to
(at about minute 1):
>
> http://www.youtube.com/watch?v=oAhrFQVnsrY

Thanks, that's perfect. I'm definitely going to try out decent.

Re: Foreach Closures?

[Kevin Cox]

On Apr 9, 2012 9:19 AM, "Manu"  wrote:
>
> OMG, DO WANT! :P
> Who wrote this? I wonder if they'd be interested in adapting it to
VisualD + MonoDevelop?
>
>
> On 9 April 2012 12:56, Ary Manzana  wrote:
>>
>> On 4/9/12 7:26 AM, Kevin Cox wrote:
>>>
>>> I was wondering about the foreach statement and when you implement
>>> opApply() for a class it is implemented using closures.  I was wondering
>>> if this is just how it is expressed or if it is actually syntatic
>>> sugar.  The reason I aski is because if you have a return statement
>>> inside a foreach it returns from the outside function not the "closure".
>>>
>>> I was just wondering if anyone could spill the implementation details.
>>>
>>> Thanks,
>>> Kevin
>>
>>
>> In this video you can see what foreach with opApply gets translated to
(at about minute 1):
>>
>> http://www.youtube.com/watch?v=oAhrFQVnsrY
>

Unfortunately I can't get it working.  Ill have to keep fiddling.

Re: Foreach Closures?

[Kevin Cox]

On Apr 9, 2012 10:29 PM, "Andrei Alexandrescu" <
seewebsiteforem...@erdani.org> wrote:
>
> On 4/9/12 9:21 PM, Ary Manzana wrote:
>>
>> Yes, D definitely needs that. The Eclipse plugin could just use bindings
>> to the D compiler API with JNI.
>
>
> Would the JSON compiler output help?
>
> Andrei

It would cover the basics but as soon as you want to something more than
slightly advanced you are up a creek.

Re: Is anyone hacking on druntime in a widespread fashion at the moment?

[Kevin Cox]

On Apr 10, 2012 7:08 PM, "H. S. Teoh"  wrote:
>
> On Wed, Apr 11, 2012 at 12:10:19AM +0200, Alex Rønne Petersen wrote:
> > I'm planning to go over druntime and add nothrow/pure everywhere I
> > can, but I don't want to disturb anyone else who's currently working
> > on patches that this could disrupt.
> [...]
>
> Please do. The current lack of proper function qualifiers has been
> bugging me to no end, every time I try to do the same in my own code. I
> inevitably have to remove some qualifiers that should be there, just
> because of a single druntime construct that wasn't properly qualified.
>
> And while you're at it, you might want to consider const too. Last I
> looked, a whole bunch of stuff that should be const, isn't.
>
> And best of luck to you... the last time I tried to do the same thing I
> ended up changing almost the entire druntime, and still couldn't get the
> result to compile.
>
>
> T
>
> --
> "I speak better English than this villain Bush" -- Mohammed Saeed
al-Sahaf, Iraqi Minister of Information

I was wondering why they could not be implied from the code itself.

Re: Is anyone hacking on druntime in a widespread fashion at themoment?

[Kevin Cox]

On Apr 11, 2012 4:14 PM, "Nick Sabalausky" <
seewebsitetocontac...@semitwist.com> wrote:
>
> "Kevin Cox"  wrote in message
> news:mailman.1599.1334099575.4860.digitalmar...@puremagic.com...
> >
> >I was wondering why they could not be implied from the code itself.
>
> That question comes up a lot. The thing is, that would completely defeat
the
> point. The point is that you want the compiler to *guarantee* that certain
> specific functions are pure/@safe/const/nothrow, etc.
>
> If you make a change that prevents a function from being
> pure/@safe/const/nothrow, and the compiler just simply accepted it and
> internally considered it non-pure/non-whatever, then you haven't gained
> anything at all. It'd be no different from not even having any
> pure/@safe/const/nothrow system in the first place. At *best* it would
just
> be a few optimizations here and there.
>
> But if the compiler tells you, "Hey, you said you wanted this function to
be
> pure/whatever, but you're doing X which prevents that", then you can
> actually *fix* the problem and go make it pure/whatever.
>

Makes sense.

Re: Measuring the page generation of the forum

[Kevin Cox]

On Apr 12, 2012 4:29 PM, "SomeDude"  wrote
>
> So noone thinks this could be a good idea ?

I like it.  I usually put a comment in the bottom of my pages but since the
form is implemented in D it would nice to actually display it somewhere.

Re: Static method conflicts with non-static method?

[Kevin Cox]

On Apr 27, 2012 7:34 AM, "so"  wrote:
>
> I agree it is ugly. If there is a way out (reason why i asked), we should
just dump it.

I don't like the idea either because it is confusing.  The only reason I
can imagine is if there was polymorphism on statics which I see as a fairly
useless feature.   I would be interested to hear of possible use cases
though.

Re: -wi on default?

[Kevin Cox]

On May 7, 2012 7:33 PM, "Alex Rønne Petersen"  wrote:
>  (I mean, we're D, not C; we don't have over 9000 warning variants).
>
> --
> - Alex

Yet.

Re: Please help with GC exception!

[Kevin Cox]

On May 9, 2012 12:53 PM, "Gor Gyolchanyan" 
wrote:
> Wouldn't it make more sense for GC to ignore second deallocation?
> If this was the case, data, which is know to become garbage would be
> deallocated right away.
> On the other hand, I might as well use std.c.stdlib.realloc for these
cases.

No, because then the GC could never give out that same location in memory
again.

Re: [OT] GitHub down?

[Kevin Cox]

On May 11, 2012 5:53 PM, "Alex Rønne Petersen"  wrote:
>
> On 11-05-2012 23:48, Nick Sabalausky wrote:
>>
>> Is it just me, or does GitHub (in its entirety) seem to be down today?
>>
>>
>
> Works For Me (TM) - haven't had problems with GitHub at all today.
>
> Also, this is useful for cases like this one:
http://www.downforeveryoneorjustme.com/github.com
>
> --
> - Alex

Also status.github.com.

Re: Is the D community lacking development tools?

[Kevin Cox]

On May 22, 2012 12:13 PM, "s"  wrote:
>
> +1 for a GUI lib, which is in sync with DMD releases.
>

Is there any way to bind Qt without the dreaded moc and friends?  Because
that would give you a cross platform solution without too much work.

Re: dget - getting code from github

[Kevin Cox]

On May 24, 2012 6:43 AM, "Tobias Pankrath"  wrote:
>
> On Thursday, 24 May 2012 at 09:50:33 UTC, Russel Winder wrote:
>>
>> On Thu, 2012-05-24 at 10:34 +0200, Paulo Pinto wrote:
>> [...]
>>>
>>> Every time I need to do something in an language without official
package manager support, I curse myself.
>>
>>
>> On the other hand Debian, Fedora, FreeBSD, MacOSX, etc. already have
>> package managements systems. A problem is that Windows does not.
>>
>> Experience shows (Maven, Gems, Hackage, ...) that having language
>> specific packaging and platform specific packaging causes strife.
>
>
>
> Platform specific package management is not enough for development use.
It only works, if you need the version the platform provides. And everyone
must have the same platform to have the same version.
>

Yes and no, for actually using programs that use the language the system
package manager is far superior because when you install an app it can also
install the required packages in one go. (As opposed to having to go to the
d package manager and get the right libs.  However you bring up the point
of development.  If you look at the arch build system it has what you
want.  You can write descriptions on how to download and build a package
and then is it just as easy to install as a dget would be, however thee
advantage is that you can still depend on these packages.  Also, for
switching versions all you have to do is change on variable.  I'm sure
there are things like this for other systems but I use arch and I see a
solution to your problem.

Re: dget - getting code from github

[Kevin Cox]

On May 24, 2012 7:03 AM, "Jacob Carlborg"  wrote:
>
> Mac OS X doesn't have one out of the box, App Store doesn't count.
>
> --
> /Jacob Carlborg

IIRC there is one that a ton of people use, is it called macports?

Re: dget - getting code from github

[Kevin Cox]

On May 24, 2012 7:08 AM, "Tobias Pankrath"  wrote:
>
> I'm using arch, too. The problem are the people, who don't :-)

I know what you are saying but package managers were beautiful things that
made it stupidly simple to install software.  But we are slowly going back
to windoze with "install this, run this command, you may need to configure
your repositories, sorry dependency not installed"

I understand that it is more work to have multiple solutions but I think it
is worth it.

And IIRC the abs is portable so worst case is go and install it.  (Easy for
me on arch to say).

Re: Nimrod language

[Kevin Cox]

On May 24, 2012 6:53 PM, "Froglegs"  wrote:
>
>  Like the design, syntax is way better than D
>
>  But half of what makes a language are the compilers/debuggers/tool

I like many ideas of the language but there are some show-stoppers for me.
For example the fact that you have to define things in order.  I shouldn't
have to deal with that in this day and age.

Re: Where is naming convention?

[Kevin Cox]

On Jun 2, 2012 1:54 AM, "Jonathan M Davis"  wrote:
> No. It simply means that all of the letters of an acronym are always the
same
> case. So, you'd have
>
> class ASCIIException {}
> void funcASCII() {}
> int asciiVar;
> enum UTFEnum { asciiEnum, utfEnum }

Oh, good solution, I could never decide how to do it in my code.

Re: SetTimer function not found?

[Kevin Cox]

On Jun 2, 2012 6:33 AM, "John Chapman"  wrote:
>
> On Saturday, 2 June 2012 at 10:11:02 UTC, Godlike wrote:
>>
>> On Saturday, 2 June 2012 at 10:00:07 UTC, Martin Nowak wrote:
>
> Just add these declarations to the appropriate module:
>
> extern(Windows) {
>
> alias void function(HWND, uint, uint, uint) TIMERPROC;
>
> uint SetTimer(HWND hWnd, uint uIDEvent, uint uElapse, TIMERPROC
lpTimerFunc);
>
> BOOL KillTimer(HWND hWnd, uint uIDEvent);
> }

Better yet, put them into std.windows and submit a pull request :P

Re: Increment / Decrement Operator Behavior

[Kevin Cox]

On Jun 4, 2012 8:43 PM, "Xinok"  wrote:
>
> I wonder in that case, is it even worth including in the language? For me
anyways, the whole point of these operators is to use them in expressions.
Otherwise, why not simply write (i+=1)?

For pointers they are useful because they go up in units not bytes
(although addition often does too).

Re: Review: std.uuid

[Kevin Cox]

On Jun 13, 2012 7:23 AM, "Kagamin"  wrote:
>
> If we use all caps for abbreviations then the names should be SHA1UUID,
MD5UUID and UUIDVersion?

I believe tr naming scheme is acronyms have the same case.  So if an
acronym is first it is all lowercase otherwise all uppercase.

Re: getcwd behaves inconsistent?

[Kevin Cox]

On Jun 17, 2012 6:42 PM, "Stephen Jones"  wrote:
>
> I recently switched from Eclipse to monoD and found that all my code to
images etc was invalid because getcwd returns the directory that contains
the main entry code in Eclipse, but returns the directory that contains the
executable in MonoDevelop. Is there a universally consistent way of
accessing files?

This depends on the directory your executable is run in.  I don't know off
the top of my head but I'm sure there is a setting.  Look in run settings
for something along the lines of execution directory.  Set it to the
directory you want.

Re: getcwd behaves inconsistent?

[Kevin Cox]

On Jun 19, 2012 11:03 PM, "BLM768"  wrote:
>
> Is there any chance of this code being added to Phobos? I think it would
get a fair bit of use.
>

+1  I think locating the executable is a common task.

Re: No D->C++, right?

[Kevin Cox]

On Jul 13, 2012 3:45 PM, "Nick Sabalausky" <
seewebsitetocontac...@semitwist.com> wrote:
>
> Am I correct in my understanding that we still don't have a reliable
> tool to translate a D source to C or C++? Can LDC/GDC do anything like
> that? (Doesn't LLVM have a C-outputting backend?)
>

Yes LLVM does.  I think GCC can do something like that too.  AFAIK this is
the only way to do it.

Re: D front-end in D for D

[Kevin Cox]

On Jul 14, 2012 9:15 AM, "David"  wrote:
>>
>> Run-time mixins can be used for incredibly powerful stuff, yet the same
>> run-time mixins can be used for incredibly dangerous stuff. Just don't
>> use them if you don't know exactly what you're doing. :-)
>
>
> I don't see any case where a "runtime-mixin" is the only solution (it's
definitly the unsafest)
>

Yes, eval or exec is pretty much outlawed in other languages, I can only
imagine the same would happen in D.

Re: D versionning

[Kevin Cox]

On Jul 16, 2012 4:15 AM, "Jacob Carlborg"  wrote:
>
> On 2012-07-16 08:51, Walter Bright wrote:
>
>> It is a good idea, but I'd be nervous myself about allowing the compiler
>> to edit my code :-)
>
>
> Don't you trust your own compiler :)
>
> The compiler could have --dry-run option to show what would be changed.
It could also show a diff after all processing.
>
> --
> /Jacob Carlborg
>

Yeah, and if you're using some kind of version control system there is
really no risk.

Re: reference to 'self' inside a function

[Kevin Cox]

On Jul 17, 2012 1:00 PM, "angel"  wrote:
>
> I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
> What might this be good for ?
> For implementing recursion in a lambda function.
> Writing in functional style, one creates many functions, and looking for
reasonable names for these functions becomes unnecessarily painful.

I like that idea, although I don't know about the name.  We also might want
more features such as access to syntacticly nested functions.

Re: reference to 'self' inside a function

[Kevin Cox]

On Jul 17, 2012 6:50 PM, "Era Scarecrow"  wrote:
>
> On Tuesday, 17 July 2012 at 22:13:13 UTC, Eyyub wrote:
>>
>> On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
>>>
>>> I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
>>> What might this be good for ?
>>> For implementing recursion in a lambda function. Writing in functional
style, one creates many functions, and looking for reasonable names for
these functions becomes unnecessarily painful.
>>
>>
>> Good idea !
>> "self" is a cute keyword, or "lambda" but this could break existing code.
>
>
> Mmm.. Why not an inner function to represent the recursive function? True
a 'self' reference may resolve the issue,

What about how JavaScript does it.  Anonymous functions can still have a
"name" that can be used from inside of a function to refer to itself.

And the most useless example ever.

var f = function func ( i ) {
return func(7);
};

I think that this is nice because there is no name space pollution, no new
keywords needed and it is pretty.

Re: reference to 'self' inside a function

[Kevin Cox]

On Jul 18, 2012 6:20 AM, "FeepingCreature" 
wrote:
>
> On 07/18/12 01:05, Kevin Cox wrote:
> >

> > What about how JavaScript does it.  Anonymous functions can still have
a "name" that can be used from inside of a function to refer to itself.
> Sadly, this collides with the return-type syntax already in place.
>
> auto f = function int(int i) { return 0; };

True, but the concept could still be used, we just need some syntax.