Squeak-dev April 2007

squeak-dev@lists.squeakfoundation.org

151 participants
201 discussions

Re: [Vm-dev] search order for plugins
by subbukk 27 Apr '07

27 Apr '07

On Friday 27 April 2007 3:11 pm, Bert Freudenberg wrote: > Ian, I did not see your reply on-list ... which may explain why you > appear "silent" at times ;) > > Maybe you're posting with the wrong address? Ian's reply came to me direct. I assumed he must have replied to me direct instead of to the list by mistake and posted my reply to this list. Oooops! .. Subbu

1 0

Re: [Vm-dev] search order for plugins
by subbukk 27 Apr '07

27 Apr '07

On Friday 27 April 2007 2:03 am, Andreas Raab wrote: > subbukk wrote: > > An strace of squeak (3.7.7) startup reveals 181 attempts to open of which > > 179 fails with ENOENT. > > Why is that a problem? The primary risk is that we may hit a file which may not be what we want. E.g. If I happen to run a test squeak vm from /usr/lib/squeak/3.7-7, a wrong plugin would be picked. A secondary problem is that each open in an unlikely location costs time and processor cycles. This may not matter on desktops but will impact small factor machines like XO (unnecessary battery drain). A second BTW, running (Kubuntu Dapper) squeak -plugins /usr/lib/squeak/3.7-7 -vm-sound-OSS squeak.image reduced the number of opens for vm-* plugins from 181 to 2 and the number of failures to 0. On Unix, the search order for sound modules is MACOS, Sun and only then OSS :-(. We could compile each platform's binary to be smart in picking the most likely display and sound plugins. Regards .. Subbu

1 0

Re: [Vm-dev] search order for plugins
by subbukk 27 Apr '07

27 Apr '07

On Friday 27 April 2007 1:58 am, John M McIntosh wrote: > I'll note the Mac carbon VM has a info.plist flag that is turned on > to ensure the tryLoading logic tries less hard and considers the > internall bundle's application folder first so > the the number of opens is *considerably* less. True. But this is not portable. Does the order -plugin overrides followed by dirname(argv[0]) have the same effect but in a portable way? Regards .. Subbu

1 0

Adding images to the squeaksource wikis
by Damien Cassou 27 Apr '07

27 Apr '07

Hi, I would like to know how I can add images, or attach files, to the squeaksource wikis. Is it possible? Thank you -- Damien Cassou

2 2

Morphic graphics, Displaying fonts & canvases
by sig 27 Apr '07

27 Apr '07

Hello squeak-dev, during my struggle to make morphic world be OpenGL ready i found that current drawing protocols not providing a freedom in selecting a methods on how the text/images is drawn on display. As i can see, the current graphics classes (Canvas/DisplayScreen/Morph) is heavily relying on blitting operations and (wrongly) assume that canvases and/or their display mediums supporting them by default. First of all, DisplayScreen is a subclass of Form which is a subclass of DisplayMedium. A DisplayMedium comment reads: I am a display object which can both paint myself on a medium (displayOn: messages), and can act as a medium myself. My chief subclass is Form. This is wrong. I can give you tons of exapmles when display medium represents a hard copy (take a look at the paper on you desk) and can't be painted on other medium. The printer can be considered as such medium to which you can draw but can't draw a printed contents on other medium. And i strongly presume that the DisplayScreen is such kind of medium. Even more, not all mediums can be represented as rectangular area of pixels. Some of them can be presented as set of vectors (vector displays) or other forms of drawings, and even have non-rectangular display surface. And thats where we need a Canvas to draw on it. The drawing process by its nature is one way road and assuming that we can freely draw between different mediums is totally wrong. So, at abstract level we must think of a Medium to which we can draw by issuing commands through its Canvas. Nothing more. To simulate drawings from one medium into another we can use caching canvas, which will collect all drawing commands and then pass them to another canvas of target medium. All morphic drawing is built on top of this wrong assumption, which prevents me to make a nice and clean replacement of Display to allow morphs drawn using OpenGL. For making this possible there is need to make changes in many places to conform different protocol(s). And here is my proposals: Fix the DisplayMedium protocol by revoking assumption that it can be drawn on other medium. DisplayScreen class: - make it a subclass of DisplayMedium, not Form. Canvas class: - remove methods which based on assumtion that canvas is drawing on top of Form. Refactor code which assumes such behavior. Since canvas represents capabilities of DisplayMedium i think that first references to Canvas must appear there, and any drawing on medium must be a drawing using canvas received from #getCanvas message. The method #defaultCanvasClass must be removed. You cannot connect a canvas to different medium and cannot use two independent canvases for drawing on the same medium because this leads to breaking its current internal state. For caching/clipping purposes there are protocol in canvas itself, which can give you instances for such uses and since they refer to the main canvas, the risk of breaking the medium internal state is minimal. For example, if morph wants to use a Form to draw itself into (as in Morph>>#imageForm:forRectangle:), then it must directly instantiate a Form and use #getCanvas to draw on it. If there is need in a form having same depth as screen - use Display>>depth. But note, message #depth for DisplayScreen must be considered as a hint, not a part of Form protocol. In most cases, drawing in to independent form used for caching purposes, when resulting image is then _blitted_ on the screen. There is a class named CachingCanvas designed specially for such purposes, and showing 0 references in my 3.9 image. Make a conclusion :) So, returning back to the needs pre-cached drawing i think the best way is to use Canvas protocol, so it can return an instance of CachingCanvas or its subclass to cache the incoming drawing operations. The caching canvas MUST be used by morphs and fonts. Take a look at the TTCFont implementation, i cant look at it without pain.. What do you think, is this the best way of drawing true type glyphs using pre-cached bitmaps? The authors of true type package made a great job by providing TTF's for a squeak, but failed to make it in a really nice fashion when glyphs are coming to draw on the screen. This is another design flaw to which I would like to pay attention. The protocol between Canvas and AbstractFont is need to be redesigned in the way of using CachingCanvas for this purposes. Then there will be no need to introduce own bitmap cache what is currently done in TTCFont class. And moreover, in case of OpenGL a caching canvas is stored in video memory which greatly improves performance when you need to copy it on the screen. Displaying a string is simple set of commands which draw part(s) of cached canvas(es) on the main canvas. Comparing to Form(s), a caching canvas can store a list of commands issued to it, instead of bitmap. And this can reduce the memory usage and greatly improve speed, because of reducing an excessive blitting operations. I'd like to discuss all above metioned with you :) Meanwhile my current implementation of GLCanvas draws a World from 3 to 8 times faster than current Display. And i think it can be even faster. I think that performance can be increased to such level to make it possible to draw entire World in back buffer and still have decent frame rates. -- Best regards, sig

9 24

Meeting events during SmalltalkSolutions in Toronto
by Milan Zimmermann 27 Apr '07

27 Apr '07

Hi, I just though I'd point this out as a reminder of what events are being organized as "get together" in Toronto this weekend till Wednesday (I realize it was already posted earlier): http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Smalltalk+World+Tour Milan

1 0

Digg Plopp
by Michael Rueger 27 Apr '07

27 Apr '07

Hi all, we just announced the free (Ubuntu) Linux version of Plopp, our Teddy inspired 3D painting tool done completely in Squeak: http://digg.com/software/Award_winning_3D_painter_for_Kids_released_as_Free… Please digg it :-) And don't forget to submit your creations to the gallery! Cheers Michael

3 2

A newbie needs some help in squeak (maths, algorithm and drawing)
by Jerome Peace 27 Apr '07

27 Apr '07

Here is a different take on the same problem: paste in a workspace select and do: ======>> "Something to use to show results:" arrow := [ :verticesCollection | (PolygonMorph arrowPrototype setVertices: verticesCollection ) openCenteredInWorld ] . " len was the number of steps. Which means rotations should actually be len / ppr. I just left it a whole number for simplicity" rotations := 5 . ppr := 10. "What I couldn't resist is pointing out how deadly simple squeak can make things. You just need to think thru to the next iteration of the problem.'" spiralVertices := (0 to: rotations * Float twoPi by: Float twoPi / ppr ) collect: [ :each | Point r: 0.15 * each sqrt degrees: each radiansToDegrees ] . arrow value: spiralVertices * 50 . >>========== Then play with the details. Yours in curiosity and service, --Jerome Peace __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: The Weekly Juan #10: "Cheap, High Quality Fonts in Squeak"
by Benoit St-Jean 27 Apr '07

27 Apr '07

To sum it up, WOW! Nice work! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

1 0

Re: Need to draw finite state machines (Again)
by Ken G. Brown 26 Apr '07

26 Apr '07

Have you seen this?: <http://bike-nomad.com/squeak/> at the bottom of the page: Squeak implementation of Miro Samek's ideas from Practical Statecharts in C/C++ This zip contains just the FSM code from the Connectors 2 package. It can be used by itself. Squeak/MIT license download SqueakQHsm.zip Ken >Date: Wed, 18 Apr 2007 19:05:33 -0400 >From: "Ralph Boland" <rpboland(a)gmail.com> >Subject: Need to draw finite state machines (Again) >To: squeak-dev(a)lists.squeakfoundation.org >Message-ID: > <fd59e9e70704181605p3f5b5d90xb49b940c2fef490d(a)mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >Thanks for the responses for my posting on my need to draw finite state >machines. For example:

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
21
Older →

Jump to page: