Squeak-dev September 2014

squeak-dev@lists.squeakfoundation.org

49 participants
162 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

trunk update broken cuz there's an empty diffy version
by Eliot Miranda 24 Apr '16

24 Apr '16

Hi Guys, source.squeak.org/trunk's Morphic-eem.740(cmm.739).mcd is empty. How do we fix it? On a related note is there any way to get the updater to download full packages, avoiding the diffy versions? e.g a preference? -- best, Eliot

6 12

deselection broken in method list
by Eliot Miranda 17 Apr '16

17 Apr '16

Hi All, I depend heavily on fileOutAll in method list browsers. For example, I'm trying to create versions of the VM's boolean cheat code for the Sista bytecode set and do this by filing out the code for the Newspeak set and editing it. I tried to do this using "self systemNavigation browseAllSelect: [:m| ('*ooleanCheat*V*' match: m selector) or: [m sendsSelector: #booleanCheatV4:]]" to get a method list browser. Then I was expecting to be able to use file out with nothing in the list selected. This files out all methods in the list but... Deselection is broken! I can't deselect the first item and hence can only file out a single definition . Will whoever changed this please restore it asap? (in trunk) -- Mahalo, Eliot

7 16

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

It's not yet clear how serialization should work in the presence of environments
by David T. Lewis 30 Nov '15

30 Nov '15

Currently we have: Binding>>objectForDataStream: refStream "It's not yet clear how serialization should work in the presence of environments" self shouldBeImplemented. This prevents us from being able to save projects to local disk in Squeak trunk. See Mantis entry at: http://bugs.squeak.org/view.php?id=7814 Any thoughts as to how this should be implemented? Taking the method comment literally, I would expect that serialization in the presence of environments should work identically to serialization in the absence of environments, at least as a default behavior. I suspect that is not hard to make this happen, but I don't know how to do it. Dave

5 6

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

Maintainer of FFI-Package
by Nicolai Hess 12 Sep '15

12 Sep '15

Who is the maintainer of the FFI-Package for Squeak and/or Pharo ? I especially interested in the FFI-Unix examples and the state on working FFI on linux for current squeak release (AFAIK it does not work with "squeak all in one" 4.5) regards Nicolai

4 9

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 20 Oct '14

20 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

Re: VanIsle CampSmalltalk 3rd - 5th October 2014
by Boris Shingarov 12 Oct '14

12 Oct '14

Count me in, too! Talk title: "Reviving Cheese" Abstract/Background: Cheese was a Squeak with Native Widgets which I made in 1997/98. There were two major varieties. Cheese4's peculiar feature was dual UI message loop: it started from Squeak 1.30 X11 port on OS/2 (EMX), added an FFI and used that FFI to implement a native OS/2 Presentation Manager UI, all the while keeping the X11 UI for development. The X11 message loop and the PM/2 message loop ran at the same time. When Cheese gained enough native-based tools to self-host development, Cheese5 cut off X11 support in the VM and the BitBlt-based half of the image; so it's just a native OS/2 application. These experiments later inspired my work on SWT. At ESUG-2014 in Cambridge, a number of people asked me where to get a copy of Cheese. So I thought it worthwhile to shake the dust off that 16-year old archive, fire up a VirtualBox VM with OS/2, and bring Cheese to VanIsle CampSmalltalk.

2 2

Jump to page: