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 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® 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® 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® 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 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® 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® 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® 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
[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® 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