tcllib-devel — Discussion of development for tcllib

[Tcllib-devel] trace logging for logger package?

[Michael K. <mki...@ci...>]

Hi, Folks.

We have several logging packages that we're merging together into one
wrapper around the logger package.  One of the things it does is provide
some additional APIs for execution tracing, where you can tell the logging
service log entry and exit of specified procedures (or all procedures in a
namespace).

# Synopsis:
#   <service>::trace  on
#   <service>::trace  off
#   <service>::trace  status ?<procName> ...?
#   <service>::trace  add    <procName> ...
#   <service>::trace  add    ?-ns? <nsName> ...
#   <service>::trace  remove <procName> ...
#   <service>::trace  remove ?-ns? <nsName> ...

It was suggested that I bring up the possibility of submitting the trace
logging feature as a patch for inclusion in the logger package itself.
Rather than reworking it right off and submitting it, though, we wanted to
bring it up to see whether the interest was there, primarily because there
would probably be a little bit of divergence from the other logger APIs.  In
particular:

* It's not possible (I believe) to enable/disable individual logging levels
for a logger service, only at-or-above a particular level.  In contrast, a
user might want to (and the current trace logging mechanism is set up to
allow) enable/disable tracing without having all other levels enabled
(assuming "trace" was one level below "debug").  The current mechanism does
this through <service>::trace on and <service>::trace off commands (and Tcl
traces are not set in the "off" state so, like log levels, there's no
execution overhead when disabled).

* For logprocs invoked by the trace, one would probably want to get all of
the arguments passed by trace itself, rather than a pre-formatted message.
However, logprocs currently only take one argument.  The way the trace
logging feature is currently implemented, it's not possible to specify an
alternate logproc for the trace logging.  I suppose it could just put all of
the arguments as a list into the message parameter...

What do the logger package developers/maintainers think about the
suitability of this for inclusion in the logger package, and about these
issues?

RE: [Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)

[Virden, L. W. <lv...@ca...>]

Well, certainly 1.7.0 is what is available for download at tcllib.sf.net
- and I seem to recall that many of the distribution projects expect to
use code that's been "released" , rather than take chances on using the
"latest" cvs version, which could have bugs introduced .

--=20
<URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20


-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of J. Tang
Sent: Thursday, May 25, 2006 6:06 PM
To: da...@tc...
Cc: tcl...@li...
Subject: Re: [Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)


>  From: Damon Courtney <da...@tc...>
>  Date: Thu, 25 May 2006 16:26:55 -0500
> =20
>      I guess it got fixed somewhere along the way.  I just test 1.7 in
>  the latest ActiveTcl, and it works as expected.  Not sure what
version=20
>  Jason is using.

Your suspicions are correct -- what I have installed is /not/ what is in
CVS.  My development machine, Debian/testing, has the package
bwidget-1.7.0-1 and has an error in NoteBook::bindtabs.  On the line
that appends to script, it uses the index value of 2 instead of 1.

As a test, I searched for the latest bwidget package for Fedora Core 5.
The latest version found is bwidget-1.7.0-2.fc5
(http://tinyurl.com/gb4rs).  This package also has the errant index
value of 2 for [NoteBook::bindtabs].

--=20
Jason Tang  /  ta...@jt...  /  http://www.jtang.org/~tang


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications
in the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=3D=
121642
_______________________________________________
Tcllib-devel mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcllib-devel

Re: [Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)

[<ta...@jt...>]

>  From: Damon Courtney <da...@tc...>
>  Date: Thu, 25 May 2006 16:26:55 -0500
>  
>      I guess it got fixed somewhere along the way.  I just test 1.7 in 
>  the latest ActiveTcl, and it works as expected.  Not sure what version 
>  Jason is using.

Your suspicions are correct -- what I have installed is /not/ what is in
CVS.  My development machine, Debian/testing, has the package
bwidget-1.7.0-1 and has an error in NoteBook::bindtabs.  On the line
that appends to script, it uses the index value of 2 instead of 1.

As a test, I searched for the latest bwidget package for Fedora Core 5.
The latest version found is bwidget-1.7.0-2.fc5
(http://tinyurl.com/gb4rs).  This package also has the errant index
value of 2 for [NoteBook::bindtabs].

-- 
Jason Tang  /  ta...@jt...  /  http://www.jtang.org/~tang

Re: [Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)

[Damon C. <da...@tc...>]

    I guess it got fixed somewhere along the way.  I just test 1.7 in 
the latest ActiveTcl, and it works as expected.  Not sure what version 
Jason is using.

Damon


Jeff Hobbs wrote:
> What is the bug?  I tested the bindtags operation, and it returned the 
> "expected" behavior.  Any modification would *introduce* a bug, IMO.  
> Please elaborate with a script.
>
>   Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/ 
> <http://www.activestate.com/>
>
>     -----Original Message-----
>     *From:* tcl...@li...
>     [mailto:tcl...@li...] *On Behalf Of
>     *Damon Courtney
>
>         This actually was a bug.  I'm not sure it's in CVS like that
>     or not, but I don't think fixing it would break others who are
>     expecting something wrong.  I think you're better off fixing it.
>
>     Damon
>
>
>     Jeff Hobbs wrote:
>>     J. Tang wrote:
>>       
>>>     There is an error in the latest stable version of BWidget 
>>>     NoteBook's bindtabs function.  It purports to append the page 
>>>     identifier to the script to be executed.  Examining the 
>>>     source code, NoteBook makes a call to 
>>>     NoteBook::_get_page_name that returns the tab's name *sans* 
>>>     first two characters.  Clearly something is amiss here.
>>>
>>>     Question: If I were to modify _get_page_name, I could 
>>>     potentially break all sorts of programs that have depended 
>>>     upon this unusual behavior.  Is the correct fix to deprecate 
>>>     bindtabs, introducing a new procedure without this behavior?
>>>         
>>
>>     I believe this is correct, and may relate to this old change:
>>
>>     2003-11-26  Jeff Hobbs  <je...@Ac...>
>>
>>     	* notebook.tcl (NoteBook::bindtabs): correct tab name returned.
>>     (groth)
>>
>>     When I do a test, I see that that the tag found is p:$realPageName, so it's
>>     appropriate to have the first 2 chars stripped.
>>
>>     Jeff
>

RE: [Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)

[Jeff H. <je...@ac...>]

What is the bug?  I tested the bindtags operation, and it returned the
"expected" behavior.  Any modification would *introduce* a bug, IMO.  =
Please
elaborate with a script.

  Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/=20

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...] On Behalf Of Damon =
Courtney


    This actually was a bug.  I'm not sure it's in CVS like that or not, =
but I
don't think fixing it would break others who are expecting something =
wrong.  I
think you're better off fixing it.

Damon


Jeff Hobbs wrote:=20

J. Tang wrote:

 =20

There is an error in the latest stable version of BWidget=20

NoteBook's bindtabs function.  It purports to append the page=20

identifier to the script to be executed.  Examining the=20

source code, NoteBook makes a call to=20

NoteBook::_get_page_name that returns the tab's name *sans*=20

first two characters.  Clearly something is amiss here.



Question: If I were to modify _get_page_name, I could=20

potentially break all sorts of programs that have depended=20

upon this unusual behavior.  Is the correct fix to deprecate=20

bindtabs, introducing a new procedure without this behavior?

   =20



I believe this is correct, and may relate to this old change:



2003-11-26  Jeff Hobbs   <mailto:je...@Ac...>
<je...@Ac...>



	* notebook.tcl (NoteBook::bindtabs): correct tab name returned.

(groth)



When I do a test, I see that that the tag found is p:$realPageName, so =
it's

appropriate to have the first 2 chars stripped.



Jeff

Re: [Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)

[Damon C. <da...@tc...>]

    This actually was a bug.  I'm not sure it's in CVS like that or not, 
but I don't think fixing it would break others who are expecting 
something wrong.  I think you're better off fixing it.

Damon


Jeff Hobbs wrote:
> J. Tang wrote:
>   
>> There is an error in the latest stable version of BWidget 
>> NoteBook's bindtabs function.  It purports to append the page 
>> identifier to the script to be executed.  Examining the 
>> source code, NoteBook makes a call to 
>> NoteBook::_get_page_name that returns the tab's name *sans* 
>> first two characters.  Clearly something is amiss here.
>>
>> Question: If I were to modify _get_page_name, I could 
>> potentially break all sorts of programs that have depended 
>> upon this unusual behavior.  Is the correct fix to deprecate 
>> bindtabs, introducing a new procedure without this behavior?
>>     
>
> I believe this is correct, and may relate to this old change:
>
> 2003-11-26  Jeff Hobbs  <je...@Ac...>
>
> 	* notebook.tcl (NoteBook::bindtabs): correct tab name returned.
> (groth)
>
> When I do a test, I see that that the tag found is p:$realPageName, so it's
> appropriate to have the first 2 chars stripped.
>
> Jeff
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel
>   

RE: [Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)

[Jeff H. <je...@ac...>]

J. Tang wrote:
> There is an error in the latest stable version of BWidget 
> NoteBook's bindtabs function.  It purports to append the page 
> identifier to the script to be executed.  Examining the 
> source code, NoteBook makes a call to 
> NoteBook::_get_page_name that returns the tab's name *sans* 
> first two characters.  Clearly something is amiss here.
> 
> Question: If I were to modify _get_page_name, I could 
> potentially break all sorts of programs that have depended 
> upon this unusual behavior.  Is the correct fix to deprecate 
> bindtabs, introducing a new procedure without this behavior?

I believe this is correct, and may relate to this old change:

2003-11-26  Jeff Hobbs  <je...@Ac...>

	* notebook.tcl (NoteBook::bindtabs): correct tab name returned.
(groth)

When I do a test, I see that that the tag found is p:$realPageName, so it's
appropriate to have the first 2 chars stripped.

Jeff

[Tcllib-devel] BWidget NoteBook bindtabs error (and RFC)

[<ta...@jt...>]

There is an error in the latest stable version of BWidget NoteBook's
bindtabs function.  It purports to append the page identifier to the
script to be executed.  Examining the source code, NoteBook makes a call
to NoteBook::_get_page_name that returns the tab's name *sans* first two
characters.  Clearly something is amiss here.

Question: If I were to modify _get_page_name, I could potentially break
all sorts of programs that have depended upon this unusual behavior.  Is
the correct fix to deprecate bindtabs, introducing a new procedure
without this behavior?

-- 
Jason Tang  /  ta...@jt...  /  http://www.jtang.org/~tang

[Tcllib-devel] Fuzzing the tcllib ftpd code

[Michael S. <sc...@un...>]

Hi all,

there was a recent posting on the bugtraq security mailing list about a
fuzz tool for ftp servers.
(http://www.infigo.hr/files/ftpfuzz.zip)

I tried it with the ftpd.test file in the demos directory of tcllib, and
it promptly managed to bring the server to a shutdown.
(one has to check the 'fuzz all selected command in one FTP session'
checkbox in the fuzz tool to make it work).

If someone with a bit more interest in the ftpd code would check if
there are security or other issues lurking in there, or what would be
good new test cases it would be nice.

Michael

[Tcllib-devel] Call For Papers: 13th Annual Tcl/Tk Conference, Oct. 9-13, 2006

[Tcl C. 2. <tc...@tc...>]

Tcl/Tk
 - radically simple  
 - radically flexible
 - radically powerful

Announcing the 13th Annual Tcl/Tk Conference

October 9-13, 2006
Naperville, Illinois USA

Learn from the experts, share your experience - the annual Tcl/Tk conference is 
your opportunity to engage with the Tcl/Tk core team and your fellow peers.

The conference program will include:
  * Presentations and tutorials
  * The (Active)State of Tcl talk by Tcl/Tk release manager Jeff Hobbs
  * Birds of a Feather (BOF) sessions
  * Invited key-note talks
  * Discussion forums with the Tcl/Tk core team

Call For Papers

You are invited and indeed encouraged to submit proposals for presentations and 
tutorials. The conference schedule will consist of 2 days of tutorials 
(Monday - Tuesday) and 3 days for the main conference (Wednesday - Friday).

The conference provides you an opportunity to report on original
research and applications of Tcl/Tk and related technology. The audience will 
consist of practitioners and researchers who are intermediate or experienced 
users of Tcl/Tk.  For this reason, reports on experiences and applications 
should draw out lessons for other Tcl/Tk developers.

Topics will include, but are not limited to:
  * Application of Tcl/Tk in industries as diverse as engineering,
      industrial controls, broadcasting, financial services,
      medical and electronic design
  * Networking with Tcl/Tk, including distributed applications and network
      management
  * New widgets and techniques for GUI design with Tk
  * Simulation and application steering with Tcl/Tk
  * Tcl/Tk on handheld and embedded devices
  * New Tcl extensions and add-ons, including Tcllib and Tklib
  * Tcl/Tk centric operating environments

Submission Guidelines

If you are interested in submitting a paper you should send an abstract of about
100 words and a summary of maximum two pages. Omit extraneous or redundant 
information. Length is not a direct factor in judging the quality of the 
submission.

If submitting a tutorial proposal you should send an outline of the tutorial and
a brief biography, and clearly indicate whether the tutorial is of half-day or 
full-day duration.

Send submissions as plain text to <tc...@tc...>  no later than May 31, 2006.

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

The program committee will review and evaluate papers according to
the following criteria:
  * Quantity and quality of novel content
  * Relevance and interest to the Tcl/Tk community
  * Suitability of content for presentation at the conference

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

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

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

Registration Information

More information on the conference will be available in Spring 2006
at the conference web site (http://www.tcl.tk/community/tcl2006/)
and published on various Tcl/Tk related information channels.

To keep in touch with conference announcements and Tcl events in
general, subscribe to the tcl-announce list at:
   http://listserv.activestate.com/mailman/mysubs?show=announce
by entering your email and selecting Tcl-announce.

Conference Committee

Cyndy Lilagan     Eolas Technologies              Facilities Coordination
Clif Flynt        Noumena Corp                    General Chair
Steve Redler IV   SR Technology                   Program Chair
Steve Landers     Digital Smarties                Program Co-chair
Kevin Kenny       GE Global Research Center
Jeffrey Hobbs     ActiveState
Andreas Kupries   ActiveState
Mike Doyle        Eolas Technologies
Ron Fox           NSCL Michigan State University
Donal Fellows     University of Manchester
Gerald Lester     HMS Software
Larry Virden      Tcl FAQ Maintainer

Contact Information

tc...@tc...
http://www.tcl.tk/community/tcl2006/

Re: [Tcllib-devel] logger, convenience command

[Hemang L. <hl...@ci...>]

Hi Andreas,

The logutil proc should also set the default level to "warn" for the new
service created:

	proc logutil {ns {level "warn"}} {
	    set service [string trimleft $ns :]
	    namespace eval $ns [list logger::init $service]
	    namespace eval $ns [list logger::import -force \
		      -all -namespace log $service]
            namespace eval $ns [list log::setlevel $level]
	    return
	}

Thanks,
Hemang.
Andreas Kupries wrote:
> Hi.
>
> Enclosed a tcl procedure I find very convenient to create a logger
> service coupled directly to a specific namespace. Service name and
> namespace name are identical (modulo :: for full qualification), and
> the log commands are directly acessible in the the namespace.
>
> 	_________________________________________________________
> 	proc logutil {ns} {
> 	    set service [string trimleft $ns :]
> 	    namespace eval $ns [list logger::init $service]
> 	    namespace eval $ns [list logger::import -force \
> 		      -all -namespace log $service]
> 	    return
> 	}
> 	_________________________________________________________
>
> Use
> 	namespace eval ::foo::bar::blech
> 	logutil        ::foo::bar::blech
>
> Right now I have this command in a mini package of its own, however I
> believe that having it in logger itself would be better. Haven't found
> a real good name for it yet however. So far only
>
> 	logger::initNamespace
> 	logger::setupServiceInNamespace
> 	...
>
> Other ideas and opinions ?
>
>   

[Tcllib-devel] logger, convenience command

[Andreas K. <aku...@sh...>]

Hi.

Enclosed a tcl procedure I find very convenient to create a logger
service coupled directly to a specific namespace. Service name and
namespace name are identical (modulo :: for full qualification), and
the log commands are directly acessible in the the namespace.

	_________________________________________________________
	proc logutil {ns} {
	    set service [string trimleft $ns :]
	    namespace eval $ns [list logger::init $service]
	    namespace eval $ns [list logger::import -force \
		      -all -namespace log $service]
	    return
	}
	_________________________________________________________

Use
	namespace eval ::foo::bar::blech
	logutil        ::foo::bar::blech

Right now I have this command in a mini package of its own, however I
believe that having it in logger itself would be better. Haven't found
a real good name for it yet however. So far only

	logger::initNamespace
	logger::setupServiceInNamespace
	...

Other ideas and opinions ?

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

[Tcllib-devel] config package, for option managment

[Georg L. <jor...@ma...>]

Hello!

After looking around for existing code for commandline and
configuration file processing I decided to wrap up a package by myself
to combine and simplify option managment.

The result is the 'config' package, which can be found and downloaded
at:

  http://www.magma.com.ni/moin/TclConfig

I would be happy to contribute this package to Tcllib, if you deem it
of interest.

To comply with the requisites I converted my notes to the doctools
format, and put the package under a double Licence: BSD and GPL.

You can find the individual files as attachments to the Wiki page.


Best Regards,

     Jorge-Le=F3n

[Tcllib-devel] Call For Papers: 13th Annual Tcl/Tk Conference, Oct. 9-13, 2006

[<aku...@sh...>]

Tcl/Tk
 - radically simple
 - radically flexible
 - radically powerful

Announcing the 13th Annual Tcl/Tk Conference

October 9-13, 2006
Naperville, Illinois USA

Learn from the experts, share your experience - the annual Tcl/Tk
conference is your opportunity to engage with the Tcl/Tk core team and
your fellow peers.

The conference program will include:
  * Presentations and tutorials
  * The (Active)State of Tcl talk by Tcl/Tk release manager Jeff Hobbs
  * Birds of a Feather (BOF) sessions
  * Invited key-note talks
  * Discussion forums with the Tcl/Tk core team

Call For Papers

You are invited and indeed encouraged to submit proposals for
presentations and tutorials. The conference schedule will consist of two
days of tutorials (Monday - Tuesday) and 3 days for the main
conference (Wednesday - Friday).

The conference provides you an opportunity to report on original
research and applications of Tcl/Tk and related technology. The
audience will consist of practitioners and researchers who are
intermediate or experienced users of Tcl/Tk.  For this reason, reports
on experiences and applications should draw out lessons for other
Tcl/Tk developers.

Topics will include, but are not limited to:

  * Application of Tcl/Tk in industries as diverse as engineering,
      industrial controls, broadcasting, financial services,
      medical and electronic design
  * Networking with Tcl/Tk, including distributed applications and network
      management
  * New widgets and techniques for GUI design with Tk
  * Simulation and application steering with Tcl/Tk
  * Tcl/Tk on handheld and embedded devices
  * New Tcl extensions and add-ons, including Tcllib and Tklib
  * Tcl/Tk centric operating environments

Submission Guidelines

If you are interested in submitting a paper you should send an
abstract of about 100 words and a summary of maximum two pages. Omit
extraneous or redundant information. Length is not a direct factor in
judging the quality of the submission.

If submitting a tutorial proposal you should send an outline of the
tutorial and a brief biography, and clearly indicate whether the
tutorial is of half-day or full-day duration.

Send submissions as plain text to <tc...@tc...> no later than May
31, 2006.

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

The program committee will review and evaluate papers according to
the following criteria:
  * Quantity and quality of novel content
  * Relevance and interest to the Tcl/Tk community
  * Suitability of content for presentation at the conference

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

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

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

Registration Information

More information on the conference will be available in Spring 2006 at
the conference web site (http://www.tcl.tk/community/tcl2006/) and
published on various Tcl/Tk related information channels.

To keep in touch with conference announcements and Tcl events in
general, subscribe to the tcl-announce list at:

   http://listserv.activestate.com/mailman/mysubs?show=announce

by entering your email and selecting Tcl-announce.

Conference Committee

Cyndy Lilagan     Eolas Technologies              Facilities Coordination
Clif Flynt        Noumena Corp                    General Chair
Steve Redler IV   SR Technology                   Program Chair
Steve Landers     Digital Smarties                Program Co-chair
Kevin Kenny       GE Global Research Center
Jeffrey Hobbs     ActiveState
Andreas Kupries   ActiveState
Mike Doyle        Eolas Technologies
Ron Fox           NSCL Michigan State University
Donal Fellows     University of Manchester
Gerald Lester     HMS Software
Larry Virden      Tcl FAQ Maintainer

Contact Information

tc...@tc...
http://www.tcl.tk/community/tcl2006/


--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] More file utilities ?

[Andreas K. <aku...@sh...>]

 
> Here is an updated proposal.

Having heard nothing anymore I implemented this and just committed it,
including updated testsuite and documentation.

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] Question about rshift for math::bignum

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

Lars Hellstr=F6m wrote:
>=20

>=20
> But your point is probably that math::bignum simply does not use such a
> two's complement representation, and therefore exhibits a different
> native shift behaviour.
>=20

It does not. It actually implements them in a 2**N-ary representation.

> > So, my question is:
> >
> > Should we strive to make rshift produce the _same_ results as Tcl's >=
>
> > operator?
>=20
> Since the future for math::bignum is likely to be to provide an option
> for backwards compatibility for the Tcl 8.5 built-in bignums, I think
> they should, yes.
>=20

Well, that is clear then. I was hoping for the easy answer, I must=20
admit :)

> > If so, how should we do this?
>=20
> Am I right in suspecting that the difference is that
> math::bignum::rshift in principle divides by a power of two and rounds
> towards 0, whereas >> in principle divides by a power of two and rounds
> downwards? In that case a fix would be to subtract 1 from the current
> math::bignum::rshift result if not all the out-shifted bits are zeroes.
>=20

Now, that is an interesting thought ... I haven't fathomed the effect=20
of this padding yet, but if we can translate it to so simple an
algorithm,
I am all for it.

Regards,

Arjen

Re: [Tcllib-devel] Question about rshift for math::bignum

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

torsdagen den 9 februari 2006 kl 09.15 skrev Arjen Markus:

> Now, this is fine with a fixed and finite number of bits that =
represent
> the integer,
> but the idea of bignum is that you have an arbitrary range for the
> integers. And there
> is no two's complement implementation of the sign.

It should perhaps be remarked here that there does exist a perfectly=20
valid two's complement implementation for arbitrary integers. Just as=20
one conceptually pads a non-negative number with an infinite sequence=20
of 0's on the left, one can view a negative number (in two's complement=20=

representation) as having an infinite sequence of 1's on the left.

But your point is probably that math::bignum simply does not use such a=20=

two's complement representation, and therefore exhibits a different=20
native shift behaviour.

> So, my question is:
>
> Should we strive to make rshift produce the _same_ results as Tcl's >>
> operator?

Since the future for math::bignum is likely to be to provide an option=20=

for backwards compatibility for the Tcl 8.5 built-in bignums, I think=20
they should, yes.

> If so, how should we do this?

Am I right in suspecting that the difference is that=20
math::bignum::rshift in principle divides by a power of two and rounds=20=

towards 0, whereas >> in principle divides by a power of two and rounds=20=

downwards? In that case a fix would be to subtract 1 from the current=20
math::bignum::rshift result if not all the out-shifted bits are zeroes.

Lars Hellstr=F6m=

[Tcllib-devel] Question about rshift for math::bignum

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

Hello all,

the math::bignum module implements a right bitshift operation for
arbitrary-size
integers. The problem is that the current version does not produce the
same
results as you get with Tcl's >> operator for negative numbers (See bug
#1098051 on SF). 

The problem, however, I encountered when trying to fix this bug is that
C's definition
of the operation uses the fact that signed integers are implemented via
two's-complement
bit patterns. The sign bit is used to pad the bit pattern that arises
with right 
shifting the bits.

Now, this is fine with a fixed and finite number of bits that represent
the integer,
but the idea of bignum is that you have an arbitrary range for the
integers. And there
is no two's complement implementation of the sign.

So, my question is:

Should we strive to make rshift produce the _same_ results as Tcl's >>
operator?
If so, how should we do this?

Regards,

Arjen

Re: [Tcllib-devel] More file utilities ?

[Andreas K. <aku...@sh...>]

Here is an updated proposal.

Overview:

*	get_file/readFile is gone, replaced by the existing 'cat'
	command, albeit extended (encodings, etc.).

*	The 'touch' command which confused everyone (also called
	'clear'), is gone as well.

*	The basic modifications of a file in place (insertion,
	removal, replacement of segments) are represented by their own
	commands (keeping memory usage down), everything else has to
	be expressed in terms of the 'updateInPlace' command Joe
	proposed after looking at the old 'hack*' commands.

Now for the descriptions ...

=================================================

Basic descriptions for a set of commands operating on whole files.

The recognized options are generally

    -encoding    ENC
    -translation TRA
    -eofchar     ECH
    --

where "--" forces the recognition of a file, even if its name start
with a dash. None of the options are required. Unspecified settings
use the system defaults of the channel.

=================================================

::fileutil::cat (?options? file)+

	Read all specified files, using the given options, and return
	a string containing the concatenated contents.

	Note: option settings persist between file names, i.e. when
	doing

		cat -encoding binary fileA fileB

	fileB will be read using the binary encoding as well.

	The specified paths have to exist, have to refer to files, and
	have to be readable.


::fileutil::writeFile ?options? file data

	Writes the data into the file, creating it if needed.

	If the specified path exists it has to refer to a writable
	file.

::fileutil::appendToFile ?options? file data

	Appends the data to the file.

	The specified path has to refer to an existing readable and
	writable file.

::fileutil::insertIntoFile ?options? file at data

	Insert the data into the file, at the offset.

	The specified path has to refer to an existing readable and
	writable file.

::fileutil::removeFromFile ?options? file at n

	Removes n characters from the file, starting at the given
	offset. Characters are counted as per the active encoding.

	The specified path has to refer to an existing readable and
	writable file.

::fileutil::replaceInFile ?options? file at n data

	A combination of 'removeFromFile' and
	'insertIntoFile'. Removes n characters from the file, starting
	at the given offset, and replaces them with the given data.

	The specified path has to refer to an existing readable and
	writable file.

	Semantics:
		removeFromFile path at n
		insertIntoFile path at data

::fileutil::updateInPlace ?options? file cmd

	Reads the contents of the file and passes it as an additional
	argument to the cmd (prefix). Overwrites the original file
	with the return value of the command. If the command raises an
	error, the original file is not modified.

	The specified path has to refer to an existing readable and
	writable file.

	The last three operations could be expressed in terms of
	updateInPlace. Their transforms are however so simple that a
	direct implementation is possible without loading the whole
	file into memory.

=================================================

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

RE: [Tcllib-devel] BWidget configuration/installation question

[Virden, L. W. <lv...@ca...>]

If you are going that far, why not just distribute it as a starkit that
could be placed itself into the appropriate directory so nothing had to
be extracted at all? Doesn't the new Tcl Module support provide for such
a thing?

--=20
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all
powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lv...@gm... > <URL: http://www.purl.org/NET/lvirden/
>
=20

-----Original Message-----
From:  Joe English


BWidget ought to not require a 'make install' step at all --
you should be able to just extract the tarfile in-place
(anywhere on $::auto_path) and it's ready to go.

Re: [Tcllib-devel] BWidget configuration/installation question

[Damon C. <da...@tc...>]

    Agreed.  I think the config / make stuff was always in there to try 
and create some kind of consistency with other packages.  Was there 
every defined a standard method for distributing Tcl-only extensions?  
TEA seems like overkill on something that just needs to be copied somewhere.

D


Joe English wrote:
> Larry Virdern wrote:
>
>   
>> When I fetch the cvs head tar file for bwidget from the activestate ftp
>> site, I understand why I need to run an autoconf to create the
>> configure.  But shouldn't bwidget include the config directory, with the
>> tcl.m4, install-sh, and mkinstalldirs scripts in them, if it requires
>> them to build the configure script and to install the code?
>>     
>
> BWidget ought to not require a 'make install' step at all --
> you should be able to just extract the tarfile in-place
> (anywhere on $::auto_path) and it's ready to go.
>
>
> --Joe English
>
>   jen...@fl...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel
>   

Re: [Tcllib-devel] BWidget configuration/installation question

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

Larry Virdern wrote:

> When I fetch the cvs head tar file for bwidget from the activestate ftp
> site, I understand why I need to run an autoconf to create the
> configure.  But shouldn't bwidget include the config directory, with the
> tcl.m4, install-sh, and mkinstalldirs scripts in them, if it requires
> them to build the configure script and to install the code?

BWidget ought to not require a 'make install' step at all --
you should be able to just extract the tarfile in-place
(anywhere on $::auto_path) and it's ready to go.


--Joe English

  jen...@fl...

[Tcllib-devel] BWidget configuration/installation question

[Virden, L. W. <lv...@ca...>]

When I fetch the cvs head tar file for bwidget from the activestate ftp
site, I understand why I need to run an autoconf to create the
configure.  But shouldn't bwidget include the config directory, with the
tcl.m4, install-sh, and mkinstalldirs scripts in them, if it requires
them to build the configure script and to install the code?

=20

Now, in cases like this, I normally get the files that are missing from
the sample directory tree, since it represents the latest TEA file
structure. However, bwidget requires mkinstalldirs, which is not in
sample. Sure, I can get it from one of the other extensions. But if it
isn't a requirement of TEA, does this represent a "bug" that I should
report on bwidget?

=20

Just curious. Thanks!

=20

--=20

Even if explicitly stated to the contrary, nothing in this posting

should be construed as representing my employer's opinions.

=20

RE: [Tcllib-devel] More file utilities ?

[<dg...@ni...>]

Quoting Andreas Kupries <and...@Ac...>:
> Heh. I have lots of places where I wrote 'getfile' and equivalent stuff to
> make things convenient. Also note that tcltest's 'makeFile' for example is
> 'putfile', just with different argument order.

Citing [::tcltest::makeFile] is a negative recommendation, in my opinion.
That command is about 80% a mistake.

Unless you're providing some really compelling syntactic sugar,
I don't see the point of a package providing commands that
duplicate commands that are already built-in to Tcl.

DGP

RE: [Tcllib-devel] More file utilities ?

[<dg...@ni...>]

Quoting Reinhard Max <ma...@tc...>:
> Wasn't it the default recommendation for library writers to use 
> qualified names instead of importing everything?

There are advocates for that recommendation.

There are also dissenters, like myself.

This isn't the thread to dissect the pros/cons, but wanted
to snuff the presumption that there's a settled "default"
recommendation.

DGP