Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2011-10-11 14:07:28
|
>> My plan is to release version 4.4.4 some time in the next month, consistent with the ~6 month release cycle that has held throughout the 4.2 and 4.4 release series. NEWS entries for 4.4.4 include * NEW boxxyerrors plot style now allows variable color * NEW splot with pm3d now allows variable rgb color * NEW "nonuniform matrix" indicates ascii data with explicit x, y * CHANGE columnhead(N) is a string-valued function, not a keyword * CHANGE Demarcate plots in svg output using <g id="Plot_#"><title>... * CHANGE xticlabels() works for binary data files as well as ascii * CHANGE "set key maxrows" now applies to 3D plots as well as 2D * CHANGE rewrite installation path rules for TeX files * FIX wxt terminal should now work on at least some flavors of OSX * FIX incorrect space allowed for outside left key box * FIX buffer overflow from enhanced text timefmt tic labels * FIX correction for offset in epochs when reading in time format "%s" * FIX discontinuity in defined palette limited by maxcolors * FIX initialization of svg pattern-fill definitions * FIX positioning of histogram bars when some data entries are missing * FIX emf terminal can handle UTF-8 encoding >> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over a year ago but did not seem to be fixed in 4.4.3 release in March. I don't use "other" OSes myself but I'm helping a college who has that misfortune. He is very impressed with gnuplot which I encouraged him to use and gave his a script for his data to get him started. However, I had to do a messy hack to get around the NaN=0 bug in the windoze build he got from SF. I don't have a cross-compilation set up for mwing so I can't build it here. Will this be fixed in next release? Best regards, Peter. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-11 15:53:27
|
On Tuesday, 11 October 2011, pl...@pi... wrote: > > I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over > a year ago but did not seem to be fixed in 4.4.3 release in March. The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5 Note that this fix only deals with initializing the NaN variable internally. It does not correct for any oddities in the C-language support library. I.e., if the library routines fscanf() and atod() cannot deal with the string "NaN" in an input file, that's a separate problem. I don't know whether or not that is an issue with MinGW. What is the symptom? If you start the program and say "print NaN", what does it show? Ethan > I don't use "other" OSes myself but I'm helping a college who has that > misfortune. He is very impressed with gnuplot which I encouraged him to > use and gave his a script for his data to get him started. However, I > had to do a messy hack to get around the NaN=0 bug in the windoze build > he got from SF. > > I don't have a cross-compilation set up for mwing so I can't build it here. > > Will this be fixed in next release? > > Best regards, Peter. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: <pl...@pi...> - 2011-10-11 16:20:00
|
On 10/11/11 17:53, sfeam (Ethan Merritt) wrote: > On Tuesday, 11 October 2011, pl...@pi... wrote: >> >> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over >> a year ago but did not seem to be fixed in 4.4.3 release in March. > > The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5 > Note that this fix only deals with initializing the NaN variable internally. > It does not correct for any oddities in the C-language support library. > I.e., if the library routines fscanf() and atod() cannot deal with the > string "NaN" in an input file, that's a separate problem. > I don't know whether or not that is an issue with MinGW. > > What is the symptom? > If you start the program and say "print NaN", what does it show? > > Ethan > Hi, yes that's exactly the problem as reported in that bug. print NaN; gives me zero . (apart from nothing using NaN behaving as expected) thx. > >> I don't use "other" OSes myself but I'm helping a college who has that >> misfortune. He is very impressed with gnuplot which I encouraged him to >> use and gave his a script for his data to get him started. However, I >> had to do a messy hack to get around the NaN=0 bug in the windoze build >> he got from SF. >> >> I don't have a cross-compilation set up for mwing so I can't build it here. >> >> Will this be fixed in next release? >> >> Best regards, Peter. >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> gnuplot-beta mailing list >> gnu...@li... >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta >> > > |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-11 16:40:37
|
On Tuesday, 11 October 2011, pl...@pi... wrote: > On 10/11/11 17:53, sfeam (Ethan Merritt) wrote: > > On Tuesday, 11 October 2011, pl...@pi... wrote: > >> > >> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over > >> a year ago but did not seem to be fixed in 4.4.3 release in March. > > > > The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5 > > Note that this fix only deals with initializing the NaN variable internally. > > It does not correct for any oddities in the C-language support library. > > I.e., if the library routines fscanf() and atod() cannot deal with the > > string "NaN" in an input file, that's a separate problem. > > I don't know whether or not that is an issue with MinGW. > > > > What is the symptom? > > If you start the program and say "print NaN", what does it show? > > > > Ethan > > > Hi, > > yes that's exactly the problem as reported in that bug. > > print NaN; > gives me zero . > (apart from nothing using NaN behaving as expected) Huh. Well, all I can say is that the fix was already in the source at the time 4.4.3 was released. The windows executables from Tatsuro Matsuoka's site do not suffer from this problem: http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ Ethan > > thx. > > > > > >> I don't use "other" OSes myself but I'm helping a college who has that > >> misfortune. He is very impressed with gnuplot which I encouraged him to > >> use and gave his a script for his data to get him started. However, I > >> had to do a messy hack to get around the NaN=0 bug in the windoze build > >> he got from SF. > >> > >> I don't have a cross-compilation set up for mwing so I can't build it here. > >> > >> Will this be fixed in next release? > >> > >> Best regards, Peter. > >> > >> ------------------------------------------------------------------------------ > >> All the data continuously generated in your IT infrastructure contains a > >> definitive record of customers, application performance, security > >> threats, fraudulent activity and more. Splunk takes this data and makes > >> sense of it. Business sense. IT sense. Common sense. > >> http://p.sf.net/sfu/splunk-d2d-oct > >> _______________________________________________ > >> gnuplot-beta mailing list > >> gnu...@li... > >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > >> > > > > > > |
|
From: <pl...@pi...> - 2011-10-11 22:20:47
|
On 10/11/11 18:40, sfeam (Ethan Merritt) wrote: > On Tuesday, 11 October 2011, pl...@pi... wrote: >> On 10/11/11 17:53, sfeam (Ethan Merritt) wrote: >>> On Tuesday, 11 October 2011, pl...@pi... wrote: >>>> >>>> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over >>>> a year ago but did not seem to be fixed in 4.4.3 release in March. >>> >>> The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5 >>> Note that this fix only deals with initializing the NaN variable internally. >>> It does not correct for any oddities in the C-language support library. >>> I.e., if the library routines fscanf() and atod() cannot deal with the >>> string "NaN" in an input file, that's a separate problem. >>> I don't know whether or not that is an issue with MinGW. >>> >>> What is the symptom? >>> If you start the program and say "print NaN", what does it show? >>> >>> Ethan >>> >> Hi, >> >> yes that's exactly the problem as reported in that bug. >> >> print NaN; >> gives me zero . >> (apart from nothing using NaN behaving as expected) > > Huh. Well, all I can say is that the fix was already in the source at > the time 4.4.3 was released. > > The windows executables from Tatsuro Matsuoka's site do not > suffer from this problem: > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ > > Ethan > Thanks , I'll get it installed from that source. For information the build giving problems was downloaded from SF within the last few days. If the SF build is not as stated, maybe it should be replaced by Tatsuro Matsuoka's build. BTW I see from the changelog , lots of work getting committed recently. Is 4.4.4 close to release or has it slipped back a bit? regards. Peter. >> >> thx. >> >> >>> >>>> I don't use "other" OSes myself but I'm helping a college who has that >>>> misfortune. He is very impressed with gnuplot which I encouraged him to >>>> use and gave his a script for his data to get him started. However, I >>>> had to do a messy hack to get around the NaN=0 bug in the windoze build >>>> he got from SF. >>>> >>>> I don't have a cross-compilation set up for mwing so I can't build it here. >>>> >>>> Will this be fixed in next release? >>>> >>>> Best regards, Peter. |
|
From: Tatsuro M. <tma...@ya...> - 2011-10-12 23:24:54
|
Hello I have confirmed that Print NaN gives 0.0 for gnuplot 4.4.3 binary. As written by Ethan, in the CVS source, the NaN issue is corrected here. 2010-10-10 Tatsuro Matsuoka <tma...@ya...> * src/stdfn.c (not_a_number): Bit-pattern definition of NaN for MINGW I also find the above log in the ChangeLog in gnuplot 4.4.3. I checked the source of 4.4.3. The modification is also attached to the 4.4.3 source. I do not find the reason why this modification is not effective for 4.4.3 binary. Regards Tatsuro --- On Wed, 2011/10/12, pl...@pi... wrote: > On 10/11/11 18:40, sfeam (Ethan Merritt) wrote: > > On Tuesday, 11 October 2011, pl...@pi... wrote: > >> On 10/11/11 17:53, sfeam (Ethan Merritt) wrote: > >>> On Tuesday, 11 October 2011, pl...@pi... wrote: > >>>> > >>>> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over > >>>> a year ago but did not seem to be fixed in 4.4.3 release in March. > >>> > >>> The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5 > >>> Note that this fix only deals with initializing the NaN variable internally. > >>> It does not correct for any oddities in the C-language support library. > >>> I.e., if the library routines fscanf() and atod() cannot deal with the > >>> string "NaN" in an input file, that's a separate problem. > >>> I don't know whether or not that is an issue with MinGW. > >>> > >>> What is the symptom? > >>> If you start the program and say "print NaN", what does it show? > >>> > >>> Ethan > >>> > >> Hi, > >> > >> yes that's exactly the problem as reported in that bug. > >> > >> print NaN; > >> gives me zero . > >> (apart from nothing using NaN behaving as expected) > > > > Huh. Well, all I can say is that the fix was already in the source at > > the time 4.4.3 was released. > > > > The windows executables from Tatsuro Matsuoka's site do not > > suffer from this problem: > > http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ > > > > Ethan > > > > Thanks , I'll get it installed from that source. > > For information the build giving problems was downloaded from SF within > the last few days. > > If the SF build is not as stated, maybe it should be replaced by Tatsuro > Matsuoka's build. > > BTW I see from the changelog , lots of work getting committed recently. > Is 4.4.4 close to release or has it slipped back a bit? > > regards. Peter. > > > >> > >> thx. > >> > >> > >>> > >>>> I don't use "other" OSes myself but I'm helping a college who has that > >>>> misfortune. He is very impressed with gnuplot which I encouraged him to > >>>> use and gave his a script for his data to get him started. However, I > >>>> had to do a messy hack to get around the NaN=0 bug in the windoze build > >>>> he got from SF. > >>>> > >>>> I don't have a cross-compilation set up for mwing so I can't build it here. > >>>> > >>>> Will this be fixed in next release? > >>>> > >>>> Best regards, Peter. > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Ethan A M. <sf...@us...> - 2011-10-13 00:04:08
|
Tatsuro MATSUOKA <tma...@ya...> wrote > > I have confirmed that > Print NaN gives 0.0 for gnuplot 4.4.3 binary. > > As written by Ethan, in the CVS source, the NaN issue is corrected here. > 2010-10-10 Tatsuro Matsuoka <tma...@ya...> > > * src/stdfn.c (not_a_number): Bit-pattern definition of NaN for MINGW > > I also find the above log in the ChangeLog in gnuplot 4.4.3. I checked the source of 4.4.3. > The modification is also attached to the 4.4.3 source. > I do not find the reason why this modification is not effective for 4.4.3 binary. Could it be because the test in stdfn.c is different? Version 4.4 #if defined(__MINGW__) Version 4.5 #if defined(__MINGW32__) Ethan |
|
From: Tatsuro M. <tma...@ya...> - 2011-10-13 06:29:48
|
Hello --- On Thu, 2011/10/13, Ethan A Merritt wrote: > Could it be because the test in stdfn.c is different? > Version 4.4 #if defined(__MINGW__) > Version 4.5 #if defined(__MINGW32__) You are right. Using #if defined(__MINGW32__) for gnuplot 4.4.3 source, give the correct results. gnuplot> print NaN NaN Please modify the branch-4-4-stable source. BTW, I have forgotten the way to check out branch-4-4-stable source. Please inform me. Regards Tatsuro |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-10-13 15:21:33
|
On Wednesday, 12 October 2011, Tatsuro MATSUOKA wrote: > Hello > > --- On Thu, 2011/10/13, Ethan A Merritt wrote: > > > Could it be because the test in stdfn.c is different? > > Version 4.4 #if defined(__MINGW__) > > Version 4.5 #if defined(__MINGW32__) > > You are right. > Using #if defined(__MINGW32__) for gnuplot 4.4.3 source, > give the correct results. > > gnuplot> print NaN > NaN > > Please modify the branch-4-4-stable source. > BTW, I have forgotten the way to check out branch-4-4-stable source. > Please inform me. cvs checkout -r branch-4-4-stable gnuplot Ethan |
|
From: Tatsuro M. <tma...@ya...> - 2011-10-13 22:12:20
|
Hello --- On Fri, 2011/10/14, sfeam (Ethan Merritt) wrote: > > BTW, I have forgotten the way to check out branch-4-4-stable source. > > Please inform me. > > cvs checkout -r branch-4-4-stable gnuplot I have confirmed that the src/stdfn.c in branch-4-4-stable branch is fixed. Thanks. Regards Tatsuro |
