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

Re: [Pharo-project] Topics for a term project in CG

by Igor Stasenko

On 24 October 2012 00:09, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Oh, well, I'll jump in as I spend an inordinate amount of time learning > about that text stuff. > > One requirement I'd love t see covered: have a proper text model that scales > when the size of the text increases a lot. > > What is currently implemented is not that bad, it is just with too many > layers and documentation is poor. > > But most of what's in there is needed for rendering the text, laying out the > material. > > It just does it badly, and gets the fonts metrics wrong (italics, bold...). > > And also, the TextMorph is married with the SHStyler and SmalltalkEditor for > no good reason at all. > > What would be great is already a BasicTextMorph with a BasicEditor that just > edit a Text with TextAttributes. > > This would leave out the Smalltalk marriage and provide a good enough > foundation to build upon. Yeah.. this stuff cries for cleanup. The current code is a result of different people at different time(s) adding more and more code to it without revising / cleaning it up. > > Phil > > 2012/10/23 Denis Kudriashov <dionisiydk(a)gmail.com> >> >> Hello >> >> 2012/10/23 Igor Stasenko <siguctua(a)gmail.com> >>> >>> Also, recently we started working on new text model. With the goal to >>> replace an clean Text, >>> text editing and text layout in our system (and sure thing , >>> rendering). This is also requires a lot of work. >> >> >> I am very interesting in details. Do you have description or code >> somewhere? >> >> I always think about new text editor implementation based on Presenty. I >> want remove all hardcoded stuff like cursor navigation arrow keys, >> copy/paste shortcuts, keyboard based characters input. >> User should have facility to specify how execute such primitive actions. >> For example, user can just draw characters on screen to input it or input it >> by voice. User can add buttons to move cursor, can add visual keyboard >> (maybe native for OS). >> >> And I think about subclassing TextMorph to implement my ideas. But >> TextMorph is so crappy. So I will be happy if somebody give me clean >> implementation of TextMorph. > > -- Best regards, Igor Stasenko.

Oct. 24, 2012

Re: [Pharo-project] Is Athens a good candidate from my project "Ephestos" ?

by Igor Stasenko

On 23 October 2012 23:07, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > Ok thanks for the clarification, I understand now. > > I don't have any issue contributing to the project. From what I see Athens > is orientated towards freeform graphics which is what I want to achieve > anyway. I only hope my coding skills are enough to make a satisfactory > contribution. Thanks I will now search for documentation and read the code. > There's no documentation ready yet. But to get the basics, look at AthensSurfaceExamples code. It covers most of basic operations and functionality available. -- Best regards, Igor Stasenko.

Oct. 24, 2012

Re: [Pharo-project] BlockClosure>>ensure: implementation

by Eliot Miranda

On Mon, Oct 22, 2012 at 2:17 AM, ClÃ©ment Bera <clement.bera(a)inria.fr> wrote: > Hello, > > I don't understand something on BlockClosure>>ensure:. Why does it use > 'self valueNoContextSwitch' and not 'self value' ? In which case is there > an issue ? Prior to my closure implementation BlockContext>>value[:value:*] was not a context switch point. So to preserve the threading semantics of ensure: we implemented ensure: in terms of BlockClosure>>valueNoContextSwitch, which is not a context-switch point, as opposed to BlockClosure>>value[:value:*]. The context switch points in the VM are non-primitive sends (or failing primitives, i.e. full method activation), backward branches, the Process primitives suspend, resume, signal and wait (and CrtiticalSection/Mutex enter and exit) and block evaluation. > > Thank you for any answers > > BlockClosure>>ensure: is implemented this way : > > ensure: aBlock > "Evaluate a termination block after evaluating the receiver, regardless of > whether the receiver's evaluation completes. N.B. This method is *not* > implemented as a primitive. Primitive 198 always fails. The VM uses prim > 198 in a context's method as the mark for an ensure:/ifCurtailed: > activation." > > | complete returnValue | > <primitive: 198> > returnValue := *self valueNoContextSwitch*. > complete ifNil:[ > complete := true. > aBlock value. > ]. > ^ returnValue > > -- best, Eliot

Oct. 23, 2012

Re: [Pharo-project] Topics for a term project in CG

by phil＠highoctane.be

Oh, well, I'll jump in as I spend an inordinate amount of time learning about that text stuff. One requirement I'd love t see covered: have a proper text model that scales when the size of the text increases a lot. What is currently implemented is not that bad, it is just with too many layers and documentation is poor. But most of what's in there is needed for rendering the text, laying out the material. It just does it badly, and gets the fonts metrics wrong (italics, bold...). And also, the TextMorph is married with the SHStyler and SmalltalkEditor for no good reason at all. What would be great is already a BasicTextMorph with a BasicEditor that just edit a Text with TextAttributes. This would leave out the Smalltalk marriage and provide a good enough foundation to build upon. Phil 2012/10/23 Denis Kudriashov <dionisiydk(a)gmail.com> > Hello > > 2012/10/23 Igor Stasenko <siguctua(a)gmail.com> > >> Also, recently we started working on new text model. With the goal to >> replace an clean Text, >> text editing and text layout in our system (and sure thing , >> rendering). This is also requires a lot of work. >> > > I am very interesting in details. Do you have description or code > somewhere? > > I always think about new text editor implementation based on Presenty. I > want remove all hardcoded stuff like cursor navigation arrow keys, > copy/paste shortcuts, keyboard based characters input. > User should have facility to specify how execute such primitive actions. > For example, user can just draw characters on screen to input it or input > it by voice. User can add buttons to move cursor, can add visual keyboard > (maybe native for OS). > > And I think about subclassing TextMorph to implement my ideas. But > TextMorph is so crappy. So I will be happy if somebody give me clean > implementation of TextMorph. >

Oct. 23, 2012

Re: [Pharo-project] Is Athens a good candidate from my project "Ephestos" ?

by dimitris chloupis

Ok thanks for the clarification, I understand now. I don't have any issue contributing to the project. From what I see Athens is orientated towards freeform graphics which is what I want to achieve anyway. I only hope my coding skills are enough to make a satisfactory contribution. Thanks I will now search for documentation and read the code. ----- Original Message ----- From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Cc: Sent: Tuesday, 23 October 2012, 22:28 Subject: Re: [Pharo-project] Is Athens a good candidate from my project "Ephestos" ? On 23 October 2012 18:08, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > Igor wanted to ask you but kept forgetting. I wanted to make my own GUI api > for project "Ephestos" which is visual coding for pharo and 3d app Blender. > At first NBOpenGL was a candidate , but now I also consider Athens , > especially if you say you want to port morphic to it. > Let me explain a bit about Athens: Athens is an API for vector-based 2D graphics. It was designed with layered architecture in mind: there is a top-level (user) API, and implementation , which can use one or another backend. Like that, users can be confident that no matter what rendering backend is used, they don't have to adapt to it, and just keep using same API for drawing. Currently there is 2 backends: balloon (using VM plugins) and cairo (using cairo library). Other backends could be: OpenGL, OpenVG, Quartz(native Mac OS vector engine) Btw cairo also provides quartz and openvg as one of its backends, so, in short run with some effort we can use cairo for those backends.. but in a long run it would be much better, of course, to provide backends to use these frameworks directly , avoiding extra wrapping layer , such as cairo. Also, i read that Mozilla moves to a new , faster & better rendering engine (can't remember its name), which benefits from multicore hardware, so there's a lot of choices.. > I am certainly interested in vector based GUIs but another thing that > interest me is GUIs with loads of animations like the ones you see in games. > You think Athens is fast enough to be used for such busy interfaces ? it is too early to judge how fast it is , because currently i am at "make it work" stage, not "make it fast". However the benchmarking drawing full morphic desktop (all windows & morphs) is already quite promising - they show comparable performance of balloon engine (a bit faster , in fact, but just because i am still cannot render the text morphs). Cairo is faster than balloon.. but since there is many conversion(s) happen to pass data to it (like converting forms to cairo surfaces, converting gradients etc), it suffers from it at bit. But that can be mitigated by introducing caching etc. And of course, if you going to implement own (non-morphic) UI which using Athens, you can deal much better with these caveats. I paying a lot of attention in Athens to make sure API does not comes with big overhead. It is yet to be seen, if i succeeded, because there's always some tradeoffs, basically: how to provide a nice object-oriented API to end users, without exposing them to nasty and muddy world of C functions which doing real job. > I would prefer to make my own widgets / morphs and move away from the standard > look of windows and buttons and more make it look like GUIs you see in games > and Sci Fi movies since the fun factor is a big goal in my project. Since > you are experienced in this than me , what you think ? > > The problem with NBOpenGL is that I fear I will have a lot more work to do, > but that is debatable. Of course you implementing morphic in Athens even > partially makes my life a lot easier. > I wish to start implementing Athens backend for NBOpenGL.. but that's only plans now. I have no time for it. If you maybe know, recently NVidia release an opengl extension for 2D vector graphics, which provides quite good API for 2D vector-based rendering. And i checked and my Mac OS X 10.7.5 already contains that extension. http://developer.nvidia.com/nv-path-rendering so, the idea is not to implement all computation(s) and path(s) by yourself using opengl, but to bind to this functionality. Hopefully, after couple of years , this extension will find its way to most graphic cards/GL drivers, not just NVidia ones. (and if you worry about speed, this thingy is 100-1000 x faster than cairo ;) > Another question I have is do I need Cairo installed to use Athens ? I would > rather use something that does not require installations from the user. If > yes is it possible to package Cairo with Pharo and Athens ? > The idea now is to ship VMs bundled with cairo libraries. Because balloon backend i made is quite limited, shitty and slow and was made mostly to develop & test Athens api (still it can be used as a last resort, when nothing better available)). Today i finally made cairo build successfully on windows (already did that for Mac), and on linux(es), cairo is already installed on system(s) by default, so there is nothing to care about from user's perspecitve (well, except from some minimalistic/exotic distributions, which does not includes it). > If anyone else want to jump and advice me, I am more than welcome it. > P.S. Needless to say, that i would be happy if you can join and help developing Athens. Or even if you decide to just use it, it will also help a lot for finding/fixing bugs and improve quality and performance. The Athens (like Pharo) is open-source project from its very birth, and open for any contributions by anyone. -- Best regards, Igor Stasenko.

Oct. 23, 2012

Re: [Pharo-project] Topics for a term project in CG

by Igor Stasenko

On 23 October 2012 21:01, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello > > > 2012/10/23 Igor Stasenko <siguctua(a)gmail.com> >> >> Also, recently we started working on new text model. With the goal to >> replace an clean Text, >> text editing and text layout in our system (and sure thing , >> rendering). This is also requires a lot of work. > > > I am very interesting in details. Do you have description or code somewhere? > > I always think about new text editor implementation based on Presenty. I > want remove all hardcoded stuff like cursor navigation arrow keys, > copy/paste shortcuts, keyboard based characters input. > User should have facility to specify how execute such primitive actions. For > example, user can just draw characters on screen to input it or input it by > voice. User can add buttons to move cursor, can add visual keyboard (maybe > native for OS). > Take a look at http://www.smalltalkhub.com/#!/~sig/TxText there's already a working (since tests are green ;) implementation of new text model. And, as you said, you don't have to deal with hardcoded stuff. The text model provides a 'position' API, which can be used to navigate text directly: - moveLeft, moveRight, lineUp, lineDown etc There's also a 'selection' model, which allows you to 'cut' , or 'replace' portions of text at given position. So, the text model designed by having text editor in mind. I am working on making attributes work for it (bold/italic etc).. and then renderer, layouting and editor(s). Well, actually editor will be most simplest piece of puzzle after i finish all the bottom layers :) If you wanna join and help, you're wellcome.. because i am stretched today between many things: NB, Athens, VMs > And I think about subclassing TextMorph to implement my ideas. But TextMorph > is so crappy. So I will be happy if somebody give me clean implementation of > TextMorph. hehe , stand in a line then. You will be after me :) Everyone wants something better than TextMorph, but nobody wants to make it real :) -- Best regards, Igor Stasenko.

Oct. 23, 2012

Re: [Pharo-project] Is Athens a good candidate from my project "Ephestos" ?

by Igor Stasenko

On 23 October 2012 18:08, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > Igor wanted to ask you but kept forgetting. I wanted to make my own GUI api > for project "Ephestos" which is visual coding for pharo and 3d app Blender. > At first NBOpenGL was a candidate , but now I also consider Athens , > especially if you say you want to port morphic to it. > Let me explain a bit about Athens: Athens is an API for vector-based 2D graphics. It was designed with layered architecture in mind: there is a top-level (user) API, and implementation , which can use one or another backend. Like that, users can be confident that no matter what rendering backend is used, they don't have to adapt to it, and just keep using same API for drawing. Currently there is 2 backends: balloon (using VM plugins) and cairo (using cairo library). Other backends could be: OpenGL, OpenVG, Quartz(native Mac OS vector engine) Btw cairo also provides quartz and openvg as one of its backends, so, in short run with some effort we can use cairo for those backends.. but in a long run it would be much better, of course, to provide backends to use these frameworks directly , avoiding extra wrapping layer , such as cairo. Also, i read that Mozilla moves to a new , faster & better rendering engine (can't remember its name), which benefits from multicore hardware, so there's a lot of choices.. > I am certainly interested in vector based GUIs but another thing that > interest me is GUIs with loads of animations like the ones you see in games. > You think Athens is fast enough to be used for such busy interfaces ? it is too early to judge how fast it is , because currently i am at "make it work" stage, not "make it fast". However the benchmarking drawing full morphic desktop (all windows & morphs) is already quite promising - they show comparable performance of balloon engine (a bit faster , in fact, but just because i am still cannot render the text morphs). Cairo is faster than balloon.. but since there is many conversion(s) happen to pass data to it (like converting forms to cairo surfaces, converting gradients etc), it suffers from it at bit. But that can be mitigated by introducing caching etc. And of course, if you going to implement own (non-morphic) UI which using Athens, you can deal much better with these caveats. I paying a lot of attention in Athens to make sure API does not comes with big overhead. It is yet to be seen, if i succeeded, because there's always some tradeoffs, basically: how to provide a nice object-oriented API to end users, without exposing them to nasty and muddy world of C functions which doing real job. > I would prefer to make my own widgets / morphs and move away from the standard > look of windows and buttons and more make it look like GUIs you see in games > and Sci Fi movies since the fun factor is a big goal in my project. Since > you are experienced in this than me , what you think ? > > The problem with NBOpenGL is that I fear I will have a lot more work to do, > but that is debatable. Of course you implementing morphic in Athens even > partially makes my life a lot easier. > I wish to start implementing Athens backend for NBOpenGL.. but that's only plans now. I have no time for it. If you maybe know, recently NVidia release an opengl extension for 2D vector graphics, which provides quite good API for 2D vector-based rendering. And i checked and my Mac OS X 10.7.5 already contains that extension. http://developer.nvidia.com/nv-path-rendering so, the idea is not to implement all computation(s) and path(s) by yourself using opengl, but to bind to this functionality. Hopefully, after couple of years , this extension will find its way to most graphic cards/GL drivers, not just NVidia ones. (and if you worry about speed, this thingy is 100-1000 x faster than cairo ;) > Another question I have is do I need Cairo installed to use Athens ? I would > rather use something that does not require installations from the user. If > yes is it possible to package Cairo with Pharo and Athens ? > The idea now is to ship VMs bundled with cairo libraries. Because balloon backend i made is quite limited, shitty and slow and was made mostly to develop & test Athens api (still it can be used as a last resort, when nothing better available)). Today i finally made cairo build successfully on windows (already did that for Mac), and on linux(es), cairo is already installed on system(s) by default, so there is nothing to care about from user's perspecitve (well, except from some minimalistic/exotic distributions, which does not includes it). > If anyone else want to jump and advice me, I am more than welcome it. > P.S. Needless to say, that i would be happy if you can join and help developing Athens. Or even if you decide to just use it, it will also help a lot for finding/fixing bugs and improve quality and performance. The Athens (like Pharo) is open-source project from its very birth, and open for any contributions by anyone. -- Best regards, Igor Stasenko.

Oct. 23, 2012

Re: [Pharo-project] Topics for a term project in CG

by Denis Kudriashov

Hello 2012/10/23 Igor Stasenko <siguctua(a)gmail.com> > Also, recently we started working on new text model. With the goal to > replace an clean Text, > text editing and text layout in our system (and sure thing , > rendering). This is also requires a lot of work. > I am very interesting in details. Do you have description or code somewhere? I always think about new text editor implementation based on Presenty. I want remove all hardcoded stuff like cursor navigation arrow keys, copy/paste shortcuts, keyboard based characters input. User should have facility to specify how execute such primitive actions. For example, user can just draw characters on screen to input it or input it by voice. User can add buttons to move cursor, can add visual keyboard (maybe native for OS). And I think about subclassing TextMorph to implement my ideas. But TextMorph is so crappy. So I will be happy if somebody give me clean implementation of TextMorph.

Oct. 23, 2012

Re: [Pharo-project] NativeBoost FFI

by Igor Stasenko

sorry, it looks like i forgot to hit 'save' button after adding you to project. On 23 October 2012 19:35, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi Igor, > > There seems to be an issue with the squeaksource repo... I don't see myself > listed amongst the developers nor can I commit > > I'm using this connection string: > > MCHttpRepository > location: 'http://www.squeaksource.com/NativeBoost' > > > user: 'cip.t' > password: '*******' > > > Cheers > Ciprian > > On Tue, Oct 23, 2012 at 10:20 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> HI, Ciprian. >> I added you to developers. >> >> Just single comment about auto-generated wrapper(s)/bindings: >> You need to do it only once. Then it will not be needed. >> >> Yes, you can do it automated or manually (automated is preferred), but >> since you do it only once, even if manually, this is not going to be >> too big bottleneck. >> Sure things, having a tool(s) which can automate that would be nice. >> But according to my experience, you can automate it only partially, >> but not fully. >> There , of course, exceptions like OpenGL library which API design >> allows to automate wrapping. >> >> And sure thing it would be nice to have some code generators to import >> from C header(s). >> >> >> On 22 October 2012 19:52, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> wrote: >> > Hi guys, >> > >> > First of all sorry for not saying anything the whole day ... but I don't >> > have internet connection at work. I hope I'll be excused though ;) >> > >> > Now it will be a difficult for me to address all the issues raised ... >> > however I will try >> > >> > First of all, IMHO any FFI should facilitate the task of the person >> > writing >> > the library wrapper. >> > This comes the issue of (hopefully automatically) parsing C headers and >> > generating the calls. >> > Why?... well because if I take for instance the BLAS/LAPACK case (which >> > was >> > cited today) have over 1000 functions exported. >> > Even if it is not 1000 lets say that you have a smaller library from >> > which >> > you want to use only one function X but in order to use that precise >> > function you will maybe have to initialize some C context data, or a >> > specific data structure. >> > Of course you can do that by hand, but what if you really want to >> > benefit >> > from the library without diving into the details... well in that case >> > you >> > are a little bit stuck, either you write by hand a bunch of wrappers or >> > you >> > quit. >> > >> > The problem is that nice libraries that you want to use they usually >> > have >> > horrible data structures behind that you cannot set up easily. This >> > happened >> > to me several times in the future while trying to use different external >> > library calls (graphviz, metis, abc, vpr to name a few) in Pharo (with >> > FFI, >> > with Alien, etc). In almost all cases I ended up generating text files >> > and >> > calling some bloody c program using these files as input. The problem is >> > that has a huge impact on performances... >> > >> > Now with nativeboost I found it pretty easy to automatically generate >> > some >> > usable binding... I parsed the C headers with srcml, the I have parsed >> > the >> > XML looking for function definitions... For these definitions I've >> > generated >> > the wrappers. Only that for over 15 argument functions that did not >> > work. >> > >> > Now, I do not like the idea of hacking the compiler, or even subclassing >> > it >> > like Nicolas did for Smallapack. And luckily we do not need to do that >> > with >> > the arguments in an array trick... Moreover, I completely agree with >> > Igor on >> > the fact that 15 arguments are to many, however Pharo really needs to >> > have >> > an automatable FFI generation. >> > >> > Igor, I have seen that you have mentioned some work-arounds using >> > instance >> > variables, and/or NBExternalStructures. Both these ideas are great, >> > especially the use of the NBExternalStructure, however in my opinion if >> > you >> > want to generate them automatically you've got yourself an even bigger >> > problem. >> > Will you generate a new class for each function call that you have? >> > What about the FFI being a wormhole to an ugly and mean world? >> > I think we should try to reduce the size of that hole ;) >> > Though, you have a point with using named arguments, and I think that is >> > a >> > cool solution too. That is why I was speaking about directly accessing >> > the >> > instance variables by name. >> > I simply didn't know enough about the hidden powers of >> > NBExternalStructure. >> > ;) >> > >> > As for extending the nativeboost signatures and accessing object fields >> > by >> > name, I completely agree with you that it is not a good idea. >> > >> > However, using the indices of arrays I think is only a small addition >> > that >> > can have a huge impact on the way people use NativeBoost FFI without >> > adding >> > to much extra-overhead. >> > By the way, I think we definitely have to do the bound-checking trick by >> > default. >> > Moreover, having the NBSTInObjectArgument as a wrapper over another >> > loader >> > is a great idea, giving us another degree of "controlled" freedom. ;) >> > >> > Thanks Henrik for the good joke (I didn't see it coming :)), It makes me >> > hate this idea now. :P >> > >> > self callFn: {x . y} >> > Looks kinda familiar doesnt it? (hint: swap { for ( and . for , ) >> > I for one welcome our new syntactic overlords! >> > >> > As for supporting or not more than 15 arguments for typical method >> > calls... >> > I don't know... maybe is good maybe is bad, but I think there are other >> > things that need to be done before making a fuss about it. By the way is >> > it >> > an arbitrary limit, or it is imposed by the use of 4 bytes for storing >> > the >> > number of arguments? >> > >> > Now let me come back to practical issues. My squeaksource id is cip.t >> > (you >> > can find me searching "ciprian" in the members list). >> > >> > Cheers, >> > Ciprian Teodorov >> > >> > >> > >> > >> > >> > On Mon, Oct 22, 2012 at 1:09 PM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> >> >> On 22 October 2012 12:00, Henrik Sperre Johansen >> >> <henrik.s.johansen(a)veloxit.no> wrote: >> >> > On 22.10.2012 02:37, Igor Stasenko wrote: >> >> >> >> >> >> On 22 October 2012 01:59, Nicolas Cellier >> >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >>> >> >> >>> 2012/10/22 Igor Stasenko <siguctua(a)gmail.com>: >> >> >>>> >> >> >>>> On 22 October 2012 01:20, Nicolas Cellier >> >> >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >>>>> >> >> >>>>> 5 parameters???? Igor, you're a dictator ;) >> >> >>>>> Those theories are nice, but unhelpfull when applied to FFI >> >> >>>>> Pragmatically there's not any chance I rewrite LAPACK+BLAS for >> >> >>>>> the >> >> >>>>> sake of purity. >> >> >>>>> >> >> >>>>> And your workaround (creating a class) is very poor, because >> >> >>>>> maybe >> >> >>>>> classes themselves should not have more than 5 instance variables >> >> >>>>> ;) >> >> >>>>> >> >> >>>> Hehe. >> >> >>>> This is same thing like increasing number of literals for methods >> >> >>>> (and >> >> >>>> max distances between jumps). >> >> >>>> It just makes sense where you deal with external chaotic world. >> >> >>>> My ideology is simple: prevent that chaos from entering our little >> >> >>>> peaceful bay. >> >> >>>> >> >> >>> That's not exactly the philosophy behind FFI. >> >> >>> FFI is here to let the user manage the external chaotic world. >> >> >>> OK, external peels of the onion should have 5 parameters or less. >> >> >>> Near the sprout, you can't raise such barriers, or there is no >> >> >>> onion >> >> >>> at >> >> >>> all. >> >> >>> >> >> >> Well, that's part of developer's responsibility, how to prevent >> >> >> chaos. >> >> >> Needless to say, nobody wants to deal with so many arguments at once >> >> >> (too much space for mistakes). >> >> >> As for my workaround: this mainly, how you tame the complexity in >> >> >> case >> >> >> it is inevitable? >> >> >> Look how code to call that function will look like: >> >> >> >> >> >> 1. passing as array >> >> >> >> >> >> args := Array new: 100. >> >> >> args at:1 put: x; >> >> >> at:2 put: y; >> >> >> ... >> >> >> at: 100 put: zork >> >> >> >> >> >> self callFn: args. >> >> > >> >> > self callFn: {x . y} >> >> > Looks kinda familiar doesnt it? (hint: swap { for ( and . for , ) >> >> > I for one welcome our new syntactic overlords! >> >> > >> >> >> >> Yes, it looks familiar, but cannot tell where i seen it. >> >> Gah.. how i could forget about it? >> >> >> >> >> >> >> >> >> >> 2. passing as instance of class, or external structure: >> >> >> >> >> >> args := MyFunctionArgs new. >> >> >> args >> >> >> firstArgumentName: x; >> >> >> secondArgumentName: y; >> >> >> ... >> >> >> hundrethArgumentName: zork. >> >> >> self callFn: args. >> >> >> >> >> >> admit that dealing with names instead of numbers leaves much less >> >> >> space for mistakes >> >> >> and serves for better clarity at same time. >> >> >> So, even if it is more cumbersome because requires defining extra >> >> >> class, at the end you win much more. >> >> >> >> >> >> Anyways, if people think it is worth adding indirect argument loader >> >> >> ( >> >> >> in form of param@<index>, but not param@ivar), we can introduce >> >> >> that. >> >> >> >> >> > While I often find this a good idea for maintainability, it sorta >> >> > flies >> >> > in >> >> > the face of another of ST's strengths, iterative/exporatory >> >> > programming. >> >> > If you are forced to think up front about which parameter classes you >> >> > need >> >> > due to a small limit, rather than introduce them ad-hoc when the code >> >> > really >> >> > needs the refactoring to remain legible, it slows you down. >> >> > >> >> > Not thinking of FFI specifically, but I have seen lots of evolved >> >> > mathematical models where a 5-parameter limit upfront would probably >> >> > lead to >> >> > either: >> >> > a) *Really* bad code, ie. making the calculation object stateful by >> >> > storing >> >> > in instvars instead. (and in the process, make it really hard to know >> >> > which >> >> > instvars are actually part of object state and not temp vars of some >> >> > calculation) >> >> > b) Switching to another programming language out of frustration. >> >> > >> >> >> >> keyword message syntax is bad for many arguments.. >> >> for such cases i find a positional argument notation more appeal >> >> because it is more compact. >> >> In any case, a complex math formulas smell equally bad in any >> >> programming language >> >> (sometime even if written by hand on paper using math notation(s) ;) >> >> >> >> > Cheers, >> >> > Henry >> >> > >> >> >> >> >> >> >> >> -- >> >> 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. >> > > > > -- > 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.

Oct. 23, 2012

Re: [Pharo-project] NativeBoost FFI

by Ciprian Teodorov

Hi Igor, There seems to be an issue with the squeaksource repo... I don't see myself listed amongst the developers nor can I commit I'm using this connection string: MCHttpRepository location: 'http://www.squeaksource.com/NativeBoost' user: 'cip.t' password: '*******' Cheers Ciprian On Tue, Oct 23, 2012 at 10:20 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > HI, Ciprian. > I added you to developers. > > Just single comment about auto-generated wrapper(s)/bindings: > You need to do it only once. Then it will not be needed. > > Yes, you can do it automated or manually (automated is preferred), but > since you do it only once, even if manually, this is not going to be > too big bottleneck. > Sure things, having a tool(s) which can automate that would be nice. > But according to my experience, you can automate it only partially, > but not fully. > There , of course, exceptions like OpenGL library which API design > allows to automate wrapping. > > And sure thing it would be nice to have some code generators to import > from C header(s). > > > On 22 October 2012 19:52, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > wrote: > > Hi guys, > > > > First of all sorry for not saying anything the whole day ... but I don't > > have internet connection at work. I hope I'll be excused though ;) > > > > Now it will be a difficult for me to address all the issues raised ... > > however I will try > > > > First of all, IMHO any FFI should facilitate the task of the person > writing > > the library wrapper. > > This comes the issue of (hopefully automatically) parsing C headers and > > generating the calls. > > Why?... well because if I take for instance the BLAS/LAPACK case (which > was > > cited today) have over 1000 functions exported. > > Even if it is not 1000 lets say that you have a smaller library from > which > > you want to use only one function X but in order to use that precise > > function you will maybe have to initialize some C context data, or a > > specific data structure. > > Of course you can do that by hand, but what if you really want to benefit > > from the library without diving into the details... well in that case you > > are a little bit stuck, either you write by hand a bunch of wrappers or > you > > quit. > > > > The problem is that nice libraries that you want to use they usually have > > horrible data structures behind that you cannot set up easily. This > happened > > to me several times in the future while trying to use different external > > library calls (graphviz, metis, abc, vpr to name a few) in Pharo (with > FFI, > > with Alien, etc). In almost all cases I ended up generating text files > and > > calling some bloody c program using these files as input. The problem is > > that has a huge impact on performances... > > > > Now with nativeboost I found it pretty easy to automatically generate > some > > usable binding... I parsed the C headers with srcml, the I have parsed > the > > XML looking for function definitions... For these definitions I've > generated > > the wrappers. Only that for over 15 argument functions that did not work. > > > > Now, I do not like the idea of hacking the compiler, or even subclassing > it > > like Nicolas did for Smallapack. And luckily we do not need to do that > with > > the arguments in an array trick... Moreover, I completely agree with > Igor on > > the fact that 15 arguments are to many, however Pharo really needs to > have > > an automatable FFI generation. > > > > Igor, I have seen that you have mentioned some work-arounds using > instance > > variables, and/or NBExternalStructures. Both these ideas are great, > > especially the use of the NBExternalStructure, however in my opinion if > you > > want to generate them automatically you've got yourself an even bigger > > problem. > > Will you generate a new class for each function call that you have? > > What about the FFI being a wormhole to an ugly and mean world? > > I think we should try to reduce the size of that hole ;) > > Though, you have a point with using named arguments, and I think that is > a > > cool solution too. That is why I was speaking about directly accessing > the > > instance variables by name. > > I simply didn't know enough about the hidden powers of > NBExternalStructure. > > ;) > > > > As for extending the nativeboost signatures and accessing object fields > by > > name, I completely agree with you that it is not a good idea. > > > > However, using the indices of arrays I think is only a small addition > that > > can have a huge impact on the way people use NativeBoost FFI without > adding > > to much extra-overhead. > > By the way, I think we definitely have to do the bound-checking trick by > > default. > > Moreover, having the NBSTInObjectArgument as a wrapper over another > loader > > is a great idea, giving us another degree of "controlled" freedom. ;) > > > > Thanks Henrik for the good joke (I didn't see it coming :)), It makes me > > hate this idea now. :P > > > > self callFn: {x . y} > > Looks kinda familiar doesnt it? (hint: swap { for ( and . for , ) > > I for one welcome our new syntactic overlords! > > > > As for supporting or not more than 15 arguments for typical method > calls... > > I don't know... maybe is good maybe is bad, but I think there are other > > things that need to be done before making a fuss about it. By the way is > it > > an arbitrary limit, or it is imposed by the use of 4 bytes for storing > the > > number of arguments? > > > > Now let me come back to practical issues. My squeaksource id is cip.t > (you > > can find me searching "ciprian" in the members list). > > > > Cheers, > > Ciprian Teodorov > > > > > > > > > > > > On Mon, Oct 22, 2012 at 1:09 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 22 October 2012 12:00, Henrik Sperre Johansen > >> <henrik.s.johansen(a)veloxit.no> wrote: > >> > On 22.10.2012 02:37, Igor Stasenko wrote: > >> >> > >> >> On 22 October 2012 01:59, Nicolas Cellier > >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >>> > >> >>> 2012/10/22 Igor Stasenko <siguctua(a)gmail.com>: > >> >>>> > >> >>>> On 22 October 2012 01:20, Nicolas Cellier > >> >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >>>>> > >> >>>>> 5 parameters???? Igor, you're a dictator ;) > >> >>>>> Those theories are nice, but unhelpfull when applied to FFI > >> >>>>> Pragmatically there's not any chance I rewrite LAPACK+BLAS for the > >> >>>>> sake of purity. > >> >>>>> > >> >>>>> And your workaround (creating a class) is very poor, because maybe > >> >>>>> classes themselves should not have more than 5 instance variables > ;) > >> >>>>> > >> >>>> Hehe. > >> >>>> This is same thing like increasing number of literals for methods > >> >>>> (and > >> >>>> max distances between jumps). > >> >>>> It just makes sense where you deal with external chaotic world. > >> >>>> My ideology is simple: prevent that chaos from entering our little > >> >>>> peaceful bay. > >> >>>> > >> >>> That's not exactly the philosophy behind FFI. > >> >>> FFI is here to let the user manage the external chaotic world. > >> >>> OK, external peels of the onion should have 5 parameters or less. > >> >>> Near the sprout, you can't raise such barriers, or there is no onion > >> >>> at > >> >>> all. > >> >>> > >> >> Well, that's part of developer's responsibility, how to prevent > chaos. > >> >> Needless to say, nobody wants to deal with so many arguments at once > >> >> (too much space for mistakes). > >> >> As for my workaround: this mainly, how you tame the complexity in > case > >> >> it is inevitable? > >> >> Look how code to call that function will look like: > >> >> > >> >> 1. passing as array > >> >> > >> >> args := Array new: 100. > >> >> args at:1 put: x; > >> >> at:2 put: y; > >> >> ... > >> >> at: 100 put: zork > >> >> > >> >> self callFn: args. > >> > > >> > self callFn: {x . y} > >> > Looks kinda familiar doesnt it? (hint: swap { for ( and . for , ) > >> > I for one welcome our new syntactic overlords! > >> > > >> > >> Yes, it looks familiar, but cannot tell where i seen it. > >> Gah.. how i could forget about it? > >> > >> > >> >> > >> >> 2. passing as instance of class, or external structure: > >> >> > >> >> args := MyFunctionArgs new. > >> >> args > >> >> firstArgumentName: x; > >> >> secondArgumentName: y; > >> >> ... > >> >> hundrethArgumentName: zork. > >> >> self callFn: args. > >> >> > >> >> admit that dealing with names instead of numbers leaves much less > >> >> space for mistakes > >> >> and serves for better clarity at same time. > >> >> So, even if it is more cumbersome because requires defining extra > >> >> class, at the end you win much more. > >> >> > >> >> Anyways, if people think it is worth adding indirect argument loader > ( > >> >> in form of param@<index>, but not param@ivar), we can introduce > that. > >> >> > >> > While I often find this a good idea for maintainability, it sorta > flies > >> > in > >> > the face of another of ST's strengths, iterative/exporatory > programming. > >> > If you are forced to think up front about which parameter classes you > >> > need > >> > due to a small limit, rather than introduce them ad-hoc when the code > >> > really > >> > needs the refactoring to remain legible, it slows you down. > >> > > >> > Not thinking of FFI specifically, but I have seen lots of evolved > >> > mathematical models where a 5-parameter limit upfront would probably > >> > lead to > >> > either: > >> > a) *Really* bad code, ie. making the calculation object stateful by > >> > storing > >> > in instvars instead. (and in the process, make it really hard to know > >> > which > >> > instvars are actually part of object state and not temp vars of some > >> > calculation) > >> > b) Switching to another programming language out of frustration. > >> > > >> > >> keyword message syntax is bad for many arguments.. > >> for such cases i find a positional argument notation more appeal > >> because it is more compact. > >> In any case, a complex math formulas smell equally bad in any > >> programming language > >> (sometime even if written by hand on paper using math notation(s) ;) > >> > >> > Cheers, > >> > Henry > >> > > >> > >> > >> > >> -- > >> 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. > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Oct. 23, 2012