Re: [Chicken-hackers] [PATCH] Add missing "C_" prefix to a snprintf calls in a tcp module

[Oleg Kolosov]

On 19 Oct 2014, at 19:32, Peter Bex <address@hidden> wrote:
> 
> On Sun, Oct 19, 2014 at 07:24:23PM +0400, Oleg Kolosov wrote:
>> 
>> Do you mean that I should sign-off by myself and ask somebody on IRC to 
>> review and sign-off too? I’ve looked on http://wiki.call-cc.org/contribute - 
>> it says “send them to the mailing list or fill a ticket”. Perhaps this 
>> section should be updated.
> 
> No, only core developers ("committers") are allowed to sign off on
> patches.  Sorry if that wasn't clear.  Sending it to the mailing list
> is perfectly fine.
> 
> I was just trying to explain that now only I signed off and pushed,
> but normally I would have to sign off, and resend the patch (possibly
> modified) to the list, so that a second core developer can sign off
> on it and push it.

Oh, I see, thanks for the explanation.

> 
>>> I'd hesitate to apply them, because we wouldn't be able to maintain
>>> them.  We'd need msvc support so we can verify things still work if
>>> we change things up.  Do you think you could write a Windows Makefile
>>> which uses the msvc compiler?
>> 
>> I do not think so. This task looks too formidable.
> 
> That's too bad :(
> 
> What in particular is tricky about it?  I'd expect the mingw
> Makefile to be reusable with a few changes to C_COMPILER and
> some flags.  But that's just my ignorance talking, probably.

I do not remember. It is not that simple. Various platforms have different 
conventions, Windows is not a POSIX system and not the first class citizen in 
the GNU toolchain. There are few things that CMake makes easier, we are already 
using it, and I’m more familiar with its warts - these were the reasons for 
choosing it in the first place.

> 
>>> I'd like to know what the other hackers think about this.
>> 
>> Well, I’ve tried hard to not break the existing system. It still builds with 
>> make just fine (but I’ve not tested on anything besides runtests). I intend 
>> to keep it this way as long as possible to ease merging.
>> 
>> There is another alternative. I maintain our company’s internal fork with 
>> CMake support and other experimental features and currently in the process 
>> of pushing it to my github repo, the management is fine with that so far.
>> 
>> In a few weeks we will have point release of our product, and after that, I 
>> plan to try to rebase it all on chicken-5. If all goes well - we will have a 
>> public repo with direct commit rights to experiment on as we please without 
>> spamming the mailing list with the discussions, and you will get some 
>> testing of the latest development branch on the real world application. Win 
>> - win.
> 
> This is pretty cool, but I'd caution against it if you're using a lot of
> eggs.  We intend to change a lot of things still, so you'd be creating a
> lot of extra effort for yourselves to port and re-port these eggs every
> time we make an incompatible change.  The same goes for your product, of
> course.
> 
> On the other hand, you would have the opportunity to develop in
> lock-step with core, which means you'll only need to make small iterative
> changes while core is evolving.

That’s what I was thinking - it’s easier while the history is not too large. 
I’ve made a repo for all our eggs too and working on build issues. I hope there 
will be some results worthy of submission.

If it will become too exhausting we will return to fallback stable branch.

-- 
Regards, Oleg
Art System