On Fri, 19 Nov 2010 08:25:17 -0500, Jason House wrote:

> A cast to immutable is required when constructing immutable objects. The type system can't prove that's safe. It's a design limitation to keep complexity low.
> 
Jason,

But design limitations like that will force programmers who are on a tight schedule to just say __gshared, and to hell with it.

Languages can't be designed just on theory - some recognition of practicality is also required.

As to the thread - I don't think that is under my control. I believe the Windows service dispatcher does its own thing.

Thanks for taking the trouble
Steve

On Fri, 19 Nov 2010 16:58:26 +0300, Stanislav Blinov wrote:

> Have you tried OutputDebugString()? It's WinAPI function that sends strings to the 'debugger'. DebugView application from SysInternals suite nicely prints those strings, and also times them.

How is this better than the event log. It only takes one line of code, but it's still a pain in the arse.

In any case, if it's a service, where does it output the debug string to?

Thanks for you suggestion Stanislav, but I'm pretty much worked through it by now - albeit somewhat pissed off ;=)

Steve

Steve Teale:

> Languages can't be designed just on theory - some recognition of practicality is also required.

In the case of creation of immutable data structures it looks the opposite to me: DMD is too much pragmatic and there isn't enough theory behind it :-)


> But design limitations like that will force programmers who are on a tight schedule to just say __gshared, and to hell with it.

Regarding the creation of immutable data structures, there is a proposal that is probably able to remove some of the pain: the result of strongly pure functions may become implicitly castable to immutable.

Bye,
bearophile

19.11.2010 19:08, Steve Teale пишет:
> On Fri, 19 Nov 2010 16:58:26 +0300, Stanislav Blinov wrote:
>
>> Have you tried OutputDebugString()? It's WinAPI function that sends strings to the 'debugger'. DebugView application from SysInternals suite nicely prints those strings, and also times them.
> How is this better than the event log. It only takes one line of code, but it's still a pain in the arse.

It's better precisely in that it doesn't need event log. Cluttering system log with debug messages is not a thing I personally like :)

> In any case, if it's a service, where does it output the debug string to?

It's not a console output. That function generates special Windows debug event that can be captured by external application (i.e. debugger, but not necessarily). It is very useful with things like services when console is not available and you don't feel like creating log file. SysInternals suite has a DebugView application that captures these debug strings from currently running processes and displays them as a kind of log: they are numbered and timed (see attached screenshot).

On Fri, 19 Nov 2010 11:23:44 -0500, bearophile wrote:

> Regarding the creation of immutable data structures, there is a proposal that is probably able to remove some of the pain: the result of strongly pure functions may become implicitly castable to immutable.
> 
> Bye,
> bearophile

BP,

I admire your dedication to language theory and purity, but there are many who'd translate that to impracticality and obscurity.

I came to D in the first place because I found it refreshingly clear and easy to use after C++ and Java. But now it's getting painful.

I've bailed out several times, just keep coming back to see how it is doing. I have a bunch of code that worked with D1 and D2 at one time. I've given up on D1, since it is now obviously legacy, but even without the complexity of supporting both, It's been real hard this visit to get things working again.

What's your estimate of how long it will be before D is a stable language?

Thanks
Steve

On 19-nov-10, at 17:42, Steve Teale wrote:

> On Fri, 19 Nov 2010 11:23:44 -0500, bearophile wrote:
>
>> Regarding the creation of immutable data structures, there is a proposal
>> that is probably able to remove some of the pain: the result of strongly
>> pure functions may become implicitly castable to immutable.
>>
>> Bye,
>> bearophile
>
> BP,
>
> I admire your dedication to language theory and purity, but there are
> many who'd translate that to impracticality and obscurity.
>
> I came to D in the first place because I found it refreshingly clear and
> easy to use after C++ and Java. But now it's getting painful.
>
> I've bailed out several times, just keep coming back to see how it is
> doing. I have a bunch of code that worked with D1 and D2 at one time.
> I've given up on D1, since it is now obviously legacy, but even without
> the complexity of supporting both, It's been real hard this visit to get
> things working again.
>
> What's your estimate of how long it will be before D is a stable language?

well D1 is pretty stable I think, if you are interested in stability that is a good choice, has worked well for me.
This does not mean that I will not consider D2, but D1 is my main workhorse.

Fwzi

>
> Thanks
> Steve
>
>

Steve Teale:

> I admire your dedication to language theory and purity, but there are many who'd translate that to impracticality and obscurity.

I like that idea about immutables & strong pure functions, but it was not an idea of mine :-) That enhancement request in Bugzilla is not written by me.


> I came to D in the first place because I found it refreshingly clear and easy to use after C++ and Java. But now it's getting painful.

But strongly pure functions are already present in D. So it's morally good to push its usages and implications as far as possible, otherwise we are wasting possibilities. That implicit cast idea is another implication of purity. It's a clean thing, it's not a hack or workaround or a dangerous thing or something like that, it comes from a clean & logical reasoning about consequences of purity. So it can't be compared to many other dirty things present in D2. It actually helps to clean the programs a little, because removes the need for one important use case of casts. So I can't agree. There is a large complexity difference between extending the logical implications of an already present feature, and adding a true special case.


> What's your estimate of how long it will be before D is a stable language?

I have no idea, I am not that expert, and probably no one knows. D is developed by a small group of devs, and despite in life you seem to "need" to be fast everything you do (for example because otherwise others do it before you and you miss the train), D is not a commercial project, so it has less timing pressures. Often commercial software projects produce a worse result, despite having more resources, because of the strict development timing requirements.

If you look at the PyPy Python project it's may years out of schedule, it was started by lot of money coming from European Union, but in the end it may deliver something good any way. Open Source projects too need to respect some timing schedules, but in OS you are sometimes able to say "it will be done when it will be done," while in most commercial software projects you can't say that.

The "feature" we are describing here probably needs only few lines of code to be implemented in the compiler (but I can't be sure) and it's backward-compatible (because it removes the need of a cast in some cases), so it's a kind of additive change.

Bye,
bearophile

Steve Teale Wrote:

> On Fri, 19 Nov 2010 08:25:17 -0500, Jason House wrote:
> 
> > A cast to immutable is required when constructing immutable objects. The type system can't prove that's safe. It's a design limitation to keep complexity low.
> > 
> Jason,
> 
> But design limitations like that will force programmers who are on a tight schedule to just say __gshared, and to hell with it.
> 
> Languages can't be designed just on theory - some recognition of practicality is also required.

I didn't say I liked the need for the cast or even that I think D has the proper design! IIRC, the cast with object creation was in lieu of adding "unique" tepe qualifier and the extra complexity to get that right. In your example, I believe the object was created once, so a cast really isn't that bad. The bad part to me was the need to cast away immutability with every use. That's why I encouraged a bugzilla entry. I did't check this case, but Phobos had a bad track record with adopting type qualifiers after they were added to D2.

On Fri, 19 Nov 2010 16:21:41 -0500, Jason House wrote:

> Steve Teale Wrote:
> 
>> On Fri, 19 Nov 2010 08:25:17 -0500, Jason House wrote:
>> 
>> > A cast to immutable is required when constructing immutable objects. The type system can't prove that's safe. It's a design limitation to keep complexity low.
>> > 
>> Jason,
>> 
>> But design limitations like that will force programmers who are on a tight schedule to just say __gshared, and to hell with it.
>> 
>> Languages can't be designed just on theory - some recognition of practicality is also required.
> 
> I didn't say I liked the need for the cast or even that I think D has the proper design! IIRC, the cast with object creation was in lieu of adding "unique" tepe qualifier and the extra complexity to get that right. In your example, I believe the object was created once, so a cast really isn't that bad. The bad part to me was the need to cast away immutability with every use. That's why I encouraged a bugzilla entry. I did't check this case, but Phobos had a bad track record with adopting type qualifiers after they were added to D2.

I'm a bit calmer now I have got most of my utility modules working again.

There were two circumstances where I found the casts particularly irksome.

I had at one point an immutable char* that I would be passing to Win32 functions. I was assigning to it the address of a plain static character array, and I had to use a cast to do it. I could not see what harm such an assignment could do.

Then I had a slew of cases where I had created immutable RegExp objects, and I had to do (cast(RegExp) rexobj).find(...). I could not see what the cast was protecting here either.

I think these are bugs, if you agree I will put them in bugzilla.

On Friday, 19 November 2010 at 06:53:40 UTC, Steve Teale wrote:
> On Thu, 18 Nov 2010 11:26:39 +0000, Steve Teale wrote:
>
>> I had D code that provided a basis for creation of Windows services,
>> which I have just tried to get working with the latest D2.
>> 
>> No dice.
>> 
> I have made some progress in understanding this. It appears that any D
> static data structures containing function pointers will now cause a
> Windows service to crash.
[...]

I am currently stuck with the same problem.
I have code for a windows service written in D1 that works just
fine.
And I can't get my head around what needs to be changed to make
this darn thing work with D2.

Steve, did you find a way to make your windows service work with
D2?
Care to show some example code or to point me to the right
direction?
All other information regarding windows service and D seem to be
D1 only.