On Mon, 31 Jul 2006, Joseph Lisee wrote:

> In article <e5l5v8$1g7j$1@digitaldaemon.com>,
>  Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> 
> > Lars Ivar Igesund wrote:
> > > Because not all the users will have access to the source, or be inclined to see it. Unless the user get's a readable/understandable assert message he/she might not get enough information to actually reproduce a test case for the developer to peruse.
> > > 
> > > Walter, this is a no-brainer, please put it in.
> > 
> > ++votes;
> > 
> > /+
> > when you release your app to some testing team, you might want to leave
> > asserts in. While an error message containing the line number and
> > filename could be helpful, an additional message could be priceless.
> > E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the
> > 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which
> > might mean some mem corruption or forgetting a .dup somewhere in your
> > code. You'd instead go searching for some logic problems that wouldn't
> > solve the problem.
> > +/
> 
> I vote for the assert(condition, "msg"), construct as well.
> 
> CXX Test and JUnit have spoiled me.  You can't even do assert(1 == 0 && "The laws of math have been changed"), which is trick I use in the C++ all the time.  Is having a message with the assert going to hurt anything?
> 
> -Joseph Lisee

Um..  you're voting for a feature that was added several releases ago.

Later,
Brad

Joseph Lisee wrote:
> In article <e5l5v8$1g7j$1@digitaldaemon.com>,
>  Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Because not all the users will have access to the source, or be inclined to
>>> see it. Unless the user get's a readable/understandable assert message
>>> he/she might not get enough information to actually reproduce a test case
>>> for the developer to peruse.
>>>
>>> Walter, this is a no-brainer, please put it in.
>> ++votes;
>>
>> /+
>> when you release your app to some testing team, you might want to leave asserts in. While an error message containing the line number and filename could be helpful, an additional message could be priceless. E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which might mean some mem corruption or forgetting a .dup somewhere in your code. You'd instead go searching for some logic problems that wouldn't solve the problem.
>> +/
> 
> I vote for the assert(condition, "msg"), construct as well.

This feature was added a number of builds ago.


Sean

In article <ealh03$htp$1@digitaldaemon.com>, Sean Kelly <sean@f4.ca> wrote:

> Joseph Lisee wrote:
> > In article <e5l5v8$1g7j$1@digitaldaemon.com>,
> >  Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> > 
> >> Lars Ivar Igesund wrote:
> >>> Because not all the users will have access to the source, or be inclined
> >>> to
> >>> see it. Unless the user get's a readable/understandable assert message
> >>> he/she might not get enough information to actually reproduce a test case
> >>> for the developer to peruse.
> >>>
> >>> Walter, this is a no-brainer, please put it in.
> >> ++votes;
> >>
> >> /+
> >> when you release your app to some testing team, you might want to leave
> >> asserts in. While an error message containing the line number and
> >> filename could be helpful, an additional message could be priceless.
> >> E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the
> >> 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which
> >> might mean some mem corruption or forgetting a .dup somewhere in your
> >> code. You'd instead go searching for some logic problems that wouldn't
> >> solve the problem.
> >> +/
> > 
> > I vote for the assert(condition, "msg"), construct as well.
> 
> This feature was added a number of builds ago.
> 
> 
> Sean

That is what happens when I don't read the documentation close enough and not pay attention to message dates.

It should also be noted that the in the Contract Programming page of the documentation it only mentions "assert(expression)".  While It does link to the full documentation on the assert expression should that page also mention the option for a message?

Sorry to clutter the mailing list.  I will just go back to my attempt at wrapping C++ with doxygen + python. Yes I am aware of the D module for Swig, but I am going for something more elegant and this effort is a good C++, Python, and D programming exercise.

-Joseph

Joseph Lisee wrote:
> In article <ealh03$htp$1@digitaldaemon.com>, Sean Kelly <sean@f4.ca> wrote:
> 
> 
>>Joseph Lisee wrote:
>>
>>>In article <e5l5v8$1g7j$1@digitaldaemon.com>,
>>> Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
>>>
>>>
>>>>Lars Ivar Igesund wrote:
>>>>
>>>>>Because not all the users will have access to the source, or be inclined to
>>>>>see it. Unless the user get's a readable/understandable assert message
>>>>>he/she might not get enough information to actually reproduce a test case
>>>>>for the developer to peruse.
>>>>>
>>>>>Walter, this is a no-brainer, please put it in.
>>>>
>>>>++votes;
>>>>
>>>>/+
>>>>when you release your app to some testing team, you might want to leave asserts in. While an error message containing the line number and filename could be helpful, an additional message could be priceless. E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which might mean some mem corruption or forgetting a .dup somewhere in your code. You'd instead go searching for some logic problems that wouldn't solve the problem.
>>>>+/
>>>
>>>I vote for the assert(condition, "msg"), construct as well.
>>
>>This feature was added a number of builds ago.
>>
>>
>>Sean
> 
> 
> That is what happens when I don't read the documentation close enough and not pay attention to message dates.
> 
> It should also be noted that the in the Contract Programming page of the documentation it only mentions "assert(expression)".  While It does link to the full documentation on the assert expression should that page also mention the option for a message?
> 
> Sorry to clutter the mailing list.  I will just go back to my attempt at wrapping C++ with doxygen + python. Yes I am aware of the D module for Swig, but I am going for something more elegant and this effort is a good C++, Python, and D programming exercise.

Are you aware of my Pyd library? It's a wrapper around the Python API, analogous to Boost::Python, but for D. It's probably not quite ready for serious use (for one thing, I haven't really documented it yet; for another, I haven't added Linux support yet, though it's going in Real Soon Now (tm)), but it might be worth taking a look at.

So yeah, this is yet another unfinished, undocumented open-source project, but it is still capable of the following and more:

[testdll.d]
import pyd.pyd;
import std.stdio;

class Foo {
    int m_i;
    this() { m_i = 0; }
    this(int i) { m_i = i; }

    void foo() { writefln("i = ", m_i); }
    int i() { return m_i; }
    void i(int j) { m_i = j; }
}

void bar(int i) {
    writefln("You entered: ", i);
}

extern(C)
export void inittestdll() {
    // Function wrapping
    def!(bar, "bar");

    module_init("testdll");

    // Class wrapping
    wrapped_class!(Foo, "Foo") f;
    // Constructor wrapping
    f.init!(tuple!(int));
    // Member function wrapping
    f.def!(Foo.foo, "foo");
    // Property wrapping
    f.prop!(Foo.i, "i");
    finalize_class(f);
}
// EOF

And in Python:

>>> import testdll
>>> testdll.bar(20)
You entered: 20
>>> f = testdll.Foo(30)
>>> f.i
30
>>> f.i = 50
>>> f.foo()
i = 50

It also comes with an extension to Python's distutils (David Rushby's CeleriD), to make building these extensions so much easier.

Even if you don't use Pyd, the project has what I believe is the most complete version of the Python API header, which would probably be useful to you:
http://dsource.org/projects/pyd/browser/trunk/infrastructure/python/headers/python.d

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

In article <eao805$2svv$1@digitaldaemon.com>,
 Kirk McDonald <kirklin.mcdonald@gmail.com> wrote:


> Are you aware of my Pyd library? It's a wrapper around the Python API, analogous to Boost::Python, but for D. It's probably not quite ready for serious use (for one thing, I haven't really documented it yet; for another, I haven't added Linux support yet, though it's going in Real Soon Now (tm)), but it might be worth taking a look at.
> 
> So yeah, this is yet another unfinished, undocumented open-source project, but it is still capable of the following and more:
> 
> [testdll.d]
> import pyd.pyd;
> import std.stdio;
> 
> class Foo {
>      int m_i;
>      this() { m_i = 0; }
>      this(int i) { m_i = i; }
> 
>      void foo() { writefln("i = ", m_i); }
>      int i() { return m_i; }
>      void i(int j) { m_i = j; }
> }
> 
> void bar(int i) {
>      writefln("You entered: ", i);
> }
> 
> extern(C)
> export void inittestdll() {
>      // Function wrapping
>      def!(bar, "bar");
> 
>      module_init("testdll");
> 
>      // Class wrapping
>      wrapped_class!(Foo, "Foo") f;
>      // Constructor wrapping
>      f.init!(tuple!(int));
>      // Member function wrapping
>      f.def!(Foo.foo, "foo");
>      // Property wrapping
>      f.prop!(Foo.i, "i");
>      finalize_class(f);
> }
> // EOF
> 
> And in Python:
> 
>  >>> import testdll
>  >>> testdll.bar(20)
> You entered: 20
>  >>> f = testdll.Foo(30)
>  >>> f.i
> 30
>  >>> f.i = 50
>  >>> f.foo()
> i = 50
> 
> It also comes with an extension to Python's distutils (David Rushby's CeleriD), to make building these extensions so much easier.
> 
> Even if you don't use Pyd, the project has what I believe is the most
> complete version of the Python API header, which would probably be
> useful to you:
> http://dsource.org/projects/pyd/browser/trunk/infrastructure/python/headers/py
> thon.d

I have seen your library and I think it will be a great addition to D, what parts of linux support are missing?

I don't think PyD will apply to my project.  Let me get incredibly off topic and explain a little more. I am trying to make a program that generates wrappers for C++ programs so you can use them in D.  My current plan is to process the XML output from Doxygen with Python and the ElementTree library.  I will then generate a C++ file with a C interface to the class and D wrapper file for each class.  Something similar to below:

// C++ Code
class MyClass {
   int m_num;
public:
    MyClass(int num) {
        m_num = num;
    }

    int getNum() {
        return m_num;
    }
};

// C Wrapper Code
extern "C"
{
    void* MyClass_new(int num) {
        return (void*)(new myClass(num));
    }

    int MyClass_getNum(void* obj) {
        return ((myClass*)obj)->getNum();
    }

    void MyClass_delete(void* obj) {
        delete (myClass*)obj;
    }
}

// D wrapper class
extern (C)
{
    void* MyClass_new(int num);
    int MyClass_getNum(void* obj);
    void MyClass_delete(void* obj);
}

class MyClass {
    private void* cppObj;

    this(int num) {
        cppObj = MyClass_new(num);
    }

    ~this() {
        MyClass_delete(cppObj);
    }

    int getNum() {
        return MyClass_getNum(cppObj);
    }
}

That is a very basic example and doesn't handle exception being thrown from the C++ code.  I haven't start work on the generator yet.  I am currently testing my ideas on the following issues:

  -properly handling the passing of D wrapped C++ classes to and from
the C++ code.
  -using directors at the bottom of the inheritance tree to properly
pass virtual function calls of to inherited D class
  -Throwing C++ and D exceptions through the interface that has C
linkage.
  -Mapping of types from C++ to C to D.

If this ever gets off the ground I am thinking of calling it WrapeD, the lack of two p's is intentional.  I hope to have simpler interface file system than swig.  Something looks more like SCons build files.

-Joseph

Joseph Lisee wrote:
> I have seen your library and I think it will be a great addition to D, what parts of linux support are missing?
> 

Mostly I need to re-write CeleriD's DCompiler classes to add support for gdc. Building shared libraries with DMD on Linux doesn't work, but using gdc does. This is farily tedious (it basically means re-writing the entire dcompiler.py module), but I'm bashing away at it.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

I've done something close to what you discribe using Python ( C++ wrapping using the output of gccxml ). You can have a look at it on http://remy.moueza.free.fr. Gregor Richards has done better with BCD, available on dsource, only using D and gccxml. Swig also output xml, thus it is also possible to use it as an alternative to gccxml. I didn't know doxygen could output an xml view of its analysis.
Good luck.

> I don't think PyD will apply to my project.  Let me get incredibly off topic and explain a little more. I am trying to make a program that generates wrappers for C++ programs so you can use them in D.  My current plan is to process the XML output from Doxygen with Python and the ElementTree library.  I will then generate a C++ file with a C interface to the class and D wrapper file for each class.  Something similar to below:
> 
> // C++ Code
> class MyClass {
>    int m_num;
> public:
>     MyClass(int num) {
>         m_num = num;
>     }
> 
>     int getNum() {
>         return m_num;
>     }
> };
> 
> // C Wrapper Code
> extern "C"
> {
>     void* MyClass_new(int num) {
>         return (void*)(new myClass(num));
>     }
> 
>     int MyClass_getNum(void* obj) {
>         return ((myClass*)obj)->getNum();
>     }
> 
>     void MyClass_delete(void* obj) {
>         delete (myClass*)obj;
>     }
> }
> 
> // D wrapper class
> extern (C)
> {
>     void* MyClass_new(int num);
>     int MyClass_getNum(void* obj);
>     void MyClass_delete(void* obj);
> }
> 
> class MyClass {
>     private void* cppObj;
> 
>     this(int num) {
>         cppObj = MyClass_new(num);
>     }
> 
>     ~this() {
>         MyClass_delete(cppObj);
>     }
> 
>     int getNum() {
>         return MyClass_getNum(cppObj);
>     }
> }
> 
> That is a very basic example and doesn't handle exception being thrown from the C++ code.  I haven't start work on the generator yet.  I am currently testing my ideas on the following issues:
> 
>   -properly handling the passing of D wrapped C++ classes to and from the C++ code.
>   -using directors at the bottom of the inheritance tree to properly pass virtual function calls of to inherited D class
>   -Throwing C++ and D exceptions through the interface that has C linkage.
>   -Mapping of types from C++ to C to D.
> 
> If this ever gets off the ground I am thinking of calling it WrapeD, the lack of two p's is intentional.  I hope to have simpler interface file system than swig.  Something looks more like SCons build files.
> 
> -Joseph

In article <eapnnc$14sh$1@digitaldaemon.com>,
 "Rémy J. A. Mouëza" <ray.jay.ay.moueza@do.not.spam.gmail.com> wrote:

> I've done something close to what you discribe using Python ( C++
> wrapping using the output of gccxml ). You can have a look at it on
> http://remy.moueza.free.fr. Gregor Richards has done better with BCD,
> available on dsource, only using D and gccxml. Swig also output xml,
> thus it is also possible to use it as an alternative to gccxml. I didn't
> know doxygen could output an xml view of its analysis.
> Good luck.

I looked at your project about a week ago but did not have gccxml installed at the time and all of the comments as to what works, and what didn't work are in French.  I will give it a go and see what kind of code it produces.

Could you translate the comments to French, or maybe just put the information on the website you provided above?

-Joseph

Joseph Lisee a écrit :
> I looked at your project about a week ago but did not have gccxml installed at the time and all of the comments as to what works, and what didn't work are in French.  I will give it a go and see what kind of code it produces.  
> 
> Could you translate the comments to French, or maybe just put the information on the website you provided above?
> 
> -Joseph

Yes, I can.
By the time I've written those comments they were kind of log of the progress I was doing. They just lists problems that happened and that I resolved and a few things to improve. They were not intended to be used  as documentation.
I haven't updated the site for a long time, I will first resolve my ftp access and ftp client problems first and update the site with a translated version of these log messages.

Rémy J. A. Mouëza a écrit :
> Joseph Lisee a écrit :
>> I looked at your project about a week ago but did not have gccxml installed at the time and all of the comments as to what works, and what didn't work are in French.  I will give it a go and see what kind of code it produces. Could you translate the comments to French, or maybe just put the information on the website you provided above?
>>
>> -Joseph
> 
> Yes, I can.
> By the time I've written those comments they were kind of log of the progress I was doing. They just lists problems that happened and that I resolved and a few things to improve. They were not intended to be used  as documentation.
> I haven't updated the site for a long time, I will first resolve my ftp access and ftp client problems first and update the site with a translated version of these log messages.

As I had problems with the firewall of my university and ftp connection,I used my wiki (I had forgotten I set up one, and just started to use it).
Translation of the french comments is available:
http://remy.moueza.free.fr/wikini/wakka.php?wiki=DeeWrapperGenerator

And I have written a few line on my feelings about that wrapper generator.