Re: [Chicken-hackers] CHICKEN in production

[Daniel Leslie]

I hope no one minds me jumping in to add my two cents...

On Wed, Oct 8, 2014 at 12:16 AM, Peter Bex <address@hidden> wrote:
> On Wed, Oct 08, 2014 at 01:31:30AM +0400, Oleg Kolosov wrote:
>> On Oct 7, 2014, at 10:04 PM, Peter Bex <address@hidden> wrote:
> It was discussed before on this list, and I shot it down due to the
> danger, however I think it may be possible to change the string
> representation to always include a \0 at the end, so that passing it
> to C will simply be a matter of passing a pointer.  The danger could
> be avoided by a taint bit: if the string is known to not contain \0,
> it can be passed directly.  Otherwise, it needs to be checked and
> marked if it's safe.  If it's unsafe, an exception can be thrown.

It seems strange that Chicken Scheme doesn't support blind use of
char[] strings; but I appreciate the choices made and the difficulty
in making changes now.  Perhaps this is something that can be examined
by whomever takes the plunge and brings core UTF8 support in?

> So much to do, so little manpower :(

It would help if the Development Roadmap were updated, and contained
more than bullet points regarding features. As an outsider it would be
useful to be able to look at a list of features in progress, stalled,
blocked et al; who is presently working on them; and which are open
for grabs.

> Yeah, that can certainly be a problem.  Debugging CHICKEN code can be a
> bit like reading tealeaves, sometimes.  I don't see an easy way to fix
> that, considering Cheney on the MTA is really an essential part of CHICKEN.
>
>> And useful info about passed arguments and such is left in the generated 
>> comments - you need to inspect the sources with the ‘list’ command to view 
>> it.
>
> That's a good thing, right?  The sources are available and can be kept
> using the -k switch.  If there are other comments that could be inserted
> which might be more helpful, we're open to suggestions.
>
>> We tried to improve this with the insertion of #line directives without much 
>> success - code generator is too complex, especially where FFI is involved. 
>> We are inserting logging statements everywhere. Unfortunately logging 
>> considerably uglifies the code and makes some functional programming idioms 
>> much harder to use (like map/fold/cut oneliners). Also various analysis 
>> tools like Valgrind and libc malloc checkers fall flat when Chicken is 
>> involved.
>
> I think Jerry mentioned he used Valgrind for debugging CHICKEN/C code,
> and malloc checkers should work just fine with CHICKEN: it doesn't mess
> with the C heap.

I've used a combination of -k, gdb and perf to a fair amount of
success. The hurdles remain that it unavoidably requires one to become
comfortable with wading through stacks of name-mangled code, and gain
some familiarity with the internal representation of Chicken objects.
Neither of those are particularly conducive to source-level debugging.

There are several packages for Emacs that make writing Chicken code
easier, but last I checked there's a fairly big gap in the debugging
department. Relatedly, I checked with Nick G, the author of the SLIME
egg, and he's no longer working on Chicken-related projects but is
happy to accept patches.

> What exactly is wrong with SIGINT handling?

Also curious. Chicken's POSIX compatibility is a strong point, to me.

> I'd like to note, though, that it's unfortunate that we're only now
> having this conversation about your previous project: I'm sure that if
> you'd asked earlier on the list, we could've helped you better to debug
> or work around problems.  Like for example the disable-interrupts and
> defstruct issues could possibly have been solved as you ran into them.
> One of the great things about CHICKEN is its community; I'd advise
> everyone to make good use of it!

Aye, y'all are a great bunch of folks. Chicken enjoys a fantastic
group of hackers, users and lurkers. No one should hesitate to reach
out if they have questions.

-Dan