Squeak-dev January 2007

squeak-dev@lists.squeakfoundation.org

160 participants
184 discussions

re: the 2007 Squeak Foundation board election
by Craig Latta 25 Jan '07

25 Jan '07

Hi all-- Just a note to say that I'll stand again for the Squeak Foundation board. In the past term, I got the board to meet on a regular basis. I established meeting agendas, kept the meetings moving, captured the meetings, and produced edited notes for the community. I coordinated a master list of Squeak's code contributors, so that we can produce a fully-relicensed version of the system. I began the process of incorporating the Squeak Foundation as a tax-exempt corporation, so that we can pursue budgets that are both realistic and consequential. I coordinated the Squeak BOF at OOPSLA 2006. I helped establish new community teams, particularly the release team, and acted as board liaison for several of them. I participated in community discussion on several mailing lists and the IRC channel. My vision for Squeak is that we make it approachable, inspiring, and serious fun for all comers. In the next term, I plan to complete incorporation, and help decide how best to spend our sustainable resources for the community. I want to help the teams function smoothly (again, particularly the release team). And I want to have more fun with Squeak myself! thanks again, -C -- Craig Latta Smalltalkers do: [:it | All with: Class, (And love: it)] http://netjam.org/resume

1 0

Should every kernel class x provide support for (x new) printString and (x new) hash
by Klaus D. Witzel 24 Jan '07

24 Jan '07

Hi folks, on the beginners list Brent McConnell reported a situation in which (Collection new) was assigned to an automatic declared variable x and a subsequent (x := OrderedCollection new) still called for the dubugger, because aDictionary(Set) relies on ((Collection new) hash) for already declared variables. You can provoke the walkback with printIt on (Collection new) hash but also on (Collection new) Q: wouldn't it be noob-friendlier if *all* kernel classes avoided the debugger in doIt/printIt situations? Just my CHF 0.05 :) /Klaus

5 16

[ANN] Magma 1.0r39
by Chris Muller 24 Jan '07

24 Jan '07

I have just posted a new version of Magma with Keith Hodges' relative-path support enhancement. Now that they are officially included, I hope Keith will update his Seaside-Magma-Pier (wiki out of the box) image. There are number of other minor enhancements, fixes and performance improvements: - Ability to reference a MagmaSession in the domain. Any reference will always materialize to whatever session did the materialization. - Some enhancements to MagmaMutatingProxy to better support PointerFinder and Object Explorer tools. - After adding a new MagmaCollection with indexes in one commit, don't enumerate the collection again to build its indexes (omitting the ones it already added). This is strictly a performance improvement for a specific scenario. - Corrected reference to Morph class to just its name, #Morph. - Serialization optimization - No longer opening repository just to determine files, because a Magma repository now owns the entire directory. Magma continues to be fully-supported, questions or issues are addressed promptly. - Chris

1 0

saving window top/left in the image, and what does it mean?
by John M McIntosh 24 Jan '07

24 Jan '07

For reasons lost in time, although one of the readers might now, the vm stores the window width/height in the image file, but not the top/ left. Now Eliot Miranda asked me about launching Squeak on his mac and having it show up as full screen on the secondary display. Which of course does not happen since it opens on the main display and goes to full screen there. To do this I would need to know that I have to place the window on the secondary display, or elsewhere in the coordinate system which would be the secondary display, then go to full screen. I'd like to propose that we grab another 4 bytes (8 bytes?) out of the header and store the top/left in mmm macintosh quickdraw coordinate systems values. Then on main window open a VM would need to see if the window created based on the top/left be visible, if so to open it at those coordinates, otherwise fall back to the historical code. I realize of course this might not work for Xwindows or Windows (no clue) but even just having the ability to position a squeak window at startup at a given location is more useful than our fall back position of 44 & 8. Perhaps even suggesting a number (2) meaning use the secondary screen or something, mm and top/left being 0/0 of top/left of 2nd screen. Thoughts? Well one part is do we need this? The second is how to implement in a manner that all VMs would do the right thing based on some magic numbers. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

3 3

Re: [Vm-dev] saving window top/left in the image, and what does it mean?
by John M McIntosh 24 Jan '07

24 Jan '07

