[Chicken-users] SWIG and 2.5rc1
I tried running the 2.5rc1 against the latest SWIG code (which we are about to make a rc release too... good test of them both). Problem is, when you use the -proxy argument to SWIG it exports (declare (uses tinyclos)) into the generated .scm file. This won't work anymore unless -uses tinyclos is passed on the command line, and I am not sure how it will work if you try with csi. So I was wondering if it should be changed to (require-extension)? Problem is, it needs to be backwards compatible. Will require-extension work on old versions of chicken?.. maybe just (require)? Or should I change SWIG to export some code to test the chicken version? John ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: about DISOWN (Re: [Chicken-users] non-finalized object in SWIG
Daishi Kato wrote:
> Thanks for all those explanations.
> I now better understand some of the typemaps.
> My resolution for now is putting %apply by a script.
Note, you can run swig -xml which produces a bunch of XML describing the
.i file you input... so you could parse the -xml output to create the
%applys. That is what the xml output was really added for, modifying
the .i files from scripts.
If you didn't want to use XML, you can try the sexp which exports it in
Lisp s-expressions... then you can parse that directly in scheme. (I
think this is less tested than the xml module...)
>
> Well, so, here is another question:
> I'm wrapping the following class method, and it fails.
>
> class wxControl : public wxWindow {
> wxString& GetLabel();
> };
>
> 8<--8<--8<--8<--8<--
>
> wxchicken_core_wrap.cxx: In function 'void _wrap_wx_control_getslabel___(int,
> in
> t, int, int)':
> wxchicken_core_wrap.cxx:27542: error: invalid initialization of non-const
> refere
> nce of type 'wxString&' from a temporary of type 'wxString'
> wxchicken_core_wrap.cxx:27551: error: invalid conversion from 'const wxChar*'
> to
> 'char*'
> wxchicken_core_wrap.cxx:27551: error: initializing argument 3 of 'int
> C_string
> (int**, int, char*)'
Definatly a problem with the typemaps... just open up the
wxchicken_core_wrap.cxx file and go to that line... you should see the
code from the typemap. The second error is because C_string takes a
char *, but I assume wxString->cstr() returns a type const wxChar *
you can just cast between them
$result = C_string (&string_space, string_len, (char *) $1->c_str());
The first I am not sure about... are you sure the GetLabel() returns a
wxString &... it looks like it returns a const wxString &... in which
case you need to declare it like
class wxControl : public wxWindow {
const wxString& GetLabel();
};
so SWIG declares the temporary variable the correct type.
You can look inside the _wrap.cxx file, it isn't that scary!
John
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: about DISOWN (Re: [Chicken-users] non-finalized object in SWIG
Daishi Kato wrote:
> Hi,
>
> Sorry that I can't help much with the compilation errors.
>
> I have another question.
> Is it possible to specify a DISOWN typemap
> outside of the class definition.
>
> The following works:
> class Foo{
> %apply SWIGTYPE *DISOWN {Bar bar};
> void Foo(Bar bar);
> %clear Bar bar;
> };
>
> What I would like to do is like this:
> %apply SWIGTYPE *DISOWN {Foo::Foo(Bar bar)};
> class Foo{
> void Foo(Bar bar);
> };
>
For the details on how typemaps are matched, see
http://www.swig.org/Doc1.3/Typemaps.html
mainly the section "Pattern matching rules"
No. Typemaps are just that... they are defined and stored and whatever
based on types. As such, the DISOWN typemap is slightly different than
most typemaps in that you want it to "encode" a property of the
parameter instead of the type itself. There are several possible
solutions...
1) Since typemaps encode properties of types and not parameters, change
the type of the parameter to reflect this. For example:
typedef Bar BarDisown;
%apply SWIGTYPE *DISOWN { BarDisown * };
and then everywhere in the .i file you use BarDisown instead of Bar.
2) SWIG provides a very basic way to match on the parameter, but only
based on name. So instead of applying all those things, you can just
write code like
class Foo {
void Foo(Bar DISOWN);
};
where the name of the parameter is DISOWN. SWIG will use the DISOWN
typemap for this, no need to add any apply or clear or anything. If you
don't like the name, you can do something like
%apply SWIGTYPE *DISOWN { SWIGTYPE *hey };
and just use hey everywhere.
3) Could encode DISOWN as a %feature instead of as a typemap. Features
encode properties of parameters (and classes) instead of types, and so
you have to specify the feature for every function or class (just like
you want). So you could do something like
%delobject Foo::Foo();
%delobject *::add_container();
The %feature (which is what %delobject is) is very powerful at applying
marks to specific functions and such.
This was recently added in SWIG version 1.3.28, but has not yet been
implemented for Chicken (it works for python). See the section:
http://www.swig.org/Doc1.3/Customization.html#ownership
and that whole chapter on how %feature works. I might look into
supporting this for chicken, If you would like to use it...
John
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] non-finalized object in SWIG
Daishi Kato wrote: > Hi, here is the steps. > > Surely, you need chicken and swig. > (I use chicken-2.3 and swig-1.3.29.) > Also, wxWidgets is required. deb: libwxgtk2.6-dev > (Mine is wxWidgets-2.6.2.) > > Get the project: > % svn co https://galinha.ucpel.tche.br/svn/chicken-eggs/wxchicken > (you can login as "anonymous") > > Compile it: > % cd wxchicken; chicken-setup wxchicken.setup > I get a whole bunch of errors of the form wxchicken_wrap.cxx:1413: error: default argument for parameter of type ‘const wxString&’ has type ‘const char [1]’ wxchicken_wrap.cxx:1414: error: default argument for parameter of type ‘const wxString&’ has type ‘const char [1]’ wxchicken_wrap.cxx:1435: error: default argument for parameter of type ‘const wxString&’ has type ‘const char [6]’ wxchicken_wrap.cxx:1441: error: default argument for ‘const wxString& name’ has type ‘const char [7]’ I am using gcc 4.0.3. maybe that is the problem? John ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] non-finalized object in SWIG
Daishi Kato wrote: > Hi, > > Although my question was not that clear, > you gave me the right answer: > The helper function would certainly solve it. > Thanks for your suggestion. > > There is another weird issue with SWIG, > which I'm not sure if I can describe it clearly. > It would be much easier if you could access > to the SVN repo and try the wxchicken egg. > Hey, are you still having problems with this? I have some time to look at it in the next few days. Just provide a little more info... Where do I download it from (where is the SVN repo), which debian -dev packages (libraries) should I install, etc? John ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] non-finalized object in SWIG
Daishi Kato wrote:
> To SWIG experts,
>
> My question is if it is possible to create
> an object that is not garbage collected.
> DISOWN can be specified to input typemaps,
> but can an object that is created by a constructor
> be DISOWNed?
Yes, if you pass an object that was originally created by a constructor
(and is marked for garbage collection), the DISOWN typemap will remove
it from the garbage collector. The typemap basically just calls
C_do_unregister_finalizer(s)
>
> I would like to have sort of output typemaps with DISOWN.
>
> Note that I'm not yet used to SWIG, but it looks pretty nice.
> Daishi
>
>
Perhaps the easiest way would be to create a helper function: something
like
%inline %{
Foo *makeFoo(...) {
return new Foo(...);
}
%}
SWIG assumes by default that pointers that are returned from functions
are not added for garbage collection. You have to specifically add a
%newobject tag to functions when you want the return value to be
collected. (Note that from SWIGs point of view, a constructor is just
another function, except that SWIG automatically adds the %newobject tag
to constructors)
You could play some games with the definition of this function on the
chicken/scheme side too, so the helper looks like the real constructor.
(define old-new-Foo new-Foo) (set! new-Foo makeFoo)
John
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] foreign functions, swig
On Sat, 2006-05-20 at 14:18 -0700, Dan wrote:
> Thanks. I ended up writing SWIG typemaps (which I'm
> providing below, for those interested; no checks for
> now). I really think these should have been provided
> by SWIG, though...
> typedef unsigned int size_t;
You can do something like %apply unsigned int size_t; as well
>
> %typemap(in) float * {
> $1 = C_c_f32vector_or_null ($input);
> }
>
> %typemap(in) double * {
> $1 = C_c_f64vector_or_null ($input);
> }
>
> %typemap(in) int * {
> $1 = C_c_s32vector_or_null ($input);
> }
>
> %typemap(in) unsigned * {
> $1 = C_c_u32vector_or_null ($input);
> }
>
> %typemap(in) long * {
> $1 = C_c_s32vector_or_null ($input);
> }
>
> %typemap(in) unsigned long * {
> $1 = C_c_u32vector_or_null ($input);
> }
I was thinking about these, and I think should define something like
%typemap(in) unsigned int *u32vector {
$1 = C_c_u32vector_or_null($input);
}
(That is, give the typemap a name of u32vector.) Then to use the
typemap, you need to do something like
%apply unsigned int *u32vector { unsigned int *vec };
void test(unsigned int *vec) {
...
}
And then optionally %clear unsigned int *vec;
This way, including srfi4.i does not corrupt the global namespace of
typemaps. If you actually want to pass a double * somewhere as an
actual pointer, and not an array, you don't have to do anything. This
is how argout/argin typemaps work, you apply the unsigned int *OUTPUT
typemap to whatever you want to be an output argument.
If you just want to apply the typemap to everything, you can do
something like
%clear unsigned int *;
%apply unsigned int *u32vector { unsigned int * };
(You need the clear because %apply never overwrites existing typemaps)
What do you think about using this kind of interface?
John
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] foreign functions, swig
On Sat, 2006-05-20 at 23:42 +0200, felix winkelmann wrote: > On 5/20/06, Dan <[EMAIL PROTECTED]> wrote: > > Thanks. I ended up writing SWIG typemaps (which I'm > > providing below, for those interested; no checks for > > now). I really think these should have been provided > > by SWIG, though... > > Hm... I can send these to the SWIG maintainers. > No need :) I usually read/scan the chicken-users mailing list for SWIG. I think I will add a file called srfi4.i that needs to be explicitly included (and add something to the chicken documentation on how to include it), instead of always including these typemaps in every interface generated. To use them, an interface would just need to have a line like %include This would be similar to how generic arrays are handled. see http://www.swig.org/Doc1.3/Library.html#Library Dan, for future compatibility you can just create a file named srfi4.i, and include it from every interface file you have. Then, when the new version of SWIG comes out you will be able to either delete srfi4.i or whatever (depending on how you have your SWIG library search path set up). John ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] SWIG Policy Question
A test was recently added to the SWIG test suite that checks if overflows are correctly detected. It was added for guile, which allows arbitrarily big integers, so a check if the integer is inside the range of a long is possible. Since the scheme languages in SWIG share a lot of code, the test was added for chicken as well. But the test currently fails, and I am wondering how to proceed. Currently, SWIG chicken accepts either a fixnum or a flonum to any integer parameter, and does no checking at all for overflow. (It uses C_num_to_int to convert. Thus, a direct cast from int to double.) The question is, which types (if any) should SWIG check for overflow? Testing for the double/flonum -> long overflows could be made, using something like double arg1d = C_flonum_magnitude(scm1); if ((double)C_WORD_MIN > arg1d || (double)C_WORD_MAX < arg1d) SWIG_Chicken_Barf(...) int arg1 = (int) arg1d; Also, casts from fixnums to shorts could also be checked for overflow. Casts from fixnums to ints or longs would not check for overflow... since any overflow chicken would convert to a flonum. Or, we could skip overflow detection and leave the code like it is right now. In that case, I would remove the tests for overflow from the chicken portion of the test suite. John PS: I recently commited some changes to configure.in to no longer check chicken-config and use csc instead. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Wierd error running chicken
I was just running the SWIG chicken test suite to see if it still ran, since we are planning on releasing a new version of SWIG. I am getting a very strange error. Well, the error itself isn't that strange. But adding a blank line with a comment on it causes the error to disappear. This is with the 2.2 snapshot of chicken, and the example is from SWIG CVS. (also compiling on Ubuntu amd64). Adding blank lines and comments causes the error to disappear. I was unable to make the example any smaller. I put the files up on my site at http://www.cs.wisc.edu/~lenz/chickenbug.tar.gz run csc -s li_typemaps.scm li_typemaps_wrap.cxx -o li_typemaps.so env LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH csi -quiet ./li_typemaps_runme_proxy.ss env LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH csi -quiet ./li_typemaps_runme_proxy_broken.ss The only difference between the two files is the existance of a line with a ";" on it. I get an error on the second command because the return value from the out-foo function is not the correct type. I can't see what it is returning, because adding a (display a) line in there makes the program work again. Putting blank lines other places in the code sometimes causes the error, other times it doesn't. I suspect some sort of stack overflow or something, although adding blank lines in the input shouldn't be changing anything. John P.S: I haven't been keeping up with any SWIG requests and am just coming back from a while away from my email, so if there are any problems with chicken and SWIG, you will have to send them to me again. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Scheme, Chicken, and Parrot
Introduction I have a very alpha patch to add a parrot backend to the CHICKEN compiler. CHICKEN is a scheme to C compiler, and parrot is a continuation (rather than stack) based virtual machine. There are several design issues mapping chicken constructs to parrot constructs (do the words "calling conventions" come to mind? :) that need to get worked out. Rather than attach the patches to this email, I have stuck them on my web site at http://www.cs.wisc.edu/~lenz/parrot http://www.call-with-current-continuation.org http://www.parrotcode.org Background Chicken compiles scheme code into continuation-passing-style. It is heavily influenced by the paper http://home.pipeline.com/~hbaker1/CheneyMTA.html This is a good match to Parrot's continuation passing call/return convention, but there are a few problems. Most of the problems stem from the fact that IMCC and PIR assume that languages are exporting functions that act like traditional functions... they call other functions, and then return. Chicken exported functions are interesting, in that they never return, and every function call never returns; every function knows where it should go next and we never come back to a function after a function call (unless the function is referenced inside the continuation). The advantages are that since both chicken and parrot use a continuation passing style, they are a very good fit for each other. Chicken generated code never has to deal with a stack (the C backend needs to use longjmp() since no function ever returns...). Chicken generated code will take advantage of the just in time compilation that parrot provides, as well as all the libraries. It also will allow scheme code to be called (and to call) perl6, python, tcl, and the other languages that are being ported to run on parrot. Parrot Issues (scroll down a ways for Chicken issues) --- 1) Calling Conventions. Chicken generates tons of little functions. The compiler (which is written in scheme and compiles itself) generates over 10,000 functions, each one on average 10-15 parrot instructions. Because of that, we can very efficiently manage the passing of arguments. That is, arguments for a call can be generated directly into registers. For example, here is a sample function generated by chicken. The function accepts 3 arguments (P1, P2, P3) , and calls with two arguments (P1, P2). # bar in k24 in k21 in k18 f_28: set P1, P2 new P2, .FixedPMCArray # Closure set P2, 2 set_addr I0, f_30 set P2[0], I0 new P4, .Ref setref P4, P3 set P2[1], P4 jump P1 I have yet to add argument length checking, but you get the idea. As you can see, I am currently just using set_addr and jump so as to avoid the massive overhead of passing arguments, when they are already in the right registers. Since scheme is dynamicly typed, everything is a PMC and we don't really use the other registers. It is fairly trivial to export a real sub that would use PPD3 that just wraps up this call to marshal between the "internal" calling convention to the PPD3. While this would work fine, I would like to support these calling conventions directly in parrot, so that the interpreter knows which sub it is currently running, tracing, etc. As such, I propose a fasttailcall opcode. This opcode acts exactly like the tailcall opcode, except it does not pass any arguments and leaves the registers alone. http://www.cs.wisc.edu/~lenz/parrot/fasttailcall.patch One way to think about and justify the fasttailcall opcode is to think about the difference between functions and chicken exported functions. For example, the scheme function (define (myfunc a b) (let ((c (* a 6))) (print (+ a b c)) (- a b))) might generate 10 function-pieces. Thus, what you would really like is for the entire "myfunc" to be a function that is presented to the rest of parrot... that is the only function that gets registered, it uses the new PPD3 calling conventions, etc. But internally, we split up the execution of that function into 10 function-pieces. Then we can fasttailcall between function pieces, which really just means continue working on the current function. Thus, since you are still working on the same function, leaving the registers and not invoking the entire PPD3 calling conventions makes sense when switching between pieces. 2) PIR doesn't fit so well. First off, we have already done all the register allocation. We never need to save registers across calls (since nothing returns), and the only if-dependent code looks like if I0, truecode ...setup args for false fasttailcall truecode: ..setup args for true fasttailcall There is no register allocation that needs to take place, except for overflow. Chicken generates code that assumes infinite registers. In practice, most functions are using less than 10 registers. From what I can see, the current register a
Re: [Chicken-users] Problem with finalizers?
On 05/01/05 10:59:25, Alejandro Forero Cuervo wrote: Are finalizers actually getting called? You might try this thread: http://lists.gnu.org/archive/html/chicken-users/2005-03/msg00041.html lists.gnu.org is refusing connections right now, but I was able to see the google cache: http://64.233.167.104/search?q=cache:mMKog2KoNm0J:lists.gnu.org/archive/html/chicken-users/2005-03/msg00041.html+finalizers+chicken&hl=en&client=firefox http://64.233.167.104/search?q=cache:04OAkdSEsvMJ:lists.gnu.org/archive/html/chicken-users/2005-03/msg00043.html+finalizers+chicken&hl=en&client=firefox The latest darcs chicken code has the patch for that problem. John ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
