<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel">
    <title>gmane.comp.lib.ivtools.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/29"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/28"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/27"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/26"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/25"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/24"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/23"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/29">
    <title>Re: ivtools build failures with gcc40 in 64 bit arches</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/29</link>
    <description>&lt;pre&gt;
Yes, otherwise gcc(&amp;gt;40) will fail in 64 bit arches because of the different
pointer length. I add a modified patch since gcc-4.4.2 complained about
uintptr_t not being available in context. But last Debian gcc-4.2.2 seems to
have some problems, so this may be a compiler problem.


If this is the only purpose, using plain (long) and (unsigned long) 
may even be enough.

Cheers,

&lt;/pre&gt;</description>
    <dc:creator>Agustin Martin</dc:creator>
    <dc:date>2009-12-11T16:16:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/28">
    <title>Re: ivtools build failures with gcc40 in 64 bit arches</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/28</link>
    <description>&lt;pre&gt;Agustin,

Does the contents of this patch resolve a compiler error or a  
warning?  Information is still being lost, but if it this fools the  
compiler, I'm fine with that.

Casting a pointer to boolean, int, or unsigned int is kind of  
meaningless (other than comparison to NULL), and was only supported  
for debug purposes.

Scott

On Oct 23, 2009, at 8:30 AM, Agustin Martin wrote:




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
&lt;/pre&gt;</description>
    <dc:creator>Scott Johnston</dc:creator>
    <dc:date>2009-10-23T17:15:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/27">
    <title>Re: idraw 1.2.6 files sometimes make ghostscript fail possibly due toa buggy non-visible element</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/27</link>
    <description>&lt;pre&gt;In the idraw file with a problem you have a multi-line and a polygon  
grouped together, both of zero length.  I found them by importing the  
file into comdraw and using its scripting commands to select and  
inspect them.   Not sure how these got created.  Perhaps you can  
document this problem at http://sf.net.projects/ivtools?

Scott Johnston


On Oct 23, 2009, at 8:56 AM, Agustin Martin wrote:




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
&lt;/pre&gt;</description>
    <dc:creator>Scott Johnston</dc:creator>
    <dc:date>2009-10-23T16:46:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/26">
    <title>idraw 1.2.6 files sometimes make ghostscript fail possibly due toa buggy non-visible element</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/26</link>
    <description>&lt;pre&gt;Hi,

I noticed that sometimes files created by idraw 1.2.6 cannot be processed
by ghostscript, which fails with an error (lines are formatted)

------------------------------------ 8&amp;lt; ---------------------------------
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
   % --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
   % -- --nostringval--   false   1   %stopped_push   1862   1   3
   % -- -- %oparray_pop   1861   1   3   %oparray_pop   --nostringval--
   % -- -- % 1845   1   3   %oparray_pop   1739   1   3   %oparray_pop
   % -- -- % --nostringval--   %errorexec_pop   .runexec2   --nostringval--
   % -- -- % -- --nostringval--   --nostringval--   2   %stopped_push
   % -- -- % -- -- --nostringval--   --nostringval--
Dictionary stack:
   --dict:1154/1684(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--
   -- --dict:33/50(L)--   --dict:1/17(L)--   --dict:14/17(L)--
Current allocation mode is local
Current file position is 8551
GPL Ghostscript 8.70: Unr&lt;/pre&gt;</description>
    <dc:creator>Agustin Martin</dc:creator>
    <dc:date>2009-10-23T15:56:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/25">
    <title>ivtools build failures with gcc40 in 64 bit arches</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/25</link>
    <description>&lt;pre&gt;Hi,

The old build failure due to the different pointer lenght in 32 and 64 bit
arches came back,

http://bugs.debian.org/545834

The reason is that not all issues from http://bugs.debian.org/314666 were
fixed with the applied patch. Note that a pointer does not fit in an integer
on 64 bit arches. A pointer is 64 bit, an integer 32 bit.

I am attaching a quick and dirty patch which mostly does what was proposed
in #314666 for that part, but using c99 typedefs intptr_t and uintptr_t,
from libc6 stdint.h, instead of unconditional long. I think they are present
in current libc variants, but you may prefer something more general or
moving its use for boolean to the boolean definition.

Hope this helps anyway.

Cheers,
 
&lt;/pre&gt;</description>
    <dc:creator>Agustin Martin</dc:creator>
    <dc:date>2009-10-23T15:30:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/24">
    <title>Re: InterViews updates</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/24</link>
    <description>&lt;pre&gt;Gert-jan,

Thanks for your interest in ivtools.  Your evolutions sound perfectly  
fine, but personally I avoid the use of templates in my work whenever  
possible, and have to admit I won't be incorporating your changes into  
my copy of ivtools in the near future.

That said, I would like to encourage you to carry on with your  
changes.  Perhaps you would like to take over as the Debian maintainer  
of ivtools, and incorporate your changes into those sources?  Or  
perhaps you simply want to publish your patch file somewhere and I'll  
link to it from ivtools.org?  Or forward the patch to me and I'll put  
it up?  Or simply make your own tar file and distribute it?

In any case, glad you appreciate InterViews and Unidraw.   In my  
opinion Qt is a suitable replacement for InterViews, but there is  
still no substitute for Unidraw.

Scott Johnston

p.s. I just recently got ivtools built on the latest version of  
Ubuntu, something people have been struggling with for a while.  The  
trick was to get rid of&lt;/pre&gt;</description>
    <dc:creator>Scott Johnston</dc:creator>
    <dc:date>2009-09-24T15:29:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/23">
    <title>InterViews updates</title>
    <link>http://permalink.gmane.org/gmane.comp.lib.ivtools.devel/23</link>
    <description>&lt;pre&gt;Hello,
in the last several weeks I have been tinkering with the InterViews and
Unidraw parts of ivtools.  My main motivation is to get reaccustomed with GUI
programming, and InterViews' clean design is very helpful for this.

While I'm aware that ivtools is in deep maintenance mode, some of my
modifications may still be of interest to you: 
- Improved UTF-16 and UTF-8 support
- Use of 'bool' and min/max from libc++
- Replaced the macros for generic types like List, Table, Action
  and some special callbacks with templates.
- Reimplemented List and Table with std::deque and std::map
- Extended Actions with up to 3 arguments
- Introduced smart pointers for automated Resource management
- Switched IV-3.1, IV-Look and IV-X11 from manual Resource
  management to smart pointers
- Replaced the Unidraw low-level containers (UArray, UList, UMap,
  UHashTable) with templates.
- Switched the internals of some Unidraw classes to smart pointers
  and containers from the C++ standard library.

The current cha&lt;/pre&gt;</description>
    <dc:creator>Gert-jan Los</dc:creator>
    <dc:date>2009-09-24T14:01:25</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lib.ivtools.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lib.ivtools.devel</link>
  </textinput>
</rdf:RDF>