Oh sure make me work all weekend on Sophie, and I forget *all* about Ffenstri, has to be your fault Tim. I mean that assumes there is *any* interest in Ffenstri you know, well I did repackage for 3.10, likely works under 3.9 too. mmm one thing we don't have is access to window (1) which by default is the window opened by the vm... Lets see hwp := HostWindowProxy new. hwp windowHandle: 1. "create this accessor" hwp on: Display. hwp windowPosition: 100@100 I doubt closing window (1) would be a good thing to do, likely the mac carbon VM will freak, must fix that... ya, open squeak, use windowPosition: to put where you want window. On Jan 23, 2007, at 2:39 PM, tim Rowledge wrote: > > On 23-Jan-07, at 2:26 PM, John M McIntosh wrote: > >> For reasons lost in time, although one of the readers might now, >> the vm stores the window width/height in the image file, but not >> the top/left. > > And a totally pointless thing that is too. There simply isn't any > need to do it - especially with the Ffenstri code allowing easy > access to setting the position/size/etc of the window(s). All this > can be in the image startup code instead of buried pointlessly in > the file header. We could query the screen size(s), decide sensibly > where to locate the window, whether it can match the saved size or > not, all that in the image with easily modified policy. > > I don't think we had secondary screen stuff specified as yet for > Ffenestri but it is probably a trivial addition. > > > tim > -- > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: IXM: Initiate X-rated error Messages > > -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

1 0

Re: [croquet] Linux: My computer is so fast ...
by Bert Freudenberg 24 Jan '07

24 Jan '07

On Jan 23, 2007, at 23:39 , Mike O'Brien wrote: > Bert Freudenberg says: > >> Well, I got a request by one desperate Linux user who felt nobody >> from the Croquet community was able to help him get Croquet running >> under Linux. I do not have a real Linux box anymore (well, except for >> the $100-laptop), so I tried to run it in my Parallels install. It >> did not work, the red "connecting" screen does not seem to finish. > > Ok, this is just a theory, but if I remember correctly, > Parallels does not (yet) support video acceleration. Therefore > I question whether an OpenGL program would work well (or at all) > under Parallels, especially if the software more or less > insists that the accelerator hardware be there. > > I may be wrong here but... ... you most certainly are ;-) I'm just running a network test, plain Squeak, no OpenGL in sight. And I *wrote* the OpenGL stuff for the Linux VM back when, so I'm pretty sure it does not do any OpenGL operations behind our collective backs ;-) - Bert -

1 0

Re: [croquet] Linux: My computer is so fast ...
by Mike O'Brien 23 Jan '07

23 Jan '07

Bert Freudenberg says: > Well, I got a request by one desperate Linux user who felt nobody > from the Croquet community was able to help him get Croquet running > under Linux. I do not have a real Linux box anymore (well, except for > the $100-laptop), so I tried to run it in my Parallels install. It > did not work, the red "connecting" screen does not seem to finish. Ok, this is just a theory, but if I remember correctly, Parallels does not (yet) support video acceleration. Therefore I question whether an OpenGL program would work well (or at all) under Parallels, especially if the software more or less insists that the accelerator hardware be there. I may be wrong here but... Mike O'Brien

1 0

Linux: My computer is so fast ...
by Bert Freudenberg 23 Jan '07

23 Jan '07

... that it finishes before it even started. I just ran Croquet's tests on a MacBook Pro with Ubuntu Linux in the Parallels PC emulator: CroquetVMTests new quickLatencyTest results in #(2.451390797266446e6 1073741822 0.023 3) which is a test failure. The first value is supposed to be the average number of milliseconds for a local network roundtrip, the second the maximum. Strange values. Looking at the actual test runs, here are the results sorted by occurrence, values in hex: a SortedCollection(63481->'16r0' 4374->'16r1' 131->'16r2' 61- >'16r3FFFFFFE' 45->'16r3FFFFFFD' 44->'16r3' 29->'16r4' 20- >'16r3FFFFFFC' 10->'16r7' 3->'16r6' 3->'16r5' 2->'16r8' 1- >'16r3FFFFFFB') The method to measure the runtime is [...] timeToRun. How could that possibly answer a negative amount?! Only if the millisecond clock turns backwards. The new Apple machines indeed are very fast, but *that* fast? - Bert -

2 2

Re: [croquet] Linux: My computer is so fast ...
by Bert Freudenberg 23 Jan '07

23 Jan '07

Well, I got a request by one desperate Linux user who felt nobody from the Croquet community was able to help him get Croquet running under Linux. I do not have a real Linux box anymore (well, except for the $100-laptop), so I tried to run it in my Parallels install. It did not work, the red "connecting" screen does not seem to finish. So I tried running the Croquet unit tests, which worked fine except for this strange behaviour. The clock values are actually fine when not doing I/O, so I still suspect the VM to be faulty. - Bert - Am Jan 23, 2007 um 22:19 schrieb David P. Reed: > The Linux SqueakVM may run strangely under parallels - Linux has a > complex way of using the various Intel hardware clocks, and the > Parallels IntelVM emulates the hardware clocks. In particular the > TSC (high res) clock runs at a rate dependent on the cpu frequency, > which changes dynamically under OS X, but that dynamic change > cannot easily be detected in a virtualized Intel machine. > Wondering why you don't use the OS X vm? > > Ken Causey wrote: >> Perhaps a time correction through an NTP daeomon or the like? >> >> Ken >> >> P.S. Of course that only makes sense if the clock used is the actual >> time and not something like a clock time independent value like >> milliseconds since program start. Maybe. I'm not sure how that is >> calculated either, truth be told. >> >> On Tue, 2007-01-23 at 20:43 +0100, Bert Freudenberg wrote: >> >>> ... that it finishes before it even started. >>> >>> I just ran Croquet's tests on a MacBook Pro with Ubuntu Linux in >>> the Parallels PC emulator: >>> >>> CroquetVMTests new quickLatencyTest >>> >>> results in >>> >>> #(2.451390797266446e6 1073741822 0.023 3) >>> >>> which is a test failure. The first value is supposed to be the >>> average number of milliseconds for a local network roundtrip, >>> the second the maximum. Strange values. Looking at the actual >>> test runs, here are the results sorted by occurrence, values in >>> hex: >>> >>> a SortedCollection(63481->'16r0' 4374->'16r1' 131->'16r2' 61- >>> >'16r3FFFFFFE' 45->'16r3FFFFFFD' 44->'16r3' 29->'16r4' 20- >>> >'16r3FFFFFFC' 10->'16r7' 3->'16r6' 3->'16r5' 2->'16r8' 1- >>> >'16r3FFFFFFB') >>> >>> The method to measure the runtime is [...] timeToRun. How could >>> that possibly answer a negative amount?! Only if the millisecond >>> clock turns backwards. The new Apple machines indeed are very >>> fast, but *that* fast? >>> >>> - Bert -

1 0

Re: [croquet] Linux: My computer is so fast ...
by David P. Reed 23 Jan '07

23 Jan '07

The Linux SqueakVM may run strangely under parallels - Linux has a complex way of using the various Intel hardware clocks, and the Parallels IntelVM emulates the hardware clocks. In particular the TSC (high res) clock runs at a rate dependent on the cpu frequency, which changes dynamically under OS X, but that dynamic change cannot easily be detected in a virtualized Intel machine. Wondering why you don't use the OS X vm? Ken Causey wrote: > Perhaps a time correction through an NTP daeomon or the like? > > Ken > > P.S. Of course that only makes sense if the clock used is the actual > time and not something like a clock time independent value like > milliseconds since program start. Maybe. I'm not sure how that is > calculated either, truth be told. > > On Tue, 2007-01-23 at 20:43 +0100, Bert Freudenberg wrote: > >> ... that it finishes before it even started. >> >> I just ran Croquet's tests on a MacBook Pro with Ubuntu Linux in the >> Parallels PC emulator: >> >> CroquetVMTests new quickLatencyTest >> >> results in >> >> #(2.451390797266446e6 1073741822 0.023 3) >> >> which is a test failure. The first value is supposed to be the >> average number of milliseconds for a local network roundtrip, the >> second the maximum. Strange values. Looking at the actual test runs, >> here are the results sorted by occurrence, values in hex: >> >> a SortedCollection(63481->'16r0' 4374->'16r1' 131->'16r2' 61- >> >'16r3FFFFFFE' 45->'16r3FFFFFFD' 44->'16r3' 29->'16r4' 20- >> >'16r3FFFFFFC' 10->'16r7' 3->'16r6' 3->'16r5' 2->'16r8' 1- >> >'16r3FFFFFFB') >> >> The method to measure the runtime is [...] timeToRun. How could that >> possibly answer a negative amount?! Only if the millisecond clock >> turns backwards. The new Apple machines indeed are very fast, but >> *that* fast? >> >> - Bert - >> >> >> >> >>

1 0

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

Jump to page: