Am 14.07.2017 01:42, schrieb dah:
> I'm sure people were expecting you to stick to clock speedups only. > Mucking around with msgcat, adding smartref to dict, and whatever else > is not part of the implicit/explicit promise to work on the clock.
As already said, I rewrite back many of things (that were not wanted at
public C/Tcl level), e. g. msgcat is again original, smartref used at
the C-level from me only (although I could use pure hash-table, but why
creates duplicate?) and other things affected are easy going fixed (if
someone will say me I should do that).
> The speedup code should behave as a mirror image of the current clock > code...
Hmm, who said this? It's very complex to rewrite a part of tcl, without
touching of something else in core.
Especially if we speak about performance increase 10x-20x and more.
> The maintainer is responsible for reviewing and signing off on your > code, then they become responsible for it after giving it an OK.
I am familiar with tcl-core development (already over 20 years) and know
how it happens there. Please, don't noise.
> When they become aware you're adding in 'extras' it makes their job > harder as your code will need additional scrutiny to ensure you aren't > trying to slip anything in that isn't supposed to be there.
How it should be easier, if instead of extending of some available API
for the needed features, I'll duplicate some code (to extend it) or even
additionally write completely new module (where 90% is duplicate).
The strategy "don't touch my code" is very strange and IMHO wrong,
because:
* this tends to grow the codebase (and then more code should be
verified possibly still longer)
* more code - more errors;
* the API becomes fewer lucid
* not to mention the resulting performance of whole tcl-core (more
code wash out cpu-cache, memory etc.)
> The current clock maintainer is probably the toughest one out of the > whole bunch. You had better make sure everything is in order, every > single line has a justifiable existence and there is no better way, and > that it behaves exactly as the Tcl version of clock.
Please don't tell me, what I should better make...
Possibly I'm sole (apart from Kevin of course) which got a nerve at all
to develop round about clock-engine...
> Eventually if it is good stuff, they'll come around to adding it in, > but I wouldn't hold your breathe.
And I wouldn't tell, what I don't know...
> Tcl is old. Their maintainers are all part-timers AFAIK.
You think really I make it full-time?
I've also my family and my job (both have priority), several other
projects (open source and not) besides tcl, etc.
Just if someone has permanently no time, it should rely on other
colleagues. That is the way the open source is working...
> Projects as old as Tcl tend to slow in development as reliability and > stability is favored over all else.
I know that also.
Regards,
sebres.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core