Squeak-dev June 2014

squeak-dev@lists.squeakfoundation.org

41 participants
191 discussions

Running headless on a Mac
by Frank Shearar 03 Jul '16

03 Jul '16

OK, so I've run out of patience in my flailing around. All I want is to run a headless image on a Mac (so I can unbreak the SqueakTrunk-OSX job, which _used_ to work). How? Do I say "-headless"? ("could not find module vm-display-X11") "-vm-display-null -headless"? ("squeak: could not find any sound driver") "-vm-sound-null -vm-display-null -headless"? ("could not find module vm-sound-null") I don't mind whether I use Cog or Interpreter, as long as I can just get an image running tests. Thanks! frank

8 11

Breaking up ToolBuilder
by Frank Shearar 17 Feb '16

17 Feb '16

I noticed this morning that every package that uses ToolBuilder has a transitive dependency on both Morphic and MVC (in the form of the ST80 package). This is caused by MorphicToolBuilder and MVCToolBuilder. I suggest either rename 'ToolBuilder-Morphic' to 'Morphic-ToolBuilder' and 'ToolBuilder-MVC' to 'ST80-ToolBuilder' (or'MVC-ToolBuilder'). This would move Morphic-specific stuff where it belongs, and ditto for MVC. frank

7 13

Environments update
by Colin Putney 25 Nov '15

25 Nov '15

Hi all, So I've been plugging away at Environments, and have a new implementation that supports renaming, but I wanted to get some feedback before figuring out the sequence of commits necessary to update the trunk safely. The idea is to support this kind of scenario: seaside := (Environment named: #Seaside) import: Smalltalk globals; importSelf; exportSelf; yourself. magma := (Environment named: #Magma) import: Smalltalk globals; importSelf; exportSelf; yourself. app := (Environment named: #AwesomeApp) import: Smalltalk globals; import: seaside; from: seaside import: {#Session -> #SeasideSession}; import: magma; from: magma import: {#Session -> #MagmaSession}; importSelf; exportSelf; yourself. In order to have the decompiled code use the correct names, I've changed the way lookup works. Instead of moving bindings from one environment to another, we now create a separate set of bindings for each environment, and copy the values (i.e., classes and globals) into a new binding when a binding is imported. I had originally thought to use something like #changed:/#update: to keep all the bindings in sync, but then I realized that ClassBuilder does a #becomeForward: updates a class. So it's really only globals that could become out of sync between environments. Since we have very few globals in the image, and they basically never change, an update mechanism may not be necessary in practice. So, here are some possible ways to proceed: 1. Use #changed:/#update: or something similar to keep keep global variables in sync. 2. Idea from Eliot—adopt the same convention as VW, and send #value to the binding on every access. Then we could have a special Alias bindings that forward the #value message to the original binding. 3. Share bindings for global variables between environments and disallow renaming of globals. 4. Special case the traditional globals such as Transcript and Display, and disallow the creation of new globals. Anyhow, I'd appreciate a code review from anybody who's interested in this stuff. To take a look, file the attached (hand edited) change set into an updated trunk image. Thanks, Colin

6 21

Re: [squeak-dev] Ometa vs XTreams PEG, PetitParser, Helvetia
by Hannes Hirzel 08 Apr '15

08 Apr '15

On 3/30/11, Nikolay Suslov <nsuslovi(a)gmail.com> wrote: > >From conceptual and practical point of view, > OMeta - is not yet another "system tool" written for Squeak or another fork, > in contrary to XTreams (a generalized stream/iterator framework written in > Smalltalk) burned in Pharo. OMeta is a language which allows to simplify an > existed tools in it's hosted language (Squeak, Pharo, JavaScript, etc) where > it is implemented, while not porting, learning and using another ones, like > XTreams. So, redefined tools with OMeta could become really portable and > mobile, ready for using in any other fork, even in another language, like > JavaScript. > > Regards, > Nikolay XTreams is primarily a generalized stream/iterator framework. It contains PEG parser generation facilities, which I assume might use XTreams. If not the PEG parser stuff could be separated. Nikolay, what you write is interesting but too terse for me to understand. If I understand you right you mean that OMeta goes beyond the PEG parser in XTreams and PetitParser (L. Renggli) and Helvetia (L Renggli). In which ways does OMeta go beyond these other tools? AND: Of course very welcome that you run for the board. --Hannes

8 11

Shrinking
by Colin Putney 19 Oct '14

19 Oct '14

Hi folks, What's the state of the art in shrinking these days? I'm starting a new web project with Squeak, and I want to create a smallish base image that I can use to build up images for development and deployment. It doesn't have to be absolutely minimal, just unloading unnecessary code and cleaning up the registries, clearing caches etc would fine. I tried "Smalltalk shrinkAndCleanDesktop", but it complains about obsolete behaviours still being present, so I guess there's some bit rot there. Suggestions? Colin

10 24

Phexample: API Change Proposal
by Sean P. DeNigris 25 Sep '14

25 Sep '14

I brought this up on Pharo Dev (http://forum.world.st/Phexample-API-Change-Proposal-was-Phexample-Image-Des…) and wanted to re-post here before committing my fix, since I assume that Squeak and Pharo make up the Phexample user base... MAJOR API CHANGE: - change matcher #= to #equal: e.g. "1 should = 1" would now be written "1 should equal: 1" - update all code to use new API Motivation: the #= magic made it impossible to store matchers in dictionaries, and #hash was implemented to signal an error explaining as much. Unfortunately, #= and #hash are deeply ingrained Smalltalk concepts, and are assumed to work as expected. In Pharo 3.0, the debugger tried to put matchers in a dictionary, causing an infinite error loop whenever a matcher failed. Let me know if you have any suggestions/objections/whatever. Sean ----- Cheers, Sean -- View this message in context: http://forum.world.st/Phexample-API-Change-Proposal-tp4759586.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

2 2

What's up on build.squeak.org
by Nicolas Cellier 27 Aug '14

27 Aug '14

Hi, it seems that most of the builds are red for 2 months. I checked the last artefact for squeak trunk: http://build.squeak.org/job/SqueakTrunk/853/ It's still blocked with the [Warning signal: 'About to serialize an empty package.'] With this warning, a test never time out (I don't know why exactly, but it seems that theProcess monitored by the timeout watchdog is already suspended by the Warning) As a result, the tests do never complete and are aborted after 20 minutes... Chris has fixed the problem since, but it seems that the CI does not upload latest trunk. Why? It seems to be the same problem as the TestRunner: updating triggers the same [Warning signal: 'About to serialize an empty package.'] Ah Chris, it's irony that it's you who precisely keep on fighting modal UI ;) Now the question: how do we escape from this situation? Shall I cheat and modify the update that is blocking?

14 53

Intent to upgrade box4 VM from VMr.2776 to VM.r2987
by Chris Cunnington 03 Jul '14

03 Jul '14

I intend to upgrade the VM on box4 VM.r2776 (Aug. 2013) to VM.r2987 (June 2014). The intention here is to refine the install/removal process. I just did this on my Debian Wheezy box, so it seems pretty straightforward. Installing: - get a Cog binary from mirandabanda.org - use Ken's cogdeb.zip to make a deb - install with dpkg (i.e. dpkg -i cogvm_2776-1_i386.deb) - execute "man squeak" to see if it's loaded Removing: - check the package name with dpkg-query -l - see it's actually called "coglinux" as opposed to cogvm or squeak - dpkg -r coglinux So, as I said, I just did this on my server and is seemed to work OK. I plan to upgrade the VM from last year's model (2776) to this year's (2987). If there's anything people with more LInux experience could add to this process, I'd be happy to hear it. Chris

5 12

Re: [squeak-dev] The Inbox: Morphic-cmm.728.mcz
by Chris Muller 01 Jul '14

01 Jul '14

TSTTCPW but I think we should revisit #flash again because sometimes it's so fast I barely saw it. I'll try this unconditional flash for a few days, make sure it won't become, ahem, annoying, before trunking it.. ;-) On Mon, Jun 30, 2014 at 12:23 PM, <commits(a)source.squeak.org> wrote: > Chris Muller uploaded a new version of Morphic to project The Inbox: > http://source.squeak.org/inbox/Morphic-cmm.728.mcz > > ==================== Summary ==================== > > Name: Morphic-cmm.728 > Author: cmm > Time: 30 June 2014, 12:23:11.962 pm > UUID: 09c9997d-d2e2-4e71-9077-c768f21a0071 > Ancestors: Morphic-dtl.727 > > - If the Reuse Windows preference is set, and an existing window on the > desktop qualifies as reusable for a request, #flash it after activating it > to ensure the user's attention will be guided to its on-screen location. > > =============== Diff against Morphic-dtl.727 =============== > > Item was changed: > ----- Method: SystemWindow>>openInWorld:extent: (in category > 'open/close') ----- > openInWorld: aWorld extent: extent > "This msg and its callees result in the window being > activeOnlyOnTop" > ^ self anyOpenWindowLikeMe > ifEmpty: > [ self > position: (RealEstateAgent > initialFrameFor: self initialExtent: extent world: aWorld) topLeft ; > extent: extent. > self openAsIsIn: aWorld ] > ifNotEmptyDo: > [ : windows | > windows anyOne > expand ; > activate ; > + postAcceptBrowseFor: self ; > + flash ]! > - postAcceptBrowseFor: self ]! > > >

7 11

Is there a preference for this?
by David T. Lewis 30 Jun '14

30 Jun '14

In my updated trunk image, if I inspect something that already has an open inspector, that open inspector gets the focus and no new inspector is opened. I'm guessing that someone set a preference for this and maybe I missed the announcement. Is there some way I can make this improvement go away? I can't see anything obvious in the preference browser. Thanks, Dave

6 13

Jump to page: