Vm-dev November 2009

vm-dev@lists.squeakfoundation.org

26 participants
37 discussions

cocoa squeak 32/64bit vm 5.0.0 ALPHA 1 ships
by John M McIntosh 25 Nov '09

25 Nov '09

I've sent a copy of the VM to a couple of people to try, if anyone else is interested please email me for the ALPHA -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

4 3

Trunk stable?
by Michael van der Gulik 24 Nov '09

24 Nov '09

Hi. Is there a policy of keeping trunk in usable condition? I've found this problem with the Linux VM: http://bugs.squeak.org/view.php?id=7419 I was going to build a new VM to see if I could fix this problem and I'd like to know if the source from trunk is the best place to start. Gulik. -- http://gulik.pbwiki.com/

3 3

More serial ports under win32
by Levente Uzonyi 24 Nov '09

24 Nov '09

Hi, Please take a look at http://bugs.squeak.org/view.php?id=7410 Cheers, Levente

1 1

macintosh cocoa squeak 64bit vm rewrite
by John M McIntosh 24 Nov '09

24 Nov '09

Ok, I've checked in the latest changes to isqueak.org. I've managed to work my way thru the file and the directory logic by testing with numerous nested symbolic links and Finder aliases. Less robust alias resolvers freak when given a path with three Finder Aliases embedded within it. Lastly. I've added clipboard support. For people who build a VM, you should check to see if keyboard data entry works, and that using the file system seems sane, especially if you use accented characters and symbolic links and Finder Alises to manage your directory structure. Also consider moving characters from various applications to/from the VM to see if the clipboard is functionally correctly. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

Setting up a VMMaker image
by Andreas Raab 23 Nov '09

23 Nov '09

Hi - Since setting up a VMMaker image has become a serious pain I thought I'd post my process for documentation here. This is what I did: [ ] Start with a trunk image from http://ftp.squeak.org/trunk [ ] Load Speech: http://source.squeakfoundation.org/39a [ ] Load FFI version 3.9.1: Universes (System>>FFI version 3.9.1) [ ] Load VMMaker: http://squeaksource.com/VMMaker [ ] Load Balloon3D-Constants: http://squeaksource.com/Balloon3D [ ] Load Balloon3D-Plugins: http://squeaksource.com/Balloon3D [ ] Load Freetype: http://squeaksource.com/FreeTypePlus [ ] Load Freetype-Plugin: http://source.impara.de/freetype After doing all this I have a healthy current VMMaker image. Cheers, - Andreas

8 10

squeak cocoa 64bit vm rewrite progress
by John M McIntosh 23 Nov '09

23 Nov '09

Ok, I'm managed to get to the point where the keyboard event entry mirrors the carbon vm, excluding a bug which no-one ever reported. I've also gotten the cmd key logic to work properly and resolved the cursor setup issues. At the moment. I'm still not sure the alias/symbolic link logic works correctly when you want to delete a symbolic or alias file, versus the target of the file. There seems to be a problem with the directory logic and what the Squeak smalltalk code thinks file names are based on versus what I return from the dir_lookup (UTF8 or so we think). No doubt it's an issue with normalized versus non-normalized UTF8, which I'll figure out in the morning. All the changes were checked into isqueak.org for the moment. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

Return a value from the image to the VM
by Rob Rothwell 22 Nov '09

22 Nov '09

Hello... For scripting purposes, I just want to be able to do something like: SmalltalkImage current quit: errorCode. So that in the VM I can essentially do: return errorCode. at the end of sqMain? Any pointers on how to push a value BACK to the VM? I have only barely dabbled with adding some custom menu commands to the VM long ago, and have no idea where to start. Thanks! Rob

2 1

Performance, Quality and Process [was Array new: SmallInteger maxVal]
by Eliot Miranda 20 Nov '09

20 Nov '09

Hi All, I'm not happy with this fix and I'm not happy with the lack of process behind it. First there has been insufficient discussion of what the right behaviour is. Second, the fix David has written does lots of computation (shifts) to check a valid size request that could be pushed earlier at initialization time, which would allow e.g. a vmParameterAt:put: to modify the max allocation request size. Third, there is no review of fixes; we just put them out there. I'm concerned about performance, code quality and a lack of process for agreeing fixes. But at the same time I don't want to institute a bureaucracy or slow down the pace of development. Do others share my concerns? What suggestions have you? One problem here is that Cog will introduce a huge raft of changes to the VM and to Slang, and so possibly the whole issue is moot. We'll face the issues as we try and integrate my Cog VM into the squeakvm trunk. But it might be worth thinking a little about the issues up front. David, I know you're technical lead, and I'm not trying to depose or undermine you. But I do think we can benefit from discussion and review of major changes. Alas, my Cog work not being generaly available yet is going to cause problems down the line. I need to at least hurry up and get the StackInterpreter released. On Tue, Oct 20, 2009 at 7:39 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Tue, Oct 06, 2009 at 06:58:30PM -0400, David T. Lewis wrote: > > > > On Tue, Oct 06, 2009 at 10:05:02PM +0200, Nicolas Cellier wrote: > > > > > > >From http://code.google.com/p/pharo/issues/detail?id=1282 > > > Is this known? > > > > Thanks, it's known now :) > > > > Also added to Mantis at http://bugs.squeak.org/view.php?id=7405. > > > > Petr: Yes this is definitely a cool bug. > > A fix for this is on Mantis 7405 (http://bugs.squeak.org/view.php?id=7405 > ). > > The VMMaker updates are in SqueakSource in VMMaker-dtl.142. > > A separate patch is needed for platforms/unix/vm/sqUnixMemory.c (see the > Mantis report, patch also sent to Ian). > > I have not tested Windows or Mac OS, but the basic scenario now is that > the VM will limit the size of memory increase requests to 31 bit integer > so support code can check for overflows. The requests from the VM are > guaranteed (I hope) be valid 31 bit integers. > > Allocation requests of > 950 MB seem to be possible, although I do not > have enough memory on my PC to verify that it actually works. > > Limiting allocation requests to more reasonable limits would be the > responsibility of the image. > > Dave > >

7 16

mac os-x 64bit vm update
by John M McIntosh 20 Nov '09

20 Nov '09

I've check in the latest changes to isqueak.org. At the moment, I've added the mouse up/'down/drag for three button mice. I have not added scroll wheel support yet. I've added the basic keyboard key down, char, up for keyboard interaction. However this does not include deadkey support or cmd-key pass thru. Bugs: (a) Cursor is not not updated correctly in 64bit mode. Tomorrow I hope to resolve issues with the keyboard logic. Today I spend many hours figuring out that if you create a CGImageRef using a data provider, the data provider is *NOT* actually asked for the data which would toss bytes from the Squeak oops in ioShowDisplayOnWindow at creation time. Rather the bytes are only read when the CGImageRef is used for drawing. Now in the past once a CGImageRef was setup it appeared Apple used a COW VM trick to ensure the data was not mutable. However this seems to have changed again in 10.6. We don't experience the problem in the old logic because we do a context sync which seems to move the data into the graphics engine after we create the CGImageRef. The solution is to copy the data from squeak into a malloced area then free after usage. At the moment the drawing pattern I am using is to place draw requests from ioShowDisplayOnWindow onto a FIFO queue, then on the ioForceDisplayUpdate we send the drawing atoms to the drawing queue and invalidate the combined window area. Or if 20 milliseconds pass after a ioShowDisplayOnWindow and no ioForceDisplayUpdate we then do an explicit ioForceDisplayUpdate to flush the drawing. The desire is to flush data to the screen on the ioForceDisplayUpdate boundary, not on each ioShowDisplayOnWindow. The other interesting thing is that I have squeak running as a background pthread versus on the main UI thread. We'll see how that works out since it appears to be more tolerant than in past years. This model change results in an idle Squeak using 50% less CPU than before since it's sleeping, and the UI is sleeping. Previous versions would have to poll the UI, which was expensive. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

Re: [squeak-dev] Re: Test breaking mouse-wheel scrolling (was: Re: Re: Test failures in trunk)
by Igor Stasenko 18 Nov '09

18 Nov '09

Btw, what about altering VM to generate a true mouse scroll events, so it wont be dependent from keyboard events anymore? 2009/11/18 Igor Stasenko <siguctua(a)gmail.com>: > 2009/11/18 Andreas Raab <andreas.raab(a)gmx.de>: >> Igor Stasenko wrote: >>> >>> It does not fixes the problem for me :( >>> I wonder, why mouse scroll behavior depends on flaps or locale.. >> >> Most likely because scroll events are delivered as Ctrl-UpArrow and >> Ctrl-DownArrow events and there is a chance that the input converters muck >> with that. I had a quick look but I couldn't find much. Some things you >> could try is: >> * see if typing Ctrl-UpArrow and Ctrl-DownArrow scrolls text > > works fine. > >> * check what running "Sensor kbdTest" shows when you operate the scroll >> wheel > > shows > 30 16 > 31 16 > in display corner, when i scrolling da wheel > >> * check the keyboard converter in World primaryHand to ensure it's correct. >> > it points to an UTF32JPInputInterpreter, which is wrong.. > > I found how to revert back to EN locale: > Locale currentPlatform: (Locale isoLanguage: 'en') > > after that, mouse scroll starts working again. > > But back to the question: > - why it not works in japanese locale? Is japanese guys not using > mouse scroll, or their goverment prohibits from use a mouse scroll > wheel? ;) > >> Cheers, >> - Andreas > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev November 2009