Squeak-dev September 2014

squeak-dev@lists.squeakfoundation.org

49 participants
162 discussions

startup time command line (or dropped files) arguments
by tim Rowledge 02 Oct '14

02 Oct '14

How are command line arguments intended for the image supposed to be dealt with these days? It’s an awfully long time since last I looked at this area and the code I’m seeing in the image is… convoluted. I need to be able to handle some simple cases for Scratch startup and we seem to have completely changed how that area is handled. I have come across (and reeled in horror) code in ProjectLauncher, AutoStart etc but so far I don’t see anything to make it all make sense in my head. I don’t suppose anybody knows of a correct wiki page? Not found one so far. Maybe I need to drop one or more of the current startup related classes and write a ScratchStart class? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Programmer: One who is too lacking in people skills to be a software engineer.

5 9

Re: [Newbies] Running Squeak on Mac OS X fails due to damaged file.
by Tobias Pape 01 Oct '14

01 Oct '14

Hi, On 29.09.2014, at 17:59, Chris Muller <asqueaker(a)gmail.com> wrote: > On Fri, Sep 26, 2014 at 5:59 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: >> [cc squeak-dev] >> >> I'm puzzled. >> I though the All-In-One was signed and should not be reported as damaged? > > It was signed back in May when we released, but just a couple of weeks > ago, recall we discovered that issue with the ".ini" file used by the > Windows VM where the 3ButtonMouse setting wasn't set. > > So, I set it, stuffed it back into the All-In-One zip, re-uploaded it, > and asked someone to verify Mac. > > Someone did and it was fine. > > So maybe this is not the problem...? Or should it be checked again? Probably Craig can do that. Craig? Best -tobias

4 5

New Cog VMs available
by Eliot Miranda 30 Sep '14

30 Sep '14

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3085/. CogVM binaries as per VMMaker.oscog-eem.887/r3085 Spur: Change become to flush method caches for becommed classes. Changes are to - add a BecameActiveClassFlag to becomeEffectsFlags - refuse to do an in-place become on active classes. - flush the caches before the post-become scan of the class table so that forwarded classes can be spotted. i.e. if a class index in a method cache is that of a forwarded class then it was becommed and the cache entry can be voided. Fix bug in sweepToFollowForwardersForPigCompact which failed to update and answer lowest forwarder. Fixes numForwarders == 0 assert failures. Fix bug with become and class table not removing classes which become causes them to be unhashed. Fix bogus assert fail in synchronousSignal:. Refactor following code into ensureSemaphoreForwardedThroughContext: and fix the assert there-in. Use rawOverflowSlotsOf: in bytesInObject:. Cogit: Make sure voidImplicitReceiverCacheAt: sets codeModified if IRCs are inline. Make sure freeMethod: clears cmRefersToYoung Fix assert in cogitPostGCAction: that would fire erroneously in Spur become. Fix regression in V3 become youngReferrers management in VMMaker.oscog-eem.882. We /must/ prune young referrers if mapObjectReferencesInMachineCodeForBecome removes a cog method from youngReferrers because it may get added back and youngReferrers cannot contain duplicates. Fix potential bug in Spur become argument validation. Check for immediates needs to come /after/ following forwarders since an object can become-forward to an immediate. Fix cPICHasForwardedClass:; this did /not/ enumerate the classIndices in a Spur Closed PIC. Install the callPrimitiveBytecode in the Interpreter's bytecodeDispatchTable on Spur. Modify callPrimitiveBytecode to not invoke unknownBytecode processing if at the first bytecode of a primitive method. Correct sign comparison of instructionPointer in justActivateNewMethod. Relax the validInstructionPointer:inMethod:framePointer: assert to accept any pc in initialPC to self size range now that callPrimitiveBytecode is more forgiving. Speed up primitiveMarkUnwindMethod & primitiveMarkHandlerMethod in the StackInterpreter by setting them to 0 in the primitive table. -- best, Eliot

2 1

Re: [squeak-dev] The Trunk: Kernel-eem.876.mcz
by Nicolas Cellier 30 Sep '14

30 Sep '14

So generally, all tempAt: accesses should be protected? 2014-09-29 23:22 GMT+02:00 <commits(a)source.squeak.org>: > Eliot Miranda uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-eem.876.mcz > > ==================== Summary ==================== > > Name: Kernel-eem.876 > Author: eem > Time: 29 September 2014, 2:21:45.514 pm > UUID: 9ea5bea7-14c9-48c9-9d49-ca311d68d49a > Ancestors: Kernel-ul.875 > > Fix handleSignal: for a rare edge case that can > occur on Stack & Cog VMs. > > =============== Diff against Kernel-ul.875 =============== > > Item was changed: > ----- Method: ContextPart>>handleSignal: (in category > 'private-exceptions') ----- > handleSignal: exception > + "Sent to handler (on:do:) contexts only. If my exception class > (first arg) handles exception > + and the handler is active then execute my handle block (second > arg), otherwise forward > + this message to the next handler context. If none left, execute > exception's defaultAction > + (see nil>>handleSignal:)." > - "Sent to handler (on:do:) contexts only. If my exception class > (first arg) handles exception then execute my handle block (second arg), > otherwise forward this message to the next handler context. If none left, > execute exception's defaultAction (see nil>>handleSignal:)." > > + | handlerActive val | > + "If the context has been returned from the handlerActive temp var > may not be accessible." > + handlerActive := stackp >= 3 and: [(self tempAt: 3) == true]. > + (((self tempAt: 1) handles: exception) and: [handlerActive]) > ifFalse: > + [^self nextHandlerContext handleSignal: exception]. > - | val | > - (((self tempAt: 1) handles: exception) and: [self tempAt: 3]) > ifFalse: [ > - ^ self nextHandlerContext handleSignal: exception]. > > exception privHandlerContext: self contextTag. > self tempAt: 3 put: false. "disable self while executing handle > block" > + val := [(self tempAt: 2) cull: exception] > + ensure: [self tempAt: 3 put: true]. > + self return: val "return from self if not otherwise directed in > handle block" > - val := [(self tempAt: 2) cull: exception ] > - ensure: [self tempAt: 3 put: true]. > - self return: val. "return from self if not otherwise directed in > handle block" > ! > > >

2 1

Daily Commit Log
by commits＠source.squeak.org 30 Sep '14

30 Sep '14

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2014-September/007304.… Name: Kernel-eem.876 Ancestors: Kernel-ul.875 Fix handleSignal: for a rare edge case that can occur on Stack & Cog VMs. =============================================

1 0

Request for adding Smalltalk syntax highlight in SE network
by Hernán Morales Durand 30 Sep '14

30 Sep '14

I have requested for some justice to stop the look down on Smalltalk syntax highlighting in StackOverflow: http://meta.stackoverflow.com/questions/272327/syntax-highlighting-for-smal… Maybe more votes (from you) would better support the request. Cheers, Hernán

3 2

The Trunk: Kernel-eem.876.mcz
by commits＠source.squeak.org 29 Sep '14

29 Sep '14

Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.876.mcz ==================== Summary ==================== Name: Kernel-eem.876 Author: eem Time: 29 September 2014, 2:21:45.514 pm UUID: 9ea5bea7-14c9-48c9-9d49-ca311d68d49a Ancestors: Kernel-ul.875 Fix handleSignal: for a rare edge case that can occur on Stack & Cog VMs. =============== Diff against Kernel-ul.875 =============== Item was changed: ----- Method: ContextPart>>handleSignal: (in category 'private-exceptions') ----- handleSignal: exception + "Sent to handler (on:do:) contexts only. If my exception class (first arg) handles exception + and the handler is active then execute my handle block (second arg), otherwise forward + this message to the next handler context. If none left, execute exception's defaultAction + (see nil>>handleSignal:)." - "Sent to handler (on:do:) contexts only. If my exception class (first arg) handles exception then execute my handle block (second arg), otherwise forward this message to the next handler context. If none left, execute exception's defaultAction (see nil>>handleSignal:)." + | handlerActive val | + "If the context has been returned from the handlerActive temp var may not be accessible." + handlerActive := stackp >= 3 and: [(self tempAt: 3) == true]. + (((self tempAt: 1) handles: exception) and: [handlerActive]) ifFalse: + [^self nextHandlerContext handleSignal: exception]. - | val | - (((self tempAt: 1) handles: exception) and: [self tempAt: 3]) ifFalse: [ - ^ self nextHandlerContext handleSignal: exception]. exception privHandlerContext: self contextTag. self tempAt: 3 put: false. "disable self while executing handle block" + val := [(self tempAt: 2) cull: exception] + ensure: [self tempAt: 3 put: true]. + self return: val "return from self if not otherwise directed in handle block" - val := [(self tempAt: 2) cull: exception ] - ensure: [self tempAt: 3 put: true]. - self return: val. "return from self if not otherwise directed in handle block" !

1 0

New Cog VMs available
by Eliot Miranda 29 Sep '14

29 Sep '14

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3083 CogVM source as per VMMaker.oscog-eem.886/r3083 Fix regression in V3 become youngReferrers management in VMMaker.oscog-eem.882. We /must/ prune young referrers if mapObjectReferencesInMachineCodeForBecome removes a cog method from youngReferrers because it may get added back and youngReferrers cannot contain duplicates. Spur: Fix bug in sweepToFollowForwardersForPigCompact which failed to update and answer lowest forwarder. Fixes numForwarders == 0 assert failures. Fix bug with become and class table not removing classes which become causes them to be unhashed. Fix bogus assert fail in synchronousSignal:. Refactor following code into ensureSemaphoreForwardedThroughContext: and fix the assert there-in. Use rawOverflowSlotsOf: in bytesInObject:. Make a little more progress on Spur image segment support. Provide a classTableEntriesDo: and use it to compute an arrayOfUnmarkedClasses. Cogit: Make sure voidImplicitReceiverCacheAt: sets codeModified if IRCs are inline. Make sure freeMethod: clears cmRefersToYoung Fix assert in cogitPostGCAction: that would fire erroneously in Spur become. Move evaluation of Cogit primitive desacriptor enabled function from initialization to just-in-time, and add enablers on SmallInteger primitives to ensure they are applied only to SmallInteger receivers (falling back to interpreter prims if not). Hence fix Cog for 4.1 (e.g. MuO) images. Back out of saneMethodClassAssociation assert in initialPCForHeader:method:. Newspeak falls foul of this. Make sure that the method is set on returning from a callback. Fixes MNUs of atAddress: in exampleCqsort in the stack VMs. Fix bugs in scripts and Windows manifests. -- best, Eliot

2 2

Contributor agreement
by Louis LaBrunda 29 Sep '14

29 Sep '14

Hi Jecel, Thanks for the history and all your efforts. Lou On Tue, 23 Sep 2014 19:56:16 -0300, "Jecel Assumpcao Jr." <jecel(a)merlintec.com> wrote: >David T. Lewis wrote on Mon, 22 Sep 2014 20:54:13 -0400 >> The signed contributor agreement was a part of the process of establishing >> the current Squeak licensing. I signed one of them myself, as did everyone >> else who was known to have contributed anything (large or small) to the >> image up to that point. > >Just to add a bit to the history of the licensing issues for those who >have joined us more recently: > >After being developed as an internal and mostly secret project at Xerox >PARC for a decade, the company decided to release Smalltalk to the world >in the early 1980s (thanks mostly to the efforts of Adele Goldberg and >friends). Xerox got in touch with several other companies and made a >deal with Apple, Tektronix, HP and DEC to give them a license to the >Smalltalk technology that would allow them to do absolutely anything >they wanted with it for free in exchange for them dedicating engineering >resources to help with the process of converting a research project into >a product. > >Later on a fifth license was granted to Berkeley but I don't know if the >terms were the same. Tektronix created some "artificial intelligence" >workstations around Smalltalk (the 4404 and 4406). They also used >Smalltalk in their oscilloscopes, but I am not sure if this also came >from Xerox. HP and DEC are now the same company and didn't do anything >with it, though later HP had a Distributed Smalltalk project. > >Apple did a limited release of Lisa Smalltalk to developers and this >later ran on Macintosh machines as well when these got enough memory. It >was never available to the general public. When the Squeak project was >started in 1996/1997 this code was the starting point and the Xerox >license meant that Apple could relicense it under any terms it wanted. >Since the Squeak group was moving from Apple to Disney, getting Apple to >do its very first Free Software license was key to not having to start >from scratch. The new SqueakL (as the license became known) tried to >strike a balance between the advantages of the BSD/MIT commercial >friendliness (so Disney could build products on top of Squeak and >distribute them without giving away the source) and the GPL forced >contributions to the common good. Which terms applied depended on >whether a method was considered a part of the kernel or if it was an >extension, which is a rather subjective thing in a monolithic image. > >The following year the term Open Source was invented and defined in a >way that the SqueakL didn't quite fit. This caused a lot of anguish and >yearly discussions about possible relicensing (always in the Spring, >though since it is nearly Spring where I am this thread could be >considered timely). Oddly enough the halfway MIT half GPL aspect never >bothered anybody. The complaints were about the terms for one of the >fonts (which was soon eliminated from the image anyway), about export >restrictions (which US laws impose even on licenses that don't mention >them) and the promise to help Apple in any lawsuit they got into due to >your distributing Squeak. > >Things became critical in 2006 when people in the One Laptop Per Child >project threatened to reject Squeak due to the license. Alan Kay called >Steve Jobs personally and got Apple to re-release Squeak 1.1 under the >Apple Community license, as allowed by their Xerox PARC license. The >OLPC people were not happy with that, and Alan got Jobs to release >Squeak 1.1 a third time under the Apache version 2 license. Then the >people at VPRI (Alan's research institute) started the effort to get >everybody who had ever added code after Squeak 1.1 to sign an agreement >to relicense their part from SqueakL to MIT. The focus was on Etoys, so >the Pharo guys extended this effort to the code in their system which >wasn't a part of Etoys. After that the Squeak Board started from the >Pharo effort and covered the whole Squeak code (my contribution was >checking everything that was done in early versions before we had >programmer initials). > >One additional detail is that when Ian Piumarta ported the Squeak VM to >Unix he selected to the GPL for his contributions. Since this is C code >and very isolated from the rest of the system nobody has ever had a >problem with that. But it does mean that the whole Squeak system is >available in 3 different licenses: parts under the GPL, parts under >Apache version 2 and everything else under MIT. Our policy is that all >future contributions have to be MIT, so the tiny parts under the two >other licenses will never grow. The simplification that "Squeak is >available under the MIT license" is good enough for nearly all purposes, >but some people are picky so I thought it would be a good idea to bore >you all with these details. > >-- Jecel > > ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com

7 11

RE: Status of PostgresV3
by Stephan Eggermont 28 Sep '14

28 Sep '14

Hi Balázs, Thanks for the clear and extensive response. I'll take a look at the new packages and see how far I get. So if I understand it correctly, your code is more tightly coupled to the PostgreSQL database, can get to better performance by heavy reliance on stored procedures, and gives up some abstraction to get there? And of course there are the results of using v3 vs v2 and non-blocking calls to the database? Cheers, Stephan

1 0

Jump to page: