gmane.comp.programming.swig.devel

Re: Fw: Special Qt mode for SWIG

Dimitar Dobrev — 2013-05-17T18:32:52

    I'm not really sure about slots but signals do matter. Target languages may have specific features for analogous functionality (such as events in C#). So, knowing that a function is a signal gives the opportunity for better integration.
    Dimitar

________________________________
 From: William S Fulton <wsf< at >fultondesigns.co.uk>
To: Peter McKinna <peter.mckinna< at >gmail.com> 
Cc: Dimitar Dobrev <dpldobrev< at >yahoo.com>; "swig-devel< at >lists.sourceforge.net" <swig-devel< at >lists.sourceforge.net> 
Sent: Friday, May 17, 2013 8:53 PM
Subject: Re: [Swig-devel] Fw: Special Qt mode for SWIG

From my quick look at the QT macros, a lot of them can be #define'd 
away to nothing. Some, like Q_PROPERTY can probably be expanded into 
equivalent accessors (get/set methods) on the class, or accessors into a 
%extend block by defining a SWIG/C macro to write the accessors.

From what I can make out Q_SIGNALS/Q_SLOTS/Q_SIGNAL/Q_SLOT macros 
expand into keywords signal/slot/signal/slot. These are clearly easy to 
get rid of by the preprocessor. In doing so, you'll lose information 
that the methods are signals/slots. Does that matter from the target 
language point of view? If it does matter, then these keywords will need 
to handled with additions to SWIG.

It certainly looks feasible, but may require a some development / 
additional enhancements in SWIG.

William

On 17/05/13 01:18, Peter McKinna wrote:
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Fw: Special Qt mode for SWIG

William S Fulton — 2013-05-17T17:53:16

 From my quick look at the QT macros, a lot of them can be #define'd 
away to nothing. Some, like Q_PROPERTY can probably be expanded into 
equivalent accessors (get/set methods) on the class, or accessors into a 
%extend block by defining a SWIG/C macro to write the accessors.

 From what I can make out Q_SIGNALS/Q_SLOTS/Q_SIGNAL/Q_SLOT macros 
expand into keywords signal/slot/signal/slot. These are clearly easy to 
get rid of by the preprocessor. In doing so, you'll lose information 
that the methods are signals/slots. Does that matter from the target 
language point of view? If it does matter, then these keywords will need 
to handled with additions to SWIG.

It certainly looks feasible, but may require a some development / 
additional enhancements in SWIG.

William



On 17/05/13 01:18, Peter McKinna wrote:


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Abstract base classes to interfaces conversion

Brant K. Kyser — 2013-05-17T15:12:56

My project has two types of classes that contain pure virtual methods. 
The first is similar to your case, where the class only contains pure 
virtual methods. In this case, the desired result it to have swig 
generate a C# or Java interface. The second case is classes that contain 
a mixture of pure virtual methods and non-virtual methods. For this 
second case, the desired result is for swig to generate an abstract C# 
or Java class where the pure virtual methods are abstract.

Currently, swig generates a C# and Java class with non-abstract methods 
for the pure virtual methods. This creates confusion to developers 
implementing the methods in the target language and causes runtime 
errors when they fail to implement all of the methods.

Brant

On 5/16/13 10:39 AM, Vladimir Kalinin wrote:



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Fw: Special Qt mode for SWIG

Dimitar Dobrev — 2013-05-17T10:10:19

From: Peter McKinna <peter.mckinna< at >gmail.com>

To: Dimitar Dobrev <dpldobrev< at >yahoo.com> 
Cc: "swig-devel< at >lists.sourceforge.net" <swig-devel< at >lists.sourceforge.net> 
Sent: Friday, May 17, 2013 3:18 AM
Subject: Re: [Swig-devel] Fw: Special Qt mode for SWIG

Hi,

 Yes certainly feasible. In fact I have already swigged a fair few of the 
qcore h files, and enough of the qgui  ones to build a few working test 
programs. Not sure if you need a qt mode, although there might be a case for it. 
  I have only done this for modula3 so a lot of your qt 
specific typemaps would have to be redone for python, java et al. Also 
you need some glue code for the signals and slots. The stuff I have at 
the moment it built on subclassing a dynamic qobject and is pretty 
clunky, no compile time support like pyeside. 
  When I began I had to null out a lot of the qt macros. 
Caused a lot of grief to swig. Once you have a decent set of typemaps, 
judicious use of apply works wonders and the average .i file for a qgui 
.h file is only a few lines long. Your mileage may vary in other 
languages of course. I confess I am not an expert swigger and hardly 
ever use c++ so I'm sure there are better ways of building a qt 
interface.

Regards Peter

________________________________

    Hi, Peter,

    Thank you for your reply. If your code is not closed source, may I ask you to share it? I do understand your approach is a little different but I'd love to have your work as reference. Thanks.

    Regards,
    Dimitar
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Fw: Special Qt mode for SWIG

Peter McKinna — 2013-05-17T00:18:18

Hi,

 Yes certainly feasible. In fact I have already swigged a fair few of the
qcore h files, and enough of the qgui  ones to build a few working test
programs. Not sure if you need a qt mode, although there might be a case
for it.
  I have only done this for modula3 so a lot of your qt specific typemaps
would have to be redone for python, java et al. Also you need some glue
code for the signals and slots. The stuff I have at the moment it built on
subclassing a dynamic qobject and is pretty clunky, no compile time support
like pyeside.
  When I began I had to null out a lot of the qt macros. Caused a lot of
grief to swig. Once you have a decent set of typemaps, judicious use of
apply works wonders and the average .i file for a qgui .h file is only a
few lines long. Your mileage may vary in other languages of course. I
confess I am not an expert swigger and hardly ever use c++ so I'm sure
there are better ways of building a qt interface.

Regards Peter


On Thu, May 16, 2013 at 11:11 PM, Dimitar Dobrev <dpldobrev< at >yahoo.com>wrote:

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Abstract base classes to interfaces conversion

Vladimir Kalinin — 2013-05-16T15:39:14

Hi Brant,

No, I didn't work on this project recently. You see - for my
applications it is enough to convert to interfaces C++ classes
containing only pure virtual functions and no data members.
Converting to interfaces the classes with data members and non-pure virtual
member functions is a lot more complicated, especially when/if virtual
inheritance is used. I definitely intend to finish this work (if no
one else will volunteer to do it), but I can't make any promises about
timing.

BTW, what do you think about the questions discussed in the previous
mail?

Best regards,
 Vladimir                          mailto:vkalinin< at >opendesign.com

----- Original Message -----
I am interested in using this feature in my project. Has there been any 
movement in getting this merged into swig?

Once this is working in the C# module, I would also be interested in 
porting it over to the Java module.

Brant

On 4/21/13 1:14 PM, Vladimir Kalinin wrote:



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Swig-devel mailing list
Swig-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-devel


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Abstract base classes to interfaces conversion

Brant K. Kyser — 2013-05-16T15:09:08

I am interested in using this feature in my project. Has there been any 
movement in getting this merged into swig?

Once this is working in the C# module, I would also be interested in 
porting it over to the Java module.

Brant

On 4/21/13 1:14 PM, Vladimir Kalinin wrote:



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Fw: Special Qt mode for SWIG

Dimitar Dobrev — 2013-05-16T13:11:39

----- Forwarded Message -----

From: Dimitar Dobrev <dpldobrev< at >yahoo.com>
To: "swig-devel< at >lists.sourceforge.net" <swig-devel< at >lists.sourceforge.net> 
Sent: Monday, May 13, 2013 9:51 PM
Subject: Fw: [Swig-devel] Special Qt mode for SWIG

----- Forwarded Message -----
From: Dimitar Dobrev <dpldobrev< at >yahoo.com>
To: William S Fulton <wsf< at >fultondesigns.co.uk> 
Sent: Monday, May 13, 2013 9:51 PM
Subject: Re: [Swig-devel] Special Qt mode for SWIG

From: William S Fulton <wsf< at >fultondesigns.co.uk>

To: Dimitar Dobrev <dpldobrev< at >yahoo.com> 
Cc: "swig-devel< at >lists.sourceforge.net" <swig-devel< at >lists.sourceforge.net> 
Sent: Monday, May 13, 2013 8:43 PM
Subject: Re: [Swig-devel] Special Qt mode for SWIG

On 13/05/13 12:46, Dimitar Dobrev
 wrote:

I'm not familiar with the QT world, but from what I understand it is an 
extension of C++. In which case, I can't see any major obstacles as to 
why the SWIG parser couldn't be enhanced to add in QT syntax. SWIG has 
always
 expected ISO C/C++,
 but I don't have a problem if a flag or 
something similar adds in additional support. Where is the QT syntax 
documented? What are the concepts in QT and can they be mapped onto C++ 
concepts? For example, from what I know, QT has some sort of properties, 
which are very similiar to C++ member variables or even SWIG's %extend 
variables or even %attribute.

Please feel free to make a Github fork for your work on this and use 
this list for discussion.

There is plenty of developer docs to read, however, I'd expect you'll 
first tackle the parsing in Source/CParse/parser.y.

I don't know SMOKE, are there any reasons why SWIG might be a better fit?

William

________________________________

    I'm not sure if there is a full list of Qt's macros but here are quite a few. All of their concepts can me expressed through C++ and this is what they do internally. They have a tool called moc (Meta-Object Compiler) that is run on their code before any other steps. It produces standard C++ which is then compiled. The problem is that it produces only "real" cpp files, not "real" headers, and, as stated in the documentation, SWIG cannot be relied upon to work properly with C++ source files. So I figure there should be an option for SWIG to be able to parse Qt headers directly.

    SMOKE is poorly maintained (a single developer who hasn't worked on the main branch for almost a year, and hasn't worked on the project at all for more than half a year). I say that as a person who has sent quite a few patches to SMOKE and reported even more bugs none of which were actually fixed and only two or three paid attention to at all. Besides, SMOKE libraries cannot be used directly, they require an additional C++ layer to be manually written specifically for the binding in question (memory management, marshaling, etc.). As far as I can see, SWIG provides much better automation for these issues.

    Anyway, what I was asking is whether SWIG could wrap Qt with reasonable effort. I read some of the mailing list archives and found some discouraging posts. So, can it be done in practice?

    Dimitar

________________________________

    So, does someone have an opinion if it's feasible?

    Dimitar Dobrev
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Bug in guile's port example when wrapping for guile 2.0

Geert Janssens — 2013-05-14T15:23:50

When running the ports example in a guile 2 context, you will see this output:
314159
(wrong-type-arg "$name" "Wrong type argument in position ~A: ~S" (1 #<output: string 
90071e0>) (#<output: string 90071e0>))
read_int: error reading from file
read_int: Success
1075290112

On 1.8 you will get this:
314159
(wrong-type-arg "$name" "Wrong type argument in position ~A: ~S" (1 #<output: string 
8f3a5d0>) (#<output: string 8f3a5d0>))
4711

The wrong-type-arg error is expected. It is an illustration in the example of what doesn't work.

The difference is in the read_int error.

The runme script first writes a number to stdout (314159). Then it writes a number to a file 
called output.txt (4711). You don't see this in the output above, but it happens just before the 
wrong-type-arg illustration is run.

After the wrong-type-arg error, the runme script goes on to read the number that was written 
to output.txt and prints what it found. On 1.8 it correctly prints 4711 again, on 2.0 it gives an 
error and then a wrong number.

The error is generated when executing line 13 in example.c (fscanf ...). The function is called 
from port_wrap.c, line 1370, which is inside the wrapper code for the read_int function.

I did step through the wrapper function in gdb, both in guile 1.8 and 2.0 environments, but I 
couldn't find any difference in behaviour between the two. Yet one results in a read error 
eventually, the other doesn't.

That's all I have found so far. I hope you can spot the issue. Otherwise it will be something for 
a guile expert.

Geert
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Fw: Special Qt mode for SWIG

Dimitar Dobrev — 2013-05-13T18:51:57

----- Forwarded Message -----
From: Dimitar Dobrev <dpldobrev< at >yahoo.com>
To: William S Fulton <wsf< at >fultondesigns.co.uk> 
Sent: Monday, May 13, 2013 9:51 PM
Subject: Re: [Swig-devel] Special Qt mode for SWIG

From: William S Fulton <wsf< at >fultondesigns.co.uk>

To: Dimitar Dobrev <dpldobrev< at >yahoo.com> 
Cc: "swig-devel< at >lists.sourceforge.net" <swig-devel< at >lists.sourceforge.net> 
Sent: Monday, May 13, 2013 8:43 PM
Subject: Re: [Swig-devel] Special Qt mode for SWIG

On 13/05/13 12:46, Dimitar Dobrev
 wrote:

I'm not familiar with the QT world, but from what I understand it is an 
extension of C++. In which case, I can't see any major obstacles as to 
why the SWIG parser couldn't be enhanced to add in QT syntax. SWIG has 
always expected ISO C/C++,
 but I don't have a problem if a flag or 
something similar adds in additional support. Where is the QT syntax 
documented? What are the concepts in QT and can they be mapped onto C++ 
concepts? For example, from what I know, QT has some sort of properties, 
which are very similiar to C++ member variables or even SWIG's %extend 
variables or even %attribute.

Please feel free to make a Github fork for your work on this and use 
this list for discussion.

There is plenty of developer docs to read, however, I'd expect you'll 
first tackle the parsing in Source/CParse/parser.y.

I don't know SMOKE, are there any reasons why SWIG might be a better fit?

William

________________________________

    I'm not sure if there is a full list of Qt's macros but here are quite a few. All of their concepts can me expressed through C++ and this is what they do internally. They have a tool called moc (Meta-Object Compiler) that is run on their code before any other steps. It produces standard C++ which is then compiled. The problem is that it produces only "real" cpp files, not "real" headers, and, as stated in the documentation, SWIG cannot be relied upon to work properly with C++ source files. So I figure there should be an option for SWIG to be able to parse Qt headers directly.

    SMOKE is poorly maintained (a single developer who hasn't worked on the main branch for almost a year, and hasn't worked on the project at all for more than half a year). I say that as a person who has sent quite a few patches to SMOKE and reported even more bugs none of which were actually fixed and only two or three paid attention to at all. Besides, SMOKE libraries cannot be used directly, they require an additional C++ layer to be manually written specifically for the binding in question (memory management, marshaling, etc.). As far as I can see, SWIG provides much better automation for these issues.

    Anyway, what I was asking is whether SWIG could wrap Qt with reasonable effort. I read some of the mailing list archives and found some discouraging posts. So, can it be done in practice?

    Dimitar------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Special Qt mode for SWIG

William S Fulton — 2013-05-13T17:43:57

I'm not familiar with the QT world, but from what I understand it is an 
extension of C++. In which case, I can't see any major obstacles as to 
why the SWIG parser couldn't be enhanced to add in QT syntax. SWIG has 
always expected ISO C/C++, but I don't have a problem if a flag or 
something similar adds in additional support. Where is the QT syntax 
documented? What are the concepts in QT and can they be mapped onto C++ 
concepts? For example, from what I know, QT has some sort of properties, 
which are very similiar to C++ member variables or even SWIG's %extend 
variables or even %attribute.

Please feel free to make a Github fork for your work on this and use 
this list for discussion.

There is plenty of developer docs to read, however, I'd expect you'll 
first tackle the parsing in Source/CParse/parser.y.

I don't know SMOKE, are there any reasons why SWIG might be a better fit?

William


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Add CCache/ccache-swig.1 to .gitignore

William S Fulton — 2013-05-13T17:25:34

Sure, that's useful. Actually .gitignore (and svn:ignore properties 
before that) isn't very well maintained, there is quite a lot to 
implement given all the different outputs after running the tests. I 
noticed that if the .gitignore file gets big, it slows down git :(

William


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Add CCache/ccache-swig.1 to .gitignore

Karl Wette — 2013-05-13T12:16:46

Hi William,

Just FYI, I've pushed a minor change to the SWIG repository, adding
CCache/ccache-swig.1 to .gitignore - it seems to be the only build product
that isn't ignored. Hope that is okay.

Cheers,
Karl
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Special Qt mode for SWIG

Dimitar Dobrev — 2013-05-13T11:46:09


    Hello,
    

    I'm looking into the possibility to wrap Qt with SWIG. I've already 
read it's quite the challenge but I have an idea about which I'd love to hear some opinions.
    You probably know about SMOKE, another tool for wrapping C++ using headers. It has a special "qt" mode which allows it to properly recognize and 
parse Qt headers. I was wondering if the same option could in theory be 
added to SWIG? If so, I'd be interested in working on it.


    Regards,    Dimitar Dobrev------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Guile autoconf

Geert Janssens — 2013-05-10T16:46:19

On 4 May 2013 17:46, Geert Janssens <info< at >kobaltwit.be[1]> wrote:

For all I'll write below, keep in mind that my autoconf knowledge is fairly limited...

I'm surprised that pkg-config is causing that much trouble. It's used by the guile sources to build guile. So I
would expect any system that ships guile also has a compatible version of pkg-config. (I'm not a Guile core
dev, but I have worked on getting guile to compile on Windows for the GnuCash project).

I suspect the problems arise from the fact that PGK_CONFIG is inside an if/then construct. I found
references that this might cause problems (1).

I have rewritten the code a bit to use AS_IF instead of plain if/then/else, as suggested on that page. You can
find my patch here:
https://github.com/gjanssens/swig/tree/guile_config_tmp[2]

Can you try this and see if the expansion issues go away ? The patch is not complete yet, but I'd like to
know if it's worth continuing in this direction.

No real progress, the error message is equally obscure.

+ autoconf
configure:8954: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.

BTW, you can test this by just removing pkg.m4 from your installation (like old versions of pkg-config which
don't install any pkg.m4 file). Probably we can just put in a copy of pkg.m4 into Tools/config to solve this
problem, but we'd probably have to check that the include paths given to aclocal and ensure our pkg.m4
doesn't override the system's pkg.m4.

On Saturday 04 May 2013 00:20:54 William S Fulton wrote:
It wasn't working properly when I tried it for guile 2. I'm smarter now than I was when I started this and
meanwhile I have found it was mostly used improperly already in the existing configure script. The way guile
was installed before 2.0, this didn't cause any issues. But for 2.0 it broke configure. Given that guile in its
documentation recommends using pkg-config (2) and not knowing how to invoke guile-config properly for
guile 2.0, I decided to go try pkg-config. The guile-config tool is still there in guile 2.0, but I'm not sure if it
will remain so.

This shows my limited autoconf knowledge. The test for pkg-config was copied from the GnuCash project. I
now think the GnuCash config file may be due for some updates.
In my most recent patch, I have used the autoconf macros provided by guile (which internally depend on
pkg-config).
For guile 1.8, the GUILE_FLAGS macro will call guile-config behind the scenes so in the end with guile 1.8
the relevant information comes from the same source. For guile 2.0 this is no longer true. Clearly the guile
developers are moving away from guile-config in favour of pkg-config.

So in my opinion getting the pkg-based configuration working properly will be better in the long term.

By the way, I won't be available from Sunday till Friday, so future reactions may come only after that.

Geert

(1) For example in section 3.4 on this page:
http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/pkg_check_modules.html[3]
(2) http://www.gnu.org/software/guile/manual/guile.html#Autoconf-Background[4]

Maybe Guile and GnuCash can get away with having pkg-config properly installed, but SWIG is about a
whole lot more languages than Guile and I need it to work on a wider set of configurations. As depending on
pkg-config can easily break the autogen.sh stage, I'm going to remove the pkg-config dependency and go
back to using guile-config. Maybe it will have problems in the long term, but correctly getting guile detected
is not that important. For now, it works and doesn't have any negative side effects on old machines for
developers where pkg-config is out of date. The most important thing is for configure to finish successfully
so that folk can build SWIG. Of secondary importance is getting a perfect target language detection
working, especially given the values can be provided with the --with-guile-xxxx options. I have hence
rewritten configure.ac[5] to use guile-config.

Hope you enjoy your break and when you come back, please try it out and I would appreciate it if you could
find a way to set the GUILE_SCM_INTERFACE flag in some intelligent way, perhaps by running some guile
code to detect scm over gh or using 'guile-config info guileversion' or something else in guile-config that is
still supported in the newer versions. Probably you need something like GUILE_MODULE_CHECK in guile.m4.
I notice that guile-1.6 doesn't work, even though from what I understand it does have scm support. Perhaps
in that case we just check for 1.8 or later.

William

Regarding guile 1.6 support. This has been dropped. Not because it doesn't have an scm interface (it has),
but because it has a different memory management model than guile 1.8 and 2.0 have and several of guile
1.6's procedures have been deprecated in 1.8 and removed in 2.0. Trying to support both may be possible,
but results in much more complicated code. I motivated this on this list before that I had no intention to
support guile 1.6 anymore.------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Octave examples

Karl Wette — 2013-05-08T22:11:03

You're right, the docs should be kept up to date too. I've just added an
extra patch to the pull request doing just that.

Cheers,
Karl


On 8 May 2013 23:57, William S Fulton <wsf< at >fultondesigns.co.uk> wrote:

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Octave examples

William S Fulton — 2013-05-08T21:57:07

Great, thanks. I've committed this. Probably we should change the 
examples in the html files to match too?

William

On 08/05/13 21:46, Karl Wette wrote:


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Octave examples

Karl Wette — 2013-05-08T20:46:49

Hi William,

I've just opened a pull request for this:

https://github.com/swig/swig/pull/46

Cheers,
Karl


On 30 April 2013 08:56, William S Fulton <wsf< at >fultondesigns.co.uk> wrote:

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Guile autoconf

William S Fulton — 2013-05-08T16:48:17

No real progress, the error message is equally obscure.

+ autoconf
configure:8954: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

BTW, you can test this by just removing pkg.m4 from your installation (like
old versions of pkg-config which don't install any pkg.m4 file). Probably
we can just put in a copy of pkg.m4 into Tools/config to solve this
problem, but we'd probably have to check that the include paths given to
aclocal and ensure our pkg.m4 doesn't override the system's pkg.m4.




Maybe Guile and GnuCash can get away with having pkg-config properly
installed, but SWIG is about a whole lot more languages than Guile and I
need it to work on a wider set of configurations. As depending on
pkg-config can easily break the autogen.sh stage, I'm going to remove the
pkg-config dependency and go back to using guile-config. Maybe it will have
problems in the long term, but correctly getting guile detected is not that
important. For now, it works and doesn't have any negative side effects on
old machines for developers where pkg-config is out of date. The most
important thing is for configure to finish successfully so that folk can
build SWIG. Of secondary importance is getting a perfect target language
detection working, especially given the values can be provided with the
--with-guile-xxxx options. I have hence rewritten configure.ac to use
guile-config.

Hope you enjoy your break and when you come back, please try it out and I
would appreciate it if you could find a way to set the GUILE_SCM_INTERFACE
flag in some intelligent way, perhaps by running some guile code to detect
scm over gh or using 'guile-config info guileversion' or something else in
guile-config that is still supported in the newer versions. Probably you
need something like GUILE_MODULE_CHECK in guile.m4. I notice that guile-1.6
doesn't work, even though from what I understand it does have scm support.
Perhaps in that case we just check for 1.8 or later.

William
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Guile examples

William S Fulton — 2013-05-08T16:49:37

I got the std_vector and multivalue examples running using the 
dynamic-link approach.

My latest changes also get the guile test-suite and examples working 
correctly on Cygwin. With respect to the examples, the only remaining 
thing you could help out with for now is the 'port' and 'class' example, 
then Guile will be sufficiently ready for release as far as I'm 
concerned although I'll tidy up the Makefiles a bit more.

William


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Problem with 2.10 on modula3

William S Fulton — 2013-05-07T20:59:24

If you are getting the seg fault while running SWIG please let us know 
how to replicate.

If you are getting a seg fault while running modula3, you'll need to put 
in some effort provide more info to debug to see what has changed as the 
modula3 target language in SWIG has always been in an unknown state as 
no-one has provided any tests.

William


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may