November 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20422
by Marcus Denker Nov. 29, 2012

Nov. 29, 2012

20422 ----- Issue 7069: Better pop up menu entries http://code.google.com/p/pharo/issues/detail?id=7069 Issue 7068: Fixed smartCharacter http://code.google.com/p/pharo/issues/detail?id=7068 Issue 7066: Hot-Fix for MC version serializer http://code.google.com/p/pharo/issues/detail?id=7066 Diff information: http://ss3.gemstone.com/ss/Pharo20/NECompletion-MarcusDenker.68.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.729.diff http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.362.diff -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

1 0

[Pharo-project] Alt-. does not work anymore on Linux or?
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

Same issue with Stack VM. So it looks like it is image side. When the keyboard focus is in a workspace and I hit CMD+. it not directly interrupts. Only when I repeat very often. I've put a Transcript show: toInterrupt asString; cr. into UserInterruptHandler>>handleUserInterrupt and very often this block temporary variable is nil since #processToInterrupt returns nil. Sometimes the #processToInterrupt catches a process to interrupt and then the debugger opens. GÃ¶ran can you confirm that as well? Bye T.

2 2

[Pharo-project] Alt-. does not work anymore on Linux or?
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

On Win32 (german locale) I can not interrupt (Delay forSeconds: 10) wait. 1 inspect when using NBCog.exe as a VM. Even when I set a new key like ";" (without ALT) I can not interrupt the delay. |handler| handler := UserInterruptHandler new setInterruptKeyValue: ($; asciiValue). handler registerIn: InputEventFetcher default. (Delay forSeconds: 10) wait. 1 inspect I can not interrupt with ";" while the delay is waiting. But it interrupts aftewards when I hit ";". I'm not sure it is really a locale problem as described in http://code.google.com/p/pharo/issues/detail?id=6688 When I try 1.4 one click I have the same problem - the delay is not interruptable. When I try 1.3 one click I can interrupt. Can it be related to switching to Cog VM starting from 1.4? Bye T.

2 1

[Pharo-project] Alt-. does not work anymore on Linux or?
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

It's not a Linux issue. When I run (Delay forSeconds: 5) wait on Win32 with Pharo 2.0 I can also not interrupt it using ALT+. I checked and "UserInterruptHandler cmdDotEnabled" returns true in my image. Havent digged deeper. Can you please open an issue? Thx T.

2 1

[Pharo-project] NativeBoost extending Object
by Ciprian Teodorov Nov. 29, 2012

Nov. 29, 2012

Hi guys, Looking at NB methods extending Object I am wandering if it won't be better to put them in a Trait to be used by any class needing them? As for ByteArray maybe instead of using the methods inherited from Object maybe we can use a double-dispatch scheme to delegate NB calls to another class. This way we won't need to extend Object anymore... Igor, what do you think? (if you agree I will do it for NB)... I don't know if that will play well with existing NB-based projects though (Athens, NBOpenGL, etc...) But I think it is worth it on the long run... Cheers, -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

4 11

[Pharo-project] NativeBoost extending Object
by Igor Stasenko Nov. 29, 2012

Nov. 29, 2012

On 29 November 2012 08:29, Torsten Bergmann <astares(a)gmx.de> wrote: >>and i am not really happy with that. I prefer having 9 methods in Object >than 9*100 methods in many classes. > > What about having just one single method on Object called #externalCaller (or just #external) that returns an object understanding the > callout protocol. > > self externalCaller call: 'whatever' > > This wont overload Object but may require some fiddling since > "thisContext sender" is used. > > ... and this is what new api 'self nbCallout' provides. > > I also dislike the "namespacing" using "nb" in the selectors. > What if you rename or replace the project in the future? > > I would have to rename my methods from ffiCall: to alienCall: > to nbCall: ... ;) > a solution to this problem: use own convenience method(s).. then if you will ever need to get rid of namespace, all you need to do is change few methods. > Yes I know it is a different interface protocol from FFI to > NativeBoost - but still nobody is interested that the > subproject is called FFI/Alien/NativeBoost once it is > integrated in standard Pharo. > > You just want to do an external call like in any other > language and you are just interested that it works > reliable and easy. > > > And I would vote for a simple pragma <externalCall> > instead of > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > Sorry for all the wished ... but Christmas is near ... > did you behave well this year? you know Santa do not likes bad boys :) If serious.. we're evolving.. and it takes time and effort to change skins. Once we will be ready to get rid of namespace prefix, then we can abandon it, but not right now. > BTW: I marked 1.6 as release > 1.7 as stable > 1.8 as new development in the config > > We can also mark 1.7 as release since there was an official > announcement from Igor. Version 1.8 should get new developments. > > Thanks > Torsten -- Best regards, Igor Stasenko.

1 0

[Pharo-project] NativeBoost extending Object
by Torsten Bergmann Nov. 29, 2012

Nov. 29, 2012

>and i am not really happy with that. I prefer having 9 methods in Object >than 9*100 methods in many classes. What about having just one single method on Object called #externalCaller (or just #external) that returns an object understanding the callout protocol. self externalCaller call: 'whatever' This wont overload Object but may require some fiddling since "thisContext sender" is used. I also dislike the "namespacing" using "nb" in the selectors. What if you rename or replace the project in the future? I would have to rename my methods from ffiCall: to alienCall: to nbCall: ... ;) Yes I know it is a different interface protocol from FFI to NativeBoost - but still nobody is interested that the subproject is called FFI/Alien/NativeBoost once it is integrated in standard Pharo. You just want to do an external call like in any other language and you are just interested that it works reliable and easy. And I would vote for a simple pragma <externalCall> instead of <primitive: #primitiveNativeCall module: #NativeBoostPlugin> Sorry for all the wished ... but Christmas is near ... BTW: I marked 1.6 as release 1.7 as stable 1.8 as new development in the config We can also mark 1.7 as release since there was an official announcement from Igor. Version 1.8 should get new developments. Thanks Torsten

1 0

[Pharo-project] NativeBoost - new version new ideas ;)
by Ciprian Teodorov Nov. 29, 2012

Nov. 29, 2012

Hi Igor, While I'm waiting impatiently for the new NB version I played around some more and I have noted some ideas: First thing is related to structures and callbacks... what if I want to have a callback as a member of a structure? It seems to me that the way to go is to declare a MyCallback class and then use it in the structure, which is fair enough. But what if I have a function that initializes this structure with a user provided callback? Then the structure is not printed correctly. It seems that #*coerceReturnValue: is not implemented in the NBCallbackType... * *While this is not a big issue it made me think that I was doing something wrong... Maybe in this case we can instantiate MyCallback class and put the fct pointer in in trunk ivar.* Secondly, related to structs again... It seems that we can define structures like: struct { void *a[2]; } only by transforming them to struct { void *a1; void *a2; } Am I wrong... if not maybe we can extend a little bit the syntax for defining structs to accept the first form... which will be far easier to write if we have large index values like void *x[20]... What do you think? Lastly, seeing that we are starting to have support for most of c-like declarations, i am not really satified with the way the enums should be handled... Maybe we can reify them as some kind of external object so that we can say something like: enum { AAA = 1, BBB = 2, }; MyEnum AAA (to get the item AAA of the enum) MyEnum BBB value = 2 and behind the enumeration is defined as a Dictionary of item->value mappings. Attached to this mail you will find a fileout of such an approach... I agree that maybe this is not the most optimized way of dealing with enums, however I like this approach because it is uniform (with structs, external objects, external addresses, callbacks, etc). Moreover if a beginner wants to hack his way into NB FFI I think it is easier to cope with an enum object than with SharedPools defined in classes, and imported. Cheers, PS: I can't way to get my hand on the new version... -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

2 2

[Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API
by Igor Stasenko Nov. 28, 2012

Nov. 28, 2012

Hi, i am thinking about redesign of FFI top-level api, because it not very good. First thing is that NBFFICallout referenced in too many places (187 in my image). So, from one side, we should encourage using a convenience syntax, using self nbCall: .. instead of NBFFICallout ... but there's one more thing: - a code generator has many different ways of use, and i actually going to add another one, but i see that it will explode the protocol(s) without make it convenient to use. Imagine that you want to generate a callout to function, which address cannot be obtained directly from external library. This is actually a real issue, which Esteban met when implementing bindings to Chipmunk library: - some functions are not exposed directly by dynamic library, but indirectly: the symbol(s) which library exports is not direct pointer(s) to functions but instead a pointers to variable, where the function pointer is stored. So, in order to get function pointer , one needs first to get a pointer to symbol, and then read the pointer value at that address. So, i thought that i would simply add new protocol to NBFFICallout: call: anonFunctionSignature convention: callConvention functionAddress: aFunctionAddressBlock Then, one could use it like: myMethod <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ NBFFICallout call: #( int () ) convention: #cdecl functionAddress: [ self getPointerTo: 'functionname' ] but it is too elaborate.. you can imagine that if one would like to implement a more convenient form, he could just do: myMethod <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ self indirectCall: #( int () ) name: 'functionname' or even: myMethod <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ self indirectCall: #( int functionname () ) now the problem is that you cannot wrap the NBFFICallout method in order to implement convenience method, because of use of thisContext. I also concerned about exploding NBFFICallout public API.. which imo doesn't makes much sense, because we should encourage the use of convenience methods. So, i looking for improving public API: - First thing is getting rid of direct references to NBFFICallout.. - second thing is avoid tying public API with thisContext (so you can create own convenience methods without much hassle). So, lets imagine what and how we can do it: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ NBFFICallout cdecl: #( int foo() ) module: 'bar' 1. getting rid of global: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout cdecl: #( int foo() ) module: 'bar' 2. separating the call convention from signature: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout cdecl call: #( int foo() ) module: 'bar' 3. as a bonus, since cdecl is most used, we can assume it is default: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout call: #( int foo() ) module: 'bar' 4. avoid hardcoding module: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout call: #( int foo() ) module: self module 5. pass code generation options as a separate message, instead of additional keyword: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout options: #( +optFoo - optBar); call: #( int foo() ) module: self module 6. finally users would want to do it in most convenient way: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self call: #( int foo() ) Which means that #call: is convenience method which they implement by themselves. Here how i think it should look like: call: fnSpec ^ (self nbCalloutIn: thisContext sender) cdecl; options: #(+optFoo - optBar); call: fnSpec module: self module. If you look at current implementation of Object>>nbCall: nbCall: fnSpec " you can override this method if you need to" | sender | sender := thisContext sender. ^ NBFFICallout handleFailureIn: sender nativeCode: [ :gen | gen sender: sender; callType: self nbCallingConvention; generateCall: fnSpec module: self nbLibraryNameOrHandle] it is almost the same, except from cryptic use of blocks, and private internal NBFFICallout methods which doing the job. So, basicly, i want to get rid of NBFFICallout class >> [cdecl/stdcall]: module: [options:] [cdecl/stdcall]: emitCall: [options:] and replace them with #call:module: and #call: emit: and also add new one: #call:address: which can be used for passing a function pointer directly. And any future extensions to public API will be a single method. Not 2,3 or more, like today.. -- Best regards, Igor Stasenko.

4 13

[Pharo-project] monticello not tracking recategorization
by Camillo Bruni Nov. 28, 2012

Nov. 28, 2012

currently monticello does not track method recategorization! anybody has a direct hint where to look at? in the mean time I start a binary search on the images to figure out when we introduced the bug...

2 1