Cobra Forums

Just to move things along

Postby kobi7 » Thu Jan 30, 2014 10:01 am
hi Charles,
I see some nice patches in the bugs database.

Why aren't they accepted into the master branch?
is it outdated with regard to the current code base?
They have some really useful features and fixes.

honestly wanting to know,
Thanks, kobi

see Custom query

If the issue is lack of time to test I would be willing to help.

I feel this question also entails the attitude towards community contributions.
in other words, the role of community, the feeling of being a part of it, the joint effort for mutual benefits.
When a project is shared with others, it shows an open heart and acceptance of others' opinions and ways of thinking
considering the ideas, work and wishes of others for the way forward, even though it's a labor of your own.
hard decisions can still be made, and should be made. there has to be a vision. But it's still important for a community to be heard and appreciated. The enthusiasm of a community and feeling your needs are met mean much, may determine if people come or go, and affects the success of a project. of course I'm sure this "lingering" had good reasons or the circumstances of reality.
just wanted to be honest and highlight the importance from this perspective.

Sorry for the delay. I've been doubled up on projects at work and had some other distractions.

The #1 reason that new features and refinements don't get added is that I usually have bugs that I'm in the middle of fixing. These are the highest priority.

Note that when I say "bug" I'm referring to things like:
* Cobra internal error / uncaught exception
* False compilation errors
* Incorrect treatment of command line options
* Incorrect behavior of Cobra programs at run-time
* Stack overflows

When I say "bug", I'm not referring to other issues like "flaws", "gaps", "missing features", "missing conveniences".

Regarding bugs:

- There is always a backlog of bugs to fix.
- Most bugs in Cobra do not get patches/contribs; I fix them.
- Bugs are a higher priority than most anything else.

The #2 reason for the patch backlog is that patches are rarely straightforward. They might introduce new bugs or be missing key test cases. The patch for optional keyword arguments (a feature I love btw) introduced two bugs, each of which delayed the last release by two weeks total and each of which was fixed by me in lieu of applying other patches for feature refinements and enhancements. So the effort to apply the patch wasn't to just check it in and move on.

Or a patch may do things in a way that I haven't yet decided upon. IIRC there is a multi-line string patch, but I haven't yet decided between the many potential variations on multi-line string syntax.

Languages are different than say, gui apps, in that once you have added a feature, people will create programs that subsequently require those features. It's a commitment. Those take more time to process. A contrasting example would be an image editing program. If you add an image filter that doesn't work out, you just take it out. No one is going to be blocked from opening a file after you do so. For a compiler, if you remove or change a feature, they will be blocked from compiling.

Further ramblings:

I don't even get to my own pet projects like the simplified `base` invocation and fleshing out mix-ins because there's always another bug to fix.

A lot of patches have, in fact, been applied. I count 163 (svn log | grep -i credit: | wc -l). I don't have a count of how many are outstanding, but that would be an interesting number too.

Getting back to bugs which are my #1 distraction, there are 17 fixes here:
http://cobra-language.com/trac/cobra/wi ... otes_0.9.6

Plus additional fixes not listed because of bugs introduced between releases.

If those bugs hadn't already existed, I'm sure I would have gotten to more patches and features. Also, if I hadn't fixed those bugs, Cobra wouldn't be very usable.

#3 reason. I'm part time on Cobra. I can't get to everything as fast as I would like.

#4, I have also prioritized the occasional refinement or fix that enables better IDE support. Ramon is doing the bulk of the work here, but I occasionally do something on the Cobra compiler side to facilitate it.

Re: outstanding bugs, I'm currently eyeballing:

* http://cobra-language.com/trac/cobra/ticket/356
* http://cobra-language.com/trac/cobra/ticket/231
* Cobra type information (dynamic and nilable reference types) doesn't pass the library boundary (I don't see the ticket for this at the moment, but I only glanced.)

My apologies if there are some straightforward bug-fixing patches. Let's keep the conversation going:

Are there bug fix patches that I have missed?

Are there particular patches you're interested in (besides all of them) that have a strong enough impact that they supersede fixes?

OK, in reverse order:
> Are there bug fix patches that I have missed?
All the ones marked as 'defect' are bug fixes - some trivial (and so old they are nearly fossilized) so they are low hanging fruit,
some not-so and really really bloody annoying
lets start with ticket:34 (bloody annoying and bloody stupid )
ticket:239 trivial
ticket:283 trivial
ticket:141 trivial
ticket:236 trivial
ticket:8 fossil ( pending for 6 years FGS!!)

ticket:152 - known obvious noticeable bug
- I dont know if the patch is a 100% fix but it at least addresses the failing test suite item

> Are there particular patches you're interested in (besides all of them) that have a strong enough impact that they supersede fixes?
(presumably here you mean enhancements vs defect fixes)
Number 1 here is:
typing empty literal collections - small but extremely convenient (and makes the cobra literal collection actually notionally useful)
ticket:230

Deficient type inference with method refs and lambdas: This area has been non-working forever - it needs something ( even if a small step)
done to start to address it ( Cobra does type inference so you dont have to explicitly type anything .... except where it doesn't so you do...)
ticket:39
and ticket:204
(however this area is likely to have flow on effects and unknown barbs and hooks (wrt lambdas and anon methods at least)

ticket:201 - pretty trivial occasionally required

Probably the most immediately desirable and useful is sorting out multiline literal strings
ticket:120 (this patch is 4 years old , the issue this is addressing is at least that old...)

ticket:281 is a constant niggle ( to me at least) and the current situation is unaddressable without this change

The others - well lets get the above sorted first....

Re the rest of you posting: ( Here it comes )

#1 Patches not applied cos fixing "bugs" (hi priority/visibility bugs)

Most/many of these dont show up (ever) in the defect/trac bug database - the first notice of these is a change record for a fix
so you are actually the only only that can fix them.
No debate about internal compiler errors but there could be some about some of the choices of what "bugs" you choose as highest priority
( as a for instance ticket:356 preconditions on streams - is this really the biggest baddest worst thing that needs addressing before all else???)

But OK - Everyone has the choice about how they spend their own time
however is it at all reasonable that a patch languishes uncommented/unexamined/unapplied for multiple months ( 3,6,12) much less multiple years??
What does that say as to the value you put on the effort made in providing patches??
especially when some of them are things you've indicated you want or that we should 'provide something for'
ticket:253
ticket:263
ticket:8
ticket:193

- There is always a backlog of bugs to fix.

and the fix for that is?
"Chuck must work harder"
and a backlog of patches it seems, Surely the answer isnt to just let them sit there slowly bitrotting

- Most bugs in Cobra do not get patches/contribs; I fix them.

Well there is the above point and if you define "bugs" as the ones you know about and fix I guess thats tautalogically true
OTOH many of them are ones you are the best person to work out a fix...
On the gripping hand there are a goodly number of patches marked on the tickets as "defects"
.. if they're not worth addressing (priority) then surely its worthwhile noting that up front rather than just ignoring the contrib.

- Bugs are a higher priority than most anything else.

and thats as it should be but that doesnt mean that anything else gets mostly ignored. and to repeat - there are bug fixes in the patches

#2 patches are rarely straightforward

some are (perhaps you mean enhancements??)

They might introduce new bugs or be missing key test cases

and they might not (introduce new bugs) - not applying/trying the patch definitely preserves a bug/deficiency.
Whats the philosophy here?
Cant take patches cos they might have bugs ( in spite of test suite) - lets not anyone do anything then ..
Has anyone ever done anything non-trivial that someone did not find bugs in ????
Also how do you expect a good answer to emerge - the first code is the best code is the only code - sometimes we need to experiment

If they are missing key test cases or otherwise deficient then shouldnt that be indicated on the ticket??
In many cases its the long (long long) deafening silence post patch upload that is the most dispiriting...

optional keyword arguments (a feature I love btw) introduced two bugs

so if that patch not applied, those 2 bugs not surface but also not the feature you love
since patch was applied the 2 bugs were found - halleluiah we're ahead - we have the feature AND the two bugs quashed and blocked
(checking tests so not reoccur)

The release delay argument is not really applicable is it - cobra isnt on a mandated release cycle - Its as and when ready
Hell if its that much an issue you could have backed out the feature and released without it

Once again whats the philosophy?
Do you not want patches/contributions??

Or a patch may do things in a way that I haven't yet decided upon

Well that might be something to put on a ticket or discussion up front but really - 4 years?????

Languages are different... commitment..

Only if you assume the only philosophy is one-shot right-first-time ....
The question is more how do you address changes(compatible or not) cos there will be changes
- keep everything - total backward compatibility or
- cycle fast, checkpoint, ....
So far cobra hasnt conformed fully to any of them....
Admittedly You might have a real problem if we had a massive user base but we're in a position so far that we can afford to try things to see what flies...

re ramblings

I don't even get to my own pet projects like the simplified `base` invocation and fleshing out mix-ins because there's always another bug to fix.

I see this as a problem of your own making - expose (all) the bug (reports) so someone else can have a shot at fixing

Yes a lot of patches have been applied - But then again thats what they are there for - thats the EXPECTED result FCS.
(and thats 165 fixes/changes you didnt have to do ( well apart from setting yourself up as gatekeeper/filter/SourceCodeApplicator/bottleneck - once again a problem of your own making)

unfortunately its the ones that havent been applied that are apparent
("What have you done for us lately punk" )
That and the issue that many of them are really really old...

I don't have a count of how many are outstanding, but that would be an interesting number too.

( wheres a wince emoticon when you need one?)

Yes, wouldnt it....
So, why dont you know how many are outstanding?
Did you not look at the custom query given at the top of this posting?
Do you not track the patches at all??
( this is the very mad option)

( Just FYI Theres about 35 unapplied which is about 35^h^h25 more than is reasonable, once there were < 10 but the number creeps up as they are posted and not addressed)

...17 fixes in the last release.... Also, if I hadn't fixed those bugs,....

maybe not

#3 Part time on cobra
as are we all...

#4 Prioritise refinement or fix (for IDE)
fair enough

This reply has got really long so I'll stop now but
I'll ask you a question I asked way back when this issue came up before
You have one or two people providing patches now and with the system, constraints, preferences you have now you cant keep up
either with the patches supplied, bugs you think must be fixed immediately or your own pet projects/areas...
How is that sustainable or scalable?
What are you going to do if the number of people providing patches doubles ( and doubles again) ?

I think hops makes a lot of valid points. This discussion could go in many different directions, but I'd like to see something positive come from it.

It sounds like bug fixes should be a priority and hops has taken the time to identify some low hanging fruit. I'm going to excavate some of these fossils, do some testing, and update the status on the tickets.

Okay and to one of Chuck's points...

Charles wrote:The #2 reason for the patch backlog is that patches are rarely straightforward

I'm really feeling this pain right now. One issue we have now is that a lot of these patches are not easy to apply to the current codebase.

I was all like "I'll do it. How hard can it be? " I've spent two hours on ticket #141 and I still can't get the test to pass. And it's not because the patch has a bug or the test case is not complete, it's because I can't get the test runner to pick up the correct version of 'cobra.exe'. Blargh!

Hops, any chance you've been secretly maintaining different branches over the years that include all these patches already and can easily be merged into the trunk?

pick up the correct version of 'cobra.exe'

.
Perhaps this will help:
The way I addressed this was to stop/not install cobra.exe in a 'standard' place (accessed via PATH) - no cobra stdlib in GAC
Instead I have several source trees with pure and patched sources (compiled) and a set of aliases for specifying a particular .exe from one of those trees
( cobc0 - for my work tree, cobc1 for an untouched (from cvs) source tree, cobcp for an allpatches tree)
that way I can specify a particular run directly with no chance of a fallout to something indeterminate.....

maintaining different branches over the years that include all these patches already and can easily be merged into the trunk?

Unfortunately not as such
I have copies of some of the patch files and a couple of patched trees
one with only the important/most useful ( in my mind at least) unapplied patches in it,
another with all the unapplied patches
- I keep these to make sure that any new changes dont cause test regressions against those changes

Unfortunately they are currently not 100% synced to the current VCS code base
- I've been a bit lazy about keeping them up to date recently - probably just needs a sync and work though any outages
neither are much use for looking at a single patch (sorry)

More recently I've been trying to work against a shadowed mercurial VCS repository- I do changes against a branch till working then merge them back into the main mercurial trunk, diff that against the SVN tree (chucks canonical code tree) and send in a patch for that ( then back out the mercurial trunk back to the SVN version)
- this way changes stay in a mercurial branch till applied in the baseline svn codebase....
Periodically I resync the svn and hg trees together
Unfortunately I've only started doing this recently (and sometimes I ... dont) so its also not much use for a single old change/patch..

I've been quite surprised - the patch files hold together quite well when applied against later trees - slight issues with library changes to the old library directory name structure but think most of the old ones doing that have been washed into the baseline source now.....

whow,
I'm sorry. I REALLY didn't meant to open up a nest of hornets.
I am aware that it's all a part-time project, and Charles has his own personal life too. I really appreciate your work and dedication over all those years.
I understand the anger that was sounded from a veteran member and main contributor.
However I feel we shouldn't blame others.
I know I used to have issues with holding control, and possibly many in this profession have.
hell, a main feature in the language is to know better what happens with the code: contracts, tests and all.
(for me it was not that i didn't want to, but more like I didn't know how to let go, like a constant worrying and wanting to verify. in retrospect it was just lack of trust, or trusting only myself. I'm glad it's not there anymore)
of course this may not be the case here.

To have a good outcome of this conversation, as nerdzero suggested,
would it be plausible to make a change in the process or way things are done? making things more independent/decentralized?
taking a risk, relaxing the guard on incoming code (or assigning another person), allow to up the priority for noticeable features that make coding more fun and elegant? it might be a mine-field, or it might not... maybe it's worth a try?
Some people have a real vested interest in the Cobra language, and perhaps they are willing to give of their time for this extra job.
just my 2 cents...
Best regards to everyone, Kobi