Menu
▾
▴
gnuplot-beta
|
From: Tatsuro M. <tma...@ya...> - 2011-01-03 11:07:09
|
Hello
I have checked out the cvs source and tried to build it.
2011-01-02 Peter Juhasz <ju...@us...>
* src/internal.c (f_time) docs/gnuplot.doc:
Modified time() so that type of result depends on type of argument
gcc -shared-libgcc -DHAVE_CONFIG_H -I. -I.. -I../term -I../term -DBINDIR=\"/usr/local/bin\"
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.5\"
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.5/PostScript\"
-DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.5/js\"
-DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.5/lua\"
-DCONTACT=\"gnu...@li...\"
-DHELPFILE=\"/usr/local/share/gnuplot/4.5/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed
's,x,x,'`.exe\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\" -I/usr/local/include -D_REENTRANT
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O3
-fomit-frame-pointer -MT internal.o -MD -MP -MF .deps/internal.Tpo -c -o internal.o internal.c
internal.c: In function 'f_time':
internal.c:1452: error: storage size of 'tp' isn't known
make[3]: *** [internal.o] Error 1
On djgpp and MinGW, the builds were successful without errors.
HMMM. On the source 2011-01-01, the cygwin build was carried out without problem. So this error comes
from newly imported code.
f_time(union argument *arg)
{
struct value val, val2;
double time;
struct timeval tp; // <== line 1452
Is timeval a origin of the error
Any suggestions?
Regards
Tatsuro
Any suggestions ?
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: Peter J. <pet...@gm...> - 2011-01-03 14:51:28
|
On Mon, Jan 3, 2011 at 11:40 AM, Tatsuro MATSUOKA
<tma...@ya...> wrote:
> Hello
>
> I have checked out the cvs source and tried to build it.
>
> 2011-01-02 Peter Juhasz <ju...@us...>
>
> * src/internal.c (f_time) docs/gnuplot.doc:
> Modified time() so that type of result depends on type of argument
>
>
> gcc -shared-libgcc -DHAVE_CONFIG_H -I. -I.. -I../term -I../term -DBINDIR=\"/usr/local/bin\"
> -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.5\"
> -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.5/PostScript\"
> -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.5/js\"
> -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.5/lua\"
> -DCONTACT=\"gnu...@li...\"
> -DHELPFILE=\"/usr/local/share/gnuplot/4.5/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed
> 's,x,x,'`.exe\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\" -I/usr/local/include -D_REENTRANT
> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
> -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O3
> -fomit-frame-pointer -MT internal.o -MD -MP -MF .deps/internal.Tpo -c -o internal.o internal.c
> internal.c: In function 'f_time':
> internal.c:1452: error: storage size of 'tp' isn't known
> make[3]: *** [internal.o] Error 1
>
>
> On djgpp and MinGW, the builds were successful without errors.
>
> HMMM. On the source 2011-01-01, the cygwin build was carried out without problem. So this error comes
> from newly imported code.
>
> f_time(union argument *arg)
> {
> struct value val, val2;
> double time;
> struct timeval tp; // <== line 1452
>
> Is timeval a origin of the error
>
> Any suggestions?
>
> Regards
>
> Tatsuro
>
>
>
> Any suggestions ?
>
The breakage was caused by me: I carelessly used the gettimeofday()
function without realizing that it has to be included from sys/time.h.
Apparently, on GNU systems the compiler manages to find the correct
definition even without the missing #include statement - perhaps this
is why your MinGW and djgpp builds proceeded without error, and this
is why I noticed nothing. However, on other systems this is not so.
I've checked in a fix just now. Could you please test it? If it builds
successfully, could you test the following command?
print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
I apologize for the inconvenience.
Péter Juhász
|
|
From: Tatsuro M. <tma...@ya...> - 2011-01-03 19:44:07
|
Hello
Thank you for immediate response and treatment.
Build on the Cygwin with the cvs source dated 2011-01-03 was successful.
Fine!!
> I've checked in a fix just now. Could you please test it? If it builds
> successfully, could you test the following command?
>
> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
Cygwin
gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347398005 347398005.468875 2011/01/03 19:26:45.468875
MinGW
gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347398047 347398047.453125 2011/01/03 19:27:27.453125
DJGPP
gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347430489 347430489.76 2011/01/04 04:28:09.760000
Note that the result in DJGPP is different from those in Cygwin and MinGW.
Perhaps DJGPP uses JST (Japanese Standard Time, UTC+9) and Cygwin and MinGW use UTC.
I do not know which you would like to implement.
> I apologize for the inconvenience.
No problem. One of the purpose of my frequently build of the CVS source is to kill the bug as soon as
possible. Faster finding issue is better for debugging.
Regards
Tatsuro
--- Peter Juhasz wrote:
> On Mon, Jan 3, 2011 at 11:40 AM, Tatsuro MATSUOKA
> <tma...@ya...> wrote:
> > Hello
> >
> > I have checked out the cvs source and tried to build it.
> >
> > 2011-01-02 �Peter Juhasz �<ju...@us...>
> >
> > � � � �* src/internal.c (f_time) docs/gnuplot.doc:
> > � � � �Modified time() so that type of result depends on type of
argument
> >
> >
> > gcc -shared-libgcc -DHAVE_CONFIG_H -I. -I.. �-I../term -I../term
-DBINDIR=\"/usr/local/bin\"
> > -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.5\"
> > -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.5/PostScript\"
> > -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.5/js\"
> > -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.5/lua\"
> > -DCONTACT=\"gnu...@li...\"
> > -DHELPFILE=\"/usr/local/share/gnuplot/4.5/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 |
> sed
> > 's,x,x,'`.exe\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\" �-I/usr/local/include �
-D_REENTRANT
> > -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
> > -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include � �-O3
> > -fomit-frame-pointer -MT internal.o -MD -MP -MF .deps/internal.Tpo -c -o internal.o internal.c
> > internal.c: In function 'f_time':
> > internal.c:1452: error: storage size of 'tp' isn't known
> > make[3]: *** [internal.o] Error 1
> >
> >
> > On djgpp and MinGW, the builds were successful without errors.
> >
> > HMMM. On the source 2011-01-01, the cygwin build was carried out without problem. So this
> error comes
> > from newly imported code.
> >
> > f_time(union argument *arg)
> > {
> > � �struct value val, val2;
> > � �double time;
> > � �struct timeval tp; // <== line 1452
> >
> > Is timeval a origin of the error
> >
> > Any suggestions?
> >
> > Regards
> >
> > Tatsuro
> >
> >
> >
> > Any suggestions ?
> >
>
> The breakage was caused by me: I carelessly used the gettimeofday()
> function without realizing that it has to be included from sys/time.h.
> Apparently, on GNU systems the compiler manages to find the correct
> definition even without the missing #include statement - perhaps this
> is why your MinGW and djgpp builds proceeded without error, and this
> is why I noticed nothing. However, on other systems this is not so.
>
> I've checked in a fix just now. Could you please test it? If it builds
> successfully, could you test the following command?
>
> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
>
> I apologize for the inconvenience.
>
> P�er Juh�z
>
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|
|
From: Juhász P. <pet...@gm...> - 2011-01-03 20:59:20
|
On Tue, 2011-01-04 at 04:43 +0900, Tatsuro MATSUOKA wrote:
> Hello
>
> Thank you for immediate response and treatment.
>
> Build on the Cygwin with the cvs source dated 2011-01-03 was successful.
> Fine!!
>
That's good to hear!
> > I've checked in a fix just now. Could you please test it? If it builds
> > successfully, could you test the following command?
> >
> > print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
>
> Cygwin
> gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
> 347398005 347398005.468875 2011/01/03 19:26:45.468875
>
> MinGW
> gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
> 347398047 347398047.453125 2011/01/03 19:27:27.453125
>
> DJGPP
> gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
> 347430489 347430489.76 2011/01/04 04:28:09.760000
>
> Note that the result in DJGPP is different from those in Cygwin and MinGW.
> Perhaps DJGPP uses JST (Japanese Standard Time, UTC+9) and Cygwin and MinGW use UTC.
>
> I do not know which you would like to implement.
>
The fact that DJGPP returns a different answer is somewhat worrisome.
Gnuplot uses and assumes UTC more or less consistently. Therefore "time"
should return UTC as well. On a well-behaved platform where the system
clock runs in UTC and there is a sane mechanism in the OS to handle time
zones, gettimeofday() does return UTC, and so does gnuplot's "time".
Apparently, DJGPP is not such a platform, because the underlying system
call uses local time. Perhaps we should fall back to the good old time()
function on DJGPP, or figure out a different implementation if that's
bad as well.
Interestingly, on linux I get something like this:
gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347400672 347400672.289117 2011/01/03 20:11:12.289168
which means that the timer is precise enough to measure the time elapsed
between the consecutive function calls.
Péter Juhász
|
