ivtools-devel Mailing List for ivtools
Brought to you by:
johnston
Menu
▾
▴
ivtools-devel
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(63) |
Feb
(16) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2001 |
Jan
|
Feb
|
Mar
(2) |
Apr
(11) |
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2002 |
Jan
(1) |
Feb
(8) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2003 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(4) |
Nov
|
Dec
(1) |
|
From: Agustin M. <agu...@hi...> - 2009-12-11 16:16:32
|
On Fri, Oct 23, 2009 at 10:15:43AM -0700, Scott Johnston wrote: > 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. Yes, otherwise gcc(>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. > 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. If this is the only purpose, using plain (long) and (unsigned long) may even be enough. Cheers, -- Agustin |
|
From: Scott J. <joh...@ve...> - 2009-10-23 17:28:42
|
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: > 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, > > -- > Agustin > < > 48_gcc40_int_pointer_errors > .diff > > > ------------------------------------------------------------------------------ > 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_______________________________________________ > Ivtools-devel mailing list > Ivt...@li... > https://lists.sourceforge.net/lists/listinfo/ivtools-devel |
|
From: Scott J. <joh...@ve...> - 2009-10-23 16:59:27
|
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: > 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< > --------------------------------- > 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: Unrecoverable error, exit code 1 > ------------------------------------ 8< > --------------------------------- > > I could not yet isolate what is exactly triggering the problem during > edition, but noticed that in a buggy file, when I remove visible > elements > in a one by one basis (individual select+delete), I end up with a > supposedly empty file that is still buggy. > > If I then do a 'select all', nothing is shown as selected, but if > issue the > delete command from the menu or the 'x' key file is marked as > changed, and > as a matter of fact saved file does no longer trigger a ghostscript > failure. > > I am attaching two supposedly empty files, one with the extra code > that > fails and another one really empty and thus not failing. > > Hope this helps, > > -- > Agustin > < > carrito > .idw > .void > .fail > > > < > carrito > .idw > .void > .ok > > > ------------------------------------------------------------------------------ > 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_______________________________________________ > Ivtools-devel mailing list > Ivt...@li... > https://lists.sourceforge.net/lists/listinfo/ivtools-devel |
|
From: Agustin M. <agu...@hi...> - 2009-10-23 15:57:03
|
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< --------------------------------- 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: Unrecoverable error, exit code 1 ------------------------------------ 8< --------------------------------- I could not yet isolate what is exactly triggering the problem during edition, but noticed that in a buggy file, when I remove visible elements in a one by one basis (individual select+delete), I end up with a supposedly empty file that is still buggy. If I then do a 'select all', nothing is shown as selected, but if issue the delete command from the menu or the 'x' key file is marked as changed, and as a matter of fact saved file does no longer trigger a ghostscript failure. I am attaching two supposedly empty files, one with the extra code that fails and another one really empty and thus not failing. Hope this helps, -- Agustin |
|
From: Agustin M. <agu...@hi...> - 2009-10-23 15:31:17
|
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, -- Agustin |
|
From: Scott J. <joh...@ve...> - 2009-09-24 15:56:25
|
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 ivtools-1.2/src/include/ivstd/stdio.h On Sep 24, 2009, at 7:01 AM, Gert-jan Los wrote: > 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 changes are against a modified version of the Debian > package > and some make use of rather new features of C++. But if there is > enough > interest for some of the listed items I'm willing to recreate the > patches > against current, pristine ivtools sources and test with older > compilers. > > Have a nice Day > Gert-jan > PS: My first email used a different From adress and seems to be > stuck in moderation > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® 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/devconf > _______________________________________________ > Ivtools-devel mailing list > Ivt...@li... > https://lists.sourceforge.net/lists/listinfo/ivtools-devel > |
|
From: Gert-jan L. <lo...@rz...> - 2009-09-24 14:12:26
|
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 changes are against a modified version of the Debian package and some make use of rather new features of C++. But if there is enough interest for some of the listed items I'm willing to recreate the patches against current, pristine ivtools sources and test with older compilers. Have a nice Day Gert-jan PS: My first email used a different From adress and seems to be stuck in moderation |
|
From: Kari P. <kar...@gm...> - 2005-07-09 05:11:19
|
Hello. Parts of ivtools fail to build with gcc 4.0. There is a patch for version 1.1.3 at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D314666 Apparently at least some of the modifications in there apply for 1.2.2 too. I haven't yet gone through 1.2.2 myself, but you might want to look at the patch anyway. |
|
From: Scott J. <joh...@ve...> - 2005-04-03 17:44:48
|
Hi Eduard, If someone had the interest in doing this, and was willing to put some effort into testing it, I would accept the patch, and do my own testing as well. The current solution was arrived at incrementally. The iostream's of libg++ in the 90's were a stable and efficient thing, whereas the migration to ANSI standard iostreams (by libstdc++) took a while. The best solution at the time was to hold on to the old way. The original ibuild will mostly likely still compile on top of ivtools. But the focus of ivtools is the drawing editors, not the user interface widgets (which have not proven popular in the free software world). And ibuild was never updated to work with the glyphs of InterViews 3.1, so it is only useful as a GUI builder for InterViews 2.6 Interactors. Thanks for your interest in ivtools, So where did IV3.1-nls come from? Scott Johnston http://www.ivtools.org On Apr 3, 2005, at 12:25 AM, Eduard Votapek wrote: > Hi friends, > > recently i've looked at the newest ivtools. > Well, i think the method of wrapping all around the > old headers is quite ugly. > > How about doing a straigt replacement of the > old InterViews with the new headers? > > Currently i'm doing this work on my old IV3.1-nls > with some fixes inside, to use it with gcc-3.4.3. > I'm using IV since one of it's first versions > in '92 ... (this should tell all :-) > > BTW, does anybody know where and why ibuild > did disappear from ivtools? > > regards, Eduard > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Ivtools-devel mailing list > Ivt...@li... > https://lists.sourceforge.net/lists/listinfo/ivtools-devel > |
|
From: Eduard V. <evo...@ev...> - 2005-04-03 08:25:31
|
Hi friends, recently i've looked at the newest ivtools. Well, i think the method of wrapping all around the old headers is quite ugly. How about doing a straigt replacement of the old InterViews with the new headers? Currently i'm doing this work on my old IV3.1-nls with some fixes inside, to use it with gcc-3.4.3. I'm using IV since one of it's first versions in '92 ... (this should tell all :-) BTW, does anybody know where and why ibuild did disappear from ivtools? regards, Eduard |
|
From: Michael H. <mic...@ya...> - 2005-03-01 22:58:39
|
Michael Hines wrote: > I see in ivtools-1.2/src/IVGlyph/figure.c > how to convert *_BSpline31 arrays into a sequence of curve_to calls. > But I need to go the other way. > My application uses curve_to and contains an Idraw file writer which > needs to convert them to a BSpl or CBSpl. > Does anyone know the algorithm? No need to look. I found the algorithm at //http://www.timotheegroleau.com/Flash/articles/cubic_bezier_in_flash.htm |
|
From: Michael H. <mic...@ya...> - 2005-03-01 17:44:11
|
I see in ivtools-1.2/src/IVGlyph/figure.c how to convert *_BSpline31 arrays into a sequence of curve_to calls. But I need to go the other way. My application uses curve_to and contains an Idraw file writer which needs to convert them to a BSpl or CBSpl. Does anyone know the algorithm? By the way, if anyone is interested, I've long been maintaining a mac os x carbon and MSWindows version of InterViews 3.2a for use with my application and the tar.gz file can be found at http://www.neuron.yale.edu/neuron/install/install.html It builds using an autoconf generated configure file. With X11 it also builds the original idraw using the Unidraw and InterViews-2.6 compatibility classes, but I never got around to porting the InterViews-2.6/x*.c files to carbon or mswin so idraw never made it to those places. -Michael Hines |
|
From: Scott J. <joh...@ve...> - 2004-06-30 21:27:29
|
Have you attempted to build your application with ivtools? I don't really think HP added that much to InterViews when they created their product, just simply compiled it and distributed it in binary form. I would be interested in your results. Scott Johnston http://www.ivtools.org On Jun 30, 2004, at 11:16 AM, bat...@cf... wrote: > I am currently attempting to port some software that used HPs IVPlus > implementation of InterViews. > > The source tree that I have is incomplete. > > If anyone has any information on IVPlus or how I can optain a complete > distribution, please contact me @ bat...@cf... or post to the > distribution list. > > Thanks. > > Brian Atkinson > Orlando, FL > |
|
From: <bat...@cf...> - 2004-06-30 18:16:48
|
I am currently attempting to port some software that used HPs IVPlus implementation of InterViews. The source tree that I have is incomplete. If anyone has any information on IVPlus or how I can optain a complete distribution, please contact me @ bat...@cf... or post to the distribution list. Thanks. Brian Atkinson Orlando, FL |
|
From: Michal P. <mi...@pa...> - 2004-05-07 21:27:17
|
Hi, I just build rpms for the latest ivtools source packages. They have been tested on redhat 9 and 8. You can find them here. http://evolution.gs.washington.edu/~mpalczew/ Is there an official place to upload them? or is there someone in charge of this? Scott Johnston wrote: > This is an e-mail to test the ivtools-devel mailing list. I approved a > post from mike at palczewski dot net earlier today. The subject was > some newly generated RPM's. But the e-mail never came through, and I > don't have a copy of it. Mike, if you read this, please forward another > copy, and cc me. > > Scott Johnston > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Ivtools-devel mailing list > Ivt...@li... > https://lists.sourceforge.net/lists/listinfo/ivtools-devel |
|
From: Scott J. <joh...@ve...> - 2004-05-07 19:54:06
|
This is an e-mail to test the ivtools-devel mailing list. I approved a post from mike at palczewski dot net earlier today. The subject was some newly generated RPM's. But the e-mail never came through, and I don't have a copy of it. Mike, if you read this, please forward another copy, and cc me. Scott Johnston |
|
From: Michal P. <mi...@pa...> - 2004-05-07 00:30:30
|
Hi, I just build rpms for the latest ivtools source packages. They have been tested on redhat 9 and 8. You can find them here. http://evolution.gs.washington.edu/~mpalczew/ Is there an official place to upload them? or is there someone in charge of this? |
|
From: Leon B. <le...@ne...> - 2003-02-11 19:53:30
|
I prepared a rpm package for ivtools-1.0.7. The source package is in http://leon.bottou.com/files/ivtools-1.0.7-1.src.rpm. The spec file and the patch files are attached. - the first patch (ivtools-rpm.patch) makes various makefile changes that redefine the set of files to install. This comes from a old ivtools package and I did not try to think to hard. - the second patch (ivtools-bug.patch) removes a default argument in a function definition. This causes a compile error with gcc-3.2. - Leon Bottou |
|
From: Scott J. <joh...@ve...> - 2003-01-10 16:47:54
|
At 3:43 PM +0800 1/10/03, to...@se... wrote: >Hi Scott, > >Thanks for your reply. In fact, i am interested in the porting of >Interviews from Unix to Red Hat Linux only. Do you know how complex it is >to port Interviews from Unix to Linux? Or is there anyone else i can >consult? Thanks again Scott. Your reply is very much appreciated. > >Regards, >David > Porting InterViews to RedHat 7.3 is more about changing InterViews to get it compiled with a recent version of gcc. As far as I know, no one has been getting InterViews compiled with recent versions of gcc. Several years ago there used to be an RPM for iv-3.1, but I haven't seen it in the last few years. And there have been a lot of (minor) changes over the years required to these libraries, I know, because I went through them all. Most of it is conformance to the ANSI standard. You can use the ivtools source tree as a reference, but I really think it would be less work for you to use the InterViews and Unidraw libraries out of the ivtools source tree. They are the same for the most part, with only bug fixes and compilation fixes accrued over time. Scott Johnston http://www.ivtools.org |
|
From: Scott J. <joh...@ve...> - 2003-01-10 06:51:48
|
Yes, it is entirely possible to do both things, 1) port an InterViews application from a Unix to RedHat Linux, and 2) port an InterViews application over to ivtools. If you only want to do former this list won't be of much help. But if you want to migrate to ivtools, which has been continuously developed on various Linuxes for several years, you've come to the right place. First off, you'd probably have far better results if you completely upgraded to gcc-3.* before building ivtools or your application. In theory things should work with the default gcc-2.96 compiler of RH 7.3, but in practice people have run into a lot of strange problems with symbol resolution. Also make sure to use the latest version of ivtools, 1.0.7. The whole process might be as simple as building and installing ivtools (following the INSTALL directions), then using the resultant ivmkmf to configure your application to build on ivtools. Are you familiar with ivmkmf? I have not recently tested the port of an InterViews application to ivtools, and I wouldn't be surprised if there are some minor configuration issues to resolve. Come back here for more help if you need it. But it has worked before, and should work again. Scott Johnston http://www.ivtools.org At 2:09 PM +0800 1/10/03, to...@se... wrote: >Dear Sir, > > Currently i have an application written in C++ with Interviews on a >Unix Platform and wished to port over to Red Hat Linux 7.3. However i am >not sure whether is Interviews compatible and is able to run on a PC-based >Red Hat Linux. Please advise. Thanks a lot. > >Regards, >David > >[This e-mail is confidential and may also be privileged. If you are not the >intended recipient, please delete it and notify us immediately; you should >not copy or use it for any purpose, nor disclose its contents to any other >person. Thank you.] |
|
From: <to...@se...> - 2003-01-10 06:10:34
|
Dear Sir,
Currently i have an application written in C++ with Interviews on a
Unix Platform and wished to port over to Red Hat Linux 7.3. However i am
not sure whether is Interviews compatible and is able to run on a PC-based
Red Hat Linux. Please advise. Thanks a lot.
Regards,
David
[This e-mail is confidential and may also be privileged. If you are not the
intended recipient, please delete it and notify us immediately; you should
not copy or use it for any purpose, nor disclose its contents to any other
person. Thank you.]
|
|
From: Scott J. <joh...@ve...> - 2002-11-26 05:09:06
|
>Delivered-To: vwp...@ve... >Date: Mon, 25 Nov 2002 10:34:31 -0800 >Subject: Re: fink ivtools needs Jaguar? >Cc: be...@us... >To: Scott Johnston <joh...@ve...> >From: Ben Hines <bh...@al...> >X-Authentication-Info: Submitted using SMTP AUTH PLAIN at >out001.verizon.net from [4.60.76.58] at Mon, 25 Nov 2002 12:34:31 >-0600 > > >On Monday, November 25, 2002, at 10:09 AM, Scott Johnston wrote: > >>Ben, >> >>Thanks for your efforts. So I guess I have to upgrade to Jaguar >>before I can download the fink'ified ivtools, right? >> > >Yes, i don't have a 10.1 machine to try it on and support. > >>In the meantime, I wonder if you can perform a test for me. >>ivtools on 10.1.* (and XFree86 4.2) has a problem with the X11 >>shared memory extension that hasn't shown up on other OS'es. >>Perhaps the problem has been fixed. All you have to do is import >>an image (TIFF, PPM, or JPEG if you have djpeg, PNG if you have >>pngtoppm) and zoom in once. If it crashes the problem is still >>there. It'd be great if Jaguar or a new X fixes it. >> > >Jaguar i believe had some major changes in this area. I can import a >JPEG into comdraw and zoom in just fine. But not TIFFs. > >Importing in idraw seems to be broken, i get: > >/Volumes/Medea/Pictures/Family/Ben/2ndClass.tiff: Seek error >accessing TIFF directory. > > >When i try to import a tiff into comdraw, i get: >Volumes/Medea/Pictures/Family/Ben/2ndClass.tiff: Seek error >accessing TIFF directory. >then it crashes: > >********** > >Date/Time: 2002-11-25 10:29:56 -0800 >OS Version: 10.2.2 (Build 6F21) >Host: lsanca1-ar8-4-60-076-058.lsanca1.dsl-verizon.net > >Command: comdraw >PID: 16948 > >Exception: EXC_BAD_ACCESS (0x0001) >Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 > >Thread 0 Crashed: > #0 0x0038a308 in OverlayRaster::construct(ivRaster const&) > #1 0x00389ed0 in OverlayRaster::OverlayRaster[unified](ivRaster const&) > #2 0x00363450 in OvImportCmd::TIFF_Raster(char const*) > #3 0x00363358 in OvImportCmd::TIFF_Image(char const*) > #4 0x00362c90 in OvImportCmd::DoImport(std::basic_istream<char, >std::char_traints<char> >&, unsigned&, FileHelper&, ivEditor*, >unsigned, char const*, int&, unsigned) > #5 0x003622d8 in OvImportCmd::Import(std::basic_istream<char, >std::char_traints<char> >&, unsigned&) > #6 0x00362270 in OvImportCmd::Import(std::basic_istream<char, >std::char_traints<char> >&) > #7 0x003620f4 in OvImportCmd::Import(char const*) > #8 0x00361844 in OvImportCmd::PostDialog() > #9 0x00360eb0 in OvImportCmd::Execute() > #10 0x00357678 in CommandDoer::Do() > #11 0x00397640 in OverlayUnidraw::Run() > #12 0x00002f80 in 0x2f80 > #13 0x00002b70 in 0x2b70 > #14 0x000029f0 in 0x29f0 > > > >>Scott Johnston >>http://www.ivtools.org >> >>p.s. if this doesn't fix the problem, I've got a patch ready to >>disable the shared memory extension for OS X. >> >> > >I had to make a number of patches to get it compiling on jaguar. > >See: >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/fink/dists/10.2/unstable/main/finkinfo/graphics/ > >Click on ivtools, the .info and .patch files. > >-Ben |
|
From: Scott J. <joh...@ve...> - 2002-09-27 18:10:11
|
I'm pondering just how to go about adding SVG export to ivtools. I have two choices. Either use the existing OverlayScript class hierarchy to generate SVG as well as native ivtools format, or create a SVG-specific subclass for every class in the existing hierarchy: http://www.ivtools.org/ivtools/doc/classes/derivedclasses.html#OverlayScript (with the largest subtree here: http://www.ivtools.org/ivtools/doc/classes/derivedclasses.html#OverlaysScript ) In the past we've used both approaches for supporting multiple formats. The support for idraw-EPS in parallel with anything-goes-EPS is implemented with a global flag used by the one set of methods that generates PostScript. In vhclmaps support for graphic export versus native map feature export was done with two sets of methods (and classes). The drawback of creating an SVG-specific subclass is further proliferation of the somewhat confusing tree of external view classes already in place for ivtools: http://www.ivtools.org/ivtools/doc/classes/derivedtree.html#ExternView plus because of the manual nature of the component class registration of Unidraw, I find it somewhat labor intensive any time I have to create one class for each graphic shape and/or container. It would be a different story if I could isolate this to a single derived class. The drawback of not creating an SVG-specific subclass is I'll have many methods with a body split into two parts, one part for SVG, one part for native ivtools format, without much common ground. A lot of common ground in underlying methods that are invoked to prepare data for serialization, but little in the serialization process. Anyone care to share their opinion? Scott Johnston |
|
From: Scott J. <sc...@ac...> - 2002-07-16 16:44:30
|
David Nowak wrote:
>Thank you Todd and Scott for your replies,
>
>I have finally found my mistake. Indeed, in order to use Arrows, In need to
>replace the line
>
> Creator creator;
>
>by
>
> IdrawCreator creator;
>
>In my main function!
>
>It still crashes but at a further point in the program. Probably the same kind
>of mistake.
>
>I'd like to make a kind of automata editor in which I can draw an arrow between
>two nodes and when I move one of this nodes, the arrow moves too. Is there any
>source code available that do such things!
>
>Many thanks,
>
>David.
>
>
>
That's exactly what ivtools graphdraw does:
http://www.ivtools.org/ivtools/graphdraw.html
For information on the relevant classes and the layering of class libraries:
http://www.ivtools.org/ivtools/graphinfo.html
Scott Johnston
http://www.ivtools.org
|
|
From: <now...@ya...> - 2002-07-16 12:15:19
|
Thank you Todd and Scott for your replies, I have finally found my mistake. Indeed, in order to use Arrows, In need to replace the line Creator creator; by IdrawCreator creator; In my main function! It still crashes but at a further point in the program. Probably the same kind of mistake. I'd like to make a kind of automata editor in which I can draw an arrow between two nodes and when I move one of this nodes, the arrow moves too. Is there any source code available that do such things! Many thanks, David. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com |
