Squeak-dev November 2006

squeak-dev@lists.squeakfoundation.org

157 participants
223 discussions

Squeak-dev-62 , Shout, Monticello and ToolBuilder
by Andrew Tween 25 Nov '06

25 Nov '06

I have been investigating why, in a squeak-dev image, Shout fails to syntax highlight in a MC Snapshot Browser on the working copy of a package but correctly highlights in a snapshot browser on a version of a package. It turns out that when creating a snapshot browser for a working copy, ToolBuilder is used (see MCTool>>show) but when browsing a package version ToolBuilder is NOT used (see MCTool>>showLabelled: ). Which one of these is "correct"? Is ToolBuilder used by anything else? I can fix the Shout problem by making it work with ToolBuilder. But there is little point in doing that if, in the future, ToolBuilder is not going to be used. Andy

2 1

mac carbon VM 3.8.14b3 pending
by John M McIntosh 24 Nov '06

24 Nov '06

I've posted a 3.8.14b3 Mac carbon VM to my ftp site and idisk for testing. Some notes are below, the big changes are for ppc, and macIntel browser support (safari/firefix), headless support, remapping of mouse buttons, and adding Exupery support for MacIntel. http://www.smalltalkconsulting.com/squeak.html Please let me know if there are issues. PS Yes I know sound recording is broken somehow, I hope to explore why at some point this weekend, although the unix code was swapped in at 3.8.6b5 and no one noticed anything, assuming anyone does sound recording anymore, and perhaps it's just a macintel issue, yet another endian issue one can hope. 3.8.14b3 sqMacWIndowUnversial.c Ensure window is created when non- headless and not running under the browser typo in check prevent squeak from showing the window when running standalone for 3.8.14b2. sqMacMain.c Check processsor status at startup, if non-headless and LSBackgroundOnly is true, then switch process to foreground. info.plist rest LSBackgroundOnly to false, from true, to avoid Dock display issue. People wanting true headless app need then to alter info.plist revert bitBlt>copyLoop changes, introduced drawing problems, look at fixing later, or never as time permits 3.8.14b2 Fixes for browser support 3.8.14b1 New browser support on os-x mac/macintel for safari and firefox. This logic now follows the example set by the unix plugin, where we run the VM headless and talk to the browser plugin stub via a two- way pipe to enable fetching data via a URL, drawing the screen, and setting the cursor. Thanks to Viewpoint Research for funding this effort. This VM had limited distribution. sqMacOpenGL.c - remove BROWSERPLUGIN sqMacUnixFileInterface.c - needed include for sqUnixCharConv.h sqMacHostWindow.c - remove BROWSERPLUGIN sqMacMain.c - remove BROWSERPLUGIN, add browser pipe logic, rearrange startup to handle startup with out window for browser support. sqMacMemory.c - remove BROWSERPLUGIN sqMacTime.c - remove BROWSERPLUGIN sqMacUIAppleEvents.c - remove BROWSERPLUGIN sqMacUIEventsUniversal.c - remove BROWSERPLUGIN, expose some internals so new browser support code can call or access. sqMacUnixCommandLineInterface.c - add headfull cmd for browser testing sqMacUnixExernalPrims.c - remove BROWSERPLUGIN sqMacWIndowUnversial.c - remove BROWSERPLUGIN, changes for browser support, assume window is hidden which is different from being headless. sqNamedPrims.h - remove BROWSERPLUGIN sqPlatformSpecific.h - remove BROWSERPLUGIN, add URL_FETCH npSqueak - Directory, add plugin for browser into source tree sqMacNSPLuginUILogic2.c - new file to replace sqmacNSPluginUILogic.c sqMacNSPLuginUILogic2.h - new file to replace sqmacNSPluginUILogic2.c 3.8.13.b4 Headless support sqMacMain.c headless, set background to false if not headless. alter uuid returned to signify which VM this is info.plist swap buttons to ensure cmd/opt of trackpad is right Add LSBackgroundOnly to yes i sqMacEventsUniversal.c headless support sqMacUnixCommandLineInterface.c headless parm -headless added sqMacWindowUniversal.c headless support platforms/Cross/plugins/ExuperyPLugin created 3.8.13.b4, b5, b6, b7 Had limited distribution to test new button modification logic 3.8.13.b3 bitBlt>copyLoop changes, normally it prefetchs the next byte for barrel shifting 64 bits when copying from one form to another, and a dirty secret and old bug is that it reads one word past the end of the Form when it processes the last word in the Form. However when you use surfaces where the surface is allocated elsewhere not in object space and in fact say the allocated form is 2MB and the vm memory system makes the frame past the 2MB range non-readable, why then you die on a read protection failure. So alter the loop to consider if it's preload and the last line we don't do the pre-fetch because that could cause a read failure. 3.8.13.b2 Exupery support, via plugin and changes in the VM for Mac Intel, use merged VMMaker-Exupery change set 3.8.13.b1 Exupery support, via plugin and changes in the VM for Mac Intel. http://minnow.cc.gatech.edu/squeak/5672 -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

