Squeak-dev January 2001

squeak-dev@lists.squeakfoundation.org

112 participants
318 discussions

RE: CharRecog & ALT-?? keys
by Nathanael Schärli 07 Jan '01

07 Jan '01

Hi all > Don't forget that Nathanial Schaerli did a fantastic recognizer that > is much much better than the one in the download. He has promised to > put it in 2.9 when it settles down enough. (Nathanial: has it?) Oh yes, it has! I'm going to be very busy in January, but perhaps I'll find the time to do it anyway. If not, I'm going to put it into 2.9 at the beginning of February... Cheers, Nathanael -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Nathanael Schärli Rüttenenstrasse 41 CH-4515 Oberdorf, Switzerland Phone: +41 32 622 89 03 Fax: +41 32 621 78 50 Email: n.schaerli(a)gmx.net /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

2 1

AW: AW: Squeak and the thing GUI
by HNBeck＠t-online.de 07 Jan '01

07 Jan '01

Hi, > > [Hans N. Beck] Hmmm. That's not clear to me. Two points: > 1. one can find Morphic only in Squeak environement - so it is not portable over all Smalltalk systems ?? You are using a different definition of "portable" than Bert was. He was stating that Squeak (and its GUI's) are portable across many OS/hardware platforms, not different Smalltalk variants. Squeak is ported to more platforms than any other Smalltalk, including Windows, Mac, Linux and various Unixes, BeOS, several PDA's, etc. So, I'm not sure why you would need to port your code to a different Smalltalk... at least you wouldn't need to in order to gain access to a new OS/hardware platform. [Hans N. Beck] ok. The wish porting over different Smalltalks comes from the search for GUI principles beeing part of any Smalltalk system, comparable to the desktop/widget logic which can be found on any modern comercial PC environement today or as another example the collections beeing part of any Smalltalk. But what I now learn from this mailing list until know is, Morphic can be seen as "MetaGUI" , it is not made to rebuilt the GUI Squeak is running on. A Squeak GUI built in either MVC or Morphic would be instantly portable accross all of these OS/hardware platforms, because it does not use any native widgets. [Hans N. Beck] ok On the other hand, if you absolutely had to use native Win32 widgets in your GUI, then Squeak currently does not support this. But then it is much more difficult to port a Win32 native GUI to another OS platform than it is to port a Squeak GUI. Computers are generally fast enough these days that non-native GUI's are plenty fast anyway. Look and feel is another matter, but I wouldn't be surprised if there were some sort of Windows look and feel emulation add-on developed by someone for Squeak sometime soon, if that's what you needed. (Also, I'm currently working on some improved default looks for the standard Squeak Morphic GUI.) [Hans N. Beck] Hmm. The point I started was, to use Squeak to do

1 0

Re: ["BUG"][FIX?]Incorrect Pseudo-Codefor#whileTrue:/#whileFalse:?
by Bob Arning 07 Jan '01

07 Jan '01

Hi Mark, On Sat, 06 Jan 2001 16:47:21 -0600 Mark van Gulik <ghoul6(a)home.net> wrote: >> !BlockContext methodsFor: 'controlling' stamp: 'RAA 1/5/2001 23:10'! >> repeatEndlessly >> | loopAgain | >> "Evaluate the receiver repeatedly, ending only if the block explicitly >> returns." >> >> loopAgain _ thisContext pc. >> self value. >> thisContext jumpTo: loopAgain stack: 1. >> self halt. >> ! ! > >That's interesting, I was intially worried about the stack depths not >corresponding too. On a guess I'd say it failed some time around the 12th >iteration (from my recollection of the short context size). Did you ever >crash the VM with such a test? Nope, although some of the walkbacks looked rather odd. >Anyhow, this is fixed by using #realPc >above. Then the call site to #realPc is expecting one value on the stack, >which matches the call site to #jumpTo:. Thanks for explaining that. I did this without examining exactly what tricks the compiler/VM were using (I wasn't up for the headaches). I just tried things that ought to work and threw away those that didn't. >> loopAgain _ thisContext pc + 5. "5 is the size of the bytecodes for this > >Hm, that was a bit kludgy. Yep, that was a performance tweak that your #realPC handles much better. > >> !BlockContext methodsFor: 'controlling' stamp: 'RAA 1/4/2001 10:21'! >> whileTrue4: aBlock >> >> " >> | x | >> x _ 0. >> [(x _ x + 1) < 100] whileTrue4: [Transcript show: x printString; cr]. >> " >> [ >> self value ifFalse: [^self]. >> aBlock value. >> ] repeatEndlessly >> ! ! > >This is the cleanest implementation. My vote is to add special compiler >support for #repeatEndlessly (VisualWorks calls it #repeat), and have >special compiler support for it. Then the #whileTrue: operations don't need >to have bodies that look recursive. Instead, they can appear to invoke >#repeatEndlessly (but really be implemented with branch bytecodes because of >the way #repeatEndlessly is handled by the compiler). The implementation of >#repeatEndlessly can use #restart or whatever, as it only makes a >performance difference if you send a non-literal block the #repeatEndlessly >message (which is very easy to avoid). My vote, too, if we decide this is broken enough to warrant fixing. WRT #repeatEndlessly, I picked that since #repeat was already used and relies on, guess what?, #whileTrue. If this change is accepted, then we could use either or pick something else. Cheers, Bob

1 0

Re: More on Squeak installation
by Bob Arning 07 Jan '01

07 Jan '01

Hi peter, On Sat, 6 Jan 2001 08:06:23 -0500 "Peter Schuller" <peter.schuller(a)infidyne.com> wrote: >But so there is absolutely no depdencent what so ever, except for the >default name of the image it tries to load? I already know that the VM is >more or less separate from the Smalltalk stuff (i.e. the image), but I was >thinking there might be some details in the image low-level stuff that might >be best left to the "right" VM. The VMs generally work well from one release of the image to the next. An exception in recent memory was somewhere in 2.8 some code was changed relating to the lookup of external primitives, IIRC. At that point a new VM was strongly recommended to avoid decreased performance. There may come a time when, e.g. bytecodes change or the layout of a class the VM really depends on changes, that a new VM will be *required*, but that hasn't happened in a while. >Another reason I preferred this way of updating is that I read a comment >from someone (don't remember who - no offence :)) who had found that Morphic >was faster with an image updates manually with the changes file rather than >using the stock image (IIRC). > >Based on *very* simple tests I seem to be seeing the same thing. For >example, scrolling the list of all methods of Object in the class browser in >a morphic project leads to 100% CPU utilitzation in the 2.7 VM/stock 2.9 >image combination (on an Athlon 500, Linux). But doing the same thing with >my new 'fresh' updates 2.8 image results in 50% CPU utilization. It may be that something "happened" to the stock image. If someone who is experiencing this disparity of behavior were to run a MessageTally for 10 or 20 seconds in each of these images, it might help us figure out what the cause is. Cheers, Bob

