proc named "#"

[Jay]

Is there a way to define proc named "#"; In other words: Can I define

proc # {args} { puts $args }

Defining above proc does not produce any error. However, when
executing # as command, interpreter still treats as comment line

% proc # {args} {puts [lindex $args 0]}
% info body #
puts [lindex $args 0]

Good.. now let me execute # as command
% # blah blah1


----nothing returned.. Ok.. Let me eval w/ []...
% puts [# blah blah1]
]

----looks like I need to have eol and then close ].. still # is
interpreted as comment line and not as proc #

:(

Jay

[George Petasis]

\# blah blah1

George

[Uwe Klein]

% proc # {} {puts hallo}
% #
% {#}
hallo
% \#
hallo
% set do #
#
% $do
hallo
% "#"
hallo

probably is not exhaustive

uwe

[Jay]

Ah... that works.. Thanks for the trick.

Let me ask differently: Is there a way to rename comment line
character "#" to something else, so that I do not need to \#, or "#",,
Reason is that I have a huge file containing # <some specific comment>
as a delimiting section of data. I want to process this report by
doing..

here is ex of file..

# type2
data1 129 129s 838R....
data2 abce 939fix
blah x x x x I dont care

-------
proc unknown {} {}
proc data1 {args} {do something}
proc data2 {args} {do somethingelse}
..
..
proc # {args} {dosometing_based_on_<some specific comment>}

% source myreport

Your trick requires to modify the report file

[Aric Bills]

I think comment processing is hard-wired into Tcl, but unless your report is ridiculously huge, it shouldn't be a big deal to modify your report data (without modifying your report file). How about something like this:

set file [open myreport]
set reportdata [read $file]
close $file
eval [regsub -all {(^|\n)#} $reportdata "\\1\\#"]

[Ralf Fassel]

* Jay <apna...@gmail.com>

| Let me ask differently: Is there a way to rename comment line
| character "#" to something else, so that I do not need to \#, or "#",,
| Reason is that I have a huge file containing # <some specific comment>
| as a delimiting section of data. I want to process this report by
| doing..

--<snip-snip>--
| % source myreport

Do you control the contents of this file? If not, I'd strongly advice
against simply sourcing the file. Sourcing (=executing) unknown data
opens a huge security hole.

while {[gets $fd line] >= 0} {
set line [string trim $line]
switch -glob -- $line {
#* {
# process comment line
}
data1\ * {
# process data1 line
}
data2\ * {
# process data2 line
}
default {
# ...
}
}
}

R'

[Donal K. Fellows]

On 30/05/2012 08:33, Ralf Fassel wrote:
> Do you control the contents of this file? If not, I'd strongly advice
> against simply sourcing the file. Sourcing (=executing) unknown data
> opens a huge security hole.

It also means that if there's an unbalanced brace or bracket or double
quote (something that's quite easy to encounter in non-systematic data)
then you get all sorts of bad excitement. If it's a format that you can
do some simple parsing of instead (e.g., with [scan]) that's much easier.

Donal.

[Jay]

Thanks for the comments. And I agree security risk of sourcing unknown
data file.

In my case data file is huge.. I mean really huge.. could be more than
20gb .gz compressed text data. Data is structured and considered safe
and free of unbalanced "enclosing" characters. My initial attempt to
while {[gets $fd line]>=0} {} could not process full file because of
some stack overflow in 32bit tclsh.

I want to try something new w/ tcl and keep it simple...

I have sourced this file with about ten or so procs...

proc unknown {} {}
proc data1 {args} {do something}
proc data2 {args} {do somethingelse}
..

and it seems to work.. However, proc data1, proc data2 etc.. behavior
needs to change depending on keywords in comment line.

And hence idea of proc # such that global state machine can be coded
to alter data1, data2 behavior....

Oh well...

Jay

[Alexandre Ferrieux]

Note that the dangerous-but-oh-so-handy idiom of evaluating the data
as Tcl code can also be used in stream mode instead of sourcing the
huge file:

set ff [open $datafile r]
set accu ""
while {[gets $ff line]>=0} {
append accu $line\n
if {![info complete $accu]} continue
# do some preprocessing here (like transliterating comments)
eval $accu
set accu ""
}
close $ff

-Alex

[Andreas Leitgeb]

Jay <apna...@gmail.com> wrote:
> In my case data file is huge.. I mean really huge.. could be more than
> 20gb .gz compressed text data. Data is structured and considered safe
> and free of unbalanced "enclosing" characters. My initial attempt to
> while {[gets $fd line]>=0} {} could not process full file because of
> some stack overflow in 32bit tclsh.

You must have been quite close to a working solution then.
Probably just a bug, that we could help you spot, if you
post your initial attempt.

A while-loop as such would never make the stack overflow,
so it must have been something in the body of the loop.
Maybe you called the procedure doing the while from within it?

[Andreas Leitgeb]

Jay <apna...@gmail.com> wrote:
> In my case data file is huge.. I mean really huge.. could be more than
> 20gb .gz compressed text data. Data is structured and considered safe
> and free of unbalanced "enclosing" characters. My initial attempt to
> while {[gets $fd line]>=0} {} could not process full file because of
> some stack overflow in 32bit tclsh.

[Donal K. Fellows]

On 31/05/2012 03:22, Jay wrote:
> In my case data file is huge.. I mean really huge.. could be more than
> 20gb .gz compressed text data. Data is structured and considered safe
> and free of unbalanced "enclosing" characters. My initial attempt to
> while {[gets $fd line]>=0} {} could not process full file because of
> some stack overflow in 32bit tclsh.

Hmm, well you certainly cannot just [source] a script that large. One of
the lesser-known restrictions of Tcl is that no data object[*] can get
larger than 2GB at present, even on a 64-bit system (it's also true on a
32-bit system, but feels like less of a restriction there). This is due
to what is perhaps the oldest standing open Tcl bug (assigned to me too)
and it's all tangled up in the use of types across a lot of Tcl's C API
so fixing it is very disruptive. :-(

The [source] command is actually pretty dumb though; it just reads the
whole file into memory and then does (in effect) an [eval] on it.
Reading a bit at a time and evaluating that will work better.

Donal.
[* Technically, our memory allocator can't allocate anything longer than
2GB and many string functions are limited there too. ]