Squeak-dev January 2013

squeak-dev@lists.squeakfoundation.org

105 participants
332 discussions

AndreasSystemProfiler Released MIT
by Ron Teitelbaum 09 Feb '13

09 Feb '13

Hello All, In Memory of Andreas Raab http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html We have renamed and released the AndreasSystemProfiler. http://ss3.gemstone.com/ss/AndreasSystemProfiler.html Using the MIT License. Thank you Eliot for your help to get this ready. The profiler works with Squeak 4.4. All the best, Ron Teitelbaum, Julie LeMoine and David Smith > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev- > bounces(a)lists.squeakfoundation.org] On Behalf Of Andreas.Raab > Sent: Friday, January 11, 2013 1:39 PM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] Re: Profiling > > Levente Uzonyi-2 wrote > > It uses some primitives which were added to the CogVM, so it requires Cog. > > We could reimplement it from scratch using the same primitives and get > > a better profiler in the image. We can't include this due to the GPL > > license. > > Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and > Software) can re-release the code under a more permissable license. > > Cheers, > - Andreas > > > > > -- > View this message in context: http://forum.world.st/Profiling- > tp4662704p4662987.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. >

14 28

Re: [squeak-dev] The Inbox: Kernel-fbs.736.mcz
by Frank Shearar 06 Feb '13

06 Feb '13

On 30 January 2013 20:04, <commits(a)source.squeak.org> wrote: > Frank Shearar uploaded a new version of Kernel to project The Inbox: > http://source.squeak.org/inbox/Kernel-fbs.736.mcz > > ==================== Summary ==================== > > Name: Kernel-fbs.736 > Author: fbs > Time: 30 January 2013, 8:04:08.926 pm > UUID: 1d99c937-4c68-475c-987b-2990c8040c29 > Ancestors: Kernel-fbs.735 > > Rename NotImplemented errors in line with conventions 2 of 3. > > =============== Diff against Kernel-fbs.735 =============== If folks are happy with what I've got, I'd like to make one more change, and remove NotYetImplemented>>#defaultAction. This will make this message send open up a Debugger. Then I just need to tweak the Debugger to show the Create button. If people think that's sensible I'll make the change and resubmit, clearing out obsolete Inbox ancestors to show a more complete diff. frank

3 6

Re: [squeak-dev] The Inbox: Kernel-fbs.735.mcz
by Frank Shearar 06 Feb '13

06 Feb '13

On 30 January 2013 18:33, <commits(a)source.squeak.org> wrote: > Frank Shearar uploaded a new version of Kernel to project The Inbox: > http://source.squeak.org/inbox/Kernel-fbs.735.mcz > > ==================== Summary ==================== > > Name: Kernel-fbs.735 > Author: fbs > Time: 30 January 2013, 6:33:47.078 pm > UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc > Ancestors: Kernel-fbs.734 > > Actually, return a Message, and find out the receiver of the Message from the signalercontext. > > Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method. > > =============== Diff against Kernel-fbs.734 =============== > > Item was added: > + ----- Method: ContextPart>>asMessage (in category 'converting') ----- > + asMessage > + | sender selector args | > + sender := self sender. > + selector := sender method selector. > + args := Array new: selector numArgs. > + 1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)]. > + ^ Message selector: selector arguments: args.! > > Item was removed: > - ----- Method: ContextPart>>asMessageSend (in category 'converting') ----- > - asMessageSend > - | sender selector args | > - sender := self sender. > - selector := sender method selector. > - args := Array new: selector numArgs. > - 1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)]. > - ^ MessageSend receiver: self receiver selector: selector arguments: args.! <snip> Diffs serve as a helper for reviewers. To that end, the diffs ought to actually show what changes would be applied to trunk should the change be accepted. This diff, for instance, shows the removal of #asMessageSend and the addition of #asMessage, but really the change applied to trunk will be just the addition of #asMessage. In other words when something undergoes a few rounds of review (and I'd think this should be the _norm_) the reviewer must reconstruct a series of diffs to get an idea of how trunk will change. Wouldn't it be better to diff against trunk rather than against the mcz's ancestor? (*) frank (*) This is actually how github's pull requests work: you _can_ see the commit history, but you also have a straight "this is what will change" view, which is where I normally look.

4 12

I'm running
by Eliot Miranda 04 Feb '13

04 Feb '13

Hi All, I've decided to run for the board. Electioneering to follow. -- best, Eliot

7 9

RaspberryPi RISC OS Squeak now has actual sound output
by tim Rowledge 01 Feb '13

01 Feb '13

I'm sure it seems like a small thing but it's taken me 18 years to get a round tuit and make this stuff work. I haven't got the semaphore signalling version working yet but I can play a Bach fugue for coffee-cup without anything falling over. Playing multi-track midi files seems a bit more of a problem right now and I'm trying to work out WTF is causing that. But Yay! Sounds! tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Make it right before you make it faster.

6 11

Re: Cross-classified methods
by Stephan Eggermont 01 Feb '13

01 Feb '13

Hmm, it was not clear in which direction this works. I switched them for http://code.google.com/p/pharo/issues/detail?id=7379 Thanks for noting, Sean. So: the first set are methods where Squeak has no classification, and Pharo does. The second set has methods where Pharo has no classifications, and Squeak does. Stephan

2 1

last call for items to mention in the "State of Squeak" talk at FOSDEM 2013
by Craig Latta 01 Feb '13

01 Feb '13

Hi all-- I'll be giving an overview of the state of the Squeak project on at the FOSDEM conference in Brussels on Sunday. Please let me know of anything you'd like to mention! Or rather, since time is short, please let us all know, by using this thread. thanks again! -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

6 7

Please VOTE!!
by Ron Teitelbaum 01 Feb '13

01 Feb '13

Hi All, So far we have 98 votes! That's 21 votes less than last election. I know we can do better than that. Please take the time to find your ballot and vote. If you need the ballot sent to you again, no problem just let me know at voters(a)squeak.org. Friday 8th of February 2013 6PM (23:00 UTC): Online election ends. The Squeak Oversight Board election ballots have gone out. Please VOTE!! It's easy to forget or lose track of the email, so please vote while you still know where the email is! The subject is: Poll: Squeak Oversight Board 2013 Sent on 28th of Jan between 5 and 6pm Eastern Time. From: andru(a)cs.cornell.edu; on behalf of; Ron Teitelbaum (CIVS poll supervisor) ron(a)usmedrec.com For more information about the election see this page: http://wiki.squeak.org/squeak/6191 Thank you!! Ron Teitelbaum

9 9

new Cog VMs available
by Eliot Miranda 31 Jan '13

31 Jan '13

...at http://www.mirandabanda.org/files/Cog/VM/VM.r2677/. CogVM binaries as per VMMaker.oscog-eem.261/r2677. Move determination of the ammount of headroom to the platform in osCogStackPageHeadroom (in the various sqFooMain.c files). Hence 2k stack pages on Mac and Win32 with 4k pages on linux. Provide a routine to monitor the ammount of unused headroom, which requires the stack memory be zeroed before use. Assume the platform will provide a -reportheadroom flag for enabling the report. Provide primitiveMinimumUnusedHeadroom for in-image access. -- best, Eliot

2 5

[bug 7733] Re: browsing method speed
by Vaidotas Didžbalis 31 Jan '13

31 Jan '13

http://bugs.squeak.org/view.php?id=7733 2013/1/30 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Personally I think it's important. But I want to hear form others whether > they find the hack I proposed acceptable or not. >> > On Mon, Jan 21, 2013 at 3:51 PM, tim Rowledge <tim(a)rowledge.org> wrote: >> >> >> >> >> >> On 21-01-2013, at 3:48 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> >> wrote: >> >> > >> >> > Alas it bites at a slightly higher-level than that also. Yes, the >> >> > decoupling of positioning and reading is a problem for thread-safety. >> >> > But >> >> > so is the single buffer and the single position. e.g. if one were to >> >> > call >> >> > your unified primitive below to fill the buffer that wouldn't prevent >> >> > another thread reading at a different position into the same buffer >> >> > and >> >> > trashing the contents from the POV of the first thread. Since the >> >> > programming tools are essentially single-threaded it's not *that* bad >> >> > a >> >> > problem, unless you're debugging source access (I *think*). >> >> >> >> Gotta start somewhere. Bottom is often good. Then other people can >> >> build >> >> upon that. >> > >> > >> > Sure, but can't solve the immediate problem this way because it takes >> > time >> > for a VM change to percolate through. >> > -- >> > best, >> > Eliot >> > >> > >> > > > > > > -- > best, > Eliot

1 0

Jump to page: