June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] The Morphic 3 project

by Igor Stasenko

On 2 June 2010 15:16, Juan Vuletich <juan(a)jvuletich.org> wrote: > Lukas Renggli wrote: >> >> Hi Juan, >> >> This looks really exiting! >> >> How do you get the actual pixels drawn? Is this implemented in >> Smalltalk? Did you write primitives to do that? Are you using external >> libraries? How does it compare performance wise with the current >> rendering? >> >> Lukas >> >> > > Hi Lukas, > > I'm glad you like it. It is all done in Smalltalk. There are no external > libraries. In fact, I developed new drawing algorithms that are better than > those in Cairo, AGG, etc. So there are no libraries in existence I could > call! > > The sampling theorem is about 80 years old. It is the base (together with > Fourier analysis) of most of the DSP (Digital Signal Processing) field. It > is therefore the basis of digital audio and photography. But it seems I am > the first one to apply it to 2d rendering! I have been working on this for > the last 3 years, after finishing my Ms.Sc. in CS on Image and Signal > Processing. I had to establish the theoretical foundations, and come up with > new algorithms to draw basic elements using this theory. What you see are > the first practical result of all this work. > > It is still pure Smalltalk, and therefore, a bit slow. The lion takes 1.8 > secs to draw on my 1.6GHz Mac mini. I am still changing the code a lot, but > when it stabilizes I'll do a VM plugin. I guess it would be about 100 times > faster. The other option is to use Igor's NativeBoost. That could perhaps be > 10 times faster than the plugin, at the cost of portability and hand written > asm (I'd done lots of asm in a previous life). > Last year i built an SVG API bindings. And i were able to render the Tiger at screen refresh rate (65Hz). The rendering throughput is even higher than that, but it looks like SVG implementation limits the frame rate to screen refresh rate as maximum :) Sure thing, the quality is not that high as yours, but still, it shows how much speed-up we could achieve, if we put all processing on GPU side. It would be cool if we could cooperate and implement this stuff using OpenGL as backend. > Cheers, > Juan Vuletich > >> On 2 June 2010 13:43, Juan Vuletich <juan(a)jvuletich.org> wrote: >> >>> >>> Hi Folks, >>> >>> I'm new to this list, but many of you already know me. >>> >>> Morphic 3 is a deep redesign of the Morphic framework. It includes new >>> rendering algorithms I developed that produce unparalleled visual >>> quality. >>> Really. This is the best 2d rendering in the world. You can take a look >>> at >>> Â www.jvuletich.org. I have been working a lot recently, and uploaded >>> several >>> very cool samples for you to see. >>> >>> I also want to thank publicly to Stef Ducasse and ESUG, as they are >>> sponsoring Morphic 3 via the "support your project" program, described in >>> http://www.esug.org/Promotion/Project . Thanks ESUG! >>> >>> Comments welcome. >>> >>> Cheers, >>> Juan Vuletich >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> >> >> Â ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: >> 271.1.1/2912 - Release Date: 06/02/10 03:25:00 >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

June 3, 2010

Re: [Pharo-project] The Morphic 3 project

by Brian Brown

Juan Vuletich wrote: > My work is not about creating svg files but about rendering them. The > links are the same because they point to the original svg (vector > graphics) file used to render both in Inkscape and in Morphic 3. If you > want to save the rendered versions, your web browser should allow > something like right click / Save image As... > Sorry, a misunderstanding on my part - I get it now!

June 3, 2010

Re: [Pharo-project] How get font instance programmatically?

by Denis Kudriashov

Thank you very much 2010/6/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > LogicalFont familyName:'DejaVu Sans' fallbackFamilyNames:nil pointSize:8 > stretchValue:0 weightValue:400 slantValue:0. >

June 3, 2010

Re: [Pharo-project] About TDD and Pharo

by Noury Bouraqadi

I'd like to add to my whishlist : an automated execution of lint when all tests are green. Noury On 3 juin 2010, at 21:07, Noury Bouraqadi wrote: > > On 3 juin 2010, at 07:45, StÃ©phane Ducasse wrote: > >> >> On Jun 2, 2010, at 11:22 PM, GermÃ¡n Leiva wrote: >> >>> I'm thinking out load here ... >>> >>> In the debugger when a DNU is raised, for speeding up the programming in "TDD mode": >>> â¢ The create button must add the method in the class of the receiver, the possibility to choose a superclass of the receiver must be optional (I don't like the recurrent asking...) in other button for example or having different shortcuts from the keyboard >> is it not already the case? >> > Only when the exception window shows up. Once you click on the debug button, you can't do it anymore. > >>> >>> â¢ In the creation of a new class through "define new class" it will be helpful to remember the last class category used >>> Some ToDo list supported from the environment and some facility for the creation of test. > > I'd rather go for a bit more sophisticated system based on Scrum task board coupled with Monticello. > Tasks descriptions are organized in three collections Done, ToDo and inProgress. > Once we do a project snapshot, we got these descriptions referenced in the snapshot. So, when browsing the history of snapshot, one can more easily figure out what each version is about. > > More features I'd like to have is in the refactoring browser : > -When renaming an instance variable, rename its accessors two > -Suggest to delete accessors when deleting an IV > -Be able to generate accessors for multiple IVs at the same time (like in eclipse!) > -Have a preference that automatically generate accessors on addition of IVs / class definition > > Noury

June 3, 2010

Re: [Pharo-project] About TDD and Pharo

by Lukas Renggli

> -Suggest to delete accessors when deleting an IV You cannot delete an inst-var with the refactoring engine if there are references. > -Be able to generate accessors for multiple IVs at the same time (like in eclipse!) This is built-in for several years now: refactor class | create accessors > -Have a preference that automatically generate accessors on addition of IVs / class definition I rarely use these accessor refactorings because I have to rewrite each method by hand afterwards anyway to have a type-revealing argument name and a comment. Lukas -- Lukas Renggli www.lukas-renggli.ch

June 3, 2010

Re: [Pharo-project] Multiple Worlds (was Re: Can I use Projects in Pharo?)

by Jochen Riekhof

Ok, found time to hack up a /very preliminary/ test class that allows me to switch between PasteUpMorphs by name. It would be nice if someone could tell me if what I did is reasonable (I did not use Squeak/Pharo for looong time). It might e.g. well be that I use methods intended for Project that will go away soon Just file in JRWorldManager and evaluate in a workspace JRWorldManager instance createOrSwitchToWorldNamed: 'JustAnotherWorld'. you should be carried to a new empty world. To switch back, use JRWorldManager instance createOrSwitchToWorldNamed: 'Pharo'. (I hope that attachments work in this list). Ciao ...Jochen Am 03.06.2010 um 14:29 schrieb Sean P. DeNigris: > > > StÃ©phane Ducasse wrote: >> >> there is a key point in all this thread. >> we are not against ideas. >> > Ha ha, I never thought otherwise :) > > > StÃ©phane Ducasse wrote: >> >> We loved etoys and I did more presentations about it than probably 95% of >> the squeakers population >> now we do not like its implementation because it hurts us. >> Same for projects. Simple. >> > Yes, I got that. That's why I forked this thread - to refocus on the > multiple world feature, and away from the existing project implementation. > > I'll add the mockup to my todo list (with key bindings at the top), but the > immediate future will be working on a commercial project in Pharo - yay! > > Sean > -- > View this message in context: http://forum.world.st/Multiple-Worlds-was-Re-Can-I-use-Projects-in-Pharo-tp… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 3, 2010

Re: [Pharo-project] About TDD and Pharo

by Noury Bouraqadi

On 3 juin 2010, at 07:45, StÃ©phane Ducasse wrote: > > On Jun 2, 2010, at 11:22 PM, GermÃ¡n Leiva wrote: > >> I'm thinking out load here ... >> >> In the debugger when a DNU is raised, for speeding up the programming in "TDD mode": >> â¢ The create button must add the method in the class of the receiver, the possibility to choose a superclass of the receiver must be optional (I don't like the recurrent asking...) in other button for example or having different shortcuts from the keyboard > is it not already the case? > Only when the exception window shows up. Once you click on the debug button, you can't do it anymore. >> >> â¢ In the creation of a new class through "define new class" it will be helpful to remember the last class category used >> Some ToDo list supported from the environment and some facility for the creation of test. I'd rather go for a bit more sophisticated system based on Scrum task board coupled with Monticello. Tasks descriptions are organized in three collections Done, ToDo and inProgress. Once we do a project snapshot, we got these descriptions referenced in the snapshot. So, when browsing the history of snapshot, one can more easily figure out what each version is about. More features I'd like to have is in the refactoring browser : -When renaming an instance variable, rename its accessors two -Suggest to delete accessors when deleting an IV -Be able to generate accessors for multiple IVs at the same time (like in eclipse!) -Have a preference that automatically generate accessors on addition of IVs / class definition Noury

June 3, 2010

Re: [Pharo-project] Something I don't see in ImageSegment

by Noury Bouraqadi

On 3 juin 2010, at 18:55, Eliot Miranda wrote: > Hi Mariano, Hi All, > > response below. But does anyone have any tests for the image segment primitives? I'm refactoring them and would like some tests. > I don't have tests, but it's cool that you take care of this. The code I saw was really ugly with huge methods. Noury > 2010/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi. ImageSegment uses GC to compute the out pointers. Basically, to a given array of roots (a graph) it does: > > 1) It marks the rootArray and all root objects by turning on the Garbage Collector bit in the object header of those particular objects. > 2) Then does a mark pass over all objects. This will stop at our marked roots leaving our segment unmarked in their shadow. > 3) Finally, it unmarks the rootArray and all root objects. > 4) Only external objects are now marked. > > The unmarked objects in the graph of objects of the arrays are those who will be put in the WordArray (the segment) and those who are marked to the outPointers. > > However, I don't see where step 2) is done in Interpreter >> primitiveStoreImageSegment > > In a piece of such method it does: > > > "Then do a mark pass over all objects. This will stop at our marked roots, > thus leaving our segment unmarked in their shadow." > savedYoungStart := youngStart. > youngStart := self startOfMemory. "process all of memory" > "clear the recycled context lists" > freeContexts := NilContext. > freeLargeContexts := NilContext. > self markAndTraceInterpreterOops. "and special objects array" > youngStart := savedYoungStart. > > "Finally unmark the rootArray and all root objects." > self longAt: arrayOfRoots put: ((self longAt: arrayOfRoots) bitAnd: AllButMarkBit). > ......continue....... > > But here I see it is only marking Interpreter oops, not all objects. And I don't see where all objects are marked even in the code that follows this little piece. > > markInterpreterOops marks all objects accessible from the interpreter oops, including the specialObjectsArray, recursively marking any unmarked objects and their referents. i.e. it marks all objects reachable from the roots of the system. This would mark all objects in the system were it not for the fact that the primitive marks the rootArray and so markInterpreterOops does not marl objects /only/ reachable from the rootArray. So once the rootArray objects have been unmarked, only those objects that should go in the image segment are unmarked. > > So the primitive works by > - marking the objects in rootArray, preventing marking of objects reachable from them in the next step > - recursively marking all objects reachable from the roots (except those already marked) > - unmarking root objects, leaving the transitive closure of objects accessible from the roots and no where else unmarked > - writing the unmarked objects to an image segment > > > HTH > Eliot > > > You can see the comment: "Then do a mark pass over all objects" and even without the comment it makes sense to mark all objects in order to detect outPointers. > > Does anyone has a hint? > > Thanks > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 3, 2010

Re: [Pharo-project] The Morphic 3 project

by Juan Vuletich

Brian Brown wrote: > Juan Vuletich wrote: > >> Yes, that would be cool. I also thought about multi user multi touch >> tables, where I need to handle input form several fingers >> simultaneously, that can belong or not to the same hand (user). Also >> multiple standard and MIDI keyboards, continuous MIDI controllers, pen >> tablets, more "special" input devices, such as the voice and various >> devices designed for people with disabilities, etc... But I have done >> nothing of this yet. >> >> Cheers, >> Juan Vuletich >> > > On a related note... when I went to your website and looked at the svg > samples, there is only one link for each pair of images; for example, > both lion pictures are linked to: > > http://www.jvuletich.org/Morphic3/lionx.svg > > This is the same for all pictures, so it is hard to compare in an SVG > viewer ;) > > - Brian My work is not about creating svg files but about rendering them. The links are the same because they point to the original svg (vector graphics) file used to render both in Inkscape and in Morphic 3. If you want to save the rendered versions, your web browser should allow something like right click / Save image As... Cheers, Juan Vuletich

June 3, 2010

Re: [Pharo-project] The Morphic 3 project

by Juan Vuletich

StÃ©phane Ducasse wrote: > finishing something is always taking time and this is great to see you making progress on that front. > For the PhD it could be full time job to sell that. > Did you identify potential research group? > > Stef > I'm trying to contact a research group on graphics at my university, but without luck so far. Cheers, Juna Vuletich >> Douglas Brebner wrote: >> >>> On 02/06/2010 12:43, Juan Vuletich wrote: >>> >>>> Hi Folks, >>>> >>>> I'm new to this list, but many of you already know me. >>>> >>>> Morphic 3 is a deep redesign of the Morphic framework. It includes new rendering algorithms I developed that produce unparalleled visual quality. Really. This is the best 2d rendering in the world. You can take a look at www.jvuletich.org. I have been working a lot recently, and uploaded several very cool samples for you to see. >>>> >>>> >>> This is awesome :) >>> >>> I'm wondering though, what you intend for the input side. There's a lot of touch screen and multitouch devices around now which would be nice to directly support in addition to keyboard + mouse, things like pinch-zoom on a ZUI would be cool :) >>> >> Yes, that would be cool. I also thought about multi user multi touch tables, where I need to handle input form several fingers simultaneously, that can belong or not to the same hand (user). Also multiple standard and MIDI keyboards, continuous MIDI controllers, pen tablets, more "special" input devices, such as the voice and various devices designed for people with disabilities, etc... But I have done nothing of this yet. >> >> Cheers, >> Juan Vuletich >>

June 3, 2010