1 0

AW: Squeak and the thing GUI
by HNBeck＠t-online.de 07 Jan '01

07 Jan '01

Hi, > I know that prof. Smalltalks have full Win32 GUI binding, COM bindung > etc. On the other side: Morpic seems interesting, but it's only a > thing of squeak, isn't it, not portable ? Actually it is portable *exactly* because it does not use the platfrom GUI stuff. [Hans N. Beck] Hmmm. That's not clear to me. Two points: 1. one can find Morphic only in Squeak environement - so it is not portable over all Smalltalk systems ?? 2. GUI developments means developing for the widget based logic of /KDE/GNOME/Windows/Be. So developing a interesting GUI which can not be ported to the target system becaus of completly different logic behind, it (the GUI prototype in Smalltalk) is in this sense no portable. (TCL/TK is portable over the various systems, but has a widget based logic similar to Windows) Conclusion: If I want to build W32 GUI prototypes, I must use a (commercial) Smalltalk (example to make this more clear: Oberon ist a nice system with interesting GUI, but for Win32 development you should use Oberon/F, which has all win32 widges as part of the system....) Where is my knot in thought ? Morphic is something like an OO-framebuffer. It's not just pixels on the screen like most other GUIs but everything you see is an object (a Morph) that can be manipulated and assembled into more complex entities like dialogs or menus or whatever. You can learn about the Morphic philosophy in the numerous Self papers (http://www.sun.com/research/self/) [Hans N. Beck] So the framebuffer the pixels are virtual ? That sounds to be sloowwly. Or is there any efficient connection to hardware by a special object (the canvas you mentioned ?) Ok, I'wd have a look at Self Greetings Hans

2 1

[BeOS VM] Fixed bad links for 2.8 BeOS VM download
by Colin Sarsfield 06 Jan '01

06 Jan '01

The original links I posted for the BeOS Squeak VM 2.8 were incorrect. Please redownload the VM and/or VM source files if you attempted to the download the most recent version earlier. You do not need to redownload the image and changes files. Thanks, Colin

1 0

does the APSL update help Squeak?
by merlyn＠stonehenge.com 06 Jan '01

06 Jan '01

New version of APSL at http://www.opensource.apple.com/apsl/ Slashdot discussion at http://slashdot.org/article.pl?sid=01/01/05/0111218 -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

2 3

Where is Squeak Headed 2001?
by Karl Ramberg 06 Jan '01

06 Jan '01

I just read trough the Where is Squeak Headed? ( http://squeak.org/headed.html ) web page on squeak.org. And most of these goals have been reached :-) Now I'm curious to know what next years goals are Karl

1 0

Re: MacOSX port
by Marcel Weiher 06 Jan '01

06 Jan '01

> From: Karl Goiser <squeak(a)wattle.net> > In an earlier message, you said the VM was multi-threaded. Does that mean > it will go faster on a dual processor Mac? Two answers to that: no, and not really. No, the bytecode interpreter itself is not multi-threaded, and thus won't go any faster. The "not really" part is that you have some parallelism between the Cocoa-side event-handling code, so in theory you could have some speedup, but I doubt that this would be measurable if it is present at all, with synchronization overhead being what it is. > With sound support and the like, I understand that it is possible to call > Carbon code from Cocoa code? If that is the case, maybe that is the way to > go until Apple gets everything finished... I'd prefer to just use CoreAudio and other basic APIs. Marcel

1 0

[ENH] VMMaker; build source code trees for any platform on any platform
by Tim Rowledge 06 Jan '01

06 Jan '01

I've just completed a reasonable v1.0 release of a VM maker tool. It builds the source tree for any platform, with any combination of internal/external/not-there plugins. It currently assembles a new directory tree layout that is not suited to any makefile regime except my own Acorn stuff, but that should be trivial for anyone to adapt to. Basically all the core-VM & internal plugins code is in one place and all the external plugins are in a list of places. No need for the unix 'PLUGINS' file that Ian so dislikes. I think that almost any directory tree could be produced with a little fiddling, should you really want anything different. As an added bonus, it is possible with the VMMaker to keep the platform specific files (code, makefiles, resources etc) for ALL platforms in one nice clean tree. The VMMaker can produce a source tree for any platform that you have the plat. code for. All you need to complete the story is a suitable cross-compiler; or maybe a file transfer utility. There is no flashy UI yet. It would be nice to have one. Likewise there is no form of savable/loadable configuration yet. I also took the opportunity to cleanup the naming of some of the plugins and associated files a little; as Ian and some others have noted, a few of them were really pretty silly names. I have _not_ completely excised all the code that really ought to be pluginised yet; the ADPCM stuff, the remaining sounds stuff etc still ought to be pulled somehow. Because of the plugin renaming there is a compatibiliy problem for now; some methods need alterations to refer to the new names. I have changesets available for that, or the renaming could be deferred maybe. Rather than spam everyone with a bunch of big files, I've placed them in http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/VMMaker/ - including the 'platforms' directory for Acorn and unix for illustration purposes. Note that ONLY the Acorn tree is correct, since I haven't reworked the unix makefile stuff yet I'll assume some changes to the unix tree will be warranted. If you're a autoconf/whatever expert with a few hours to spare, let me know what you can do with it. An interesting point to note is that the Acorn VM has become approx 10% faster by shrinking the VM (by making _everything_ external, including BitBlt) and the core VM is ~140Kb instead of ~300kb. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- He demonstrates that beauty times brains is a constant.

2 1

← Newer
1
...
23
24
25
26
27
28
29
...
32
Older →

Jump to page: