www.digitalmars.com         C & C++   DMDScript  

D - dmd 0.46 release

reply "Walter" <walter digitalmars.com> writes:
www.digitalmars.com/d/changelog.html
Oct 22 2002
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Here's a weird one.  I have a function:

    Color ColorBlend (Color a, Color b, ubyte t);

And a function usage:

    return ColorBlend (colors [c - 1], colors [c], t);

When Color is a typedef uint, it works fine.  When color is a struct 
(which is either each component separate or a wrapper for the uint), I 
get "Internal error: e2ir.c 119".  In the latter case, I can fix it by:

    Color ca = colors [c - 1];
    Color cb = colors [c];
    return ColorBlend (ca, cb, t);

It otherwise compiles, but is producing black and white when the struct 
isn't just a uint wrapper.  Here's another one that messes up:

    Color eval (float x, float y)
    {
        return colors [0];
    }

This returns what appears to be Color.init, while this:

    Color eval (float x, float y)
    {
        Color c = colors [0];
        return c;
    }

Works "properly".  Now, to the grayscale.  I can switch between:

    struct Color { uint value; }
    struct Color { ubyte r, g, b, a; }

With a version switch.  The first one produces proper colors, but the 
second one is grayscale in an odd way.  Changing those to:

    struct Color { int r, g, b, a; }

Fixes it.  I played around and discovered that using:

    struct Color { ubyte r, g, b, a, dontusethisone; }

Fixes it.  So maybe it's a returning-in-register concern.
Oct 22 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I'll have a look. Is this problem new with 0.46?
Oct 22 2002
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:
 I'll have a look. Is this problem new with 0.46?

Yup, this is the same code that wasn't working with 0.45.
Oct 22 2002
prev sibling parent "Andrew Edwards" <crxace13 comcast.net> writes:
While you're at it, can you have a look at stream.d? The unit test assumes
that line 1150 will write 18 characters when infact it will only write 17.

Thanks,
Andrew

"Walter" <walter digitalmars.com> wrote in message
news:ap3bcn$ia5$1 digitaldaemon.com...
| I'll have a look. Is this problem new with 0.46?
|
|
Oct 22 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
I need some help here. What is "color" declared as?

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:ap3a43$h2r$1 digitaldaemon.com...
 Here's a weird one.  I have a function:

     Color ColorBlend (Color a, Color b, ubyte t);

 And a function usage:

     return ColorBlend (colors [c - 1], colors [c], t);

 When Color is a typedef uint, it works fine.  When color is a struct
 (which is either each component separate or a wrapper for the uint), I
 get "Internal error: e2ir.c 119".  In the latter case, I can fix it by:

     Color ca = colors [c - 1];
     Color cb = colors [c];
     return ColorBlend (ca, cb, t);

 It otherwise compiles, but is producing black and white when the struct
 isn't just a uint wrapper.  Here's another one that messes up:

     Color eval (float x, float y)
     {
         return colors [0];
     }

 This returns what appears to be Color.init, while this:

     Color eval (float x, float y)
     {
         Color c = colors [0];
         return c;
     }

 Works "properly".  Now, to the grayscale.  I can switch between:

     struct Color { uint value; }
     struct Color { ubyte r, g, b, a; }

 With a version switch.  The first one produces proper colors, but the
 second one is grayscale in an odd way.  Changing those to:

     struct Color { int r, g, b, a; }

 Fixes it.  I played around and discovered that using:

     struct Color { ubyte r, g, b, a, dontusethisone; }

 Fixes it.  So maybe it's a returning-in-register concern.

Oct 22 2002
parent Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:
 I need some help here. What is "color" declared as?

I don't mention such a symbol. If you mean Color, it depended upon version switches, one of: typedef uint Color; // Typedef'd mode struct { uint value; } Color; // Wrapped mode struct { ubyte r, g, b, a; } Color; // Struct mode Typedef'd mode had no problems, except that it and Wrapped mode display invalid colors when optimising (some kind of shifting problem - I need to look into it more). Wrapped mode and Struct mode don't handle returns from array indices properly: Color colors [] = new Color [1]; return a [0]; /* returns Color.init or possibly just nonsense */ Struct mode does not work unless if I include another field that makes it larger than four bytes. When it's normal, all field accesses appear to be returning .r; that it's fixed by kicking it to be larger than four bytes indicates to me that it's a register return problem. Struct mode also can't handle passing an array index of it to a function: Color colors [] = new Color [1]; void func (Color c); func (colors [0]); /* "Internal error: e2ir.c 119" */
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:ap3a43$h2r$1 digitaldaemon.com...
 
Here's a weird one.  I have a function:

    Color ColorBlend (Color a, Color b, ubyte t);

And a function usage:

    return ColorBlend (colors [c - 1], colors [c], t);

When Color is a typedef uint, it works fine.  When color is a struct
(which is either each component separate or a wrapper for the uint), I
get "Internal error: e2ir.c 119".  In the latter case, I can fix it by:

    Color ca = colors [c - 1];
    Color cb = colors [c];
    return ColorBlend (ca, cb, t);

It otherwise compiles, but is producing black and white when the struct
isn't just a uint wrapper.  Here's another one that messes up:

    Color eval (float x, float y)
    {
        return colors [0];
    }

This returns what appears to be Color.init, while this:

    Color eval (float x, float y)
    {
        Color c = colors [0];
        return c;
    }

Works "properly".  Now, to the grayscale.  I can switch between:

    struct Color { uint value; }
    struct Color { ubyte r, g, b, a; }

With a version switch.  The first one produces proper colors, but the
second one is grayscale in an odd way.  Changing those to:

    struct Color { int r, g, b, a; }

Fixes it.  I played around and discovered that using:

    struct Color { ubyte r, g, b, a, dontusethisone; }

Fixes it.  So maybe it's a returning-in-register concern.


Oct 22 2002
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
When using WinMain, nothing is setup in Phobos - particularly static 
constructors.  Is there a single entry point that I can call to 
kickstart it?  Or is it the same sequence as with a DLL:

     gc_init ();
     _minit ();
     _moduleCtor ();
     _moduleUnitTests ();
     ... body ...
     gc_term ();

DInit () and DTerm () would be nicer.  Perhaps we should also define a 
couple new versions.  Specifically:

     version = WinMain; /* Won't spawn a console, wraps with WinMain */
     //version = DLLMain; /* Handles DLLMain instead */

     int main (char [] [] argv)
     {
         hinst = GetModuleHandleA (null);
         ...
     }

I'm working on a windows wrapper, similar to Pavel's project, but with 
more portable intentions.  This would remove the need for putting an 
entry point in the library and calling a library-specific main from there.
Oct 22 2002
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
WinMain sucks.  There's nothing there that can't be obtained later.  I've
been using the VC /entrypoint:mainCRTStartup for quite some time now without
needing WinMain at all.

I've often had issues in C++ trying to figure out if I'm compiling a library
to a .DLL or a .EXE.  I usually supply both WinMain and DllMain just in case
and let the linker sort it out.

Sean


 DInit () and DTerm () would be nicer.  Perhaps we should also define a
 couple new versions.  Specifically:

      version = WinMain; /* Won't spawn a console, wraps with WinMain */
      //version = DLLMain; /* Handles DLLMain instead */

      int main (char [] [] argv)
      {
          hinst = GetModuleHandleA (null);
          ...
      }

 I'm working on a windows wrapper, similar to Pavel's project, but with
 more portable intentions.  This would remove the need for putting an
 entry point in the library and calling a library-specific main from there.

Oct 22 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
There's an example in \dmd\samples\d\winsamp.d of how to do a WinMain(). I
admit it's primitive, but it's a start.

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:ap3tmu$2bp3$1 digitaldaemon.com...
 When using WinMain, nothing is setup in Phobos - particularly static
 constructors.  Is there a single entry point that I can call to
 kickstart it?  Or is it the same sequence as with a DLL:

      gc_init ();
      _minit ();
      _moduleCtor ();
      _moduleUnitTests ();
      ... body ...
      gc_term ();

 DInit () and DTerm () would be nicer.  Perhaps we should also define a
 couple new versions.  Specifically:

      version = WinMain; /* Won't spawn a console, wraps with WinMain */
      //version = DLLMain; /* Handles DLLMain instead */

      int main (char [] [] argv)
      {
          hinst = GetModuleHandleA (null);
          ...
      }

 I'm working on a windows wrapper, similar to Pavel's project, but with
 more portable intentions.  This would remove the need for putting an
 entry point in the library and calling a library-specific main from there.

Oct 22 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I wonder if this construct deserves any special support;  I find myself
using it alot:

if (x)
do
{
    blah();
} while (x);

it is basically

while (x)
{
    blah();
}

but having the loop condition at the bottom is usually faster.  I suppose
compilers do this automatically most of the time.

What about:

while (true)
{
    blah();
    if (x == end) break;
    ++x;
}

I'd love to have a "loop" construct that replaces the need for "while(true)"
and "for(;;)".

Another construct that is used alot:

do
{
    a = next();
    if (a==x)
        continue;
    if (a==y)
        continue;
} while(0);

This is equivalent to:

start:
    a = next();
    if (a==x)
        goto start;
    if (a==y)
        goto start;

I think some other languages (IMP? Icon?) have loop constructs that could be
worth looking at.

Sean
Oct 22 2002
next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
One loop construct that python has that 
I like is:

while(x):
if y:
break # Do no execute else
else:
# go here is loop terminates because x is not true

You can do the same with the for statement.
I like it because I often want to do something
if the loop terminates naturally rather that with
a break statement.  The only odd thing about it is
using the "else" keyword for this.  It doesn't 
quite fit.
Oct 22 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:ap41fj$8dt$1 digitaldaemon.com...
 I wonder if this construct deserves any special support;  I find myself
 using it alot:

 if (x)
 do
 {
     blah();
 } while (x);

 it is basically

 while (x)
 {
     blah();
 }

 but having the loop condition at the bottom is usually faster.  I suppose
 compilers do this automatically most of the time.

The compiler will do that optimization automatically (it's called "loop rotation").
 What about:

 while (true)
 {
     blah();
     if (x == end) break;
     ++x;
 }

 I'd love to have a "loop" construct that replaces the need for

 and "for(;;)".

Those are such common idioms, I don't see much benefit in replacing them with a keyword.
 Another construct that is used alot:

 do
 {
     a = next();
     if (a==x)
         continue;
     if (a==y)
         continue;
 } while(0);

 This is equivalent to:

 start:
     a = next();
     if (a==x)
         goto start;
     if (a==y)
         goto start;

 I think some other languages (IMP? Icon?) have loop constructs that could

 worth looking at.

There are endless ways to write loops <g>.
Oct 22 2002
parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I guess what I'm asking is if anyone can think of any more loop constructs
that might currently be awkward using the run-of-the-mill for, while, do
loop constructs.  Things where you'd be tempted to use a goto.

Not very important I guess.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ap479o$1b6u$2 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:ap41fj$8dt$1 digitaldaemon.com...
 I wonder if this construct deserves any special support;  I find myself
 using it alot:

 if (x)
 do
 {
     blah();
 } while (x);

 it is basically

 while (x)
 {
     blah();
 }

 but having the loop condition at the bottom is usually faster.  I


 compilers do this automatically most of the time.

The compiler will do that optimization automatically (it's called "loop rotation").
 What about:

 while (true)
 {
     blah();
     if (x == end) break;
     ++x;
 }

 I'd love to have a "loop" construct that replaces the need for

 and "for(;;)".

Those are such common idioms, I don't see much benefit in replacing them with a keyword.
 Another construct that is used alot:

 do
 {
     a = next();
     if (a==x)
         continue;
     if (a==y)
         continue;
 } while(0);

 This is equivalent to:

 start:
     a = next();
     if (a==x)
         goto start;
     if (a==y)
         goto start;

 I think some other languages (IMP? Icon?) have loop constructs that


 be
 worth looking at.

There are endless ways to write loops <g>.

Oct 23 2002