4 31

SVI + OmniBrowser + Shout
by Benjamin Pollack 24 Nov '06

24 Nov '06

So, first, I want to say a huge thank-you to Steven for getting SVI running on Squeak 3.9. I loved SVI when it first came out back for 3.7, and was very happy to discover that it runs again on modern Squeaks. That said, I have been completely unable to get SVI + Shout + OmniBrowser all working at the same time. I can do Shout + SVI, SVI + OmniBrowser, and Shout + OmniBrowser, but that's it. Has anyone had success getting all three to work together?

5 5

RE: Progrmaming in Bytecode?
by Swan, Dean 24 Nov '06

24 Nov '06

>> It's not uncommon to find x86 code padded with a lot of NOPs >> that weren't in the original source. > >Cowardly assembler! ;-) > >> [NOPs...] Sometimes they're there to pad the execution pipeline, and >> sometimes it's just because the code generator allocates a whole large >> enough for the largest form of an instruction to simplify the branch >> target calculations. > >We must be talking about M$oft assemblers here. ;^p) Yes. This has been pretty characteristic of MS assemblers as far back as I can remember (i.e. about MASM 2.0 - I remember being quite excited when MASM 4.0 came out - '186 and '286 code!). >The real problem is that the solution in general might require N >iterations for a piece of code with N branches -- if promoting one of them >from short to long causes the next (or, much more problematically, a >preceding) one to become long too. You're such an optimist. O(n) is close to best case for this problem. >This is a weak form of what I suppose one might call an "oscillating >constraints" problem. (Hands up anyone who has ever seen [La]TeX get Hence, stochastic optimization. Even MS uses stochastic optimizers now, even in vb. (didn't want to say that too loud here. ;) ) >The usual cause for "padding" in (capable) assemblers (other than for >prefetch alignment, as you point out) is due to dynamic linking where the >size of call sites isn't known until link time. (On modern systems the Not only prefetch alignment. I have heard, although I don't know the details that sometimes it's desirable to force a dead cycle in the execution pipeline. I can only guess that this would be to influence the scheduling of the execution units for complex instructions, but I consider myself to be only a "casual observer" with respect to this kind of thing. >In Smalltalk you've also got a bigger problem: for very long methods the >range of even unconditional branches might not be enough, at which point >I know this has nothing whatsoever to do with Smalltalk...) Well, to kind of tie this back into something relevant to Squeak - I know a few people have talked about "new" VM instruction sets. It seems that it might help to think about a VM where all instructions are the same size. This could simplify code generation (i.e. compiling methods), and possibly improve performance and *reduce* code size (at least in the case of long methods). The anticipated performance improvement would come from forcing aligned fetches more often and potentially simpler instruction decoding. It's really nice to work with an architecture where all instructions take up one word of memory, take one cyle to execute, and sometimes can cause five or six different useful things to occur during that one cycle. (ok, so I write a lot of DSP code...) The single cycle thing isn't necessarily relevant for Smalltalk, but those "extended" bytecodes are really distasteful to me. -Dean

10 15

2006-11-15 SqF board notes
by Craig Latta 24 Nov '06

24 Nov '06

Hi all-- Thanks again to those of you who have submitted agenda item suggestions[1]. Please keep them coming! The Squeak Foundation board meets online for one hour on the first and third Wednesday of each month. At the 2006-11-15 meeting, Bert, Cees, Craig, Marcus, and Yoshiki attended; Tim was absent. *** There were five action items from the previous meeting. 1. Craig will make a second call for release team volunteers. I did this on 2006-11-03 (see [2]). We actually have some volunteers now! Thanks to those of you who have responded. Again, the board would like to make a decision about the release team during the 2006-12-06 meeting, so if you'd like to volunteer for the release team and haven't contacted us, please do. 2. Craig will make the contributor objects available in addition to the textual summary. I did this on 2006-11-03 (see [3]). Since then, I've incorporated updates from Yoshiki, Kim Rose, and others. Viewpoints has prepared a contributor agreement letter; Kim is now sending it out via email to each known contributor. Watch for it! 3. The board will discuss incorporation further via email. We didn't get to this before the meeting, but we did discuss it during the meeting. There was mention before (when Cees wasn't present) that Cees preferred incorporation in Europe for some reason. At this meeting Cees said he actually prefers US incorporation, as it provides the greatest access to tax-free donations. There was consensus on this point amongst the board. I had previously mentioned a company, Foundation Group[4] that will hold one's hand through the incorporation and US IRS 501(c)(3) processes. We decided that I would get a quote from Foundation Group, then decide whether to engage their services. From reading their website, I expect the cost to be about USD 1500 for both incorporation and the granting of tax-exempt status. We noted that we may want to incorporate in other countries in the future (this is something I would bring up during the US incorporation process). 4. Craig will create a tree of passworded wiki pages for board meeting notes and team status reports. I haven't done this yet. 5. Cees will make another gentle reminder to Jochen about the wiki move. Cees did this, and passed along word from Jochen that the situation will be resolved by 2006-12-31. *** The meeting had seven agenda items. 1. What shall we do about the upcoming loss of the Georgia Tech swiki? Cees and Jochen are handling this. 2. How shall we ensure reliable access to the Squeak website and our other servers? Cees says he can set up a fallback system in a different datacenter for about EUR 30 per month. We did not make a decision as to whether and when to go ahead with this; it's on the next agenda. 3. How shall we incorporate? See previous action item 3 above. 4. Ken Causey suggests that someone from the board help guide discussion on squeak-dev (e.g., the recent Morphic/eToys threads; see [1]). While we think this could be a good idea, no one on the current board has time to do this right now. We may have more to say about this later, though. 5. How should the community support the release and harvesting process? Stephane Ducasse suggests establishing test and build servers. Cees thought this was a good idea and pointed out that we have ample server capacity for this. I suggested that coordinating this could be the responsibility of the release team. Time ran out during this discussion; we did not make a formal decision. 6. Matt asks that we consider declaring a documentation policy, in which each SqueakMap package has at least a minimal usage description, a la the TalkBack package. 7. What shall we do with regard to merchandising? We deferred these items. *** The action items from this meeting were: 1. Craig will get a quote from Foundation Group for incorporating the Squeak Foundation in the United States and obtaining tax-exempt status for it. 2. Craig will create a tree of passworded wiki pages for board meeting notes and team status reports. *** Currently, the next agenda is tentatively: 1. discussion of previous action items 2. How shall we make future contributors aware their submissions must be made available under the terms of the MIT license? 3. How shall we ensure reliable access to the Squeak website and our other servers? 4. How should the community support the release and harvesting process? Stephane Ducasse suggests establishing test and build servers. 5. Matt asks that we consider declaring a documentation policy, in which each SqueakMap package has at least a minimal usage description, a la the TalkBack package. 6. What shall we do with regard to merchandising? thanks! -C [1] http://people.squeakfoundation.org/article/64.html [2] http://tinyurl.com/y2porp (lists.squeakfoundation.org) [3] http://netjam.org/squeak/contributors [4] http://501c3.org -- Craig Latta http://netjam.org/resume

9 10

Re: SqueakMap Package Loader UI
by Chris Muller 23 Nov '06

23 Nov '06

> Comments? Suggestions? Rants? I like the search bar, although if the search button and filter field were to switch places, the flow from left-to-right would feel more natural. Besides the input, the entry field should also output the current search term (i.e., don't erase the last-used term). However, I think the command buttons across the top are a step in the wrong direction. Right-clicking is as important as left-clicking, not just in Squeak but in mainstream Windows too. No one will get very far unless they know, "left click select, right click options". Squeak should give newbies a simple, consistent interface and just a little training. By "simple consistent" I mean showing just the objects and then emphatically delineate the concept of "sending a message" by consistently letting the context menus represent a "message sending" mechanism. Make Squeak "objects all the way up" so the mindset will be consistent when we dive through objects "all the way down". So many interfaces today are focused on showing every single thing the user can click; for example, laden with long scrolling lists or drop-down lists. Their usability is not scalable, and poor because they have the user _laboring_ with the computer to find something instead of vice-versa. With scrolling lists we display every object in the list, now we want to add all possible command buttons for all possible object selections showing too. Ok, not all commands, just few enough that we only *quadruple* the number of widgets the user is initially confronted with. So in the end, the user still has to know to right-click, so this change hasn't really solved the original usability issue. I prefer to present a simple, consistent, usable, well-executed, object-oriented interface. Do so proudly, not apologetically, so that, along with some friendly, basic documentation right in the start-up image explaining how things work, we build appreciation not resentment for the differences.

2 1

Smalltalk Solutions 2007 Call for Participation
by Alan Knight 23 Nov '06

23 Nov '06

The Smalltalk Solutions 2007 Call for Participation is now available at http://www.lwnwexpo.plumcom.ca/smalltalk_cfp.cfm Smalltalk Solutions, in conjunction with IT360 (formerly LinuxWorld & NetworkWorld Canada) is seeking conference participations. Show dates are April 30, 2007 through May 2, 2007 in Toronto at the Metro Toronto Convention Centre. The submission deadline is December 15th, so please get your submissions in as soon as possible. Thank you, Alan Knight Smalltalk Solutions 2007 Program Chair knight(a)acm.org

1 0

OSProcessPlugin loads incorrectly in a squeak-dev 49 image
by bryce＠kampjes.demon.co.uk 23 Nov '06

23 Nov '06

Three methods have corrupt source that stops VMMaker building. Browsers can not display them, debuggers will pop up. No errors were produced while loading. Copying the methods across from a 3.8 image works fine. The methods are: OSProcessPlugin>>initialiseModule OSProcessPlugin>>primitiveCreatePipe OSProcessPlugin>>primitiveGetSession After copying them from a 3.8 image VMMaker will build the plugin and it appears to work. I was using a modified VMMAker-3.8b6 VMMaker which is now on SqueakSource in the Exupery project. I doubt that the version of VMMaker matters. Bryce

4 7

Re: Resilient (was: The Weekly Juan #4: "Smalltalk, Direct Manipulation and End User Programming")
by Lex Spoon 23 Nov '06

23 Nov '06

Jecel Assumpcao Jr <jecel(a)merlintec.com> writes: > Someone mentioned that the language had been changed from Smalltalk, but > it is impossible to tell from the information on the company site > (though you can register to download it and see for yourself). A good > starting point for information about this system is: > > http://www.smalltalk.org/versions/OOVM.html More info here: http://wiki.cs.uiuc.edu/Resilient/Issues This claims, and I had heard, that its blocks cannot be returned or stored in the heap. IMHO that is such a major limitation that it is hardly Smalltalk any longer. -Lex

2 2

new PNGReadWriter with libpng support
by Jens Lincke 22 Nov '06

22 Nov '06

Hi, I made a PNGReadWriter2 and a PNGReadWriter2Plugin with libpng support for fast png reading, which is needed in Sophie and future versions of Plopp. Currently it can only read a png file and returns only 32bit forms. The repository for this is http://www.squeaksource.com/PNGReadWriter2 and I build it with vmaker 3.8b6, squeak 3.9 and the squeak 3.9-8 unix sources. to build it under linux, create a Makefile.inc with LDFLAGS += -lpng in platforms/unix/plugins/PNGReadWriter2Plugin contributions, e.g. writing images, are very welcome. - Jens Lincke -

5 6

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

Jump to page: