Porting to the Tcl 8.0 object interface 
Author Message
 Porting to the Tcl 8.0 object interface

Fellow extension developers,

I believe the best way we can thank the Sun Tcl team for the 8.0 on-the-fly
compiler is to port our extensions to the object interface as quickly as
possible.  This will not only speed up the extensions, but help flush out
problems Tcl 8.0 while its still in alpha.

Once the basic mechanism is figured out, its goes pretty smoothly.  The biggest
problem is the need for procedures to do common tasks:

   o Lack of operations on the object result, in particular no equivalent to
     Tcl_AppendResult.  This has been one of the biggest pains.
     TclSetObjResultFromString is very useful, but is not an exported procedure
     and only takes one string.

   o Tcl_GetStringFromObj requires a pointer to a length, although this is
     often not used.  Allowing NULL would be useful.

   o There is a Tcl_ExprBooleanObj, but no object interface for longs or
     doubles.

Please start porting while its in alpha and get your enhancements in to
our friends at Sun Labs...

Mark



Fri, 11 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface

|>
|> Fellow extension developers,
|>
|> I believe the best way we can thank the Sun Tcl team for the 8.0 on-the-fly
|> compiler is to port our extensions to the object interface as quickly as
|> possible.  This will not only speed up the extensions, but help flush out
|> problems Tcl 8.0 while its still in alpha.

Yes, please.  The sooner we find out about problems, the sooner we can
fix them.  Once 8.0 goes final it will be much harder to fix problems that
require API changes.

|> Once the basic mechanism is figured out, its goes pretty smoothly.  The biggest
|> problem is the need for procedures to do common tasks:
|>
|>    o Lack of operations on the object result, in particular no equivalent to
|>      Tcl_AppendResult.  This has been one of the biggest pains.
|>      TclSetObjResultFromString is very useful, but is not an exported procedure
|>      and only takes one string.

The result is now an object just like any other Tcl object, so you can use
any of the procedures that manipulate string objects, such as
Tcl_StringObjAppend (use Tcl_GetObjResult to get the result object).

|>    o Tcl_GetStringFromObj requires a pointer to a length, although this is
|>      often not used.  Allowing NULL would be useful.

Sounds reasonable.

|>    o There is a Tcl_ExprBooleanObj, but no object interface for longs or
|>      doubles.

Also sounds reasonable.



Fri, 11 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface

Quote:


>  |>
>   |> Fellow extension developers,
>   |>
>   |> I believe the best way we can thank the Sun Tcl team for the 8.0 on-the-fly
>   |> compiler is to port our extensions to the object interface as quickly as
>   |> possible.  This will not only speed up the extensions, but help flush out
>   |> problems Tcl 8.0 while its still in alpha.

>   Yes, please.  The sooner we find out about problems, the sooner we can
>   fix them.  Once 8.0 goes final it will be much harder to fix problems that
>   require API changes.

I have been working on a Tcl 8.0 module for SWIG that uses the new object
interface throughout (including using a new Tcl object type for holding
SWIG's type-checked pointers).   With any luck I hope to have that
available within a week for people to play with... of course, all
of this is super-experimental :-).

I have a few initial impressions about the new object interface :

     1.   Performance seems good.  For a simple example involving lots of
          calls to C code I got the following :

                        Tcl 7.6            :  32.8 sec
                        Tcl 8.0 (strings)  :  22.3 sec
                        Tcl 8.0 (objects)  :  7.5 sec  ( ~200% speedup over strings)

     2.  Creating new Tcl objects was much easier than I thought it would
         be.  In fact, once I got the code to compile, it worked on the first
         try.   Nice job!

     3.  Retrieving values from Tcl_Obj's is a little weird (especially for
         floats).   I don't think it is at all intuitive that a GetObj operation
         should mutate the original object into some other kind of object.
         Where I've run into problems is with extension functions that take
         double precision values like this (roughly):

         my_function(...) {
               Tcl_GetDoubleFromObj(...);
               ...
         }

         If you do this and then write the following script, it will die :

         # Weird Tcl script
         my_function(1)
         set i 1          
         incr i 1         # This fails because 'i' has somehow turned into a double

         To get around these problems, I've have to write wrapper code like this :

         my_function(...) {
               newobj = Tcl_DuplicateObj(...)
               Tcl_GetDoubleFromObj(newobj)
               ...
         }

         Having to make a duplicate of every floating point object before trying to
         grab its value seems really bizarre to me--not to mention the fact that it
         slows things down.

         This problem could probably be fixed if there were some way to extract
         numerical values from Objects without having the object mutate into a
         new type.   I'm not sure how easy adding this would be however. Perhaps
         having some sort of call like this :

                     Tcl_GetAsDouble(Tcl_Interp, Tcl_Obj, double *val)

         that does the same thing as Tcl_GetDoubleFromObj, but leaves the object
         unchanged would work.  

     4.  I second the idea of allowing "NULL" to be used as the length parameter for
         String operations that return a length.  Most of the time I'm working with
         null-terminated strings and just end up throwing away the length value.

Otherwise, I really like the new interface.  Seems fast and is actully easy to
understand (although the 'double' handling is a little oddball).  

Cheers,

Dave
----------------------------------------------------------------
Dave Beazley
Department of Computer Science
University of Utah
Salt Lake City, Utah  84112

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



Sat, 12 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface


Quote:

>     3.  Retrieving values from Tcl_Obj's is a little weird (especially for
>         floats).   I don't think it is at all intuitive that a GetObj
>         operation should mutate the original object into some other kind of
>         object.

I agree.  We have tests in our working Extended Tcl 8.0 alpha build failing
tests in a number of places because of things like 022 turning into 18.0
automagically.

It may be too late at this point, but if it's not too much work I think that
the lazy conversion of a string into, say, an integer, should not invalidate
the string value unless a new value is stored into the object through an
interface such as Tcl_SetIntObj, Tcl_SetDoubleObj, etc, (i.e. a non-string
interface) and if I ask for the string value out, if the string value is in
there as valid (even if I last looked at the object as an integer or a double
or whatever, so the binary value is also valid), I get the string value back.

Another scenario where this would be important would be if someone decided
to make compiled regular expressions an object type.  This would be cool.
But I don't think you can easily turn a compiled regular expression back into
a textual one, so the way things work right now, your binary regexp type would
have to include a pointer to the compiled expression and a pointer to a copy
of the source expression, so that if you were asked to produce the string
form the binary data, you'd have a way to, which would be to look it up from
our hidden copy and stuff it back into the string pointer in an appropriate
way.
--
"Egon, this reminds me of the time you
 were going to drill a hole in your head."
                                        "That would have worked if you
                                         hadn't stopped me."



Sat, 12 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface



|> >     3.  Retrieving values from Tcl_Obj's is a little weird (especially for
|> >         floats).   I don't think it is at all intuitive that a GetObj
|> >         operation should mutate the original object into some other kind of
|> >         object.
|>
|> I agree.  We have tests in our working Extended Tcl 8.0 alpha build failing
|> tests in a number of places because of things like 022 turning into 18.0
|> automagically.
|>
|> It may be too late at this point, but if it's not too much work I think that
|> the lazy conversion of a string into, say, an integer, should not invalidate
|> the string value unless a new value is stored into the object.

Brian and I were just talking about this yesterday, and we agree that the
current behavior is a bug.  The semantics of Tcl need to be defined by the
string value of each object, and conversions among the internal representations
need to preserve the string value.  This isn't happening in the case
mentioned above; we'll fix it.



Sat, 12 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface



: >     3.  Retrieving values from Tcl_Obj's is a little weird (especially for
: >         floats).   I don't think it is at all intuitive that a GetObj
: >         operation should mutate the original object into some other kind of
: >         object.

: I agree.  We have tests in our working Extended Tcl 8.0 alpha build failing
: tests in a number of places because of things like 022 turning into 18.0
: automagically.

: It may be too late at this point, but if it's not too much work I think that
: the lazy conversion of a string into, say, an integer, should not invalidate
: the string value unless a new value is stored into the object through an
: interface such as Tcl_SetIntObj, Tcl_SetDoubleObj, etc, (i.e. a non-string
: interface) and if I ask for the string value out, if the string value is in
: there as valid (even if I last looked at the object as an integer or a double
: or whatever, so the binary value is also valid), I get the string value back.

Hi Karl,

Your suggestion is one of the fixes in the patch I posted earlier today
to the posting "Possible bug in new 8.0 C API" by David Beazley. This bug
was pretty tricky. There were actually three problems: 1) I was too eager
to convert Tcl objects from one internal representation to another,
2) I wasn't generating a valid string representation for compiler-created
integer objects before converting them to another type, and 3) I wasn't
duplicating a valid string representation when copying an object. The
patch will fix the magical tran{*filter*}ing of numbers.

  Brian



Sat, 12 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface

As 1996 draws to a close, I'd just like to say that I have never been more
e{*filter*}d about Tcl and Tk, their prospects, and their significance to computer
users worldwide.

I am very thankful that John took the time to email a prerelease of Tcl 1.0
to me back around 1988 or so.

I am also thankful to everyone who has contributed to making Tcl a success...
John, his students, and colleagues... all of the extension developers...  the
FAQ maintainers...  and everyone who gave of their time to help someone by
answering a question, looking for a bug, and so on...

I am also extremely grateful to Sun Microsystems for funding the development
of some of the most important work ever done on Tcl, such as the Windows and
Mac ports, the bytecode compiler, enhancing and bringing Safe Tcl and Safe Tk
into the core, the new I/O and event systems, and more, and for their wonderful
decision to make these enhancements available, with source code, to the public.

The continued development and enhancement of Tcl/Tk has been one of the net's
most successful collaborative projects, and the cooperativeness, lack of
cantankerousness, and steady progress made by the online Tcl developer
community sets a standard to which few other such projects can favorably
compare.  

John's continuing presence and involvement in Tcl has provided a beacon for
all of us to rally around, keeping Tcl from degenerating into a bunch of
incompatible dialects, and his excellent instincts and careful stewardship
of the core for all these years has kept the implementation open, clean, and
continually improving.

My professional reputation, to the extent that I have one, has come almost
entirely from my work on Tcl.  I confess that I *did* imagine, back when we
first got Tcl up on an Intel '286, that Tcl could become very important.
Today I feel giddy whenever I think about the incredible distance Tcl has
come since Tcl 1.0, in quality, capabilities, and its broad acceptance and
use worldwide.

1996 ends with developers just beginning to grapple with, understand, and
integrate the many new and terrific capabilities of Tcl and Tk version 8.  

Thanks again to everyone involved...  1997 is shaping up to be a very, very
good year...

Regards,

Karl Lehenbauer
--
"Egon, this reminds me of the time you
 were going to drill a hole in your head."
                                        "That would have worked if you
                                         hadn't stopped me."



Sat, 12 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface



Quote:
>Once the basic mechanism is figured out, its goes pretty smoothly.  The biggest
>problem is the need for procedures to do common tasks:
[snip]
>   o Tcl_GetStringFromObj requires a pointer to a length, although this is
>     often not used.  Allowing NULL would be useful.

    I may be off here, since I haven't tried 8.0 yet. But if the new
interface really does allow imbedded NUL characters in Tcl strings, it would
seem that treating the returned string as a C-style NUL-terminated string
would be a lurking bug in most cases. Won't the length pretty much *always*
be needed now?
    Jon



Sat, 12 Jun 1999 03:00:00 GMT  
 Porting to the Tcl 8.0 object interface

Quote:



> >Once the basic mechanism is figured out, its goes pretty smoothly.  The biggest
> >problem is the need for procedures to do common tasks:
> [snip]
> >   o Tcl_GetStringFromObj requires a pointer to a length, although this is
> >     often not used.  Allowing NULL would be useful.

>     I may be off here, since I haven't tried 8.0 yet. But if the new
> interface really does allow imbedded NUL characters in Tcl strings, it would
> seem that treating the returned string as a C-style NUL-terminated string
> would be a lurking bug in most cases. Won't the length pretty much *always*
> be needed now?

In many cases yes, in certain cases, maybe not, when binary data doesn't
make sense.  However, maybe binary data should be error check for in these
cases, otherwise a truncated string is used.

However, the more I get into it, the more it is a pain that a char* and
a string length are returned separately in a lot of places.  A structure
return maybe easier, but its also a big change to many interfaces.

IMHO,
Mark



Mon, 14 Jun 1999 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Porting Widgets to TCL 8.0

2. stupid Tcl 8.0 porting question

3. porting TCL/TK interface from unix to NT

4. Accessing Global variables/objects from C code in Tcl 8.0

5. Object-orientation for Tcl/Tk 8.0?

6. Need an example to create lists in Tcl 8.0 using Object

7. Creating lists in Tcl 8.0 using Object

8. TclBin 1.2 {full binary objects structures and IO for Tcl 7.3 to 8.0}

9. Problems with HP-UX 8.0 and Tcl/TK 8.0

10. ANNOUNCE: Tcl 8.0 and Tk 8.0 releases

11. Bug Found in Tcl 8.0/Tk 8.0

12. Porting tkdesk to Red Hat 8.0

 

 
Powered by phpBB® Forum Software