On 17 April 2013 13:34, p...@highoctane.be <p...@highoctane.be> wrote: > Of course we can still understand with an all in image style (leveraging > ObjCBridge and NB). > > But it will be hard to study how things are occuring internally when leaving > the image. e.g. using components from the OSX Frameworks for things like > text editors may be powerful but ultimately, this will make us into "users" > and not technology owners (mmmh, hard to explain what I want to convey). > Well, you always have a choice to write everything from scratch :)
For instance, try implement own sockets library or file system (not FS as in Pharo, but FS which deals with disks - ext, ext2, FAT, NTFS etc ;). > Pharo is an interesting platform to *really* understand how things do work > at a low level. > > I agree with your view on doing most inside the image, plugins and stuff is > actually hard to understand and master (I've been cutting my teeth at this > for something like a year and still am a super n00b). > > One cool thing I'd like to have working is CUDA or OpenCL for example. That > would be easier to do if on the image side of course. > > Phil > > > 2013/4/17 Esteban Lorenzano <esteba...@gmail.com> >> >> Hi Phil, >> >> On Apr 17, 2013, at 9:26 AM, "p...@highoctane.be" <p...@highoctane.be> >> wrote: >> >> Regarding this, of the key points of Pharo is that most of the system is >> able to be looked at from a lot of angles in source code form. >> >> >> I do not understand this... why do you think that now you can do that and >> with an all-in-image approach you cannot? >> >> >> Removing that ability is not going to be nice. >> >> >> why do you think that this will remove it? >> >> Esteban >> >> >> But this doesn't mean we can't go the other way around of course, allowing >> it to embrace new technical possibilities. But as extensions to a core that >> stays under full control. >> >> At the moment, I've been tinkering with the idea of integrating a 3D demo >> engine (DirectX based) with Pharo. >> >> The engine will get an API and being scripted from the Pharo side. >> >> The engine can currently do things like: >> http://www.youtube.com/watch?v=oRnogMokS_8 >> >> Phil >> >> Phil >> >> >> 2013/4/17 Esteban Lorenzano <esteba...@gmail.com> >>> >>> Hi, >>> >>> This is just the cairo library rendering in a quartz format. No native >>> quartz access yet, so... >>> >>> 1) yes... is 100% compatible with Cairo (because it is Cairo :) >>> 2) no GPU, no OpenGL, just optimized rendering (one of this days I will >>> write the novel "how we render world canvas nowadays"... it is a thriller >>> end-of-the-world story) >>> >>> we are thinking with Igor if a quartz native renderer has sense right >>> now. Of course, in the long term, it has completely sense, but atm, I have >>> the feeling that other more portable renderer (like an OpenGL renderer) is >>> better investment. >>> Anyway, we still have some other stuff to do before: >>> >>> - finish athens (including new text model) >>> - finish bridge >>> - test same with linux, windows >>> etc. >>> >>> On Apr 17, 2013, at 7:50 AM, Denis Kudriashov <dionisi...@gmail.com> >>> wrote: >>> >>> Hi >>> >>> 2013/4/17 Fernando Olivero <fernando.oliv...@usi.ch> >>>> >>>> NICE work Esteban! >>>> >>>> Does the AthensQuartzSurface, support all Athens related code? (paths, >>>> paints,etc..) I will be more than happy to move away from the software >>>> rendering of the current cairo backend. >>> >>> >>> Is Quartz work by GPU? is it use openGL? >>> >>>> >>>> >>>> Fernando >>>> >>>> >>>> >>>> On Tue, Apr 16, 2013 at 8:41 PM, Esteban Lorenzano <esteba...@gmail.com> >>>> wrote: >>>> > not to say about efficiency. >>>> > >>>> > I've been doing some cpu cycle tests. >>>> > >>>> > Rendering a 1600@1200 gradient to world canvas (repeat each 50ms): >>>> > ~90% cpu consumption >>>> > >>>> > Same test, but sending it direct to window canvas using bridge: ~40% >>>> > cpu consumption >>>> > >>>> > so... we are in the good path :) >>>> > >>>> > Esteban >>>> > >>>> > On Apr 16, 2013, at 8:28 PM, Igor Stasenko <siguc...@gmail.com> wrote: >>>> > >>>> >> On 16 April 2013 19:09, kilon <theki...@yahoo.co.uk> wrote: >>>> >>> And you guys then say that pharo is not macos first citizen >>>> >>> >>>> >>> ha >>>> >>> >>>> >>> ha >>>> >>> >>>> >>> and >>>> >>> >>>> >>> ha >>>> >>> >>>> >>> I am a macos user , I love my imac and macos, but my vote goes to >>>> >>> cross >>>> >>> platform. >>>> >>> >>>> >>> Still another great library that is more than welcomed, definitely >>>> >>> cant do >>>> >>> any harm ;) >>>> >>> >>>> >> >>>> >> By saying that we don't need Cairo on MacOS i meant following: >>>> >> >>>> >> Athens designed to support multiple backends. >>>> >> It is out of question, that better to use most suitable backend, >>>> >> available on current platform. >>>> >> >>>> >> But apart of it stays ObjC bridge. Which would allow us to speak with >>>> >> ObjC-runtime >>>> >> (and Mac VM using it) directly. >>>> >> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> View this message in context: >>>> >>> http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html >>>> >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Best regards, >>>> >> Igor Stasenko. >>>> >> >>>> > >>>> > >>>> >>> >>> >> >> > -- Best regards, Igor Stasenko.
