Re: [Factor-talk] *-in-c-type-name

2010-03-15 Thread Ben Schlingelhof
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

2010-03-15 Thread Joe Groff
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

2010-03-15 Thread Jim mack
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

2010-03-15 Thread Joe Groff
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

2010-03-15 Thread Ben Schlingelhof
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