yeah, what I did was bypass the type checking, not a really solution... we need something better. On May 5, 2013, at 12:18 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:

I remember Esteban had some similar problem when working on the ObjCBridge... Esteban? :D

On Sun, May 5, 2013 at 12:14 PM, Max Leske <maxleske@gmail.com> wrote: I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy.

Here's my use case:

self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type))

This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so:

self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type))

But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. Being able to use a superclass would just be awesome!

Cheers, Max

Thanks Igor. I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? I hope this doesn't seem like a dumb question, I'm just curious. On 05.05.2013, at 17:43, Igor Stasenko <siguctua@gmail.com> wrote:

On 5 May 2013 12:14, Max Leske <maxleske@gmail.com> wrote:

...

I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy.

Here's my use case:

self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type))

This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so:

self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type))

But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. Being able to use a superclass would just be awesome!

Cheers, Max

As i told before, i am not using membership test, because it costs extra cycles e.g..

object isKindOf: CommonSuperClass

is much slower than

object class == SomeSpecificClass

if you look at NBExternalObjectType>>pushAsValue: / pushAsPointer: it only checks that object belongs to specific class, doing self verifyClassOf: oop is: objectClass generator: gen.

The InterpreterProxy has #includesBehavior:ThatOf: method, which can be used to test if given class has some specific ancestor in its inheritance chain.

The main reason why i did not implemented the code that way is performance. It is not that hard to implement this kind of test (see attached) ===========

Btw, we have a problem:

- NativeBoost-Core in my 3.0 image shows that last version of it is EstebanLorenzano.116 there is not such package in NB repository. It is in Pharo30 repository.. but when i open it, it shows that it has ancestor NativeBoost-Core-cb.117

Name: NativeBoost-Core-EstebanLorenzano.118 Author: EstebanLorenzano Time: 23 April 2013, 5:52:38.099 pm UUID: d256a011-ce1f-4959-b5ed-37de2c7f3b84 Ancestors: NativeBoost-Core-cb.117

which is not there. Now i cannot merge with code which is in project repository.

We should discuss, how we manage updates for NB.. because searching packages located in multiple repositories is tedious and counterproductive.

-- Best regards, Igor Stasenko. <NBExternalType-verifyClassOfisMemberOfgenerator.st>

On 05.05.2013, at 23:06, Igor Stasenko <siguctua@gmail.com> wrote:

On 5 May 2013 22:19, Max Leske <maxleske@gmail.com> wrote:

...

Thanks Igor.

I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? I hope this doesn't seem like a dumb question, I'm just curious.

err.. im not sure i understand. You either do the type check or you don't, and then get error if you pass wrong object, or crash. There is no 3rd option :)

Yes, that was the idea. Only with the thought of doing the type check for the user. Something like this: [ <perform call without typecheck> ] on: Error do: [ :e | (type isKindOf: expected) ifTrue: [ NBCalloutFailed signal: 'expected…' ] ifFalse: [ e pass ] ]. But that's only cool if possible without more VM crashes.

We can, however, introduce an option so you can turn strict type check on/off , or turn it off completely.

That's a pretty cool idea actually. What about extending that idea: 1. replace current typecheck with an #isKindOf: check 2. add option to turn typecheck on / off. Then we'd have great feedback during development and would still be fast in production by disabling the typecheck. What do you think?

...

On 05.05.2013, at 17:43, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 5 May 2013 12:14, Max Leske <maxleske@gmail.com> wrote:

...

I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy.

Here's my use case:

self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type))

This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so:

self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type))

But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. Being able to use a superclass would just be awesome!

Cheers, Max

As i told before, i am not using membership test, because it costs extra cycles e.g..

object isKindOf: CommonSuperClass

is much slower than

object class == SomeSpecificClass

if you look at NBExternalObjectType>>pushAsValue: / pushAsPointer: it only checks that object belongs to specific class, doing self verifyClassOf: oop is: objectClass generator: gen.

The InterpreterProxy has #includesBehavior:ThatOf: method, which can be used to test if given class has some specific ancestor in its inheritance chain.

The main reason why i did not implemented the code that way is performance. It is not that hard to implement this kind of test (see attached) ===========

Btw, we have a problem:

- NativeBoost-Core in my 3.0 image shows that last version of it is EstebanLorenzano.116 there is not such package in NB repository. It is in Pharo30 repository.. but when i open it, it shows that it has ancestor NativeBoost-Core-cb.117

Name: NativeBoost-Core-EstebanLorenzano.118 Author: EstebanLorenzano Time: 23 April 2013, 5:52:38.099 pm UUID: d256a011-ce1f-4959-b5ed-37de2c7f3b84 Ancestors: NativeBoost-Core-cb.117

which is not there. Now i cannot merge with code which is in project repository.

We should discuss, how we manage updates for NB.. because searching packages located in multiple repositories is tedious and counterproductive.

-- Best regards, Igor Stasenko. <NBExternalType-verifyClassOfisMemberOfgenerator.st>

-- Best regards, Igor Stasenko.

On 06.05.2013, at 00:58, Igor Stasenko <siguctua@gmail.com> wrote:

On 5 May 2013 23:59, Max Leske <maxleske@gmail.com> wrote:

...

On 05.05.2013, at 23:06, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 5 May 2013 22:19, Max Leske <maxleske@gmail.com> wrote:

...

Thanks Igor.

I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? I hope this doesn't seem like a dumb question, I'm just curious.

err.. im not sure i understand. You either do the type check or you don't, and then get error if you pass wrong object, or crash. There is no 3rd option :)

Yes, that was the idea. Only with the thought of doing the type check for the user. Something like this:

[ <perform call without typecheck> ] on: Error do: [ :e | (type isKindOf: expected) ifTrue: [ NBCalloutFailed signal: 'expected…' ] ifFalse: [ e pass ] ].

But that's only cool if possible without more VM crashes.

...

We can, however, introduce an option so you can turn strict type check on/off , or turn it off completely.

That's a pretty cool idea actually. What about extending that idea: 1. replace current typecheck with an #isKindOf: check 2. add option to turn typecheck on / off.

Then we'd have great feedback during development and would still be fast in production by disabling the typecheck. What do you think?

I will add the option. But default will be same like now e.g. strict obj class == class.

Ok, cool.

Btw, what stops you from implementing own marshaller with semantics you want?

In your case, make subclass of NBExternalObjectType, override methods there. Then to make your code use new marshaller, if you use MyClass in function signature e.g.:

nbCall: #(void foo( MyClass param) )

create a MyClass class>>asNBExternalType: method, which will answer an instance of your new marshaller. (same what NBExternalObject does).

Thanks for the advice. I'll do that.

-- Best regards, Igor Stasenko.

On May 5, 2013, at 5:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:

- NativeBoost-Core in my 3.0 image shows that last version of it is EstebanLorenzano.116 there is not such package in NB repository. It is in Pharo30 repository.. but when i open it, it shows that it has ancestor NativeBoost-Core-cb.117

Name: NativeBoost-Core-EstebanLorenzano.118 Author: EstebanLorenzano Time: 23 April 2013, 5:52:38.099 pm UUID: d256a011-ce1f-4959-b5ed-37de2c7f3b84 Ancestors: NativeBoost-Core-cb.117

no, because that's the "integrated one"... that's how the current integrator works. That's why my name is in so many packages now :) but seriously, the package is the result of the merge of the latest stable that we integrate with the one that was there before. So, it should be exactly the same as you have in Pharo/NativeBoost repo... since we (afaik) do not integrate any NB change. and yes, I'm working in a new integrator that can work in project basis, but my times are also limited so it will be ready... when it is ready :) Esteban