tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #358: Suppress Empty List Element Generation from the Split Command

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

George Petasis wrote:
>  TIP #358: SUPPRESS EMPTY LIST ELEMENT GENERATION FROM THE SPLIT COMMAND 
> =========================================================================
[...]
>  This TIP proposes a new optional switch (*-noemptyelements*) to the 
>  *split* command: 
> 
>        *split -noemptyelements* /string/ ?/splitChars/? 

Would you like to comment what would happen to the currently-valid Tcl code:

   set s "-noemptyelements"
   set list [split $s {abcde}]

Donal.

Re: [TCLCORE] TIP #358: Suppress Empty List Element Generation from the Split Command

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

George Petasis wrote:
>  TIP #358: SUPPRESS EMPTY LIST ELEMENT GENERATION FROM THE SPLIT COMMAND 

Possible solutions without having to add options to a builtin ...

proc split-without-empty-elements-1 {list} {
	return [lsearch -all -inline -not [split $list] {}]
	# Thanks to spjuth.
	# This is 8.4+
}

# And for older Tcl's without the relevant lsearch options ...

proc split-without-empty-elements-3 {list} {
	set res {}
	foreach x [split $list] {
		if {$x eq {}} continue
		lappend res $x
	}
	return $res
}

proc split-without-empty-elements-2 {list} {
	package require struct::list
	return [struct::list filterfor x [split $list] {$x ne {}}]
}

-- 
Sincerely,
     Andreas Kupries <an...@ac...>
     Developer @    <http://www.activestate.com/>

[TCLCORE] TIP #358: Suppress Empty List Element Generation from the Split Command

[George P. <pe...@ii...>]

 TIP #358: SUPPRESS EMPTY LIST ELEMENT GENERATION FROM THE SPLIT COMMAND 
=========================================================================
 Version:      $Revision: 1.2 $
 Author:       George Petasis <petasis_at_iit.demokritos.gr>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Sunday, 04 October 2009
 URL:          http://purl.org/tcl/tip/358.html
 WebEdit:      http://purl.org/tcl/tip/edit/358
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 The *split* command will create empty list elements when adjacent split 
 characters are found in the input. In some cases these empty list 
 elements are not desired, so this TIP proposes a new switch to disable 
 their generation. 

 RATIONALE 
===========

 The idea for this TIP came from a discussion in comp.lang.tcl: 
 [<URL:http://groups.google.gr/group/comp.lang.tcl/browse_thread/thread/8d46b0f10e7a5750/d7844cc739aa4310>] 
 and the (non obvious) suggestions on how tokens can be extracted from a 
 string can be performed efficiently. 

 It should be noted that this will allow the *split* command to be used 
 in a fashion that is very similar to how splitting works in many other 
 languages (e.g., Perl, awk, Unix shells). 

 SPECIFICATION 
===============

 This TIP proposes a new optional switch (*-noemptyelements*) to the 
 *split* command: 

       *split -noemptyelements* /string/ ?/splitChars/? 

 If this option is present, then *split* will not produce an empty list 
 element when the /string/ contains adjacent characters that are present 
 in /splitChars/. 

 REFERENCE IMPLEMENTATION 
==========================

 Currently there is no patch, but it should be quite easy to implement 
 this. 

 COPYRIGHT 
===========

 This document has been placed in the public domain. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

Re: [TCLCORE] Slowness is passing data into slave interpreters

[Donald G P. <don...@ni...>]

Ashok P. Nadkarni wrote:
> Timestamping the C code, the slowdown with the slave interp seems to 
> happen because of shimmering in SlaveEval (the internal rep for the list 
> is thrown away and converted to a string and then converted back in the 
> slave).

Appears this was added as part of the first big NRE patch last year.

Also appears it isn't needed, and can't see any evidence it was ever
needed.  If we uncover some actual reason we do need it, we need a test
case in the test suite to demonstrate it.

Fixed on HEAD.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] changes for 8.5.8 releases

[Donald G P. <don...@ni...>]

I've updated the changes files for the Tcl/Tk 8.5.8 releases.  Please
examine and correct and fill in any missing bits.  Thanks!

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] Implemented TIP 348 : ::tcl::errorStack

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

Hi,

I'm pleased to announce the completion of the reference implementation
of TIP 348, bringing substituted tracebacks ala Python/gdb. Please
review.

One nice thing is the very small overhead:

   - zero (one boolean test in Tcl_LogCommandInfo) when not enabled
   - very little when enabled:

   for {set i 1} {$i<10} {incr i} {
    proc f$i x "f[expr {$i+1}] \$x"
   }
   proc f10 x {error F10:$x}

   time {catch {f1 12}} 10000
   -> 75.4951 microseconds per iteration

   set ::tcl::useErrorStack 1

   time {catch {f1 12}} 10000
   -> 79.7074 microseconds per iteration

   puts $::tcl::errorStack
   {f10 12} {f9 12} {f8 12} {f7 12} {f6 12} {f5 12} {f4 12} {f3 12}
{f2 12} {f1 12}

This is a 6% overhead in a 10-level catch with empty hulls as procs.
Should be vanishingly small if we add any real meat.

-Alex

Re: [TCLCORE] Slowness is passing data into slave interpreters

[Ashok P. N. <apn...@ya...>]

Alexandre Ferrieux wrote:
>       ip eval [list slaveproc] [list $s]
>
>
> Note that {ip eval slaveproc [list $s]} won't work, because TCO shies
> away from optimized list operations as soon as one non-list is found
> (the reason is that [concat] is more general than list concatenation,
> and must be able to work on non-lists).
>   
You know, I saw that other branch and tried forcing that path through 
[ip eval slaveproc [list $s]] but that didn't help as you say. I didn't 
think of trying what you suggested (did not even think realize there is 
a difference). Now I understand. Thanks

/Ashok

Re: [TCLCORE] Slowness is passing data into slave interpreters

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

On 10/4/09, Ashok P. Nadkarni <apn...@ya...> wrote:
>
>  Timestamping the C code, the slowdown with the slave interp seems to
>  happen because of shimmering in SlaveEval (the internal rep for the list
>  is thrown away and converted to a string and then converted back in the
>  slave).
>  Is this issue worth addressing in the core or is
>  it expected behaviour for whatever reason? I traced through SlaveEval
>  but do not grok exactly why the shimmering (intentionally done) is
>  necessary.

While Lars' suggestion solves the immediate problem, your question is
interesting.
Looking at SlaveEval, there's a nonobvious dichotomy between
single-arg and multiple-arg [$slave eval]. In the single-arg case, the
shimmering is a documented consequence of TIP 280 trying to keep the
link with the original source:

	/*
	 * TIP #280: Make actual argument location available to eval'd script.
	 *
	 * Do not let any intReps accross, with the exception of
	 * bytecodes. The intrep spoiling is due to happen anyway when
	 * compiling.
	 */

While I admit I don't fully understand this necessity, it turns out
the multiple-argument code path doesn't have the limitation, since it
directly calls  Tcl_ConcatObj on its list of arguments, and it is well
known that TCO is optimized for all-pure-list arguments (dating back
to Paul Duffin's work on Concat objects IIRC). Hence one can derive a
script-level idiom guaranteeing a shimmerless path:

      ip eval [list slaveproc] [list $s]

Measurements prove the validity of the prediction:

   % time {ip eval [list slaveproc $s]} 10
   1384.7 microseconds per iteration
   % time {ip eval [list slaveproc] [list $s]} 10
   6.7 microseconds per iteration

Note that {ip eval slaveproc [list $s]} won't work, because TCO shies
away from optimized list operations as soon as one non-list is found
(the reason is that [concat] is more general than list concatenation,
and must be able to work on non-lists).

So, after all there's a (contrived) idiom giving back its due speed to
your direct slave call.

But I's still appreciate explanations about the TIP 280-related
comment above. Andreas ?

-Alex

Re: [TCLCORE] Slowness is passing data into slave interpreters

[Ashok P. N. <apn...@ya...>]

Lars Hellström wrote:
> If you only want to call a specific command in the slave, then you can 
> set up an alias in the master to that command:
Gaah! this never occurred to me. In fact, reading the slave interp 
examples, somehow it has (my own fault) been burnt into my brain that 
aliases are for mapping slave procs to master procs. This works great.
>
> OTOH, one might wonder which Tcl version you're using... Upon testing 
> the above in 8.5.5 (which I happened to have running), I got
>
8.6 CVS HEAD
> Lars Hellström
Thanks much

/Ashok

Re: [TCLCORE] Slowness is passing data into slave interpreters

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

Ashok P. Nadkarni skrev:
> FINALLY, my questions -  is there any way to reduce this overhead of 
> passing data into a slave interpreter without the hack of having it 
> "call back" for data?

If you only want to call a specific command in the slave, then you can 
set up an alias in the master to that command:

% interp alias {} slaveproc ip slaveproc
slaveproc
% time {slaveproc $test} 10
29.555799999999998 microseconds per iteration

OTOH, one might wonder which Tcl version you're using... Upon testing 
the above in 8.5.5 (which I happened to have running), I got

% time {eval [list masterproc $test]} 10
44.3157 microseconds per iteration
% time {ip eval [list slaveproc $test]} 10
53.6789 microseconds per iteration
% time {masterproc $test} 10
22.560499999999998 microseconds per iteration

All of these are within the same order of magnitude, and the overhead 
for crossing interpreter boundaries doesn't seem to be noticable. (It'd 
be a different matter if you communicated with a slave in another 
thread, though.)

Lars Hellström

[TCLCORE] Slowness is passing data into slave interpreters

[Ashok P. N. <apn...@ya...>]

(Posting here rather than c.l.t because I believe this is an internals 
issue)

I want to process data received over the network in a safe interpreter 
(although for the purposes of this question, the safe-ness is 
irrelevant). Roughly speaking, I invoke the safe interpreter as

  safeinterp eval [list process_request $received_data]

What I've found is that invoking the slave interpreter in this manner is 
slower than processing in the same interpreter by two orders of 
magnitude or more. Here is a tkcon session simulating the issue:

(woof) 51 % interp create ip
ip
(woof) 52 % ip eval {proc slaveproc arg {}}
(woof) 53 % string length [set s [string repeat x 100000]]
100000
(woof) 54 % time {ip eval [list slaveproc $s]} 10
3335.4 microseconds per iteration

So roughly, 3.3ms to pass 100K into an empty proc in the slave. By 
comparison, passing it to a proc in the same interp (using eval for 
consistency)

(woof) 55 % proc masterproc arg {}
(woof) 56 % time {eval [list masterproc $s]} 10
9.3 microseconds per iteration

So use of a slave interpreter in this fashion is MUCH slower. That 3ms 
overhead makes this approach a non-starter in a web server environment. 
As a workaround, what I currently do is call the slave proc without any 
arguments and then have it call back to retrieve the data through an 
alias. This is only slightly slower (~15 microsecs) than the one interp 
case so acceptable but feels like a hack with unnecessary additional 
bookkeeping for the callback alias.

Timestamping the C code, the slowdown with the slave interp seems to 
happen because of shimmering in SlaveEval (the internal rep for the list 
is thrown away and converted to a string and then converted back in the 
slave).

FINALLY, my questions -  is there any way to reduce this overhead of 
passing data into a slave interpreter without the hack of having it 
"call back" for data? Is this issue worth addressing in the core or is 
it expected behaviour for whatever reason? I traced through SlaveEval 
but do not grok exactly why the shimmering (intentionally done) is 
necessary.

/Ashok

Re: [TCLCORE] TIP #357: Export TclLoadFile

[Joe E. <jen...@fl...>]

Kevin Kenny wrote:
>
>  TIP #357: EXPORT TCLLOADFILE
>  SPECIFICATION
> ===============
>
>  The /TclLoadFile/ call shall be renamed /Tcl_LoadFile/ and exported in
>  the external Stubs. Its call signature is:

[ lightly reformatted, -JE ]

>     EXTERN int Tcl_LoadFile(
> 	Tcl_Interp *interp,			// [1]
> 	Tcl_Obj *pathPtr,			// [2]
> 	int symc,				// [3]
>	const char *symbols[],			// [4]
> 	Tcl_PackageInitProc **procPtrs[],	// [5]
> 	Tcl_LoadHandle *handlePtr,		// [6]
> 	ClientData *clientDataPtr,		// [7]
> 	Tcl_FSUnloadFileProc **unloadProcPtr)	// [8]
> [...]

Re argument [6], Tcl_LoadHandle *handlePtr:

>  The /loadHandle/ pointer will be a handle suitable for passing to
>  /TclpFindSymbol/ for resolving additional symbols in the library.

If that's all it's good for then either TclpFindSymbol
should also be made public or this argument should be dropped.

However, according to tcl.h, 'Tcl_FSUnloadFileProc's also
take a Tcl_LoadHandle argument:

| typedef void (Tcl_FSUnloadFileProc) (Tcl_LoadHandle loadHandle);

If this is the case, then argument [7] ClientData *clientDataPtr
should be dropped instead:

>  The /clientData/ will be filled in with client data that is needed if the
>  library is to be unloaded, and the /unloadProcPtr/ will have the
>  correct filesystem-dependent procedure for unloading the library.

Re argument [5], Tcl_PackageInitProc **procPtrs[]:
this makes the function less general than it should be.
It presumes that every function in the table is of the
form 'int func(Tcl_Interp*) { ... }'.

That's sufficient for dynamically-loaded Tcl packages
where you're looking for 'int Foo_Init(Tcl_Interp*)',
optionally 'int Foo_SafeInit(Tcl_Interp*)',
and hoping not to find 'int Foo_Unload(Tcl_Interp*)',
but in the general case the functions to be loaded
will have arbitrary signatures.

For an example, see struct XPThemeProcs in tk/win/ttkWinXPTheme.c,
(which is filled in at run-time by dlsym()ing UXTHEME.DLL):

| typedef HTHEME  (STDAPICALLTYPE OpenThemeDataProc)(HWND hwnd,
| 		 LPCWSTR pszClassList);
| typedef HRESULT (STDAPICALLTYPE CloseThemeDataProc)(HTHEME hTheme);
| ...
| typedef struct
| {
|     OpenThemeDataProc *OpenThemeData;
|     CloseThemeDataProc *CloseThemeData;
|     [...]
| } XPThemeProcs;


What we really want for argument [5] is "pointer to structure
containing sequence of (generic) function pointers", but
since the C type system doesn't have a way to say that,
I suggest changing it to "void *".  Otherwise the function
can't be profitably used without a cast.

Last problem:

>  On return, /Tcl_LoadFile/ fills in /procPtrs/ with the addresses that
>  correspond to the names in /symbols./ If a name cannot be resolved in
>  the given library, the corresponding entry in /procPtrs/ will be NULL.

I suspect that in the most common case you'll want to
return TCL_ERROR if any of the names can't be resolved.

Returning TCL_OK but leaving a NULL pointer in the stub table
means the caller has to double-check the answer; not very
for a convenience routine.


--Joe English

  jen...@fl...

Re: [TCLCORE] TIP #357: Export TclLoadFile

[Vince D. <vin...@gm...>]

How does this TIP relate to how extensions can/should interact with
virtual filesystems and the ability of Tcl to load shared libraries
embedded in virtual filesystems?

Vince.

2009/10/2 Kevin Kenny <kev...@gm...>:
> Kevin Kenny wrote:
>>  TIP #357: EXPORT TCLLOADFILE
>> ==============================
>>  Version:      $Revision: 1.1 $
>>  Author:       Kevin Kenny <kevin.b.kenny_at_gmail.com>
>>  State:        Draft
>>  Type:         Project
>>  Tcl-Version:  8.7
>
> Clarification: There's a clerical error here; this is an _8.6_ TIP.
>
> --
> 73 de ke9tv/2, Kevin
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] TIP #357: Export TclLoadFile

[Kevin K. <kev...@gm...>]

Kevin Kenny wrote:
>  TIP #357: EXPORT TCLLOADFILE 
> ==============================
>  Version:      $Revision: 1.1 $
>  Author:       Kevin Kenny <kevin.b.kenny_at_gmail.com>
>  State:        Draft
>  Type:         Project
>  Tcl-Version:  8.7

Clarification: There's a clerical error here; this is an _8.6_ TIP.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP #357: Export TclLoadFile

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

I don't know if there are repercussions but that is awesome as it reads. 
  :-)

Bob

[TCLCORE] TIP #357: Export TclLoadFile

[Kevin K. <kev...@gm...>]

 TIP #357: EXPORT TCLLOADFILE 
==============================
 Version:      $Revision: 1.1 $
 Author:       Kevin Kenny <kevin.b.kenny_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Thursday, 01 October 2009
 URL:          http://purl.org/tcl/tip/357.html
 WebEdit:      http://purl.org/tcl/tip/edit/357
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 This TIP proposes to promote the internal call /TclLoadFile/ to the 
 external API, making it available to C extensions. 

 RATIONALE 
===========

 In developing TDBC, the author of this TIP was advised to look at the 
 way that the 'oratcl' extension contrives to build on a system where 
 Oracle is not installed as a model for TDBC extensions. Examination of 
 the code revealed that it operates essentially by constructing at run 
 time a Stubs table for the routines in the Oracle client library. There 
 is a maze of *#if* directives selecting whether this process is 
 accomplished by the system calls that manage Unix .so files (/dlopen/ 
 and friends), Windows .DLL files (/LoadLibrary/ and related calls), 
 HP-UX .shl files (/shl_load,/ etc.), and so on. 

 Tcl already has functionality so that a caller can abstract away all 
 this complexity. It provides the capability in the /TclLoadFile/ call, 
 but this call is *MODULE_SCOPE* and not exported even in the internal 
 Stubs table. For this reason, it is entirely unavailable to 
 TEA-compliant extensions. 

 If this call were available, it would be feasible, in the 8.6 time 
 frame, to bundle all the database-specific TDBC drivers with the core 
 TDBC distribution, since things could be set up so that they will build 
 anywhere, even in the absence of the databases where they connect. 

 SPECIFICATION 
===============

 The /TclLoadFile/ call shall be renamed /Tcl_LoadFile/ and exported in 
 the external Stubs. Its call signature is: 

       EXTERN int *Tcl_LoadFile*( Tcl_Interp */interp/, Tcl_Obj 
       */pathPtr/, int /symc/, const char */symbols/[], 
       Tcl_PackageInitProc **/procPtrs/[], Tcl_LoadHandle */handlePtr/, 
       ClientData */clientDataPtr/, Tcl_FSUnloadFileProc 
       **/unloadProcPtr/) 

 In this call, /interp/ designates an interpreter for error reporting. 
 /pathPtr/ is an object containing the path of the library to be loaded. 
 If /pathPtr/ is a single name, the library search path of the current 
 environment will be used to resolve it. /symc/ is the number of symbols 
 that are to be imported from the newly loaded library. The /symbols/ 
 array gives /symc/ character strings that are the names of the imported 
 symbols. 

 The return value of /Tcl_LoadFile/ is a standard Tcl result code. If 
 the result is TCL_ERROR, the interpreter result will contain an 
 appropriate error message. 

 On return, /Tcl_LoadFile/ fills in /procPtrs/ with the addresses that 
 correspond to the names in /symbols./ If a name cannot be resolved in 
 the given library, the corresponding entry in /procPtrs/ will be NULL. 
 The /loadHandle/ pointer will be a handle suitable for passing to 
 /TclpFindSymbol/ for resolving additional symbols in the library. The 
 /clientData/ will be filled in with client data that is needed if the 
 library is to be unloaded, and the /unloadProcPtr/ will have the 
 correct filesystem-dependent procedure for unloading the library. 

 REFERENCE IMPLEMENTATION 
==========================

 This TIP proposes simply documenting and renaming an existing internal 
 routine. No new executable code ought to be needed to support it. 

 LICENSE 
=========

 This file is explicitly released to the public domain and the author 
 explicitly disclaims all rights under copyright law. 

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows 

[TCLCORE] Prep for 8.5.8 releases

[Donald G P. <dg...@ni...>]

I've raised the following Tracker items to prio-9:

     1712098
     1835292
     1839067
     1869390
     1941434
     2107634
     2418583
     2629338
     2782488
     2794032
     2800740
     2824550

They are all reports I'd like to see examined as we try to shove
releases 8.5.8 of Tcl and Tk out the door in the next couple of weeks.

It would be great to fix them all, but I'm not requiring that.  If a
maintainer simply comments that it's not reasonable to quickly fix an
issue in that time frame, I'll accept that.  I just don't want them to
slip by unexamined.

If there's some other issue that I didn't list above that a maintainer
thinks ought to be on the list, please raise it.

Thanks for your help.

For those about to ask "Hey what about 8.6b2?!"... I want 8.6b2
releases to happen shortly after 8.5.8.  I have an additional list of
tracker items for that, which I will post soon.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] TDBC 1.0b13 released

[Kevin K. <kev...@gm...>]

I am happy to announce release 1.0b13 of TDBC.  This is the most
recent of the frequent beta releases of the TDBC core and driver code.
This release includes the new Postgres native-code driver contributed
by Slavek Cygan, supported by Google Summer of Code 2009.

Source code of TDBC, and all the drivers, can be obtained by the
following steps:

(1) Open a browser and go to http://tdbc.tcl.tk/index.cgi/login

(2) Log in as 'anonymous' - the password is shown on that page.

(3) Once you are logged in, go to the page for the 1.0b12 release:
     http://tdbc.tcl.tk/index.cgi/ci/e8ac920205

(4) Download the source code by clicking on the [ZIP Archive] link
     in the 'Commands:' line at the bottom of the first paragraph.

Win32 binaries and HTML documentation for the 1.0b11 release are
available from SourceForge at:

https://sourceforge.net/project/showfiles.php?group_id=10894&package_id=305160

The files to be found there are:

tdbc1.0b13-win32.zip:

This file contains Win32 binaries of the database drivers for TDBC. To
install it, unzip the file, and then run 'wish86.exe' passing it the
INSTALL.TCL file in the resulting directory. Thereafter, tclsh and
wish should be able to do
     [package require tdbc::mysql]
     [package require tdbc::odbc]
     [package require tdbc::postgres]
and
     [package require tdbc::sqlite3]

tdbc1.0b13-doc.zip:

This file contains HTML documentation for the TDBC drivers. The
'contents.html' file in its root directory is the entry point to the
documentation and contains the links to everything else.

-----------------------------------------------------------------------------

Significant changes since the 1.0b12 release:

tdbc::postgres:
	The 'tdbc::postgres' driver is new in this release.  This driver
	allows TDBC to access PostgreSQL databases directly through
	libpq, without needing an intermediate ODBC layer.

tdbc::odbc:
	The 'tdbc::odbc' package now uses SQLSetConnectOption
	in place of SQLSetConnectAttr to manipulate the 'autocommit'
	flag. While this function is documented as 'obsolete', it
	is observed to give better compatibility with legacy
	ODBC drivers.

[TCLCORE] You've been invited by Ezhilan Ilangovan

[Ezhilan I. <in...@lu...>]

Ezhilan invited you to play brain games on Lumosity, the leader in healthy games that make you smarter.

Do you want to play games with Ezhilan?

Play games at:
http://www.lumosity.com/account/sign_up?invite=5b352bac-6d80-552a-f61d-f93952324ecf&refer=166



Thanks,
The Lumosity Team

This message was intended for tcl...@li.... Lumos Labs Inc | 500 3rd Street, Suite 235| San Francisco, CA 94107

Re: [TCLCORE] Tcl/Tk port for Maemo 5 (N900)

[Youness A. <kak...@ka...>]

Hi Alexandre,

On Tue, Sep 29, 2009 at 3:19 AM, Alexandre Ferrieux <
ale...@gm...> wrote:

> Hi Youness,
>
> On 9/29/09, Youness Alaoui <kak...@ka...> wrote:
> >
> > I'm wondering if anyone would be interested in making a port of the
> latest
> > Tcl/Tk for Maemo 5, or would be ready to help me make that port. Nokia
> gives
> > extensive support for developers and you can get all the info you need
> from
> > here : http://maemo.org/development/
> > It would also be nice if the hildonized version of Tcl/Tk would get
> merged
> > upstream (with #ifdef MAEMO if necessary) so that we don't need to redo
> > everything when a new version of tc/tk is released.
> >
> > What do you think?
>
> As to the hildonization of Tk, I suspect there is a parallel with the
> GUI adaptation done for Windows Mobile in eTcl (windowless window
> manager, virtual keyboard, hard buttons).
> Just wanted to make sure you knew about it ;-)
>
> -Alex
>
Thanks for the response, I know about eTcl and tried it a long time ago but
it wasn't hildonized or anything.
I also found this in the wiki : http://wiki.tcl.tk/15408 (about the first
maemo version on the Nokia 770). The last comment seems to say that eTcl is
hildonized but I just tested it and it's not actually (the hildon system
changed from Maemo 4 to Maemo 5, so maybe that's why it failed to load the
hildon library/code on Maemo 5).
Also note that Maemo is not like Windows Mobile, we're not talking about a
windowless window manager, the thing runs an X server, the window manager
does handle windows, just a bit differently (you still have a title bar, an
X button to close and you can have as many windows opened as you want). But
I do agree that the GUI adaptation done by eTcl would be a lot easier to use
in order to adapt Tcl/Tk for Maemo too, however I don't seem to be able to
find etcl's source code either and it looks like it's closed source.. so I'm
not sure how much help I might get from them.. I'll add evolane's support in
CC in case they want to join in to this discussion.
Thanks, I hope we can get this to work nicely!
KaKaRoTo

Re: [TCLCORE] Tcl/Tk port for Maemo 5 (N900)

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

Hi Youness,

On 9/29/09, Youness Alaoui <kak...@ka...> wrote:
>
> I'm wondering if anyone would be interested in making a port of the latest
> Tcl/Tk for Maemo 5, or would be ready to help me make that port. Nokia gives
> extensive support for developers and you can get all the info you need from
> here : http://maemo.org/development/
> It would also be nice if the hildonized version of Tcl/Tk would get merged
> upstream (with #ifdef MAEMO if necessary) so that we don't need to redo
> everything when a new version of tc/tk is released.
>
> What do you think?

As to the hildonization of Tk, I suspect there is a parallel with the
GUI adaptation done for Windows Mobile in eTcl (windowless window
manager, virtual keyboard, hard buttons).
Just wanted to make sure you knew about it ;-)

-Alex

[TCLCORE] Tcl/Tk port for Maemo 5 (N900)

[Youness A. <kak...@ka...>]

Hi everyone,

Some of you might know what Maemo is, some may not, so I'll explain it very
briefly. Maemo is Nokia's debian-based, open source Linux OS that runs on
the Nokia internet tablets. There were many iteration of the Maemo OS and
Nokia is about to release Maemo 5 along with it's newest Phone+Internet
tablet, the Nokia N900.
You can read more about it here : http://maemo.nokia.com
And here's a nice walkthrough video showing off the device and the software
: http://www.youtube.com/watch?v=a_WlpCpwVq4
And you can probably just google, or search youtube (or wikipedia) for maemo
or n900 to learn/see a lot more about this.

As some of you know, I'm the lead developer of the aMSN project, one of the
most successful Tcl/Tk applications. I've ported (basically just compiled)
aMSN for the previous internet tablets (N800 and N810) with deb packages for
bora, chinook and diablo (code names for Maemo 2, 3 and 4) and I'd like to
create some new ones for fremantle (code name for Maemo 5). I will soon get
my N900 (once it gets released), and I'd like to run aMSN on it obviously.

Now the problem is that the UI needs to be 'hildonized' which basically
means that it should know how to interact with the Maemo OS, a few examples
of the behavioral changes in an application that is 'hildonized' : the menu
doesn't appear unless you tap the title bar, if the virtual keyboard is
enabled, when focus is on a text/entry, the virtual keyboard appears, the
system's smart dictionary can suggest word completion, etc...
To be able to run aMSN on the previous Maemo versions, I used this port of
Tcl/Tk for Maemo (bora) : https://garage.maemo.org/projects/tcltk/
It is a hildonized version of Tcl/Tk 8.4.13 and it has been unmaintained
since it's release in 2007, but it still compiled and ran the same way
across all the different versions of Maemo, however it never was complete
and it's quite outdated now...
aMSN with that version of tcl/tk still compiles and runs fine on Maemo 5
(you can run maemo on your desktop using scratchbox, xephyr and qemu (or
build maemo for i386 and not use qemu), the nokia website gives instructions
on how to do that),

I'm wondering if anyone would be interested in making a port of the latest
Tcl/Tk for Maemo 5, or would be ready to help me make that port. Nokia gives
extensive support for developers and you can get all the info you need from
here : http://maemo.org/development/
It would also be nice if the hildonized version of Tcl/Tk would get merged
upstream (with #ifdef MAEMO if necessary) so that we don't need to redo
everything when a new version of tc/tk is released.

What do you think?

Thank you for reading (and hopefully answering),
KaKaRoTo

Re: [TCLCORE] Seeking USE_TCLALLOC users

[Donald G P. <dg...@NI...>]

 >> ....Is anyone making any use of a USE_TCLALLOC build
>> of Tcl? 

Konovalov, Vadim (Vadim)** CTR ** wrote:
> I used it,...

Thanks for the reply.  That's enough for me to keep it around.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] TIP 356 Accepted

[Donald G P. <dg...@ni...>]

Donald G Porter wrote:
> Please cast votes on TIP 356 by [clock format 1253721600].

TIP 356 Accepted by 7-0-0 vote.
YES: Kenny, Sofer, Porter, English, Steffen, Fellows, Nijtmans


-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Seeking USE_TCLALLOC users

[Konovalov, V. (Vadim)** C. ** <vko...@al...>]

> As mentioned in Tcl Bug 2557696, I believe the memory allocation
> routines enabled when Tcl sources are built with the USE_TCLALLOC
> directive have some problems.  I think there are 64-bit issues and
> argument overflow checking issues.  I've been correcting such things
> in other allocators that I know get used.
> 
> I'd rather not waste time fixing the USE_TCLALLOC allocators if it
> no longer has any users.  I'd rather just purge the dead code.  I
> would do this only on the HEAD sources.
> 
> So here's the call.  Is anyone making any use of a USE_TCLALLOC build
> of Tcl?  Can anyone report successful test or use of it for any
> productive purpose in the last year or two?

I used it, for the following reasons:

- this speeds up the wince build significantly (although I haven't built it for several years. I use old binaries, but will occasionally rebuild it)
- Sometimes I compile together Perl with Tcl/Tk with USE_PERLMALLOC and USE_TCLALLOC and substitute memory allocation calls with Perl_malloc. This gains me a common allocator, which happens to be a little bit faster, to my eye (but  I did not any real benchmarking, so I could be wrong)

I would like to see USE_TCLALLOC not reaped, I think that it is useful.

I would not be really really sad if it will go away, so I will accept reaping it with a proper courage, but my preference is to leave it.

Instead, is it possible to substitute Tcl allocatot with a 3rd party already tested one, with interface remaining the same?
As I already said, I even used Perl's allocator succesfully, but I guess it is not the only alternative :)

On the other side, reaping USE_TCLALLOC will be transparent to me if, while reaping content, the interface to allocator will be unchanged, so I will continue using Perl's allocator where applicable, and system's one otherwise.

Best regards,
Vadim.