Menu
▾
▴
e4graph-core — Technical discussions regarding the e4Graph package
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(24) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(6) |
Mar
(4) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(2) |
|
From: Fletcher, J. P <j.p...@as...> - 2007-12-01 22:12:53
|
Jeff Here is a workaround for the problem, which minimises the loss of optimisat= ion. Not a full solution. Move to the all directory and make sure that in makefile.include the line C= FLAGS_OPTIMIZE has the flag -O (or -O2 if you prefer). Run the commands make clean make make test This test will fail. Then edit makefile.include and remove the optimisation flag from CFLAGS_OPT= IMIZE. Also move to directory main/mkdriver and touch or edit the file mks= torage.cpp in some way (e.g. edit a comment). Return to all and again run make make test For me this test passes. Only the file mkstorage.cpp has been compiled wit= hout optimisation, and included in the library. This is enough for the pro= blem to go away. This works for me with the combination in my previous mes= sage (gcc 4.0.2 and metakit 2.4.9.7 and a hybrid version of e4graph 1.0a11 = with some updates, but not to anything related to the metakit driver and GC= ). Why is another matter. Best wishes to all John ________________________________________ From: e4g...@li... [e4graph-core-bounces@list= s.sourceforge.net] On Behalf Of Jeff Rose [ro...@gm...] Sent: 29 November 2007 16:48 To: e4g...@li... Subject: Re: [E4graph-core] ping Here we go... $ gcc --version gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) I'm just checking out metakit from the subversion repository, but first I'll try to use the latest Ubuntu Gutsy version of metakit listed as: libmetakit2.4.9.3c2. I've got both the last e4graph release as well as the latest version in cvs. First, the build system is a bit broken. It could probably just do ./configure && make && make install like most open source projects for linux/unix these days. It requires that you run autoconf first. It is also checking for python, java and expat, even when not passing those flags to configure. In the latest release it still continues, but in the cvs version it fails the configure (even when passing --disable-tcl --disable-java --disable-python). So for now I'll just use the latest release because I don't want to deal with debugging the configure script... So, latest e4graph release with metakit in ubuntu: $./testcore a Running e4_DString tests: ..... Running e4_Refcount tests: .... Running e4_Storage tests: ...Segmentation fault From a gdb run with -ggdb: (gdb) bt #0 0x00000000 in ?? () #1 0xb7f88e9c in e4_StorageImpl::NotReferenced (this=3D0x809f7a0) at ../impl/i4storage.cpp:1609 #2 0xb7f769a3 in ~e4_RefCount (this=3D0xbfff7bf8) at ../include/e4graphimpl.h:197 #3 0x0805a834 in test_storage5 () at ./../../main/include/e4graph.h:716 #4 0x0805c9e9 in test_storage () at ./../src/teststorage.cpp:1494 #5 0x0804ca47 in main (ac=3D2, av=3D0xbfff7d34) at ./../src/test.cpp:147 ----------------------------------------------------------- Ok, some more info. All tests pass when optimizations have been turned off. This is a nasty memory bug. Poking around with valgrind/gdb on the optimized version I think I've got it somewhat figured out though. Here is the relevant dump: Running e4_Storage tests: ...=3D=3D27925=3D=3D Invalid read of size 1 =3D=3D27925=3D=3D at 0x405BD82: e4_StorageImpl::CleanUp() (e4graphimpl.h= :397) =3D=3D27925=3D=3D by 0x405BE07: e4_StorageImpl::NotReferenced() (i4storage.cpp:1577) =3D=3D27925=3D=3D by 0x40499A2: e4_RefCount::~e4_RefCount() (e4graphimpl= .h:197) =3D=3D27925=3D=3D by 0x805A833: test_storage5() (e4graph.h:716) =3D=3D27925=3D=3D by 0x805C9E8: test_storage() (teststorage.cpp:1494) =3D=3D27925=3D=3D by 0x804CA46: main (test.cpp:147) =3D=3D27925=3D=3D Address 0x45C250D is 13 bytes inside a block of size 360= free'd =3D=3D27925=3D=3D at 0x4022096: operator delete(void*) (vg_replace_mallo= c.c:244) =3D=3D27925=3D=3D by 0x403C831: e4_MetakitStorageImpl::~e4_MetakitStorageImpl() (mkstorage.cpp:1096) =3D=3D27925=3D=3D by 0x405BEED: e4_StorageImpl::NotReferenced() (i4storage.cpp:1634) =3D=3D27925=3D=3D by 0x4049B2C: e4_RefCount::~e4_RefCount() (e4graphimpl= .h:197) =3D=3D27925=3D=3D by 0x405AB80: e4_StorageImpl::CauseEventInternal(int, e4_RefCounter*, void*) (i4storage.cpp:1833) =3D=3D27925=3D=3D by 0x403E278: e4_MetakitStorageImpl::DRV_Commit() (e4graphimpl.h:402) =3D=3D27925=3D=3D by 0x405BDE3: e4_StorageImpl::CleanUp() (e4graphimpl.h= :426) =3D=3D27925=3D=3D by 0x405BE07: e4_StorageImpl::NotReferenced() (i4storage.cpp:1577) =3D=3D27925=3D=3D by 0x40499A2: e4_RefCount::~e4_RefCount() (e4graphimpl= .h:197) =3D=3D27925=3D=3D by 0x805A833: test_storage5() (e4graph.h:716) =3D=3D27925=3D=3D by 0x805C9E8: test_storage() (teststorage.cpp:1494) =3D=3D27925=3D=3D by 0x804CA46: main (test.cpp:147) =3D=3D27925=3D=3D =3D=3D27925=3D=3D ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y --------------------- So the goal of this test is to check that the storage is correctly serialized when the destructor is called after going out of scope. That looks like it is happening correctly if you go through the bottom stack. (RefCount -> NotReferenced -> CleanUp -> DRV_Commit) Strangely, that seems to fire an event which results in the destructor getting called. This is bad, because that event was triggered from inside the destructor, so when it returns back out a bit to CleanUp() valgrind finds a read error. That means the program is reading an invalid variable, which make sense since it is operating on an already deleted object and trying to use non-existant member vars. I don't know anything about the event stuff or why an event is calling the destructor, and I think I'm done for now. Hopefully someone who knows a bit about it can use this info to find the event and make it not call the destructor. On a related note, is it worth doing this work? Is anyone with commit access paying attention? I saw a message somewhere about writing a new graph library like e4graph on top of the new_new metakit, vlerq. Anyone know much about vlerq? Ciao, Jeff Fletcher, John P wrote: > Daniel > > See comment below. e4graph needs a fix of some sort. > > John > ________________________________________ > From: Daniel Rucci [da...@ru...] > Sent: 29 November 2007 07:36 > To: Fletcher, John P > Cc: e4g...@li... > Subject: Re: [E4graph-core] ping > > Fletcher, John P wrote: >> [snip] >> Things that occur to me to check. >> >> 1. Do the corresponding tests for metakit run O.K. either for 2.4.9.3 or= later? >> That will establish whether the problem is in metakit or e4graph >> > The test suite for metakit 2.4.9.3_4 using gcc 4.2.1 & 4.2.3 competed > successfully. > > **** That means that there must be a problem with e4graph and the newer g= cc. **** > >> 2. It is possible that updating the metakit may make the problem go away= . >> > A newer version of metakit has not yet been ported to FreeBSD, from the > looks of the patches required for the last version, it should be pretty > easy to port over, if I don't see anyone taking care of this perhaps > I'll give it a shot this weekend.. > > Thanks, > Dan > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > E4graph-core mailing list > E4g...@li... > https://lists.sourceforge.net/lists/listinfo/e4graph-core ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ E4graph-core mailing list E4g...@li... https://lists.sourceforge.net/lists/listinfo/e4graph-core |
|
From: Fletcher, J. P <j.p...@as...> - 2007-12-01 21:43:06
|
Jeff I have had a chance to have a look at this myself, with the same results, b= ut with a different version of the gcc compiler (4.0.2) and the latest meta= kit (2.4.9.7). It seems that the metakit version makes no difference. I a= m clear that the bug goes away if I take out the optimisation. I suppose t= hat is really a bug in the compiler, in that optimisation changes the behav= iour, which it should not. One workaround is to remove the garbage collect= ion call (DRV_DoGC) from e4_StorageImpl::NotReferenced (i4storage.cpp line = 1610) but that is to introduce a different problem, although the tests do t= hen run with optimisation on. I have had a go at looking at the code for= the GC which is in mkstorage.cpp. I tried looking at the assembler code w= ith and without optimisation but I do not know enough to be able to spot an= y problems. It may be that the behaviour is changed with newer compilers (= e.g. 4.3?). I had not done any work on E4Graph for several years until this thread star= ted up. I was at that time getting regular updates from Jacob, and had bee= n contributing fixes and minor modifications, mainly to the XML decoding wh= ich was of interest to me at that time. I would be happy to contribute tho= se if someone takes up the development. As regards whether this is useful or not, it seems to me that metakit is li= kely to stay around for some time even if there is a new development, as it= is used by a number of applications. E4Graph seems to me to be a good ide= a sitting on top of metakit and providing a user friendly structure. I hav= e done some work myself to interface that to Ruby using SWIG. I hope we can iron out the present difficulty. Best wishes John ________________________________________ From: e4g...@li... [e4graph-core-bounces@list= s.sourceforge.net] On Behalf Of Jeff Rose [ro...@gm...] Sent: 29 November 2007 16:48 To: e4g...@li... Subject: Re: [E4graph-core] ping Here we go... $ gcc --version gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) I'm just checking out metakit from the subversion repository, but first I'll try to use the latest Ubuntu Gutsy version of metakit listed as: libmetakit2.4.9.3c2. I've got both the last e4graph release as well as the latest version in cvs. First, the build system is a bit broken. It could probably just do ./configure && make && make install like most open source projects for linux/unix these days. It requires that you run autoconf first. It is also checking for python, java and expat, even when not passing those flags to configure. In the latest release it still continues, but in the cvs version it fails the configure (even when passing --disable-tcl --disable-java --disable-python). So for now I'll just use the latest release because I don't want to deal with debugging the configure script... So, latest e4graph release with metakit in ubuntu: $./testcore a Running e4_DString tests: ..... Running e4_Refcount tests: .... Running e4_Storage tests: ...Segmentation fault From a gdb run with -ggdb: (gdb) bt #0 0x00000000 in ?? () #1 0xb7f88e9c in e4_StorageImpl::NotReferenced (this=3D0x809f7a0) at ../impl/i4storage.cpp:1609 #2 0xb7f769a3 in ~e4_RefCount (this=3D0xbfff7bf8) at ../include/e4graphimpl.h:197 #3 0x0805a834 in test_storage5 () at ./../../main/include/e4graph.h:716 #4 0x0805c9e9 in test_storage () at ./../src/teststorage.cpp:1494 #5 0x0804ca47 in main (ac=3D2, av=3D0xbfff7d34) at ./../src/test.cpp:147 ----------------------------------------------------------- Ok, some more info. All tests pass when optimizations have been turned off. This is a nasty memory bug. Poking around with valgrind/gdb on the optimized version I think I've got it somewhat figured out though. Here is the relevant dump: Running e4_Storage tests: ...=3D=3D27925=3D=3D Invalid read of size 1 =3D=3D27925=3D=3D at 0x405BD82: e4_StorageImpl::CleanUp() (e4graphimpl.h= :397) =3D=3D27925=3D=3D by 0x405BE07: e4_StorageImpl::NotReferenced() (i4storage.cpp:1577) =3D=3D27925=3D=3D by 0x40499A2: e4_RefCount::~e4_RefCount() (e4graphimpl= .h:197) =3D=3D27925=3D=3D by 0x805A833: test_storage5() (e4graph.h:716) =3D=3D27925=3D=3D by 0x805C9E8: test_storage() (teststorage.cpp:1494) =3D=3D27925=3D=3D by 0x804CA46: main (test.cpp:147) =3D=3D27925=3D=3D Address 0x45C250D is 13 bytes inside a block of size 360= free'd =3D=3D27925=3D=3D at 0x4022096: operator delete(void*) (vg_replace_mallo= c.c:244) =3D=3D27925=3D=3D by 0x403C831: e4_MetakitStorageImpl::~e4_MetakitStorageImpl() (mkstorage.cpp:1096) =3D=3D27925=3D=3D by 0x405BEED: e4_StorageImpl::NotReferenced() (i4storage.cpp:1634) =3D=3D27925=3D=3D by 0x4049B2C: e4_RefCount::~e4_RefCount() (e4graphimpl= .h:197) =3D=3D27925=3D=3D by 0x405AB80: e4_StorageImpl::CauseEventInternal(int, e4_RefCounter*, void*) (i4storage.cpp:1833) =3D=3D27925=3D=3D by 0x403E278: e4_MetakitStorageImpl::DRV_Commit() (e4graphimpl.h:402) =3D=3D27925=3D=3D by 0x405BDE3: e4_StorageImpl::CleanUp() (e4graphimpl.h= :426) =3D=3D27925=3D=3D by 0x405BE07: e4_StorageImpl::NotReferenced() (i4storage.cpp:1577) =3D=3D27925=3D=3D by 0x40499A2: e4_RefCount::~e4_RefCount() (e4graphimpl= .h:197) =3D=3D27925=3D=3D by 0x805A833: test_storage5() (e4graph.h:716) =3D=3D27925=3D=3D by 0x805C9E8: test_storage() (teststorage.cpp:1494) =3D=3D27925=3D=3D by 0x804CA46: main (test.cpp:147) =3D=3D27925=3D=3D =3D=3D27925=3D=3D ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y --------------------- So the goal of this test is to check that the storage is correctly serialized when the destructor is called after going out of scope. That looks like it is happening correctly if you go through the bottom stack. (RefCount -> NotReferenced -> CleanUp -> DRV_Commit) Strangely, that seems to fire an event which results in the destructor getting called. This is bad, because that event was triggered from inside the destructor, so when it returns back out a bit to CleanUp() valgrind finds a read error. That means the program is reading an invalid variable, which make sense since it is operating on an already deleted object and trying to use non-existant member vars. I don't know anything about the event stuff or why an event is calling the destructor, and I think I'm done for now. Hopefully someone who knows a bit about it can use this info to find the event and make it not call the destructor. On a related note, is it worth doing this work? Is anyone with commit access paying attention? I saw a message somewhere about writing a new graph library like e4graph on top of the new_new metakit, vlerq. Anyone know much about vlerq? Ciao, Jeff Fletcher, John P wrote: > Daniel > > See comment below. e4graph needs a fix of some sort. > > John > ________________________________________ > From: Daniel Rucci [da...@ru...] > Sent: 29 November 2007 07:36 > To: Fletcher, John P > Cc: e4g...@li... > Subject: Re: [E4graph-core] ping > > Fletcher, John P wrote: >> [snip] >> Things that occur to me to check. >> >> 1. Do the corresponding tests for metakit run O.K. either for 2.4.9.3 or= later? >> That will establish whether the problem is in metakit or e4graph >> > The test suite for metakit 2.4.9.3_4 using gcc 4.2.1 & 4.2.3 competed > successfully. > > **** That means that there must be a problem with e4graph and the newer g= cc. **** > >> 2. It is possible that updating the metakit may make the problem go away= . >> > A newer version of metakit has not yet been ported to FreeBSD, from the > looks of the patches required for the last version, it should be pretty > easy to port over, if I don't see anyone taking care of this perhaps > I'll give it a shot this weekend.. > > Thanks, > Dan > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > E4graph-core mailing list > E4g...@li... > https://lists.sourceforge.net/lists/listinfo/e4graph-core ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ E4graph-core mailing list E4g...@li... https://lists.sourceforge.net/lists/listinfo/e4graph-core |
|
From: Jeff R. <ro...@gm...> - 2007-11-29 16:48:34
|
Here we go...
$ gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I'm just checking out metakit from the subversion repository, but first
I'll try to use the latest Ubuntu Gutsy version of metakit listed as:
libmetakit2.4.9.3c2.
I've got both the last e4graph release as well as the latest version in
cvs. First, the build system is a bit broken. It could probably just do
./configure && make && make install
like most open source projects for linux/unix these days. It requires
that you run autoconf first. It is also checking for python, java and
expat, even when not passing those flags to configure. In the latest
release it still continues, but in the cvs version it fails the
configure (even when passing --disable-tcl --disable-java
--disable-python). So for now I'll just use the latest release because
I don't want to deal with debugging the configure script...
So, latest e4graph release with metakit in ubuntu:
$./testcore a
Running e4_DString tests: .....
Running e4_Refcount tests: ....
Running e4_Storage tests: ...Segmentation fault
From a gdb run with -ggdb:
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xb7f88e9c in e4_StorageImpl::NotReferenced (this=0x809f7a0)
at ../impl/i4storage.cpp:1609
#2 0xb7f769a3 in ~e4_RefCount (this=0xbfff7bf8) at
../include/e4graphimpl.h:197
#3 0x0805a834 in test_storage5 () at ./../../main/include/e4graph.h:716
#4 0x0805c9e9 in test_storage () at ./../src/teststorage.cpp:1494
#5 0x0804ca47 in main (ac=2, av=0xbfff7d34) at ./../src/test.cpp:147
-----------------------------------------------------------
Ok, some more info. All tests pass when optimizations have been turned
off. This is a nasty memory bug. Poking around with valgrind/gdb on
the optimized version I think I've got it somewhat figured out though.
Here is the relevant dump:
Running e4_Storage tests: ...==27925== Invalid read of size 1
==27925== at 0x405BD82: e4_StorageImpl::CleanUp() (e4graphimpl.h:397)
==27925== by 0x405BE07: e4_StorageImpl::NotReferenced()
(i4storage.cpp:1577)
==27925== by 0x40499A2: e4_RefCount::~e4_RefCount() (e4graphimpl.h:197)
==27925== by 0x805A833: test_storage5() (e4graph.h:716)
==27925== by 0x805C9E8: test_storage() (teststorage.cpp:1494)
==27925== by 0x804CA46: main (test.cpp:147)
==27925== Address 0x45C250D is 13 bytes inside a block of size 360 free'd
==27925== at 0x4022096: operator delete(void*) (vg_replace_malloc.c:244)
==27925== by 0x403C831:
e4_MetakitStorageImpl::~e4_MetakitStorageImpl() (mkstorage.cpp:1096)
==27925== by 0x405BEED: e4_StorageImpl::NotReferenced()
(i4storage.cpp:1634)
==27925== by 0x4049B2C: e4_RefCount::~e4_RefCount() (e4graphimpl.h:197)
==27925== by 0x405AB80: e4_StorageImpl::CauseEventInternal(int,
e4_RefCounter*, void*) (i4storage.cpp:1833)
==27925== by 0x403E278: e4_MetakitStorageImpl::DRV_Commit()
(e4graphimpl.h:402)
==27925== by 0x405BDE3: e4_StorageImpl::CleanUp() (e4graphimpl.h:426)
==27925== by 0x405BE07: e4_StorageImpl::NotReferenced()
(i4storage.cpp:1577)
==27925== by 0x40499A2: e4_RefCount::~e4_RefCount() (e4graphimpl.h:197)
==27925== by 0x805A833: test_storage5() (e4graph.h:716)
==27925== by 0x805C9E8: test_storage() (teststorage.cpp:1494)
==27925== by 0x804CA46: main (test.cpp:147)
==27925==
==27925== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
---------------------
So the goal of this test is to check that the storage is correctly
serialized when the destructor is called after going out of scope. That
looks like it is happening correctly if you go through the bottom stack.
(RefCount -> NotReferenced -> CleanUp -> DRV_Commit) Strangely, that
seems to fire an event which results in the destructor getting called.
This is bad, because that event was triggered from inside the
destructor, so when it returns back out a bit to CleanUp() valgrind
finds a read error. That means the program is reading an invalid
variable, which make sense since it is operating on an already deleted
object and trying to use non-existant member vars.
I don't know anything about the event stuff or why an event is calling
the destructor, and I think I'm done for now. Hopefully someone who
knows a bit about it can use this info to find the event and make it not
call the destructor.
On a related note, is it worth doing this work? Is anyone with commit
access paying attention? I saw a message somewhere about writing a new
graph library like e4graph on top of the new_new metakit, vlerq. Anyone
know much about vlerq?
Ciao,
Jeff
Fletcher, John P wrote:
> Daniel
>
> See comment below. e4graph needs a fix of some sort.
>
> John
> ________________________________________
> From: Daniel Rucci [da...@ru...]
> Sent: 29 November 2007 07:36
> To: Fletcher, John P
> Cc: e4g...@li...
> Subject: Re: [E4graph-core] ping
>
> Fletcher, John P wrote:
>> [snip]
>> Things that occur to me to check.
>>
>> 1. Do the corresponding tests for metakit run O.K. either for 2.4.9.3 or later?
>> That will establish whether the problem is in metakit or e4graph
>>
> The test suite for metakit 2.4.9.3_4 using gcc 4.2.1 & 4.2.3 competed
> successfully.
>
> **** That means that there must be a problem with e4graph and the newer gcc. ****
>
>> 2. It is possible that updating the metakit may make the problem go away.
>>
> A newer version of metakit has not yet been ported to FreeBSD, from the
> looks of the patches required for the last version, it should be pretty
> easy to port over, if I don't see anyone taking care of this perhaps
> I'll give it a shot this weekend..
>
> Thanks,
> Dan
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> E4graph-core mailing list
> E4g...@li...
> https://lists.sourceforge.net/lists/listinfo/e4graph-core
|
|
From: Fletcher, J. P <j.p...@as...> - 2007-11-29 12:45:25
|
Daniel
See comment below. e4graph needs a fix of some sort.
John
________________________________________
From: Daniel Rucci [da...@ru...]
Sent: 29 November 2007 07:36
To: Fletcher, John P
Cc: e4g...@li...
Subject: Re: [E4graph-core] ping
Fletcher, John P wrote:
> [snip]
> Things that occur to me to check.
>
> 1. Do the corresponding tests for metakit run O.K. either for 2.4.9.3 or =
later?
> That will establish whether the problem is in metakit or e4graph
>
The test suite for metakit 2.4.9.3_4 using gcc 4.2.1 & 4.2.3 competed
successfully.
**** That means that there must be a problem with e4graph and the newer gcc=
. ****
> 2. It is possible that updating the metakit may make the problem go away.
>
A newer version of metakit has not yet been ported to FreeBSD, from the
looks of the patches required for the last version, it should be pretty
easy to port over, if I don't see anyone taking care of this perhaps
I'll give it a shot this weekend..
Thanks,
Dan
|
|
From: Daniel R. <da...@ru...> - 2007-11-29 12:34:47
|
Fletcher, John P wrote:
> [snip]
> Things that occur to me to check.
>
> 1. Do the corresponding tests for metakit run O.K. either for 2.4.9.3 or later?
> That will establish whether the problem is in metakit or e4graph
>
The test suite for metakit 2.4.9.3_4 using gcc 4.2.1 & 4.2.3 competed
successfully.
> 2. It is possible that updating the metakit may make the problem go away.
>
A newer version of metakit has not yet been ported to FreeBSD, from the
looks of the patches required for the last version, it should be pretty
easy to port over, if I don't see anyone taking care of this perhaps
I'll give it a shot this weekend..
Thanks,
Dan
|
|
From: Fletcher, J. P <j.p...@as...> - 2007-11-29 11:13:52
|
Daniel It looks to me that the problem is when a destructor is called when somethi= ng is going out of scope. I have had a look at the metakit changes file up= to 2.4.9.7 to see whether there was anything relevant there, but have foun= d nothing obvious. Things that occur to me to check. 1. Do the corresponding tests for metakit run O.K. either for 2.4.9.3 or la= ter? That will establish whether the problem is in metakit or e4graph 2. It is possible that updating the metakit may make the problem go away. Sorry that I don't have time to any tests myself. Best wishes John Dr John P. Fletcher Tel: (44) 121 204 3389 (direct line) Chemical Engineering and Applied Chemistry (CEAC), School of Engineering and Applied Science (SEAS), Aston University, Aston Triangle, BIRMINGHAM B4 7ET U.K. CEAC Web site http://www.ceac.aston.ac.uk/ FAX: (44) 121 204 3679 -----Original Message----- From: Daniel Rucci [mailto:da...@ru...] Sent: 29 November 2007 05:49 To: Fletcher, John P Cc: e4g...@li... Subject: Re: [E4graph-core] ping Fletcher, John P wrote: > Daniel > > I was a bit puzzled by the old version of metakit, 2.4.0!! > > The other difference is the move from gcc 3.4.6 to gcc 4.2.1 > > I have known this move to break code in msyterious ways, mainly because t= he language was implemented more strictly and some wrong things in the C++ = stopped working. It might be inheritance - something private when it shoul= d be public, in the E4Graph code and not being picked up at compile time. > Between step 5 and step 6 of storage5 test I added some output and determin= ed where the exception occurs /* * Now rely on the C++ scoping rules to cause a commit. */ fprintf(stderr,"at the end of scope\n"); } //The error happens here, when the scope is closed { fprintf(stderr, "start of next scope\n"); e4_Storage s2("foo.db", E4_METAKIT); Only 'at the end of scope' is printed. Anyone comfortable with the scoping changes for newer versions of gcc? Thanks, Dan |
|
From: Daniel R. <da...@ru...> - 2007-11-29 10:47:14
|
Fletcher, John P wrote:
> Daniel
>
> I was a bit puzzled by the old version of metakit, 2.4.0!!
>
> The other difference is the move from gcc 3.4.6 to gcc 4.2.1
>
> I have known this move to break code in msyterious ways, mainly because the language was implemented more strictly and some wrong things in the C++ stopped working. It might be inheritance - something private when it should be public, in the E4Graph code and not being picked up at compile time.
>
Between step 5 and step 6 of storage5 test I added some output and
determined where the exception occurs
/*
* Now rely on the C++ scoping rules to cause a commit.
*/ fprintf(stderr,"at the end of scope\n");
} //The error happens here, when the scope is closed
{
fprintf(stderr, "start of next scope\n");
e4_Storage s2("foo.db", E4_METAKIT);
Only 'at the end of scope' is printed.
Anyone comfortable with the scoping changes for newer versions of gcc?
Thanks,
Dan
|
|
From: Fletcher, J. P <j.p...@as...> - 2007-11-28 11:38:20
|
Daniel I was a bit puzzled by the old version of metakit, 2.4.0!! The other difference is the move from gcc 3.4.6 to gcc 4.2.1 I have known this move to break code in msyterious ways, mainly because the= language was implemented more strictly and some wrong things in the C++ st= opped working. It might be inheritance - something private when it should = be public, in the E4Graph code and not being picked up at compile time. I hope this helps. John ________________________________________ From: Daniel Rucci [da...@ru...] Sent: 28 November 2007 06:33 To: Fletcher, John P Cc: e4g...@li... Subject: Re: [E4graph-core] ping Daniel Rucci wrote: > Fletcher, John P wrote: >> Dear All >> >> I have not run any tests. What I do see is that metakit has moved on >> in version, I think to 2.4.9.7 while E4Graph which uses it has not. >> It may be useful to note which version of metakit is being used in >> the different tests. Some Linux distributions e.g. fedora6 actually >> have an option to install metakit and metakit-devel, but not in that >> case the python or tcl interfaces. >> >> Best wishes >> >> John >> > True but that would not explain why I am experiencing problems on 1 > setup and not the other, both are running metakit-2.4.0.3_4 Sorry, meant to write 2.4.9.3_4 there |
|
From: Daniel R. <da...@ru...> - 2007-11-28 11:30:55
|
Daniel Rucci wrote: > Fletcher, John P wrote: >> Dear All >> >> I have not run any tests. What I do see is that metakit has moved on >> in version, I think to 2.4.9.7 while E4Graph which uses it has not. >> It may be useful to note which version of metakit is being used in >> the different tests. Some Linux distributions e.g. fedora6 actually >> have an option to install metakit and metakit-devel, but not in that >> case the python or tcl interfaces. >> >> Best wishes >> >> John >> > True but that would not explain why I am experiencing problems on 1 > setup and not the other, both are running metakit-2.4.0.3_4 Sorry, meant to write 2.4.9.3_4 there |
|
From: Daniel R. <da...@ru...> - 2007-11-28 11:23:26
|
Fletcher, John P wrote: > Dear All > > I have not run any tests. What I do see is that metakit has moved on in version, I think to 2.4.9.7 while E4Graph which uses it has not. It may be useful to note which version of metakit is being used in the different tests. Some Linux distributions e.g. fedora6 actually have an option to install metakit and metakit-devel, but not in that case the python or tcl interfaces. > > Best wishes > > John > True but that would not explain why I am experiencing problems on 1 setup and not the other, both are running metakit-2.4.0.3_4 Heres an update on the gdb output, i built the test libs with ggdb3: #7 0x28101c42 in e4_StorageImpl::NotReferenced () from /usr/ports/devel/e4graph/work/e4graph-1.0a11/all/../builds/i386-portbld-freebsd7.0/libs/libe4graph.so #8 0x280ee837 in e4_RefCount::~e4_RefCount () from /usr/ports/devel/e4graph/work/e4graph-1.0a11/all/../builds/i386-portbld-freebsd7.0/libs/libe4graph.so #9 0x0805aafe in test_storage5 () at e4graph.h:716 #10 0x0805c996 in test_storage () at ./../src/teststorage.cpp:1494 #11 0x0804ca19 in main (ac=Cannot access memory at address 0x5 And in a second attempt, added some more output; looks like it segfaults at step 6... test storage5 passed step 1 test storage5 passed step 2.a test storage5 passed step 3 test storage5 passed step 3.a test storage5 passed step 4 test storage5 passed step 5 > Jeff Rose wrote: > >> Hello out there, >> Anyone still here? I thought I'd try to knock the dust of the >> mailing list here. Are people still using e4Graph? I'm getting a >> segfault when running the unit tests on a fresh build in Ubuntu Gutsy, >> and the python bindings don't build because of a syntax error. Is this >> library just getting old and unloved? >> >> > Hey Jeff, First off, I love it. Now, about the unit tests, which I've > never actually ran until tonight. > > For FreeBSD 6.3-PRERELEASE with gcc 3.4.6 > > I get this output when running the tests: > Running e4_DString tests: ..... > Running e4_Refcount tests: .... > Running e4_Storage tests: ..................... > Running e4_Node tests: ........................................... > Running e4_Vertex tests: ............... > Running e4_StorageVisitor tests: .. > Running e4_NodeVisitor tests: ....... > Running e4_VertexVisitor tests: ............................ > Running callback tests: ...... > Running detach tests: ........ > > Which I believe means everything passed. > > However on 7.0-BETA3 FreeBSD 7.0-BETA3 with > gcc version 4.2.1 20070719 AND > gcc version 4.2.3 20071024 I get: > > Running e4_DString tests: ..... > Running e4_Refcount tests: .... > Running e4_Storage tests: ...pure virtual method called > terminate called without an active exception > Abort trap: 6 (core dumped) > > And some gdb: > #0 0x282ef0d7 in kill () from /lib/libc.so.7 > #1 0x282ef036 in raise () from /lib/libc.so.7 > #2 0x282edc4a in abort () from /lib/libc.so.7 > #3 0x28175b80 in __gnu_cxx::__verbose_terminate_handler () from > /usr/lib/libstdc++.so.6 > #4 0x2817a02a in std::set_unexpected () from /usr/lib/libstdc++.so.6 > #5 0x2817a072 in std::terminate () from /usr/lib/libstdc++.so.6 > #6 0x281c3b55 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6 > #7 0x28101c42 in e4_StorageImpl::NotReferenced () from > /usr/local/lib/libe4graph.so > #8 0x280ee837 in e4_RefCount::~e4_RefCount () from > /usr/local/lib/libe4graph.so > #9 0x08070b2e in test_storage5 () > #10 0x080729c6 in test_storage () > #11 0x0804ca19 in main () > > If someone can do something with the output I'll rebuild with debugging > symbols. > > Is this the same spot your unit test fail in Linux? > > Cheers, > Daniel Rucci > > |
|
From: Fletcher, J. P <j.p...@as...> - 2007-11-28 11:01:47
|
Dear All I have not run any tests. What I do see is that metakit has moved on in ve= rsion, I think to 2.4.9.7 while E4Graph which uses it has not. It may be u= seful to note which version of metakit is being used in the different tests= . Some Linux distributions e.g. fedora6 actually have an option to install= metakit and metakit-devel, but not in that case the python or tcl interfac= es. Best wishes John ________________________________________ From: e4g...@li... [e4graph-core-bounces@list= s.sourceforge.net] On Behalf Of Daniel Rucci [dev...@ru...] Sent: 28 November 2007 05:42 To: Jeff Rose Cc: e4g...@li... Subject: Re: [E4graph-core] ping Jeff Rose wrote: > Hello out there, > Anyone still here? I thought I'd try to knock the dust of the > mailing list here. Are people still using e4Graph? I'm getting a > segfault when running the unit tests on a fresh build in Ubuntu Gutsy, > and the python bindings don't build because of a syntax error. Is this > library just getting old and unloved? > Hey Jeff, First off, I love it. Now, about the unit tests, which I've never actually ran until tonight. For FreeBSD 6.3-PRERELEASE with gcc 3.4.6 I get this output when running the tests: Running e4_DString tests: ..... Running e4_Refcount tests: .... Running e4_Storage tests: ..................... Running e4_Node tests: ........................................... Running e4_Vertex tests: ............... Running e4_StorageVisitor tests: .. Running e4_NodeVisitor tests: ....... Running e4_VertexVisitor tests: ............................ Running callback tests: ...... Running detach tests: ........ Which I believe means everything passed. However on 7.0-BETA3 FreeBSD 7.0-BETA3 with gcc version 4.2.1 20070719 AND gcc version 4.2.3 20071024 I get: Running e4_DString tests: ..... Running e4_Refcount tests: .... Running e4_Storage tests: ...pure virtual method called terminate called without an active exception Abort trap: 6 (core dumped) And some gdb: #0 0x282ef0d7 in kill () from /lib/libc.so.7 #1 0x282ef036 in raise () from /lib/libc.so.7 #2 0x282edc4a in abort () from /lib/libc.so.7 #3 0x28175b80 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #4 0x2817a02a in std::set_unexpected () from /usr/lib/libstdc++.so.6 #5 0x2817a072 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0x281c3b55 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6 #7 0x28101c42 in e4_StorageImpl::NotReferenced () from /usr/local/lib/libe4graph.so #8 0x280ee837 in e4_RefCount::~e4_RefCount () from /usr/local/lib/libe4graph.so #9 0x08070b2e in test_storage5 () #10 0x080729c6 in test_storage () #11 0x0804ca19 in main () If someone can do something with the output I'll rebuild with debugging symbols. Is this the same spot your unit test fail in Linux? Cheers, Daniel Rucci ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ E4graph-core mailing list E4g...@li... https://lists.sourceforge.net/lists/listinfo/e4graph-core |
|
From: Daniel R. <dev...@ru...> - 2007-11-28 10:40:02
|
Jeff Rose wrote:
> Hello out there,
> Anyone still here? I thought I'd try to knock the dust of the
> mailing list here. Are people still using e4Graph? I'm getting a
> segfault when running the unit tests on a fresh build in Ubuntu Gutsy,
> and the python bindings don't build because of a syntax error. Is this
> library just getting old and unloved?
>
Hey Jeff, First off, I love it. Now, about the unit tests, which I've
never actually ran until tonight.
For FreeBSD 6.3-PRERELEASE with gcc 3.4.6
I get this output when running the tests:
Running e4_DString tests: .....
Running e4_Refcount tests: ....
Running e4_Storage tests: .....................
Running e4_Node tests: ...........................................
Running e4_Vertex tests: ...............
Running e4_StorageVisitor tests: ..
Running e4_NodeVisitor tests: .......
Running e4_VertexVisitor tests: ............................
Running callback tests: ......
Running detach tests: ........
Which I believe means everything passed.
However on 7.0-BETA3 FreeBSD 7.0-BETA3 with
gcc version 4.2.1 20070719 AND
gcc version 4.2.3 20071024 I get:
Running e4_DString tests: .....
Running e4_Refcount tests: ....
Running e4_Storage tests: ...pure virtual method called
terminate called without an active exception
Abort trap: 6 (core dumped)
And some gdb:
#0 0x282ef0d7 in kill () from /lib/libc.so.7
#1 0x282ef036 in raise () from /lib/libc.so.7
#2 0x282edc4a in abort () from /lib/libc.so.7
#3 0x28175b80 in __gnu_cxx::__verbose_terminate_handler () from
/usr/lib/libstdc++.so.6
#4 0x2817a02a in std::set_unexpected () from /usr/lib/libstdc++.so.6
#5 0x2817a072 in std::terminate () from /usr/lib/libstdc++.so.6
#6 0x281c3b55 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6
#7 0x28101c42 in e4_StorageImpl::NotReferenced () from
/usr/local/lib/libe4graph.so
#8 0x280ee837 in e4_RefCount::~e4_RefCount () from
/usr/local/lib/libe4graph.so
#9 0x08070b2e in test_storage5 ()
#10 0x080729c6 in test_storage ()
#11 0x0804ca19 in main ()
If someone can do something with the output I'll rebuild with debugging
symbols.
Is this the same spot your unit test fail in Linux?
Cheers,
Daniel Rucci
|
|
From: Fletcher, J. P <j.p...@as...> - 2007-11-26 22:52:36
|
Jeff I am still here and reading the E4Graph list. I have not made much use of = it for some time, although my reason for being interested has not gone away= . I did work on the code quite closely at one time and might be able to he= lp with your problem. I haven't tried to compile either E4Graph or Metakit= with an uptodate compiler, which could be the problem if a test routine fa= ils. Best wishes John Fletcher ________________________________________ From: e4g...@li... [e4graph-core-bounces@list= s.sourceforge.net] On Behalf Of Jeff Rose [ro...@gm...] Sent: 26 November 2007 13:36 To: e4g...@li... Subject: [E4graph-core] ping Hello out there, Anyone still here? I thought I'd try to knock the dust of the mailing list here. Are people still using e4Graph? I'm getting a segfault when running the unit tests on a fresh build in Ubuntu Gutsy, and the python bindings don't build because of a syntax error. Is this library just getting old and unloved? If there are people on the list who have a bit of experience using e4Graph developing an application it would be great to hear your experiences. I'm starting development on a graph based, distributed computing platform for my PhD thesis, and I think a modified version of this library or something like it will probably serve as the foundation for everything. So if people have run into major issues with either the data model or something related to programming on top of graphs it would be great to know about them now since I'm in the early stages of the project. Cheers, Jeff ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ E4graph-core mailing list E4g...@li... https://lists.sourceforge.net/lists/listinfo/e4graph-core |
|
From: Jeff R. <ro...@gm...> - 2007-11-26 13:36:51
|
Hello out there, Anyone still here? I thought I'd try to knock the dust of the mailing list here. Are people still using e4Graph? I'm getting a segfault when running the unit tests on a fresh build in Ubuntu Gutsy, and the python bindings don't build because of a syntax error. Is this library just getting old and unloved? If there are people on the list who have a bit of experience using e4Graph developing an application it would be great to hear your experiences. I'm starting development on a graph based, distributed computing platform for my PhD thesis, and I think a modified version of this library or something like it will probably serve as the foundation for everything. So if people have run into major issues with either the data model or something related to programming on top of graphs it would be great to know about them now since I'm in the early stages of the project. Cheers, Jeff |
|
From: David V. M. <da...@va...> - 2006-09-04 16:49:58
|
On Friday 25 August 2006 21:07, Daniel Rucci wrote: > Is this project still being maintained? > I haven't heard anything from Jacob Levy since March of 2005. We're still using the SW in our product, and are quite happy with it, and know of no bugs in it. Strictly speaking, it's not under development, and hasn't changed in quite a while, but it hasn't needed any maintenance, AFAIK. Are you looking for some new functionality? DVM |
|
From: Daniel R. <dev...@ru...> - 2006-08-26 03:07:56
|
Is this project still being maintained?
Thanks,
Dan
|
|
From: <aku...@sh...> - 2004-08-20 02:34:57
|
11'th Annual Tcl/Tk Conference
October 11 - 15, 2004
New Orleans, Louisiana, USA
Email Contact tc...@tc...
We are pleased to announce the 11'th Annual Tcl/Tk conference
(Tcl'2004), sponsored by Noumena Corporation, in cooperation with
ActiveState and ExpoTech.
Come to New Orleans to:
* Learn about the power of Tcl/Tk.
* Present exciting new work involving Tcl/Tk.
* See the latest developments in Tcl/Tk.
* Meet Tcl/Tk researchers and users from academia, government and industry.
* Plan for future Tcl/Tk related developments.
The conference program will include paper presentations,
tutorials, Birds of a Feather (BOF) sessions and invited key-note
talks.
Registration
Online registration is ready now.
<http://www.tcl.tk/community/tcl2004/reg.html>
Tutorials
Come learn about Tcl from the experts. This year's Tcl/Tk
Conference includes one of the best sets of Tutorials ever offered
including tutorials on Jacl, TclHttpd,
Starkit, Advanced GUI construction, and the API.
<http://www.tcl.tk/community/tcl2004/tut2004.html>
Schedule
More details will be added to the schedule as they become
available.
<http://www.tcl.tk/community/tcl2004/schedule.html>
Those attending the conference will be interested in the
conference info page.
<http://www.tcl.tk/community/tcl2004/info.html>
To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list.
<http://listserv.activestate.com/mailman/mysubs?show=announce>
Other Forms of Participation
For those who are not presenting a paper at the conference, but
would like to present their work in some form, we do provide
several other forms of participation.
Slots for Works-in-Progress (WIP) presentations and
Birds-of-a-Feather sessions (BOFs) are available on a first-come,
first-served basis by sending email to tc...@tc.... Some WIP
and BOF time slots will be held open for on-site reservation, so
we encourage all attendees with interesting work in progress to
consider presenting that work at the conference.
Conference Committee
Gerald Lester HMS Software General Chair
Andreas Kupries ActiveState Corp
Clif Flynt Noumena Corp Website Admin
Jeffrey Hobbs ActiveState Corp
Kevin Kenny GE Global Research Center
Ken Jones Avia Training
Mac Cody Raytheon Company
Kim Richerts
Steve Landers Digital Smarties
Sheila Miguez Motorola
Larry Virden Tcl FAQ Maintainer
Contact Information
tc...@tc...
|
|
From: Colin M. <co...@ch...> - 2003-11-15 04:18:56
|
I have tclVFS fever at the moment - anything that sits still long enough, I'll write a VFS for it. e4graph would seem to be a good candidate. I have some questions/observations, though, pertaining to vertex properties: A directory is a node with node out-vertices, and with some data associated with those vertices (specifically: permissions, owner, group, access times, and so on.) It seems that e4graph uses vertices as a means of storing attributes, which is a clever reduction, but means that vertices don't have attributes - this is a bit of a shame, because vertex 'colouring' is sometimes useful (and some of the above properties like permissions in a directory are examples of this.) I don't know if this is worth worrying about, if it's hard to do within the architecture of e4graph - if it is, don't worry about it, but if it's easy to add, it might be worth adding. Assuming the architecture precludes giving vertices properties, for efficiency or other reasons, there may be a couple of ways around it: 1) having multiple vertices with the same name, and different values, such as key/value lists, and traversing the range of vertices with the same name to collect these properties. This would work with filesystem semantics, because each file entry in a directory is unique, and so duplicate names can convey meaning. It wouldn't be too inefficient, I guess, because one could discriminate the actual file content by type (outgoing file edges with a name would have vertex type node, attributes would have vertex type string.) 2) using e4graph to manage the namespace, and storing attributes externally, in a flat namespace. To do this, one would have to index by some unique and immutable property of the vertex. Could this be: a) $vertex id ... does this change between compactions of the db? b) if id is mutable, then $vertex userdata could be used to store a unique immutable id for a given node ... or even extended to contain the complete node attribute/property set. Which of these approaches are consistent with your long-term vision for e4graph, Jacob? -- Colin McCormack <co...@ch...> |
|
From: Khorev S. <Kh...@So...> - 2003-11-04 10:10:25
|
This list seems to be ve-e-e-ry silent :)) I'm trying to implement persistence for MzScheme using e4Graph. Have some questions: 1) The current version is 1.09 alpha. Does "alpha" relate to code quality or feature set? It seems that e4Graph has good code coverage by tests, am I right? 2) I don't want to expose full e4Graph interface to Scheme (at least for now) because Scheme has its own good data structures :) But I want to store this "good data structs" with e4Graph. And I don't want to store e4_Nodes and Vertices in memory, managed by MzScheme GCollector. So, are the following actions safe? e4_Storage stg; e4_Node node; ... // here goes node loading e4_NodeUniqueID uid; node.GetUniqueID(uid); int saved_node_id = uid.GetUniqueID(); ...// here goes other actions WITHOUT closing storage e4_Node node2; e4_NodeUniqueID uid2; uid2.SetUniqueID(saved_node_id, stg); stg.GetNodeFromID(uid2, node2); assert(node == node2) -- Sergey Khorev http://iamphet.nm.ru Get thee down. Be thou funky. |
|
From: <bo...@go...> - 2003-09-02 06:43:35
|
Hi, The site says the last version is alfa 9. When or where can we get it ? From what I see, the latest additions were done only for C++ and and TCL. Isn't the Python actively supported ? What about a simple 'setup.py' file to create an installer for the e4py ? I want to use the e4graph for a "Where Is It ?" GPL clone written with Python 2.3, WxPython and e4graph. (I've started working on it, but it goes a bit slow as I can dedicate it only 1 hour per day, before going at work ;-) I'd be more confident if I know the Python biding is actively supported, too, by e4graph. TIA, Ionutz |
|
From: John F. <J.P...@as...> - 2001-05-22 14:40:09
|
Date sent: Sat, 19 May 2001 10:36:53 -0700
From: Jacob Levy <jy...@be...>
Organization: Leage of Retired Slug Programmers
To: jacob levy <jac...@en...>
Copies to: jc...@eq..., j.p...@as..., dj...@dj...,
da...@cy..., ho...@fr..., ry...@si...,
cl...@st..., uwe...@un...
Subject: Re: e4Graph release schedule
> Revised release schedule:
>
> June 14 2001: e4Graph 1.0b1
> July 9: e4Graph 1.0b2
> August 4: e4Graph 1.0 final.
>
> The additional time in the schedule is there in the hopes of getting
> complete support for Mac OS X in in time as well as a complete Java
> binding. That code has to be there in some form by e4Graph 1.0b1 or it gets
> deferred to 1.1.
>
> --JYL
>
Has anyone ever done a release of E4Graph for mingw32
(GCC 2.95.2). If so, I would be interested to know.
Thanks
John Fletcher
-------------------------------------------------------------------
Dr John P. Fletcher Tel: (44) 121 359 3611 ext 4625
Chemical Engineering and Applied Chemistry (CEAC),
School of Engineering and Applied Science (SEAS),
Aston University, Fax: (44) 121 359 4094
Aston Triangle, Email: J.P...@as...
BIRMINGHAM B4 7ET U.K. CEAC Web site http://www.ceac.aston.ac.uk/
|
|
From: Jacob L. <jy...@be...> - 2001-03-24 04:10:49
|
This is not a problem for my part. JC may reply for his part. --JYL John Fletcher wrote: > Jacob, Jean-Claude. > > As you can see from further down this message, I asked about f4_ > last September and have been using it without any problems ever > since. I would like to continue doing so, with JCW understanding > this. His use of f4_ seems to be internal. I have a lot of code > which all consistently uses it on all public functions and classes, > to keep them distinct from the ones in e4graph to which they are > related. > > John Fletcher > > Date sent: Sat, 17 Mar 2001 07:16:25 -0800 > From: Jacob Levy <jy...@be...> > Organization: Leage of Retired Slug Programmers > To: John Fletcher <J.P...@as...> > Copies to: Jean-Claude Wippler <jc...@eq...>, da...@cy..., dj...@dj... > Subject: Re: Use of f4_ as class and function prefix. > > > Sorry for the belated reply. I looked over the Metakit headers and none of the f4 stuff is > > exposed. I don't think there'll be any conflicts if you dynamically link with Metakit. I > > dont know what would happen if you statically link. I've been asked to create a statically > > linked e4Graph library for another user, so we will find out :). > > > > How about just avoiding the problem? I'm reserving the prefix e4_, and JC is reserving f4_ > > and probably c4_ (and maybe others). If I were in your position and depending on how > > widely you expect your layer to be distributed, I'd rename everything right now to a new > > prefix. > > > > Just my $0.02 of course.. > > > > --JYL > > > > John Fletcher wrote: > > > > > Date sent: Fri, 29 Sep 2000 10:08:27 -0700 > > > From: jacob levy <jac...@en...> > > > Subject: Re: e4graph > > > To: John Fletcher <J.P...@as...> > > > Copies to: Jacob Levy <jy...@be...>, Jean-Claude Wippler <jc...@eq...> > > > Organization: Sun Microsystems (SCT NJC group) > > > > > > > Sure, no problem. You can have the 'f4_' prefix. Of course I can't > > > > promise anything about other people who might also want to extend E4G. > > > > > > > > > > Hi > > > > > > Back last September, when I started to develop code to go with > > > e4Graph, I sent a message about using f4_ as a prefix for my > > > functions in order to avoid clashes with the e4_ in e4Graph. I have > > > been doing that ever since. Here is an extract from the reply. > > > > > > I have just found out while compiling metakit 2.3.3 that the prefix > > > f4_ is in fact used inside metakit for some internal functions. > > > > > > I don't think there is any direct clash of names at the moment, but > > > will keep an eye out for any possible problems. > > > > > > Cheers > > > > > > John > > > > > > ------------------------------------------------------------------- > > > Dr John P. Fletcher Tel: (44) 121 359 3611 ext 4625 > > > Chemical Engineering and Applied Chemistry (CEAC), > > > School of Engineering and Applied Science (SEAS), > > > Aston University, Fax: (44) 121 359 4094 > > > Aston Triangle, Email: J.P...@as... > > > BIRMINGHAM B4 7ET U.K. CEAC Web site http://www.ceac.aston.ac.uk/ > > > > > > ------------------------------------------------------------------- > Dr John P. Fletcher Tel: (44) 121 359 3611 ext 4625 > Chemical Engineering and Applied Chemistry (CEAC), > School of Engineering and Applied Science (SEAS), > Aston University, Fax: (44) 121 359 4094 > Aston Triangle, Email: J.P...@as... > BIRMINGHAM B4 7ET U.K. CEAC Web site http://www.ceac.aston.ac.uk/ |
|
From: John F. <J.P...@as...> - 2001-03-23 17:06:16
|
Jacob, Jean-Claude. As you can see from further down this message, I asked about f4_ last September and have been using it without any problems ever since. I would like to continue doing so, with JCW understanding this. His use of f4_ seems to be internal. I have a lot of code which all consistently uses it on all public functions and classes, to keep them distinct from the ones in e4graph to which they are related. John Fletcher Date sent: Sat, 17 Mar 2001 07:16:25 -0800 From: Jacob Levy <jy...@be...> Organization: Leage of Retired Slug Programmers To: John Fletcher <J.P...@as...> Copies to: Jean-Claude Wippler <jc...@eq...>, da...@cy..., dj...@dj... Subject: Re: Use of f4_ as class and function prefix. > Sorry for the belated reply. I looked over the Metakit headers and none of the f4 stuff is > exposed. I don't think there'll be any conflicts if you dynamically link with Metakit. I > dont know what would happen if you statically link. I've been asked to create a statically > linked e4Graph library for another user, so we will find out :). > > How about just avoiding the problem? I'm reserving the prefix e4_, and JC is reserving f4_ > and probably c4_ (and maybe others). If I were in your position and depending on how > widely you expect your layer to be distributed, I'd rename everything right now to a new > prefix. > > Just my $0.02 of course.. > > --JYL > > John Fletcher wrote: > > > Date sent: Fri, 29 Sep 2000 10:08:27 -0700 > > From: jacob levy <jac...@en...> > > Subject: Re: e4graph > > To: John Fletcher <J.P...@as...> > > Copies to: Jacob Levy <jy...@be...>, Jean-Claude Wippler <jc...@eq...> > > Organization: Sun Microsystems (SCT NJC group) > > > > > Sure, no problem. You can have the 'f4_' prefix. Of course I can't > > > promise anything about other people who might also want to extend E4G. > > > > > > > Hi > > > > Back last September, when I started to develop code to go with > > e4Graph, I sent a message about using f4_ as a prefix for my > > functions in order to avoid clashes with the e4_ in e4Graph. I have > > been doing that ever since. Here is an extract from the reply. > > > > I have just found out while compiling metakit 2.3.3 that the prefix > > f4_ is in fact used inside metakit for some internal functions. > > > > I don't think there is any direct clash of names at the moment, but > > will keep an eye out for any possible problems. > > > > Cheers > > > > John > > > > ------------------------------------------------------------------- > > Dr John P. Fletcher Tel: (44) 121 359 3611 ext 4625 > > Chemical Engineering and Applied Chemistry (CEAC), > > School of Engineering and Applied Science (SEAS), > > Aston University, Fax: (44) 121 359 4094 > > Aston Triangle, Email: J.P...@as... > > BIRMINGHAM B4 7ET U.K. CEAC Web site http://www.ceac.aston.ac.uk/ > > ------------------------------------------------------------------- Dr John P. Fletcher Tel: (44) 121 359 3611 ext 4625 Chemical Engineering and Applied Chemistry (CEAC), School of Engineering and Applied Science (SEAS), Aston University, Fax: (44) 121 359 4094 Aston Triangle, Email: J.P...@as... BIRMINGHAM B4 7ET U.K. CEAC Web site http://www.ceac.aston.ac.uk/ |
|
From: Rob P. <pry...@ho...> - 2001-03-04 16:47:53
|
Hi,
I'm currently having problems deleting markers from my storages using tgraph
(using verion 10a2). When I delete a marker from the storage (and then
commit the storage) it appears to be deleted, but then when I open the
storage again the marker has returned. The following tcl code is an example
of what I am doing:
#
# USed to test bits of code.
#
load tgraph
set database [tgraph::open foo2.db]
puts "The name of $database is [$database name]"
puts "mystorage isempty == [$database isempty]"
set mm1 [$database marker m1]
set mm2 [$database marker m2]
set mm3 [$database marker m3]
set mm4 [$database marker m4]
puts "markers"
puts $mm1
puts $mm2
puts $mm3
puts $mm4
puts "delete m4"
$mm4 delete
$database commit
$database foreach marker m {
puts [$m name]
}
$database close
the output from which is:
% The name of storage0 is foo2.db
mystorage isempty == 0
markers
::tgraph::storage0::markers::marker0
::tgraph::storage0::markers::marker1
::tgraph::storage0::markers::marker2
::tgraph::storage0::markers::marker3
delete m4
m1
m2
m3
Which suggest that the marker has been deleted, but the when I open the same
storage again the marker "m4" is still there.
Am I doing something wrong or is this a bug?
Thanks
Rob Pryce
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
|
|
From: John F. <J.P...@as...> - 2001-03-02 09:39:39
|
Hi all I am having trouble compiling Metakit 2.01 with Salford C++ (Win32) Motivation: Provide e4XML/e4graph/metakit interface from FORTRAN. Hence choice of compiler which is link compatible with FORTRAN. Also version of Metakit which is the one used in e4Graph. Problem: view.cpp will not compile as the compiler does not recognise the default constructor for c4_Row as valid and therefore statements such as c4_Row empty; do not compile. The compiler is fussy and I have done a number of workarounds already where I spelled something out more obviously an error went away. I have tried a lot of things and think one way MAY be to provide null objects for some of the things which are involved in constructing a c4_Row object, which is very complicated. Any thoughts would be much appreciated. John Fletcher ------------------------------------------------------------------- Dr John P. Fletcher Tel: (44) 121 359 3611 ext 4625 Chemical Engineering and Applied Chemistry (CEAC), School of Engineering and Applied Science (SEAS), Aston University, Fax: (44) 121 359 4094 Aston Triangle, Email: J.P...@as... BIRMINGHAM B4 7ET U.K. CEAC Web site http://www.ceac.aston.ac.uk/ |
