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

Re: [Pharo-project] Helping with Athens development

by Esteban Lorenzano

yeah, you are the boss :) I was just saying :) On Nov 23, 2012, at 3:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 November 2012 14:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> in the long way, an OpenGL backend seems more important to me than a Quartz backend (of course both are good, but OpenGL is portable and "de facto standard", Quartz is not...) > > OpenGL does not have high level abstractions for paths/paints. > But NVidia extension released lately, called nv_path is the way to go, i think. > > Using OpenGL without this extension will require sufficient effort to > implement everything. > Because you will need to do a lot of processing to convert paths to > something which opengl understands - triangles. > It is doable, of course, but not as fast and as easy as doing backend > for cairo or openvg or quartz. > > But i agree, that if we would have opengl backend , we would not need > to care much about others. > Because it is best thing what you can have: GPU acceleration :) > > -- > Best regards, > Igor Stasenko. >

Nov. 23, 2012

Re: [Pharo-project] NativeBoost callbacks - status?

by Igor Stasenko

On 23 November 2012 11:07, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > On Nov 22, 2012 11:23 PM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: >> >> On 22 November 2012 20:22, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> wrote: >> > Hi Igor, >> > >> > My bet ... extracting the nbXAtOffset to the TNBMemoryAccessors broke >> > the >> > callbacks since I have also removed the ulongAt: and ulongAt:put: >> > accessors >> > which are used by the callback counter (there are some strange argument >> > conversions going on). >> > >> > Though if I merge your .78.mcz with my .83.mcz all tests pass ... >> > >> > I don't know what you think about having the memory accessors in a >> > trait? >> > the bad thing is that I do not see any way of sharing them with the ones >> > from ByteArray (can we extend a class with traits?)... >> >> hmm.. i think we can't because that will make Collections package dirty. >> So, there's not much choice: we should use only extension methods. >> What i thinking is getting rid of ulongAt/put protocols, and use uint32 >> instead >> to be more precise and to not confuse with C types. > That's what I have tried to do in my last 3 commits, but there seems to be > some strange border effect (with callback counter) that I did not see > coming. I'll look into it during the WE. > yes, i merged with your code and now running callback test is crashing VM. i will try to figure what's going on. > Cheers > -- Best regards, Igor Stasenko.

Nov. 23, 2012

Re: [Pharo-project] Athens Documentation (was: Helping with Athens development)

by Camillo Bruni

On 2012-11-23, at 10:56, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 November 2012 13:57, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> Thank you Igor , this was the type of answer I wanted . Ok I think I will >> work first on documenting the code and creating a pdf that helps the user >> understand how to use Athens. After I gain a very good insight through >> documentation of how Athens works I start contributing code. I assume for >> documenting code (adding doc strings to methods missing them) files out and >> attaching them here will do or you want me to upload to my own project in >> ss3 ? >> >> > Well, i was thinking more about format which is available online. > And because Athens documentation will absolutely require a lot of illustrations, > i think best would be to use HTML for it. > (or something which generates html ). > Making a PDF out of it is not a big deal, isn't? yes! - presence in the web is very important for people coming from the outside. - in image documentation/examples are very important for development speed so yes, somthing like markdown can be easily converted to pdf, I use http://johnmacfarlane.net/pandoc/ regularly to compile my outline notes to nice pdfs ;) > Of course, this is not makes class/method comments less important. > But i vote for online documentation first. Online documents are mainly for, let's say, lazy users of your system, currently we're still in core development, so I would go for the things needed by programmers. That is Examples, Class Comments and maybe method comments. I am certainly a bit extreme on that, but I think investing time into examples that explain the design is wort more. Also for me this is more smalltalk. I hate reading prose text which is a fuzzy definition of something whereas I could read a nicely documented example and debug and learn it! > Because most of people don't even understand the basic concepts of > paths/contours and coordinate system.. > and class comments are not really helpful for that I definitely agree on that (as we figured out with esteban, we were both not that solid on this topic). But examples are much better, much more interactive. > I wanna have something like Amber documentation: > http://amber-lang.net/documentation.html well I you focus on examples you could revive my old WebDoc thingy that will nicely format the source code and uses full markdown for all in-method comments. > Also, as for the starting point, what things we should describe there, i think > OpenVG spec could serve as a guiding source. > > www.khronos.org/registry/vg/specs/openvg_1_0_1.pdf > > it contains a lot of material which we can reuse for starters: > matrices, coordinate system, > paths and path commands etc. > > So, for getting started we much decide what source format we should use. > and where we will host it (as an early-term solution i propose to just > create a project on github). Go for examples! I want to have the most interactive documentation possible! Otherwise, yes github + wiki is a low-resistance solution, though we should take care that we have the information as well in the image :) > And then first step would be to make a TOC :) > > -- > Best regards, > Igor Stasenko. >

Nov. 23, 2012

Re: [Pharo-project] Helping with Athens development

by Igor Stasenko

On 23 November 2012 14:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > in the long way, an OpenGL backend seems more important to me than a Quartz backend (of course both are good, but OpenGL is portable and "de facto standard", Quartz is not...) OpenGL does not have high level abstractions for paths/paints. But NVidia extension released lately, called nv_path is the way to go, i think. Using OpenGL without this extension will require sufficient effort to implement everything. Because you will need to do a lot of processing to convert paths to something which opengl understands - triangles. It is doable, of course, but not as fast and as easy as doing backend for cairo or openvg or quartz. But i agree, that if we would have opengl backend , we would not need to care much about others. Because it is best thing what you can have: GPU acceleration :) -- Best regards, Igor Stasenko.

Nov. 23, 2012

[Pharo-project] Athens Documentation (was: Helping with Athens development)

by Igor Stasenko

On 23 November 2012 13:57, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > Thank you Igor , this was the type of answer I wanted . Ok I think I will > work first on documenting the code and creating a pdf that helps the user > understand how to use Athens. After I gain a very good insight through > documentation of how Athens works I start contributing code. I assume for > documenting code (adding doc strings to methods missing them) files out and > attaching them here will do or you want me to upload to my own project in > ss3 ? > > Well, i was thinking more about format which is available online. And because Athens documentation will absolutely require a lot of illustrations, i think best would be to use HTML for it. (or something which generates html ). Making a PDF out of it is not a big deal, isn't? Of course, this is not makes class/method comments less important. But i vote for online documentation first. Because most of people don't even understand the basic concepts of paths/contours and coordinate system.. and class comments are not really helpful for that. I wanna have something like Amber documentation: http://amber-lang.net/documentation.html Also, as for the starting point, what things we should describe there, i think OpenVG spec could serve as a guiding source. www.khronos.org/registry/vg/specs/openvg_1_0_1.pdf it contains a lot of material which we can reuse for starters: matrices, coordinate system, paths and path commands etc. So, for getting started we much decide what source format we should use. and where we will host it (as an early-term solution i propose to just create a project on github). And then first step would be to make a TOC :) -- Best regards, Igor Stasenko.

Nov. 23, 2012

Re: [Pharo-project] Helping with Athens development

by Camillo Bruni

On 2012-11-23, at 10:46, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > CogVM ? sounds very hard for me to do. I am not that good as a coder and VM development looks very difficult to me. > > I am sticking with Athens for the time being. I love graphics , sound and music. Getting bored is not an option :D sorry I randomly copied strings :D => http://code.google.com/p/pharo/issues ;)

Nov. 23, 2012

Re: [Pharo-project] Helping with Athens development

by dimitris chloupis

CogVM ? sounds very hard for me to do. I am not that good as a coder and VM development looks very difficult to me. I am sticking with Athens for the time being. I love graphics , sound and music. Getting bored is not an option :D ________________________________ From: Camillo Bruni <camillobruni(a)gmail.com> To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, 23 November 2012, 15:31 Subject: Re: [Pharo-project] Helping with Athens development On 2012-11-23, at 10:17, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > internal help , no problemo I can do that too. Its an opportunity to see how pharo internal help system works , last time I checked it seemed simple enough. > > Class docstrings first seems like a good priority. > > I love your work with pharo and I was itching to contribute back to the community. I love smalltalk mainly because of the great environment and I think that there is still a lot more to be done to improve it and make it even more user friendly , I only hope I play my own small part in this.Â oh, definitely our whishlist of things we want to improve is quite large, and most of it is not even in the issue tracker :P so whenever you feel bored working on athens => http://code.google.com/p/cog/issues ;)

Nov. 23, 2012

Re: [Pharo-project] Helping with Athens development

by Camillo Bruni

On 2012-11-23, at 10:17, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > internal help , no problemo I can do that too. Its an opportunity to see how pharo internal help system works , last time I checked it seemed simple enough. > > Class docstrings first seems like a good priority. > > I love your work with pharo and I was itching to contribute back to the community. I love smalltalk mainly because of the great environment and I think that there is still a lot more to be done to improve it and make it even more user friendly , I only hope I play my own small part in this. oh, definitely our whishlist of things we want to improve is quite large, and most of it is not even in the issue tracker :P so whenever you feel bored working on athens => http://code.google.com/p/cog/issues ;)

Nov. 23, 2012

Re: [Pharo-project] Helping with Athens development

by Esteban Lorenzano

in the long way, an OpenGL backend seems more important to me than a Quartz backend (of course both are good, but OpenGL is portable and "de facto standard", Quartz is not...) On Nov 23, 2012, at 1:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 23 November 2012 12:11, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> So after diving in common lisp and take a look at various alternative I >> decided that Pharo is the best place for me to start for my Ephestos >> project. The first thing that got my attention is Athens , it seems to be >> very close to my own goal for Ephestos. So my question is how may I help >> Athens involve by contributing code to it ? >> >> Are there specific features I can work on ? The first part of my Ephestos >> project I call it Morpheas and its basically a GUI API based on morphic >> specialised on customised guis, meaning guis that do not look native . >> Athens seems a good library to base Morpheas on, so I am actually interested >> in expanding it. >> >> In the future I would also like to port Athens to opengl , but if cairo is >> fast enough for me, I may avoid it and instead focus more on porting Morphic >> to Athens. >> >> So my post here is to clarify the way I can contribute to Athens . I want my >> project Ephestos to be a contribution to the existing Pharo image and offer >> more GUI widgets, maybe a gui designer and some more graphic and audio >> tools. I think that Athens can be the base for my project so naturally I >> want to contribute. > > Hi, Dimitris. > yes, you're welcome to contribute. > > There's a lot of areas: > > Documentation > > The most important thing today is documentation and examples. > This will open doors to users and future contributors. Without it, > things will stay a bit arcane, > and behind closed doors. > > Development: > > - delivery of rendered stuff to screen estate. Right now, we do it via > morphic: so first you render on surface, > then you blit results on Display form, and then VM blits bits again on > screen. To improve frame rate, we should certainty think how to avoid > copying things twice and deliver results directly on screen avoiding > transferring/copying big chunks of data. > > - SVG importer: it works for simple SVG documents, but it is not > finished and more work is needed. Some svgs are not imported > correctly, we need to improve that. Of course full SVG coverage is not > a goal (no animaiton nor fancy filter stuff).. > But we should have a robust solution for importing vector graphics > made by artists. > > - integration with morphic: the goal is to be able to render > everything using Athens canvas. The work is already started, but > there's many morphs which has own custom draw methods, and waiting to > be ported for athens. > Apart from it is text layout/rendering.. it is the main hurdle for us, > but we're working on it, by implementing new text model, > and rendering/layout engine for it. > > - implementing more backends. Currently there's only Cairo backend > which is more or less functional. We need more. I am looking forward > to implement quartz backend on mac os. Also, opengl backend would be > good to have. > > Another thing: Amber. If someone interested, i think it will be good > to port it on Amber and make Athens working in web browsers using > HTML5 canvas. > > > If you need details about any of the above, feel free to ask. > > -- > Best regards, > Igor Stasenko. >

Nov. 23, 2012

Re: [Pharo-project] Helping with Athens development

by dimitris chloupis

internal help , no problemo I can do that too. Its an opportunity to see how pharo internal help system works , last time I checked it seemed simple enough. Class docstrings first seems like a good priority. I love your work with pharo and I was itching to contribute back to the community. I love smalltalk mainly because of the great environment and I think that there is still a lot more to be done to improve it and make it even more user friendly , I only hope I play my own small part in this.Â ________________________________ From: Camillo Bruni <camillobruni(a)gmail.com> To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, 23 November 2012, 15:02 Subject: Re: [Pharo-project] Helping with Athens development On 2012-11-23, at 09:57, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > Thank you Igor , this was the type of answer I wanted . Ok I think I will work first on documenting the code and creating a pdf that helps the user understand how to use Athens. if you could, it would be nice to have the text also for Pharo's internal help system. In my opinion that is more smalltalk-like, since we ship everything together :) > After I gain a very good insight through documentation of how Athens works I start contributing code. I assume for documenting code (adding doc strings to methods missing them) files out and attaching them here will do or you want me to upload to my own project in ss3 ? I guess the highest priority here is class comments, that is kind of a must (though I catch myself too often not adding one). nice to see additional support for athens!

Nov. 23, 2012