Re: [Chicken-users] posix-extras sleep
On Tues, 19 Feb 2013 15:13:30 -0600 Jim Ursetto wrote:
Hmm, I just realized scheduler.scm relies on nanosleep(3) on UNIX, so I guess
it is safe to use in posix-extras as well. I'll change posix-extras to use
nanosleep shortly.
After all the discussion and further study the merits of nanosleep are clearer,
and it nicely accommodates the fractional time specifier idea--it really is a
good match.
Because the idea was interesting I took the liberty to attempt a simple
implementation of a nanosleep-based scheme sleep function:
(define process-sleep (foreign-lambda* double ((double tm))
#PSLP
struct timespec req;
struct timespec rem;
time_t s = (time_t) trunc(tm);
int r;
req.tv_sec = s;
req.tv_nsec = (long) (10.0 * (tm - (double)s));
r = nanosleep (req, rem);
if (!r) {
C_return(0.0);
} else {
C_return((double) ((double)rem.tv_sec
(rem.tv_nsec / 10.0)));
}
PSLP
))
A benefit of nanosleep is that if it receives an interrupt during the sleep,
the leftover sleep time is preserved in the second parameter, and so if
necessary, the sleep can be resumed with that value. In the above function, if
the sleep completes, it returns 0.0, but any other value is the unslept
remainder.
Here's a little driver program to test it out:
(use posix)
(define (sig-int sig)
2)
(set-signal-handler! 2 sig-int)
(define (sleeper tm)
(let ((currms (current-milliseconds)))
(let sleep-lp ((r (process-sleep tm)))
(if (= r 0)
(print Total sleep interval: (/ (- (current-milliseconds)
currms) 1000)
seconds.)
(begin
(print Signal 2: r secs remain..resume sleep)
(sleep-lp (process-sleep r)))
(let ((sl (list-ref (argv) 1)))
(sleeper (string-number sl)))
I used this shell script to interrupt periodically and gave results following.
#!/bin/sh
sleeptm=${1:-40.0}
echo requested sleep time: $sleeptm secs.
proc-sleep $sleeptm
slpid=`pgrep proc-sleep`
# echo $slpid
chkpid=ps -o pid= -o comm= -p $slpid
#echo pid... $($chkpid)
intsec=$(echo $sleeptm / 8 | bc -s)
echo initial sleep interrupt: $intsec sec
sleep $intsec
chk_sleeper () {
local n=$1
intsec=$(($intsec $n))
while [ $n -gt 0 ] ; do
if [ -z $($chkpid) ] ; then
exit
else
sleep 1
n=$((n - 1))
fi
done
}
while : ; do
if [ -z $($chkpid) ] ; then
exit
fi
if [ $intsec -gt 1 ] ; then
printf After %-2d sec - $intsec
kill -2 $slpid
fi
chk_sleeper $(echo $sleeptm / 4 | bc -s)
done
jra % int-sleep.sh 12.147
requested sleep time: 12.147 secs.
initial sleep interrupt: 1 sec
After 4 sec - Signal 2: 8.068483725 secs remain..resume sleep
After 7 sec - Signal 2: 5.008279345 secs remain..resume sleep
After 10 sec - Signal 2: 1.947937168 secs remain..resume sleep
Total sleep interval: 12.147 seconds.
jra %
Anyway, I'm using /process-sleep/ in my project instead of usleep, et. al., and
it seems to be working consistently and reliably. Now if only Windows would
implement it too, wouldn't that be wonderful?
Thanks,
Jules Altfas.
(Hmm. Some formatting problem is showing up. Will get it straightened out...)___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] posix-extras sleep
On Feb 20, 2013, at 3:57, J Altfas p...@bmedctr.com wrote: On Tues, 19 Feb 2013 15:13:30 -0600 Jim Ursetto wrote: Hmm, I just realized scheduler.scm relies on nanosleep(3) on UNIX, so I guess it is safe to use in posix-extras as well. I'll change posix-extras to use nanosleep shortly. After all the discussion and further study the merits of nanosleep are clearer, and it nicely accommodates the fractional time specifier idea--it really is a good match. Because the idea was interesting I took the liberty to attempt a simple implementation of a nanosleep-based scheme sleep function: Indeed, yesterday I changed posix-extras' sleep to use nanosleep() in 0.1.5. The implementation is essentially the same as yours but it also uses Sleep() on Windows. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] New string manipulation module
I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Thanks, Nicholas Van Horn ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Nice work, contributions are greatly appreciated. :) Since you're asking for constructive feedback, two things come to mind: It's a matter of taste, but IMHO it's schemier that /descriptive-variable/ is preferable to /desc-var/, so in your case /s-foo/ could easily be /string-foo/. However, I would drop the prefix altogether, as Chicken supports renaming on import. So /string-foo/ would become /foo/ and any prefixing is left up to the user of your library. I'm not certain what you intended by 'official', but if you meant that you'd like to see it packaged with Chicken then perhaps you should consider switching the license to Chicken's license. Mind you, GPL3 eggs are happily accepted, but note that many folks won't touch them for various reasons. However, if this is a port of an elisp library then likely re-licensing is not an option. Anyhow, thanks for the hard work and the contribution! And welcome to Chicken-land, come join us on IRC if you get a chance. Thanks, -Dan On 2/20/2013 9:36 AM, Nicholas Van Horn wrote: I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Thanks, Nicholas Van Horn ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Hi Nicholas, On Wed, 20 Feb 2013 12:36:22 -0500 Nicholas Van Horn vanhorn...@gmail.com wrote: I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Very nice. Thanks for sharing. I really think you should make it available as an egg. Although s may not sound very appealing to users who already know the srfi-13 API, it can still be useful for newcomers that know s and want to get started on Scheme (or port some code for it) or even for those Scheme users that for some reason don't like the API provided by srfi-13. Some random comments: * procedures from the data-structures unit are usually faster than the similar ones ones from srfi-13 (some of them provide similar features). For example, I'd implement s-starts-with? using data-structures' substring-index[-ci] instead of srfi-13's string-prefix[-ci]?, or string-chomp for s-chop-suffix. * maybe drop the dependency on the regex egg and use the built-in unit irregex? * if you intend to publish your code as an egg, it would be nice to have the documentation in the Chicken Wiki format, so it can be indexed by chickadee (http://api.call-cc.org). Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
I think it sounds good as an official egg; although there's a lot of overlap with SRFI-13 it's not bad to have another API. The main thing I'd suggest if making it official is that, as a port of the s library, to name it something like s or s-strings instead of strings, since the latter sounds like it would be the de-facto strings library for chicken. By convention as a port of s.el I think s is the most appropriate name. But I'm not sure if anyone else would agree. (Just don't name it slib!) I also think it's ok to keep the explicit s- prefix on your procedures. Although Chicken does support module prefixing, having procedures like join, matches?, equals? and match in the first place is not very descriptive, and may conflict with commonly-used names. However, titlecase is immediately obvious. One option is to disambiguate the names, like string-join or join-strings, and string-match or match-string. Another is to keep the s- prefix, which is a natural grouping. Or you could require the user to prefix on import, but if that's always needed due to conflicts, why make them go through the extra step? Ultimately, since there are no official guidelines for naming, it's up to you and your users. Jim On Feb 20, 2013, at 11:36 AM, Nicholas Van Horn wrote: I'm new to Chicken (and scheme for that matter), but I'm eager to contribute. I've been working on several text processing projects for which I've ported an Emacs-lisp string manipulation library to Chicken. The strings module provides many convenient string manipulation procedures (including new procedures not ported from the original elisp library). Each procedure is documented with examples. Beyond their immediate convenience, (I think) they present the user with a consistent API for working with strings. I am eager to share this as an official egg, but being new to scheme I have likely violated common practices. I share the preliminary module here in the hopes that someone will find it useful. I welcome any feedback with respect to changes in implementation/behavior, as well as missing functionality that you would like to see added. The module is packaged to be distributed as an egg, but it is currently only available at: https://github.com/n3mo/strings Thanks, Nicholas Van Horn ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New string manipulation module
Hi, On Wed, 20 Feb 2013 14:46:20 -0600 Jim Ursetto zbignie...@gmail.com wrote: I think it sounds good as an official egg; although there's a lot of overlap with SRFI-13 it's not bad to have another API. The main thing I'd suggest if making it official is that, as a port of the s library, to name it something like s or s-strings instead of strings, since the latter sounds like it would be the de-facto strings library for chicken. By convention as a port of s.el I think s is the most appropriate name. But I'm not sure if anyone else would agree. (Just don't name it slib!) I agree. I also think it's ok to keep the explicit s- prefix on your procedures. Although Chicken does support module prefixing, having procedures like join, matches?, equals? and match in the first place is not very descriptive, and may conflict with commonly-used names. However, titlecase is immediately obvious. One option is to disambiguate the names, like string-join or join-strings, and string-match or match-string. Another is to keep the s- prefix, which is a natural grouping. Or you could require the user to prefix on import, but if that's always needed due to conflicts, why make them go through the extra step? add1 (except if there is an `exchange' procedure in the API). :-) Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
