tcllib-devel — Discussion of development for tcllib

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Andreas K. <and...@ac...>]

On 4/26/2011 6:03 AM, Gerald W. Lester wrote:
> On 4/26/11 2:20 AM, Arjen Markus wrote:
>> Hi Andreas,
>>
>> have we reached a conclusion for this issue yet? (My most pressing
>> need at the moment is the development of a new version of Plotchart,
>> which I am developing together with Torsten Berg)
> Arjen,
>
> According to my email log TclLib was going to follow Core and use fossil.
> I'm not sure why the leap has not been made yet.

Sinking under my radar over time.

>
> Andreas, if this is correct -- do we have a schedule for making the jump?

My apologies. We do not have a schedule.
Right now I also do not have time for this, due to donuts eating it up.

> Also, are we going to use the  fossil bug tracking or stay with the SF bug
> tracking?

I would stay with the SF tracking. We can transfer an SF bug database to fossil 
just fine by now, in terms of data translation. However integration of old 
references in the changelogs and such isn't fully there yet, and our most 
experienced person in that area (Kevin) counsels against, at least not before 
the default setup in fossil got an overhaul. Which he, unfortunately doesn't 
have time for.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Kevin K. <kk...@ny...>]

On 04/26/2011 09:03 AM, Gerald W. Lester wrote:
> On 4/26/11 2:20 AM, Arjen Markus wrote:
>> Hi Andreas,
>>
>> have we reached a conclusion for this issue yet? (My most pressing
>> need at the moment is the development of a new version of Plotchart,
>> which I am developing together with Torsten Berg)
> Arjen,
>
> According to my email log TclLib was going to follow Core and use fossil.
> I'm not sure why the leap has not been made yet.
>
> Andreas, if this is correct -- do we have a schedule for making the jump?
>
> Also, are we going to use the  fossil bug tracking or stay with the SF bug
> tracking?

My $0.02:

Please stay with SF bug tracking.  Fossil's bug tracking isn't ready.
I say this as probably the guy with the most experience transferring
a bug DB from SF to Fossil. The transfer works, and I'm quite confident
about the data integrity, now and moving forward, but the UI and
workflow are both in need of some serious love and I don't have time
to put in the necessary work.

-- 
73 de ke9tv/2, Kevin

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Arjen M. <arj...@de...>]

Hi Gerald,

that is what I understood at the time, but then the decision about the
core was not yet made. Now that it is, it seems we should make the
jump too.

Regards,

Arjen

On 2011-04-26 15:03, Gerald W. Lester wrote:
> On 4/26/11 2:20 AM, Arjen Markus wrote:
>> Hi Andreas,
>>
>> have we reached a conclusion for this issue yet? (My most pressing
>> need at the moment is the development of a new version of Plotchart,
>> which I am developing together with Torsten Berg)
> Arjen,
> 
> According to my email log TclLib was going to follow Core and use fossil.  
> I'm not sure why the leap has not been made yet.
> 
> Andreas, if this is correct -- do we have a schedule for making the jump?
> 
> Also, are we going to use the  fossil bug tracking or stay with the SF bug 
> tracking?
> 
 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Gerald W. L. <Ger...@co...>]

On 4/26/11 2:20 AM, Arjen Markus wrote:
> Hi Andreas,
>
> have we reached a conclusion for this issue yet? (My most pressing
> need at the moment is the development of a new version of Plotchart,
> which I am developing together with Torsten Berg)
Arjen,

According to my email log TclLib was going to follow Core and use fossil.  
I'm not sure why the leap has not been made yet.

Andreas, if this is correct -- do we have a schedule for making the jump?

Also, are we going to use the  fossil bug tracking or stay with the SF bug 
tracking?

-- 
+------------------------------------------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Arjen M. <arj...@de...>]

Hi Andreas,

have we reached a conclusion for this issue yet? (My most pressing
need at the moment is the development of a new version of Plotchart,
which I am developing together with Torsten Berg)

Regards,

Arjen

On 2011-02-15 19:04, Andreas Kupries wrote:
> On 2/14/2011 4:41 PM, Michael Schlenker wrote:
>> Hi Andreas,
>>
>> I personally do not really care if either Git or Fossil gets picked, both are fine for the intended use.
>>
>>  From a more global perspective it might be better to pick Git instead of Fossil due to the larger group of
>> users already knowing Git in general, compared to fossil. It is the 800 lbs gorilla, but if that one moves
>> us forward faster, who cares?
> 
>> And it is not really in doubt that there are and will be more tools available for Git than for fossil due to the pure market share.
>>
>> So, for political reason I would cast a vote for Git. Its good enough for the job, gives Tcl(lib) some more visibility than using
> 
> I should clarify here my previous example/argument I made, about the GSoC 
> student. The argument is one of "lower barrier to entry". It is not a 
> (auto)magic visibility of the form "If you build it they will come".
> 
> Even with going "git" Tcl(lib)s visibility is determined by actual marketing, 
> i.e. evangelization.
> 
> There is one argument which I was told in private mail, against "git", namely 
> that it(s support) is not very good on windows, and that this might drive 
> developers away, given that Tcl prides itself on good x-platform portability, 
> which means that we need good windows support in our tools for easy development 
> on that platform. At least for those people not using a mix of platforms like 
> me (*).
> 
> Regarding the core assumption behind the argument, of git not being good on 
> Win, that I can't really evaluate. I haven't used git very much and not at all 
> on Windows.
> 
> Given my own preference for fossil I will certainly ask this question on the 
> fossil list as well, for while I am using fossil often now I haven't used it on 
> windows either.
> 
> 
>> a (nice, but) 'fringe' system like fossil, and makes it easier for others to participate.
> 
> I would not describe fossil as 'fringe' with its negative connotations. Niche, 
> yes, fringe, no.
> 
>> I think we should also look at other things like issue/bug trackers when doing the move, the Sourceforge trackers are far from best
>> of breed for sure, so both fossils trackers and github or others might offer improvements.
> 
> (*) With the mix of boxes I have access to, and the shared file systems all the 
> VCS ops happen on linux and files are copied to windows boxes for building. No 
> direct VCS ops on the windows boxes.
> 
 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Tcllib-devel] 1st Call For Papers, 18th Annual Tcl/Tk Conference 2011

[Andreas K. <and...@ac...>]

18th Annual Tcl/Tk Conference (Tcl'2011)
http://www.tcl.tk/community/tcl2011/

October 24 - 28, 2011
Comfort Suites Manassas

Manassas, Virgina, USA

Important Dates:

Abstracts and proposals due   August    26, 2011
Notification to authors       September 12, 2011
WIP and BOF reservations open August     1, 2011
Author materials due          October    9, 2011
Tutorials Start               October   24, 2011
Conference starts             October   26, 2011

Email Contact:                tcl...@go...

Submission of Summaries

Tcl/Tk 2011 will be held in Manassas, Virgina, USA from
October 24 - 28, 2011. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

This year is the fourth year that the Tcl community is participating
in the Google Summer of Code.  The conference program committee would
like to encourage submissions that report on the Tcl projects selected
for Google SoC 2011.

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 30,
2011. Authors of accepted abstracts will have until October 14, 2011
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 1, 2011. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 2011. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2011/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://aspn.activestate.com/ASPN/Mail/ to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt              Noumena Corp                    General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.       Program Chair
Cyndy Lilagan           Iomas Research, LLC
Brian Griffin           Mentor Graphics
Ron Fox                 NSCL/FRIB Michigan State University
Arjen Markus            Deltares
Mike Doyle              Iomas Research, LLC
Gerald Lester           KnG Consulting, LLC
Donal Fellows           University of Manchester
Jeffrey Hobbs           ActiveState Software Inc.
Steve Landers           Digital Smarties
Kevin Kenny             GE Global Research Center
Larry Virden            Tcl FAQ Maintainer
Steve Redler IV		SR Technology

Contact Information     tcl...@go...


Tcl'2011 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

[Tcllib-devel] GSoC Tcl/Tk: The student application period is now open ...

[Andreas K. <and...@ac...>]

Hi all.

The student application period is now open, ending at April 8 (in 2 weeks).

To apply with the Tcl/Tk community use the 'Login'/'Register' buttons found at 
the Tcl/Tk Community page, i.e.:

	http://socghop.appspot.com/gsoc/org/google/gsoc2011/tcltk

Mentors have a link for their registration too.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

[Tcllib-devel] Tcl/Tk status regarding GSoC 2011

[Andreas K. <and...@ac...>]

Hi all.

This is a heads-up that the Tcl/Tk community has been accepted for
Google's Summer Of Code 2011, making this our 4th acceptance.

Please spread the word to all and sundry, especially to prospective
students and mentors.

Some notes:

*	Tcl/Tk's homepage at GSoC's website is

		http://socghop.appspot.com/gsoc/org/show/google/gsoc2011/tcltk

*	Prospective students, please subscribe to the "tcl-gsoc"
         mailing list for overall communication with us. The
         registration page is at

	        https://lists.sourceforge.net/lists/listinfo/tcl-gsoc

	Also, while our page of ideas is at

		http://wiki.tcl.tk/26127

	a student's own ideas around Tcl are welcome too.


*	Prospective mentors, please subscribe to the "tcl-gsoc"
         mailing list for overall communication, and the
         "tcl-gsoc-mentors" mailing list for communication between
         mentors only.

         The registration pages are at

	        https://lists.sourceforge.net/lists/listinfo/tcl-gsoc
         and	http://groups.google.com/group/tcl-gsoc-mentors

*	All of the above is also mentioned on our main entry page at

		http://www.tcl.tk/gsoc/

---
Andreas

Re: [Tcllib-devel] tcllib csv mention

[Gerald W. L. <Ger...@co...>]

On 3/15/11 6:35 AM, Larry W. Virden wrote:
> Over on http://wiki.tcl.tk/5985 there is a note in the last piece of
> code on the page that the tcllib csv package fails rule 6 of
> http://tools.ietf.org/html/rfc4180 . Is this the case, and if so, is
> there a way to provide the missing functionality in the existing code?
I've updated http://wiki.tcl.tk/5985 to point out, with an example, that the 
CSV package in TclLib does indeed handle rule #6 of RFC4180.

-- 
+------------------------------------------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Re: [Tcllib-devel] tcllib csv mention

[Arjen M. <arj...@de...>]

Hi Larry,

I am a bit surprised about that:

package require csv
set a "A,\"B C\",D"
set b [::csv::split $a]

produces a list in b that is printed as: A {B C} D,
exactly what I expect.

I have Tcllib csv version 0.6

Regards,

Arjen

On 2011-03-15 12:35, Larry W. Virden wrote:
> Over on http://wiki.tcl.tk/5985 there is a note in the last piece of
> code on the page that the tcllib csv package fails rule 6 of
> http://tools.ietf.org/html/rfc4180 . Is this the case, and if so, is
> there a way to provide the missing functionality in the existing code?
> 
 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Tcllib-devel] tcllib csv mention

[Larry W. V. <lv...@gm...>]

Over on http://wiki.tcl.tk/5985 there is a note in the last piece of
code on the page that the tcllib csv package fails rule 6 of
http://tools.ietf.org/html/rfc4180 . Is this the case, and if so, is
there a way to provide the missing functionality in the existing code?

-- 
Tcl - The glue of a new generation.   http://wiki.tcl.tk/
Larry W. Virden
http://www.facebook.com/lvirden/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

Re: [Tcllib-devel] Tcl GSoC 2011 - Ideas anyone ?

[Lars H. <Lar...@re...>]

Andreas Kupries skrev 2011-03-11 18.27:
> On 3/11/2011 12:33 AM, Lars Hellström wrote:
>> For what it's worth, I've been doing some (pure-Tcl, though unpublished)
>> work on parsing TrueType/OpenType files, particularly to the end of
>
> Does this work fit under
> 	http://wiki.tcl.tk/28085
> 	(GSoC Idea: Computational geometry for glyph outlines)
>
> or would that be a different but related idea ?

Different but related (and only vaguely so).

I came to the conclusion myself today that this could probably be put 
forth as an idea of its own (independent of PDF generation, even if it has 
applications in that area), so I'll add it to the list after I've had 
another look at the code.

A good thing about it as a GSoC project is that there it plenty of 
independent tasks that can be undertaken (TrueType has a gazillion 
different table, subtable, and subsubtable types). It's nothing big and 
essential for the community, but if all projects were that then we 
probably would get fewer students.

Lars Hellström

Re: [Tcllib-devel] Tcl GSoC 2011 - Ideas anyone ?

[Andreas K. <and...@ac...>]

Diverting from reading the accumulated mails in this thread ...

	While I am glad that my mail kicked the ant-hill and is producing
	ideas I would really like for people to not just voice them here, but
	add their ideas directly to the Wiki too.

	The page http://wiki.tcl.tk/27201 has the necessary template (*).

	A distributed effort of getting them up and about is IMHO much better
	than expecting me to keep up with everybody and their dog. I am but a
	single person standing in this flood.

... And back to reading ...

~~~~~~~
(*) I know that I was bad in this regard yesterday evening. I was more focused 
on getting the older ideas on their own pages for discussion than putting in 
them in the style of the template.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Tcl GSoC 2011 - Ideas anyone ?

[Andreas K. <and...@ac...>]

On 3/11/2011 12:33 AM, Lars Hellström wrote:
> Kevin Walzer skrev 2011-03-11 02.26:
>> 2. Complete the PDF-generation projects from the past couple of summers,
>> hook them up to native printing dialogs on each platform, and get the
>> whole package into the core (or at least as a visible extension, I have
>> no clue where the code currently exists). I can offer Mac-specific
>> printer dialog code here:
>> http://tk-components.svn.sourceforge.net/viewvc/tk-components/cocoaprint/.
>
> I haven't kept up-to-date with these developments, but generally, how do
> these projects stand on the axis of doing-stuff-themselves vs.
> relying-on-external-libraries (of which some are probably
> platform-specific)? A print dialog surely introduces some platform
> dependence, but what about the content generation parts? How much is tied
> into Tk, and how much can be used without?
>
> For what it's worth, I've been doing some (pure-Tcl, though unpublished)
> work on parsing TrueType/OpenType files, particularly to the end of

Does this work fit under
	http://wiki.tcl.tk/28085
	(GSoC Idea: Computational geometry for glyph outlines)

or would that be a different but related idea ?

> dumping metric and outline data, but I expect a lot of the effort could be
> reused in a PDF generation context. Font handling is otherwise likely to
> be an obstacle if going the doing-stuff-yourself route.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Tcl GSoC 2011 - Ideas anyone ?

[Lars H. <Lar...@re...>]

Kevin Walzer skrev 2011-03-11 02.26:
> 2. Complete the PDF-generation projects from the past couple of summers,
> hook them up to native printing dialogs on each platform, and get the
> whole package into the core (or at least as a visible extension, I have
> no clue where the code currently exists). I can offer Mac-specific
> printer dialog code here:
> http://tk-components.svn.sourceforge.net/viewvc/tk-components/cocoaprint/.

I haven't kept up-to-date with these developments, but generally, how do 
these projects stand on the axis of doing-stuff-themselves vs. 
relying-on-external-libraries (of which some are probably 
platform-specific)? A print dialog surely introduces some platform 
dependence, but what about the content generation parts? How much is tied 
into Tk, and how much can be used without?

For what it's worth, I've been doing some (pure-Tcl, though unpublished) 
work on parsing TrueType/OpenType files, particularly to the end of 
dumping metric and outline data, but I expect a lot of the effort could be 
reused in a PDF generation context. Font handling is otherwise likely to 
be an obstacle if going the doing-stuff-yourself route.

Lars Hellström

Re: [Tcllib-devel] Tcl GSoC 2011 - Ideas anyone ?

[Arjen M. <arj...@de...>]

Hi Andreas,

something I would love to see is a way of dealing with large sets
of _structured_ data. I am thinking of:
- An extension to read and write NetCDF or HDF files
- An extension to deal with partial differential equations
- An extension to deal with linear algebra and large linear systems
- (Perhaps) dealing with picture data, like your own extension (forgot
   the name)

There are a number of extensions (Tensor, NAP, my own work on LAPACK)
that can deal with at least a part of these questions, but they have
their own style. Something more coherent along the lines of TclOO and
TclODBC ...

Just a thought.

Oh, and I second Larry McVoy's plea for more attention to Tk.

Regards,

Arjen

On 2011-03-10 23:52, Andreas Kupries wrote:
> Our GSoC 2011 page at
> 
> 	http://wiki.tcl.tk/26127
> 
> looks a bit sparse.
> 
> While we can fluff it up a bit by copying ideas from previous years which did 
> not get executed onto the page (or subpages like in the table at the end), I 
> would really like to have newer ideas as well.
> 
> Anybody with spare cycles, please think and/or dream up ideas and put them up.
> 
 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Tcllib-devel] [TCLCORE] Tcl GSoC 2011 - Ideas anyone ?

[Robert <si...@gm...>]

* x-platform printing

That is one thing that I have always wished for...no pun intended.

Maybe open the question up on the comp.lang.tcl group to see what floats to the top?

Also, maybe Tk needs a "core" dev group all by its lonesome if Tk is to move forward (whatever forward ends up meaning here). One or two devs that are willing to push it along.

BTW...I looked at the shootout...no Tcl. 

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all


-- 
Robert
Sent with Sparrow

On Thursday, March 10, 2011 at 8:15 PM, Larry McVoy wrote: 
> I'd kinda like to get a discussion going around Tk. My personal
> feeling is that for the non-tcl people using tcl, it is all about Tk.
> By "non-tcl" I mean no disrespect, but there are a set of people, call
> them T, who love the tcl syntax and rules, etc. And I have respect,
> true respect for Tcl, especially in the tcl runtime. Many times I have
> found that Tcl has figured out a solution to a portability problem before
> we have. There is real value there.
> 
> There is another set of people, call them !T, that use tcl in spite
> of tcl. They don't like the tcl syntax at all but they put up with it
> because tcl gets them TK.
> 
> This will not play well in this venue but my feeling is that without
> the !T crowd, tcl would be far more obscure than it is (and it is pretty
> obscure, I was told recently that the language shootout people dropped
> tcl a while back, which is, if true, a bummer).
> 
> Tk gets some attention now and then but tcl gets lots of attention,
> from the crowd of people here. TK needs more lovin.
> 
> I would be open to taking on some effort on TK, to make it better,
> require less libs, be even more compelling than it is. And it is
> pretty compelling, it's way more pleasant than other GUI toolkits
> in my opinion. 
> 
> Colin will step up and say I want to control everything, and he's
> partially right. Sort of. I have absolutely zero interest in
> controlling the direction of tcl, you guys are doing fine on that,
> I do have issues and I voice them, but I am fine with being 
> ignored or shouted down. On tcl. On TK, I'd like to have more
> progress. Or better put, I am willing to put some energy and 
> money there. If it can do some good and if it has a different 
> process than the TIP process (or not, if the $DVCS changes help
> make the process better. But as things stand, I'm not spending
> a dime to push something through the TIP process).
> 
> So, what do you guys want?
> 
> On Thu, Mar 10, 2011 at 02:52:29PM -0800, Andreas Kupries wrote:
> > 
> > Our GSoC 2011 page at
> > 
> > http://wiki.tcl.tk/26127
> > 
> > looks a bit sparse.
> > 
> > While we can fluff it up a bit by copying ideas from previous years which did 
> > not get executed onto the page (or subpages like in the table at the end), I 
> > would really like to have newer ideas as well.
> > 
> > Anybody with spare cycles, please think and/or dream up ideas and put them up.
> > 
> > -- 
> > Andreas Kupries
> > Senior Tcl Developer
> > ActiveState, The Dynamic Language Experts
> > 
> > P: 778.786.1122
> > F: 778.786.1133
> > and...@ac...
> > http://www.activestate.com
> > Get insights on Open Source and Dynamic Languages at www.activestate.com/blog
> > 
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> -- 
> ---
> Larry McVoy lm at bitmover.com http://www.bitkeeper.com
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

Re: [Tcllib-devel] Tcl GSoC 2011 - Ideas anyone ?

[Kevin W. <kw...@co...>]

On 3/10/11 5:52 PM, Andreas Kupries wrote:
>
> Our GSoC 2011 page at
>
> 	http://wiki.tcl.tk/26127
>
> looks a bit sparse.
>
> While we can fluff it up a bit by copying ideas from previous years which did
> not get executed onto the page (or subpages like in the table at the end), I
> would really like to have newer ideas as well.
>
> Anybody with spare cycles, please think and/or dream up ideas and put them up.
>

1. Webkit bindings for Tk. It has to be simpler than writing an entire 
HTML parser and widget from scratch (TkHTML).

2. Complete the PDF-generation projects from the past couple of summers, 
hook them up to native printing dialogs on each platform, and get the 
whole package into the core (or at least as a visible extension, I have 
no clue where the code currently exists). I can offer Mac-specific 
printer dialog code here: 
http://tk-components.svn.sourceforge.net/viewvc/tk-components/cocoaprint/.

--Kevin



-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [Tcllib-devel] [TCLCORE] Tcl GSoC 2011 - Ideas anyone ?

[Larry M. <lm...@bi...>]

I'd kinda like to get a discussion going around Tk.  My personal
feeling is that for the non-tcl people using tcl, it is all about Tk.
By "non-tcl" I mean no disrespect, but there are a set of people, call
them T, who love the tcl syntax and rules, etc.  And I have respect,
true respect for Tcl, especially in the tcl runtime.  Many times I have
found that Tcl has figured out a solution to a portability problem before
we have.  There is real value there.

There is another set of people, call them !T, that use tcl in spite
of tcl.  They don't like the tcl syntax at all but they put up with it
because tcl gets them TK.

This will not play well in this venue but my feeling is that without
the !T crowd, tcl would be far more obscure than it is (and it is pretty
obscure, I was told recently that the language shootout people dropped
tcl a while back, which is, if true, a bummer).

Tk gets some attention now and then but tcl gets lots of attention,
from the crowd of people here.  TK needs more lovin.

I would be open to taking on some effort on TK, to make it better,
require less libs, be even more compelling than it is.  And it is
pretty compelling, it's way more pleasant than other GUI toolkits
in my opinion.  

Colin will step up and say I want to control everything, and he's
partially right.  Sort of.  I have absolutely zero interest in
controlling the direction of tcl, you guys are doing fine on that,
I do have issues and I voice them, but I am fine with being 
ignored or shouted down.  On tcl.  On TK, I'd like to have more
progress.  Or better put, I am willing to put some energy and 
money there.  If it can do some good and if it has a different 
process than the TIP process (or not, if the $DVCS changes help
make the process better.  But as things stand, I'm not spending
a dime to push something through the TIP process).

So, what do you guys want?

On Thu, Mar 10, 2011 at 02:52:29PM -0800, Andreas Kupries wrote:
> 
> Our GSoC 2011 page at
> 
> 	http://wiki.tcl.tk/26127
> 
> looks a bit sparse.
> 
> While we can fluff it up a bit by copying ideas from previous years which did 
> not get executed onto the page (or subpages like in the table at the end), I 
> would really like to have newer ideas as well.
> 
> Anybody with spare cycles, please think and/or dream up ideas and put them up.
> 
> -- 
> Andreas Kupries
> Senior Tcl Developer
> ActiveState, The Dynamic Language Experts
> 
> P: 778.786.1122
> F: 778.786.1133
> and...@ac...
> http://www.activestate.com
> Get insights on Open Source and Dynamic Languages at www.activestate.com/blog
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[Tcllib-devel] Tcl GSoC 2011 - Ideas anyone ?

[Andreas K. <and...@ac...>]

Our GSoC 2011 page at

	http://wiki.tcl.tk/26127

looks a bit sparse.

While we can fluff it up a bit by copying ideas from previous years which did 
not get executed onto the page (or subpages like in the table at the end), I 
would really like to have newer ideas as well.

Anybody with spare cycles, please think and/or dream up ideas and put them up.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Automated Checkin notification E-Mail missing

[Harald O. <har...@el...>]

Am 07.03.2011 18:11, schrieb Andreas Kupries:
> On 3/2/2011 11:12 PM, Harald Oehlmann wrote:
>> The checkin is in the repository but I received no change information mail.
> The last two points (**) are the most relevant.
> This is something I am (likely) not able to fix.

Thank you, Andreas,
IMHO you should not spent any time trying to fix this.
Echeckin notification E-Mails are gone - ok, no problem.

Thanks,
Harald

Re: [Tcllib-devel] Automated Checkin notification E-Mail missing

[Andreas K. <and...@ac...>]

On 3/2/2011 11:12 PM, Harald Oehlmann wrote:
> I checked in a patch for bwidget/combobox.tcl yesterday.

> There was a warning from sourceforge which said "if this persists please
> contact sourceforge".

> The checkin is in the repository but I received no change information mail.
> -Harald

I believe the CIAbot, i.e. the script doing the notification mail got disabled 
after the attack on SF and subsequent cleanup.

... Going back into their blog (https://sourceforge.net/blog/) the relevant 
block of text, as of Feb 10 is

	===============================================================
	CVS is back online (rsync, pserver, SSH and ViewVC), with a few
	caveats:
xx	- adminrepo via the Interactive Shell is temporarily offline
**	- due to a reduced number of installed libraries, some hook scripts
	may not function properly
**	- outbound email is not functional, so any script utilizing this will
	fail. If you need to send outbound email, a workaround would be to use
	curl and and external site or Project Web to send the email.
	===============================================================

The last two points (**) are the most relevant.
This is something I am (likely) not able to fix.

This is the last information they gave on this topic, i.e. I would believe that 
this situation regarding commit notifications is persisting.

Point (xx) I have just confirmed by logging into their shell.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

[Tcllib-devel] Automated Checkin notification E-Mail missing

[Harald O. <har...@el...>]

I checked in a patch for bwidget/combobox.tcl yesterday.
There was a warning from sourceforge which said "if this persists please
contact sourceforge".
The checkin is in the repository but I received no change information mail.
-Harald

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Andreas K. <and...@ac...>]

This seems to have puttered out.

My decisions on this, for the moment:

*	Follow what Tcl/Tk core is doing

*	The CVS is generally open for commits again.

	When the actual transition comes up I will close
	it again.

-- 
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
and...@ac...
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog

Re: [Tcllib-devel] Regarding SourceForge, the Tcllib CVS, and transitioning somewhere.

[Pat T. <pat...@us...>]

Only the tcl community would agonize about this. Anyone else would be
picking between bzr/hg/git. If we use git then someone used to using hg
can use hg-git and keep using hg even with a git backend. There is a
similar bzr-git shim for people who like using bzr (wierd though that
might seem).

Anyway - I agree they should get split into multiple repos. The only
reason tcllib,tklib,tclapps etc are together was administration of the
users (and the bug trackers to a lesser extent).

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD