"Derek Parnell" <derek@psych.ward> wrote in message news:ltjlj9k2celp$.4bi3tevsw23m.dlg@40tude.net...
> On Sat, 24 Sep 2005 23:50:00 -0700, Walter Bright wrote:
>
> > "Derek Parnell" <derek@psych.ward> wrote in message news:18dquf8vcj3pn$.16w7fqn2hhp6o.dlg@40tude.net...
> >> Can you please alter DMD to use both sc.ini file *and* a user defined
.ini
> >> file (maybe site_sc.ini) such that the definitions in the user file override the ones in sc.ini. That way, whenever you distribute a new
DMD
> >> you won't wipe out my changes to sc.ini.
> >
> > Mark yours as read-only, and it should survive.
>
> But then I don't get any new things that you might have created in DMD's sc.ini file.

I haven't changed that file in years <g>.

"Derek Parnell" <derek@psych.ward> wrote in message news:17ovuy6hovtgu.kydtinvs4pq$.dlg@40tude.net...
> (1) There is something wrong with the .ddoc files. They seem to be completely ignored. I had to rename manual.ddoc to manual.d to get
anything
> at all with this command line ...
>
>    dmd -D -o- config.ddoc manual.ddoc

The compiler is looking for a .d file, as it is completely built around generating documentation for a D module, which is in a .d file. All the .ddoc files are are macro definitions. Documentation is not generated from .ddoc files.

> (2) I don't get anything generated if the file does not contain a module statement. I was hoping to have .ddoc files that only contain
documentation
> comments. These would be used to create End User manuals rather than documentation for developers.

I never thought of that. But you can just put in a dummy module declaration, and then in the DDOC macro insert your own TITLE. Ddoc is built around comments being attached to declarations. Also, it'll have to be a .d file, not a .ddoc file.

> (3) This ...
>
>   $(D_CODE
>       $(B pragma)( $(I name) );
>       $(B pragma)( $(I name) , $(I option) [ $(I option) ] );
>   )
>
> produced this output ...
>
> <pre class="d_code">
>       <b> pragma </b>
> ( <i> name </i>
>  );
>       <b> pragma </b>
> ( <i> name </i>
>  , <i> option </i>
>  [ <i> option </i>
>  ] );
> </pre>
>
> So it seems that a lot of line breaks were inserted by DMD.

Yes, that looks like a bug.

> (4) I want to have unmatched parenthesis inside a macro invocation. May I suggest that macro invocation can be kicked off by any sort of brackets. For example ...
>
>    $(B)
>    ${B}
>    $[B]
>    $<B>
>
> all invoke the B macro. Then I could do this ...
>
>     $[B pragma(] name $B[);]

Ok, I see what you're trying to do. Let me think about it.

> (5) This ...
>
> Example 1
>  $(D_CODE
>       // This app needs the MyGUI.lib library to be used.
>       version(build) { pragma(link, MyGUI); }
>  )
>
>  Example 2
>  $(D_CODE
>
>       // This app needs the a DB library and TCP library to be used.
>       version(build) { pragma(link, EuDB, TCP4Win); }
>  )
>
> produced this output ...
>
> Example 1
> <pre class="d_code">
>       // This app needs the MyGUI.lib library to be used.
>       version(build) { pragma(link, MyGUI); }
> </pre>
>
> </p>
> <p>
> Example 2
> <pre class="d_code">
> </pre>
>
> <p>
>       // This app needs the a DB library and TCP library to be used.
>       version(build) { pragma(link, EuDB, TCP4Win); }
> </p>

Wierd. Looks like a bug.

Walter Bright wrote:
> Extensive update of Ddoc, www.digitalmars.com/d/ddoc.html
> 
> http://www.digitalmars.com/d/changelog.html

I see you're gradually getting back into working on the compiler itself.

Has this come your way?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28426

And waiting on pending peeves is getting tiring again.  It would be helpful if you gave feedback on the progress reviews at least from time to time.  The most recent one is here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28449

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

dmd.133 breaks nested functions in some weird way :( I haven't been unable to isolate a test case yet, but it causes Access Violations in places where they make no sense. I'll try to send a test case, but the code that caused that AVs ripped out of a larger program worked fine. My program wasn't the only one that experienced that same problem.

Tom S wrote:
> dmd.133 breaks nested functions in some weird way :( I haven't been unable to
> isolate a test case yet, but it causes Access Violations in places where they
> make no sense. I'll try to send a test case, but the code that caused that AVs
> ripped out of a larger program worked fine. My program wasn't the only one that
> experienced that same problem.
> 
> 

Weird. The changelog doesn't say anything about nested functions.
But I have an impression that Walter did't always list all the major changes. For example, some int types are replaced by size_t in Phobos since dmd 0.133 without a note in the changelog. That unexpectedly breaks existing code, by the way.

"zwang" <nehzgnaw@gmail.com> wrote in message news:dh94fa$1gg9$1@digitaldaemon.com...
> Weird. The changelog doesn't say anything about nested functions.

I didn't change anything with nested functions.

> But I have an impression that Walter did't always list all the major changes. For example, some int types are replaced by size_t in Phobos since dmd 0.133 without a note in the changelog. That unexpectedly breaks existing code, by the way.

I don't see how it can?

Sorry. I want to get Ddoc in a usable state, then I'll turn back to the usual bug fixing in D.

On Mon, 26 Sep 2005 08:59:08 -0700, Walter Bright <newshound@digitalmars.com> wrote:
> "zwang" <nehzgnaw@gmail.com> wrote in message
> news:dh94fa$1gg9$1@digitaldaemon.com...
>> Weird. The changelog doesn't say anything about nested functions.
>
> I didn't change anything with nested functions.
>
>> But I have an impression that Walter did't always list all the major
>> changes. For example, some int types are replaced by size_t in Phobos
>> since dmd 0.133 without a note in the changelog. That unexpectedly breaks
>> existing code, by the way.
>
> I don't see how it can?

I suspect zwang is referring to the std.string.find bug reported recently which now uses a size_t, so...

int find(char[] s, char[] sub) where s = "a" and sub = "abc"
..
size_t sublength = sub.length;
...
size_t imax = s.length - sublength + 1;

gives imax == a very large _positive_ number.

No?

Regan

Regan Heath wrote:
> On Mon, 26 Sep 2005 08:59:08 -0700, Walter Bright  <newshound@digitalmars.com> wrote:
> 
>> "zwang" <nehzgnaw@gmail.com> wrote in message
>> news:dh94fa$1gg9$1@digitaldaemon.com...
>>
>>> Weird. The changelog doesn't say anything about nested functions.
>>
>>
>> I didn't change anything with nested functions.
>>
>>> But I have an impression that Walter did't always list all the major
>>> changes. For example, some int types are replaced by size_t in Phobos
>>> since dmd 0.133 without a note in the changelog. That unexpectedly  breaks
>>> existing code, by the way.
>>
>>
>> I don't see how it can?
> 
> 
> I suspect zwang is referring to the std.string.find bug reported recently  which now uses a size_t, so...
> 
> int find(char[] s, char[] sub) where s = "a" and sub = "abc"
> ..
> size_t sublength = sub.length;
> ...
> size_t imax = s.length - sublength + 1;
> 
> gives imax == a very large _positive_ number.
> 
> No?
> 
> Regan


That's the bug I was referring to.
Has anyone reviewed other Phobos functions that might also be affected by this signed-to-unsigned change?

On Mon, 26 Sep 2005 08:59:08 -0700, Walter Bright wrote:

> "zwang" <nehzgnaw@gmail.com> wrote in message news:dh94fa$1gg9$1@digitaldaemon.com...
>> Weird. The changelog doesn't say anything about nested functions.
> 
> I didn't change anything with nested functions.
> 
>> But I have an impression that Walter did't always list all the major changes. For example, some int types are replaced by size_t in Phobos since dmd 0.133 without a note in the changelog. That unexpectedly breaks existing code, by the way.
> 
> I don't see how it can?

You're kidding, right? Changing a parameter from a signed type to an unsigned type has got to have an impact, especially as DMD doesn't complain about implicit conversions between them. Remember that negative values in 'int' types appear to be positive values in 'uint' types. Whenever you calculate the difference between to numbers the result must be assumed to be a signed value.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
27/09/2005 11:05:37 AM