file unsplit?
in [TCL]
|
From: Arndt Roger Schneider on 13 Sep 2009 08:49 Andreas Leitgeb schrieb: > Arndt Roger Schneider <arndt.roger(a)web.de> wrote: > >>On concat: concat takes two forms one working on >>strings the other on lists, If the first argument >>is a list, then the list form is being aplied. > > > No, only if *all* the arguments are pure lists, then the > result also will be one, otherwise not. Correct. As stated in the man-page. > > e.g: > concat [list foo bar] \; > > >>It seems to be faster than linsert, too. >>And is better readable than linsert. Concat is slower and the reasons are obvious (~50%), too. First the inner list must be evaluated and then concat has to test whether the arguments are lists or strings. eval versus if 1 has no effect on the evaluation time. eval produces better radable code than if 1. [snip] -roger
From: Andreas Leitgeb on 13 Sep 2009 11:53 Arndt Roger Schneider <arndt.roger(a)web.de> wrote: > eval versus if 1 has no effect on the > evaluation time. This is not supported by the experiment I posted recently.
From: Hai Vu on 15 Sep 2009 01:09 On Sep 11, 2:36 am, Jonathan Bromley <jonathan.brom...(a)MYCOMPANY.com> wrote: > This is probably a painfully basic question, sorry. > > We have [file split] and [file join] for all the > right reasons. But what should I do if I want the > inverse operation of [file split], i.e. reassemble > a list of path components into a platform-appropriate > pathname? > > Given > set components [file split $original_path] > here are some attempts, none of which really satisfies me: > > set newpath [eval file join $components] > # I don't like eval very much.... > > set newpath [join $components [file separator]] > # is this really safe? Duplicated separators??? > > set newpath {} > foreach piece $components { > set newpath [file join $newpath $piece] > } > # looks clumsy, probably quite slow > > set newpath [file join {*}$components] > # probably best, but usually I'm stuck with Tcl 8.4 > > Is there something simple and obvious I've missed? > > Thanks in advance > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...(a)MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Another way to skin the cat: eval [concat file join $components]
From: Arndt Roger Schneider on 15 Sep 2009 12:24 Andreas Leitgeb schrieb: > Arndt Roger Schneider <arndt.roger(a)web.de> wrote: > >>eval versus if 1 has no effect on the >>evaluation time. > > > This is not supported by the experiment I posted recently. Hmmh, interesting. I 've altered your testcase somewhat to run it under 8.4: proc xx1 { } { set x [list a b c] for {set i 0} { $i < 12345 } { incr i } { eval [list set x [linsert $x 0 "$i"]] } } proc xx2 { } { set x [list a b c] for {set i 0} { $i < 12345 } { incr i } { if 1 [list set x [linsert $x 0 "$i"]] } } eval: 3134003 microseconds per iteration if 1:148357603 microseconds per iteration My former test was directly on the prompt --not inside a proc. So apparently the "byte compiled" version of "if 1" is significant slower than eval. -roger
From: Andreas Leitgeb on 15 Sep 2009 12:44
Hai Vu <wuhrrr(a)gmail.com> wrote: > Another way to skin the cat: > eval [concat file join $components] For the record: this is exactly as slow and potentially unsafe as eval file join $components concat doesn't "sanitize" lists the way linsert,lrange,... do. (and it's not a bug: concat isn't supposed to do that) I can't think of any situation, where using explicit [concat ...] directly for eval arguments makes any difference to letting eval do the concatting itself. |