October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pointer types

by Igor Stasenko

On 7 October 2010 14:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > I have to start watching the clock here, so I will just throw this out for your consideration. Â Yes a pointer is a pointer, but there are layers of specificity. Â If a function expects a double*, ideally passing a FloatArray would "take some work," perhaps in the form of wrapping the argument in a "cast"/adpater of some type and passing that to the function. Â If I describe an argument to the function as void*, then I do not expect much help. Â In fact, this is a growing source of trouble for me, because my DOUBLEArray leads me to describe parameters as void* when they should/could be double*. Â The current FFI *appears* to be helping in other situations by complaining when type A does not fit in slot B. > > Clearly if the function is mapped as the wrong type in the code I give you, then the seg fault is on me. Â But it would be nice if when given a correct (double*, long) argument sequence, you could raise an error if those are reversed. Â Am I missing something? Â I gotta go =:0 You could even specify that a double* argument expects an argument to be an instance of DoubleArray, which then will be coerced to pointer. There's many other things possible, but before you start using it, you'll never know :) > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Thursday, October 07, 2010 6:49 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pointer types > > On 7 October 2010 13:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Ultimately, I will have to simply try this, but it reminds me of something that I can't place. Â Have you considered using a dictionary or other type of collection to store the types? Â A new handler would then be created and finally hooked into the system by sending a message to connect it; opposite on removal. Â It might turn out to be very much one-to-one so that what I am wondering about does not apply. >> > > Sure, you can use dictionaries in alias lookup implementation: > > Â MyClass>>externalTypeAlias: aTypeName > Â Â ^ myAliasesDict at: aTypeName ifAbsent: [ nil ] > >> Anything that can be double* can also be used with void*. Â How does that work? >> > > Pointer is a pointer. If function expects a pointer argument, you can > pass any pointer to it. > Code generator just checks that an argument you passes can be > converted to C pointer (bytearray, wordarray, external pointer), > but sure thing it can't check if you passed char* or double* or void*. > Such kind of type checking belongs to C compiler :) > > So, a pointer types in FFI callout declarations is more like a hint, > what function expects, rather than something ,which > influence the generated callout code. > > >> Bill >> >> >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Thursday, October 07, 2010 12:41 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Pointer types >> >> On 7 October 2010 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> Am I correct in taking this as a description of how to solve it with NB, not Squeak/Pharo FFI? Â That's ok, just want to know if there is an applicable lesson on FFI to be extracted. >>> >>> You say the NB callout generator knows nothing about types. Â Is that how it should be? Â The scenario I have in mind is a bogus type and whether that can/should be flagged at compile time vs. runtime. Â Maybe all it takes is a scan for a suitable handler before or after the method is compiled. Â I ask because I hit a related snag with FFI runtime errors being reported as coercion errors when in fact I had used errant types in the callout definitions. Â IIRC, Andreas patched the compiler to report the bogus types. >>> >>> >>> "Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: >>> >>> MyClass>>externalTypeAlias: aTypeName >>> Â aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >>> Â ^ nil >>> >>> Then, any method which contains an FFI callout in MyClass, will use that alias." >>> >>> What is MyClass in the above? Â Is it the class holding the callout method, or it elsewhere in the chain? Â I ask because it could be a sore spot for maintenance/pluggability. Â I'm wondering how you and I would independently add such instructions. Â If it goes in the external type subclass, then it is probably fine; if it goes in a class that makes the call, we might stomp on each other. Â Make sense? Â My hunch is that you have it handled. >>> >> >> Its in an any class, which using FFI callouts. We can stomp on each >> other if you define aliases in Object class :) >> But this won't be a good idea, isnt? >> NBExternalType subclasses defining coercions between ST oops and >> concrete C type, they are not for defining aliases. >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >>> Sent: Monday, October 04, 2010 7:36 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Pointer types >>> >>> On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> Sig, >>>> >>>> You mentioned something that might be useful, depending on where it lives. Â Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Â Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. >>>> >>>> Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? Â If not FFI, how does NB handle it? >>>> >>> >>> In NB, there is a type system, which implements C<->Smalltalk coercions. >>> The responsibility of type coercions taken by a subclasses of NBExternalType, >>> so NB callout code generator actually knows nothing about types and >>> how to coerce them. >>> >>> To create own custom type, you need to subclass from NBExternalType >>> and override methods which responsible for coercions. >>> There you can define any kind of operations , what needs to be done in >>> order to push value on stack, or >>> convert it to some smalltalk object. >>> >>> Then, in your DoubleArray class, simply implement a message on a class side: >>> >>> asNBExternalType: gen >>> >>> Â Â Â Â ^ MyDoubleArrayExternalType new >>> >>> >>> And then, in FFI callouts you can use a class name directly: >>> >>> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >>> >>> etc. >>> >>> Or, if you want make double* type to use it as a DoubleArray, then you >>> can add an alias: >>> >>> MyClass>>externalTypeAlias: aTypeName >>> Â aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >>> Â ^ nil >>> >>> Then, any method which contains an FFI callout in MyClass, >>> will use that alias. So, you can write callout as: >>> >>> double* foo (double *arr, double ** arrPtrPtr) >>> >>> but it will be understood as: >>> >>> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >>> >>> >>> About handling pointers.. well for smalltalk there is no pointers, just objects. >>> So, in NB NBExternalType keeps two things: >>> Â - a value type >>> Â - a pointer arity >>> >>> >>> So, for example, when you specifying type, like: >>> char *** >>> >>> a value type will be char >>> and pointer arity will be 3. >>> >>> It is up to NBExternalType subclass how to push values whose pointer arity > 0. >>> By default, if pointerArity > 0, then it is treated as a pointer, >>> which can be either: - nil, ByteArray, or NBExternalAddress >>> >>> >>>> Bill >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 7, 2010

Re: [Pharo-project] Pointer types

by Schwab,Wilhelm K

Sig, I have to start watching the clock here, so I will just throw this out for your consideration. Yes a pointer is a pointer, but there are layers of specificity. If a function expects a double*, ideally passing a FloatArray would "take some work," perhaps in the form of wrapping the argument in a "cast"/adpater of some type and passing that to the function. If I describe an argument to the function as void*, then I do not expect much help. In fact, this is a growing source of trouble for me, because my DOUBLEArray leads me to describe parameters as void* when they should/could be double*. The current FFI *appears* to be helping in other situations by complaining when type A does not fit in slot B. Clearly if the function is mapped as the wrong type in the code I give you, then the seg fault is on me. But it would be nice if when given a correct (double*, long) argument sequence, you could raise an error if those are reversed. Am I missing something? I gotta go =:0 Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, October 07, 2010 6:49 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pointer types On 7 October 2010 13:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Ultimately, I will have to simply try this, but it reminds me of something that I can't place. Have you considered using a dictionary or other type of collection to store the types? A new handler would then be created and finally hooked into the system by sending a message to connect it; opposite on removal. It might turn out to be very much one-to-one so that what I am wondering about does not apply. > Sure, you can use dictionaries in alias lookup implementation: MyClass>>externalTypeAlias: aTypeName ^ myAliasesDict at: aTypeName ifAbsent: [ nil ] > Anything that can be double* can also be used with void*. How does that work? > Pointer is a pointer. If function expects a pointer argument, you can pass any pointer to it. Code generator just checks that an argument you passes can be converted to C pointer (bytearray, wordarray, external pointer), but sure thing it can't check if you passed char* or double* or void*. Such kind of type checking belongs to C compiler :) So, a pointer types in FFI callout declarations is more like a hint, what function expects, rather than something ,which influence the generated callout code. > Bill > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Thursday, October 07, 2010 12:41 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pointer types > > On 7 October 2010 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Am I correct in taking this as a description of how to solve it with NB, not Squeak/Pharo FFI? That's ok, just want to know if there is an applicable lesson on FFI to be extracted. >> >> You say the NB callout generator knows nothing about types. Is that how it should be? The scenario I have in mind is a bogus type and whether that can/should be flagged at compile time vs. runtime. Maybe all it takes is a scan for a suitable handler before or after the method is compiled. I ask because I hit a related snag with FFI runtime errors being reported as coercion errors when in fact I had used errant types in the callout definitions. IIRC, Andreas patched the compiler to report the bogus types. >> >> >> "Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: >> >> MyClass>>externalTypeAlias: aTypeName >> aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >> ^ nil >> >> Then, any method which contains an FFI callout in MyClass, will use that alias." >> >> What is MyClass in the above? Is it the class holding the callout method, or it elsewhere in the chain? I ask because it could be a sore spot for maintenance/pluggability. I'm wondering how you and I would independently add such instructions. If it goes in the external type subclass, then it is probably fine; if it goes in a class that makes the call, we might stomp on each other. Make sense? My hunch is that you have it handled. >> > > Its in an any class, which using FFI callouts. We can stomp on each > other if you define aliases in Object class :) > But this won't be a good idea, isnt? > NBExternalType subclasses defining coercions between ST oops and > concrete C type, they are not for defining aliases. > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Monday, October 04, 2010 7:36 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Pointer types >> >> On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> You mentioned something that might be useful, depending on where it lives. Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. >>> >>> Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? If not FFI, how does NB handle it? >>> >> >> In NB, there is a type system, which implements C<->Smalltalk coercions. >> The responsibility of type coercions taken by a subclasses of NBExternalType, >> so NB callout code generator actually knows nothing about types and >> how to coerce them. >> >> To create own custom type, you need to subclass from NBExternalType >> and override methods which responsible for coercions. >> There you can define any kind of operations , what needs to be done in >> order to push value on stack, or >> convert it to some smalltalk object. >> >> Then, in your DoubleArray class, simply implement a message on a class side: >> >> asNBExternalType: gen >> >> ^ MyDoubleArrayExternalType new >> >> >> And then, in FFI callouts you can use a class name directly: >> >> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >> >> etc. >> >> Or, if you want make double* type to use it as a DoubleArray, then you >> can add an alias: >> >> MyClass>>externalTypeAlias: aTypeName >> aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >> ^ nil >> >> Then, any method which contains an FFI callout in MyClass, >> will use that alias. So, you can write callout as: >> >> double* foo (double *arr, double ** arrPtrPtr) >> >> but it will be understood as: >> >> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >> >> >> About handling pointers.. well for smalltalk there is no pointers, just objects. >> So, in NB NBExternalType keeps two things: >> - a value type >> - a pointer arity >> >> >> So, for example, when you specifying type, like: >> char *** >> >> a value type will be char >> and pointer arity will be 3. >> >> It is up to NBExternalType subclass how to push values whose pointer arity > 0. >> By default, if pointerArity > 0, then it is treated as a pointer, >> which can be either: - nil, ByteArray, or NBExternalAddress >> >> >>> Bill >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2010

Re: [Pharo-project] Learning by download all the mcz files from a repository

by Schwab,Wilhelm K

Do you see yourself acting as scientist or student? Good scientists *are* students (learning never stops), but the distinction I am making is more about what you plan to get from this. If you see this as a scientific exercise, you will want to collect or map the changes to some type of reportable data (object oriented metrics, graph theoretic representation, etc.). If I were going to do this, I would grab the .mcz files (cheap storage is a good thing) and work toward having an image do the loading and looking. Along the way, it would create the "data trail" that would ultimately be of interest. That would likely be iterative, meaning that I would expect to do what you describe (looking at the changes, no doubt with the aid of conditional breakpoints) at various steps along the way, but the goal would probably be to summarize what is happening. Good luck. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of HwaJong Oh [daliot.oh(a)gmail.com] Sent: Thursday, October 07, 2010 3:23 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Learning by download all the mcz files from a repository I plan to study history of Metacello. For that I came up with an idea, what if i download all the mcz in the metacello repository on squeaksource. Then sort them by commit time stamp. installing very first version of Metacello to last version of Metacello-Help. Every moment of installation, see the difference by clicking "Changes" button of monticello browser. By doing it, i can grasp the idea, the indents of version and understand how the design has been changed and know the direction of change. What do you think of this idea? -HwaJong Oh- -- View this message in context: http://forum.world.st/Learning-by-download-all-the-mcz-files-from-a-reposit… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2010

[Pharo-project] WebBrowser

by Torsten Bergmann

There once was a subclass of AppRegistry called WebBrowser. This is now gone in "PharoCore 1.2a 12172" compared to Pharo 1.1 Dont know why this specific subclass was removed since other subclasses of AppRegistry are still in the image (like MailSender, SoundService, ...) Was it by accident or if not what is the idea here. However - since this class is missing the package "ExternalWebBrowser" will fail to load in Pharo 1.2 since it would like to register itself as a webbrowser in a class side #initialize. Two possibilities: - we change ExternalWebBrowser - we reintroduce the missing class (either internal or in a compatibility package) Any comments? Thx Torsten -- GRATIS! Movie-FLAT mit Ã¼ber 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

