In article <dsai30$2eim$3@digitaldaemon.com>, Walter Bright says...
>
>
>"Derek Parnell" <derek@psych.ward> wrote in message news:kd76gxwx1ay2.19m4wymne8pm$.dlg@40tude.net...
>> * Why are some of the module statements wrong? (I've sent you the list
>> twice now)
>
>Sloth on my part.
>
>> * Why are some module statements missing? (I've also sent you this list)
>
>Sloth on my part for the ones in std. For the ones in internal, they are irrelevant, because those modules are not meant to ever be imported.
>
>> * Why don't you want others to recompile Phobos using a heightened measure of caution (ie "-w" switch)
>
>In the previous long, and heated, discussions on this issue, I argued passionately that the -w style code reduces readability, maintainability, and reliability. I don't think there's anything to be added to that.
>
>This current thread only reinforces my opinion that the mere existence of warnings is a mistake in any language, as it causes unresolvable debates about "is this code right or wrong?"
>
>


So why not instead treat the compiler -w option as a LINT like tool.  I know it's *not* LINT, but maybe it's just a terminology thing that's hanging things up.  Treat -w like LINT and allow the compiler to compile through the 'warnings'.  Maybe instead of 'warnings', they should be 'code that you are highly advised to look at, because the compiler doesn't agree with you'.

I'm not trying to be sarcastic.  If the term warnings has such an ingrained meaning for everyone, then call it something else.  As a side-effect -- granted it's not a full-blown LINT tool -- it's kind of nice to have *some* of that functionality in the compiler.

Just my (nieve as they may be) thoughts.

-Kramer

Don Clugston wrote:
> Anders F Björklund wrote:
> 
>> David Medlock wrote:
>>
>>> Isn't that GPL?
>>> I vote lets not force any D developers into (L)GPL type licensing issues.  That type of 'freedom' discourages commercial use (despite what the pundits say).
>>
>>
>> It's not really fair to bundle GPL and LGPL like that I think...
>> The *LGPL* will only affect the library development, not the use.
>>
>> The only "downside" to the LGPL is the dynamic link requirement ?
>> (It's possible to explicitly allow static linking as an exception)
> 
> 
> rant
> Personally, I think the default LGPL license is the most ridiculous one I've seen, "Arse licence" included. The dynamic linking requirement doesn't benefit anyone. It's annoying for commercial use, but it doesn't benefit open source at all. GPL makes a lot of sense (in the right context, but definitely not for D standard libraries), but LGPL is just nuts.
> /rant

On top of that, for embedded work the LGPL becomes GPL because there is no 'dynamic' linking possible.

The libraries which allow the static linking exception (such as FLTK) should just use MPL or Apache Licenses, which avoid the ambiguities which come with GNU licenses.

-DavidM

In article <dsafo1$2c19$1@digitaldaemon.com>, Don Clugston says...
>
>Anders F Björklund wrote:
>> David Medlock wrote:
>> 
>>> Isn't that GPL?
>>> I vote lets not force any D developers into (L)GPL type licensing
>>> issues.  That type of 'freedom' discourages commercial use (despite
>>> what the pundits say).
>> 
>> It's not really fair to bundle GPL and LGPL like that I think... The *LGPL* will only affect the library development, not the use.
>> 
>> The only "downside" to the LGPL is the dynamic link requirement ? (It's possible to explicitly allow static linking as an exception)
>
>rant
>Personally, I think the default LGPL license is the most ridiculous one
>I've seen, "Arse licence" included. The dynamic linking requirement
>doesn't benefit anyone. It's annoying for commercial use, but it doesn't
>benefit open source at all. GPL makes a lot of sense (in the right
>context, but definitely not for D standard libraries), but LGPL is just
>nuts.
>/rant

You're not alone in thinking this.  I myself find all GPL variants rather dogmatic, and practically a form of "PM-repellant" around the office.  I always felt the tone of the license to be more on the side of foisting a particular agenda on developers rather than promoting "freedom".  The current flap surrounding GPLv3, and the proliferation of other more flexible licenses, has only solidified this belief of mine.

- Eric Anderton at yahoo

David Medlock wrote:

> On top of that, for embedded work the LGPL becomes GPL because there is no 'dynamic' linking possible.

On the other hand, if they DO have the exception to allow static linking
then there is no such LGPL->GPL change in licensing when going embedded.

For instance: http://www.wxwidgets.org/embedded.htm (wxWindows License)

> The libraries which allow the static linking exception (such as FLTK) should just use MPL or Apache Licenses, which avoid the ambiguities which come with GNU licenses.

Perhaps, but that is their decision to make ? I use zlib/png, usually.

I still find it quite the difference if they use the LGPL-with-static-
linking (such as FLTK or wx) or if it is the GPL license (Qt O.S. Ed.)

--anders

In article <dsaofo$2lc8$1@digitaldaemon.com>, pragma says...
>
>In article <dsafo1$2c19$1@digitaldaemon.com>, Don Clugston says...
>>
>>Anders F Björklund wrote:
>>> David Medlock wrote:
>>> 
>>>> Isn't that GPL?
>>>> I vote lets not force any D developers into (L)GPL type licensing
>>>> issues.  That type of 'freedom' discourages commercial use (despite
>>>> what the pundits say).
>>> 
>>> It's not really fair to bundle GPL and LGPL like that I think... The *LGPL* will only affect the library development, not the use.
>>> 
>>> The only "downside" to the LGPL is the dynamic link requirement ? (It's possible to explicitly allow static linking as an exception)
>>
>>rant
>>Personally, I think the default LGPL license is the most ridiculous one
>>I've seen, "Arse licence" included. The dynamic linking requirement
>>doesn't benefit anyone. It's annoying for commercial use, but it doesn't
>>benefit open source at all. GPL makes a lot of sense (in the right
>>context, but definitely not for D standard libraries), but LGPL is just
>>nuts.
>>/rant
>
>You're not alone in thinking this.  I myself find all GPL variants rather dogmatic, and practically a form of "PM-repellant" around the office.  I always felt the tone of the license to be more on the side of foisting a particular agenda on developers rather than promoting "freedom".  The current flap surrounding GPLv3, and the proliferation of other more flexible licenses, has only solidified this belief of mine.
>
>- Eric Anderton at yahoo

Hear, hear!

"Anders F Björklund" <afb@algonet.se> wrote in message news:dsaivb$2fos$1@digitaldaemon.com...
> From the Qt# home page, they say there are 476 classes converted...

That's just one heck of a lot of work to do.

> You would still face the same licensing issues as the C++ version, though. (i.e. this "Open Source" version is under the GPL license)

While that would make it fine as a 3rd party library for D, it makes it impossible to use as a standard part of D.

Can we move this discussion over to digitalmars.D.dwt?

"Kramer" <Kramer_member@pathlink.com> wrote in message news:dsalta$2ivu$1@digitaldaemon.com...
> So why not instead treat the compiler -w option as a LINT like tool.  I
> know
> it's *not* LINT, but maybe it's just a terminology thing that's hanging
> things
> up.  Treat -w like LINT and allow the compiler to compile through the
> 'warnings'.  Maybe instead of 'warnings', they should be 'code that you
> are
> highly advised to look at, because the compiler doesn't agree with you'.

The trouble with that is it sounds good on paper, but in practice those warnings scroll up and off the screen, and are missed.

> 
> Thanks for the input, Micke.
> 
> Here is a listing of GUI toolkits(it's been around for a while); it isn't up to date, but you should get people started.
> 
> http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
> 
> P.S. Should we, maybe start a new thread? This one is getting kind of long.

Yeah, I have followed that list for a few years now.
Unfortunately there is a shortage of mature portable C libraries that are
maintained.
GTK works, but the api and complexity sucks (my opinion).
But as mono is using it, it should have a somewhat bright future after all.

Walter Bright wrote:

>>From the Qt# home page, they say there are 476 classes converted...
> 
> That's just one heck of a lot of work to do.

I don't how many classes there are in SWT, and maybe not
all of them are needed for D (some might be Java specific),
but if effectively triples* if you now plan on porting all
of them over to D (as opposed to just porting C++ wrappers)

So I would think that DWT will end up having many *more* ?

--anders

* assuming you want to support three platforms
  (Windows, GTK, Mac OS X). Multiply further,
  for supporting any other wanted platforms...