Re: MS extend C++ significantly for Windows8... and Andrei got name drop

[Manu]

On 26 January 2012 03:15, Adam Wilson  wrote:

> On Wed, 25 Jan 2012 15:05:43 -0800, Manu  wrote:
>
>  On 26 January 2012 00:55, Adam Wilson  wrote:
>>
>>  On Wed, 25 Jan 2012 14:44:09 -0800, Manu  wrote:
>>>
>>>  On 26 January 2012 00:37, Adam Wilson  wrote:
>>>

  On Wed, 25 Jan 2012 14:28:46 -0800, Manu  wrote:

>
>  On 25 January 2012 23:59, Adam Wilson  wrote:
>
>
>>  On Wed, 25 Jan 2012 13:35:38 -0800, Manu 
>> wrote:
>>
>>
>>>  On 25 January 2012 21:47, bls  wrote:
>>>
>>>
>>>   On 01/25/2012 07:03 AM, Manu wrote:


   This is fairly interesting. MS have extended their C++ compiler
>
>  significantly for Windows8 with a bunch of non-standard stuff.
>
>> FINALLY implement garbage collection, ref counting, properties,
>> delegates, events, generics, etc...
>> If other compilers adopt this tech, D loses some advantages.
>>
>>
>>  But you still have to fight with ifndef ,forward declaration,
>> and a
>>
>>  template syntax against common sense.  Even if you paint shit
> yellow
> it's
> not necessarily gold.
>
>
>  True, but I think this will mitigate a lot of the motivation
> Windows
>
>  devs
 have to seek another language if they're not developing cross
 platform
 apps.

 Sadly, since WinRT requires using these language extensions to
 interface
 with the new windows runtime, you won't be able to write a Windows8
 app
 in
 D.
 Interestingly though, D supports almost everything they've added to
 C++. I
 wonder if it would be possible to do extern(Windows8) to produce a
 compatible ABI for linking with MS C++ apps?

 The most interesting features are 'ref new' and 'gcnew', which makes
 me
 wonder, since Windows8 has an OS garbage collector, would it be at
 all
 possible to have D use the Windows8 GC? I'd prefer this to using D's
 own
 GC
 if it would be supported, and obviously this would be a requirement
 if D
 was going to interact with WinRT properly.
 Also, WinRT uses 'ref new' to allocate ref counted (effectively COM
 to
 my
 understanding) objects. I think I read somewhere that D already has
 extern(COM) no? I wonder if Windows8 ref type linkage is already
 technically supported in D?


  There is no Win8GC, it's all ref counted. WinRT is COM with extras

>>> and as
>>> such should be accessible to D. It would need some extra glue code
>>> over
>>> what we have now ... like the IInspectable interface.
>>>
>>>
>>>  Really? So what's 'gcnew' for?
>>>
>>
>>
>>  That's for targeting the CLR (.NET) so it doesn't conflict with
> new/delete
> in regular C++. It goes all the way back to the first C++/CLI in Visual
> Studio 2005.
> http://msdn.microsoft.com/en-**us/library/te3ecsc8.aspx
> http://msdn.microsoft.com/en-**us/library/te3ecsc8.aspx>
> >
> http://msdn.microsoft.com/en-us/**library/te3ecsc8.aspx>
> <**http://msdn.microsoft.com/en-**us/library/te3ecsc8.aspx
> >
> >
>
>

 So there is a GC... It just happens to be the .net GC. Is that a
 problem?
 Obviously it's accessible in C++ code. Can you use it to allocate C++
 objects, or is it exclusively for some sort of interaction with .net?
 If the rest of the platform is using it...


>>> It's exclusively for the .NET Framework and requires the .NET Framework
>>> to
>>> be installed and loaded to run. It's the .NET Runtime, and as such, it
>>> would be VERY unwise to base anything D on it.
>>>
>>
>>
>> .NET will be a requirement on all Win8 machines. You didn't answer though,
>> can you use the .NET GC to allocate C++ objects to use throughout your
>> native program? Or is gcnew strictly for interfacing C++ with .NET, like
>> C++/CLI?
>>
>
> It is strictly for allocating .NET objects. You CANNOT allocate C++
> objects with the .NET GC, that was implied by the statement on the use of
> the .NET GC.


I see, well that's good. I presume then that it shouldn't be too much
trouble to implement MS C++'s ref type ABI in D then if it is just
basically COM.
How about 'delegate'? Would it be trouble to make the extern ABI compatible
when passing delegates between MSC++/D?

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Mirko Pilger]

YES, I'm not the only person alive using a trackball! Thumb-ball,
marble, or one of those giant pool-ball things?


you both are not alone. i'm also a trackball user for 11 years now. atm 
i have a logitech trackman on my desk but owned one of those billiard 
balls in the past, too.

Re: enum scope

[Trass3r]

You can use anonymous enums. The members will then live in the 
global scope. You can then use just one alias to an int, uint 
or what's appropriate.


Yeah but you loose type safety.

Re: enum scope

[Michel Fortin]

On 2012-01-26 01:12:40 +, Jonathan M Davis  said:


On Thursday, January 26, 2012 02:06:45 Trass3r wrote:

When writing C bindings I usually create lots of aliases via a
string mixin to pull enum members into the enclosing scope so
it's compatible to C.
Would it be wise to let the compiler do this automatically for
extern(C) enums?


Why? You're using them in D code, not C code. What difference does it make if
the enum is one that's used in C code or not? Why would you use such aliases
with enums from C but not those from D/ What makes enums from C different?


Often C enum value naming takes into account that they'll live in the 
outer scope. For instance:


enum UITableViewRowAnimation {
UITableViewRowAnimationFade,
UITableViewRowAnimationRight,
UITableViewRowAnimationLeft,
UITableViewRowAnimationTop,
UITableViewRowAnimationBottom,
UITableViewRowAnimationNone,
UITableViewRowAnimationMiddle,
UITableViewRowAnimationAutomatic = 100
}

So if you're doing direct bindings where you don't want to change the 
names, how do you use that in D?


UITableViewRowAnimation.UITableViewRowAnimationFade

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: enum scope

[Michel Fortin]

On 2012-01-26 11:51:10 +, "Trass3r"  said:

You can use anonymous enums. The members will then live in the global 
scope. You can then use just one alias to an int, uint or what's 
appropriate.


Yeah but you loose type safety.


Or if you absolutely need both type safety and the values to live in 
the outer scope, you can do this:


enum Something
{
SomethingPointy,
SomethingSmooth,
}
alias Something.SomethingPointy SomethingPointy;
alias Something.SomethingSmooth SomethingSmooth;

But that's rather extreme verbosity at the definition.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: enum scope

[Trass3r]

Often C enum value naming takes into account that they'll live 
in the outer scope. For instance:


enum UITableViewRowAnimation {
UITableViewRowAnimationFade,
UITableViewRowAnimationRight,
UITableViewRowAnimationLeft,
UITableViewRowAnimationTop,
UITableViewRowAnimationBottom,
UITableViewRowAnimationNone,
UITableViewRowAnimationMiddle,
UITableViewRowAnimationAutomatic = 100
}

So if you're doing direct bindings where you don't want to 
change the names, how do you use that in D?


UITableViewRowAnimation.UITableViewRowAnimationFade


Precisely.
See dmd's source code, enum STC {STCscope, STCforeach, ...}, enum 
MOD {MODconst, MODshared,...}, etc.

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[Trass3r]

Are the Clang C bindings complete? I imagine they don't get 
that much attention.


It depends on what complete means. If you mean that you can do 
all the things you can do with the C++ API, then no. If you 
mean it's complete enough to implement this project, then I 
don't know. I think at least parts of the C bindings are added 
when someone needs it.


Well I know from the llvm bindings that they aren't complete and 
it's not hard to guess they don't pay that much attention to them.


Is it easy to use them? From what I've seen the llvm bindings 
don't quite follow the naming scheme of the C++ counterpart which 
makes it harder to find the appropriate functions.

Re: enum scope

[Trass3r]

Or if you absolutely need both type safety and the values to 
live in the outer scope, you can do this:


enum Something
{
SomethingPointy,
SomethingSmooth,
}
alias Something.SomethingPointy SomethingPointy;
alias Something.SomethingSmooth SomethingSmooth;

But that's rather extreme verbosity at the definition.


As I said in the first post, this is what I actually do.
Though I use a mixin like mixin(bringIntoCurrentScope!Something);

But inserting this everywhere is rather annoying. And since the 
whole module is guarded by an extern(C): anyway I figured the 
compiler could do it for me.

Re: using enums for flags

[Trass3r]

I agree, enum variable should only contain one of the 
enumerated values. Here's an example how current way may lead 
to unexpected result:


enum Foo { A = 1, B }

void bar( Foo foo ) {
   final switch( foo ) {
   case Foo.A:
   writeln( "A" );
   return;
   case Foo.B:
   writeln( "B" );
   return;
   }
   writeln( "Unreachable branch" );
}

int main() {
   bar( Foo.A | Foo.B );
   return 0;
}

It is intuitive to assume that the final switch will always hit 
one of it's branches, yet this doesn't work here.


Valid example.
As I said one could introduce something like @flags but I guess a 
library solution is preferred.
I still wonder though if implicit conversion to the basetype has 
any merit.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Nick Sabalausky]

"Andrew Wiley"  wrote in message 
news:mailman.40.1327562674.25230.digitalmar...@puremagic.com...
>On Wed, Jan 25, 2012 at 3:31 PM, Nick Sabalausky  wrote:
>> "Steven Schveighoffer"  wrote in message
>> news:op.v8nbixzyeav7ka@localhost.localdomain...
>>>
>>> I must rave about the trackpad on the macbook pro. The interface is so
>>> damned good, I hate going back to my linux laptop (which I must do for
>>> work).
>>>
>>
>> A good trackpad?!? That seems difficult to believe. Whenever I use a 
>> laptop,
>> I just grab/carry-around a trackball (or at least a mouse). I can barely 
>> use
>> those touchpad things, and IBM's "clitmouse" is only a little bit better.
>>
>
>YES, I'm not the only person alive using a trackball! Thumb-ball,
>marble, or one of those giant pool-ball things?

http://www.amazon.com/Logitech-Trackman-Wheel-Optical-Silver/dp/B5NIMJ

(I don't know why the price there is so high, though. They're only around 
$35-ish in stores.)

I absolutely love it. It's my primary pointing device on *any* of my 
computers.

Around 5-10 years ago I started getting wrist pain. I heard that trackballs 
were better for the wrist than mice, so I got one (this logitech one). It 
was really awkward the first, but I got used to it after a couple days. 
After two weeks it felt 100% as natural as a mouse, even for games. 
(Touchpads, by contrast, I was never able to get past the "really awkward" 
stage, even after several years with the laptop I used to have). And I 
haven't been having any more wrist pain since.

I don't even like actual mice all that much anymore (They need so much more 
surface area! And so much more movement. The trackball is just - ZIP! 
Awesome :) ).

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[Jacob Carlborg]

On 2012-01-26 13:24, Trass3r wrote:

Are the Clang C bindings complete? I imagine they don't get that much
attention.


It depends on what complete means. If you mean that you can do all the
things you can do with the C++ API, then no. If you mean it's complete
enough to implement this project, then I don't know. I think at least
parts of the C bindings are added when someone needs it.


Well I know from the llvm bindings that they aren't complete and it's
not hard to guess they don't pay that much attention to them.


I think they pay quite much attention to the bindings. I mean Apple uses 
it in Xcode  (at least I think it's the C bindings and not the C++ code) 
and the C bindings are much more API stable compared to the C++.



Is it easy to use them? From what I've seen the llvm bindings don't
quite follow the naming scheme of the C++ counterpart which makes it
harder to find the appropriate functions.


It seems fairly straightforward, I've just started to use the bindings.
I'm not sure how the LLVM bindings work but these bindings for Clang are 
more of a C library built on top of the C++ code than actual bindings. 
You don't even link with the same library. Instead of linking to 
libclangSema, libclangAST and so on you just link to libclang.


--
/Jacob Carlborg

Re: enum scope

[Jacob Carlborg]

On 2012-01-26 12:51, Trass3r wrote:

You can use anonymous enums. The members will then live in the global
scope. You can then use just one alias to an int, uint or what's
appropriate.


Yeah but you loose type safety.


It's not type safe in C. But you can wrap it in a struct with alias this 
instead.


--
/Jacob Carlborg

Re: using enums for flags

[bearophile]

Trass3r:

> As I said one could introduce something like @flags but I guess a 
> library solution is preferred.
> I still wonder though if implicit conversion to the basetype has 
> any merit.

Those are important topics. D must offer a solution that is both safer and more 
handy than the current one.

Bye,
bearophile

Re: enum scope

[Trass3r]

It's not type safe in C. But you can wrap it in a struct with 
alias this instead.


Yep, but in D we have strong enums, so why not use them.

Re: enum scope

[Mike Parker]

On 1/26/2012 8:55 PM, Michel Fortin wrote:

On 2012-01-26 01:12:40 +, Jonathan M Davis  said:


On Thursday, January 26, 2012 02:06:45 Trass3r wrote:

When writing C bindings I usually create lots of aliases via a
string mixin to pull enum members into the enclosing scope so
it's compatible to C.
Would it be wise to let the compiler do this automatically for
extern(C) enums?


Why? You're using them in D code, not C code. What difference does it
make if
the enum is one that's used in C code or not? Why would you use such
aliases
with enums from C but not those from D/ What makes enums from C
different?


Often C enum value naming takes into account that they'll live in the
outer scope. For instance:

enum UITableViewRowAnimation {
UITableViewRowAnimationFade,
UITableViewRowAnimationRight,
UITableViewRowAnimationLeft,
UITableViewRowAnimationTop,
UITableViewRowAnimationBottom,
UITableViewRowAnimationNone,
UITableViewRowAnimationMiddle,
UITableViewRowAnimationAutomatic = 100
}

So if you're doing direct bindings where you don't want to change the
names, how do you use that in D?

UITableViewRowAnimation.UITableViewRowAnimationFade


alias int UITableViewRowAnimation;
enum
{
UITableViewRowAnimationFade,
UITableViewRowAnimationRight,
UITableViewRowAnimationLeft,
UITableViewRowAnimationTop,
UITableViewRowAnimationBottom,
UITableViewRowAnimationNone,
UITableViewRowAnimationMiddle,
UITableViewRowAnimationAutomatic = 100
}

Re: enum scope

[Jacob Carlborg]

On 2012-01-26 14:23, Trass3r wrote:

It's not type safe in C. But you can wrap it in a struct with alias
this instead.


Yep, but in D we have strong enums, so why not use them.


What about be able to do something like this:

enum Foo
{
public:
bar,
fooBar,
}

Foo f = bar;

--
/Jacob Carlborg

Re: enum scope

[Mike Parker]

On 1/26/2012 10:23 PM, Trass3r wrote:

It's not type safe in C. But you can wrap it in a struct with alias
this instead.


Yep, but in D we have strong enums, so why not use them.


If your binding is for yourself, that's not a big deal. But if you're 
putting it out there for public consumption, then I think compatibility 
with the C version would be more important. If someone is looking at 
sample C code, you should make it they don't need to adjust it much at 
all. In some cases, this is unavoidable (bit fields, macros), but where 
it *is* avoidable, it should be.

strong enums: why implicit conversion to basetype?

[Trass3r]

I thought it'd be good to outsource this question from the other 
thread about enums as flags.


Is there any merit in having implicit conversion to the basetype?
Imo it only introduces a severe bug source and brings no 
advantages.


For example it allows implicit conversion to bool.

enum Bla
{
   S1 = 1,
   S2,
   S3
}
if (Bla.S2) // makes no sense at all, all Blas convert to true
// and if S1 was 0, it would mean false, but it isn't meant as a 
special member!


A better example is something like
if (b && Bla.S2) // written '&&' instead of '&' by mistake, will 
silently pass



In general it allows operations that don't make any sense.

if (Bla.S2 & Blub.S1) // works cause an int is produced
// but by using named enums I made clear that Bla and Blub are 
totally different


Heck even +,-,... work.

Remember that if you do need to do such crazy stuff you can still 
explicitly cast to int or whatever.

Re: HELP! DMD Asserts while generating DI files.

[kenji hara]

What version do you use?
In 2.058head(commit f8887855), `dmd -H -c test.d` succeeds to compile
without DMD assertion.

Kenji Hara

2012/1/23 Adam Wilson :
> Does anyone have any idea why DMD would assert with the following assert on
> this code while building the druntime during DI generation?
>
> Generating This DI file...
> // D import file generated from 'src\core\bitop.d'
> module core.bitop;
> nothrow
> {
>        pure int bsf(size_t v);
>
>        pure int bsr(size_t v);
>
>        pure int bt(in size_t* p, size_t bitnum);
>
>        int btc(size_t* p, size_t bitnum);
>        int btr(size_t* p, size_t bitnum);
>        int bts(size_t* p, size_t bitnum);
>        pure uint bswap(uint v);
>
>        ubyte inp(uint port_address);
>        ushort inpw(uint port_address);
>        uint inpl(uint port_address);
>        ubyte outp(uint port_address, ubyte value);
>        ushort outpw(uint port_address, ushort value);
>        uint outpl(uint port_address, uint value);
>        int popcnt(uint x);
>        debug (UnitTest)
>        {
>        }
>        uint bitswap(uint x);
>        debug (UnitTest)
>        {
>        }
> }
>
> produces this assert in DMD: assert cast.c(2082) t1->ty == t2->ty
> which appears to be the typeMerge function in cast.c
>
> It doesn't do this on all DI files and I am at a loss as to any rhyme or
> reason for when it does assert. Perhaps someone with knowledge of the
> compiler internals could be of help...
>
> Any ideas would be very helpful!
>
> --
> Adam Wilson
> Project Coordinator
> The Horizon Project
> http://www.thehorizonproject.org/

Re: Windows API and druntime/Phobos

[Marco Leise]

Am 26.01.2012, 05:08 Uhr, schrieb Brad Roberts :


On 1/24/2012 8:48 PM, Jonathan M Davis wrote:
The level of support for the Windows API in druntime and Phobos is  
pretty low.

As I understand it, Windows users are pretty much forced to use
http://www.dsource.org/projects/bindings/browser/trunk/win32 if they  
need
comprehensive Win32 API bindings. druntime seems to be trying to define  
all of
the OS-specific stuff like that, but on top of it missing much of it,  
in the
case of the Win32 API, that's a _lot_ of functions, and I don't know if  
we
want to put that much in druntime. So, the question is, how do we want  
to

support the Win32 API in druntime and Phobos?

Do we want to put all of the Win32 API bindings in druntime? If not,  
then do
we want to put them in Phobos? Or do we just want to send Windows  
developers
to a 3rd party library like the Win32 bindings project on dsource?  
Given that
they're OS bindings, I would _think_ that we'd want them in druntime,  
but I

don't know.

Regardless, this is one of those issues which frequently plagues D  
Windows
developers, and we really should at least get a plan together as to how  
we

want to handle it.

- Jonathan M Davis


P.S. A related pull request: https://github.com/D-Programming-
Language/druntime/pull/139


We've got the posix api set in the runtime, not just the subset that the  
runtime or phobos needs.  IMHO, windows should
follow that pattern.  It might be large from a number of lines of  
declarations standpoint, but who cares.


I tend to agree.

Re: Windows API and druntime/Phobos

[Manu]

On 26 January 2012 16:33, Marco Leise  wrote:

> Am 26.01.2012, 05:08 Uhr, schrieb Brad Roberts :
>
>  On 1/24/2012 8:48 PM, Jonathan M Davis wrote:
>>
>>> The level of support for the Windows API in druntime and Phobos is
>>> pretty low.
>>> As I understand it, Windows users are pretty much forced to use
>>> http://www.dsource.org/**projects/bindings/browser/**trunk/win32if
>>>  they need
>>> comprehensive Win32 API bindings. druntime seems to be trying to define
>>> all of
>>> the OS-specific stuff like that, but on top of it missing much of it, in
>>> the
>>> case of the Win32 API, that's a _lot_ of functions, and I don't know if
>>> we
>>> want to put that much in druntime. So, the question is, how do we want to
>>> support the Win32 API in druntime and Phobos?
>>>
>>> Do we want to put all of the Win32 API bindings in druntime? If not,
>>> then do
>>> we want to put them in Phobos? Or do we just want to send Windows
>>> developers
>>> to a 3rd party library like the Win32 bindings project on dsource? Given
>>> that
>>> they're OS bindings, I would _think_ that we'd want them in druntime,
>>> but I
>>> don't know.
>>>
>>> Regardless, this is one of those issues which frequently plagues D
>>> Windows
>>> developers, and we really should at least get a plan together as to how
>>> we
>>> want to handle it.
>>>
>>> - Jonathan M Davis
>>>
>>>
>>> P.S. A related pull request: 
>>> https://github.com/D-**Programming-
>>> Language/druntime/pull/139
>>>
>>
>> We've got the posix api set in the runtime, not just the subset that the
>> runtime or phobos needs.  IMHO, windows should
>> follow that pattern.  It might be large from a number of lines of
>> declarations standpoint, but who cares.
>>
>
> I tend to agree.
>

I wouldn't object to having guaranteed access to winapi in druntime... but
it is pretty big. In the interest of following the pattern with posix, it
makes sense to me.
But I'm also not allergic to it being a completely separate library, as
long as it's distributed with the windows toolchain. I probably wouldn't
want to see it in std, that makes no sense to me. druntime makes some sense
(since parts of druntime depend on windows calls) if people think that's
where it should be.

What is the reasoning for putting the posix api in druntime? That seems
like a weird choice to me... it's nothing to do with druntime, except for a
couple of dependencies perhaps.

Re: Windows API and druntime/Phobos

[Manu]

On 26 January 2012 16:45, Manu  wrote:

> On 26 January 2012 16:33, Marco Leise  wrote:
>
>> Am 26.01.2012, 05:08 Uhr, schrieb Brad Roberts :
>>
>>  On 1/24/2012 8:48 PM, Jonathan M Davis wrote:
>>>
 The level of support for the Windows API in druntime and Phobos is
 pretty low.
 As I understand it, Windows users are pretty much forced to use
 http://www.dsource.org/**projects/bindings/browser/**trunk/win32if
  they need
 comprehensive Win32 API bindings. druntime seems to be trying to define
 all of
 the OS-specific stuff like that, but on top of it missing much of it,
 in the
 case of the Win32 API, that's a _lot_ of functions, and I don't know if
 we
 want to put that much in druntime. So, the question is, how do we want
 to
 support the Win32 API in druntime and Phobos?

 Do we want to put all of the Win32 API bindings in druntime? If not,
 then do
 we want to put them in Phobos? Or do we just want to send Windows
 developers
 to a 3rd party library like the Win32 bindings project on dsource?
 Given that
 they're OS bindings, I would _think_ that we'd want them in druntime,
 but I
 don't know.

 Regardless, this is one of those issues which frequently plagues D
 Windows
 developers, and we really should at least get a plan together as to how
 we
 want to handle it.

 - Jonathan M Davis


 P.S. A related pull request: 
 https://github.com/D-**Programming-
 Language/druntime/pull/139

>>>
>>> We've got the posix api set in the runtime, not just the subset that the
>>> runtime or phobos needs.  IMHO, windows should
>>> follow that pattern.  It might be large from a number of lines of
>>> declarations standpoint, but who cares.
>>>
>>
>> I tend to agree.
>>
>
> I wouldn't object to having guaranteed access to winapi in druntime... but
> it is pretty big. In the interest of following the pattern with posix, it
> makes sense to me.
> But I'm also not allergic to it being a completely separate library, as
> long as it's distributed with the windows toolchain. I probably wouldn't
> want to see it in std, that makes no sense to me. druntime makes some sense
> (since parts of druntime depend on windows calls) if people think that's
> where it should be.
>
> What is the reasoning for putting the posix api in druntime? That seems
> like a weird choice to me... it's nothing to do with druntime, except for a
> couple of dependencies perhaps.
>

Also, WinRT is upon us... I intend to start writing WinRT programs asap.
Ahould that go in druntime too? Are we opening a floodgate?

Re: strong enums: why implicit conversion to basetype?

[Manfred Nowak]

Trass3r wrote:

> but by using named enums I made clear that Bla and Blub are 
> totally different

No. Obviously you decjlared both to be implicitely convertable to a 
common super type: int. To change this, both supertypes have be 
changed.

The impßlementation is unfortenatey broken:

void main(){
enum INT1{ DUMMY};
enum MY1:INT1{ A};
}

Error: cannot implicitly convert expression (0) of type int to INT1

-manfred

Re: strong enums: why implicit conversion to basetype?

[Trass3r]

On Thursday, 26 January 2012 at 14:45:02 UTC, Manfred Nowak wrote:

Trass3r wrote:

but by using named enums I made clear that Bla and Blub are 
totally different


No. Obviously you decjlared both to be implicitely convertable 
to a common super type: int. To change this, both supertypes 
have be changed.


No. The intention is "Bla and Blub don't have anything to do with 
each other".

That's why I question the implicit conversion.

Re: strong enums: why implicit conversion to basetype?

[Manfred Nowak]

Trass3r wrote:

> Is there any merit in having implicit conversion to the basetype?

Yes. Otherwise it would be at least close to equivalence to a 
`typedef'.

-manfred

Re: strong enums: why implicit conversion to basetype?

[Manfred Nowak]

Trass3r wrote:

> That's why I question the implicit conversion.

Yes. I realized my fault and canceled my message, but wasn't fast 
enough.

-manfred

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Steven Schveighoffer]

On Wed, 25 Jan 2012 17:16:19 -0500, Nick Sabalausky  wrote:



But how is just the basic "moving the pointer" compared to other  
touchpads?


It's similar.  The only thing is, the click is actually a physical button  
(the whole pad is a button).  On a normal touchpad, you can click by  
tapping.  It doesn't work that way on the macbook (although you can enable  
it).  It has the right feel IMO, so it doesn't require too much strength  
to drag and drop for instance (push pad down, then drag finger, then  
release).



That's the only problem I ever had with them (Well, that and accidentally
"clicking" with my palm while trying to type).


This can't happen unless you push the pad down with your palm.  And yes,  
that annoys me too on normal touchpads, you just get used to not touching  
the pad.



The physical buttons always
worked fine for me, I've never been much a fan of gestures anyway.


These aren't your standard gestures.  All the gestures use multiple  
fingers, so the activation of gestures depends on how many fingers you put  
down.  One finger *always* signifies moving the pointer.  There are no  
"hot zones" or accidental clicking.  It feels quite natural, and even  
though it's not quite intuitive (there is no intuitive way to map number  
of fingers to something), you get used to it pretty quick.  The scrolling  
is awesome.  Just lay your next finger down, and instantly you are  
scrolling.  I frequently find myself trying to do it on my other laptop  
only to be disappointed :)  To me, that is proof to myself that I like  
it...


If you can bring yourself to stomach the apple store atmosphere, I  
encourage you to visit one and try it out.  It's definitely different than  
any other interface I've ever used.


I do have a gripe about the mac system, however: the whole special key  
shit.  Control, Shift and Alt should be enough.  Why do we have option,  
and that funky clover key?  Not to mention that on every other system in  
the world, ctrl-c is copy ctrl-v is paste.  On apple it's that key  
formerly known as prince that does everything (and it's not in the same  
spot as normal control is either).  I have to look at the keyboard every  
time I want to do something like that.


As a bonus, they've left off the home, end, page up, and page down keys.   
Instead you use (yep, you guessed it) flower-key + arrow keys.  And the  
backspace key is labeled delete, and I still don't know how to do what a  
normal delete key would do (delete the character that follows the cursor)  
can someone tell me?


-Steve

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[bls]

On 01/25/2012 01:38 PM, Andrej Mitrovic wrote:

The Json parsing I've initially attempted was a mistake. I've assumed
the XML parsing would be harder than necessary, but I ended up
fighting wxPhp's arbitrary Json output (arrays holding objects of
different types.. which is no good for D, or my sanity).

Yesterday I've started working on xml parsing instead (using Vladimir
Panteelev's xml library) and now I have a full script that parses wx
doxygen files in pretty much the same way as the wxPhp script
(although the syntax is much nicer to work with).

I'm now in the process of testing the entire output to verify that
I've parsed the xml files correctly and loaded all the info in the
same way as wxPhp's xml script (basically I'm going to do some printf
diffs).

Once that is done I can begin working on porting the source_maker
script (obviously I can skip the Json part altogether since I have the
structures in memory already).


Andrej,
I can't await your SUCCESS message. For me your upcoming code is the 
most important stuff since years.
A few questions : where do I find Vladimir Panteelev's XML library ? 
Does this library support XPATH ?


Maybe it's too early but what do you think about replacing wxEvent with 
a D solution ?


I think about something similar to DGUI's event framework.  Same is 
valid for the wxWidgets sizer framework.


Enough now... Just want to say: Thanks man !

Re: using enums for flags

[foobar]

On Thursday, 26 January 2012 at 01:44:23 UTC, Marco Leise wrote:
Delphi: 
http://delphi.about.com/od/beginners/a/delphi_set_type.htm | 
Scroll to: "Sets with Enumerations"
Sets use the smallest integer type that can hold enough bits 
for the number of elements in an enum. So up to 8 enum flags 
use a byte for example. TDaySet in the example code would also 
be 1 byte in size. As the syntax suggests they don't implicitly 
convert forth or back to integers.


vote += MAX_INT for the above suggestion which btw is also the 
solution in Java 5.0 which provides an EnumSet type. At the 
moment eums are completely broken in D and IMO they are even 
worse that the unsafe C counterparts. C# is a lousy example here 
since its design is only very slightly better than the original C 
semantics.


I suggest looking into the Java implementation of Enum and 
EnumSet types which provides both type safety and convenience.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[David Nadlinger]

On 1/26/12 4:06 PM, Steven Schveighoffer wrote:

[…]And the
backspace key is labeled delete, and I still don't know how to do what a
normal delete key would do (delete the character that follows the
cursor) can someone tell me?


Fn + Backspace, on my Macbook Pro.

David

DStep

[bls]

Sorry for my ignorance but why should one use DStep instead of htod in 
order to port plain vanilla C headers ? I have to admit that I haven't 
tried DStep yet.

Did you try DStep on libxml2, respective libxslt ?

TIA,
Bjoern

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Steven Schveighoffer]

On Thu, 26 Jan 2012 10:20:38 -0500, David Nadlinger   
wrote:



On 1/26/12 4:06 PM, Steven Schveighoffer wrote:

[…]And the
backspace key is labeled delete, and I still don't know how to do what a
normal delete key would do (delete the character that follows the
cursor) can someone tell me?


Fn + Backspace, on my Macbook Pro.


Thank you :)  I will try it next time I use my macbook pro.  And I forgot  
about that Fn key!  Though that's pretty much standard on most laptops  
these days.


-Steve

Re: DStep

[Gour]

On Thu, 26 Jan 2012 07:19:27 -0800
bls  wrote:

> Sorry for my ignorance but why should one use DStep instead of htod
> in order to port plain vanilla C headers ? I have to admit that I
> haven't tried DStep yet.

Excuse me for my ignorance about DStep, but htod is Windows-only.


Sincerely,
Gour


-- 
A person who has given up all desires for sense gratification, 
who lives free from desires, who has given up all sense of 
proprietorship and is devoid of false ego — he alone can 
attain real peace.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: DStep

[Trass3r]

Sorry for my ignorance but why should one use DStep instead of 
htod in order to port plain vanilla C headers ? I have to 
admit that I haven't tried DStep yet.


htod is Windows-only.


And it sucks.
For example it drops const, runs the preprocessor instead of 
turning preprocessor directives into proper D equivalents, 
horribly messes up the comments (esp. comments for enum 
members),...

Re: strong enums: why implicit conversion to basetype?

[Trass3r]

Is there any merit in having implicit conversion to the 
basetype?


Yes. Otherwise it would be at least close to equivalence to a 
`typedef'.


Even typedef implicitly converts in one of the directions.
A named enum is a separate type with a finite set of allowed 
values defined by the user.

Re: DStep

[bls]

On 01/26/2012 07:51 AM, Trass3r wrote:

Sorry for my ignorance but why should one use DStep instead of htod
in order to port plain vanilla C headers ? I have to admit that I
haven't tried DStep yet.


htod is Windows-only.


And it sucks.
For example it drops const, runs the preprocessor instead of turning
preprocessor directives into proper D equivalents, horribly messes up
the comments (esp. comments for enum members),...


Ok,Thanks for clarification! Seems that DStep is a missing link in the D 
tool-chain and should be part of the DMD package
I'll try DStep ASAP on libxml2 and libxslt. Will let you know how it 
works for me.

Thanks, Bjoern

Re: DStep

[Trass3r]

Ok,Thanks for clarification! Seems that DStep is a missing link 
in the D tool-chain and should be part of the DMD package
I'll try DStep ASAP on libxml2 and libxslt. Will let you know 
how it works for me.


I don't think it's in a usable state yet.
I guess SWIG could be useful currently.

Re: using enums for flags

[Simen Kjærås]

On Thu, 26 Jan 2012 00:49:58 +0100, Trass3r  wrote:


In the codebase I have to work with, having the same enum specified in
different places is rather common. Yeah, I hate it. This means I might
have a filter defined using one enum, and the value to filter being a
different type with the same values.


Why don't you fix it then?


I'm not allowed to. The project I'm on has its tasks, and fixing things
in other projects is not one of them, especially when such an easy
workaround exists.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Andrei Alexandrescu]

On 1/26/12 10:41 AM, Steven Schveighoffer wrote:

On Thu, 26 Jan 2012 10:20:38 -0500, David Nadlinger 
wrote:


On 1/26/12 4:06 PM, Steven Schveighoffer wrote:

[…]And the
backspace key is labeled delete, and I still don't know how to do what a
normal delete key would do (delete the character that follows the
cursor) can someone tell me?


Fn + Backspace, on my Macbook Pro.


Thank you :) I will try it next time I use my macbook pro. And I forgot
about that Fn key! Though that's pretty much standard on most laptops
these days.

-Steve


Awesome tip, had no idea. Thanks David!

Andrei

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Sean Kelly]

My only gripe about the trackpad is that it's impossible to drag with the right 
button down. Beyond that, I actually like the control key setup on OSX, even if 
it isn't as comprehensive as Windows. The command key has a long history in the 
Unix world anyway. It's much better than the Windows key that just does one 
thing, and something I've never actually wanted to do. 

Sent from my iPhone

On Jan 26, 2012, at 7:06 AM, "Steven Schveighoffer"  wrote:

> On Wed, 25 Jan 2012 17:16:19 -0500, Nick Sabalausky  wrote:
> 
>> 
>> But how is just the basic "moving the pointer" compared to other touchpads?
> 
> It's similar.  The only thing is, the click is actually a physical button 
> (the whole pad is a button).  On a normal touchpad, you can click by tapping. 
>  It doesn't work that way on the macbook (although you can enable it).  It 
> has the right feel IMO, so it doesn't require too much strength to drag and 
> drop for instance (push pad down, then drag finger, then release).
> 
>> That's the only problem I ever had with them (Well, that and accidentally
>> "clicking" with my palm while trying to type).
> 
> This can't happen unless you push the pad down with your palm.  And yes, that 
> annoys me too on normal touchpads, you just get used to not touching the pad.
> 
>> The physical buttons always
>> worked fine for me, I've never been much a fan of gestures anyway.
> 
> These aren't your standard gestures.  All the gestures use multiple fingers, 
> so the activation of gestures depends on how many fingers you put down.  One 
> finger *always* signifies moving the pointer.  There are no "hot zones" or 
> accidental clicking.  It feels quite natural, and even though it's not quite 
> intuitive (there is no intuitive way to map number of fingers to something), 
> you get used to it pretty quick.  The scrolling is awesome.  Just lay your 
> next finger down, and instantly you are scrolling.  I frequently find myself 
> trying to do it on my other laptop only to be disappointed :)  To me, that is 
> proof to myself that I like it...
> 
> If you can bring yourself to stomach the apple store atmosphere, I encourage 
> you to visit one and try it out.  It's definitely different than any other 
> interface I've ever used.
> 
> I do have a gripe about the mac system, however: the whole special key shit.  
> Control, Shift and Alt should be enough.  Why do we have option, and that 
> funky clover key?  Not to mention that on every other system in the world, 
> ctrl-c is copy ctrl-v is paste.  On apple it's that key formerly known as 
> prince that does everything (and it's not in the same spot as normal control 
> is either).  I have to look at the keyboard every time I want to do something 
> like that.
> 
> As a bonus, they've left off the home, end, page up, and page down keys.  
> Instead you use (yep, you guessed it) flower-key + arrow keys.  And the 
> backspace key is labeled delete, and I still don't know how to do what a 
> normal delete key would do (delete the character that follows the cursor) can 
> someone tell me?
> 
> -Steve

Re: HELP! DMD Asserts while generating DI files.

[Adam Wilson]

On Thu, 26 Jan 2012 06:33:12 -0800, kenji hara  wrote:


What version do you use?
In 2.058head(commit f8887855), `dmd -H -c test.d` succeeds to compile
without DMD assertion.

Kenji Hara

2012/1/23 Adam Wilson :
Does anyone have any idea why DMD would assert with the following  
assert on

this code while building the druntime during DI generation?

Generating This DI file...
// D import file generated from 'src\core\bitop.d'
module core.bitop;
nothrow
{
   pure int bsf(size_t v);

   pure int bsr(size_t v);

   pure int bt(in size_t* p, size_t bitnum);

   int btc(size_t* p, size_t bitnum);
   int btr(size_t* p, size_t bitnum);
   int bts(size_t* p, size_t bitnum);
   pure uint bswap(uint v);

   ubyte inp(uint port_address);
   ushort inpw(uint port_address);
   uint inpl(uint port_address);
   ubyte outp(uint port_address, ubyte value);
   ushort outpw(uint port_address, ushort value);
   uint outpl(uint port_address, uint value);
   int popcnt(uint x);
   debug (UnitTest)
   {
   }
   uint bitswap(uint x);
   debug (UnitTest)
   {
   }
}

produces this assert in DMD: assert cast.c(2082) t1->ty == t2->ty
which appears to be the typeMerge function in cast.c

It doesn't do this on all DI files and I am at a loss as to any rhyme or
reason for when it does assert. Perhaps someone with knowledge of the
compiler internals could be of help...

Any ideas would be very helpful!

--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/


Hi Kenji,

It appears to be a problem related to my DI generation patch. But I don't  
know near enough about cast.c to reduce the problem quickly, my guess is  
that druntime and phobos are excepting something to exist in the DI that  
the patch strips out, but that's only a guess. As you can see, the DI file  
itself is generated without any errors, this assert seems to come  
afterwards. Does D export the .DI file then try to use it during  
compilation of the .D file?


--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: MS extend C++ significantly for Windows8... and Andrei got name drop

[Adam Wilson]

On Thu, 26 Jan 2012 00:30:14 -0800, Manu  wrote:


On 26 January 2012 03:15, Adam Wilson  wrote:


On Wed, 25 Jan 2012 15:05:43 -0800, Manu  wrote:

 On 26 January 2012 00:55, Adam Wilson  wrote:


 On Wed, 25 Jan 2012 14:44:09 -0800, Manu  wrote:


 On 26 January 2012 00:37, Adam Wilson  wrote:



 On Wed, 25 Jan 2012 14:28:46 -0800, Manu   
wrote:




 On 25 January 2012 23:59, Adam Wilson  wrote:



 On Wed, 25 Jan 2012 13:35:38 -0800, Manu 
wrote:



 On 25 January 2012 21:47, bls  wrote:


  On 01/25/2012 07:03 AM, Manu wrote:



  This is fairly interesting. MS have extended their C++ compiler


 significantly for Windows8 with a bunch of non-standard stuff.


FINALLY implement garbage collection, ref counting, properties,
delegates, events, generics, etc...
If other compilers adopt this tech, D loses some advantages.


 But you still have to fight with ifndef ,forward declaration,
and a

 template syntax against common sense.  Even if you paint shit

yellow
it's
not necessarily gold.


 True, but I think this will mitigate a lot of the motivation
Windows

 devs

have to seek another language if they're not developing cross
platform
apps.

Sadly, since WinRT requires using these language extensions to
interface
with the new windows runtime, you won't be able to write a  
Windows8

app
in
D.
Interestingly though, D supports almost everything they've added  
to

C++. I
wonder if it would be possible to do extern(Windows8) to produce  
a

compatible ABI for linking with MS C++ apps?

The most interesting features are 'ref new' and 'gcnew', which  
makes

me
wonder, since Windows8 has an OS garbage collector, would it be  
at

all
possible to have D use the Windows8 GC? I'd prefer this to using  
D's

own
GC
if it would be supported, and obviously this would be a  
requirement

if D
was going to interact with WinRT properly.
Also, WinRT uses 'ref new' to allocate ref counted (effectively  
COM

to
my
understanding) objects. I think I read somewhere that D already  
has

extern(COM) no? I wonder if Windows8 ref type linkage is already
technically supported in D?


 There is no Win8GC, it's all ref counted. WinRT is COM with  
extras



and as
such should be accessible to D. It would need some extra glue code
over
what we have now ... like the IInspectable interface.


 Really? So what's 'gcnew' for?




 That's for targeting the CLR (.NET) so it doesn't conflict with

new/delete
in regular C++. It goes all the way back to the first C++/CLI in  
Visual

Studio 2005.
http://msdn.microsoft.com/en-**us/library/te3ecsc8.aspx
http://msdn.microsoft.com/en-**us/library/te3ecsc8.aspx>
>
http://msdn.microsoft.com/en-us/**library/te3ecsc8.aspx>
<**http://msdn.microsoft.com/en-**us/library/te3ecsc8.aspx
>
>




So there is a GC... It just happens to be the .net GC. Is that a
problem?
Obviously it's accessible in C++ code. Can you use it to allocate C++
objects, or is it exclusively for some sort of interaction with .net?
If the rest of the platform is using it...


It's exclusively for the .NET Framework and requires the .NET  
Framework

to
be installed and loaded to run. It's the .NET Runtime, and as such, it
would be VERY unwise to base anything D on it.




.NET will be a requirement on all Win8 machines. You didn't answer  
though,

can you use the .NET GC to allocate C++ objects to use throughout your
native program? Or is gcnew strictly for interfacing C++ with .NET,  
like

C++/CLI?



It is strictly for allocating .NET objects. You CANNOT allocate C++
objects with the .NET GC, that was implied by the statement on the use  
of

the .NET GC.



I see, well that's good. I presume then that it shouldn't be too much
trouble to implement MS C++'s ref type ABI in D then if it is just
basically COM.
How about 'delegate'? Would it be trouble to make the extern ABI  
compatible

when passing delegates between MSC++/D?


Theoretically, it wouldn't be to hard, getting Walter to do it however ...

--
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: strong enums: why implicit conversion to basetype?

[Manfred Nowak]

Trass3r wrote:


> Even typedef implicitly converts in one of the directions.

`typedef' is or will be disallowed in D because of reasons I do not 
understand. In C and C++ their existence introduce problems because 
they increase the amount of parsing passes. 


> A named enum is a separate type with a finite set of allowed 
> values defined by the user.
A)
Both wrong according to the currently published reference:

1) "The enum EnumTag declares a new type, and all the EnumMembers have 
that type.", i.e. it is the tag not the hole enum that produces a new 
type. 
2) "Enum declarations are used to define a group of constants.", i.e. 
only some of the valid values of the basetype are given names. All of 
the valid values of the basetype are also valid in the type declared 
by the tag.
3) "An EmptyEnumBody signifies an opaque enum - the enum members are 
unknown", i.e. none of the valied values of the basetype has got a 
name, but all valid values of the basetype are also valid in the type 
declared by the tag.

B)
It is somehow difficult to write about the reference because the use 
of the terms declaration, definition or declaration follows rules, 
which I have not yet detected.

I use "declaration" for any entity, which is undefined at the current 
position of reading _and_ will be defined after that position is 
passed. This is often an identifier in D.  

I use "definition" for any entity, which represents the content of the 
transition from undefined to defined. This is often a type in D. 

I use "specification" for those two entities, which represents a 
binding between a declaration and a definition. This is often the 
absence of operators in D.

-manfred

Re: strong enums: why implicit conversion to basetype?

[Timon Gehr]

On 01/26/2012 02:59 PM, Trass3r wrote:

I thought it'd be good to outsource this question from the other thread
about enums as flags.

Is there any merit in having implicit conversion to the basetype?
Imo it only introduces a severe bug source and brings no advantages.

For example it allows implicit conversion to bool.

enum Bla
{
S1 = 1,
S2,
S3
}
if (Bla.S2) // makes no sense at all, all Blas convert to true
// and if S1 was 0, it would mean false, but it isn't meant as a special
member!


That is not an implicit conversion. if(x) is equivalent to if(cast(bool)x).




A better example is something like
if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
silently pass


In general it allows operations that don't make any sense.

if (Bla.S2 & Blub.S1) // works cause an int is produced
// but by using named enums I made clear that Bla and Blub are totally
different

Heck even +,-,... work.

Remember that if you do need to do such crazy stuff you can still
explicitly cast to int or whatever.


I have argued for banning those operations on strong enums before, but 
some objected to it because they wanted to use strong enums as bit flags.

Re: public aliases to private/package symbols

[Martin Nowak]

The issue is not with aliases, accessability already has a natural grey
area:


module lib;

private struct Foo {}

// Should any of these be allowed?
public Foo getFoo() { return Foo(); }
public void takeFoo(Foo f) {}
struct Bar
{
Foo f;
}

--

module main;
import lib;

getFoo();  // Allowed?

takeFoo(getFoo());  // Allowed?

Bar b;  // Allowed?

takeFoo(b.f);   // Allowed?

b.f = getFoo();   // Allowed?

// Allowed? If so, can you *do* anything with x?
auto x = getFoo();




The solution seems to be to check protection only during symbol lookup.
Thus all of the above are allowed and you can do with x what Foo allows  
you to

(aggregates default to public protection).

Re: Windows API and druntime/Phobos

[Jacob Carlborg]

On 2012-01-26 15:46, Manu wrote:

On 26 January 2012 16:45, Manu mailto:turkey...@gmail.com>> wrote:

On 26 January 2012 16:33, Marco Leise mailto:marco.le...@gmx.de>> wrote:

Am 26.01.2012, 05:08 Uhr, schrieb Brad Roberts
mailto:bra...@puremagic.com>>:

On 1/24/2012 8:48 PM, Jonathan M Davis wrote:

The level of support for the Windows API in druntime and
Phobos is pretty low.
As I understand it, Windows users are pretty much forced
to use
http://www.dsource.org/__projects/bindings/browser/__trunk/win32

if they need
comprehensive Win32 API bindings. druntime seems to be
trying to define all of
the OS-specific stuff like that, but on top of it
missing much of it, in the
case of the Win32 API, that's a _lot_ of functions, and
I don't know if we
want to put that much in druntime. So, the question is,
how do we want to
support the Win32 API in druntime and Phobos?

Do we want to put all of the Win32 API bindings in
druntime? If not, then do
we want to put them in Phobos? Or do we just want to
send Windows developers
to a 3rd party library like the Win32 bindings project
on dsource? Given that
they're OS bindings, I would _think_ that we'd want them
in druntime, but I
don't know.

Regardless, this is one of those issues which frequently
plagues D Windows
developers, and we really should at least get a plan
together as to how we
want to handle it.

- Jonathan M Davis


P.S. A related pull request:
https://github.com/D-__Programming-

Language/druntime/pull/139


We've got the posix api set in the runtime, not just the
subset that the runtime or phobos needs.  IMHO, windows should
follow that pattern.  It might be large from a number of
lines of declarations standpoint, but who cares.


I tend to agree.


I wouldn't object to having guaranteed access to winapi in
druntime... but it is pretty big. In the interest of following the
pattern with posix, it makes sense to me.
But I'm also not allergic to it being a completely separate library,
as long as it's distributed with the windows toolchain. I probably
wouldn't want to see it in std, that makes no sense to me. druntime
makes some sense (since parts of druntime depend on windows calls)
if people think that's where it should be.

What is the reasoning for putting the posix api in druntime? That
seems like a weird choice to me... it's nothing to do with druntime,
except for a couple of dependencies perhaps.


Also, WinRT is upon us... I intend to start writing WinRT programs asap.
Ahould that go in druntime too? Are we opening a floodgate?


BTW, we don't have any OS specific bindings for OSes that also have 
Posix bindings. I thinking mostly on Mac OS X, don't know if the other 
OSes have anything useful.


--
/Jacob Carlborg

Re: DStep

[Jacob Carlborg]

On 2012-01-26 17:18, Trass3r wrote:

Ok,Thanks for clarification! Seems that DStep is a missing link in the
D tool-chain and should be part of the DMD package
I'll try DStep ASAP on libxml2 and libxslt. Will let you know how it
works for me.


I don't think it's in a usable state yet.
I guess SWIG could be useful currently.


No, it's not in very usable state currently. The Clang modifications are 
somewhat usable: https://github.com/jacob-carlborg/clang


--
/Jacob Carlborg

Re: DStep

[Jacob Carlborg]

On 2012-01-26 16:41, Gour wrote:

On Thu, 26 Jan 2012 07:19:27 -0800
bls  wrote:


Sorry for my ignorance but why should one use DStep instead of htod
in order to port plain vanilla C headers ? I have to admit that I
haven't tried DStep yet.


Excuse me for my ignorance about DStep, but htod is Windows-only.


Exactly, dstep could work on any platform supported by Clang and D.

--
/Jacob Carlborg

Re: DStep

[Jacob Carlborg]

On 2012-01-26 17:08, bls wrote:

On 01/26/2012 07:51 AM, Trass3r wrote:

Sorry for my ignorance but why should one use DStep instead of htod
in order to port plain vanilla C headers ? I have to admit that I
haven't tried DStep yet.


htod is Windows-only.


And it sucks.
For example it drops const, runs the preprocessor instead of turning
preprocessor directives into proper D equivalents, horribly messes up
the comments (esp. comments for enum members),...


Ok,Thanks for clarification! Seems that DStep is a missing link in the D
tool-chain and should be part of the DMD package
I'll try DStep ASAP on libxml2 and libxslt. Will let you know how it
works for me.
Thanks, Bjoern


DStep has nothing to do with XML. It uses the Clang C API to create D 
bindings.


--
/Jacob Carlborg

Re: DStep

[bls]

On 01/26/2012 09:51 AM, Jacob Carlborg wrote:

On 2012-01-26 17:08, bls wrote:

On 01/26/2012 07:51 AM, Trass3r wrote:

Sorry for my ignorance but why should one use DStep instead of htod
in order to port plain vanilla C headers ? I have to admit that I
haven't tried DStep yet.


htod is Windows-only.


And it sucks.
For example it drops const, runs the preprocessor instead of turning
preprocessor directives into proper D equivalents, horribly messes up
the comments (esp. comments for enum members),...


Ok,Thanks for clarification! Seems that DStep is a missing link in the D
tool-chain and should be part of the DMD package
I'll try DStep ASAP on libxml2 and libxslt. Will let you know how it
works for me.
Thanks, Bjoern


DStep has nothing to do with XML. It uses the Clang C API to create D
bindings.



libxml2 is a plain c library
http://xmlsoft.org/

libxslt dito.
http://xmlsoft.org/XSLT/

?? May you mix it up. In order to create *bindings* to C++ libs doxygens 
xml output seems to be perfect.


To _port_ C headers DStep is probaly the right tool. But I just see that 
I have to build llvm and what the heck.. :(


Now, in order to parse doxygens xml output std.xml is not good enough. 
In other words it would be nice to have libxml2 as D lib available.

Re: enum scope

[Gor Gyolchanyan]

That would break the independence between parser and semantic
analyzer, because there's no way to disambiguate "bar" from "Foo.bar"
without knowing, that "Foo" is actually an enum.

On Thu, Jan 26, 2012 at 5:41 PM, Jacob Carlborg  wrote:
> On 2012-01-26 14:23, Trass3r wrote:
>>>
>>> It's not type safe in C. But you can wrap it in a struct with alias
>>> this instead.
>>
>>
>> Yep, but in D we have strong enums, so why not use them.
>
>
> What about be able to do something like this:
>
> enum Foo
> {
> public:
>    bar,
>    fooBar,
> }
>
> Foo f = bar;
>
> --
> /Jacob Carlborg



-- 
Bye,
Gor Gyolchanyan.

Re: Do we need Win95/98/Me support?

[Martin Nowak]

We need a decision on this topic.

Actively maintaining support for new features?

Cleaning out Win9x code?

Re: Do we need Win95/98/Me support?

[Jonathan M Davis]

On Thursday, January 26, 2012 19:21:53 Martin Nowak wrote:
> We need a decision on this topic.
> 
> Actively maintaining support for new features?
> 
> Cleaning out Win9x code?
 
There doesn't seem to be much support for continuing support of Win9x code, so 
I think that we're going to axe it. I believe that the main reason that we've
had the Win9x support in the past is because Walter wanted it, and he's not
against removing it now - if nothing else because we don't have a way to test
it. Certainly, if the pull requests for removing Win9x support are solid, I'll
probably merge them in. I'd prefer that some Windows devs look at them first
though.

- Jonathan M Davis

Re: enum scope

[Timon Gehr]

On 01/26/2012 07:21 PM, Gor Gyolchanyan wrote:

That would break the independence between parser and semantic
analyzer, because there's no way to disambiguate "bar" from "Foo.bar"
without knowing, that "Foo" is actually an enum.



No, it would not. The parser does not have to care.


On Thu, Jan 26, 2012 at 5:41 PM, Jacob Carlborg  wrote:

On 2012-01-26 14:23, Trass3r wrote:


It's not type safe in C. But you can wrap it in a struct with alias
this instead.



Yep, but in D we have strong enums, so why not use them.



What about be able to do something like this:

enum Foo
{
public:
bar,
fooBar,
}

Foo f = bar;

--
/Jacob Carlborg

Re: enum scope

[Timon Gehr]

On 01/26/2012 02:41 PM, Jacob Carlborg wrote:

On 2012-01-26 14:23, Trass3r wrote:

It's not type safe in C. But you can wrap it in a struct with alias
this instead.


Yep, but in D we have strong enums, so why not use them.


What about be able to do something like this:

enum Foo
{
public:
bar,
fooBar,
}

Foo f = bar;



public is the wrong keyword. Furthermore, the solution is not better 
than mixin Import!Foo; I think the extern(C) enum proposal is pragmatic 
and makes more sense.

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[Jesse Phillips]

On Thursday, 26 January 2012 at 15:13:57 UTC, bls wrote:


Andrej,
I can't await your SUCCESS message. For me your upcoming code 
is the most important stuff since years.
A few questions : where do I find Vladimir Panteelev's XML 
library ? Does this library support XPATH ?


I don't know anything about Vladimir's parser, I've just been 
using xmlp, which has xpath though I have have not used. Xmlp has 
gone through some breaking changes recently as I've been 
submitting bugs.


http://www.dsource.org/projects/xmlp/browser/trunk/std

Re: strong enums: why implicit conversion to basetype?

[deadalnix]

Le 26/01/2012 14:59, Trass3r a écrit :

I thought it'd be good to outsource this question from the other thread
about enums as flags.

Is there any merit in having implicit conversion to the basetype?
Imo it only introduces a severe bug source and brings no advantages.

For example it allows implicit conversion to bool.

enum Bla
{
S1 = 1,
S2,
S3
}
if (Bla.S2) // makes no sense at all, all Blas convert to true
// and if S1 was 0, it would mean false, but it isn't meant as a special
member!

A better example is something like
if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
silently pass


In general it allows operations that don't make any sense.

if (Bla.S2 & Blub.S1) // works cause an int is produced
// but by using named enums I made clear that Bla and Blub are totally
different

Heck even +,-,... work.

Remember that if you do need to do such crazy stuff you can still
explicitly cast to int or whatever.


I don't see any problem with that : it is perfectly safe. The other way 
around isn't and isn't allowed, so the current behaviour seems fine to me.

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[Jonathan M Davis]

On Thursday, January 26, 2012 19:44:18 Jesse Phillips wrote:
> On Thursday, 26 January 2012 at 15:13:57 UTC, bls wrote:
> > Andrej,
> > I can't await your SUCCESS message. For me your upcoming code
> > is the most important stuff since years.
> > A few questions : where do I find Vladimir Panteelev's XML
> > library ? Does this library support XPATH ?
> 
> I don't know anything about Vladimir's parser, I've just been
> using xmlp, which has xpath though I have have not used. Xmlp has
> gone through some breaking changes recently as I've been
> submitting bugs.
> 
> http://www.dsource.org/projects/xmlp/browser/trunk/std

xmlp is the one that Tomaz is working on to replace std.xml, correct? Any idea 
how close it is to actually being submitted for review?

- Jonathan M Davis

Re: strong enums: why implicit conversion to basetype?

[Trass3r]

I have argued for banning those operations on strong enums before, but  
some objected to it because they wanted to use strong enums as bit flags.


Yep, that's what the other thread 'using enums for flags' is about.
But implicit conversions seem wrong in any case.

Re: strong enums: why implicit conversion to basetype?

[Trass3r]

`typedef' is or will be disallowed in D because of reasons I do not
understand.


