Squeak-dev December 1999

squeak-dev@lists.squeakfoundation.org

146 participants
451 discussions

RE: Organizing VM sources, CCodeGenerator: suggestionsandquestions
by Raab, Andreas 29 Dec '99

29 Dec '99

Stephan, > I haven't kept in mind that in Smalltalk _all_ is an object! This is > valid for classes, too. Heh, heh ;-) One of the things that make Smalltalk so different... > But how is it with objects in the special objects array? > Are object pointers stored in the special objects array constant - > during one run of squeak - or not? No. They aren't constant from a C point of view. The special objects array just stores oops (though very special oops) - if you look at SystemDictionary>>recreateSpecialObjectsArray you'll see that this is just a regular Array. > I'm just storing the class pointer of classLargeNegativeInteger in a var > in C. Don't do it. Since it's an oop it may be moved around by any GC. > In 2.7 classLargeNegativeInteger also resides in the special objects > array (according my updated image). True. LargeNegativeInteger were introduced in the special objects array so that it is possible to read/generate signed 32bit integers from the C level. This was in one of the updates for 2.7alpha. > How is it in 2.6? > Answer: It is not stored there! > > So in either case: this way is no way. The answer is simple: Just wait until 2.7 is out. From then on, all Squeakers will have LargeNegativeInteger available. Andreas

1 0

RE: Display speed on large monitor
by Raab, Andreas 29 Dec '99

29 Dec '99

Ryan, > Interesting... it's just that performance in windows is far > far superior to graphics performance in Squeak. > Operations in windows are actually quite fast, > while in Squeak they are unusably slow. Squeak is using exactly one function of the graphics driver - copying a bitmap of arbitrary depth to the screen. Common Windows applications hardly ever use this function (except from image manipulation programs). You may want to check how well some of these perform. > Hmm, well judging by performance in other apps, I don't > see why Squeak should be so significantly slower.... See above. If that single function isn't performing well you will feel the impact quite heavily. > OH well, I suppose I'll just stick to squeaking at work... Or maybe it's time to get a new machine ;-) Andreas

1 0

[ENH] FontSet reworked
by Stefan Matthias Aust 29 Dec '99

29 Dec '99

--=====================_946496777==_ Content-Type: text/plain; charset="us-ascii" Hi! I refactored and (IMHO) improved the FontSet mechanism to store also existing TextStyles and StrikeFonts into classes. I also created some new fonts for Squeak. But because I used Microsoft TrueType fonts as a source, I'm not really sure whether I'm allowed to publish this work or not. All I can say that Squeak looks really nice with Tahoma or Georgia (one of my favorites) as default font. Tahoma is a very clean computer-display-optimized font which is part of the Microsoft Office (I think). Georgia is one of Microsoft's free web fonts. I also converted Trebuchet MS (another free web font) which looks nearly as nice as Tahoma but has larger ascents and descents. See http://www.microsoft.com/typography/ for more details about these and other fonts. As I understand Microsoft's licence, it would be okay if Squeak would be able to read in the unmodified fonts - displaying them in any way that doesn't matter then. Embedding the fonts into documents is okay they say. However I created something one could perhaps call a derived work - even if I'd say I embedded just a view of these fonts :-) Therefore, I added only a freeware font called "Bookworm" which I found, modified and extended some time agao and for which I now also created the special ^ and _ characters. It's only usuable for large headlines I'm afraid because it looks very awful in Squeak without anti-aliasing in smaller sizes. >From the changeset: Refactored and reworked FontSet stuff. Additional to the BitFont converter (which hopefully still works) you can now store complete TextStyles into FontSet classes using FontSet convertTextStyleNamed: 'Bookworm' As already implemented, you can then use FontSetBookworm installAsTextStyle to (re)install that font family again. The mechanism requires a strike font name consisting of 'family name' 'pointSize' ['B' and/or 'I'] where [ ] means that this part is optionally. The pointSize argument must be a two-digit number, so use '08' for 8pt fonts. Changes in detail: * The FontSet class is now a simple Object-subclass and not a subclass of StrikeFont anymore. * FontSets are stored into the 'Graphics-Fonts' category. * Created fonts are prefixed with 'FontSet' to reduce the probability of name clashes. bye --=====================_946496777==_ Content-Type: text/plain; name="FontSetStuff.zip" ; x-mac-type="705A4950" ; x-mac-creator="705A4950" Content-Disposition: attachment; filename="FontSetStuff.zip" Content-Transfer-Encoding: imap_stub 0,2731,2,9798,0, --=====================_946496777==_ Content-Type: text/plain; charset="us-ascii" -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf. --=====================_946496777==_--

1 0

RE: Display speed on large monitor
by Raab, Andreas 29 Dec '99

29 Dec '99

Ryan, > I am using Squeak 2.6 on the Win32 VM on Windows 98 on a > P2-266 with an ImageAccel 2 card on a 20" 256-grayscale monitor. What's an ImageAccel 2 card?! Never heard of it - who's the manufacturer?! > The card can only operate in one of two modes: 640x480 or 1600x1280. > Rendering speed in Squeak is an order of magnitude slower > than rendering speeds in any Windows applications, and > makes it pretty much unusable for me. Squeak's display speed depends heavily on the quality of the drivers for your graphics card. In particular it depends on how efficient bitmap copy operations are implemented. *Usually*, modern graphics cards implement 2D hardware accelleration for bitmaps and if so, Squeak should be reasonably fast. My best guess is that you've got relatively poor drivers for your card (Windows falls back onto simulation code if the operation is not directly supported by the driver). > I like the way Squeak looks in grayscale, and having all the extra > working space, but I can't make it behave at a reasonable speed. > I tried reduce colour bit depth to 8, 4, or 1, but this didn't > improve behaviour that much. > > Are there newer additions to the BitBlt code for Squeak that > would improve this? I do not think that BitBlt speed is related to this. I've been running Squeak for quite some time on a 200Mhz PPro system with an ATI graphics card and the display speed was perfectly reasonable. > Any support for hardware graphics acceleration? No ... not yet. I'm working on this but it'll take some more time. I'm hoping to release some stuff after 2.7 is out but somehow I doubt that it'll help you, since it will rely on exactly the same things that should be accellerated already. Although it'll make things quite a bit faster (hopefully) the core question is still how good is the graphics card at copying pixels efficiently. Andreas

3 2

Re: Organizing VM sources, CCodeGenerator: suggestionsandquestions
by Bob Arning 29 Dec '99

29 Dec '99

On Wed, 29 Dec 1999 19:55:32 +0100 Stephan Rudlof <sr(a)evolgo.de> wrote: >But how is it with objects in the special objects array? >Are object pointers stored in the special objects array constant - >during one run of squeak - or not? No, they are not constant. The special objects array is just that: an Array. What's special about it is that the VM knows directly of its existence and contents. During a compaction phase any oops in this array are adjusted if the object they point to moves. Cheers, Bob

1 0

RE: Organizing VM sources, CCodeGenerator: suggestionsandquestions
by agree＠carltonfields.com 29 Dec '99

29 Dec '99

> > This was a recent addition to the interpreterProxy, and your VM may > > not support it. Andreas mistakenly called the additional function a > > "minor" revision, so a plugin depending upon its existence > may try to > > run the code, even if it doesn't exist. > > It won't. The interpreter proxy exports a major number and a > minor number, > but the plugin will only accept proxies that have the same > major and *at > least* the minor version the plugin was compiled with. > Therefore, unless > you've hacked setInterpreter() a plugin will never run with > incompatible > proxies. This appears to be correct (I had misread the code of setInterpeter earlier), so the error was mine, not Andreas's. So, help me out -- does the V2.6 VM interpeterProxy support classLargeNegativeInteger() or not? I had a few problems with code that exploded when I made the call, but disappeared after using various hacks to get a handle to the oop more directly. If so, I'm confused why that code crashed earlier, but worked when I passed the class as a parameter. (Maybe I just ran that unit test wrong -- I'll get back to you). If not, I'm confused why the plugins ran at all. > > Now I've taken another way: I'm initializing a variable > > 'myClassLargeNegativeInteger' (to avoid name clashes with > > 'classLargeNegativeInteger' in 2.7) while starting up the > system by a > > startup class method and use this variable then. This works fine and > > avoids unnecessary parameters in ST primitive (your approach) or C > > function calls (my first approach). And also the changes to use the > > features of 2.7 are minimal. > > This is dangerous. If you cache any Oop on the C side it will not be > remapped during GC and the next call to your primitive after > GC will almost > always break the system. Right, and in practice, I didn't actually go that route, but instead passed the class on each call using references to the parameter stack instead which survived GC's.

2 1

Re: [Q] Generic CRC-generation
by JArchibald＠aol.com 29 Dec '99

29 Dec '99

--part1_0.754538e7.25982b25_boundary Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit => 12/22/99 1:00:59 PM EST, djm(a)san.rr.com => << Does anybody out there have code for generic CRC generation? The implementation does not have to be efficient. I am aware of the 16-bit algorithm in the current image, but need to be able to generate CRCs with non-standard polynomials for arbitrary bit length messages. Thanks in advance. >> Doug, Attached is CRC package I did a while ago. I hacked a change to remove BitMasks Class Variable from class Integer; it wouldn't load on 2.6 otherwise. 2.7a fixes bug. Much slower table creation without that Class Variable. It cached BitMasks (1-bit in a width of 0s). This is based rather strictly on the paper by Ross N. Williams. I built the table driven version and then went back and added the reference version from the paper to fully document the program. I later added an 'incremental' version <processes crc's a character at a time, but uses tables for calculating intermediate results>. There are various test methods to execute internal tests; they are probably the best way to figure out how to add your own needs to the package.. ------------------------------------------ I've taken a quick look at Maurice's package. His algorithms are based on Peterson & Weldon's 'Error Correction Codes' so the packages look different when setting up your own crc processor. His goal of using 30 bits for intermediate results is definitely the right way to go for Squeak (with 2 extra bits over SmallInteger in a 32-bit word) so I'll have to figure out how he does the algorithm. Jerry. +--------------------+ | Jerry L. Archibald | +--------------------+---------+ | systemObjectivesIncorporated | +------------------------------+ --part1_0.754538e7.25982b25_boundary Content-Type: text/plain; name="CRC26D~1.ZIP" ; x-mac-type="705A4950" ; x-mac-creator="705A4950" Content-Disposition: attachment; filename="CRC26D~1.ZIP" Content-Transfer-Encoding: imap_stub 0,2665,2,8040,0, --part1_0.754538e7.25982b25_boundary--

2 1

Re: [Paper] Subject-oriented programming through RMI
by Jecel Assumpcao Jr. 29 Dec '99

29 Dec '99

> What are Isis/Horus virtual synchrony protocols (and where can I find > information on them). This page seems to be a good starting point for this: http://www.cs.cornell.edu/Info/Projects/Ensemble/overview.html You can find the Horus home page from there, as well as links to interesting papers and FAQs. -- Jecel

2 1

RE: Organizing VM sources, CCodeGenerator: suggestions and questions
by Raab, Andreas 29 Dec '99

29 Dec '99

Stephan, > > > - A compiler warning would be nice, if someone overrides a > > > predefined function. > > > > See above - this shouldn't be necessary if in a plugin. > > But I have run exactly in this problem, because I have defined a > function which was also defined in interp.c. I'm strongly > supposing that my VM crashed, because isBytes() is not static > there and interfered with my also not static function. Hm ... interesting. I'm not sure what the reason is - perhaps Unix gets confused with the scope of a function. Have you checked from where your #isBytes: was called?! This might give you a hint if there was some confusion. Side note: I'm not an expert regarding the rules of binding exported names from a DSO - perhaps Ian knows?! AFAIK, the Unix Makefiles just export *everything* from the plugin. Windows and Mac don't do this - they just export those functions that are marked as #export (and in this sense any non-exported functions are static to the plugin automatically without the need to declare them as static). Perhaps that's where your problem is coming from. > > > > > > Does regenerating interp.c also create a new sqVirtualMachine.h? > > > > > > > No, it does not. > > Then it is impossible to call > > class := interpreterProxy classLargeNegativeInteger. > > , because in case of LargePositiveInteger it is compiled to > > class = interpreterProxy->classLargePositiveInteger(); > ; and the interpreter struct is declared in sqVirtualMachine.h. > But the function > int classLargePositiveInteger(void); > is defined in interp.c. Because it is not static, the variant for > LargeNegativeIntegers should be directly callable after > regenerating the interpreter. The reason for having a proxy instead of direct bindings to the interpreter is mainly to allow for evolution of the interpreter without breaking what plugins rely on. If you call functions without going through the proxy somebody may use an older VM that doesn't even provide the functions you're relying on (which is okay since the plugin DSO should never start up then) or, even worse, may have a newer VM where some of the meaning has changed. By providing the proxy we know exactly what functions plugins rely on and can make sure that the associated semantics of these functions don't change. Also, the negotiating process upon plugin startup makes sure that the VM and the plugin can work with one another - again this would be very hard to find out if you bind the plugin to the VM directly. Finally, it is true that regenerating the interpreter does not automatically provide you with the latest version of sqVirtualMachine.h - however, 'InterpreterSupportCode writeSupportFiles' does give you the latest version of it. sqVirtualMachine.h is (somewhat) independent from the interpreter because of exactly the reason I mentioned above. > I have to note that I need access to classLargeNegativeInteger in my > plugin. This is possible in my - updated - image, but the > interpreter is the original one from 2.6. So I have to regenerate > the interpreter and asked if sqVirtualMachine.h - now it is clear > that also sqVirtualMachine.c - is/are regenerated, too. Yes, exactly. > Therefore I think now that making interp.c functions static could lead > to problems for someone who hasn't used the sqVirtualMachine.h interface > only. But in spite of this I think that making 'static' as much as > possible is a more clean and better programming style. Ah ... well yes, it's cleaner programming style. But there are a few users of interpreter functions in the VM support code for instance that really want to know what's going on inside the interpreter (such as for printing stack dumps on fatal errors). > > > Couldn't there arise any compatibility problems between different > > > plugins in the current situation? > > > > Not that I know of. > > I think there could arise such problems if name clashes occure. Or is > there a name space separation between different *.so libraries? > At least between VM executable and my plugin *.so there seemed to be > such a name clash... That's a good point. Somebody with more experience than I should look into the problem of exported names in Unix DSOs. > Es muesste wohl J2T (Tausend!) heissen... Sehr lustig ;-) > Are you German native speaker? Nicht nur das, sogar deutscher Staatsbuerger (aber Ossi, disqualifiziert mich das als Muttersprachler, auch wenn ich nicht saechsele?! ;-)) Bin erst vor fast genau einem Jahr nach Kalifornien gezogen. Ciao, Andreas

2 1

Re: RE: Organizing VM sources, CCodeGenerator: suggestions and questions
by Marcel Weiher 29 Dec '99

29 Dec '99

> The reason for having a proxy instead of direct bindings to the interpreter > is mainly to allow for evolution of the interpreter without breaking what > plugins rely on. Isn't it kind of funny that we are building an ad-hoc (I am guessing, correct me if it's not) runtime system with rudimentary reflection capability? Marcel

1 0

← Newer
1
2
3
4
5
6
7
...
46
Older →

Jump to page: