Menu
▾
▴
tcllib-devel
|
From: Andreas K. <and...@ac...> - 2011-03-10 22:54:29
|
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 |
|
From: Larry M. <lm...@bi...> - 2011-03-11 01:15:56
|
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 |
|
From: Robert <si...@gm...> - 2011-03-11 01:36:03
|
* 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 > |
|
From: Kevin W. <kw...@co...> - 2011-03-11 01:26:43
|
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 |
|
From: Lars H. <Lar...@re...> - 2011-03-11 08:33:20
|
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 |
|
From: Andreas K. <and...@ac...> - 2011-03-11 17:29:40
|
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 |
|
From: Lars H. <Lar...@re...> - 2011-03-11 22:50:29
|
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 |
|
From: Andreas K. <and...@ac...> - 2011-03-11 17:31:24
|
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 |
|
From: Arjen M. <arj...@de...> - 2011-03-11 07:53:43
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X