tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] direct access to canvas pixels

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

Hello Terry,

not a big problem. tcl-core is meant for discussing Tcl itself,
rather than its use. Apart from that, comp.lang.tcl has a wider
audience and there may be people out there with better suggestions.

Regards,

Arjen

On 2009-04-01 15:58, T. Horsnell wrote:
> 
> Thank you, and apologies for using the wrong list.
> I'll use comp.lang.tcl in future.
> Cheers,
> Terry
>> Hello Terry,
>>
>> one way to achieve that is via the Img extension:
>> - copy the contents of the canvas to an image
>> - manipulate the contents via the image command (or underlying routines)
>> - put the new image on the canvas
>>
>> Your question is more suitable for comp.lang.tcl though.
>>
>> Regards,
>>
>> Arjen
>>
>> On 2009-04-01 13:16, T. Horsnell wrote:
>>> Hi all,
>>> Is there a tk routine which would enable me to directly read/write a 
>>> pixel-area on a canvas?
>>> I would like to be able to dump a selected canvas area into a tcl 
>>> array for later processing, and then possibly write it back.
>>>
>>> Cheers,
>>> Terry
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO 
>> and parts of Rijkswaterstaat have joined forces in a new independent 
>> institute for delta technology, Deltares. Deltares combines knowledge 
>> and experience in the field of water, soil and the subsurface. We 
>> provide innovative solutions to make living in deltas, coastal areas 
>> and river basins safe, clean and sustainable.
>>
>>
>> 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.
>>
>>
>>
>>
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

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: [TCLCORE] direct access to canvas pixels

[T. H. <ts...@mr...>]

Thank you, and apologies for using the wrong list.
I'll use comp.lang.tcl in future.
Cheers,
Terry
> Hello Terry,
>
> one way to achieve that is via the Img extension:
> - copy the contents of the canvas to an image
> - manipulate the contents via the image command (or underlying routines)
> - put the new image on the canvas
>
> Your question is more suitable for comp.lang.tcl though.
>
> Regards,
>
> Arjen
>
> On 2009-04-01 13:16, T. Horsnell wrote:
>> Hi all,
>> Is there a tk routine which would enable me to directly read/write a 
>> pixel-area on a canvas?
>> I would like to be able to dump a selected canvas area into a tcl 
>> array for later processing, and then possibly write it back.
>>
>> Cheers,
>> Terry
>>
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO 
> and parts of Rijkswaterstaat have joined forces in a new independent 
> institute for delta technology, Deltares. Deltares combines knowledge 
> and experience in the field of water, soil and the subsurface. We 
> provide innovative solutions to make living in deltas, coastal areas 
> and river basins safe, clean and sustainable.
>
>
> 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: [TCLCORE] direct access to canvas pixels

[Griffin, B. <bri...@me...>]

Hi Terry,

This list is for discussion of Tcl/Tk core implementation, and not it's usage.  The best place to get answers about Tcl/Tk use is the group comp.lang.tcl (see Google Groups).

That being said, the answer is no, direct pixel access on the canvas is not possible.  Pixel access is possible in an image and images can be placed on the canvas.  I don't know if that will help.

-Brian

-----Original Message-----
From: T. Horsnell [mailto:ts...@mr...]
Sent: Wed 4/1/2009 4:16 AM
To: tcl...@li...
Subject: [TCLCORE] direct access to canvas pixels
 

Hi all,
Is there a tk routine which would enable me to directly read/write a 
pixel-area on a canvas?
I would like to be able to dump a selected canvas area into a tcl array 
for later processing, and then possibly write it back.

Cheers,
Terry



------------------------------------------------------------------------------
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] direct access to canvas pixels

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

Hello Terry,

one way to achieve that is via the Img extension:
- copy the contents of the canvas to an image
- manipulate the contents via the image command (or underlying routines)
- put the new image on the canvas

Your question is more suitable for comp.lang.tcl though.

Regards,

Arjen

On 2009-04-01 13:16, T. Horsnell wrote:
> Hi all,
> Is there a tk routine which would enable me to directly read/write a 
> pixel-area on a canvas?
> I would like to be able to dump a selected canvas area into a tcl array 
> for later processing, and then possibly write it back.
> 
> Cheers,
> Terry
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

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.

[TCLCORE] direct access to canvas pixels

[T. H. <ts...@mr...>]

