Re: [Swig-devel] Converting chicken to standard typemaps

[Marcelo M. <mm...@ac...>]

John Lenz wrote:

>I am in the process of converting chicken to use the standard typemaps
>(haven't committed anything yet, just on my computer here), and have a few
>questions, problems, whatever.
>
>ckerrors
>What does AddErrorMsg do?  I converted the helper functions that we had
>over to the SetErrorObj and SetErrorMsg, but couldn't really figure out
>what AddErrorMsg is for.
>  
>
that is a backward compatible method used only in python, not really a 
part of the new UTL.
don't worry about it, but if you need to know, it adds more text or info 
to a currently
reported error, but again, don't even think about it.

>Secondly, with chicken SetErrorMsg, SetErrorObj, and ThrowException never
>return, and so we don't have a fail: label in the wrapper.  So I have just
>defined SWIG_fail to nothing.  Is SWIG_fail used anywhere without a call
>to SetErrorMsg or SetErrorObj right before it?  If so, I can
>#define SWIG_fail  SWIG_SetErrorMsg(SWIG_ErrorType(SWIG_RuntimeError),
>"unspecified error")
>  
>
hmm, you can try I guess, if that doesn't work, just add to the wrap:

 fail:
    SWIG_SetErrorMsg(SWIG_ErrorType(SWIG_RuntimeError),"unspecified error");

take a look at ruby.cxx/python.cxx/perl.cxx/tcl.cxx, search for "fail:", 
there are just around
5 or 6 places where you will need to add the above code.

>constants... need to set SWIG_SetConstant in cktypemaps...
>chicken currently uses
>%typemap(constcode) char *
>"static const char *$result = $value;"
>
>%typemap(constcode) SWIGTYPE *, SWIGTYPE &, SWIGTYPE []
>"static const void *$result = (void*) $value;"
>
>%typemap(constcode) SWIGTYPE (CLASS::*)
>"static const void *$result = (void*) &$value;"
>
>and chicken.cxx outputs a bunch of code.  constcode gets put into
>f_header, and we lookup the varout typemap and just use that.
>  
>

Then, just add those typemaps to the end of the cktypemaps.swg file, 
take a look
at the special cases for perl (perltypemaps.swg) or python (pytypemaps.swg).
One good thing about the UTL is that allow you to keep using your very
language specific typemaps if needed.

>In chicken, there really isn't the concept of a constant.  We just provide
>a function that returns the value.  And since in scheme functions are
>first class objects, I guess you could say that the function itself is the
>constant....
>
>So, I am unsure how to deal with that constant stuff.
>
>Lastly, as far as that malloc stuff goes (on heap or on stack), I think I
>will just override the primitive typemaps.  I'll write all the
>SWIG_AsVal(long) or whatever to use C_alloc_on_heap.  That way, for
>fast-path wrappers (that just use primitive types or SWIGTYPE), it will
>allocate on the stack using the overriden primtive typemaps.  For anything
>more exotic (like std::map, whatever), it will allocate on the heap
>(slower) using SWIG_AsVal.  We have all the primitive typemaps written
>already in the current chicken code; I can just copy them over.
>
>Lastly, some typemaps need extra parameters to the typemap.  For example,
>%typemap(in,closcode="(slot-ref $input 'swig-this)") SWIGTYPE *, SWIGTYPE
>[], SWIGTYPE &  {
>   $1 = ($1_ltype)SWIG_MustGetPtr($input, $descriptor, $argnum, $disown);
>}
>
>That closcode can actually be added on any in or varin typemap, but for
>the included typemaps in Lib/, only SWIGTYPE currently uses it.  (User
>defined typemaps can use it too).
>  
>
If that is typemap independent, maybe is better to define it as:

%typemap(closcode) SWIGTYPE *, SWIGTYPE[], SWIGTYPE & "(slot-ref $input 'swig-this)";

and use (in chicken.cxx):
   Swig_typemap_attach_parms("closcode",l,f);
   String *clos_code = Getattr(p, "tmap:closcode") || Getattr(p, "tmap:in:closcode");

instead of:

   String *clos_code = Getattr(p, "tmap:in:closcode");
    

Marcelo


>Lastly, I haven't done anything with std_*.i yet, but the whole point of
>this conversion is to use it.  Should I copy the python code over, and
>then edit it?  Or is there some documentation on what all those traits
>things are doing?
>  
>
we are going over there, I am quite in the middle of very bussy days 
now, but the next
step is to uniform all the std*.i files. I was also waiting for the PHP 
version using the UTL
and/or any other language to see if we need to expand/modify the UTL in 
some other way.


>John
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Swig-devel mailing list
>Swi...@li...
>https://lists.sourceforge.net/lists/listinfo/swig-devel
>  
>