On Tue, 27 Sep 2005 12:51:00 +1200, 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?

Exactly my point I just posted. This really should be

  long imax = s.length - sublength + 1;

And then deal with situations where imax <= 0;

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

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

Walter's gotta have his fun, guys!  I would get so burned out fixing bug after bug after bug.

"Derek Parnell" <derek@psych.ward> wrote in message news:17ovuy6hovtgu.kydtinvs4pq$.dlg@40tude.net...
> (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[);]

The way to do this is:

    Macros:
        LPAREN = (
        RPAREN=)

    $(B pragma $(LPAREN)) name $(B $(RPAREN);)

It's not pretty, but it works.

On Mon, 26 Sep 2005 22:44:09 -0700, Walter Bright wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:17ovuy6hovtgu.kydtinvs4pq$.dlg@40tude.net...
>> (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[);]
> 
> The way to do this is:
> 
>     Macros:
>         LPAREN = (
>         RPAREN=)
> 
>     $(B pragma $(LPAREN)) name $(B $(RPAREN);)
> 
> It's not pretty, but it works.

Yuck! I hope this is just work around. _Ugly_ is not a good thing in documentation.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
27/09/2005 4:24:50 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:17ovuy6hovtgu.kydtinvs4pq$.dlg@40tude.net...
> (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.

I've got this one fixed now.


> (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>

This happens because of the order of evaluation. Macro processing is the last thing done. In the meantime, the blank line in Example 2 is seen as a paragraph break, so the first part is wrapped in $(P first part) and the second part in $(P second part). This gives the behavior you're seeing. If you want to have blank lines in a macro argument, I don't have a good solution at the moment. Counting parentheses is not a very good option, as there are the issues with unmatched parentheses in strings, comments, or just random text.

"Derek Parnell" <derek@psych.ward> wrote in message news:1tt8pbffpszbg$.19i0j58w3kgrb.dlg@40tude.net...
> On Mon, 26 Sep 2005 22:44:09 -0700, Walter Bright wrote:
> > The way to do this is:
> >
> >     Macros:
> >         LPAREN = (
> >         RPAREN=)
> >
> >     $(B pragma $(LPAREN)) name $(B $(RPAREN);)
> >
> > It's not pretty, but it works.
>
> Yuck! I hope this is just work around. _Ugly_ is not a good thing in documentation.

At one level I agree with you, at the other I'm worried about too many features that wind up stepping on each other, like the blank line problem in another message.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsxqknapw23k2f5@nrage.netwin.co.nz...
> 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?

Oops!

On Mon, 26 Sep 2005 23:36:16 -0700, Walter Bright wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:17ovuy6hovtgu.kydtinvs4pq$.dlg@40tude.net...
>> (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.
> 
> I've got this one fixed now.
> 
>> (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>
> 
> This happens because of the order of evaluation. Macro processing is the last thing done. In the meantime, the blank line in Example 2 is seen as a paragraph break, so the first part is wrapped in $(P first part) and the second part in $(P second part). This gives the behavior you're seeing. If you want to have blank lines in a macro argument, I don't have a good solution at the moment. Counting parentheses is not a very good option, as there are the issues with unmatched parentheses in strings, comments, or just random text.

Okay, so the work around is something like ...

 Example 1
  $(D_CODE // This app needs the MyGUI.lib library to be used. )
  $(D_CODE version(build) { pragma(link, MyGUI); } )

  Example 2
  $(D_CODE // This app needs the a DB library and TCP library to be used. )
  $(D_CODE version(build) { pragma(link, EuDB, TCP4Win); } )

Not pretty, and defeats the purpose of having a 'pre-formatted' section. Maybe you need to have a non-macro solution to this.

How about if when a macro invocation takes the form "$(macroname" and is the entire line, then the end of the invocation is a line consisting of a single ")". That would not require bracket counting and I've used this method in my own macro processor successfully.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
27/09/2005 5:30:01 PM

"Walter Bright" <newshound@digitalmars.com> wrote in news:dhapsq$2u9a$3@digitaldaemon.com:

> 
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsxqknapw23k2f5@nrage.netwin.co.nz...
>> 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?
> 
> Oops!
> 
> 

Oops = Objectoriented outragious programming solution

[G]

Jan

"Derek Parnell" <derek@psych.ward> wrote in message > How about if when a macro invocation takes the form "$(macroname" and is
> the entire line, then the end of the invocation is a line consisting of a single ")". That would not require bracket counting and I've used this method in my own macro processor successfully.

It might work, but I'm not sure. The fundamental problem is that the 'highlighter' is trying to highlight your code along with your own formatting and highlighting. There are bound to be conflicts.

I think the most practical solution would be to have special sections that are not touched by the highlighter. Sort of like how the ---- delimited code sections get a separate and distinct highlighter applied to them.