freestdf-devel Mailing List for STDF Solutions (Page 8)
Status: Beta
Brought to you by:
vapier
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
(38) |
Aug
(33) |
Sep
(14) |
Oct
(2) |
Nov
(5) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(7) |
Mar
|
Apr
|
May
(7) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(11) |
Dec
(8) |
2006 |
Jan
(3) |
Feb
|
Mar
(4) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
(13) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Tamas F. <tf...@li...> - 2004-07-15 10:16:31
|
> > And a little suggestion about the Generic record (GDR). The GEN_DATA > field can be a "dtc_Vn * GEN_DATA", a pointer to array of dtc_Vn > values. The size of this array is FLD_CNT. > Forget it, the cvs version solved this issue in a better way :) i updated the new version and i shut up ;) Tamas |
From: Tamas F. <tf...@li...> - 2004-07-14 11:38:26
|
Mike Frysinger wrote: >On Tuesday 13 July 2004 10:48 am, you wrote: > > >>MS VC++ 7, but it will be very simple, just for debug/dump stdf files. >>It is required for my current project, this is the reason why i have to >>write on win32 platform. >> >> > >ah i've never done a GUI app in pure VC++ ... let alone ver7 ;) > > I dont like VC++ (and i dont like developing on win32 platforms:), but creating GUIs in VC++ is fast and easy. >my work typically requires VB but i write most of the stuff by [ab]using the >win32 API's ... > >VC++ 7 is .NET right ? Yes, but we use only MFC and ATL classes/templates. Did you have any design plan about the STDF file write functionality? I think the following function can cover all STDF record write cases. int stdf_write_record(stdf_file*, rec_unknown*); From the rec_unknown->rec_header structure we can gather the REC_TYP and REC_SUB information, and with these values the implementation can calculate the record length (iterate on record members and summarize the item lengths based on used datatypes). rec_unknown->rec_header->REC_LEN can be filled with the calculated record length. The function return value can be the same (length of record), or error code (io errors in most cases). What do you think about this ? (it's just a first idea, and of course i dont want to disturb you with my first ideas, so if you are disturbed please let me know ;) Was any problems with the Vn datatype? It is currently disabled in the source... And a little suggestion about the Generic record (GDR). The GEN_DATA field can be a "dtc_Vn * GEN_DATA", a pointer to array of dtc_Vn values. The size of this array is FLD_CNT. typedef struct { rec_header header; dtc_U2 FLD_CNT; dtc_Vn *GEN_DATA; } rec_gdr; For get the 2nd data from GEN_DATA the user can use the rec_gdr->GEN_DATA[2] format. (The freestdf coding standard maybe requires a dtc_xVn type instead of using *GEN_DATA.) Have a nice day, Tamas |
From: Mike F. <va...@ge...> - 2004-07-13 14:43:21
|
On Tuesday 13 July 2004 05:17 am, Tamas Foldi wrote: > (I have to write a GUI stdf dumper program in the following weeks, if it > is finished, and you need that, i can send it) what language if you dont mind me asking ? -mike |
From: Tamas F. <tf...@li...> - 2004-07-13 09:18:02
|
Weida, Lloyd wrote: > Hello All, > > Can anyone tell me if the "libstdf-0.2.tar.bz2" stdf reader is > available to run on a pc ? > If you build libstdf 0.2 on win32 platform as static library and link with stdf dump example program, then you the answer is yes. I can send you the precompiled binary if you trust me :) But this dumper program is console based of course. (I have to write a GUI stdf dumper program in the following weeks, if it is finished, and you need that, i can send it) Tamas > Many thanks, > Lloyd > |
From: Mike F. <va...@ge...> - 2004-07-12 23:54:57
|
On Monday 12 July 2004 03:10 pm, Weida, Lloyd wrote: > Can anyone tell me if the "libstdf-0.2.tar.bz2" stdf reader is > available to run on a pc ? 0.2 comes with a win32 workspace you can load and build the dll if you're looking for some kind of GUI program that loads up STDF files and lets you manipulate them and all that jazz, then the answer is no i write this stuff in my spare time and havent made it that far yet ;) -mike |
From: Weida, L. <Llo...@an...> - 2004-07-12 19:11:01
|
Hello All, Can anyone tell me if the "libstdf-0.2.tar.bz2" stdf reader is available to run on a pc ? Many thanks, Lloyd |
From: Mike F. <va...@ge...> - 2004-07-08 22:18:22
|
bleh, i dont know what happened yesterday, but e-mail going from the freestdf mailing lists to my sf account seems to have stopped working ... i can receive mail for my sf account, just not through this list ;) i signed up another e-mail address, so things should be fine now ... i added support for reading stdf files compressed with zip/gzip/bzip2 to cvs ... was actually a lot easier than i thought i'd be :) i got a bunch of code in my local tree i'll commit later that makes the implementation a lot less ugly and lets the dump_stdf_to_html app run on them too ... results in neater interfaces i think :) -mike |
From: Mike F. <va...@ge...> - 2004-07-08 22:01:33
|
still isnt coming across ... -mike |
From: Mike F. <va...@ge...> - 2004-07-08 16:10:00
|
for some reason i havent received the last days worth of e-mail ... -mike |
From: Tamas F. <tf...@li...> - 2004-07-08 07:19:52
|
Mike Frysinger wrote: >On Wednesday 07 July 2004 10:21 am, Jerome Auza wrote: > > >>dump_records_to_html.c: In function `main': >>dump_records_to_html.c:204: error: invalid `asm': invalid operand output >>code make[1]: *** [dump_records_to_html.o] Error 1 >>make[1]: Leaving directory `/home/jauza/libstdf-0.2/examples' >> >> > >ok, i give up :) >i'm just going to include the bswap macro's that Tamas provided and rip out >the byteswap/bswap includes ... > > hehh :) Sorry for the bad bswap includes... :) But I dont known how come this 'asm' operand, because nor the bsd, nor the linux bswap macro dont use asm statement. If I have some time I will check this on my sun systems.... cheers, Tamas >looking at the macro's, the BSD ones are of the form: >bswap(x) x = (x & blah blah) >while the linux ones are of the form: >bswap(x) (x & blah blah) > >i assumed the macros were all of the 2nd form so i could see why that might >cause issues on some platforms ... > > |
From: Mike F. <va...@ge...> - 2004-07-07 22:28:59
|
On Wednesday 07 July 2004 10:21 am, Jerome Auza wrote: > dump_records_to_html.c: In function `main': > dump_records_to_html.c:204: error: invalid `asm': invalid operand output > code make[1]: *** [dump_records_to_html.o] Error 1 > make[1]: Leaving directory `/home/jauza/libstdf-0.2/examples' ok, i give up :) i'm just going to include the bswap macro's that Tamas provided and rip out the byteswap/bswap includes ... looking at the macro's, the BSD ones are of the form: bswap(x) x = (x & blah blah) while the linux ones are of the form: bswap(x) (x & blah blah) i assumed the macros were all of the 2nd form so i could see why that might cause issues on some platforms ... > And similar error on 'asm' in dtc.c. If I comment out this code in dtc.c, > libstdf compiles cleanly except for the the one in examples above. well, it'll work for files that were created on Sun (sparc) hosts and then are read on the Sun machines ... if you try to read a file in Solaris that was created on an Intel (x86) box, the results will be screwed -mike |
From: Jerome A. <jer...@bo...> - 2004-07-07 14:21:36
|
Hi Mike, It compiled almost perfectly on my Solaris box! I got this error in the examples: dump_records_to_html.c: In function `main': dump_records_to_html.c:204: error: invalid `asm': invalid operand output code make[1]: *** [dump_records_to_html.o] Error 1 make[1]: Leaving directory `/home/jauza/libstdf-0.2/examples' And similar error on 'asm' in dtc.c. If I comment out this code in dtc.c, libstdf compiles cleanly except for the the one in examples above. /* switch (len) { case 2: *((uint16_t*)in) = bswap_16(*((uint16_t*)in)); break; case 4: *((uint32_t*)in) = bswap_32(*((uint32_t*)in)); break; case 8: *((uint64_t*)in) = bswap_64(*((uint64_t*)in)); break; default: fprintf(stderr, "__byte_order_change(): byte len of %i h as no implementation\n", len); } */ Then running the examples that compiled worked okay! jerome |
From: Jerome A. <jer...@bo...> - 2004-07-07 13:15:49
|
Hi Mike, Thanks. This is application specific anyway so it can be whatever one would like. At least we know that is one of the things to watch out for the applications intended for machines like mine. jerome At 05:42 AM 7/7/2004, you wrote: >On Tuesday 06 July 2004 09:01 am, Jerome Auza wrote: > > printf() didn't like the NULL and dies when a NULL gets printed. > >ah, on modern glibc implementations, that case gets handeled 'properly' and >outputs "(null)" which is why i did it like that :) > >i'll change it like you suggested but to default to "(null)" since it's >'nicer' looking :) >-mike |
From: Mike F. <va...@ge...> - 2004-07-07 03:35:19
|
since i think i've hit all my requirements that i had set out, and all the bug reports/patches you guys sent me, ive gone ahead and released 0.2 here's the direct link for you: http://prdownloads.sourceforge.net/freestdf/libstdf-0.2.tar.bz2?download thanks :) -mike |
From: Mike F. <va...@ge...> - 2004-07-06 21:42:54
|
On Tuesday 06 July 2004 09:01 am, Jerome Auza wrote: > printf() didn't like the NULL and dies when a NULL gets printed. ah, on modern glibc implementations, that case gets handeled 'properly' and outputs "(null)" which is why i did it like that :) i'll change it like you suggested but to default to "(null)" since it's 'nicer' looking :) -mike |
From: Jerome A. <jer...@bo...> - 2004-07-06 13:01:59
|
Hi Mike, In the dump_records_to_ascii.c example, I avoided getting many segmentation errors I previously got by changing print_str() macro as below. from: #define print_str(n,s) print_fmt(n, "%s\n", (*s ? s+1 : NULL)) to: #define print_str(n,s) print_fmt(n, "%s\n", (*s ? s+1 : "")) printf() didn't like the NULL and dies when a NULL gets printed. jerome |
From: Jerome A. <jer...@bo...> - 2004-07-03 23:36:04
|
>> I also added a check in libstdf.c so that if pathname is "-", assume the >> STDF came from the input pipe. >> <snip> > >cool, i hadnt thought of this ... i've added this to cvs :) > >i guess another neat trick might be to detect if the file's are compressed by >either zip/gzip/bzip2 ... i know many places compress stdf files when storing >them ... Yeah they should be compressed. Another thing we can do later when the writer part of libstdf is coded: A program to check if PTR records repeat the entries for limits, test name, etc. If so, then rewrite the stdf so that these entries are only there for the first PTR of each parameter. I know that many stdf analysis software use only the first instance of these records anyway. This is a huge savings in filesize even without compression. >how about i try to finish up the STDFv3 stuff, debug a bit with the example >files from galaxysemi, then release 0.2 and you can play with that :) >-mike --- I'd appreciate that. :-) I'll still try hacking on autogen on the solaris machine. If I figure out something that works, I'll let you know. |
From: Mike F. <va...@ge...> - 2004-07-03 18:55:39
|
On Saturday 03 July 2004 09:55 am, Jerome Auza wrote: > As I was using a different solaris machine this time, I had to > copy again the following files before the compile works: > <snip> > I also added typedef uint64_t __uint64_t > in libstdf_systems.h inside the #if defined(SOLARIS) this should all be fixed in cvs > I also added a check in libstdf.c so that if pathname is "-", assume the > STDF came from the input pipe. > <snip> cool, i hadnt thought of this ... i've added this to cvs :) i guess another neat trick might be to detect if the file's are compressed by either zip/gzip/bzip2 ... i know many places compress stdf files when storing them ... > I still get the following error in dtc.c > <snip> again, this should be fixed in cvs > Then I get the ../libtool not found error. Maybe because I tricked the > autogen.sh that > the scripts got confused and didn't know how to compile libtool? I also > figured out that autogen.sh > is failing on the solaris machine because aclocal fails: how about i try to finish up the STDFv3 stuff, debug a bit with the example files from galaxysemi, then release 0.2 and you can play with that :) -mike |
From: Jerome A. <jer...@bo...> - 2004-07-03 13:53:10
|
Hi Mike, I got around the autogen.sh problem. I ran autogen under linux and then tried to compile under a solaris machine. close to compiling it cleanly. As I was using a different solaris machine this time, I had to copy again the following files before the compile works: from a linux_box:/usr/include: endian.h features.h byteswap.h bits/endian.h bits/byteswap.h gnu/stubs.h sys/cdefs.h I also added typedef uint64_t __uint64_t in libstdf_systems.h inside the #if defined(SOLARIS) #if defined(SOLARIS) typedef uint8_t __uint8_t; typedef uint16_t __uint16_t; typedef uint32_t __uint32_t; typedef uint64_t __uint64_t; typedef int8_t __int8_t; typedef int16_t __int16_t; typedef int32_t __int32_t; I also added a check in libstdf.c so that if pathname is "-", assume the STDF came from the input pipe. This feature is neat when you have compressed STDF files and you don't want to unzip first then zip again after reading it. With this, I can do gunzip -c file.stdf.gz | my_prog_with_libstdf. It would also be nice if we can check if the stdf file was compressed and use the gzip library to read the STDF file so that one does not have to use a pipe in calling the program. stdf_file* stdf_open_ex(char *pathname, int opts) { stdf_file *ret = (stdf_file*)malloc(sizeof(stdf_file)); ret->fd = open(pathname, O_RDONLY); if (ret->fd == -1) { free(ret); ret = NULL; }else if ( strcmp ("-",pathname) == 0 ) { ret->fd = 0; } else <snip-snip-snip> I still get the following error in dtc.c dtc.c: In function `__byte_order_change': dtc.c:32: warning: implicit declaration of function `bswap_64' dtc.c:32: error: parse error before ')' token make: *** [dtc.lo] Error 1 ... so I just commented out the part that uses bswap_64. Then I get the ../libtool not found error. Maybe because I tricked the autogen.sh that the scripts got confused and didn't know how to compile libtool? I also figured out that autogen.sh is failing on the solaris machine because aclocal fails: Can't locate object method "path" via package "Request" at /usr/local/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> chunk 111. For some reason, perl couldn't understand this in Request.pm: struct ( # The key of the cache files. 'id' => "\$", # True iff %MACRO contains all the macros we want to trace. 'valid' => "\$", # The include path. 'path' => '@', <--------- this gets interpreted as a method ala OOP. # The set of input files. 'input' => '@', # The set of macros currently traced. 'macro' => '%', ); Now I don't have a libstdf.a in /usr/local/lib (because libtool is not there at all) so I cannot run the example programs using the latest code. :-( Anyway, I hope the findings/suggestions I had above would help. jerome |
From: Mike F. <va...@ge...> - 2004-07-02 21:42:04
|
On Friday 02 July 2004 08:00 am, Tamas Foldi wrote: > dump_records_to_ascii.c v1.5 uses stdf3 related defines without a proper > #ifdef block oops, forgot that last nite :) i noticed a similar (but non-fatal) bug in the include _types file as well ... added to cvs, thanks :) -mike |
From: Mike F. <va...@ge...> - 2004-07-02 21:21:33
|
On Friday 02 July 2004 08:33 am, Tamas Foldi wrote: > It seems I wasnt too clear: in other projects in the most cases bswap.h > added as internal head feil (so no system wide bswap.h exists) > > But you can also put the bswap macros in !HAVE_BYTESWAP_H section > > #if defined(HAVE_BYTESWAP_H) > # include <byteswap.h> > #else > # define bswap_16/32/whatever > #endif could you sanitize a BSD header file so that it only includes the bswap_{16,32,64} macros for both big/little endian systems ? i realized i couldnt clean the ones from linux/glibc since they are technically GPL products ;) > currently bsd build is broken... if you think i can give you a shell for > my bsd box, but if you put these macros to else block is also fine for > me, and yeah, thanks for porting to non-linux platform:) i added those ifdef macros for including byteswap.h/bswap.h in cvs ... did you cvs up and try ? -mike |
From: Tamas F. <tf...@li...> - 2004-07-02 12:34:13
|
Hi, >>On BSD* like systems there is no endian.h (you should use >>machine/endian.h or sys/endian.h) and no byteswap.h (commonly bswap.h >>used as part of the implementation with the bwap_* macros). >> >> > >i dont have any BSD machines to test on ... i'm kind of a linux peep > > > It seems I wasnt too clear: in other projects in the most cases bswap.h added as internal head feil (so no system wide bswap.h exists) But you can also put the bswap macros in !HAVE_BYTESWAP_H section #if defined(HAVE_BYTESWAP_H) # include <byteswap.h> #else # define bswap_16/32/whatever #endif AFAIK, in most operating systems there is no system wide byteswap.h currently bsd build is broken... if you think i can give you a shell for my bsd box, but if you put these macros to else block is also fine for me, and yeah, thanks for porting to non-linux platform:) cheers, tamas |
From: Tamas F. <tf...@li...> - 2004-07-02 12:01:34
|
Hi, dump_records_to_ascii.c v1.5 uses stdf3 related defines without a proper #ifdef block Index: examples/dump_records_to_ascii.c =================================================================== RCS file: /cvsroot/freestdf/libstdf/examples/dump_records_to_ascii.c,v retrieving revision 1.5 diff -u -r1.5 dump_records_to_ascii.c --- examples/dump_records_to_ascii.c 2 Jul 2004 00:58:42 -0000 1.5 +++ examples/dump_records_to_ascii.c 2 Jul 2004 11:42:21 -0000 @@ -387,6 +387,7 @@ /*rec_eps *eps = (rec_eps*)rec;*/ break; } +#ifdef STDF_VER3 case REC_SHB: { rec_shb *shb = (rec_shb*)rec; print_int("HEAD_NUM", shb->HEAD_NUM); @@ -438,6 +439,7 @@ print_int("FUNC_CNT", scr->FUNC_CNT); break; } +#endif case REC_GDR: { /*rec_gdr *gdr = (rec_gdr*)rec;*/ print_UNK("GEN_DATA"); cheers, tamas |
From: Mike F. <va...@ge...> - 2004-07-01 23:07:09
|
On Thursday 01 July 2004 11:54 am, Jerome Auza wrote: > I got this error trying to work on the CVS copy. Unfortunately I couldn't > figure out what's wrong. ah, gotta love autotools crap ... i might ponder trying to support cmake if i get a day to go through the documentation on their site ... try this: env WANT_AUTOCONF=2.5 WANT_AUTOMAKE=1.5 ./autogen.sh if that doesnt work, see if AUTOMAKE set to 1.8 helps things -mike |
From: Mike F. <va...@ge...> - 2004-07-01 23:07:02
|
On Thursday 01 July 2004 09:19 am, Tamas Foldi wrote: > sorry for the lot emails ..:) np ... just means the project isnt going to total waste ... > I am using demofile.zip and lot2-3.zip from galaxy examinator homepage > (demofile.stdf, lot2.stdf, lot3.stdf). > Do you have these files? i didnt even know about these ... i'll download them shortly and test out with them though, thanks > I have to comment out a line in rec.c at line 613. The line is > free(sdr->SITE_NUM) and in my use cases this sdr->SITE_NUM is NULL. I > dont know if this problem is the same. right ... i'm wasnt 100% sure how the xDTC types worked and having no stdf files to test with, could really only guess ... i'll play with the aforementioned test files and see if i cant produce something usuable > Right now libstdf and the example apps runs properly both on win32 and > nix* boxes. nice > I am using static lib solution in win32 environment, but the a dll would > be better. Do you have any strategy or plan regarding the dll ? ive generated a script for producing a VS C++ 6.0 workspace ... it exports the same functions as the library on a *nix platform but i havent tested it myself ... check out the libstdf/win32/vc++/ dir in cvs now i need to ponder how to 'support' VB 'properly' since memory management and VB/DLLs is just one huge headache -mike |