Squeak-dev September 2000

squeak-dev@lists.squeakfoundation.org

115 participants
411 discussions

[Feature request]Mac sub menu mouse handling
by Karl Ramberg 02 Sep '00

02 Sep '00

Some thing I _really_ miss in Squeak is the nice way one can access sub menus in mac os. When you only move the mouse cursor up and down you select the the menu item, but when a sub menu pops up mac os notices side movement of the mouse and keeps the sub menu up ( for about a second) even if you move diagonally towards the sub menu item you want allowing moves like this \ \ \ \ instead of moves like this ____ | | | | Is this hard to implement, I looked around a little but could not find an appropriate point to start changing... Karl

1 0

[ENH] ConnectorMorph for connecting Morphs with lines
by Ned Konz 02 Sep '00

02 Sep '00

This changeSet defines ConnectorMorph. A ConnectorMorph is an open PolygonMorph that tracks Morphs that are connected to its ends. This can be used in general-purpose drawings (like UML class diagrams, or organization charts) that require connection lines between Morphs. Arrowhead geometry has been fixed so that arrowheads now don't extend past the end vertices of the ConnectorMorph. You can construct a ConnectorMorph from the New Morph menu choice (select from the alphabetical list), or by invoking: ConnectorMorph new openInWorld The ConnectorMorph can be made to display its handles by shift-clicking on it. Then the end handles can be dropped on Morphs. I'd welcome feedback on this. I will be making a general-purpose drawing package out of this that will include a playfield to draw on, a parts bin to hold drawing objects (including connectors), and a toolbar area for special verbs. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

2 2

Re: The Mosner bit
by Mats Nygren 02 Sep '00

02 Sep '00

Tim, A strong argument: If you don't do (something similar to) this how are you going to deal with large character sets like Unicode? Or even smaller character sets but several different. The fun of having a table of all instances decreases with the number of such instances. One reason I failed to get Squeak accepted for a language education program in Uppsala was that they have immediate need for interesting character sets. I couldn't guarantee the soon appearance of that. I'm still working on it. It would produce 40 persons a year with special skills in using computers for (natural) language processing, each having extensive experience with Squeak. Giving me a nice teaching work, and the Squeak community a supply of languages applications. And the students a good time. Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > Bijan Parsia <bparsia(a)email.unc.edu> is widely believed to have written: > > > Cool! > > > > I had been wondering for a while if the extended tag scheme would > > work. Any VM implementers/object memory specialists want to weigh in? > VW has used two tag bits for years. IIRC it uses three of the patterns:- > smallinteger > oop > character > > The cost is not just the reduction in range of SmallInteger - after all > the difference is pretty small - but the complexity of the tag checking. > at the moment, checking for SmallInteger/oop is a single test. Two tag > bits makes deriving the class more complex (check for SI, check for > other option, remainder is normal object) and affects any code that > needs to understand the class of the objects involved. If it is important to check with a single test then the following: 00 - oop 01 - small integer 11 - the new stuff can be used. You still have a single test to know if something is an oop. No cost for those. For smallint at least one instruction extra will be needed, probably. I don't think that is untolerable. Sacrificing one bit combination there are then only 64 new tags, but that is a lot. Another possibility: 00 - oop 01 - immediate single test and then let smallint have one of the 128 tags. Then there are only 16M smallints. I considered this to be to small to be acceptable but I could have been wrong of course. Since this is simplest and most elegant I would prefer this, if the major decrease from 2G smallints to 16M is tolerable. Probably there are places where this creates problems, solvable problems. > A restriction is that this is only really useful for manifest constant > objects; yes, you could use the data bits to index a list of classes for > example, but how is that an advantage over having the oop of the class? There are in fact advantages: - things sent over a network can be used immediately, depending on there being the same list of classes in the other image. oop have local significance only. Compare with the current image segments that make up new tables of outpointers for each image segment and then have a completetly different way of doing this when making segments for export to another image. Having a fixed list as described here will make the difference between own/export dissappear for those well known standard things that has been given this extra status. Similar issues exist with ReferenceStream, they can be made more efficient with the special tags. Can make a difference for the current interest in communication between different Squeaks. Note also that since calling plugins can be done in a similar way the difference between a plugin call and a RMI decreases. (1) The inter image significance of these things is one of the primary motivations. - you can build alternative lists: {ButtonMorph, ListMorph, <X>Morph, ..} {MvcButton, MvcList, Mvc<X>, ..} with these kinds of things you can reinterpret major structures of things immidiately without even traversing it. The list is applied at the latest moment when the relevant "new tag" is accessed. - another similar point: if you store the names of classes (or other things) in a table on the side, then it is possible to have another table with class names in another language. The switch is immediate. And this scales well. (2) This ability to swiftly switch tables and reinterpret major structures without traversal is another primary motivation. Imagine a graphical scene. With a bunch of the new type of codes in it. By changing the tables referred to astonishing effects can be achieved. Similary with documents and many things. > Immediate Points, restricted range floats, colour values, anything where > the bits is the data, would all be plausible. Remember that such > manifest objects cannot be altered any more than a SmallInteger can, so > quite a bit of code in the image would be affected; for example you wuld > have to write > pt1 := pt1 x @ (pt1 y *2) > instead of > pt1 y: (pt1 y * 2) > ... which is a poor example since I think I would prefer it anyway, but > you're smart enough to see what I mean. I agree, this is for immutable value objects only. I don't agree that any code in the image would be affacted. It will, only if one decides to use the new stuff for changeable objects. Either don't use it for things like that or clearly document that certain classes are immutable and rewrite the code. Having Point's documentedly immutable can be a good thing but isnt necessary; Point's can be left outside of this. "I think I would prefer it anyway" could be your intuition saying: perhaps Points should be considered immutable. (Whether they fit into a single word or not) > So, yes it might be useful in some sense but I rather suspect the > runtime costs are unpleasant, especially once you go past a simple VW > like form. the present: bit0 = 0 ifTrue: [normal oop] ifFalse: [Smallint] first alternative: bit0 = 0 ifTrue: [normal oop] ifFalse: [bit1 = 0 ifTrue: [Smallint] ifFalse: [Table at: (byte0 bitShift: -2)]] second alternative: bit0 = 0 ifTrue: [normal oop] ifFalse: [Table at: (byte0 bitShift: -1)] I see no unpleasant runtime costs here. The little extra time needed should be seen in relation to the decrease of allocations in object memory and the time taken in each and every gc. Note also that the present Squeak object memory runs slower due to the complexity of compact classes. A similar idea with similar effects. In fact the compact class table would be part of one of the new tags. I would like to hear Hans-Martin Mosner on this. Then a period of experimentation. Then a decision. /Mats

2 1

Freetype2
by Marcus Denker 02 Sep '00

02 Sep '00

Hi! Some month ago there was a discussion about Freetype and the patent-issues. Now a FreeType2 pre-release is available at http://www.freetype.org: Patents issues The FreeType 2 source code includes a TrueType bytecode interpreter that is covered by the Apple patents. However, this piece of code is never compiled by default in this release (unlike in previous betas) making a default build of the library entirely patent-free !! Supported font formats FreeType 2 readily supports the following font formats: -> TrueType files (.ttf) and collections (.ttc) -> Type 1 font files both in ASCII (.pfa) or binary (.pfb) format -> Type 1 Multiple Master fonts. The FreeType 2 API also provides routines to manage design instances easily -> Type 1 CID-keyed fonts -> OpenType/CFF (.otf) fonts -> CFF/Type 2 fonts -> Adobe CEF fonts (.cef), used to embed fonts in SVG documents with the Adobe SVG viewer plugin. -> Windows FNT/FON bitmap fonts -- Marcus Denker marcus(a)ira.uka.de phone@home:(0721)6649375 @work:(0721)6082749 Imitating paper on a computer screen is like tearing the wings off a 747 and using it as a bus on the highway. -- Ted Nelson

4 3

Re: Freetype2
by Henrik Gedenryd 02 Sep '00

02 Sep '00

I guess an update of my work on the FreeType plugin work is in order. The main problem is that there is no obvious demarcation for what should be there. Especially upwards the possibilities are huge, and downwards it's not clear what is "acceptable". Also, there are essentially 2 projects, as there's lots to be done inside Squeak, to support grayscale instead of 1-bit fonts. In effect, you need to bring font support 25 years forward in time. Think you don't need to fix MVC to make it work in Morphic? Hah, think emergency evaluator & progress indicators. Think you don't need the ability to draw text in color? Then give up diff views (with changes in red). And so on. And then there's the question of being able to render type directly, without first generating bitmap fonts. All in all it's pretty close, but you know about those last 10%. Dan Ingalls wrote: > We are also looking at FreeType, and other schemes (such as a simple set of > primitives that would allow Squeak to tap any font accesible in your OS). FreeType does allow this--you merely need os-specific code for locating the font files. It supports bitmaps as well as a load of outline formats, including PostScript, ps multiple master, OpenType, and a few acronyms which I don't know what they are :-) Doing this specifically for Squeak: Win -> rather easy, just a path I think. Of course the path may vary between various Wins. Same for *x. Mac -> Squeak is resource fork agnostic, but FT has both sfnt and FOND support. This requires a bit more work. Mac VM people step forward please. Tapping the OS's font renderer is also a possibility, this may be what you mean. Note that the big problem is to pass a bitmap through the VM's cell membrane. This is a big issue even with the purportedly portable FT, which is in fact very C-centric. The reasonable approach is to have the renderer work on a Squeak bitmap--not the other way (as I would have preferred). And just don't expect the render to be able to handle Squeak bitmaps, and vice versa, eg. word alignment. FT doesn't--except sometimes, in an apparently arbitrary fashion--and the documentation says nothing about this. Sigh. On the good side, this would make the use of truetype hinting legal (when the os has it), but on the bad side it leaves predictable x-platform results behind. Fonts just don't come out looking the same everywhere. (Fitting the same space, etc.) Anyway, relying on the receiving platform to have certain fonts installed has always been a bad idea, for project and application delivery alike. And the only OS's to do this are Mac, Win. (For standard formats, anyway). Ned Konz wrote: > My understanding (as someone who used to be in the typsetting business, > not as a lawyer) is that the legal protection for fonts is not > for the actual glyphs, but for the name of the font (trademark). > > This is why you see so many names for the same font (Helvetica/Swiss, > for instance). Unfortunately for type designers, anyone is free to redraw a font, however not to use a protected name for it. > Derived glyphs -- bitmaps -- are the outputs of these programs, and are > not themselves copyrighted. Legally, this is true afaik, with Ned's reservations. > If we include bitmaps in specific sizes in the image (NOT including the > actual TTF representation), and change the names, we should be OK > (as per my understanding of the copyright/trademark situation). Right. This means you should be legally safe, but not safe from their lawyers. Note the difference. > crux of the biscuit here is: what is the legal status of content (ie exported > projects) that have these derived glyphs in them. I think there are enough (read: zillions) of freeware fonts to support exported projects (as opposed to general text use, they aren't good enough for that). Beside Ned's points, vendors explicitly allow documents to contain derived representations, if they don't allow you to render strings freely from them. (Not the specific expression used.) So using a (legally obtained) font to render the bitmap for eg. "Highscores:" and distributing this bitmap in your image is 100% safe. Compare with eg. PDF documents which may legally re-distribute content with special fonts. > A committed contributor to Squeak (I just want to let him be first to announce > this) has followed up on John McIntosh's suggestion that we might be able to > get a nice set of fonts from Doug Easterbrook. These could then replace and > augment the fonts now in Squeak. This is the best sugggestion so far, and I think this will be the best solution to our problems. I hope this is still going forward. Henrik

1 0

RE: The Mosner bit
by Mats Nygren 02 Sep '00

02 Sep '00

spair(a)advantive.com (Stephen Pair) wrote: > This is very interesting! > > Has this been tried in other implementations before? I have experimented with it, but it wasn't a Smalltalk system. And it never reach production, only my own experimentation. One of the things I did was a lexicon for latin. There are many word forms and by coding it I had immediate access to millions of word-forms. Without ever using a hash table or allocate something on a heap. It was possible to associate meanings with the word forms. Assigning meaning to the word stems (< 1000 in the experiments) meaning arose for all millions of words. I used that for quite different programming language with millions of meanings reachable from a single "identifier". After that most programming languages seems to lack something. IM(Humble of course ;-)O. I also had a comprehensive set of primitive functions and that worked well to. And other stuff .. as you say below encoding schemes can be useful. > Does this essentially mean that up to 128 immediate classes can be added, > each with up to 16M unique instances? Exactly. 1G + 1G (new tags + smallints) values outside of object memory. > [snip] > The ability to efficiently represent just about any encoding scheme is > reason enough in my opinion. Good point. > I think it's definitely worth exploring! You have my vote. Thanks! /Mats

1 0

Re: [BUGS] modifier keys in 2.9a Mac VM.
by John M McIntosh 02 Sep '00

02 Sep '00

on 9/1/00 1:37 AM, Karl Ramberg at karl.ramberg(a)chello.se wrote: > OOPS. Seems like it is the 2.9a VM that caused this. That VM has big problems > eg. modifyer > keys don't work etc. Actually the modifier keys don't work in Morphic, they work fine in MVC. But under the covers it's actually a bug in the Mac VM. I'm looking at fixing it real soon. Also some of you might have noticed that the interrupt key doesn't work in 2.9 with a 2.9VM. This also is being fixed, and I think for that it's a Smalltalk change. > > Karl > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== Custom Macintosh programming & various Smalltalk dialects PGP Key: DSS/Diff/46FC3BE6 Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 ===========================================================================

1 0

Re: Freetype2
by Duane Maxwell 01 Sep '00

01 Sep '00

Bob -- Incidentally, Bob, if you'd like to expand upon the work you did with us wrt FreeType for the benefit of the Squeak community, you have my explicit release to do so. -- Duane =================================================== Duane Maxwell dmaxwell (at) exobox.com CEO/CTO http://www.exobox.com exobox, Inc. (858)348-3040 FAX(858)348-3099 Information contained herein is my personal opinion and not necessarily that of exobox. ===================================================

1 1

Re: Freetype2
by Duane Maxwell 01 Sep '00

01 Sep '00

Bob writes: >A good place to start might be: > > (TextStyle default fontAt: 1) edit: $X Yeah, I've used that for mangling individual glyphs, but I guess I was looking for something that was more savvy about the nature of fonts themselves - setting metrics, cloning and scaling existing fonts, reordering characters, test strings, blah blah, woof woof. Thanks, though. Cheers -- -- Duane

1 0

Re: Bugz in 2.8
by Dan Ingalls 01 Sep '00

01 Sep '00

>Okidok, I've now discovered I think three different Collection bugs, for >example, which I think is kinda serious. Some of them may have been around >longer though. Which brought to mind the question of the fixes that have >been posted since sma's last effort. When that list is compiled, things that >should go into 2.8 should be picked out of that list. Problem is, how do we >get those into 2.9a as well? By placing them in both streams? Yes, exactly. We have a well-automated process for reasing updates for the latest version (2.9a). We also have a fairly well automated process (it gets better as we do more of it) for issuing updates for prior versions (such as 2.8). The hard part is identifying things that are important enough to fix, and fixes that will both work in that older version, and not prevent if from being able to grow forward if desired. We'll handle the job of getting the files into the right update streams. So, for instance, if you were to submit contributions to 2.9a, you might recommend "and XXX and YYY, along with #2425 (say) from the 2.9a stream, should also be put in the 2.8 update stream". That would be a real service! - Dan

1 0

Jump to page: