How do I....
Will Coleda
wondering:
- There's a sprintf opcode. Is there a way to do a scanf?
- is there an ETA on rx_compile? I hesitate to write my own RE compiler
having already dealt with tcl and tcl's [expr] ^_^
- Did exception handling ever get fixed? (I had submitted a test case
ages past - Last I saw was Leo saying "patches welcome". It was a COW
bug, IIRC.)
- Unicode?
- I was told ages past that I should use "global" for tcl's global
variables to play nice with others... What is the "right" way to store
my interpreter's global state, then? (for example, I have a global
PerlHash that maps command names to the builtin functions). I suppose I
could create my own pad, or even an object... but then how do I access
it without storing it in a global?
--
Will "Coke" Coleda will at coleda
dot com
Leopold Toetsch
> Going through my todo (hurm, should make TODO) list for Tcl, I'm
> wondering:
> - There's a sprintf opcode. Is there a way to do a scanf?
No not yet.
> - is there an ETA on rx_compile? I hesitate to write my own RE compiler
> having already dealt with tcl and tcl's [expr] ^_^
I'd like to know that too.
> - Did exception handling ever get fixed? (I had submitted a test case
> ages past - Last I saw was Leo saying "patches welcome". It was a COW
> bug, IIRC.)
The COW bug is fixed. Using exceptions should work.
> - Unicode?
Needs a lot of work still.
> - I was told ages past that I should use "global" for tcl's global
> variables to play nice with others... What is the "right" way to store
> my interpreter's global state, then?
Well just use the global ops.
global "tcl_globals" = the_hash # store
..
pref = global "tcl_globals" # fetch
> PerlHash that maps command names to the builtin functions). I suppose I
> could create my own pad, or even an object... but then how do I access
> it without storing it in a global?
Pads are for lexicals inside subroutines. Using an object or an hash
doesn't differ, you have to store it somewhere (or pass it around).
Why not just use the global opcodes?
leo
Will Coleda
On Tuesday, March 16, 2004, at 02:01 AM, Leopold Toetsch wrote:
> Will Coleda <wi...@coleda.com> wrote:
>
>> - Did exception handling ever get fixed? (I had submitted a test case
>> ages past - Last I saw was Leo saying "patches welcome". It was a COW
>> bug, IIRC.)
>
> The COW bug is fixed. Using exceptions should work.
>
Very good, thanks. That'll let me get associative arrays finished up.
>> - I was told ages past that I should use "global" for tcl's global
>> variables to play nice with others... What is the "right" way to store
>> my interpreter's global state, then?
>
> Well just use the global ops.
>
> global "tcl_globals" = the_hash # store
> ..
> pref = global "tcl_globals" # fetch
>
>> PerlHash that maps command names to the builtin functions). I suppose
>> I
>> could create my own pad, or even an object... but then how do I access
>> it without storing it in a global?
>
> Pads are for lexicals inside subroutines. Using an object or an hash
> doesn't differ, you have to store it somewhere (or pass it around).
>
> Why not just use the global opcodes?
>
> leo
>
Because global variables in tcl are different than global state
internal to my interpreter, and it would probably be sporting of me to
only expose the variables defined in the language, rather than those
used internally by the bytecode - so, if global opcodes are the way to
store global language variables, then I need a way to hide my private
data.
My initial thought had been that tcl's "global" was really more like
outermost lexical scope, so I was going to blissfully continue using
"global" for my personal junk, but the respondent seemed to think this
was not a good thing for interoperability.
Jens Rieks
On Tuesday 16 March 2004 08:49, Will Coleda wrote:
> On Tuesday, March 16, 2004, at 02:01 AM, Leopold Toetsch wrote:
> > Well just use the global ops.
> >
> > global "tcl_globals" = the_hash # store
> > ..
> > pref = global "tcl_globals" # fetch
> >
[snip]
> >
> > Why not just use the global opcodes?
> >
> > leo
>
> Because global variables in tcl are different than global state
> internal to my interpreter, and it would probably be sporting of me to
> only expose the variables defined in the language, rather than those
> used internally by the bytecode - so, if global opcodes are the way to
> store global language variables, then I need a way to hide my private
> data.
You can also use another namespace:
store_global "TCL::InternalData", "globals", the_hash
...
find_global the_hash, "TCL::InternalData", "globals"
Using special ASCII characters in the name might also avoid accidental access
of "your globals".
> My initial thought had been that tcl's "global" was really more like
> outermost lexical scope, so I was going to blissfully continue using
> "global" for my personal junk, but the respondent seemed to think this
> was not a good thing for interoperability.
>
>
> --
> Will "Coke" Coleda will at coleda
> dot com
jens
James Mastros
>>Because global variables in tcl are different than global state
>>internal to my interpreter, and it would probably be sporting of me to
>>only expose the variables defined in the language, rather than those
>>used internally by the bytecode - so, if global opcodes are the way to
>>store global language variables, then I need a way to hide my private
>>data.
>
> You can also use another namespace:
> store_global "TCL::InternalData", "globals", the_hash
> ...
> find_global the_hash, "TCL::InternalData", "globals"
> Using special ASCII characters in the name might also avoid accidental access
> of "your globals".
introspection versus "standard" TCL.
("It's not a bug, it's a feature!")
-=- James Mastros
Jens Rieks
> On Tuesday, March 16, 2004 7:32 AM, Jens Rieks wrote:
> > You can also use another namespace:
> > store_global "TCL::InternalData", "globals", the_hash
> > ...
> > find_global the_hash, "TCL::InternalData", "globals"
>
> and 'find_global'? i can see the logic for either way, but a different
> argument list for each is inconsistant, and a bit confusing.
I had the same problem too, but I finally found out that it is consistent with
the rest of the ops. The fist argument is an OUT for ops that return
something; all parameter are IN for ops that "store" something (or are doing
other things).
"OUT" examples:
add OUT, IN, IN
open OUT, IN, IN
read OUT, IN, IN
newsub OUT, IN, IN
getprop OUT, IN, IN
"IN" examples:
store_global( in STR, in STR, in PMC)
setprop( in STR, in STR, in PMC)
compreg(in STR, in PMC)
unless(in INT, inconst INT)
setp_ind(in INT, in PMC)
set_encoding(in STR, in INT)
> i know that store_global and find_global are new, and they aren't listed in
> ops.num yet, so modifying one of their signatures shouldn't affect too much
> code.
>
> where would i go about finding more info on this? i'm source diving now,
> but it's a deep pool and i'm not a very good swimmer yet. i'd like to
> submit a patch (if needed), or at least where a patch may make changes to
> this functionality.
>
> --jerry
jens
Jerry Gay
> You can also use another namespace:
> store_global "TCL::InternalData", "globals", the_hash
> ...
> find_global the_hash, "TCL::InternalData", "globals"
is there a good reason why the signatures are different for 'store_global'
and 'find_global'? i can see the logic for either way, but a different
argument list for each is inconsistant, and a bit confusing.
i know that store_global and find_global are new, and they aren't listed in
ops.num yet, so modifying one of their signatures shouldn't affect too much
code.
where would i go about finding more info on this? i'm source diving now, but
it's a deep pool and i'm not a very good swimmer yet. i'd like to submit a
patch (if needed), or at least where a patch may make changes to this
functionality.
--jerry
**************************************************************************
This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited. Thank you
for your compliance.
Leopold Toetsch
> On Tuesday, March 16, 2004 7:32 AM, Jens Rieks wrote:
>> You can also use another namespace:
>> store_global "TCL::InternalData", "globals", the_hash
>> ...
>> find_global the_hash, "TCL::InternalData", "globals"
> is there a good reason why the signatures are different for 'store_global'
> and 'find_global'? i can see the logic for either way, but a different
> argument list for each is inconsistant, and a bit confusing.
The 2 argument version of {store,find}_global was adjusted to have the
current ordering of data +12 months ago IIRC. The 3 argument forms are
extenstions, which you could read similar to:
store_global namespace [ var ], Pvar
find_global PRes, namespace [ var ]
> i know that store_global and find_global are new,
No, not really. Only the 3 argument form is new.
> and they aren't listed in > ops.num yet,
They are listed in ops.num #1374 - #1385 since quite a time.
> where would i go about finding more info on this?
docs/ops/var.pod
> ... i'd like to submit a
> patch (if needed),
No patches needed. Argument ordering is fine and consistent.
> --jerry
leo
Jerry Gay
> > and they aren't listed in > ops.num yet,
>
> They are listed in ops.num #1374 - #1385 since quite a time.
>
this morning i performed a 'cvs co parrot' and ran make (win32 - msvc,)
which generated the following information, leading to my statement above:
cl -nologo -Gf -W3 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
-ZI -I./include -DHAS_JIT -DI386 xx.obj -c xx.c
D:\usr\local\perl580\bin\perl.exe build_tools\ops2pm.pl
ops/core.ops ops/bit.ops ops/cmp.ops ops/debug.ops ops/dotgnu.ops ops/io.ops
ops/math.ops ops/object.ops ops/pmc.ops ops/rx.ops ops/set.ops ops/stack.ops
ops/string.ops ops/sys.ops ops/var.ops
addparent_p_p 1364 not mentioned in ops.num
removeparent_p_p 1365 not mentioned in ops.num
addattribute_p_s_s 1366 not mentioned in ops.num
addattribute_p_sc_s 1367 not mentioned in ops.num
addattribute_p_s_sc 1368 not mentioned in ops.num
addattribute_p_sc_sc 1369 not mentioned in ops.num
store_global_s_s_p 1370 not mentioned in ops.num
store_global_sc_s_p 1371 not mentioned in ops.num
store_global_s_sc_p 1372 not mentioned in ops.num
store_global_sc_sc_p 1373 not mentioned in ops.num
store_global_p_s_p 1374 not mentioned in ops.num
store_global_p_sc_p 1375 not mentioned in ops.num
find_global_p_s_s 1376 not mentioned in ops.num
find_global_p_sc_s 1377 not mentioned in ops.num
find_global_p_s_sc 1378 not mentioned in ops.num
find_global_p_sc_sc 1379 not mentioned in ops.num
find_global_p_p_s 1380 not mentioned in ops.num
find_global_p_p_sc 1381 not mentioned in ops.num
D:\usr\local\perl580\bin\perl.exe build_tools\ops2c.pl C
--core
D:\usr\local\perl580\bin\perl.exe build_tools\ops2c.pl
CPrederef --core
D:\usr\local\perl580\bin\perl.exe build_tools\ops2c.pl
CSwitch --core
i'm probably reading that wrong, but i figured that meant find_global and
store_global weren't in ops.num. now that i look in ops.num, i see
find_global_p_s 1235
find_global_p_sc 1236
but some ops do indeed seem to be missing.
if putting them in is as easy as
running patch against ops/ops.num with:
1391,1409d1390
< addparent_p_p 1364
< removeparent_p_p 1365
< addattribute_p_s_s 1366
< addattribute_p_sc_s 1367
< addattribute_p_s_sc 1368
< addattribute_p_sc_sc 1369
< store_global_s_s_p 1370
< store_global_sc_s_p 1371
< store_global_s_sc_p 1372
< store_global_sc_sc_p 1373
< store_global_p_s_p 1374
< store_global_p_sc_p 1375
< find_global_p_s_s 1376
< find_global_p_sc_s 1377
< find_global_p_s_sc 1378
< find_global_p_sc_sc 1379
< find_global_p_p_s 1380
< find_global_p_p_sc 1381
then please consider converting this to a proper patch and applying it. i'm
having a little trouble right now at the moment with my wincvs install, so i
can't get this formatted in the preferred diff format.
i hope this helps.
Leopold Toetsch
> thanks all for the clarifications...
>> > and they aren't listed in > ops.num yet,
>>
>> They are listed in ops.num #1374 - #1385 since quite a time.
>>
> this morning i performed a 'cvs co parrot' and ran make (win32 - msvc,)
> which generated the following information, leading to my statement above:
> addparent_p_p 1364 not mentioned in ops.num
Well, then something is hosed on your system. Last op is currently:
decodelocaltime_p_ic 1393
Do you have r/o files in your tree? Wrong permissions?
leo