- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Xtreams's FileDirectory dependence

by Sven Van Caekenberghe

On 17 Apr 2013, at 17:09, Camillo Bruni <camillobruni(a)gmail.com> wrote: > FileSystemLegacy is your friend: > > http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy Yes, that is one possibility. But we want a clean loading Xtreams using FileSystem directly, do we not ? > On 2013-04-17, at 16:57, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> Xtreams depends on FileDirectory in at least three places, all in the >> Xtreams-Terminals package. (Three messages on FileUrl, #appending, >> #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp >> and #tearDown) >> >> Pharo 2.0 has no FileDirectory. So it seems like the easiest (not >> necessarily simple, nor right) thing to is to break that out into >> Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and >> similarly for the tests. >> >> After that, we'd need to adjust the ConfigurationOfXtreams. I think I >> forgot to fulfil a promise to submit an updated version of this that >> loaded FFI correctly (sorry!). >> >> Thoughts? Do any Pharo folk load Xtreams? >> >> frank >> > >

April 17, 2013

Re: [Pharo-project] Xtreams's FileDirectory dependence

by Camillo Bruni

FileSystemLegacy is your friend: http://smalltalkhub.com/#!/~PharoExtras/FileSystemLegacy On 2013-04-17, at 16:57, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Xtreams depends on FileDirectory in at least three places, all in the > Xtreams-Terminals package. (Three messages on FileUrl, #appending, > #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp > and #tearDown) > > Pharo 2.0 has no FileDirectory. So it seems like the easiest (not > necessarily simple, nor right) thing to is to break that out into > Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and > similarly for the tests. > > After that, we'd need to adjust the ConfigurationOfXtreams. I think I > forgot to fulfil a promise to submit an updated version of this that > loaded FFI correctly (sorry!). > > Thoughts? Do any Pharo folk load Xtreams? > > frank >

April 17, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by phil＠highoctane.be

Why not make a doodle for this? 2013/4/17 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > cool :) > > Ben > > On Apr 17, 2013, at 2:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > Marcus Denker-4 wrote > > We are planning a sprint the 3rd of May: > > > I want to join again via IRC/skype from NYC. It worked out well last > time... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Sprint-Sprint-Lille-May-3rd-tp4682097p4682106.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > >

April 17, 2013

Re: [Pharo-project] Tiger athens with objc bridge demo

by Benjamin

Cool :) Ben On Apr 17, 2013, at 3:59 PM, Max Leske <maxleske(a)gmail.com> wrote: > Cool! Especially the popup window :) > > On 17.04.2013, at 15:49, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> http://www.youtube.com/watch?v=k_bfSz2tus0 >> >> Enjoy, >> Esteban >> >> ps: small... and this time I do not speak. So is a win-win :) >> > >

April 17, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by Benjamin

cool :) Ben On Apr 17, 2013, at 2:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> We are planning a sprint the 3rd of May: > > I want to join again via IRC/skype from NYC. It worked out well last time... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Sprint-Sprint-Lille-May-3rd-tp4682097p4682106.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 17, 2013

Re: [Pharo-project] Tiger athens with objc bridge demo

by kilon

I would prefer it long and with you speaking, but I guess you cant please everyone Great job and thanks for making this bridge. -- View this message in context: http://forum.world.st/Tiger-athens-with-objc-bridge-demo-tp4682126p4682135.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 17, 2013

[Pharo-project] Xtreams's FileDirectory dependence

by Frank Shearar

Xtreams depends on FileDirectory in at least three places, all in the Xtreams-Terminals package. (Three messages on FileUrl, #appending, #reading, #writing; two tests in XTFileReadingWritingTest >> #setUp and #tearDown) Pharo 2.0 has no FileDirectory. So it seems like the easiest (not necessarily simple, nor right) thing to is to break that out into Xtreams-Terminals-Squeak and Xtreams-Terminals-Pharo packages, and similarly for the tests. After that, we'd need to adjust the ConfigurationOfXtreams. I think I forgot to fulfil a promise to submit an updated version of this that loaded FFI correctly (sorry!). Thoughts? Do any Pharo folk load Xtreams? frank

April 17, 2013

Re: [Pharo-project] do you know what is this?

by phil＠highoctane.be

True, you have a point. 2013/4/17 Igor Stasenko <siguctua(a)gmail.com> > On 17 April 2013 13:34, phil(a)highoctane.be <phil(a)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 <estebanlm(a)gmail.com> > >> > >> Hi Phil, > >> > >> On Apr 17, 2013, at 9:26 AM, "phil(a)highoctane.be" <phil(a)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 <estebanlm(a)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 <dionisiydk(a)gmail.com> > >>> wrote: > >>> > >>> Hi > >>> > >>> 2013/4/17 Fernando Olivero <fernando.olivero(a)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 < > estebanlm(a)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 <siguctua(a)gmail.com> > wrote: > >>>> > > >>>> >> On 16 April 2013 19:09, kilon <thekilon(a)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. > >

April 17, 2013

Re: [Pharo-project] do you know what is this?

by phil＠highoctane.be

Very interesting email, worth a post somewhere. 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > On Apr 17, 2013, at 11:23 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > > > Anyway, my only objection is the fact that we will have twice the code to > > maintain and more to worry about. > > let me explain this little thing a bit... > > Do you think that code doesn't need to be maintained and taken care how it > is right now? > > I will draw you a picture of how it works this now > > /----------------------------------------------\ > | "Pretended wonderland" (image) | > =========================== > | Lots of things: I/O, FFI, etc. | > ----------------------------------------------- > | Virtual Machine (Cog, Stack, Int) | > \----------------------------------------------/ > > This is your world right now. You work on "pretended wonderland" side, > assuming that everything below will work and hence you "don't need" to > maintain what is below wonderland, isn't? > > Well, wrong. > > Everything need to be maintained. What you do not see too (you do not see > it, but it is there, oh yes). > The difference is: > > - in wonderland, everybody can try to fix things (even id they fail, it is > there to play/change/adapt) > - in levels below, there are just a few people on earth who actually can > maintain that: Igor, myself and some others, but is for sure less than ten > people. > In fact, what happens now is that I have to maintain not two, but three > different versions of the same thing (for each platform), in two different > languages (C and Objective-C) and three different sets of libraries. And > yes, I "personalize" and use the "I" instead "we" because most of the > times is me, with some really valuable from Igor and Camillo (but well, > they do Athens and a PhD respectively, so many times is just a > one-man-work). > > So, what actually happens now is that problems stack waiting for a > solution, a solution which btw will never be of total satisfaction of users. > As an example, let's see the display plugin (which of course is not a > plugin at all, if you remove that from vm, it stops to work). > > Display plugin is based in BitBlt, who creates/transforms bitmaps and > renders them into screen. > Forget about 2D vectorial graphics (or any thing that can bebefict of > using of GPU). > This technology is obsolete and retina displays on mac prove that: there > is no way to do it work fine (that means: good rendering and good > performance). > > So we need to change that. > > How to do it? There are two basic approaches possible: > The traditional one says that some "gurus" should write a new plugin > (ideally backward compatible with the previous one). Then you have an > updated plugin (and probably a perfect one, if you don't want to maintain > it), until next time technology changes and then the gurus can be summoned > again to do their magic. > As you can see, since our community of potential gurus is (with luck) ten > persons in the world, that does not scales at all. > > Then it is our approach: move to the image all the things that can be > moved. Then you will have this: > > /----------------------------------------------\ > | "Pretended wonderland" | > ----------------------------------------------- > | Abstract system layer in image | > | (that most of people will never | > | see anyway) | > =========================== > | Virtual Machine (Cog, Stack, Int) | > \----------------------------------------------/ > > With NativeBoost we can achieve same performance that we achieve using > plain C. > And we have an incredible huge extra bonus: it is there so everybody can > try to modify/fix/update if needed, not just the gurus. > And we also have much more advantages to show: this is moving also the low > level programing to "pharo way", and as I showed in my silly videos, is > bring the "immediate feedback" experience also to that level (something > that you could never achieve with older way of thinking) > And finally... been in image does not need that you will need to deal with > that. How many of you know of the internals of Zinc/Zodiac or the Weak > Registry? (just to put a couple of examples). Most of us just take it and > use it. > > Our path is to bring to the whole community the power to change everything > in your environment. To change it live, in the pharo way. > And some times I feel that it is a power that the community is afraid to > take :) > > lose your fear: having that power feels good :) > > And again: do you still think there is no need for maintain low level > stuff? Think again. > > cheers, > Esteban > > >

April 17, 2013

Re: [Pharo-project] Tiger athens with objc bridge demo

by Max Leske

Cool! Especially the popup window :) On 17.04.2013, at 15:49, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > http://www.youtube.com/watch?v=k_bfSz2tus0 > > Enjoy, > Esteban > > ps: small... and this time I do not speak. So is a win-win :) >

April 17, 2013