- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:?

by Tudor Girba

Hi, On 22 Nov 2012, at 18:04, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > ----- Original Message ----- > | From: "Tudor Girba" <tudor(a)tudorgirba.com> > | To: "pharo-project" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Thursday, November 22, 2012 3:15:36 AM > | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? > | > | Hi Dale, > | > | > | I think your concerns are not consistent :): > | > | > | - you make a distinction between symbolic and regular versions, but > | you do not make a distinction between baseline and regular versions. > | Why not? Because it is good practice to have a proper naming that > | distinguishes between baseline and the regular versions without > | having this distinction hardcoded in the engine. And it works just > | fine. Of course, people can mess it up by having a version called > | 'baseline', but in practice it works just fine. > | > | The same could apply to symbolic versions. > > You're really stretching here, Doru ... I would claim that not making a distinction between baselines and versions was a mistake that should not be repeated with symbolic versions ... Ok. We disagree on this one :). This is because in practice, it is not a problem. > | - you say that when people load a '1.0' symbolic version they would > | be confused when they in fact get '1.0.37'. I think it will be > | equally confusing when the symbolic version is named #'1.0'. The > | problem is really that the name of the symbolic version should be > | different. > > I see the difference between '1.0' and #'1.0' and I assume that you are able to perceive that difference as well:) > > For me the important message to take from this is that the fact that Metacello must be involved in version control is the real travesty here ... not the invention of symbolic versions:) > > If one starts to use a version control system that can manage more than one file at a time like git/svn/mercurial/etc. you quickly find out that the need to monkey with linear versions begins to fade away, because the primary function of the linear version is to act as a version control data base ... > > When using git I use a BaselineOf which has a single baseline specification. There's no need to distinguish between different baseline specifications and the notion of baseline version disappears... The ConfigurationOf relegates the linear versions to the role of tags with no need to maintain an exhaustive list of mcz file names ... So with git Metacello begins to explicitly distinguishes between baselines (configurations) and versions (tags). I don't need to use a ConfigrationOf for development at all ... The ConfigurationOf becomes a deployment/publishing artifact. Precisely. So, you see: that shows that introducing a BaselineOf uses the mechanism of a regular version and it is enough. > The fate of symbolic versions in the presence of git is still up in the air...It may be possible to simply stop using symbolic versions, I would think...The fate of symbolic versions is the least of my worries:) Dale, I just clarified what Stef was asking. I still think it is a valid concern for those that do not work on Git. > Frankly Doru, I would welcome your critical eye applied to the Metacello Preview. I think that managing Moose with git would simplify a number of your development problems. Perhaps this whole linearizing the packages thing would just disappear? I'm pretty sure your fixation on symbolic versions would go away:) I am not fixated. I just see an extra concept that is not needed :). I am still interested in looking into this, but my time is severely limited these days. > I haven't released the Preview precisely because I want critical feedback before setting features in stone by releasing them ... As it stands the Metacello Preview is production ready (I've been using it constantly in my work for months now)... > > Metacello dipped it's toe into the version control business out of necessity, but Metacello is not a complete version control system and I really have no desire to add branching and merging features to Metacello ... those features are the domain of a version control system .... Truly the whole Metacello story gets much simpler when one can leverage a fully-featured version control system. I am not sure I quite understand that part in the context of dependencies to independent projects. You would still need to somehow refer to a version of the sub-project. How is that achieved? Cheers, Doru -- www.tudorgirba.com "Quality cannot be an afterthought."

Nov. 23, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 491 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Nov. 23, 2012

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

by Igor Stasenko

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. > 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. 22, 2012