View mode: basic / threaded / horizontal-split · Log in · Help
November 19, 2010
Re: Shared pain
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
November 19, 2010
Re: windows debug [Shared pain]
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
November 19, 2010
Re: Shared pain
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
November 19, 2010
Re: windows debug [Shared pain]
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).
November 19, 2010
Re: Shared pain
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
November 19, 2010
Re: Shared pain
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
>
>
November 19, 2010
Re: Shared pain
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
November 19, 2010
Re: Shared pain
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.
November 20, 2010
Re: Shared pain
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.
February 19, 2014
Re: Shared pain
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home