[Chicken-hackers] [PATCH] dynamic trace buffer resizing
Proposed patch to allow user to resize trace buffer at runtime, not just through command line option. Thoughts? 0001-Make-trace-buffer-resizable-at-runtime-via-sys-resiz.patch Description: Binary data ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] dynamic trace buffer resizing
On Mon, Aug 12, 2013 at 12:21:39PM -0500, Jim Ursetto wrote: Proposed patch to allow user to resize trace buffer at runtime, not just through command line option. Thoughts? Looks useful. Could it perhaps be more useful to make the argument to C_resize_trace_buffer a regular size_t instead of a Scheme fixnum? That might make it slightly more usable from an embedded situation. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] dynamic trace buffer resizing
On Mon, Aug 12, 2013 at 09:10:16PM +0200, Peter Bex wrote: On Mon, Aug 12, 2013 at 12:21:39PM -0500, Jim Ursetto wrote: Proposed patch to allow user to resize trace buffer at runtime, not just through command line option. Thoughts? Looks useful. Could it perhaps be more useful to make the argument to C_resize_trace_buffer a regular size_t instead of a Scheme fixnum? That might make it slightly more usable from an embedded situation. Also, why is a maximum size necessary, and why is it so small? Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] dynamic trace buffer resizing
On Aug 12, 2013, at 2:11 PM, Peter Bex peter@xs4all.nl wrote: Looks useful. Could it perhaps be more useful to make the argument to C_resize_trace_buffer a regular size_t instead of a Scheme fixnum? That might make it slightly more usable from an embedded situation. Sure -- but C_trace_buffer_size is an int. That's why I used int ;) I could certainly fix that at the source, shall I? Also, why is a maximum size necessary, and why is it so small? It's not. But there's a minimum size, so I figured naturally there should be a maximum size, if only to eliminate accidentally or maliciously resizing the trace buffer to an arbitrary extent. There are also max caps on some other resources. Since it's a ring buffer, I suppose there are no *performance* problems with a trace buffer of large size, just potentially memory usage. The default is also arbitrary. I could either eliminate the limit or raise the default, your call. Actually, I just realized the arg isn't checked to be a fixnum. I'll change that when I incorporate any suggestions. Jim ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] dynamic trace buffer resizing
On Mon, Aug 12, 2013 at 03:10:59PM -0500, Jim Ursetto wrote: On Aug 12, 2013, at 2:11 PM, Peter Bex peter@xs4all.nl wrote: Looks useful. Could it perhaps be more useful to make the argument to C_resize_trace_buffer a regular size_t instead of a Scheme fixnum? That might make it slightly more usable from an embedded situation. Sure -- but C_trace_buffer_size is an int. That's why I used int ;) I could certainly fix that at the source, shall I? That would be great. Also, why is a maximum size necessary, and why is it so small? It's not. But there's a minimum size, so I figured naturally there should be a maximum size, if only to eliminate accidentally or maliciously resizing the trace buffer to an arbitrary extent. There are also max caps on some other resources. Since it's a ring buffer, I suppose there are no *performance* problems with a trace buffer of large size, just potentially memory usage. The default is also arbitrary. I could either eliminate the limit or raise the default, your call. The other limits annoy me equally ;) So I guess it's probably enough to have a minimum, or even rip that out as well (minimum of 0 = no history), but I'm afraid that'd be more difficult. Actually, I just realized the arg isn't checked to be a fixnum. I'll change that when I incorporate any suggestions. Ah, well spotted! Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [ANN]: Port Chicken to AIX
Greetings!
In an effort to use Chicken at my office, I've gotten Chicken to build
on AIX 6.1. I can run the interpreter, the compiler, and manage eggs
with chicken-{install,remove}. It did not take too many changes to
the code to make this happen.
I have more details about it on github.com, along with a list of eggs
I've been able to build.
https://github.com/fadein/chicken-core/pull/1
I hope it is not too late to fit this in to the 4.8.2 release. Please
let me know if there are any further changes I ought to make to this
patch to clean it up.
--
Erik Falor http://unnovative.net
Registered Linux User #445632 http://linuxcounter.net
signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