Hi all,
Is there a tk routine which would enable me to directly read/write a 
pixel-area on a canvas?
I would like to be able to dump a selected canvas area into a tcl array 
for later processing, and then possibly write it back.

Cheers,
Terry

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Gustaf N. <ne...@wu...>]

Donal K. Fellows schrieb:
> Tomasz Kosiak wrote:
>   
>> But I do think that we may want to think about finding some funding
>> for those improvements. Python has Google who pays 2 engineers full
>> time salary. But we as Tcl community also have some companies
>> involved. None to compare with Google, but some of us can provide some
>> funds.
>>
>> Especially I was thinking about what PyPy did. In European Union there
>> are possibilities to use public funds - if you plan to release results
>> of your research project to the public you can receive 75-100%
>> financial compensation for the project.
>>     
>
> Putting together a bid for funds from the EU is non-trivial! (I should 
> know; they fund the projects that pay my salary...) But then again, I 
> only really know the research vehicles within the DG-INFSOC system; the 
> others are all ones that I've never examined in depth. But the amount of 
> bureaucracy will be high.
>   
Well, this is not only a question of paperwork and bureaucracy, but more 
a question
of fit of a *research proposal* to the "Challenges" and "Objectives" of 
the fp, and
the question of being able to set up a consortium of partners with 
shared interest
and - in the best case - with a history of successful EU framework 
projects (IST, STREP, ...).
We (the Institute of Information Systems and New Media) are 
participating currently
in several of such projects (iCAMP, Prolix, iCOPER, Ltfll, ROLE), 
currently 20 team members
are funded mostly by these projects (which are all from the technology 
enhanced learning
context, most use OpenACS and XOTcl as implementation means, but not as 
research goals).

If there is interest to pursue this idea seriously, one needs a clearly 
shaped research
challenges, which are fitting to the focus of the fp, convincing the 
project
evaluators (from academia and  industry) and having a convincing consortium
capable to solve the challenges  (the dream team).

The project proposals are evaluated on a broad basis of
items where finally the scores are summed up. The competition is
usually quite strong. For our recent ROLE-project
(Responsive Open Learning Environments, IP, 3rd call) i
have still the figures at hand: 250 Project Proposal submitted for 
technology enhanced learning, 6 get funded.
The consortium consists of 16 partners.

I don't want to discourage anybody; note that leading such a project and
setting up a strong consortium is much harder than participating in a 
project
to fit certain needs.

-gustaf neumann
---
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
Vienna University of Business

http://nm.wu-wien.ac.at/nm/pages/en/members

[TCLCORE] gsoc:2009 regex cleanup

[mahanth g. <mah...@gm...>]

Hi,
   I am mahanth ,a 3 year computer science engineering student at IT-BHU,
India. I am interested in the project "Regexp engine cleanup". Having a
strong background in theoritical computer science and regular expreseions,
the project interests me very much.I am working on the backtracking
algorithm for regex handling. I have built the project from source and I am
having a look at tclRegexp.c. Please tell me whether I am in the right
direction.Waiting for suggestions

Thanks

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Donal K. F. <don...@ma...>]

Tomasz Kosiak wrote:
> But I do think that we may want to think about finding some funding
> for those improvements. Python has Google who pays 2 engineers full
> time salary. But we as Tcl community also have some companies
> involved. None to compare with Google, but some of us can provide some
> funds.
> 
> Especially I was thinking about what PyPy did. In European Union there
> are possibilities to use public funds - if you plan to release results
> of your research project to the public you can receive 75-100%
> financial compensation for the project.

Putting together a bid for funds from the EU is non-trivial! (I should 
know; they fund the projects that pay my salary...) But then again, I 
only really know the research vehicles within the DG-INFSOC system; the 
others are all ones that I've never examined in depth. But the amount of 
bureaucracy will be high.

> In fact you probably have to spend 50% of this on paying sponsoring
> university and for paperwork. But event if we will have to fund 10-25%
> of the research costs it is cheap. As there are some university stuff
> from Europe and some companies we probably can think more about it.

You're really thinking about a research project? Hmm. If I remember 
right, the rules for small companies in Framework 7 are fairly 
favourable (like universities, they'll be able to recover 75% of costs, 
but I don't know which cost models are admissible for SMEs) so it might 
be worthwhile examining what it requires. But we'll have to target 
either one of the later calls or FET-OPEN (effectively no close date, 
but exists only to allow funds to go to areas not predicted during the 
setting up of the calls). (Actually, Call 4 is still open but we stand 
*no* chance of making it as it closes on 1 April. I've heard of people 
writing a successful bid in two weeks, but not in two days! We're 
talking over 100 pages of stuff even with a small consortium and few 
workpackages.) Any bid *must* have partners from at least three member 
countries, and mixes of universities and companies seem to work well.

I've checked the rules/topics (downloadable from the following URL: 
ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/ict-wp-2009-10_en.pdf) and 
it seems that (assuming you're talking about Framework 7, ICT area, Call 
4) that we can't apply. This is because we're thinking about this about 
two to three months too late (the call closes on 1 April).

The best chance is FET Open. It might be a bit tricky (apart from 
everything else, we'd have to provide some evidence that we are not just 
some people who couldn't get their act together for one of the other 
calls!) but should be possible. And the process is much simpler to start 
out with.

The good news is that conditions for SMEs are indeed favourable.

Of course, if we were instead to focus on basing a project on using Tcl 
to do fancy virtualized services, we'd be in with a really good chance 
to do a good application for Call 5; the Objective ICT-2009.1.2 looks 
rather interesting, especially outcome b on Page 17. (It's also a 
relatively roomy objective; very unlikely to be crowded out by a single 
big project. This is Good.) While getting money to fund compiler 
development would be nice, getting funding is absolutely about the Art 
of the Possible...

> I know that this is a crazy idea but I would like probe it somehow? I
> know that Donal K Fellows and Gustaf Neumann seems to be European
> academics. Zoran Vasilijevic ARCHIWARE or my company DAC System are
> also located in Europe. Such a project should be lead be some kind of
> consortium. When I take a look at PyPy consortium it doesn't seems as
> made of large companies either - http://pypy.org/consortium.html. I
> think that outsourcing some work to US or Peru won't be a problem ;)

The US and Canada are curiously tricky in this regard - involving 
partners from there can be tough - but collaborating with most of the 
rest of the world will earn extra political marks. Promising to Open 
Source the results would help too, and shouldn't be a problem at all.

If we want to do this (targeting FET Open or Call 5) we should strive 
for it; I have a pretty good idea what a good application looks like, 
and I most certainly can get support from work for doing it. But *all* 
involved should be aware that this is a huge lot of work. After all, 
there's potentially a lot of money involved...

This takes us back to the questions:
  1) Are we really interested in doing this?
  2) What do we really want to do with it?
  3) Who will actually make sense to have involved?

If there's genuine interest in this, I'll get some closed mailing lists 
and other appropriate communication channels set up. Some arguments it 
is best to not have in public... :-)

(Also: Call 5 is not yet open, so it is possible - if unlikely - that 
the interesting parts might not be there or changed so that we don't 
want to apply. Can't say for sure until mid-July.)

Donal.

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[miguel s. <mig...@gm...>]

Tomasz Kosiak wrote:
 > <...>
> I think that outsourcing some work to US or Peru won't be a problem ;)

How about Argentina? ;)

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Tomasz K. <tk...@gm...>]

On Sun, Mar 29, 2009 at 9:15 PM, Donal K. Fellows
<don...@ma...> wrote:
> Simon Geard wrote:
>> Does Parrot (http://code.google.com/p/partcl) provide an upgrade path
>> for the VM ?
>
> In a word, no. It's got a deep assumption about mutable values that is
> incompatible with Tcl. That (plus our significantly more sophisticated
> variable model) would mean that we'd need to implement our value and
> variable systems as extra layers on top of the Parrot primitives, which
> would almost certainly destroy most of the benefits; the sophisticated
> compilation strategy I talked about earlier would still be needed to get
> real performance.
>
> Donal.

I've started this thread out of curiosity.

But I do think that we may want to think about finding some funding
for those improvements. Python has Google who pays 2 engineers full
time salary. But we as Tcl community also have some companies
involved. None to compare with Google, but some of us can provide some
funds.

Especially I was thinking about what PyPy did. In European Union there
are possibilities to use public funds - if you plan to release results
of your research project to the public you can receive 75-100%
financial compensation for the project.

In fact you probably have to spend 50% of this on paying sponsoring
university and for paperwork. But event if we will have to fund 10-25%
of the research costs it is cheap. As there are some university stuff
from Europe and some companies we probably can think more about it.

I know that this is a crazy idea but I would like probe it somehow? I
know that Donal K Fellows and Gustaf Neumann seems to be European
academics. Zoran Vasilijevic ARCHIWARE or my company DAC System are
also located in Europe. Such a project should be lead be some kind of
consortium. When I take a look at PyPy consortium it doesn't seems as
made of large companies either - http://pypy.org/consortium.html. I
think that outsourcing some work to US or Peru won't be a problem ;)

--tkosiak

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Donal K. F. <don...@ma...>]

Simon Geard wrote:
> Does Parrot (http://code.google.com/p/partcl) provide an upgrade path 
> for the VM ?

In a word, no. It's got a deep assumption about mutable values that is
incompatible with Tcl. That (plus our significantly more sophisticated
variable model) would mean that we'd need to implement our value and
variable systems as extra layers on top of the Parrot primitives, which
would almost certainly destroy most of the benefits; the sophisticated
compilation strategy I talked about earlier would still be needed to get
real performance.

Donal.

[TCLCORE] Historical Tcl/Tk GSoC 2008 projects and their results

[Tomasz K. <tk...@da...>]

All interested parties could take a look at last year approved Tcl/Tk
GSoC 2008 student projects at:

http://code.google.com/soc/2008/tcl/about.html

Snapshots of produced code is available at:

http://code.google.com/p/google-summer-of-code-2008-tcl/downloads/list

But I know that these are only snapshots which were required by Google
to be uploaded. I think it is best to contact appropriate students or
mentors for really final results if you are interested.

--tkosiak

Re: [TCLCORE] [Tcl-gsoc] TDBC driver

[Tomasz K. <tk...@gm...>]

I think that GSoC project scope could include adding more that one
database support, do TDBC, for example:
a) 1 or 2 database tcl-only adopters on top of existing Tcl bindings
b) one new C TDBC binding for selected database (+ evaluation how
feasable it is by comparing to tcl-only adopters - performance,
features, maintenance overhead)
c) checking how TDBC can be used on top other *popular* multidatabase
interfaces like OpenACS DB API
(http://openacs.org/doc/current/db-api.html) which was reimplemented
in pure Tcl as nstcl), AOLserver original ns_db and new Naviserver
ns_dbi, see comparision in http://wiki.tcl.tk/14972. We've already
have TclODBC TDBC driver.
d) explore approach about emulating those other multidatabase APIs on
top of TDBC to allow smooth transitions.

I'm not sure that all those points are feasible but i think they
should be researched. Single tcl-only adopter is probably a few days
task and it IMHO is far too small project for 12+ weeks of quite well
paid work. I think that we are willing to spend one slot for such a
more complete approach. But this is my humble opinion, maybe other
mentors disagree or rather support my view.

So I looking forward for a discussion. That is why I also cross post
it to tcl-core so others can join tcl-gsoc mailing list if interested
(https://lists.sourceforge.net/lists/listinfo/tcl-gsoc).

--tkosiak

2009/3/29 vishakh harikumar <vs...@gm...>:
> ive been checking up on TDBC development too
> i think tcl interface for postgresql already exists
> http://pgtclng.projects.postgresql.org/ which is based on libpq the standard
> postgresql library
> so it would only be a matter of adding above library to the standard
> interface for the driver?
> so maybe i should apply for adding oracle support?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Tcl-gsoc mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-gsoc
>
>

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Simon G. <si...@wh...>]

Alexandre Ferrieux wrote:
>
>
> On Sat, Mar 28, 2009 at 8:06 PM, Tomasz Kosiak <tk...@da...> wrote:
>
>     At this URL
>     http://trentm.com/blog/archives/2009/03/26/unladden-swallow/
>     there is mentioned Google sponsored project to replace CPython’s
>     custom virtual machine with a JIT built on top of LLVM. I have found
>     that news at Planet ActiveState RSS Feed so some people in the
>     community are already aware of this.
>
>     I just wonder what are our long-term plans about Tcl bytecode engine?
>
>
> Interesting. One question to ask, then, is how do the various issues 
> and solution they found (or will find) apply to Tcl.
> Notably, there is the usual question of dynamic typing which makes it 
> uneasy to build large blocks of known-fixed-type values without 
> constant boxing/unboxing (or type verification). Is this different in 
> Python ? Are there optional type annotations ?
>
> Depending on the answers, it would seem that (a) either we're doomed 
> with an underlying type system not really compatible with those 
> superfast optimizations, or (b) we're in roughly the same boat as 
> Python's. If (a) we might target less ambitious goals (like JITting 
> only expr/set blocks with only non-overloaded mathops) or start 
> introducing optional compiler hints. If (b), what about just waiting 
> for this to happen to Python and reaping the surviving good ideas at 
> the end ?
>
> -Alex
>
Does Parrot (http://code.google.com/p/partcl) provide an upgrade path 
for the VM ?

Simon

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Alexandre F. <ale...@gm...>]

On Sat, Mar 28, 2009 at 8:06 PM, Tomasz Kosiak <tk...@da...> wrote:

> At this URL http://trentm.com/blog/archives/2009/03/26/unladden-swallow/
> there is mentioned Google sponsored project to replace CPython’s
> custom virtual machine with a JIT built on top of LLVM. I have found
> that news at Planet ActiveState RSS Feed so some people in the
> community are already aware of this.
>
> I just wonder what are our long-term plans about Tcl bytecode engine?
>

Interesting. One question to ask, then, is how do the various issues and
solution they found (or will find) apply to Tcl.
Notably, there is the usual question of dynamic typing which makes it uneasy
to build large blocks of known-fixed-type values without constant
boxing/unboxing (or type verification). Is this different in Python ? Are
there optional type annotations ?

Depending on the answers, it would seem that (a) either we're doomed with an
underlying type system not really compatible with those superfast
optimizations, or (b) we're in roughly the same boat as Python's. If (a) we
might target less ambitious goals (like JITting only expr/set blocks with
only non-overloaded mathops) or start introducing optional compiler hints.
If (b), what about just waiting for this to happen to Python and reaping the
surviving good ideas at the end ?

-Alex

Re: [TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Donal K. F. <don...@ma...>]

Tomasz Kosiak wrote:
> I just wonder what are our long-term plans about Tcl bytecode engine?

Scrap it and do something better. :-)

> I've been discussing during the last conference all this new work done
> on Javascript engines with Miguel Sofer who joked that we maybe should
> translate Tcl code to Javascript. But seriously he confirmed there is
> still a place for large improvements in our bytecode engine.

The biggest improvement needed is an optimizer, but that's blocked by
the decrepit state of the bytecodes themselves.

What I would like to see is some kind of compilation engine that starts
out with interpretation or a quick compilation to bytecode, but which
will progressively compile "hot spots" more and more aggressively. I
think it is possible to do this, and I believe it can be done in the
background so that it doesn't impact startup speed too badly. Going all
the way to high-performance native code should be possible (though it
will need a number of safety/well-behaved-ness theorems about the code
being compiled to be proved).

My effort in 8.6 has been elsewhere though. ;-)

> We've recently move [clock] implementation to pure Tcl and it seems to
> be the trend postulated long before by Jean-Claude Wippler.
> But it seems we've lost on performance and increased memory and disk
> space footprint. Speeding up and compacting this code I think will be
> useful.

To be fair, the new [clock] does a lot more than the old one did too.

> Is Miguel Sofer going surprise us with something new as it was the
> case with his wonderful NRE stuff?

I think that the biggest constraint on revising the bytecode engine
itself is that there is quite a lot of existing saved bytecodes out
there (produced by the "tclcompiler" and loadable by "tbcload"). Any
major change will need all that stuff revisiting too (well, at least
tbcload; I'm happy to leave the "compiler" to commercial efforts).

Donal.

[TCLCORE] Even potential GSoC mentors/reviewers should sign into Melange

[Tomasz K. <tk...@da...>]

Hi!

If you've been contacted by a student in private about Google Summer
of Code or you have contributed to our GSoC 2009 idea list *please*
sign in to Melange (web app prepared by Google to handle GSoC 2009).
There we mentors can put private comments on student applications,
score them, etc. It is desirable that TCT members or Tcl/Tk
maintainers sign-in into Melange to be able to influence which
projects will be funded.

How to do it:

1. Make sure you have an GMail account (you can forward it easily to
you normal e-mail account in Settings so you don't have to use it to
read e-mail).
2. Sign-in with you GMail account to http://socghop.appspot.com
3. Choose LinkID (your screen name in Melange) to be somehow related
to your first+last name so it will be easy to identify you
4. Apply to be a mentor (last item in the left menu) for Tcl Community
Association - it is under this link
http://socghop.appspot.com/org/apply_mentor/google/gsoc2009

Do this even if you do not plan to mentor but you are willing to help
us refine the scope of projects from your field of expertise.

For me this is a declaration that we should add you to private e-mail
discussion about students applications.

--tkosiak

[TCLCORE] Is Tcl bytecode engine is also *in the far future* going to LLVM?

[Tomasz K. <tk...@da...>]

At this URL http://trentm.com/blog/archives/2009/03/26/unladden-swallow/
there is mentioned Google sponsored project to replace CPython’s
custom virtual machine with a JIT built on top of LLVM. I have found
that news at Planet ActiveState RSS Feed so some people in the
community are already aware of this.

I just wonder what are our long-term plans about Tcl bytecode engine?

I've been discussing during the last conference all this new work done
on Javascript engines with Miguel Sofer who joked that we maybe should
translate Tcl code to Javascript. But seriously he confirmed there is
still a place for large improvements in our bytecode engine.

We've recently move [clock] implementation to pure Tcl and it seems to
be the trend postulated long before by Jean-Claude Wippler.
But it seems we've lost on performance and increased memory and disk
space footprint. Speeding up and compacting this code I think will be
useful.

Is Miguel Sofer going surprise us with something new as it was the
case with his wonderful NRE stuff?

--tkosiak

[TCLCORE] [Tcl/Tk Community] We need *urgent* advertisement among CS students about Tcl in GSoC 2009

[Tomasz K. <tk...@gm...>]

Hi! I'm Tomasz Kosiak.

This year I have an honor to officially serve as an administrator for
Tcl/Tk Community involvement in Google Summer of Code 2009 program. I
would like to ask all broad Tcl community members to help us reach
students worldwide and encourage them to apply for a summer
scholarship.

If you have never heard of Google Summer of Code (aka GSoC) it is a
Google, Inc. sponsored initiative to fund aproximately 1000 student
scholarship $4500 each for coding during a summer for ideas freely
chosen by approved open-source organization. Tcl/Tk community is
approved again by Google this year (second time).

We seek opportunities to advertise among CS students our GSoC project
ideas. That is why I have prepared one slide info about Tcl/Tk and
GSoC. This e-mail can be freely forwarded directly to prospective
students or to your fellow university teachers so they can show this
slide for their students. The goal is to reach students worldwide
willing to apply to Tcl/Tk as mentoring organization.

See Tcl/Tk GSoC 2009 in a pill at http://tinyurl.com/tcl-gsoc2009 and
this is the only URL students shall write down to get started.

Official news about Tcl/Tk GSoC 2009 is at http://www.tcl.tk/gsoc/ and
http://wiki.tcl.tk/22182.

We, Tcl mentors and admins, are really willing to help students
prepare their applications. This is what our community is fond of.

As last year we *do* plan to act as umbrella organization for other
Tcl-related projects like Tk, XOTcl, Expect, AOLserver, Naviserver,
OpenACS, aMSN, Coccinella and others. We will try to lobby Google to
assure one student slot to those interested sub-communities. But we
need your ideas, mentors and promotion of our effort among students as
number of slots is mostly proportional to number of students
application received by an organization.

This is urgent as it would be best to reach students before the
weekend as student application deadline is set to April 3: 12 noon PDT
/ 19:00 UTC

Don't hesitate to contact me and Matthew Burke directly. Jeff Hobbs
(Tcl Guy  you all know) is also actively involved.

Regards and Happy Tcl'ing,
Tomasz Kosiak

PS. You can point students to other resources prepared by Google from
which I like the most the MS PowerPoint Slides from Philip Johnson's
presentation on Google Summer of Code at
http://csdl.ics.hawaii.edu/~johnson/screencasts/GSoC2009.ppt (see also
the video at http://csdl.ics.hawaii.edu/~johnson/screencasts/GSoC2009.mov).
These resource are both mentioned at official Google Blog in a post at
http://googleblog.blogspot.com/2009/03/supporting-students-in-open-source.html

Re: [TCLCORE] private font-files in tcltk

[T. H. <ts...@mr...>]

Pat Thoyts wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Pat Thoyts wrote:
>> Brian Griffin wrote:
>>> On Tue, Mar 24, 2009 at 4:28 PM, T. Horsnell <ts...@mr...
>>> <mailto:ts...@mr...>> wrote:
>>>     Jeff Hobbs wrote:
>>>     > On 24/03/2009 9:46 AM, T. Horsnell wrote:
>>>     >> Is there a way in TCLTK to use fontfiles from a private directory?
>>>     >> Preferably a way in which one can refer to such files by an explicit
>>>     >> file-path.
>>>     >
>>>     > Tk is directed by the fonts the X server (or OS system) says are
>>>     > available.  Just make that font available through the X server and Tk
>>>     > will see it.
>>>     >
>>>     > Jeff
>>>     Yes, but I want to do this under Windows as well as Linux and I dont
>>>     want the user to have to install this private fontset in either case.
>>>     I want to be able to distribute them along with the application.
>>> Sounds like a good GSoC project :-)
>>
>> This can probably be achieved using AddFontResourceEx or
>> AddFontMemResourceEx which is what is used to load fonts embedded in PDF
>> documents and other such things. I should think it will be fairly simple
>> to do.
>>
>> Pat Thoyts
> 
> 
> In fact the following code does the job:
>     critcl::cproc AddFontResource {Tcl_Interp* interp Tcl_Obj* pathObj} ok {
>         Tcl_DString ds;
>         Tcl_Encoding unicode;
>         int len, r = TCL_OK;
>         const char *path = Tcl_GetStringFromObj(pathObj, &len);
> 
>         Tcl_DStringInit(&ds);
>         unicode = Tcl_GetEncoding(interp, "unicode");
>         Tcl_UtfToExternalDString(unicode, path, len, &ds);
>         if (AddFontResourceExW(Tcl_DStringValue(&ds), FR_PRIVATE, NULL)
> == 0) {
>             r = TCL_ERROR;
>         }
>         Tcl_DStringFree(&ds);
>         Tcl_FreeEncoding(unicode);
>         return r;
>     }
> 
> given this function in an extension it will add a font from a .ttf file
> to the set available shown in [font families]. The FR_PRIVATE means the
> font is only made available to this process and is not installed into
> the system permanently.
> 
> Pat Thoyts

Great. Thank you very much! I'll have a play.

Cheers,
Terry

Re: [TCLCORE] private font-files in tcltk

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pat Thoyts wrote:
> Brian Griffin wrote:
>> On Tue, Mar 24, 2009 at 4:28 PM, T. Horsnell <ts...@mr...
>> <mailto:ts...@mr...>> wrote:
> 
>>     Jeff Hobbs wrote:
>>     > On 24/03/2009 9:46 AM, T. Horsnell wrote:
>>     >> Is there a way in TCLTK to use fontfiles from a private directory?
>>     >> Preferably a way in which one can refer to such files by an explicit
>>     >> file-path.
>>     >
>>     > Tk is directed by the fonts the X server (or OS system) says are
>>     > available.  Just make that font available through the X server and Tk
>>     > will see it.
>>     >
>>     > Jeff
> 
>>     Yes, but I want to do this under Windows as well as Linux and I dont
>>     want the user to have to install this private fontset in either case.
>>     I want to be able to distribute them along with the application.
> 
>> Sounds like a good GSoC project :-)
> 
> 
> This can probably be achieved using AddFontResourceEx or
> AddFontMemResourceEx which is what is used to load fonts embedded in PDF
> documents and other such things. I should think it will be fairly simple
> to do.
> 
> Pat Thoyts


In fact the following code does the job:
    critcl::cproc AddFontResource {Tcl_Interp* interp Tcl_Obj* pathObj} ok {
        Tcl_DString ds;
        Tcl_Encoding unicode;
        int len, r = TCL_OK;
        const char *path = Tcl_GetStringFromObj(pathObj, &len);

        Tcl_DStringInit(&ds);
        unicode = Tcl_GetEncoding(interp, "unicode");
        Tcl_UtfToExternalDString(unicode, path, len, &ds);
        if (AddFontResourceExW(Tcl_DStringValue(&ds), FR_PRIVATE, NULL)
== 0) {
            r = TCL_ERROR;
        }
        Tcl_DStringFree(&ds);
        Tcl_FreeEncoding(unicode);
        return r;
    }

given this function in an extension it will add a font from a .ttf file
to the set available shown in [font families]. The FR_PRIVATE means the
font is only made available to this process and is not installed into
the system permanently.

Pat Thoyts
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBScrOuWB90JXwhOSJAQIuxwP/cAez+yR0BueZ+4uMigH6OcL5SFRoE8S2
6PktMMlE0CrFQnfknHUXeHpH/HpgDUFhhikZld9SboiyDZAx7PSt+L0cGbHe/eYA
392Ilywyn0yXoFBcIawe6+UlTcKRRgu8lGz6p80rtQp9uNVCccY8kL6Nagjceqrx
mAienWG9668=
=aVuu
-----END PGP SIGNATURE-----

Re: [TCLCORE] private font-files in tcltk

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Griffin wrote:
> On Tue, Mar 24, 2009 at 4:28 PM, T. Horsnell <ts...@mr...
> <mailto:ts...@mr...>> wrote:
> 
>     Jeff Hobbs wrote:
>     > On 24/03/2009 9:46 AM, T. Horsnell wrote:
>     >> Is there a way in TCLTK to use fontfiles from a private directory?
>     >> Preferably a way in which one can refer to such files by an explicit
>     >> file-path.
>     >
>     > Tk is directed by the fonts the X server (or OS system) says are
>     > available.  Just make that font available through the X server and Tk
>     > will see it.
>     >
>     > Jeff
> 
>     Yes, but I want to do this under Windows as well as Linux and I dont
>     want the user to have to install this private fontset in either case.
>     I want to be able to distribute them along with the application.
> 
> Sounds like a good GSoC project :-)
>

This can probably be achieved using AddFontResourceEx or
AddFontMemResourceEx which is what is used to load fonts embedded in PDF
documents and other such things. I should think it will be fairly simple
to do.

Pat Thoyts
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBScq6umB90JXwhOSJAQKZiQP9GX2RWfT+xlTYgGtqouzmMnf3GmbLxQCX
X/AQXXiwmzzFJvHgNUbAGZKFtwq7dix7W5IDrwyCWABaQRy10RQepRaEvbDheXVn
s515npjLE3lfJS0+E9of5Cb5MUdJQibQST0GQdez8LdGqaRu2RKR7zak4zgph5yL
YZ76t9a/AW8=
=7O6g
-----END PGP SIGNATURE-----

Re: [TCLCORE] private font-files in tcltk

[Brian G. <bri...@ea...>]

Sounds like a good GSoC project :-)
-Brian

On Tue, Mar 24, 2009 at 4:28 PM, T. Horsnell <ts...@mr...> wrote:

> Jeff Hobbs wrote:
> > On 24/03/2009 9:46 AM, T. Horsnell wrote:
> >> Is there a way in TCLTK to use fontfiles from a private directory?
> >> Preferably a way in which one can refer to such files by an explicit
> >> file-path.
> >
> > Tk is directed by the fonts the X server (or OS system) says are
> > available.  Just make that font available through the X server and Tk
> > will see it.
> >
> > Jeff
>
> Yes, but I want to do this under Windows as well as Linux and I dont
> want the user to have to install this private fontset in either case.
> I want to be able to distribute them along with the application.
>
> Cheers,
> Terry
>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] Canvas to image

[Paul A. <pau...@gm...>]

I know the Img extension supports it, but allowing "image create" to use a
Tk window (specifically a canvas window) as a data source seems like a
natural feature for the the base language. The current situation is
curiously assymetric: iamges of various formats can be displayed, annotated,
and manipulated, but the return function is awkward or impossible.

Uses include everything from drawing programs to smart icons.

Furthermore, the status and documentation for the Img package seems
marginal.

Re: [TCLCORE] private font-files in tcltk

[T. H. <ts...@mr...>]

Jeff Hobbs wrote:
> On 24/03/2009 9:46 AM, T. Horsnell wrote:
>> Is there a way in TCLTK to use fontfiles from a private directory?
>> Preferably a way in which one can refer to such files by an explicit
>> file-path.
> 
> Tk is directed by the fonts the X server (or OS system) says are 
> available.  Just make that font available through the X server and Tk 
> will see it.
> 
> Jeff

Yes, but I want to do this under Windows as well as Linux and I dont
want the user to have to install this private fontset in either case.
I want to be able to distribute them along with the application.

Cheers,
Terry