It's ill-defined. There are 4 possible types of typedef:  
http://d.puremagic.com/issues/show_bug.cgi?id=5467



In C and C++ their existence introduce problems because
they increase the amount of parsing passes.


C's typedef is equal to D's alias.


A named enum is a separate type with a finite set of allowed
values defined by the user.

A)
Both wrong according to the currently published reference:


Again, this thread is all about discussing the right way to do it and not  
about what the buggy and holey spec reads.


2) "Enum declarations are used to define a group of constants.", i.e. 
only some of the valid values of the basetype are given names. All ofthe  
valid values of the basetype are also valid


That's what anonymous enums are for.


3) "An EmptyEnumBody signifies an opaque enum - the enum members are
unknown", i.e. none of the valied values of the basetype has got a
name, but all valid values of the basetype are also valid in the type
declared by the tag.


So the only purpose is to create a new type similar to typedef.
I don't see any merit in that.

Re: enum scope

[Trass3r]

What about be able to do something like this:

enum Foo
{
public:
bar,
fooBar,
}

Foo f = bar;



public is the wrong keyword. Furthermore, the solution is not better  
than mixin Import!Foo; I think the extern(C) enum proposal is pragmatic  
and makes more sense.


+1

Re: enum scope

[Trass3r]

If your binding is for yourself, that's not a big deal. But if you're  
putting it out there for public consumption, then I think compatibility  
with the C version would be more important. If someone is looking at  
sample C code, you should make it they don't need to adjust it much


Yep, one big argument for my proposal.

Re: DStep

[Jacob Carlborg]

On 2012-01-26 19:08, bls wrote:

On 01/26/2012 09:51 AM, Jacob Carlborg wrote:

On 2012-01-26 17:08, bls wrote:

On 01/26/2012 07:51 AM, Trass3r wrote:

Sorry for my ignorance but why should one use DStep instead of htod
in order to port plain vanilla C headers ? I have to admit that I
haven't tried DStep yet.


htod is Windows-only.


And it sucks.
For example it drops const, runs the preprocessor instead of turning
preprocessor directives into proper D equivalents, horribly messes up
the comments (esp. comments for enum members),...


Ok,Thanks for clarification! Seems that DStep is a missing link in the D
tool-chain and should be part of the DMD package
I'll try DStep ASAP on libxml2 and libxslt. Will let you know how it
works for me.
Thanks, Bjoern


DStep has nothing to do with XML. It uses the Clang C API to create D
bindings.



libxml2 is a plain c library
http://xmlsoft.org/

libxslt dito.
http://xmlsoft.org/XSLT/

?? May you mix it up. In order to create *bindings* to C++ libs doxygens
xml output seems to be perfect.

To _port_ C headers DStep is probaly the right tool. But I just see that
I have to build llvm and what the heck.. :(

Now, in order to parse doxygens xml output std.xml is not good enough.
In other words it would be nice to have libxml2 as D lib available.


Oh, you mean create bindings to libxml2?

I don't see how doxygen xml output could be better to create bindings 
than a compiler.


Tango has a pretty good and super fast XML module. Tango is now usable 
with D2: https://github.com/SiegeLord/Tango-D2


--
/Jacob Carlborg

Re: strong enums: why implicit conversion to basetype?

[Don]

On 26.01.2012 14:59, Trass3r wrote:

I thought it'd be good to outsource this question from the other thread
about enums as flags.

Is there any merit in having implicit conversion to the basetype?


Allowing it to be used as an argument when calling C functions?

Without it, how would you support eg the Windows API?

Re: Message-Passing

[Sean Kelly]

On Jan 25, 2012, at 2:49 AM, Manu wrote:

> On 23 January 2012 02:00, Timon Gehr  wrote:
> Erlang *has* been used in multiple large projects and it is likely that you 
> make use of some service that is powered by erlang on a daily basis. It is 
> successful in its niche. Copying its message passing API is reasonable and 
> safe: Its concurrency model is the main selling point of erlang.
> 
> http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
> 
> Oh come on.. It's niche, unfamiliar to most people, and we're talking about 
> name and argument list clarity with respect to what would be instinctive to 
> the most users, not 'model' or API design, that's obviously fine.

Personally, I expected receiveOnly to see infrequent use compared to receive.  
At least in my own code, it's rare that I'd want a receive call to throw if 
there's any message in the queue other than the one I'm looking for.  So the 
naming scheme was a mistaken assumption of popular use.


> C# is awesome because it gets this right. I think that's its single
> greatest achievement, and can not be understated.
> 
> 
> I couldn't find any information about a C# API for the same functionality. 
> Can you help me out?
> 
> I'm not referring to this API in particular, I'm referring to the fairly 
> universal application of the principle within the C# libraries. Most people 
> I've ever talked to agree that one of it's biggest selling points, and 
> possibly even the key reason they use it; because it was so accessible and 
> productive from the instant they tried it out.
> You shouldn't need to read anything. Pressing '.' in the IDE shows lists of 
> classes/methods/etc, and common sense writes your code. This requires that 
> the function names make perfect sense, and the argument lists are as you 
> intuitively expect.
> 
> If I: send(tid, myThing);
> I expect to: myThing = receive!SomeThing();
> 
> How can you argue that it's not intuitive to receive what you sent?

We could overload receive even more so that if it has only one argument and 
that argument is not a callable type, it does receiveOnly.  That might be 
deceptive however.  What I like about "receiveOnly" is that the name itself 
suggests that anything other than the specified type is not expected, and so 
some measure will probably be taken.  receive!T says to me "look for a message 
of this type and block if it's not present."


> There's nothing in: send(tid, something); that suggests the expected 
> compliment API should take a var-arg list of undefined things. It's not clear 
> from receive()'s signature that it should receive delegates, it looks like it 
> could receive anything. The delegate signature is un-knowable from the 
> functions own signature, nor what the delegates are even supposed to do.

This is an artifact of templates.  I doubt C# has this issue because C# doesn't 
have templates.


> Also, the name 'receiveOnly' doesn't actually make sense unless you *already 
> know* that receive() is effectively receiveMulti. If I was scrolling through 
> the pop-up list of methods, I would not confidently predict what that does.

Matter of opinion I suppose.  See above.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Don]

On 26.01.2012 00:36, Walter Bright wrote:

On 1/25/2012 2:27 PM, Vladimir Panteleev wrote:

How about these?

http://images.google.com/search?q=download&tbm=isch&tbs=isz:i


You're in a maze of twisty passages, all different.


The first ones look as though they're showing you where the secret 
button on the hard disk is.


> download
You have walked into the slavering fangs of a lurking grue!

Re: Message-Passing

[Timon Gehr]

On 01/26/2012 09:07 PM, Sean Kelly wrote:

On Jan 25, 2012, at 2:49 AM, Manu wrote:


On 23 January 2012 02:00, Timon Gehr  wrote:
Erlang *has* been used in multiple large projects and it is likely that you 
make use of some service that is powered by erlang on a daily basis. It is 
successful in its niche. Copying its message passing API is reasonable and 
safe: Its concurrency model is the main selling point of erlang.

http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang

Oh come on.. It's niche, unfamiliar to most people, and we're talking about 
name and argument list clarity with respect to what would be instinctive to the 
most users, not 'model' or API design, that's obviously fine.


Personally, I expected receiveOnly to see infrequent use compared to receive.  
At least in my own code, it's rare that I'd want a receive call to throw if 
there's any message in the queue other than the one I'm looking for.  So the 
naming scheme was a mistaken assumption of popular use.



It is not necessarily a mistaken assumption. I still assume it.

Re: strong enums: why implicit conversion to basetype?

[Trass3r]

Is there any merit in having implicit conversion to the basetype?


Allowing it to be used as an argument when calling C functions?


extern(C):
enum Bla : int {...}
void foo(Bla b);

How does this require implicit conversion?
The codegen treats Bla like basetype anyway.

Re: Message-Passing

[Manu]

On 26 January 2012 22:07, Sean Kelly  wrote:

> On Jan 25, 2012, at 2:49 AM, Manu wrote:
>
> > On 23 January 2012 02:00, Timon Gehr  wrote:
> > Erlang *has* been used in multiple large projects and it is likely that
> you make use of some service that is powered by erlang on a daily basis. It
> is successful in its niche. Copying its message passing API is reasonable
> and safe: Its concurrency model is the main selling point of erlang.
> >
> >
> http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
> >
> > Oh come on.. It's niche, unfamiliar to most people, and we're talking
> about name and argument list clarity with respect to what would be
> instinctive to the most users, not 'model' or API design, that's obviously
> fine.
>
> Personally, I expected receiveOnly to see infrequent use compared to
> receive.  At least in my own code, it's rare that I'd want a receive call
> to throw if there's any message in the queue other than the one I'm looking
> for.  So the naming scheme was a mistaken assumption of popular use.
>

Well perhaps my usage is biased, but I think many/most threads are spawned
with the intent of receiving one particular workload from one source. I
think a thread that receives a variable/dynamic workload is probably less
common, although certainly does exist, but regardless of that, from the
point of view of API design, I don't think the API clearly communicates
that intent. It certainly had me scratching my head until I _read the
docs_, which is the basis of my argument.
If I'm wrong on that point, then there's nothing to argue :)

(bear in mind, this isn't the only thing I mentioned in my OP. As with
prior posts where I've made the mistake of listing things, the the single
most trivial detail in my list is the one that spawns the longest
conversation ;)

> C# is awesome because it gets this right. I think that's its single
> > greatest achievement, and can not be understated.
> >
> >
> > I couldn't find any information about a C# API for the same
> functionality. Can you help me out?
> >
> > I'm not referring to this API in particular, I'm referring to the fairly
> universal application of the principle within the C# libraries. Most people
> I've ever talked to agree that one of it's biggest selling points, and
> possibly even the key reason they use it; because it was so accessible and
> productive from the instant they tried it out.
> > You shouldn't need to read anything. Pressing '.' in the IDE shows lists
> of classes/methods/etc, and common sense writes your code. This requires
> that the function names make perfect sense, and the argument lists are as
> you intuitively expect.
> >
> > If I: send(tid, myThing);
> > I expect to: myThing = receive!SomeThing();
> >
> > How can you argue that it's not intuitive to receive what you sent?
>
> We could overload receive even more so that if it has only one argument
> and that argument is not a callable type, it does receiveOnly.  That might
> be deceptive however.


I agree that's a pretty ugly approach. I can see your point, but it only
makes sense to me with advanced knowledge of the API. If I approach it
without that insight, as I did, it's not so clear, or even misleading.
Consider the position you're likely to be when you reach for the API,
trying to use it for the first time, and you've just typed: send(tid,
myThing) not 10 seconds prior... what do you expect to type next?


> What I like about "receiveOnly" is that the name itself suggests that
> anything other than the specified type is not expected, and so some measure
> will probably be taken.


Again, this only makes sense to me if you already expect that the act of
receiving (as a compliment to the send API, which you've already invoked
and have a presumption about), was capable of receiving any/multiple
things, rather than receiving what you just sent a few lines back...

 receive!T says to me "look for a message of this type and block if it's
> not present."
>

Perfect. It says that to me too. I'm lost now though, this is the behaviour
of receiveOnly... are you agreeing now? :)

> There's nothing in: send(tid, something); that suggests the expected
> compliment API should take a var-arg list of undefined things. It's not
> clear from receive()'s signature that it should receive delegates, it looks
> like it could receive anything. The delegate signature is un-knowable from
> the functions own signature, nor what the delegates are even supposed to do.
>
> This is an artifact of templates.  I doubt C# has this issue because C#
> doesn't have templates.
>

C# has generics. Not quite like D templates, more like C++, but still...
But in a case like this, such an apparently arguably ambiguous API wouldn't
be permitted. It would be restructured, or the competing API's both renamed
to something more clear.

> Also, the name 'receiveOnly' doesn't actually make sense unless you
> *already know* that receive() is effectively receiveMulti. If I was
> sc

Re: Windows API and druntime/Phobos

[Marco Leise]

Am 26.01.2012, 18:47 Uhr, schrieb Jacob Carlborg :


On 2012-01-26 15:46, Manu wrote:

On 26 January 2012 16:45, Manu mailto:turkey...@gmail.com>> wrote:

On 26 January 2012 16:33, Marco Leise mailto:marco.le...@gmx.de>> wrote:

Am 26.01.2012, 05:08 Uhr, schrieb Brad Roberts
mailto:bra...@puremagic.com>>:

On 1/24/2012 8:48 PM, Jonathan M Davis wrote:

The level of support for the Windows API in druntime and
Phobos is pretty low.
As I understand it, Windows users are pretty much forced
to use
http://www.dsource.org/__projects/bindings/browser/__trunk/win32

if they need
comprehensive Win32 API bindings. druntime seems to be
trying to define all of
the OS-specific stuff like that, but on top of it
missing much of it, in the
case of the Win32 API, that's a _lot_ of functions, and
I don't know if we
want to put that much in druntime. So, the question is,
how do we want to
support the Win32 API in druntime and Phobos?

Do we want to put all of the Win32 API bindings in
druntime? If not, then do
we want to put them in Phobos? Or do we just want to
send Windows developers
to a 3rd party library like the Win32 bindings project
on dsource? Given that
they're OS bindings, I would _think_ that we'd want them
in druntime, but I
don't know.

Regardless, this is one of those issues which frequently
plagues D Windows
developers, and we really should at least get a plan
together as to how we
want to handle it.

- Jonathan M Davis


P.S. A related pull request:
https://github.com/D-__Programming-

Language/druntime/pull/139


We've got the posix api set in the runtime, not just the
subset that the runtime or phobos needs.  IMHO, windows  
should

follow that pattern.  It might be large from a number of
lines of declarations standpoint, but who cares.


I tend to agree.


I wouldn't object to having guaranteed access to winapi in
druntime... but it is pretty big. In the interest of following the
pattern with posix, it makes sense to me.
But I'm also not allergic to it being a completely separate library,
as long as it's distributed with the windows toolchain. I probably
wouldn't want to see it in std, that makes no sense to me. druntime
makes some sense (since parts of druntime depend on windows calls)
if people think that's where it should be.

What is the reasoning for putting the posix api in druntime? That
seems like a weird choice to me... it's nothing to do with druntime,
except for a couple of dependencies perhaps.


Also, WinRT is upon us... I intend to start writing WinRT programs asap.
Ahould that go in druntime too? Are we opening a floodgate?


BTW, we don't have any OS specific bindings for OSes that also have  
Posix bindings. I thinking mostly on Mac OS X, don't know if the other  
OSes have anything useful.


That's because you can get away with only using Posix on Mac OS X. If the  
situation was like on Windows, druntime would have to bind to the Mac OS X  
API as well. So I don't think this is a good counter argument. My thoughts  
are just: 2 places for the same thing are bad, druntime already depends on  
it => put it there.

Re: Message-Passing

[Timon Gehr]

On 01/26/2012 10:19 PM, Manu wrote:


C# has generics. Not quite like D templates, more like C++, but still...


C# generics and C++/D templates are *very* different things. C# generics 
make code type check (and duplicate static variables), templates 
duplicate the whole code. C# does not have anything like templates.


Templates have the benefit that they are a lot more powerful, generics 
have the benefit that they can be type checked modularly and generic 
functions can be virtual.

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[Andrej Mitrovic]

On 1/26/12, bls  wrote:
> A few questions : where do I find Vladimir Panteelev's XML library ?

https://github.com/CyberShadow/ae/blob/master/utils/ (see xml.d)

> Does this library support XPATH ?

I'm not sure. It's a light-weight library, you're probably not going
to see libxml2 features in there.

> Maybe it's too early but what do you think about replacing wxEvent with
> a D solution ?

I think it's too early for that, but I know it would be nice to have
something D-like for events. We'll see later.

Anyway, the XML parsing script is done and I've verified it has the
same output as the php script. This thing parsed about 1400 xml files,
so I don't see any issues with parsing doxygen xml files with a
lightweight xml lib, at least not for wxWidgets. The next step is to
port the generator scripts. I'll make updates as progress continues.

Re: strong enums: why implicit conversion to basetype?

[Manfred Nowak]

Trass3r wrote:

> It's ill-defined. There are 4 possible types of typedef:  
> http://d.puremagic.com/issues/show_bug.cgi?id=5467
[...]
> Again, this thread is all about discussing the right way to do it
> and not  about what the buggy and holey spec reads.
[...]
> I don't see any merit in that.

You meight be blind. The only way to eject this possibility is to prove 
that there cannot be any merit.

Currently a good approximation of your intentions for the replacment of 
`enum's seems to be a wood of rooted almost-DAGs on types, where the 
edges in the DAGs represent the allowed implicit conversions, the inner 
nodes are represented by tags and the leaves are represented by 
members. Maybe that the "almost" is not necessary.

-manfred

  

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Nick Sabalausky]

"Steven Schveighoffer"  wrote in message 
news:op.v8o5k6h4eav7ka@localhost.localdomain...
>
> If you can bring yourself to stomach the apple store atmosphere,

Heh :)

> I  encourage you to visit one and try it out.  It's definitely different 
> than  any other interface I've ever used.
>

Maybe I will. (Although, there's a MicroCenter right around here and they 
have a nice atmosphere and an Apple section...Although then I'll have to 
keep shooing the vulture know-nothing salesmen away...)

Last time I gave something a try at the apple store it was apple's version 
of a scroll mouse (the thing that "improves" on their infamous "one-button 
mouse" by having *no* buttons). By far worst mouse I've ever used. I know a 
guy that says he loves it, though I can't imagine why.

> I do have a gripe about the mac system, however: the whole special key 
> shit.  Control, Shift and Alt should be enough.  Why do we have option, 
> and that funky clover key?

Unless things have changed, it works like this (I'm actually looking at my 
Mac keyboard right here): "Option" *is* the "Alt" key (although the OS might 
treat it differently, can't remember). And the weird squiggly key is the 
"Apple" key (which is kind of a holdover from Apple 2 days when there was 
"Open Apple" and "Closed Apple", but no Control or Alt.)

The Apple key is treated like the control key - You just have to remember 
that when you'd normally go for Control, on the Mac you'd do Apple instead. 
I don't remember what the hell the Mac's "Control" key is for. My Option key 
actually says "Alt" in addition to "Option" (no function key involved b/c 
this isn't a laptop), so...I think it behaves the same IIRC...?

Of course, FWIW, Windows does have the "Windows" key and the "Menu" key.

> Not to mention that on every other system in  the world, ctrl-c is copy 
> ctrl-v is paste.

Except for damn near every text-mode editor I've ever seen on Linux :/ 
(Note, that's "text-MODE editor", not just "text editor").

>
> As a bonus, they've left off the home, end, page up, and page down keys.

Ouch. That would absolutely kill me. That's definitely got to be a 
laptop-ism though. My Mac keyboard has all of those, and in the right 
places. Hmm, although it has a "Help" where "Insert" should be. Weird. Guess 
I never noticed because the only time I ever use overwrite mode is on 
accident.

It does have F13-F15 where PrintScrn, Scroll Lock, and Pause/Break normally 
are. The last two make sense to change, as I never use them. I do use Print 
Screen though. I do remember that OSX's keyboard combo to take a screenshot 
is rather unintuitive as a result.

> Instead you use (yep, you guessed it) flower-key + arrow keys.  And the 
> backspace key is labeled delete, and I still don't know how to do what a 
> normal delete key would do (delete the character that follows the cursor) 
> can someone tell me?
>

My Mac keyboard has the normal "Del" delete button (which also has a 
right-pointing arrow that has an 'x' inside it)...Although it *also* has a 
backspace button labeled "Delete"...So there's two "Delete" keys that each 
behave different. That's strange. Even more strange that I don't remember 
noticing it, but then it *has* been awhile. Guess I just forgot.

I do agree though, keyboards on a Mac take some getting used to if you've 
been a Windows or Unix guy. And laptop keyboards can be a real pain in 
general.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Nick Sabalausky]

"Sean Kelly"  wrote in message 
news:mailman.49.1327595627.25230.digitalmar...@puremagic.com...
>The command key has a long
>history in the Unix world anyway. It's much better than
>the Windows key that just does one thing, and something
>I've never actually wanted to do.
>
>Sent from my iPhone

I do Win-R all the time. Win-D is nice, too, although I tend to forget about 
it.

---
Not sent from an iPhone.

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[Jesse Phillips]

On Thursday, 26 January 2012 at 19:02:30 UTC, Jonathan M Davis 
wrote:
xmlp is the one that Tomaz is working on to replace std.xml, 
correct? Any idea how close it is to actually being submitted 
for review?


- Jonathan M Davis


Michael Rynn, no I don't know what Tomaz is up to. Maybe some 
form of contact information should be given on the ReviewQueue.


I'll send an email to Michael about this discrepancy as I didn't 
notice this before.


As for xmlp and its progress. I can't really say either. It seems 
he started using a custom hashmap implementation which probably 
doesn't jive with being included in Phobos. Organizational work 
would probably need to be done, it isn't flat which may or may 
not be good for Phobos.

Re: strong enums: why implicit conversion to basetype?

[Alvaro]

El 26/01/2012 14:59, Trass3r escribió:

I thought it'd be good to outsource this question from the other thread
about enums as flags.

Is there any merit in having implicit conversion to the basetype?
Imo it only introduces a severe bug source and brings no advantages.



A better example is something like
if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
silently pass
Heck even +,-,... work.


I kind of agree. I understand enums as a way to define "tags" or flags 
used to define things like file open mode Read, Write, ReadWrite, 
endianness BigEndian, LittleEndian, socket type Stream/Packet, etc. 
things that under the hood are represented by integer numbers but that 
don't represent *quantities*, so should not work the same way as 
integers. What is the result of subtracting or multiplying LittleEndian 
and BigEndian? Does not make sense. Bitwise operations would be OK 
because logica tags can be combined, but little more.


And this brings the question of whether implicit casting from int to 
bool is a good thing (or making any integer a valid boolean value). The 
same way, true and false are not quantities and can't be used in 
arithmetic. Even if they are internally represented as 1 and 0, they 
should not be the same thing as numbers. IMO, Java did it better in 
making them distinct. With a non-int-convertible bool your above weird 
example would not work.

Re: strong enums: why implicit conversion to basetype?

[Manfred Nowak]

Alvaro wrote:

>  With a non-int-convertible bool your above weird 
> example would not work.

But that the example works is not the fault of the existence of enums. 
It is due to the fact that omission, inclusion or change of one 
character can produce a different value without any warning.

-manfred

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Steven Schveighoffer]

On Thu, 26 Jan 2012 17:31:34 -0500, Nick Sabalausky  wrote:


"Sean Kelly"  wrote in message
news:mailman.49.1327595627.25230.digitalmar...@puremagic.com...

The command key has a long
history in the Unix world anyway. It's much better than
the Windows key that just does one thing, and something
I've never actually wanted to do.

Sent from my iPhone


I do Win-R all the time. Win-D is nice, too, although I tend to forget  
about

it.


Win-L is lock screen or "return to welcome screen" if you have that  
enabled.  That's a useful one.


-Steve

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Sean Kelly]

On Jan 26, 2012, at 2:28 PM, Nick Sabalausky wrote:
> 
> The Apple key is treated like the control key - You just have to remember 
> that when you'd normally go for Control, on the Mac you'd do Apple instead. 
> I don't remember what the hell the Mac's "Control" key is for. My Option key 
> actually says "Alt" in addition to "Option" (no function key involved b/c 
> this isn't a laptop), so...I think it behaves the same IIRC…?

"control" click on OSX is effectively right-click.  Outside of the console, 
that's about the only use for it, as far as I know.

Re: Message-Passing

[Sean Kelly]

On Jan 26, 2012, at 1:19 PM, Manu wrote:

> On 26 January 2012 22:07, Sean Kelly  wrote:
>  
> What I like about "receiveOnly" is that the name itself suggests that 
> anything other than the specified type is not expected, and so some measure 
> will probably be taken.
> 
> Again, this only makes sense to me if you already expect that the act of 
> receiving (as a compliment to the send API, which you've already invoked and 
> have a presumption about), was capable of receiving any/multiple things, 
> rather than receiving what you just sent a few lines back...
> 
>  receive!T says to me "look for a message of this type and block if it's not 
> present."
> 
> Perfect. It says that to me too. I'm lost now though, this is the behaviour 
> of receiveOnly... are you agreeing now? :)

It's only the behavior of receiveOnly if the queue is completely empty.  If it 
contains any other message, receiveOnly will throw.  But from what you've said 
I think this is simply a difference in how we design apps.  For me, it's common 
to send multiple message types.  For you, it sounds like it is not.

Re: strong enums: why implicit conversion to basetype?

[Simen Kjærås]

On Thu, 26 Jan 2012 23:49:40 +0100, Alvaro 
wrote:


El 26/01/2012 14:59, Trass3r escribió:

I thought it'd be good to outsource this question from the other thread
about enums as flags.

Is there any merit in having implicit conversion to the basetype?
Imo it only introduces a severe bug source and brings no advantages.



A better example is something like
if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
silently pass
Heck even +,-,... work.


I kind of agree. I understand enums as a way to define "tags" or flags  
used to define things like file open mode Read, Write, ReadWrite,  
endianness BigEndian, LittleEndian, socket type Stream/Packet, etc.  
things that under the hood are represented by integer numbers but that  
don't represent *quantities*, so should not work the same way as  
integers. What is the result of subtracting or multiplying LittleEndian  
and BigEndian? Does not make sense. Bitwise operations would be OK  
because logica tags can be combined, but little more.


Sometimes, bitwise operations make sense, other times not. Enums play two
roles in D - that of an enumeration and that of a set of flags. Only for
the latter do bitwise operations make sense.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Stewart Gordon]

On 26/01/2012 15:41, Steven Schveighoffer wrote:

On Thu, 26 Jan 2012 10:20:38 -0500, David Nadlinger  wrote:


On 1/26/12 4:06 PM, Steven Schveighoffer wrote:

[…]And the
backspace key is labeled delete, and I still don't know how to do what a
normal delete key would do (delete the character that follows the
cursor) can someone tell me?


Who decides what constitutes a "normal delete key"?  Back in the days of 8-bit home 
computers (Spectrum, BBC, C64 et al), delete tended to mean delete to the left.  Then 
there was the Amstrad PCW line, with "DEL→" and "←DEL" next to each other.  Since then 
it's become more or less standard that delete means delete to the right, delete to the 
left being called backspace.


(Though even on systems with both these keys, it's taken time to standardise their 
meanings.  I grew up partly with a primitive text editor called RPED, in which delete 
deleted to the left, and backspace (IIRC) just moved the cursor left.)



Fn + Backspace, on my Macbook Pro.


Thank you :) I will try it next time I use my macbook pro. And I forgot about 
that Fn key!
Though that's pretty much standard on most laptops these days.


I've been reminded of the iMac G3 that I was made to use for some of my time as a PhD 
student.  Just the backspace key, no delete key.  And no Fn key to make some of the keys 
double as different keys - those keys they felt people could live without they just left off.


Stewart.

Alternative template instantiation syntax

[Simen Kjærås]

A pattern in D is this:

alias Foo!q{
stuffs
} MyFoo;

Where Foo is a templated struct/class. In many ways, this is similar to
defining a new type, and I therefore throw out the suggestion that the
syntax should reflect this. I may be wrong, but I think this syntax is
unused and fitting:

Foo MyFoo!q{
stuffs
}

This is clearly symmetrical with the definition of normal types:

class MyClass {
}

struct MyStruct {
}

enum MyEnum {
}

Critique? Thoughts?

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Nick Sabalausky]

"Sean Kelly"  wrote in message 
news:mailman.70.1327626159.25230.digitalmar...@puremagic.com...
>On Jan 26, 2012, at 2:28 PM, Nick Sabalausky wrote:
>>
>> The Apple key is treated like the control key - You just have to remember
>> that when you'd normally go for Control, on the Mac you'd do Apple 
>> instead.
>> I don't remember what the hell the Mac's "Control" key is for. My Option 
>> key
>> actually says "Alt" in addition to "Option" (no function key involved b/c
>> this isn't a laptop), so...I think it behaves the same IIRC…?
>
>"control" click on OSX is effectively right-click.  Outside of the console, 
>that's about the only use for it, as far as I know.=

Heh, yea. That's something thing I always found funny: Apple always used to 
prepackage one-button mice with their right-click-capable OSX machines 
because "one-button mice are simpler and easier". But I never understood how 
"control-click" qualified as simpler or easier than "right-click".

Even *my mom* isn't confused by existence of the right-button of her mouse, 
and she's the type of user who doesn't even know what a "web browser" is, 
*and* she doesn't even comprehend "double-click" (She calls it "two clicks" 
and doesn't know when to use "one click or two" - hell, she usually just 
double-clicks on almost everything). Even *she* isn't confused by second 
mouse button or the scroll wheel. And neither is my dad, and he's even 
*worse* than she is (as just one small example, he couldn't understand that 
he could use his *laptop* without it being plugged in. "It's a portable, 
dad, it has a battery. That's the whole point." Explaining it still didn't 
seem to help.)

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Stewart Gordon]

On 27/01/2012 01:36, Nick Sabalausky wrote:


Heh, yea. That's something thing I always found funny: Apple always used to
prepackage one-button mice with their right-click-capable OSX machines
because "one-button mice are simpler and easier". But I never understood how
"control-click" qualified as simpler or easier than "right-click".



A one-button mouse _is_ simpler than a mouse with three buttons and a scroll 
wheel.

OTOH, _using_ a one-button mouse is neither simpler nor easier

(The IT manager of my uni department back in the day told me (probably speculatively) that 
the reason for fewer buttons is "less to go wrong".)


Stewart.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Nick Sabalausky]

"Stewart Gordon"  wrote in message 
news:jfsuc5$12pl$1...@digitalmars.com...
>
> Who decides what constitutes a "normal delete key"?

That's "normal" as in "95% of the PCs in the past 20 years." ;)  (And macs 
*are* "personal computers", contrary to the ads.)

FWIW though, any mention of "8-bit" does get me excited.

> Back in the days of 8-bit home computers (Spectrum, BBC, C64 et al), 
> delete tended to mean delete to the left.  Then there was the Amstrad PCW 
> line, with "DEL?" and "?DEL" next to each other.  Since then it's become 
> more or less standard that delete means delete to the right, delete to the 
> left being called backspace.
>
> (Though even on systems with both these keys, it's taken time to 
> standardise their meanings.  I grew up partly with a primitive text editor 
> called RPED, in which delete deleted to the left, and backspace (IIRC) 
> just moved the cursor left.)
>
>>> Fn + Backspace, on my Macbook Pro.
>>
>> Thank you :) I will try it next time I use my macbook pro. And I forgot 
>> about that Fn key!
>> Though that's pretty much standard on most laptops these days.
>
> I've been reminded of the iMac G3 that I was made to use for some of my 
> time as a PhD student.  Just the backspace key, no delete key.  And no Fn 
> key to make some of the keys double as different keys - those keys they 
> felt people could live without they just left off.
>

That's really one of the main reasons I don't consider Apple to be good at 
design: Anytime they notice that something isn't *needed* by *all* users, 
they just throw out instead of leaving it as an option. They seem to feel 
that personal customization and preferences are an "evil" that infringes on 
the uniformity of their brand image (Which also explains their love for DRM 
and gatekeeping).

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Nick Sabalausky]

"Stewart Gordon"  wrote in message 
news:jfsvfh$14ek$1...@digitalmars.com...
> On 27/01/2012 01:36, Nick Sabalausky wrote:
> 
>> Heh, yea. That's something thing I always found funny: Apple always used 
>> to
>> prepackage one-button mice with their right-click-capable OSX machines
>> because "one-button mice are simpler and easier". But I never understood 
>> how
>> "control-click" qualified as simpler or easier than "right-click".
> 
>
> A one-button mouse _is_ simpler than a mouse with three buttons and a 
> scroll wheel.
>
> OTOH, _using_ a one-button mouse is neither simpler nor easier
>

Well, yea, but Apple's stated excuse for the one-button wasn't because they 
*are* simpler, but because they're allegedly "simpler *to use*".  I guess I 
mistakenly left off the "to use" part up there. Whenever Apple says 
"simpler", they generally mean "simpler to use", even if it's flat-out 
false.

> (The IT manager of my uni department back in the day told me (probably 
> speculatively) that the reason for fewer buttons is "less to go wrong".)
>
> Stewart. 

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:jft09p$160q$1...@digitalmars.com...
> "Stewart Gordon"  wrote in message 
> news:jfsuc5$12pl$1...@digitalmars.com...
>>
>> I've been reminded of the iMac G3 that I was made to use for some of my 
>> time as a PhD student.  Just the backspace key, no delete key.  And no Fn 
>> key to make some of the keys double as different keys - those keys they 
>> felt people could live without they just left off.
>>
>
> That's really one of the main reasons I don't consider Apple to be good at 
> design: Anytime they notice that something isn't *needed* by *all* users, 
> they just throw out instead of leaving it as an option. They seem to feel 
> that personal customization and preferences are an "evil" that infringes 
> on the uniformity of their brand image (Which also explains their love for 
> DRM and gatekeeping).
>

To clarify, I don't mean "DRM" in the sense of music/videos or 
game-industry-rootkits. I mean in terms of using it to artificially limit 
what users are able/allowed to do with their own devices.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Era Scarecrow]

> > Heh, yea. That's something thing I always found funny:
> Apple always used to
> > prepackage one-button mice with their
> right-click-capable OSX machines
> > because "one-button mice are simpler and easier". But I
> never understood how
> > "control-click" qualified as simpler or easier than
> "right-click".
> 
> 
> A one-button mouse _is_ simpler than a mouse with three
> buttons and a scroll wheel.
> 
> OTOH, _using_ a one-button mouse is neither simpler nor
> easier
> 
> (The IT manager of my uni department back in the day told me
> (probably speculatively) that 
> the reason for fewer buttons is "less to go wrong".)

 Let's see... I don't have a math degree, but how many keys are there on a 
keyboard? With a 2 button mouse, you have up to 4 combinations you can work 
with. If you include double click, that does up to 9, include a scroll wheel 
click, that's 27.

 Now instead of using one hand and two fingers (index and ring), you instead 
have to use one hand, with one button, the other hand, and you have to probably 
drop your eyes to find the key. So with a single mouse, and you have click and 
double click, plus a 101 key keyboard, you have 202 combinations, all of which 
require two hands. Amputee? Get a PC... (now there's an ad slogan :P)

 Also reminds me something I never understood. The apple machines required you 
to have a keyboard plugged into turn on the computer, because the power button 
was on the keyboard. Who the hell made that genius decision? I mean if it 
was something like, oh the Atari 800XL, or Commodore 64, that goes hand in hand 
as you COULDN'T remove the keyboard (which was the computer) but geez 
Really...

Re: MS extend C++ significantly for Windows8... and Andrei got name drop

[Daniel Murphy]

>>
>> I see, well that's good. I presume then that it shouldn't be too much
>> trouble to implement MS C++'s ref type ABI in D then if it is just
>> basically COM.
>> How about 'delegate'? Would it be trouble to make the extern ABI 
>> compatible
>> when passing delegates between MSC++/D?
>
> Theoretically, it wouldn't be to hard, getting Walter to do it however ...
>

There probably isn't much point until dmd can produce coff and link to more 
of c++ anyway. 

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Daniel Murphy]

>>
>> I do Win-R all the time. Win-D is nice, too, although I tend to forget 
>> about
>> it.
>
> Win-L is lock screen or "return to welcome screen" if you have that 
> enabled.  That's a useful one.
>

Don't forget Win-E for my computer, Win-F for find and Win-Pause to open 
system properties.  Although since I've instaled Desktops they only work on 
the primary desktop which is a pain. 

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Sean Kelly]

I think if you design an interface where the input device has only one button 
as opposed to multiple buttons, etc, one could argue that the result will be 
easier to learn. I know I always had trouble explaining the use of the right 
mouse button in Windows to my parents. 

On Jan 26, 2012, at 5:55 PM, "Nick Sabalausky"  wrote:

> "Stewart Gordon"  wrote in message 
> news:jfsvfh$14ek$1...@digitalmars.com...
>> On 27/01/2012 01:36, Nick Sabalausky wrote:
>> 
>>> Heh, yea. That's something thing I always found funny: Apple always used 
>>> to
>>> prepackage one-button mice with their right-click-capable OSX machines
>>> because "one-button mice are simpler and easier". But I never understood 
>>> how
>>> "control-click" qualified as simpler or easier than "right-click".
>> 
>> 
>> A one-button mouse _is_ simpler than a mouse with three buttons and a 
>> scroll wheel.
>> 
>> OTOH, _using_ a one-button mouse is neither simpler nor easier
>> 
> 
> Well, yea, but Apple's stated excuse for the one-button wasn't because they 
> *are* simpler, but because they're allegedly "simpler *to use*".  I guess I 
> mistakenly left off the "to use" part up there. Whenever Apple says 
> "simpler", they generally mean "simpler to use", even if it's flat-out 
> false.
> 
>> (The IT manager of my uni department back in the day told me (probably 
>> speculatively) that the reason for fewer buttons is "less to go wrong".)
>> 
>> Stewart. 
> 
> 

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Andrew Wiley]

On Thu, Jan 26, 2012 at 4:31 PM, Nick Sabalausky  wrote:
> "Sean Kelly"  wrote in message
> news:mailman.49.1327595627.25230.digitalmar...@puremagic.com...
>>The command key has a long
>>history in the Unix world anyway. It's much better than
>>the Windows key that just does one thing, and something
>>I've never actually wanted to do.
>>
>>Sent from my iPhone
>
> I do Win-R all the time. Win-D is nice, too, although I tend to forget about
> it.
>

Since I upgraded to Windows 7, I've barely ever clicked the start
menu. Windows key, type application name, enter. Probably my favorite
UI change.

Re: [OT] "The Condescending UI" (was: Do we need Win95/98/Me support?)

[Andrew Wiley]

On Thu, Jan 26, 2012 at 6:59 AM, Nick Sabalausky  wrote:
> "Andrew Wiley"  wrote in message
> news:mailman.40.1327562674.25230.digitalmar...@puremagic.com...
>>On Wed, Jan 25, 2012 at 3:31 PM, Nick Sabalausky  wrote:
>>> "Steven Schveighoffer"  wrote in message
>>> news:op.v8nbixzyeav7ka@localhost.localdomain...

 I must rave about the trackpad on the macbook pro. The interface is so
 damned good, I hate going back to my linux laptop (which I must do for
 work).

>>>
>>> A good trackpad?!? That seems difficult to believe. Whenever I use a
>>> laptop,
>>> I just grab/carry-around a trackball (or at least a mouse). I can barely
>>> use
>>> those touchpad things, and IBM's "clitmouse" is only a little bit better.
>>>
>>
>>YES, I'm not the only person alive using a trackball! Thumb-ball,
>>marble, or one of those giant pool-ball things?
>
> http://www.amazon.com/Logitech-Trackman-Wheel-Optical-Silver/dp/B5NIMJ
>
> (I don't know why the price there is so high, though. They're only around
> $35-ish in stores.)

It's that high because Logitech has stopped selling them. They've been
replaced by this:
http://www.logitech.com/en-us/mice-pointers/trackballs/devices/wireless-trackball-m570

I use the Trackman Wheel as well, and when I saw what they replaced it
with, I thought it would be terrible (dunno if you ever tried the
Wireless Trackman, but I own one and I think it's vastly inferior to
the wired version). Fortunately, the company I interned at last summer
was kind enough to buy me one of the new ones when I mentioned I was a
hardcore trackball user, and I think it's probably better than my
Trackman Silver. The wireless works flawlessly (unlike its
predecessor) and there's a lot less slop in the ball.

On the other hand, it's $60.
>
> I absolutely love it. It's my primary pointing device on *any* of my
> computers.
>
> Around 5-10 years ago I started getting wrist pain. I heard that trackballs
> were better for the wrist than mice, so I got one (this logitech one). It
> was really awkward the first, but I got used to it after a couple days.
> After two weeks it felt 100% as natural as a mouse, even for games.
> (Touchpads, by contrast, I was never able to get past the "really awkward"
> stage, even after several years with the laptop I used to have). And I
> haven't been having any more wrist pain since.

I never got to wrist pain, but I noticed my wrist tingling at one
point and the local electronics gigantostore was trying to get rid of
their stock of the Silvers. My experience pretty much matched yours.
>
> I don't even like actual mice all that much anymore (They need so much more
> surface area! And so much more movement. The trackball is just - ZIP!
> Awesome :) ).
>

The only downside I've found is that when I'm showing someone
something on my computer, there's always an awkward moment when they
try to move the trackball on the desk and notice that nothing happens.
:D

Re: enum scope

[Daniel Murphy]

> alias int UITableViewRowAnimation;
> enum
> {
> UITableViewRowAnimationFade,
> UITableViewRowAnimationRight,
> UITableViewRowAnimationLeft,
> UITableViewRowAnimationTop,
> UITableViewRowAnimationBottom,
> UITableViewRowAnimationNone,
> UITableViewRowAnimationMiddle,
> UITableViewRowAnimationAutomatic = 100
> }

That works for interfacing c, but not c++.

The following is a better solution, and should probably be in the standard 
library.

enum UITableViewRowAnimation
{
  UITableViewRowAnimationFade,
  UITableViewRowAnimationRight,
  UITableViewRowAnimationLeft,
  UITableViewRowAnimationTop,
  UITableViewRowAnimationBottom,
  UITableViewRowAnimationNone,
  UITableViewRowAnimationMiddle,
  UITableViewRowAnimationAutomatic = 100
}
alias UITableViewRowAnimation.UITableViewRowAnimationFade 
UITableViewRowAnimationFade;
alias UITableViewRowAnimation.UITableViewRowAnimationRight 
UITableViewRowAnimationRight;
alias UITableViewRowAnimation.UITableViewRowAnimationLeft 
UITableViewRowAnimationLeft;
alias UITableViewRowAnimation.UITableViewRowAnimationTop 
UITableViewRowAnimationTop;
alias UITableViewRowAnimation.UITableViewRowAnimationBottom 
UITableViewRowAnimationBottom;
alias UITableViewRowAnimation.UITableViewRowAnimationNo 
UITableViewRowAnimationNo;
alias UITableViewRowAnimation.UITableViewRowAnimationMiddle 
UITableViewRowAnimationMiddle;
alias UITableViewRowAnimation.UITableViewRowAnimationAutomatic 
UITableViewRowAnimationAutomatic;

(could be mixin(exposeEnumMembers!UITableViewRowAnimation); ) 

Re: Windows API and druntime/Phobos

[Jacob Carlborg]

On 2012-01-26 22:31, Marco Leise wrote:

Am 26.01.2012, 18:47 Uhr, schrieb Jacob Carlborg :


On 2012-01-26 15:46, Manu wrote:

On 26 January 2012 16:45, Manu mailto:turkey...@gmail.com>> wrote:

On 26 January 2012 16:33, Marco Leise mailto:marco.le...@gmx.de>> wrote:

Am 26.01.2012, 05:08 Uhr, schrieb Brad Roberts
mailto:bra...@puremagic.com>>:

On 1/24/2012 8:48 PM, Jonathan M Davis wrote:

The level of support for the Windows API in druntime and
Phobos is pretty low.
As I understand it, Windows users are pretty much forced
to use
http://www.dsource.org/__projects/bindings/browser/__trunk/win32

if they need
comprehensive Win32 API bindings. druntime seems to be
trying to define all of
the OS-specific stuff like that, but on top of it
missing much of it, in the
case of the Win32 API, that's a _lot_ of functions, and
I don't know if we
want to put that much in druntime. So, the question is,
how do we want to
support the Win32 API in druntime and Phobos?

Do we want to put all of the Win32 API bindings in
druntime? If not, then do
we want to put them in Phobos? Or do we just want to
send Windows developers
to a 3rd party library like the Win32 bindings project
on dsource? Given that
they're OS bindings, I would _think_ that we'd want them
in druntime, but I
don't know.

Regardless, this is one of those issues which frequently
plagues D Windows
developers, and we really should at least get a plan
together as to how we
want to handle it.

- Jonathan M Davis


P.S. A related pull request:
https://github.com/D-__Programming-

Language/druntime/pull/139


We've got the posix api set in the runtime, not just the
subset that the runtime or phobos needs. IMHO, windows should
follow that pattern. It might be large from a number of
lines of declarations standpoint, but who cares.


I tend to agree.


I wouldn't object to having guaranteed access to winapi in
druntime... but it is pretty big. In the interest of following the
pattern with posix, it makes sense to me.
But I'm also not allergic to it being a completely separate library,
as long as it's distributed with the windows toolchain. I probably
wouldn't want to see it in std, that makes no sense to me. druntime
makes some sense (since parts of druntime depend on windows calls)
if people think that's where it should be.

What is the reasoning for putting the posix api in druntime? That
seems like a weird choice to me... it's nothing to do with druntime,
except for a couple of dependencies perhaps.


Also, WinRT is upon us... I intend to start writing WinRT programs asap.
Ahould that go in druntime too? Are we opening a floodgate?


BTW, we don't have any OS specific bindings for OSes that also have
Posix bindings. I thinking mostly on Mac OS X, don't know if the other
OSes have anything useful.


That's because you can get away with only using Posix on Mac OS X. If
the situation was like on Windows, druntime would have to bind to the
Mac OS X API as well. So I don't think this is a good counter argument.
My thoughts are just: 2 places for the same thing are bad, druntime
already depends on it => put it there.


It's not an argument, it's a comment.

--
/Jacob Carlborg

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[equinox]

On Thu, 26 Jan 2012 23:18:10 +0100, Andrej Mitrovic  
 wrote:



On 1/26/12, bls  wrote:

A few questions : where do I find Vladimir Panteelev's XML library ?


https://github.com/CyberShadow/ae/blob/master/utils/ (see xml.d)


Does this library support XPATH ?


I'm not sure. It's a light-weight library, you're probably not going
to see libxml2 features in there.


Maybe it's too early but what do you think about replacing wxEvent with
a D solution ?


I think it's too early for that, but I know it would be nice to have
something D-like for events. We'll see later.

Anyway, the XML parsing script is done and I've verified it has the
same output as the php script. This thing parsed about 1400 xml files,
so I don't see any issues with parsing doxygen xml files with a
lightweight xml lib, at least not for wxWidgets. The next step is to
port the generator scripts. I'll make updates as progress continues.



It is not clear what you do not use xml in tango library.


Regards

Marton Papp

Re: automated C++ binding generation.. Booost D, NO , Not us. SIMD is more important.

[Andrej Mitrovic]

On 1/27/12, equi...@atw.hu  wrote:
> It is not clear what you do not use xml in tango library.

I'm using D2, not D1.