8.7a1 Feature Target List

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

8.7a1 Feature Target List

Donal K. Fellows-2
Hi all

I've been thinking a bit about 8.7 schedules in the light of talking to
people at EuroTcl, and I think we ought to have a goal of getting the
first alpha out this year. (More would be OK too.) But in order to make
8.7a1 worth releasing, we really ought to have some key features to make
it a bit awesome. So what could they possibly be?

Well, since we're talking a first alpha here, my pick would be anything
where it might need significant effort to burn the feature in, or where
we might want to build other features on top of it. That said, I also
want to keep the following lists short: these are the ones I think we
should help/twist-arms over, not the definitive lists of all that should
go in. (IOW, I'm not deliberately ignoring your pet feature; just trying
to take a higher-level strategic-ish view.)

Big Ticket Items for Tcl:

   1: Minimal support for Unicode beyond the BMP.

      I define minimal support to mean that we can take non-BMP
      characters in some external encoding (e.g., standard UTF-8),
      convert it into a form that we can *pass around* with our existing
      string handling code, and then convert back to the correct
      characters in, say, UTF-8 on the way out of Tcl. So maybe with
      surrogate pairs. The key point is that I'm not requiring [string]
      to do much right with them (let alone do anything like
      normalisation); the minimal support is effectively just
      pass-through. That Is Enough.

      I do not wish to change the size of Tcl_UniChar in 8.7. That would
      cause lots of pain.

   2: Zip VFS.

      This is more of a leading-to- thing, as it will help us improve
      how we do distributions of Tcl applications (and possibly Tcl's
      own support files too). I'd be happy with 8.7a1 only supporting
      read-only access; that's enough to be useful.

      Also, past experience with the virtual FS layer and its
      equivalents for channels suggests it will take plenty of work to
      get it truly robust. Perhaps this work has already been done (on
      the several related branches), but past experience suggests the
      extra time will be used well.

   3: Named parameters for procedure-like things.

      Get it sorted, everyone! But remember to only make people pay the
      price of the complex parsing if they volunteer to do so. Alas,
      this means that people won't get it automatically, but then again
      the users of the code wouldn't get that anyway (they'll have to
      change their code to call a procedure if it goes from positional
      to named parameters).

      I could live with seeing this one slip to a later alpha.

Big Ticket Items for Tk:

   1: Contrib package system for Tk to follow pattern of Tcl 8.6.

      Because this enables...

   2: Tkpath as contrib package.

      We need a better set of drawing primitives, especially on Linux
      and Windows. This package is pretty awesome (according to much
      user feedback at EuroTcl) and builds on all platforms that we
      actually care about supporting Tk on, so we should strongly
      encourage people to rely on it.

      Yes, there are probably other packages that ought to be in there
      too. I'm refusing to enumerate them here! (But an HTML renderer
      would be darned useful.)

   3: The updated text widget.

      This would be dead nice, and has had a lot of effort put into it
      and we REALLY want to encourage that, but currently it sounds like
      it has weird stability problems (failing with just one compiler on
      one platform? Yikes!) Help for the author with sorting this out
      would be awesome.

Of the above picks, I'd call Tcl#1, Tk#2 and Tk#3 the “political” picks.
Tcl#3 is somewhat that way too, I guess, but provided it is opt-in, we
don't actually need to wait the first alpha for it. Also, I've tried to
pick things where the code should already be there; undeveloped stuff
really doesn't hit my radar unless it is a bee in my own bonnet.

Comments? Missing things? Remember, I'm thinking in terms of GET IT
SHIPPING THIS YEAR, so ruthlessness is also important.

(I've also got interesting ideas for TclOO, the http package, string
metric functions, getting [lsort -dictionary] comparison algorithm more
widely exposed and so on, but none of those are things to make an early
alpha wait for. :-) And there's also the Tclquadcode work, but there I'm
hoping we'll get that to a first alpha this year too...)

Donal.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

donal_k_fellows.vcf (241 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Brad Lanam-2
  3: The updated text widget.

     This would be dead nice, and has had a lot of effort put into it
     and we REALLY want to encourage that, but currently it sounds like
     it has weird stability problems (failing with just one compiler on
     one platform? Yikes!) Help for the author with sorting this out
     would be awesome.

That particular weird bug (right justified text with tabs on (some) Linux displaying weird characters, extant in 8.6.6) probably won't get fixed this time around and is not a stopper.   Hard to duplicate.

At this time, tablelist's dirViewer demo is not working with the revised text widget. 
My opinion, my point of view (I am only helping with testing), I don't think the revised text widget is quite ready.  Not sure that it will make the deadline.
 
2: Tkpath as contrib package.

The following is a little off-topic as it is more post-8.7.

I believe that a list should be started of contrib packages that should be included
with the distribution (e.g. TLS).    Not necessarily for 8.7 but soon.
(Isn't it the case that when people say they want something in the "core", often a loadable contrib module included in the distribution will do just fine?)

Also for the other contrib packages that are wanted but are not included with the distribution, a repository should be built with packages that can be installed (something like pip/easy_install in python) easily.  As a starting list, include every tcl package that can be installed via yum/apt-get/pacman on Linux (the popularity contest statistics can be used to see which ones are really used).
 


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Peter da Silva-2
In reply to this post by Donal K. Fellows-2
On 7/12/17, 4:08 PM, "Donal K. Fellows" <[hidden email]> wrote:
     3: Named parameters for procedure-like things.
   
          Get it sorted, everyone! But remember to only make people pay the
          price of the complex parsing if they volunteer to do so. Alas,
          this means that people won't get it automatically, but then again
          the users of the code wouldn't get that anyway (they'll have to
          change their code to call a procedure if it goes from positional
          to named parameters).
   
          I could live with seeing this one slip to a later alpha.

What’s currently in the TIP is, if not exactly what you’re asking for, very close.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

tcl-core mailing list
How about the new notifier for U*x and the clock speed-ups? Or is that already targeted for 8.6.7 ?

/Ashok

-----Original Message-----
From: Peter da Silva [mailto:[hidden email]]
Sent: Thursday, July 13, 2017 6:53 PM
To: Donal K. Fellows <[hidden email]>; Tcl Core List <[hidden email]>
Subject: Re: [TCLCORE] 8.7a1 Feature Target List

On 7/12/17, 4:08 PM, "Donal K. Fellows" <[hidden email]> wrote:
     3: Named parameters for procedure-like things.
   
          Get it sorted, everyone! But remember to only make people pay the
          price of the complex parsing if they volunteer to do so. Alas,
          this means that people won't get it automatically, but then again
          the users of the code wouldn't get that anyway (they'll have to
          change their code to call a procedure if it goes from positional
          to named parameters).
   
          I could live with seeing this one slip to a later alpha.

What’s currently in the TIP is, if not exactly what you’re asking for, very close.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Donald G Porter-2
On 07/13/2017 09:27 AM, Ashok P. Nadkarni via Tcl-Core wrote:
> How about the new notifier for U*x and the clock speed-ups? Or is that already targeted for 8.6.7 ?

TIP 458 -- the new notifier -- is already in the trunk (which calls
itself 8.7a0) and will be in the first 8.7a release.

The clock speedups are in need of substantial review, and they are
struggling to find enough time among a knowledgeable set of reviewers.
The patch came in touching far more pieces of Tcl and associated
packages in far more radical ways than I think anyone was expecting.

--
| Don Porter            Applied and Computational Mathematics Division |
| [hidden email]             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

tcl-core mailing list

Am 13.07.2017 15:38, schrieb Donald G Porter:

The clock speedups are in need of substantial review, and they are
struggling to find enough time among a knowledgeable set of reviewers.
Well, it was already thoroughly reviewed from some people (e. g. from Jan), and I've already
eliminates all bothering things (that I got listen).
IMHO, all the people, that cannot "find enough time" but tell us that the patch is dangerous 
because ... (I did not hear which is why), could either find the time or just accept it as is. IMHO.
The patch came in touching far more pieces of Tcl and associated
packages in far more radical ways than I think anyone was expecting.
I would really like to know more about a "radical ways"...
BTW this branch was created as speedup bounty, and if developer optimizes C-api of clock-engine, but he notes hereafter that the rest of tcl has attracted handbrake
(msgcat, ensembles, etc), and the developer is able to fix it by the way, he just does it.
Why not?

As already suggested, I am in favour to extract my new clock-engine into separates
tcl binary module, that just overwrites clock-ensemble on demand. 
But flightaware doesn't want it. Or...
 
@Peter, @Karl My offer still stands... Let us just rewrite it as module.
 
Unfortunately, this is a very thankless employment to participate in bounties, where tcl-core touched. 
I really regret to have done this. Just because I've many other projects, where I can better and more 
productive spend my time.
And it looks like I've not learned anything, because I do it again and again (see for example my 
last event-perf-branch with TIP-302 implementation).

Regards,
Sergey

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

akupries
In reply to this post by Donald G Porter-2

> On 07/13/2017 09:27 AM, Ashok P. Nadkarni via Tcl-Core wrote:
> > How about the new notifier for U*x and the clock speed-ups? Or is that already targeted for 8.6.7 ?
>
> TIP 458 -- the new notifier -- is already in the trunk (which calls
> itself 8.7a0) and will be in the first 8.7a release.

Very nice.

Note, the TIP itself needs an update, it is still marked as pending.

> The clock speedups are in need of substantial review, and they are
> struggling to find enough time among a knowledgeable set of
> reviewers.  The patch came in touching far more pieces of Tcl and
> associated packages in far more radical ways than I think anyone was
> expecting.

--
See you,
        Andreas Kupries <[hidden email]>
                        <http://core.tcl.tk/akupries/>
        Developer @ SUSE (MicroFocus Canada LLC)
                  <[hidden email]>

Tcl'2017, Oct 16-20, Houston, TX, USA. http://www.tcl.tk/community/tcl2017/
EuroTcl 2017, Jul 8-9, Berlin/DE, http://www.eurotcl.tcl3d.org/
-------------------------------------------------------------------------------





------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Donald G Porter-2
In reply to this post by Donal K. Fellows-2
On 07/12/2017 05:08 PM, Donal K. Fellows wrote:
> I've been thinking a bit about 8.7 schedules in the light of talking to
> people at EuroTcl, and I think we ought to have a goal of getting the
> first alpha out this year. (More would be OK too.) But in order to make
> 8.7a1 worth releasing, we really ought to have some key features to make
> it a bit awesome. So what could they possibly be?

FWIW, my plan has been to get 8.6.7 out the door first (and that's
taking far too long as I struggle to get Itcl 4.1 release-worthy).
Then I would immediately release 8.7a0 with the feature(s) it already
has -- notably the new notifier.

I generally support your call for more features, more quickly, and
I agree that the ones most likely to need some trial by fire would
be better to get in sooner.  But I don't have any intent to make
a first alpha release wait for anything.  Whatever's in the trunk
goes out when the time comes.

>    1: Minimal support for Unicode beyond the BMP.

Months ago we had TIP 389 very nearly ready.  Just a few bugs
in the handling of the Tcl_UniChar array representation needed
fixing since this becomes a variable-length instead of fixed-length
encoding in the revised scheme.  Is there any major objection to
seeing that through as the best available path here?

>    2: Zip VFS.

This is a very welcome idea.  We've taken a few stabs at it
and every time it grows out of control.  ("Oh, if you're going
to do that, then you'll need to fix TEA.... and then you should
really invent a whole new build system for starkit making... and then...").

> Big Ticket Items for Tk:
>
>    1: Contrib package system for Tk to follow pattern of Tcl 8.6.

I understand you seek to benefit from bundling lots of
good functionality in existing Tk extension packages, but
someone has to report the downside to this.

If we didn't bundle other packages, Tcl 8.6.7 would have been out
months ago.

Bundling is an enormous burden on release-making.  Very nearly
deal-breaking.  Juggling seven balls really is harder than two.

If every bundled package could be like sqlite3, there would be no
issue.  Vigorous owner making high quality releases on his own
calendar. Just grab and go.

Not every package is like that.  Some are unhousebroken puppies
left by the side of the road.

Proceed with caution and expect me to have extreme skepticism.

I'll also mention that my idealized vision has not been to have
Tk grow a tk/pkgs directory/.  It has been to TEA-tame Tk itself
so that it and its extensions drop into the tcl/pkgs directory.

--
| Don Porter            Applied and Computational Mathematics Division |
| [hidden email]             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bundling package source code distributions...

Donald G Porter-2
On 07/13/2017 03:35 PM, Donald G Porter wrote:
> Bundling is an enormous burden on release-making.  Very nearly
> deal-breaking.  Juggling seven balls really is harder than two.

A bit more on this.  Bundling makes things much worse for me.  But that
might still be worthwhile if we had strong evidence it was really making
things much better for many many other people.

That evidence doesn't reach me.  If people love the bundling practice,
they don't tell me so.  I only hear from the folks who need to undo it
so they can adapt to their own established packaging systems.

--
| Don Porter            Applied and Computational Mathematics Division |
| [hidden email]             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bundling package source code distributions...

Harald Oehlmann
Am 13.07.2017 um 21:43 schrieb Donald G Porter:
> That evidence doesn't reach me.  If people love the bundling practice,
> they don't tell me so.  I only hear from the folks who need to undo it
> so they can adapt to their own established packaging systems.

Just to note that I love bundeling, as the required work is done (which
is your issue). So, the bundled packages in tcl are just great.

Thank you for careing !

-Harald

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bundling package source code distributions...

Peter da Silva-2
Me too, having the “penumbral” functionality always there is just great.

On 7/13/17, 3:29 PM, "Harald Oehlmann" <[hidden email]> wrote:

    Am 13.07.2017 um 21:43 schrieb Donald G Porter:
    > That evidence doesn't reach me.  If people love the bundling practice,
    > they don't tell me so.  I only hear from the folks who need to undo it
    > so they can adapt to their own established packaging systems.
   
    Just to note that I love bundeling, as the required work is done (which
    is your issue). So, the bundled packages in tcl are just great.
   
    Thank you for careing !
   
    -Harald
   
    ------------------------------------------------------------------------------
    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
    [hidden email]
    https://lists.sourceforge.net/lists/listinfo/tcl-core
   

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Donal K. Fellows-2
In reply to this post by Donald G Porter-2
On 13/07/2017 20:35, Donald G Porter wrote:

> On 07/12/2017 05:08 PM, Donal K. Fellows wrote:
>> I've been thinking a bit about 8.7 schedules in the light of talking to
>> people at EuroTcl, and I think we ought to have a goal of getting the
>> first alpha out this year. (More would be OK too.) But in order to make
>> 8.7a1 worth releasing, we really ought to have some key features to make
>> it a bit awesome. So what could they possibly be?
>
> FWIW, my plan has been to get 8.6.7 out the door first (and that's
> taking far too long as I struggle to get Itcl 4.1 release-worthy).
> Then I would immediately release 8.7a0 with the feature(s) it already
> has -- notably the new notifier.
I did note that I was sounding off with my opinions, and I'm very happy
to have your knowledgeable input on this.

> I generally support your call for more features, more quickly, and
> I agree that the ones most likely to need some trial by fire would
> be better to get in sooner.  But I don't have any intent to make
> a first alpha release wait for anything.  Whatever's in the trunk
> goes out when the time comes.

YES!!!

>>    1: Minimal support for Unicode beyond the BMP.
>
> Months ago we had TIP 389 very nearly ready.  Just a few bugs
> in the handling of the Tcl_UniChar array representation needed
> fixing since this becomes a variable-length instead of fixed-length
> encoding in the revised scheme.  Is there any major objection to
> seeing that through as the best available path here?

I'm not objecting, but I'm saying that the minimum useful functionality
set is “transport through without destroying” coupled with showing
things correctly in Tk (i.e., feeding the characters in correctly to the
relevant font rendering engine). That's the critical requirement.

If we can do more than that with the first step, that's good. It
satisfies the critical minimum. ;-)

>>    2: Zip VFS.
>
> This is a very welcome idea.  We've taken a few stabs at it
> and every time it grows out of control.  ("Oh, if you're going
> to do that, then you'll need to fix TEA.... and then you should
> really invent a whole new build system for starkit making... and then...").

That's exactly why I want to not solve that whole thing with the first
step. The first critical part is C API and Tcl command that can mount a
ZIP read only. Yes, not tackling the boot stuff or the TEA stuff or any
of that. I want the foundations done before I start picking the colour
of the wallpaper.

OTOH, I recognise that people want lots of extra stuff. That's why this
is good to get in early.

>> Big Ticket Items for Tk:
>>
>>    1: Contrib package system for Tk to follow pattern of Tcl 8.6.
>
> I understand you seek to benefit from bundling lots of
> good functionality in existing Tk extension packages, but
> someone has to report the downside to this.
>
> If we didn't bundle other packages, Tcl 8.6.7 would have been out
> months ago.
[...]
> Proceed with caution and expect me to have extreme skepticism.

Here's my thought on that general principle. If a particular release is
bust, it doesn't get bundled and we stick with the previous one we used,
which is theoretically either OK or at least a known broken. I really
don't see a good reason to wait a Tcl release because of problems with
something that is formally downstream. I appreciate that you've been
trying to provide better service than that, but I just think we have to
time-box and cut back to what we already have if necessary for the good
of everything else.

Yeah, that's a pretty hard-line position. :-P

> I'll also mention that my idealized vision has not been to have
> Tk grow a tk/pkgs directory/.  It has been to TEA-tame Tk itself
> so that it and its extensions drop into the tcl/pkgs directory.

I'm happy to accede to what you think best, but I want to get critical
packages that improve Tk more widely available. I'm very worried about
the threats to the structure of the community if we don't.

Donal.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

donal_k_fellows.vcf (241 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Donal K. Fellows-2
In reply to this post by akupries
On 13/07/2017 16:33, Andreas Kupries wrote:
> Note, the TIP itself needs an update, it is still marked as pending.

Are you sure? I fixed that about 24 hours ago. You might need to refresh
the page…

Donal.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

donal_k_fellows.vcf (241 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Donal K. Fellows-2
In reply to this post by Peter da Silva-2
On 13/07/2017 14:23, Peter da Silva wrote:
> What’s currently in the TIP is, if not exactly what you’re asking for, very close.

Well, I want it ready to go to vote soon because I really want the
change in with enough time for us to crush out as much performance by
the time we hit 8.7.0. I'm under no illusions at all that using named
parameters will have no speed implications; if we're very clever, we'll
be able to get that to being a compile-time problem only, but I suspect
that named params will always come with a runtime cost (well, at least
until we get tclquadcode to comprehend them).

As long as it is a cost that people vote for themselves to have rather
than having it thrust upon them, that's not too bad. Greater
comprehensibility is something that it is entirely reasonable to choose
over speed in some circumstances.

Donal.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core

donal_k_fellows.vcf (241 bytes) Download Attachment
dah
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

dah
In reply to this post by tcl-core mailing list
On 7/13/2017 11:19 AM, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote:

> I would really like to know more about a "radical ways"...

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.  The
speedup code should behave as a mirror image of the current clock code,
and any differences being simply in implementation details.

The maintainer is responsible for reviewing and signing off on your
code, then they become responsible for it after giving it an OK. 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.

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. Eventually if it is
good stuff, they'll come around to adding it in, but I wouldn't hold
your breathe. Tcl is old. Their maintainers are all part-timers AFAIK.
Projects as old as Tcl tend to slow in development as reliability and
stability is favored over all else.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

akupries
In reply to this post by Donal K. Fellows-2
> On 13/07/2017 16:33, Andreas Kupries wrote:
> > Note, the TIP itself needs an update, it is still marked as pending.
>
> Are you sure? I fixed that about 24 hours ago. You might need to refresh
> the page…

Ooops. Apologies for the noise.

--
See you,
        Andreas Kupries <[hidden email]>
                        <http://core.tcl.tk/akupries/>
        Developer @ SUSE (MicroFocus Canada LLC)
                  <[hidden email]>

Tcl'2017, Oct 16-20, Houston, TX, USA. http://www.tcl.tk/community/tcl2017/
EuroTcl 2017, Jul 8-9, Berlin/DE, http://www.eurotcl.tcl3d.org/
-------------------------------------------------------------------------------






------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

tcl-core mailing list
In reply to this post by dah
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Mathieu Lafon
In reply to this post by Donal K. Fellows-2
On Fri, Jul 14, 2017 at 12:38 AM, Donal K. Fellows
<[hidden email]> wrote:
>
>> What’s currently in the TIP is, if not exactly what you’re asking for,
>> very close.
>
> Well, I want it ready to go to vote soon because I really want the
> change in with enough time for us to crush out as much performance by
> the time we hit 8.7.0.

I'm not sure to understand your view on the current TIP.

Do you like the current proposal and would call for a vote after some
modifications? If yes, what parts do you think need to be modified or
clarified?

Regards.

-- Mathieu

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Peter da Silva-2
In reply to this post by Donal K. Fellows-2
On 7/13/17, 5:38 PM, "Donal K. Fellows" <[hidden email]> wrote:
> Well, I want it ready to go to vote soon because I really want the change in with enough time for us to crush out as much performance by the time we hit 8.7.0. I'm under no illusions at all that using named parameters will have no speed implications; if we're very clever, we'll be able to get that to being a compile-time problem only, but I suspect that named params will always come with a runtime cost (well, at least until we get tclquadcode to comprehend them).

Sure, but what’s in the TIP shouldn’t impose a penalty on regular positional parameters. And they should be significantly faster than any native Tcl implementation of the same functionality.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 8.7a1 Feature Target List

Harald Oehlmann
In reply to this post by Donald G Porter-2
Am 13.07.2017 um 21:35 schrieb Donald G Porter:

> If we didn't bundle other packages, Tcl 8.6.7 would have been out
> months ago.
>
> Bundling is an enormous burden on release-making.  Very nearly
> deal-breaking.  Juggling seven balls really is harder than two.
>
> If every bundled package could be like sqlite3, there would be no
> issue.  Vigorous owner making high quality releases on his own
> calendar. Just grab and go.
>
> Not every package is like that.  Some are unhousebroken puppies
> left by the side of the road.

If ITCL is unmaintained, then I propose to drop it from the bundled
packages (someone have to say this, I suppose).

> I'll also mention that my idealized vision has not been to have
> Tk grow a tk/pkgs directory/.  It has been to TEA-tame Tk itself
> so that it and its extensions drop into the tcl/pkgs directory.

IMHO, this would be an improvement.
We could also have other core-close" packages, to be installed in the
pkgs folder, but not bundled with the core. The installation method is
just nice.

Thank you,
Harald

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Loading...