From: Bruno H. <ha...@us...> - 2000-11-29 19:18:42
|
Update of /cvsroot/clisp/clisp/src In directory slayer.i.sourceforge.net:/tmp/cvs-serv13289 Modified Files: lispbibl.d time.d subr.d constsym.d ChangeLog Log Message: Some careful restructuring, after Sam complained. |
From: Sam S. <sd...@gn...> - 2000-11-29 21:12:38
|
> * In message <200...@sl...> > * On the subject of "[clisp cvs] 'clisp/src lispbibl.d,1.171,1.172 time.d,1.16,1.17 subr.d,1.60,1.61 constsym.d,1.90,1.91 ChangeLog,1.837,1.838'" > * Sent on Wed, 29 Nov 2000 11:18:42 -0800 > * Honorable Bruno Haible <ha...@us...> writes: > > Update of /cvsroot/clisp/clisp/src > In directory slayer.i.sourceforge.net:/tmp/cvs-serv13289 > > Modified Files: > lispbibl.d time.d subr.d constsym.d ChangeLog > Log Message: > Some careful restructuring, after Sam complained. on win32, `internal_time_to_I' returns the number of seconds since 1600-01-01, not 1900-01-01, as it should. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Your mousepad is incompatible with MS Windows - your HD will be reformatted. |
From: Bruno H. <ha...@il...> - 2000-11-29 22:36:04
|
Sam writes: > on win32, `internal_time_to_I' returns the number of seconds since > 1600-01-01, not 1900-01-01, as it should. internal_time_to_I only converts. Also note that internal_time_to_I is in the section about "Measuring time consumption". You are always expected to subtract two internal_time values (or two internal_time_to_I results). (In mathematical words that you understand: internal_time values are living in a projective space, not in an affine space. :-) ) Bruno |
From: Sam S. <sd...@gn...> - 2000-11-29 23:42:38
|
> * In message <148...@ho...> > * On the subject of "Re: internal_time_to_I" > * Sent on Wed, 29 Nov 2000 23:35:39 +0100 (CET) > * Honorable Bruno Haible <ha...@il...> writes: > > Sam writes: > > > on win32, `internal_time_to_I' returns the number of seconds since > > 1600-01-01, not 1900-01-01, as it should. > > internal_time_to_I only converts. Also note that internal_time_to_I is > in the section about "Measuring time consumption". You are always > expected to subtract two internal_time values (or two > internal_time_to_I results). okay, so this is an "internal real time". could you please add internal_time_to_universal_time? or, more precisely, a new type universal_time (== FILETIME on win32), and universal_time_to_I(). > (In mathematical words that you understand: internal_time values are > living in a projective space, not in an affine space. :-) ) you mean "in an affine space, not a vector space". :-) -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> When C++ is your hammer, everything looks like a thumb. |
From: Bruno H. <ha...@il...> - 2000-11-30 13:48:05
|
Sam writes: > could you please add internal_time_to_universal_time? > or, more precisely, a new type universal_time (== FILETIME on win32), > and universal_time_to_I(). What unit (resolution) shall it have? If it has 1 sec resolution, it is not FILETIME. If it has sub-second resolution, then 1. the universal_time_to_I() function would return bignums, which should be avoided, and 2. callers of the function would need to know the number of units per second. Same as 'internal-time-units-per-second'? > > (In mathematical words that you understand: internal_time values are > > living in a projective space, not in an affine space. :-) ) > > you mean "in an affine space, not a vector space". :-) Right :-) There were times when I was better at math than today. Bruno |
From: Sam S. <sd...@gn...> - 2000-11-30 15:17:47
|
> * In message <148...@ho...> > * On the subject of "Re: internal_time_to_I" > * Sent on Thu, 30 Nov 2000 14:47:35 +0100 (CET) > * Honorable Bruno Haible <ha...@il...> writes: > > Sam writes: > > > could you please add internal_time_to_universal_time? > > or, more precisely, a new type universal_time (== FILETIME on win32), > > and universal_time_to_I(). > > What unit (resolution) shall it have? If it has 1 sec resolution, it > is not FILETIME. If it has sub-second resolution, then 1. the > universal_time_to_I() function would return bignums, which should be > avoided, and 2. callers of the function would need to know the number > of units per second. Same as 'internal-time-units-per-second'? the precise definition of universal_time and universal_time_to_I can be platform-dependent. universal_time_to_I does not have to be 1-1. (and it should return a valid Lisp universal time). -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> In every non-trivial program there is at least one bug. |
From: Bruno H. <ha...@il...> - 2000-11-30 23:06:37
|
Sam writes: > > > could you please add internal_time_to_universal_time? > > > or, more precisely, a new type universal_time (== FILETIME on win32), > > > and universal_time_to_I(). > > the precise definition of universal_time and universal_time_to_I can be > platform-dependent. universal_time_to_I does not have to be 1-1. > (and it should return a valid Lisp universal time). It seems to me all you want is a function which converts a FILETIME to a universal-time Lisp integer without going through encode-universal-time (on platforms where possible). Such a function now exists. Bruno |