From attila.lendvai at gmail.com Mon Nov 5 07:34:18 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 5 Nov 2007 08:34:18 +0100 Subject: [local-time-devel] one more patch with two new functions In-Reply-To: <470E624D.8000603@mail.ru> References: <470E546C.3030104@mail.ru> <470E624D.8000603@mail.ru> Message-ID: > Also, regarding the idea to use nanoseconds instead of microseconds.. I > think it has sense to do it as the maximal value of nanoseconds would be > 10^9 which is smaller than 2^30 and thus manipulations with it should > not cause bignum arithmetics. I am planning to make this change as well. this sounds good to me. > One more idea: when adjusted-local-time is included, perhaps it has > sense to move local-time-adjust-days's functionality into it. It would > be more convenient to have the single function to get a modified time no > matter what field has to be changed, won't it? yep, we can just drop local-time-adjust-days in favour of a function that can adjust any part of a local-time. > Ideally, if we have a possibility to read the current timestamp with the > precision up to nanoseconds we would benefit from it. However, the > situation regarding the acquiring high precision time stamps looks not > very good right now. I have made a little investigation and it looks > like only SBCL provides such functionality (and I am glad that my > home-grown logging system can benefit from it). But as far as I see > neither CLISP nor Lispworks support this feature. And I guess AllegroCL > does not support that as well. Perhaps it will have sense to create an > optional native library to add this feature at least for UNIX platforms > no matter which flavor of LISP is used. i think we should push the changes so that it works on sbcl and falls back to whatever precision is available on other lisps. then later users of other lisps can add their own version. > One more thing: I have tried to add (declaim (optimize speed)) at the > top of local-time.lisp. SBCL shows a large amount of warning that it is > unable to optimize the code as it is not clear what are types of the > arguments. I think it might have sense to make sure that fields of > local-time have strict limits on values and then coerce function > arguments to integers (possibly with ranges), whenever it is possible. i wouldn't do that. i usually add the optimize declares to specific functions only that are known to be hot-spots (first to the obvious ones and then to the ones that show up while profiling). then you won't get tons of compiler notes and things remain more debuggable if something goes wrong. i've pulled your patch for me, after some test period i'll push stuff to the official. -- attila ps: darcs doesn't let you send patches that depend (line collision) on other patches unless you send the depended on patches, too. if you want to keep patches independent, you need to be careful what to record in a patch. it's a good strategy to record separate patches that do specific functionalities and record "housekeeping"-like patches that change many places in the project, but does not alter functionality much. From attila.lendvai at gmail.com Sun Nov 11 17:36:43 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 11 Nov 2007 18:36:43 +0100 Subject: [local-time-devel] one more patch with two new functions In-Reply-To: <470E546C.3030104@mail.ru> References: <470E546C.3030104@mail.ru> Message-ID: > Here is another patch with two functions I find useful. The first one > returns number the of days in month and another one > (modified-local-time) returns the local-time object with a required > modification made. It is similar to adjusted-local-time. However, > adjusted-local-time shifts the date when the modified-local-time sets > the specified field to the required value. a few comments: - the names are not too intuitive, but as i can't come up with anything better i'd better shut up right here... :) - it would be good to have a way to tell these functions to sideffect the changes into the input in situations someone wants to avoid consing. - yep, the local-time-adjust-days functionality should be merged into the adjusted-local-time. - please use spaces instead of tabs unfortunately the test suite is not in a runnable state here, but still i've recorded some changes and TODOs and pushed them with your patches because waiting for me just hinders development. i'll do some more testing eventually... btw, i've started to refactor the test suite to have much more asserts and while doing that i'm moving it to use stefil. i hope it's ok with everyone. stefil makes it very easy to combine tests and run tests on various datasets, because tests are mere instrumented defun's. thanks for the paches, -- attila From dlowe at bitmuse.com Sun Nov 18 14:32:45 2007 From: dlowe at bitmuse.com (Daniel Lowe) Date: Sun, 18 Nov 2007 09:32:45 -0500 Subject: [local-time-devel] Local-time tests Message-ID: <47404D0D.2080000@bitmuse.com> I'm a little irritated that the local-time tests have gotten completely out of sync with the source. I only blame myself, since I haven't really been keeping up with the library at all for the past year. In the interests of sanity, however, I'd like to propose the following process: - All patches should be posted to local-time-devel for review and discussion - Patches which modify code should also include at least one test of the patch itself. The tests should fail before application of the patch, and succeed after the patch is applied. - No tests should fail after the patch is applied. Comments? : Daniel : From dlowe at bitmuse.com Sun Nov 18 14:42:19 2007 From: dlowe at bitmuse.com (Daniel Lowe) Date: Sun, 18 Nov 2007 09:42:19 -0500 Subject: [local-time-devel] More development process Message-ID: <47404F4B.7000003@bitmuse.com> Oh, yeah. One more thought: - Patches which change the API must include changes to the corresponding documention : Daniel : From dlowe at bitmuse.com Sun Nov 18 16:44:48 2007 From: dlowe at bitmuse.com (Daniel Lowe) Date: Sun, 18 Nov 2007 11:44:48 -0500 Subject: [local-time-devel] Local-time 0.9.2 RC1 RFC Message-ID: <47406C00.6040004@bitmuse.com> Immediately breaking my own proposed process, I've updated the documentation and the tests now succeed (though more tests should probably be written). I'd like to make another release of local-time sometime today or tomorrow with the current repository. Does that work for everyone interested? : Daniel : From attila.lendvai at gmail.com Sun Nov 18 20:52:20 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 18 Nov 2007 21:52:20 +0100 Subject: [local-time-devel] Local-time tests In-Reply-To: <47404D0D.2080000@bitmuse.com> References: <47404D0D.2080000@bitmuse.com> Message-ID: > I'm a little irritated that the local-time tests have gotten completely > out of sync with the source. I only blame myself, since I haven't > really been keeping up with the library at all for the past year. i should have also run the testsuite more often... unfortunately in a weak moment of mine i've started to port the testsuite to use stefil, but gave up for various reasons, one of which is that stefil is our lib and... so the suite was in a nonfunctional state for me lately. but i've reverted the changes and will make sure to run the suite more often. > In the interests of sanity, however, I'd like to propose the following > process: > > - All patches should be posted to local-time-devel for review and > discussion i'm using darcsweb and its rss feed to keep updated on what's happening in the repos i'm depending on: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=local-time-local-time;a=summary when your reader shows a patch (i use google.com/reader) you can quickly get a diff, too. i'll push my patches to my public branch and drop a mail to the list so you can review it and pull it if you agree with it. > - Patches which modify code should also include at least one test of the > patch itself. The tests should fail before application of the patch, > and succeed after the patch is applied. > > - No tests should fail after the patch is applied. > > Comments? sounds good! theoretically i'm already following most of these - except when practicality steps on my toes... :) happy hacking, -- attila From dlowe at bitmuse.com Mon Nov 19 20:34:50 2007 From: dlowe at bitmuse.com (Daniel Lowe) Date: Mon, 19 Nov 2007 15:34:50 -0500 Subject: [local-time-devel] [Patch] Removes valid-date-p from the local-time library Message-ID: <4741F36A.5090706@bitmuse.com> This patch removes the valid-date-p function from the library. The function is only used in one place internally, and depends on an arbitrary definition of what is considered 'valid'. It also conflicts with a function in tests.lisp, which has a stronger claim to validity. This will go into 0.9.2 if no one has any objections. : Daniel : -------------- next part -------------- A non-text attachment was scrubbed... Name: local-time-remove-valid-date-p.patch Type: text/x-patch Size: 483 bytes Desc: not available URL: From dlowe at bitmuse.com Mon Nov 19 20:37:51 2007 From: dlowe at bitmuse.com (Daniel Lowe) Date: Mon, 19 Nov 2007 15:37:51 -0500 Subject: [local-time-devel] [Patch] Enable :nsec keyword argument in local-time function Message-ID: <4741F41F.80607@bitmuse.com> This keyword wasn't being used except when the function was being passed a universal time, contrary to the documentation. This will be going into 0.9.2. : Daniel : -------------- next part -------------- A non-text attachment was scrubbed... Name: local-time-fix-local-time-func.patch Type: text/x-patch Size: 1320 bytes Desc: not available URL: From attila.lendvai at gmail.com Mon Nov 19 21:57:19 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 19 Nov 2007 22:57:19 +0100 Subject: [local-time-devel] [Patch] Removes valid-date-p from the local-time library In-Reply-To: <4741F36A.5090706@bitmuse.com> References: <4741F36A.5090706@bitmuse.com> Message-ID: > This patch removes the valid-date-p function from the library. The > function is only used in one place internally, and depends on an > arbitrary definition of what is considered 'valid'. It also conflicts > with a function in tests.lisp, which has a stronger claim to validity. the idea here was that it's easy to represent dates with local-time objects if we define dates to be local-time's in the UTC timezone with zero time part. that way all the time arithmetic works on them as expected as long as this contract is hold. i wasn't too happy about the name of the exported VALID-DATE-P but the functionality is needed by one of our lib so i pushed it at the end. but feel free to rename it or remove! i'll just copy it into our dependent lib in that case, so that's fine with me. -- attila From johnw at newartisans.com Sun Nov 25 00:16:52 2007 From: johnw at newartisans.com (John Wiegley) Date: Sat, 24 Nov 2007 20:16:52 -0400 Subject: [local-time-devel] Dependency on CL-FAD Message-ID: <8191BD9A-554F-44A3-A353-72AA74338965@newartisans.com> Hello, I was wondering what the rational was for including a dependency on CL-FAD in 0.9.2? CL-FAD doesn't build on OS X (:sb-executable does not get built by default; I haven't tried a custom build yet, but it certainly won't be there via MacPorts or similar). This inhibits my adoption of local- time, which I was just getting comfortable with. Could there be at least a feature to avoid the dependency that I could enable on platforms that don't support it? Thanks, John From attila.lendvai at gmail.com Sun Nov 25 18:13:01 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 25 Nov 2007 19:13:01 +0100 Subject: [local-time-devel] Dependency on CL-FAD In-Reply-To: <8191BD9A-554F-44A3-A353-72AA74338965@newartisans.com> References: <8191BD9A-554F-44A3-A353-72AA74338965@newartisans.com> Message-ID: > Hello, I was wondering what the rational was for including a > dependency on CL-FAD in 0.9.2? there's only one thing used from cl-fad: WALK-DIRECTORY, but it depends on a few other things in cl-fad: DIRECTORY-PATHNAME-P FILE-EXISTS-P LIST-DIRECTORY PATHNAME-AS-DIRECTORY the clean solution would be to fix cl-fad or sbcl, whichever is needed. the ugly solution is to have a duplicates.lisp and copy&paste the needed functionality, but this would be so much against code reuse that i almost deleted this paragraph... :) just my 0.02, -- attila