Squeak-dev December 2012

squeak-dev@lists.squeakfoundation.org

58 participants
216 discussions

Metacello and Squeak4.4
by Dale Henrichs 01 Mar '13

01 Mar '13

I have a small 3 class package (Metacello-Base[1]) that I would hope could be included in the Squeak4.4 release. Of the 3 classes, the Metacello class is a stub class for the Metacello Scripting Api[2], that will bootstrap Metacello _if_ you use the scripting api. I am promoting the scripting api as the cross platform way to use Metacello. Instead of seeing install scripts fly by that look like this: Gofer new package: 'ConfigurationOfSeaside30'; squeaksource: 'MetacelloRepository'; load. ((Smalltalk at: #ConfigurationOfSeaside30) version: #stable) load. (with the caveat that Installer should be used for Squeak)...the install scripts will look like this: Metacello new configuration: 'Seaside30'; version: #stable; squeaksource: 'MetacelloRepository'; load. The same script will "do the right thing" on all three supported platforms (Squeak, Pharo, GemStone), presuming that the class Metacello is present in the base images:) I've recently released a preview version[4] and am actively collecting feedback. I would think that I can finalize the visible portion of the scripting api by September... I've been ensuring that the metacello preview release is functional on Squeak all along and I am currently running CI builds against Squeak4.3 using travis ci[5]. Moving forward I would add Squeak4.4 to the list of platforms for CI and publish updates to the Metacello-Base pacakge as needed. The class comments for each of the classes provides basic documentation for using Metacello so I think that Metacello-Base is a clean and small presence for Metacello and will enable the use of "cross-platform install scripts for Metacello." Thanks, Dale [1] http://seaside.gemstone.com/ss/metacello/Metacello-Base-dkh.96.mcz [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… [4] http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-tt4642064.html [5] http://travis-ci.org/#!/dalehenrich/metacello-work/builds/2012331

9 36

New release candidate: 4.4-12324
by Frank Shearar 20 Feb '13

20 Feb '13

http://squeakci.org/job/ReleaseSqueakTrunk/lastSuccessfulBuild/artifact/tar… I'm trying to automate more and more of the build/release process. See https://github.com/frankshearar/squeak-ci/tree/download-vms for details. (I'll merge this branch back into master at some point in the near future.) frank

11 49

Cryptography - Problem with SSH client
by Guido Chari 14 Feb '13

14 Feb '13

I'm having some problems connecting to an SSH server from Squeak. The server is in my localhost and i test it with a unix ssh client with no problems. However, when i tried to connect from Squeak i received an error ("bad signature") on SSHDHGroup1KeyExchangeProcessor>>processServerDHReplyMsg:securityParams: method on the key exchange phase of the algorithm. Does anybody use the SSH client from the cryptography package? What should be the error? Cheers, Guido.

3 2

SqueakCore
by Pavel Krivanek 11 Feb '13

11 Feb '13

Hi, this is the first unkempt attempt to produce SqueakCore image from Squeak4.4-12324. It generates 3 MB dirty image (3.2 with Unicode tables). Some overrides have only logging purpose. Cheers, -- Pavel

4 10

[Cuis] [Ann] Cuis 4.1 is released
by Juan Vuletich (mail lists) 11 Feb '13

11 Feb '13

Hi Folks, Cuis 4.1 is available at http://www.jvuletich.org/Cuis/Index.html . Biggest news is in the Morph hierarchy. Ivars 'bounds' and 'fullBounds' are gone! All coordinates are now Float and relative to the owner morph. This is part of the transition to Morphic 3. The drawing engine is still BitBlt and the UI is not scalable yet, but Morphic 3 is now much closer. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list Cuis(a)jvuletich.org http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

13 17

Calendar Chooser
by Jon Hylands 25 Jan '13

25 Jan '13

Hi everyone, So, I'm working on an application for managing my projects and timesheets and such, and one of the things I really wanted was a decent Calendar chooser. I looked around and didn't see one, so I spent a few hours and made what I think is a nice one... Its a single morph class, with one support class. I've attached a screenshot. I have no idea how widgets like this are typically included - either as some kind of add-on, or included with the base image. Thoughts? - Jon

6 16

Re: [squeak-dev] The Inbox: Collections-topa.366.mcz
by Tobias Pape 22 Jan '13

22 Jan '13

Hi, this little method may save some time if you need to generate readable method selectors frequently. Any objections against trunk inclusion? So Long, -Tobias Am 2010-06-16 um 13:34 schrieb commits(a)source.squeak.org: > > ==================== Summary ==================== > > Name: Collections-topa.366 > Author: topa > Time: 16 June 2010, 3:34:47.932 pm > UUID: 5491e7f9-bcc4-423a-a267-8853ca2eb9a3 > Ancestors: Collections-ul.365 > > Provide #asCamelCase for Strings. > May be usefull for natural language conversation or the like. >

6 10

RISC OS Pi in the workshop
by Chris Cunnington 09 Jan '13

09 Jan '13

http://osrcon.ca/pie.jpeg First pic of the first boot of the RISC OS Pi in Tim's workshop. Chris

3 9

Re: [Newbies] Two questions about Smalltalk language design
by Yoshiki Ohshima 04 Jan '13

04 Jan '13

On Sun, Dec 30, 2012 at 7:40 AM, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > On 2012-12-27, at 01:32, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > >> Why do ST methods return "self" if nothing is explicitly returned? > > > One very simple reason has not been stated yet: In the Virtual Machine, returning self is simpler and more efficient than returning any other object. > > Smalltalk byte codes implement a stack machine. That means arguments are passed by pushing them onto a stack, rather than putting them into registers. In addition to the arguments as listed in the method signature, a hidden argument is always passed, which is the receiver of the message. So even for unary methods (those without arguments) the receiver is pushed onto the stack, then the method is executed, and the receiver value on the stack is how the method knows "self". By returning "self" if no explicit return statement is given, the VM can just leave the "self" oop on the stack, which saves at least one memory store operation. So from an efficiency and simplicity standpoint, returning "self" is the most elegant thing to do. I thought of it (when I wrote the reply) but isn't this really the argument for returning self instead of nil for example? Any message send pops all arguments including the receiver and pushes the return value so "self" is not on the stack. Typical byte code sequence for a method that returns self is popping the last result and ends the sequence with "returnSelf"; so it should be equally efficient if such a method endsWIth "returnNil", if such bytecode exists? -- -- Yoshiki

9 12

Re: [squeak-dev] The Trunk: ReleaseBuilder-fbs.89.mcz
by Frank Shearar 02 Jan '13

02 Jan '13

On 31 December 2012 20:46, <commits(a)source.squeak.org> wrote: > Frank Shearar uploaded a new version of ReleaseBuilder to project The Trunk: > http://source.squeak.org/trunk/ReleaseBuilder-fbs.89.mcz > > ==================== Summary ==================== > > Name: ReleaseBuilder-fbs.89 > Author: fbs > Time: 31 December 2012, 8:46:19.365 pm > UUID: a99900e3-d3c9-4284-afb5-89c046ddc44d > Ancestors: ReleaseBuilder-fbs.88 > > Transferring packages to the new update stream requires valid credentials. This lets the release manager transfer things without changing source, and without storing credentials in the image. Consider this the first commit on the 4.5 stream! frank

2 3

Jump to page: