[Factor-talk] *-in-c-type-name
Hi there, I've tried to use the odbc-vocab in the newest factor source. I get this interesting error: 17: TYPEDEF: void* SQLSMALLINT* ^ *-in-c-type-name So I think, maybe the pointer-types work automatically now and comment this thing. Now it loads fine, but on running I get: Generic word underlying does not define a method for the string class. Dispatching on object: DSN=TEST_DSN Any hints how to resolve this? I didn't find the docs for these changes in alien.syntax. Ben -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] *-in-c-type-name
On Mar 15, 2010, at 6:18 AM, Ben Schlingelhof wrote: Hi there, I've tried to use the odbc-vocab in the newest factor source. I get this interesting error: 17: TYPEDEF: void* SQLSMALLINT* ^ *-in-c-type-name You're correct. Pointers no longer need to be (or can be) typedef-ed separately from their underlying types. If you want to define an opaque C type (that is, one which is valid as a pointer type but not as a value type), you can use C-TYPE: . Generic word underlying does not define a method for the string class. Dispatching on object: DSN=TEST_DSN I bet this is because of a recent change in string handling in the FFI. While parameters with a char* pointer type used to be treated specially and would automatically convert Factor strings to C strings and back, this is no longer the case. A separate type, c-string, is now used to automatically convert strings in the FFI. This is discussed in the C strings article of the FFI docs: http://docs.factorcode.org/content/article-c-strings.html The fix for odbc will probably be to update some parameters that take char* parameters (or typedefs thereof) to now take c-string parameters. -Joe-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] *-in-c-type-name
I've been working with the ODBC code with this change for a few months now: TYPEDEF: short* SQLSMALLINT* but am not knowledgeable enough why it would be wrong. It was early in my Factor learning process, and I can't swear I tested every data type. On Mon, Mar 15, 2010 at 12:05 PM, Joe Groff arc...@gmail.com wrote: On Mar 15, 2010, at 6:18 AM, Ben Schlingelhof wrote: Hi there, I've tried to use the odbc-vocab in the newest factor source. I get this interesting error: 17: TYPEDEF: void* SQLSMALLINT* ^ *-in-c-type-name You're correct. Pointers no longer need to be (or can be) typedef-ed separately from their underlying types. If you want to define an opaque C type (that is, one which is valid as a pointer type but not as a value type), you can use C-TYPE: . Generic word underlying does not define a method for the string class. Dispatching on object: DSN=TEST_DSN I bet this is because of a recent change in string handling in the FFI. While parameters with a char* pointer type used to be treated specially and would automatically convert Factor strings to C strings and back, this is no longer the case. A separate type, c-string, is now used to automatically convert strings in the FFI. This is discussed in the C strings article of the FFI docs: http://docs.factorcode.org/content/article-c-strings.html The fix for odbc will probably be to update some parameters that take char* parameters (or typedefs thereof) to now take c-string parameters. -Joe -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Jim I'm for extending the working Medicare program for our seniors all the way back to contraception, so Americans can concentrate on living their lives without fear of changing a job, going bankrupt from deductibles or fighting HMO bureaucracy. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] *-in-c-type-name
On Mar 15, 2010, at 2:00 PM, Jim mack wrote: I've been working with the ODBC code with this change for a few months now: TYPEDEF: short* SQLSMALLINT* but am not knowledgeable enough why it would be wrong. It was early in my Factor learning process, and I can't swear I tested every data type. Pointer C types don't exist separately from the pointed-to type anymore, so it doesn't make sense to TYPEDEF: something like SQLSMALLINT* anymore. You can get the same effect by removing the pointers: TYPEDEF: short SQLSMALLINT SQLSMALLINT* will then automatically be equivalent to short* . -Joe -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] *-in-c-type-name
Thanks for the quick and exhaustive answer. I'll try that. Ben On Mon, Mar 15, 2010 at 21:05, Joe Groff arc...@gmail.com wrote: On Mar 15, 2010, at 6:18 AM, Ben Schlingelhof wrote: Hi there, I've tried to use the odbc-vocab in the newest factor source. I get this interesting error: 17: TYPEDEF: void* SQLSMALLINT* ^ *-in-c-type-name You're correct. Pointers no longer need to be (or can be) typedef-ed separately from their underlying types. If you want to define an opaque C type (that is, one which is valid as a pointer type but not as a value type), you can use C-TYPE: . Generic word underlying does not define a method for the string class. Dispatching on object: DSN=TEST_DSN I bet this is because of a recent change in string handling in the FFI. While parameters with a char* pointer type used to be treated specially and would automatically convert Factor strings to C strings and back, this is no longer the case. A separate type, c-string, is now used to automatically convert strings in the FFI. This is discussed in the C strings article of the FFI docs: http://docs.factorcode.org/content/article-c-strings.html The fix for odbc will probably be to update some parameters that take char* parameters (or typedefs thereof) to now take c-string parameters. -Joe -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Ben Schlingelhof benseins.de -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
