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

Re: [Pharo-project] [ANN] NativeBoost v 1.7

by Igor Stasenko

indeed, there's a problem.. something broke MC in my image.. i have NativeBoost-Core-IgorStasenko.87 NativeBoost-Core-IgorStasenko.88 NativeBoost-Core-IgorStasenko.89 in my image, and when i "save" it does not showing any errors.. but then no files appear in squeaksource and more than that, if i trying to open .mcz files in other image, they fail with errror.. something got broken in version history :( On 26 November 2012 21:04, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Thanks Igor for pushing the new version of NativeBoost. > Though, as Guy noted the Core package seems to be missing from squeaksource > > -- > Ciprian > > > On Mon, Nov 26, 2012 at 7:52 PM, Guy Hylton <guygantuan(a)gmail.com> wrote: >> >> Igor, >> >> Just looking to check out your and the contributors hard work but >> ConfigurationOf... refers to "NativeBoost-Core-IgorStasenko.88" which is not >> found? >> >> Guy >> >> On Mon, Nov 26, 2012 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >>> >>> Hi, there >>> >>> i'd like to announce new version of NativeBoost - 1.7. >>> >>> Here's an overview of changes comparing to previous version: >>> >>> - indirect argument in signatures. >>> You can now use special syntax to indicate that argument to external >>> function should be taken from n-th element of variable object (like >>> Array) >>> from method's argument or instance variable. >>> >>> Syntax: >>> >>> myMethod: args >>> <primitive: .... > >>> ^ self nbCall: #( void funFoo( int args@1 , float args@2 )) >>> >>> Usage: >>> >>> self myMethod: { 1 . 1.2 } >>> >>> Thanks to Ciprian Teodorov who proposed and implemented it. >>> >>> - Win32, features and examples: >>> >>> NBWin32Shell - an interface to use windows shell api >>> (executing commands, showing control panel settings) >>> >>> different examples for using HDC, message box etc. >>> >>> Thanks to Torsten Bergmann for contribution! >>> >>> And last bits, from me: >>> >>> A public API changes to avoid use of NBFFICallout global, and instead >>> use message(s) to denote FFI callout. >>> >>> Old syntax: >>> >>> NBFFICallout cdecl: #(...) emitCall: [ â¦ ] >>> >>> New syntax: >>> >>> self nbCallout function: #(â¦) emit: [â¦] >>> >>> >>> Old syntax: >>> >>> NBFFICallout cdecl: #(...) module: .. >>> >>> New syntax: >>> >>> self nbCallout cdecl function: #(â¦) module: â¦ >>> or: >>> self nbCallout function: #(â¦) module: â¦ >>> >>> because cdecl is default >>> >>> Old syntax: >>> >>> NBFFICallout cdecl: #(...) module: .. options: #(â¦) >>> >>> New syntax: >>> >>> self nbCallout cdecl; >>> options: #(â¦); >>> function: #(â¦) module: â¦ >>> >>> >>> Old syntax: >>> >>> NBFFICallout stdcall: #(...) module: .. options: #(â¦) >>> >>> New syntax: >>> >>> self nbCallout stdcall; >>> options: #(â¦); >>> function: #(â¦) module: â¦ >>> >>> ---- >>> >>> New API and syntax: >>> >>> self nbCallout function: <signature> address: [ address block ] >>> >>> generate code for calling a function located at given address with >>> given signature. >>> The address of function is provided by user in address block, which >>> should return a pointer to the function (NBExternalAddress or Unsigned >>> integer value, representing an absolute address of function). >>> This API is useful, when you need to call some function which is not >>> exported by via DLL symbol directly, but indirectly. >>> >>> The old NBFFICallout API is still there, but use of it is strongly >>> discouraged. And it will be removed eventually. So be warned! :) >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro -- Best regards, Igor Stasenko.

Nov. 26, 2012

[Pharo-project] Got our first pharo consortium contract :)

by StÃ©phane Ducasse

Hi guys This is a great day. We got our first pharo consortium contract signed by a great company: 2Denker :) Thanks for your trust! Soon the web site will get from the ground. Esteban got distracted by some VM bug chasing parties but he will be back on it. Stef

Nov. 26, 2012

Re: [Pharo-project] NativeBoost - new version new ideas ;)

by Ciprian Teodorov

and here is the fileout i have promised ;) On Mon, Nov 26, 2012 at 9:32 PM, Ciprian Teodorov < ciprian.teodorov(a)gmail.com> wrote: > 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 > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Nov. 26, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by Ciprian Teodorov

I don't know exactly why... but I tend to agree with Igor with this one... It's not that I like copy/paste, or that the <..> pragma is sexy but it seems to me that there will be too much going on under the hood but ... well I hope at least that the user will see the pragma to understand that something funky is going on -- Ciprian On Mon, Nov 26, 2012 at 5:57 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-11-26, at 12:45, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 26 November 2012 16:27, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >>>> > >>>> it's funny to see, but even when you gave your demo even you couldn't > type > >>>> the pragma definition yourself, so how do you except this to affect > newcomers? > >>> > >>> no need to convince me. > >>> of course i can type it.. but most of the time you copy/paster it from > >>> method to method. > >> > >> of course you can copy paste it, but if you can avoid it at all, why > would > >> you even bother copy pasting? > >> > >> besides your opal solution will be ready in > 2 months. > >> Actually we simply have to add a proper UI handler for the exception you > >> throw when there is no primitive installed. You let the programmer > decide > >> what to do => 100% safe > > > > it is your call. do it if you want it so badly :) > > yup I put it on ym todo > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Nov. 26, 2012

[Pharo-project] NativeBoost - new version new ideas ;)

by Ciprian Teodorov

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

Nov. 26, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.7

by Ciprian Teodorov

Thanks Igor for pushing the new version of NativeBoost. Though, as Guy noted the Core package seems to be missing from squeaksource -- Ciprian On Mon, Nov 26, 2012 at 7:52 PM, Guy Hylton <guygantuan(a)gmail.com> wrote: > Igor, > > Just looking to check out your and the contributors hard work but > ConfigurationOf... refers to "NativeBoost-Core-IgorStasenko.88" which is > not found? > > Guy > > On Mon, Nov 26, 2012 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: > >> Hi, there >> >> i'd like to announce new version of NativeBoost - 1.7. >> >> Here's an overview of changes comparing to previous version: >> >> - indirect argument in signatures. >> You can now use special syntax to indicate that argument to external >> function should be taken from n-th element of variable object (like >> Array) >> from method's argument or instance variable. >> >> Syntax: >> >> myMethod: args >> <primitive: .... > >> ^ self nbCall: #( void funFoo( int args@1 , float args@2 )) >> >> Usage: >> >> self myMethod: { 1 . 1.2 } >> >> Thanks to Ciprian Teodorov who proposed and implemented it. >> >> - Win32, features and examples: >> >> NBWin32Shell - an interface to use windows shell api >> (executing commands, showing control panel settings) >> >> different examples for using HDC, message box etc. >> >> Thanks to Torsten Bergmann for contribution! >> >> And last bits, from me: >> >> A public API changes to avoid use of NBFFICallout global, and instead >> use message(s) to denote FFI callout. >> >> Old syntax: >> >> NBFFICallout cdecl: #(...) emitCall: [ â¦ ] >> >> New syntax: >> >> self nbCallout function: #(â¦) emit: [â¦] >> >> >> Old syntax: >> >> NBFFICallout cdecl: #(...) module: .. >> >> New syntax: >> >> self nbCallout cdecl function: #(â¦) module: â¦ >> or: >> self nbCallout function: #(â¦) module: â¦ >> >> because cdecl is default >> >> Old syntax: >> >> NBFFICallout cdecl: #(...) module: .. options: #(â¦) >> >> New syntax: >> >> self nbCallout cdecl; >> options: #(â¦); >> function: #(â¦) module: â¦ >> >> >> Old syntax: >> >> NBFFICallout stdcall: #(...) module: .. options: #(â¦) >> >> New syntax: >> >> self nbCallout stdcall; >> options: #(â¦); >> function: #(â¦) module: â¦ >> >> ---- >> >> New API and syntax: >> >> self nbCallout function: <signature> address: [ address block ] >> >> generate code for calling a function located at given address with >> given signature. >> The address of function is provided by user in address block, which >> should return a pointer to the function (NBExternalAddress or Unsigned >> integer value, representing an absolute address of function). >> This API is useful, when you need to call some function which is not >> exported by via DLL symbol directly, but indirectly. >> >> The old NBFFICallout API is still there, but use of it is strongly >> discouraged. And it will be removed eventually. So be warned! :) >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Nov. 26, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.7

by Guy Hylton

Igor, Just looking to check out your and the contributors hard work but ConfigurationOf... refers to "NativeBoost-Core-IgorStasenko.88" which is not found? Guy On Mon, Nov 26, 2012 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, there > > i'd like to announce new version of NativeBoost - 1.7. > > Here's an overview of changes comparing to previous version: > > - indirect argument in signatures. > You can now use special syntax to indicate that argument to external > function should be taken from n-th element of variable object (like > Array) > from method's argument or instance variable. > > Syntax: > > myMethod: args > <primitive: .... > > ^ self nbCall: #( void funFoo( int args@1 , float args@2 )) > > Usage: > > self myMethod: { 1 . 1.2 } > > Thanks to Ciprian Teodorov who proposed and implemented it. > > - Win32, features and examples: > > NBWin32Shell - an interface to use windows shell api > (executing commands, showing control panel settings) > > different examples for using HDC, message box etc. > > Thanks to Torsten Bergmann for contribution! > > And last bits, from me: > > A public API changes to avoid use of NBFFICallout global, and instead > use message(s) to denote FFI callout. > > Old syntax: > > NBFFICallout cdecl: #(...) emitCall: [ â¦ ] > > New syntax: > > self nbCallout function: #(â¦) emit: [â¦] > > > Old syntax: > > NBFFICallout cdecl: #(...) module: .. > > New syntax: > > self nbCallout cdecl function: #(â¦) module: â¦ > or: > self nbCallout function: #(â¦) module: â¦ > > because cdecl is default > > Old syntax: > > NBFFICallout cdecl: #(...) module: .. options: #(â¦) > > New syntax: > > self nbCallout cdecl; > options: #(â¦); > function: #(â¦) module: â¦ > > > Old syntax: > > NBFFICallout stdcall: #(...) module: .. options: #(â¦) > > New syntax: > > self nbCallout stdcall; > options: #(â¦); > function: #(â¦) module: â¦ > > ---- > > New API and syntax: > > self nbCallout function: <signature> address: [ address block ] > > generate code for calling a function located at given address with > given signature. > The address of function is provided by user in address block, which > should return a pointer to the function (NBExternalAddress or Unsigned > integer value, representing an absolute address of function). > This API is useful, when you need to call some function which is not > exported by via DLL symbol directly, but indirectly. > > The old NBFFICallout API is still there, but use of it is strongly > discouraged. And it will be removed eventually. So be warned! :) > > > -- > Best regards, > Igor Stasenko. > >

Nov. 26, 2012

[Pharo-project] Running the full Pharo 1.4 Test Suite on the Raspberry Pi

by Sven Van Caekenberghe

Hi, Although it took a very long time (the non-Cog vm on the ARM is more than a full factor 10 slower than any MacBook), I am happy to report that the stock vm on the Raspberry Pi was capable of running the full Pharo 1.4 Test Suite, with the following result: 8547 run, 8483 passes, 53 expected failures, 5 failures, 6 errors, 0 unexpected passes Failures: ZnMagicCookieTests>>#testFromString ZnMagicCookieJarTests>>#testCookiesForUrl ZnMagicCookieJarTests>>#testCookieAtForUrl SharedQueue2Test>>#testCounting ZnMagicCookieJarTests>>#testAdd Errors: CompiledMethodTest>>#testPerformInSuperclassCanExecutelongMethodWithTemps CodeSimulationTests>>#testGettingSourceFromFile CodeSimulationTests>>#testTranscriptPrinting CodeSimulationTests>>#testTranscriptPrintingWithOpenedTranscriptExists MessageTallyTest>>#testClosedTally MessageTallyTest>>#testTallySends The Zn tests were actually already fixed, so updating Zn made them go away. I am afraid that running 2.0 is blocked on FileSystem requirements being to much for this older VM. Since FileSystem is also used in the startup sequence, we won't get very far. Camillo ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 26, 2012

Re: [Pharo-project] Athens OpenGL backend - what does it mean?

by dimitris chloupis

>I'm trying to understand... was it an alternative interface for >Blender, or an interface toolkit just happening to sit on top of >Blender? (or both?) No its an alternative interface for blender , bgl is nothing more than opengl stuff, but bare minimum opengl 1 stuff. Note that blender uses opengl for its own GUI API but I did not use that api at all. So it is a separate interface. Its basically Morphic , bare bones Morphic, but still Morphic. I was successful in providing a GUI API that is far more flexible compared to the existing Blender python GUI API and excels at custom made guis that the standard gui does not allow. However bgl is slow and quite buggy. > What really would interest me is your personal opinion on Smalltalk as > somebody coming from a Python background. That is, once you have more > experience with it (Smalltalk). I don't know much Python, but > considered it more than once because of something I didn't find in > other mainstream languages that I would miss from Smalltalk: named > parameters. Of course in Smalltalk you don't have that, since the > method signatures give you that for free ;-) I dont care about languages any more. I do not care about smalltalk the language. I dont believe language choice matters. There I said it. If smalltalk did not have this amazingly cool environment I would never have left python. I am actually quite happy with python, then one thing I did miss seriously was a good IDE. I used to be a Delphi coder back a decade ago , before being a python coder and Delphi had this amazing IDE in some areas even superior to smalltalk ide and pharo. So I was searching for a very good IDE for python and I found smalltalk, smalltalk has simple syntax like python and the IDE of high quality I came to love in Delphi. So I think it fits like a glove for my needs. Ironically both python and Delphi IDE have been deeply influence by the smalltalk language and enviroment. So it feels kinda of funny after 25 years of messing with coding to go back to the roots of all this. I am sure I am going to miss python's stability and library support but I think I am trading them off for something superior. > Conceptually I find Lisp also very interesting. But anytime I evaluate > going the Lisp route I find myself planning to reach first some > Lisp-based-Smalltalk syntax & semantics and then I say: why waste my > time if there *is* already Smalltalk, waiting to be used? :-) I dont think its hard to see that Lisp is THE language , well more like a family of languages. Lispers can be snobbish about other languages but they are correct lisp is superior even to smalltalk. There is little doubt in that. But again I do not believe language choice is that important , if it was people would not be making awesome software with other languages which they do. Its ironic because AI an area that lisp dominated is now dominated by python that goes fundamentally against the lisp philosophy and something that lispers quite correctly consider far inferior to lisp. Once again its the environment that attracted me , in this case emacs. Even though I decided to go with Pharo, Emacs is far from being out of the equation. I am still planning bringing emacs like text editing features to pharo for Ephestos. Long term plan but it is there. > I don't get it... which part will you port from Python to Smalltalk, > and which part you don't need/want to port? None. This is no longer a python project its pure smalltalk. I may create a python socket bridge for smalltalk to use python libraries and to access programms like Blender and mypaint etc. but is not big priority right now. Ephestos is basically an effort to improve pharo and make it more inviting to newcomers. If I can offer tools also useful to veteran smalltalkers that will be double win for me. > And Blender would... render 3d? (whilst the interface would be on the > Pharo side?) Yes , Ephestos and hence pharo would be able to control blender completely. Â > The idea of (socket) "brides" to other languages / runtimes always > made sense to me. At least short-term to break the library/devs cycle. > I don't know if this idea was evaluated by the community. Recently > there was an announcement of a bridge to a XUL (Mozilla) -based > frontend, with Smalltalk back-end, using Seaside's continuations. So > it should be easier as ever. my bridge already works and have been tested between 2 blenders , blender and cpython 3 , blender and cpython 2 and blender and pypy. Its in the proteas folder in the link I provided. So it just waits for me to port it to pharo XMLRPC library. Its just a matter of me getting familiar with pharo. Â > I very much liked what Stef wrote yesterday, it got me thinking: start > small and work steadily... Yes I agree with Stef of course. I dont plan to do anything very complicated most of the tools that I am planning are small additions to pharo . The only thing that takes time is for me to become familiar with pharo libraries, as soon as I do that I will be able to provide one tool after another in relative quick speed. Â > Good to see that you have such long-term plans! :-) I am not doing this just for pharo, I plan to use these tools for making art. My goal is to become a professional artist and I would love to build my owns tools and find alternative ways of artistic expression. Thus the long term process of the project. To give you a clear idea , I am trying to achieve something similar to this http://openendedgroup.com/field/OverviewBanners2.html At first Ephestos was supposed to be an extension of Field. But their support was non existant (the original developer obviously are busy with art projects ) and I needed help to understand the code, so I chose to go down the pharo route because if I had any problems I had much better chances to get it fixed in pharo than getting it fixed in Field. But Ephestos and Field are two projects with very similar goals. Thank you for your interest I will keep you posted with any significant progress.

Nov. 26, 2012

Re: [Pharo-project] MongoTalk update

by Esteban Lorenzano

MontoTalk does not handle it. Voyage does :) but... an "embedded collection" sounds strange to me... I don't really think that is correct. There is no such thing like embedded collection in a mongodb sense (If I'm understanding right you question). Let's say you have for example this: ObjectA(ObjectB, CollectionOfObjectC) If ObjectA is marked as Root, you will save a document with ObjectB and a collection of ObjectC embedded into it (but is not an embedded collection, is just a document who has embedded objects, no matter if that object happens to be an array or any kind of smalltalk collection). but, for example, if ObjectC is marked as a Root too, Voyage will save ObjectA as a document with a list of references to ObjectC. Then your database will have two collections: ObjectAs and ObjectCs Other thing is that Voyage is just a mapper, not a complete DB implementation, so, if you remove ObjectA (for instance), and there are not more references to ObjectC, you need to remove it from database manually, nor mongo, nor mongotalk, not voyage will handle that kind of situations for you :) Esteban On Nov 26, 2012, at 5:53 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 25/11/12 5:04 AM, Fernando Olivero wrote: >> Hi, this seems to answer your question. >> >> http://articles.tulipemoutarde.be/embedded-document-with-voyage-in-mongodb > > The model in that article has a one-to-many relation between a Spaceship and Pilots. The Pilot isPersistent/isRoot, so has its own MongoDB collection. IIUC, if Pilot were not persistent/root, then the collection of pilots would be serialized along with the Spaceship object, and there would be no separate Pilot collection in MongeDB. > > So my question is, how does MongoTalk handle the editing of the pilot collection, when it's embedded into the Spaceship. For example, if a pilot is added, removed, or updated, does the entire embedded collection get re-saved, or does a suitable MongoDB update query get generated? > > >

Nov. 26, 2012