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

Re: [Pharo-project] Helping with Athens development

by Camillo Bruni

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

Re: [Pharo-project] Helping with Athens development

by dimitris chloupis

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 ? ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Friday, 23 November 2012, 14:07 Subject: Re: [Pharo-project] Helping with Athens development 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

[Pharo-project] Pharo 2.0 on Raspberry Pi ?

by Sven Van Caekenberghe

Hi, Does anyone know how to make Pharo 2.0 run on a Raspberry Pi ? I am running an up to date 2012-10-28-wheezy-raspbian (Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l). There seems to be a Stack VM on it, it does run Smalltalk code, but there is some initialization error, a loop of VM: unix - armv7l - linux - THERE_BE_DRAGONS_HERE MessageNotUnderstood: receiver of "do:" is nil 22 November 2012 8:55:09.996 pm in PharoDebug.log. I will (try to) look deeper into this, but if someone knows how to get things working, I would be grateful for any help. It would be really great if we as a community would be able to offer this as an option. Thx, Sven PS: I specifically want to run a (possibly patched) Pharo 2.0 image, not something else. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 23, 2012

Re: [Pharo-project] Helping with Athens development

by Igor Stasenko

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 Fernando Olivero

For now, Athens uses the software renderer of Cairo to draw into a Cairo Surface. We get it back to the Pharo, buy telling a Form to load the bits of the Cairo surface. Would be nice to have another renderer for Athens, besides Cairo, to use a hardware accelerated renderer. OpenGL backend for Athens would be great. NBOpenGL is already there. So it would a matter of having another AthensCanvas, and AthensSurface that uses OpenGL to draw. Yet, the current scheme is fast enough! So i don't know wether this is a priority. Fernando On Fri, Nov 23, 2012 at 12:11 PM, 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. >

Nov. 23, 2012

[Pharo-project] Helping with Athens development

by dimitris chloupis

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.

Nov. 23, 2012

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

by Frank Shearar

On 23 November 2012 10:49, Dan Corneanu <cdan(a)savatech.ro> wrote: > Hi, > I would really like to have a CogVM for ARM. I am a rookie in this field but I > own a raspberry pi and would love to help in any way possible to move this > forward. Testing maybe ? The interpreter VM works perfectly on the Raspberry, so you can at least get your Smalltalk fix while folks work on Cog. frank

Nov. 23, 2012

Re: [Pharo-project] Athens, Nativeboost and Igor's gray hair

by kilon

that what happens when i get tons of emails, i missed yours. But thanks to world of smalltalk i found it. Thanks for sharing that great stuff I am actually considering giving a helping hand to Athens , I really like it. -- View this message in context: http://forum.world.st/Athens-Nativeboost-and-Igor-s-gray-hair-tp4656395p465… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2012

Re: [Pharo-project] GSoC: ARM jitter for Squeak VM

by Dan Corneanu

Hi, I would really like to have a CogVM for ARM. I am a rookie in this field but I own a raspberry pi and would love to help in any way possible to move this forward. Testing maybe ?

Nov. 23, 2012

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

by Ciprian Teodorov

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. Cheers > > > however such a trait might be handy if we want to implement something like > > FloatArray using NB (think about FloatArray32, FloatArray64, etc)... > > > > I will try to fix this issue during the WE... if I will find the time. > > > > Thanks very much! > > Ciprian > > > > > > > > On Thu, Nov 22, 2012 at 2:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >> i will check. > >> > >> I didn't merged with your code, Ciprian yet.. > >> does it crashing for NativeBoost-Core-IgorStasenko.78 or > >> in your code? > >> > >> i will merge your stuff and check. > >> > >> > >> -- > >> 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. 23, 2012