Oct. 7, 2010

Re: [Pharo-project] Pointer types

by Igor Stasenko

On 7 October 2010 13:35, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Ultimately, I will have to simply try this, but it reminds me of something that I can't place. Â Have you considered using a dictionary or other type of collection to store the types? Â A new handler would then be created and finally hooked into the system by sending a message to connect it; opposite on removal. Â It might turn out to be very much one-to-one so that what I am wondering about does not apply. > Sure, you can use dictionaries in alias lookup implementation: MyClass>>externalTypeAlias: aTypeName ^ myAliasesDict at: aTypeName ifAbsent: [ nil ] > Anything that can be double* can also be used with void*. Â How does that work? > Pointer is a pointer. If function expects a pointer argument, you can pass any pointer to it. Code generator just checks that an argument you passes can be converted to C pointer (bytearray, wordarray, external pointer), but sure thing it can't check if you passed char* or double* or void*. Such kind of type checking belongs to C compiler :) So, a pointer types in FFI callout declarations is more like a hint, what function expects, rather than something ,which influence the generated callout code. > Bill > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Thursday, October 07, 2010 12:41 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pointer types > > On 7 October 2010 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> Am I correct in taking this as a description of how to solve it with NB, not Squeak/Pharo FFI? Â That's ok, just want to know if there is an applicable lesson on FFI to be extracted. >> >> You say the NB callout generator knows nothing about types. Â Is that how it should be? Â The scenario I have in mind is a bogus type and whether that can/should be flagged at compile time vs. runtime. Â Maybe all it takes is a scan for a suitable handler before or after the method is compiled. Â I ask because I hit a related snag with FFI runtime errors being reported as coercion errors when in fact I had used errant types in the callout definitions. Â IIRC, Andreas patched the compiler to report the bogus types. >> >> >> "Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: >> >> MyClass>>externalTypeAlias: aTypeName >> Â aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >> Â ^ nil >> >> Then, any method which contains an FFI callout in MyClass, will use that alias." >> >> What is MyClass in the above? Â Is it the class holding the callout method, or it elsewhere in the chain? Â I ask because it could be a sore spot for maintenance/pluggability. Â I'm wondering how you and I would independently add such instructions. Â If it goes in the external type subclass, then it is probably fine; if it goes in a class that makes the call, we might stomp on each other. Â Make sense? Â My hunch is that you have it handled. >> > > Its in an any class, which using FFI callouts. We can stomp on each > other if you define aliases in Object class :) > But this won't be a good idea, isnt? > NBExternalType subclasses defining coercions between ST oops and > concrete C type, they are not for defining aliases. > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Monday, October 04, 2010 7:36 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Pointer types >> >> On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> You mentioned something that might be useful, depending on where it lives. Â Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Â Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. >>> >>> Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? Â If not FFI, how does NB handle it? >>> >> >> In NB, there is a type system, which implements C<->Smalltalk coercions. >> The responsibility of type coercions taken by a subclasses of NBExternalType, >> so NB callout code generator actually knows nothing about types and >> how to coerce them. >> >> To create own custom type, you need to subclass from NBExternalType >> and override methods which responsible for coercions. >> There you can define any kind of operations , what needs to be done in >> order to push value on stack, or >> convert it to some smalltalk object. >> >> Then, in your DoubleArray class, simply implement a message on a class side: >> >> asNBExternalType: gen >> >> Â Â Â Â ^ MyDoubleArrayExternalType new >> >> >> And then, in FFI callouts you can use a class name directly: >> >> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >> >> etc. >> >> Or, if you want make double* type to use it as a DoubleArray, then you >> can add an alias: >> >> MyClass>>externalTypeAlias: aTypeName >> Â aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. >> Â ^ nil >> >> Then, any method which contains an FFI callout in MyClass, >> will use that alias. So, you can write callout as: >> >> double* foo (double *arr, double ** arrPtrPtr) >> >> but it will be understood as: >> >> DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) >> >> >> About handling pointers.. well for smalltalk there is no pointers, just objects. >> So, in NB NBExternalType keeps two things: >> Â - a value type >> Â - a pointer arity >> >> >> So, for example, when you specifying type, like: >> char *** >> >> a value type will be char >> and pointer arity will be 3. >> >> It is up to NBExternalType subclass how to push values whose pointer arity > 0. >> By default, if pointerArity > 0, then it is treated as a pointer, >> which can be either: - nil, ByteArray, or NBExternalAddress >> >> >>> Bill >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 7, 2010

[Pharo-project] [ANN 1.2] #12173-12185 was: Re: Cog+NativeBoost Linux32 binaries available

by Marcus Denker

On Oct 6, 2010, at 12:38 PM, StÃ©phane Ducasse wrote: > Cool > > Marcus will integrate your changes. I'm off for a full day meeting wuithout good internet connection until > thursday evening :( > Done. update #12173-12185 Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 7, 2010

Re: [Pharo-project] Pointer types

by Schwab,Wilhelm K

Sig, Ultimately, I will have to simply try this, but it reminds me of something that I can't place. Have you considered using a dictionary or other type of collection to store the types? A new handler would then be created and finally hooked into the system by sending a message to connect it; opposite on removal. It might turn out to be very much one-to-one so that what I am wondering about does not apply. Anything that can be double* can also be used with void*. How does that work? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Thursday, October 07, 2010 12:41 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pointer types On 7 October 2010 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Am I correct in taking this as a description of how to solve it with NB, not Squeak/Pharo FFI? That's ok, just want to know if there is an applicable lesson on FFI to be extracted. > > You say the NB callout generator knows nothing about types. Is that how it should be? The scenario I have in mind is a bogus type and whether that can/should be flagged at compile time vs. runtime. Maybe all it takes is a scan for a suitable handler before or after the method is compiled. I ask because I hit a related snag with FFI runtime errors being reported as coercion errors when in fact I had used errant types in the callout definitions. IIRC, Andreas patched the compiler to report the bogus types. > > > "Or, if you want make double* type to use it as a DoubleArray, then you can add an alias: > > MyClass>>externalTypeAlias: aTypeName > aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. > ^ nil > > Then, any method which contains an FFI callout in MyClass, will use that alias." > > What is MyClass in the above? Is it the class holding the callout method, or it elsewhere in the chain? I ask because it could be a sore spot for maintenance/pluggability. I'm wondering how you and I would independently add such instructions. If it goes in the external type subclass, then it is probably fine; if it goes in a class that makes the call, we might stomp on each other. Make sense? My hunch is that you have it handled. > Its in an any class, which using FFI callouts. We can stomp on each other if you define aliases in Object class :) But this won't be a good idea, isnt? NBExternalType subclasses defining coercions between ST oops and concrete C type, they are not for defining aliases. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 04, 2010 7:36 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pointer types > > On 4 October 2010 06:15, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> You mentioned something that might be useful, depending on where it lives. Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to<g>) expressing them as void pointers to allow me to pass byte arrays into them. >> >> Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? If not FFI, how does NB handle it? >> > > In NB, there is a type system, which implements C<->Smalltalk coercions. > The responsibility of type coercions taken by a subclasses of NBExternalType, > so NB callout code generator actually knows nothing about types and > how to coerce them. > > To create own custom type, you need to subclass from NBExternalType > and override methods which responsible for coercions. > There you can define any kind of operations , what needs to be done in > order to push value on stack, or > convert it to some smalltalk object. > > Then, in your DoubleArray class, simply implement a message on a class side: > > asNBExternalType: gen > > ^ MyDoubleArrayExternalType new > > > And then, in FFI callouts you can use a class name directly: > > DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) > > etc. > > Or, if you want make double* type to use it as a DoubleArray, then you > can add an alias: > > MyClass>>externalTypeAlias: aTypeName > aTypeName = 'double*' ifTrue: [ ^ #DoubleArray ]. > ^ nil > > Then, any method which contains an FFI callout in MyClass, > will use that alias. So, you can write callout as: > > double* foo (double *arr, double ** arrPtrPtr) > > but it will be understood as: > > DoubleArray foo (DoubleArray arr, DoubleArray * arrPtr) > > > About handling pointers.. well for smalltalk there is no pointers, just objects. > So, in NB NBExternalType keeps two things: > - a value type > - a pointer arity > > > So, for example, when you specifying type, like: > char *** > > a value type will be char > and pointer arity will be 3. > > It is up to NBExternalType subclass how to push values whose pointer arity > 0. > By default, if pointerArity > 0, then it is treated as a pointer, > which can be either: - nil, ByteArray, or NBExternalAddress > > >> Bill >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2010

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost Linux32 binaries available

by Igor Stasenko

On 7 October 2010 11:36, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >>>>> Also, the missing class is NBGLCurveRenderer, which i moved to >>>>> NBOpenGL-Rome package. >>>>> I did a snapshot of it. But it depends on RomeCanvas class(es) , which >>>>> is part of Athens.. >>>>> But just ignore that for now and load it. For demo, you need only >>>>> NBGLCurveRenderer which not rely on any Rome-specific stuff. >>> >>> Just for curiosity, why this dependance on Rome? To end up providing a Canvas were all the rendering is performed by OpenGL and you text rendering class ? >> >> >> A NBGLCurveRenderer is actually an experiment, which should be a part >> of something bigger (read Rome). >> So, that's why i moved it there, breaking demo :) >> > > The demo works just fine now! > >> I plan to implement an OpenGL backend for canvas, which implements >> Rome protocol. >> And then implement Morphic which using rome-canvas for rendering.. >> And then implement brand-new zoomable UI in it.. >> >> (i have a big plans)... :) >> > > I was hoping you did! > > Questions: > 1.Once you have a NBOpenGLRomeCanvas , how do you plan to implement the zoomable UI? On which layer of abstraction? (Canvas or Â Morphic ?) > Is there going to be a "camera" abstraction? ( just like Lumiere ) or who will know Â its current z transformation? first i want to implement morphic rendering pipeline which will use Rome canvas, instead of Canvas. Next, i want to replace PasteUpMorph (World) with own subclass, which will actually control the camera, zoom level etc. So, it will be a global desktop-level zoom&translation. A submorphs will be not aware of it. In this way, its a less work and less changes to existing Morphic (i hope). And of course, i want a clear separate layer (Rome canvas) which can be used by any other UI/graphics framework. > > 2. Regarding Text, will you reuse Paragraph and Editor already present in the system, or use an external library like Pango? > Â I was looking at the True Type font rendering demo, and everything seems pretty much into place, and now the "paragraph" layer must be implemented. > Initially, i will just do the simplest possible thing. Reuse what morpic provides. Text/paragraph rendering is a separate and very complex problem. Of course it would be cool to do things right, but not at initial iteration :) > How can i help? (Eventually...) > Anything you want. If you want something to be there, don't hesitate and dont wait for me - start coding :) My projects are public, they are open for contributions from anyone. Also, it would be cool to sync with Juan and his work on Morphic 3. I'd like to provide a GL backend for Morphic 3. But its unclear to me, what plans Juans having about it. Recently he said that he won't make any public releases. But i really hope that we could work together on it, because such ambitious projects need more than a single man in order to complete. > Fernando > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 7, 2010

Re: [Pharo-project] MicroSqueak [was System Tracer]

by Noury Bouraqadi

Thanks Eliot! I just downloaded Squeak 2.0 and start loading the MicroSqueak files. But, I encountered a strange problem. In the fileList, the MSqueak-Collections-Unordered.st file content isn't displayed and I can't load it. I get only this message in the fileList: For some reason, this file cannot be read Any hint? Noury On 7 oct. 2010, at 01:22, Eliot Miranda wrote: > FInd attached. You want MicroSqueak-colonequal.st and the various MSqueak-.st files. This produces a 57k image. John's also given me a 2.0 development image which will run on a 3.8 VM. Let me know if you want that. For me this is a proof of concept. What's needed is to define a headless core that contains the compiler, good error reporting to standard out, the core collection and numeric libraries and file support. Then we try and load packages into it and build up a headful image. > > On Wed, Oct 6, 2010 at 3:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: > > > > > > > On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > generate a new image. > > > > But that's not what it does. > > Yes I know gnerates = clone in my mail. > > > t merely clones an image, which is a long way form building an image form source. *That*'s a useful project. John Maloney's lovely MicroSqueak is a good starting point for ideas (basically have a copy of a kernel subset of the system in a namespace and generate a fresh image from that). > > Do you have a pointer on the code of john. We are looking at bootstrap code right now. > > > > > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > > > > > Hi! > > > > > > What do you want to achieve? > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > > > > > >> Hi > > >> > > >> Does anyone know where I can find the system tracer that is currently > > >> in use in Pharo? > > >> > > >> Bests > > >> Gabriel > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <MicroSqueak.tgz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 7, 2010

[Pharo-project] [ANN 1.2] new pre-built core#12172

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27578/PharoCore-1.2-12172.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 7, 2010