Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Bruno Haible <haible@us...>  20001129 19:18:42

Update of /cvsroot/clisp/clisp/src In directory slayer.i.sourceforge.net:/tmp/cvsserv13289 Modified Files: lispbibl.d time.d subr.d constsym.d ChangeLog Log Message: Some careful restructuring, after Sam complained. 
From: Sam Steingold <sds@gn...>  20001129 21:12:38

> * In message <200011291918.LAA13442@...> > * 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 <haible@...> writes: > > Update of /cvsroot/clisp/clisp/src > In directory slayer.i.sourceforge.net:/tmp/cvsserv13289 > > 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 16000101, not 19000101, as it should.  Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.icharity.com/go/israel>; Your mousepad is incompatible with MS Windows  your HD will be reformatted. 
From: Bruno Haible <haible@il...>  20001129 22:36:04

Sam writes: > on win32, `internal_time_to_I' returns the number of seconds since > 16000101, not 19000101, 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 Steingold <sds@gn...>  20001129 23:42:38

> * In message <14885.33979.48092.170472@...> > * On the subject of "Re: internal_time_to_I" > * Sent on Wed, 29 Nov 2000 23:35:39 +0100 (CET) > * Honorable Bruno Haible <haible@...> writes: > > Sam writes: > > > on win32, `internal_time_to_I' returns the number of seconds since > > 16000101, not 19000101, 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.icharity.com/go/israel>; When C++ is your hammer, everything looks like a thumb. 
From: Bruno Haible <haible@il...>  20001130 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 subsecond 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 'internaltimeunitspersecond'? > > (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 Steingold <sds@gn...>  20001130 15:17:47

> * In message <14886.23159.419407.965793@...> > * On the subject of "Re: internal_time_to_I" > * Sent on Thu, 30 Nov 2000 14:47:35 +0100 (CET) > * Honorable Bruno Haible <haible@...> 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 subsecond 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 'internaltimeunitspersecond'? the precise definition of universal_time and universal_time_to_I can be platformdependent. universal_time_to_I does not have to be 11. (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.icharity.com/go/israel>; In every nontrivial program there is at least one bug. 
From: Bruno Haible <haible@il...>  20001130 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 > platformdependent. universal_time_to_I does not have to be 11. > (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 universaltime Lisp integer without going through encodeuniversaltime (on platforms where possible). Such a function now exists. Bruno 