Squeak-dev August 2010

squeak-dev@lists.squeakfoundation.org

100 participants
325 discussions

[Documentation] What about package comments?
by Hannes Hirzel 13 Sep '10

13 Sep '10

Hello I found the proposal by Bernhard Pieber and Ralph Johnson to introduce package comments? It was in the thread HttpView2 where I think some people interested in documentation will miss it. An application could be to automatically generate documentation, i.e. for example at Squeaksource. --Hannes >From the HttpView2 thread On 4/23/10, Ralph Johnson <johnson(a)cs.uiuc.edu> wrote: > On Fri, Apr 23, 2010 at 5:39 AM, Bernhard Pieber <bernhard(a)pieber.com>wrote: > >> - IMHO, there should be first class package comments along the lines of >> class and method comments, i.e. version controlled in PackageInfo. This >> would greatly improve the Monticello browser. And SqueakSource could use >> them as project descriptions. (I once argued [1] that the easiest >> implementation of this would be a PackageInfo subclass for each package. >> Its >> class comment would be the package comment. Pre and post load code could >> be >> put there as well. You could reuse all the development tools like that.) >> >> [1] >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088181… >> >> > This seems like a good idea. What tools would have to change to make this > work, and could we make this change backwards compatible? For example, if > you move the preload and postload code to the PackageInfo subclass then you > could leave forwarding code behind. Tools wouldn't bother displaying the > forwarding code if they saw the PackageInfo subclass, but would keep it so > that older versions of the tools would still work. > > -Ralph >

10 19

Etoys developer chat log
by Bert Freudenberg 08 Sep '10

08 Sep '10

Hi all, almost missed the chat yesterday. And when I logged in I got distracted by #olpc-devel talk. A minute later David came back, but I didn't see that. Sorry. But: If I'm not there, that's no reason not to chat :) Anybody can lead the discussion if it gets too disorganized, but usually we're pretty civilized, so it should rarely be necessary. So here is a rule: Do not wait more than 15 minutes. Just start. I'll see it in the logs later so I can still post a summary (though it would be awesome if someone beat me to it). Anyway, next chat is next Monday, same time as always: http://tinyurl.com/3ytdm3d Hope you'll be there (and I'll try to attend too). - Bert - [21:02:37] --> Richo2 (~c9d56472(a)skylab.immuexa.com) has joined #etoys [21:05:08] --> dcorking (~dcorking(a)82.152.173.174) has joined #etoys [21:05:13] <Richo2> hi [21:06:06] <dcorking> hi Richo2 - when does the meeting start? [21:07:36] <dcorking> is storybot down again? [21:11:53] <Richo2> I think it should have started already [21:13:09] <dcorking> I have only lurked in a couple of these. bertf normally leads them doesn't he? Is randall travelling at the moment? [21:13:31] --> scottwal (~scottwal(a)99-40-5-235.lightspeed.sntcca.sbcglobal.net) has joined #etoys [21:17:00] <-- Richo2 (~c9d56472(a)skylab.immuexa.com) has quit (Quit: CGI:IRC (Ping timeout)) [21:21:13] <bertf> hi folks - sorry I'm late [21:21:26] <bertf> you could've started already ;) [21:24:59] <bertf> dcorking: storybot has been down for months, and it's unlikely to come back [21:25:12] <bertf> jecel was looking onto other logging options [21:25:19] <bertf> for now I just email the logs manually [21:26:18] <dcorking> shame: I guess a decision should be made and the link removed from http://squeakland.org/discuss/ [21:36:37] <dcorking> is the meeting starting? if not, any thoughts on jecel's idea on porting Cog VM to the XO-1? [21:38:46] <jecel> I was looking at the Cog sources to get an idea of how complex this would be. It seems doable, but not easy [21:40:05] <dcorking> hmm. Sounds like something that would distract the squeak experts from doing the next Sugar release on time, and not something for average smalltalkers. [21:40:25] <jecel> About the logging, I didn't remember we had agreed that I would check the options and so haven't yet done so [21:40:47] <dcorking> however, I wonder if qemu could be used to emulate the missing instructions: at least as a proof of concept [22:07:44] <dcorking> is the meeting over? [22:10:43] <dcorking> does the showcase still give trouble when a user uploads a new version of an existing project? [23:47:14] <-- dcorking (~dcorking(a)82.152.173.174) has quit (Quit: Leaving)

1 5

About unloading of packages in the most recent Squeak 4.1 trunk
by Hannes Hirzel 08 Sep '10

08 Sep '10

Hello Could somebody please post the code snippet which unloads all the packages in Squeak 4.1 trunk latest update which unload and reload cleanly? --Hannes

9 50

UbiquiTalk
by Sean P. DeNigris 06 Sep '10

06 Sep '10

I'm porting UbiquiTalk to Squeak 4.1 and running into a problem. I've been talking to Noury Bouraqadi about it and am posting the progress here in case anyone has any input. I'm attaching a screenshot, and can provide the images, but right now the load process is not documented. http://forum.world.st/file/n2400261/Screen_shot_2010-08-30_at_August_30%2C_… Screen_shot_2010-08-30_at_August_30%2C_2010_10.57.55_AM.png Noury, thanks for the reply. I loaded it in Squeak 4.1 and copied the image. Now I have two images running side-by-side. What happens is that the first one to be started sees itself in the host list. When the second one is started, the first one reports the error I told you about below, while the second one doesn't see either host. I've attached a screenshot. The only clue that I have is that RSTBroker>>objectFor:ifRemote: has a comment that says "answer a proxy if the reference points to other VM, otherwise answer the 'real' object" This sounds wrong because I still want a remote object even if it's another image on the same VM, don't I? p.s. 42 out of 43 tests are passing (except UTMulticastSocketTest>>testTimeToLive) On Aug 30, 2010, at 8:34 AM, Noury Bouraqadi wrote: Noury Bouraqadi-2 wrote: > > Hi Sean, > > I'm not sure to understand your problem. So, I'll try to clarify some > stuff, hoping it'll cover what you need. > > To use UbiquiTalk you're supposed to have multiple images running. > Each image named host, should have a different name or should be running > on a different device. > > On every UbiquiTalk hosts gui, you can see the other images (hosts) on the > network. > When you click on a host name, you'll get the list of available servers. > > We didn't try UbiquiTalk with Squeak 4. So, I'm unsure whether it works > properly. > On 29 août 2010, at 22:15, sean(a)clipperadams.com wrote: Noury Bouraqadi-2 wrote: > > Yes. But, we need an appropriate set of tools. We (Douai's team) > developed > a few tools a while ago as part of the UbiquiTalk project. We had a > remote-workspace working quite fine. > Quoted from: http://forum.world.st/Inter-image-communication-tp2320723p2337967.html Hey, in preparation to port to Pharo, I loaded UbiquiTalk in Squeak 4.1. It appears (per the GUI) to be running on two images, but when I turn on ubiquitalk in the second image via the gui, I get an error message: RSTObjectNotFound: host2 from RSTBroker>>objectFor: aRemoteObjectID ifRemote: aSelector Any ideas? Noury -- View this message in context: http://forum.world.st/UbiquiTalk-tp2400261p2400261.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

3 5

Re: [Cryptography Team] Re: [squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
by Rob Withers 04 Sep '10

04 Sep '10

Andreas, I will volunteer to take this on. I think it is a good idea. I need write access to the trunk repository, I believe. Can you help me with that? I am not sure how inbox gets used or whether I should use it. >From what I have gathered that you said, we should have the following packages: CryptoCore CryptoCoreTests CryptoExtras CryptoExtrasTests Certificates CertificatesTests Can you confirm this and that all would become Truck packages? A question below.... -------------------------------------------------- From: "Andreas Raab" <andreas.raab(a)gmx.de> > 2) It has too many variations (all those *WithPrimitive and > *NonPrimitive) variants. There's no need to have both; write the > primitive variants so that they use non-primitive fallback code or > simply require the primitives. This really isn't so bad. There are 4 plugins, and so there are 4 *WithPrimitive and 4 *NonPrimitive variants. I suggest for phase 1 we leave these alone. The issue is that in some cases the algorithm used for the Primitive is different than the algorithm used in the image. It will take some thinking to write non-primitive fallback code and untangle the algorithm class to use it. A worthy goal but not something that prevents us from packaging Crypto into the Trunk. Cheers, Rob > > 3) ASN1, X509, PKCS. This is not cryptography, this is certificate > handling. It should be in a Certificates package, not Cryptography. > > 4) A category per class. Puh-lease... > > If you do all of the above you'll end up with one or two "Crypto-Core" > categories containing all of the "essentials" like MD5, Triple DES, DSA, > RSA, SHA1, SHA256. That's probably about what you'd want in the base > image and I'd be surprised if it's more than 20 classes. I think you > could make a *very* reasoned case that this Crypto-Core should be > included in the trunk image by default in particular considering that it > would remain loadable and simplify the System (and other) packages. > > Then you have Crypt-Extras with the less common stuff, from MD2 to > DiffieHelman. On top of which is the Certificate package with ASN1, > X509, and PKCS. On top of which is the SSL stuff. > > I think this would be quite a nice structure and I'd be supporting > getting a small Crypto-Core package into trunk. Anyone up for it? > > Cheers, > - Andreas > > > -------------------------------------------------- > From: "Chris Muller" <asqueaker(a)gmail.com> > Sent: Thursday, August 26, 2010 7:02 PM > To: "Cryptography Team Development List" > <cryptography(a)lists.squeakfoundation.org> > Cc: "The general-purpose Squeak developers list" > <squeak-dev(a)lists.squeakfoundation.org> > Subject: Re: [Cryptography Team] Re: > [squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not > random > >> DigitalSignatureAlgorithm, SecureHashAlgorithm and >> ThirtyTwoBitRegister have been part of Squeak for a long time, there >> are legacy users, although I think they should migrate to using the >> counterparts in Cryptography. >> >> Folding Cryptography into Squeak would probably go against the >> political momentum toward smaller, more modular images. We don't need >> to do something that drastic just to solve this issue. >> >> I suggest instead that we merely move two utility methods from >> Cryptography: >> >> RandomGenerator class>>unpredictableStringsDo: aBlock >> RandomGenerator class>>generateKey >> >> to Random class in Squeak, and then employ them in >> DigitalSignatureAlgorithm for its #initRandomNonInteractively. >> #generateKey should be patched up from its dependence on Cryptography >> methods. >> >> This allows Squeak to purge the insecure approach of grabbing bits >> from a (silent or disconnected) SoundService, in favor of the robust >> one in Cryptography (except now moved to Squeak). >> >> - Chris >> >> >> >> >> On Mon, Aug 23, 2010 at 10:09 AM, Rob Withers <reefedjib(a)gmail.com> >> wrote: >>> Hi Chris, >>> >>> It works really well. The only issue now is the >>> DigitalSignatureAlgorithm >>> is located in the core squeak image and the changes I made are in the >>> Cryptography package. It would be nice to fold Cryptography into the >>> core >>> squeak image, or pull DigitalSignatureAlgorithm out into Cryptography. >>> >>> Rob >>> >>> -------------------------------------------------- >>> From: "Chris Muller" <asqueaker(a)gmail.com> >>> Sent: Sunday, August 22, 2010 5:35 PM >>> To: "The general-purpose Squeak developers list" >>> <squeak-dev(a)lists.squeakfoundation.org> >>> Cc: "Squeak Crypto" <cryptography(a)lists.squeakfoundation.org> >>> Subject: [Cryptography Team] Re: [squeak-dev] >>> DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random >>> >>>> Good, SecureRandom employs its #generateKey method (on the class side) >>>> to initialize its 'picker' (class-instance var). This was intended to >>>> serve as a globally usable SecureRandom so that clients like >>>> DigitalSignatureAlgorithm would not have to define their own. >>>> >>>> On Sat, Aug 21, 2010 at 5:30 AM, Rob Withers <reefedjib(a)gmail.com> >>>> wrote: >>>>> >>>>> I found a problem with >>>>> DigitalSignatureAlgorithm>>#initRandomNonInteractively. It is >>>>> grabbing >>>>> randomBits from the SoundSystem, but I may not have that installed. >>>>> It >>>>> gave >>>>> me the same bits repeatedly. I modified >>>>> DigitalSignatureAlgorithm>>#initRandomNonInteractively to not rely on >>>>> the >>>>> SoundSystem and instead use SecureRandom. This is published in the >>>>> Cryptography repository. >>>>> >>>>> Rob >>>>> >>>>> >>>> _______________________________________________ >>>> Cryptography mailing list >>>> Cryptography(a)lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography >>>> >>> _______________________________________________ >>> Cryptography mailing list >>> Cryptography(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography >>> >> >> >

7 48

Squeak on Ubuntu reloaded
by Alexander Lazarević 02 Sep '10

02 Sep '10

I just updated my article about Squeak on Ubuntu<http://blog.blobworks.com/2010/08/16/squeak-on-ubuntu-reloaded/>, which is aimed at the more infrequent Ubuntu/Squeak user. Any comments are welcome. Thanks, Alex

2 3

System change notifications & Smalltalk(Image)
by Eliot Miranda 01 Sep '10

01 Sep '10

Hi All, I have just found out why some recent images of ours at Teleplace aren't logging doits; the system notifications are missing Smalltalk as a target. If you look at senders of SystemChangeNotifier>>notify:ofAllSystemChangesUsing: in trunk you'll see the following three key senders (ignoring tests) ChangeSet class>>newChanges: - ensures change sets keep up to date with changes Preferences class>>registerForEvents - ensures prefs stay up to date when methods with preference method tags get added/removed Utilities class>>startUp - ensures recent submissions are maintained SmalltalkImage is conspicuously absent, yet | | am | am := (SystemChangeNotifier uniqueInstance instVarNamed: 'eventSource') actionMap. am keys select: [:k| | e | (e := am at: k) isArray ifTrue: [e anySatisfy: [:seq| seq receiver == Smalltalk]] ifFalse: [e receiver == Smalltalk]] #(#protocolRenamedEvent: #methodModifiedEvent: #protocolAddedEvent: #categoryRemovedEvent: #expressionDoItEvent: #methodRemovedEvent: #classReorganizedEvent: #protocolModifiedEvent: #categoryModifiedEvent: #classRenamedEvent: #protocolRemovedEvent: #classRemovedEvent: #classAddedEvent: #categoryRenamedEvent: #classModifiedEvent: #methodRecategorizedEvent: #classCommentedEvent: #methodAddedEvent: #classRecategorizedEvent: #categoryAddedEvent:) | am | am := (SystemChangeNotifier uniqueInstance instVarNamed: 'eventSource') actionMap. am keys reject: [:k| | e | (e := am at: k) isArray ifTrue: [e anySatisfy: [:seq| seq receiver == Smalltalk]] ifFalse: [e receiver == Smalltalk]] #(#methodReorganizedEvent: #methodCommentedEvent: #methodDoItEvent: #categoryRecategorizedEvent: #methodRenamedEvent:) and there's the rub. Why isn't Smalltalk a target of all events? Why does it exclude #methodReorganizedEvent: #methodCommentedEvent: #methodDoItEvent: #categoryRecategorizedEvent: #methodRenamedEvent:? Is this merely accident? I'm pretty sure that SmalltalkImage class>>startUp needs to ensure system notifications are up-to-date, but are the above exclusions missing for any reason? It's kind of hard to figure out (see below). I *think* that it should read SmalltalkImage class>>startUp "XXXX: This is broken. SmalltalkImage startUp happens quite late in the startup sequence; earlier startups may very well need the information about the endianness of the platform." EndianCache := nil. SystemChangeNotifier uniqueInstance notify: SmalltalkofAllSystemChangesUsing: #event: but I thought I'd check with y'all. and finally when can we reimplement this entire mess using e.g. Anouncements, I mean: AbstractEvent>>eventSelector ^self class eventSelectorBlock value: itemKind value: self changeKind AbstractEvent class>>eventSelectorBlock ^[:itemKind :changeKind | itemKind, changeKind, 'Event:'] Surely this is too direct and easy to understand ;) I mean who /needs/ senders and implementors to work? grrr.... Eliot

4 3

Daily Commit Log
by commits＠source.squeak.org 01 Sep '10

01 Sep '10

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2010-August/003669.html Name: System-eem.366 Ancestors: System-nice.365 Make sure system notifications for Smalltalk are up-to-date on start-up. Fix voiding of Smalltalk's endian cache which needs to be done in a timely manner. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-August/003670.html Name: Compiler-eem.172 Ancestors: Compiler-nice.170 Fix decompilation/pretty-print of expr ifNotNil: [:var| which used to be rendered as (var := expr) ifNotNil: [:var|. =============================================

1 0

The Trunk: Compiler-eem.172.mcz
by commits＠source.squeak.org 31 Aug '10

31 Aug '10

Eliot Miranda uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-eem.172.mcz ==================== Summary ==================== Name: Compiler-eem.172 Author: eem Time: 31 August 2010, 12:45:25.496 pm UUID: cbf01579-162b-43d4-ab9e-1099261e3570 Ancestors: Compiler-nice.170 Fix decompilation/pretty-print of expr ifNotNil: [:var| which used to be rendered as (var := expr) ifNotNil: [:var|. =============== Diff against Compiler-nice.170 =============== Item was changed: ----- Method: ParseNodeEnumerator>>visitMessageNodeInCascade: (in category 'visiting') ----- visitMessageNodeInCascade: aMessageNodeInCascade + (theSelectBlock isNil or: [theSelectBlock value: aMessageNodeInCascade]) ifFalse: + [^nil]. theBlock value: aMessageNodeInCascade. ^super visitMessageNodeInCascade: aMessageNodeInCascade! Item was changed: ----- Method: ParseNodeEnumerator>>visitAssignmentNode: (in category 'visiting') ----- visitAssignmentNode: anAssignmentNode + (theSelectBlock isNil or: [theSelectBlock value: anAssignmentNode]) ifFalse: + [^nil]. theBlock value: anAssignmentNode. ^super visitAssignmentNode: anAssignmentNode! Item was changed: ----- Method: BlockNode>>arguments (in category 'accessing') ----- arguments + ^arguments ifNil: [#()]! - ^arguments! Item was added: + ----- Method: MethodNode>>preen (in category 'converting') ----- + preen + "Preen for pretty-printing and/or decompilation. + i.e. post-process to cover up for inadequacies in both algorithms. + Currently one case, hiding the assignment to the arg of an inlined block arg to ifNotNil:, + (var := expr) ifNil: [...] ifNotNil: [...] => expr ifNil: [...] ifNotNil: [:var| ...]." + + self preenLocalIfNotNilArg! Item was changed: ----- Method: ParseNodeEnumerator>>visitMessageNode: (in category 'visiting') ----- visitMessageNode: aMessageNode + (theSelectBlock isNil or: [theSelectBlock value: aMessageNode]) ifFalse: + [^nil]. theBlock value: aMessageNode. ^super visitMessageNode: aMessageNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitInstanceVariableNode: (in category 'visiting') ----- visitInstanceVariableNode: anInstanceVariableNode + (theSelectBlock isNil or: [theSelectBlock value: anInstanceVariableNode]) ifFalse: + [^nil]. theBlock value: anInstanceVariableNode. ^super visitInstanceVariableNode: anInstanceVariableNode! Item was added: + ----- Method: ParseNodeEnumerator class>>ofBlock:select: (in category 'instance creation') ----- + ofBlock: aBlock select: selectBlock + ^self new ofBlock: aBlock select: selectBlock! Item was changed: ----- Method: ParseNodeEnumerator>>visitSelectorNode: (in category 'visiting') ----- visitSelectorNode: aSelectorNode + (theSelectBlock isNil or: [theSelectBlock value: aSelectorNode]) ifFalse: + [^nil]. theBlock value: aSelectorNode. ^super visitSelectorNode: aSelectorNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitFutureNode: (in category 'visiting') ----- visitFutureNode: aFutureNode + (theSelectBlock isNil or: [theSelectBlock value: aFutureNode]) ifFalse: + [^nil]. theBlock value: aFutureNode. ^super visitFutureNode: aFutureNode! Item was changed: ----- Method: Compiler>>format:noPattern:ifFail: (in category 'private') ----- format: aStream noPattern: noPattern ifFail: failBlock + ^(self parser - ^self parser parse: aStream class: class noPattern: noPattern context: context notifying: requestor + ifFail: [^failBlock value]) preen! - ifFail: [^failBlock value]! Item was changed: ----- Method: ParseNodeEnumerator>>visitTempVariableNode: (in category 'visiting') ----- visitTempVariableNode: aTempVariableNode + (theSelectBlock isNil or: [theSelectBlock value: aTempVariableNode]) ifFalse: + [^nil]. theBlock value: aTempVariableNode. ^super visitTempVariableNode: aTempVariableNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitCascadeNode: (in category 'visiting') ----- visitCascadeNode: aCascadeNode + (theSelectBlock isNil or: [theSelectBlock value: aCascadeNode]) ifFalse: + [^nil]. theBlock value: aCascadeNode. ^super visitCascadeNode: aCascadeNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitCommentNode: (in category 'visiting') ----- visitCommentNode: aCommentNode + (theSelectBlock isNil or: [theSelectBlock value: aCommentNode]) ifFalse: + [^nil]. theBlock value: aCommentNode. ^super visitCommentNode: aCommentNode! Item was added: + ----- Method: ParseNode>>isOnlySubnodeOf:in: (in category 'testing') ----- + isOnlySubnodeOf: aSubtree "<ParseNode>" in: aParseTree "<ParseNode>" + "Answer if the receiver only occurs within aSubtree of aParseTree, not in the rest of aParseTree. + Assumes that aSubtree is in fact a subnode of aParseTree." + | isSubnode | + isSubnode := false. + aSubtree accept: (ParseNodeEnumerator + ofBlock: [:node| node == self ifTrue: [isSubnode := true]]). + isSubnode ifFalse: + [^false]. + aParseTree accept: (ParseNodeEnumerator + ofBlock: [:node| node == self ifTrue: [^false]] + select: [:node| node ~= aSubtree]). + ^true! Item was changed: ----- Method: ParseNodeEnumerator>>visitBlockNode: (in category 'visiting') ----- visitBlockNode: aBlockNode + (theSelectBlock isNil or: [theSelectBlock value: aBlockNode]) ifFalse: + [^nil]. theBlock value: aBlockNode. ^super visitBlockNode: aBlockNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitBraceNode: (in category 'visiting') ----- visitBraceNode: aBraceNode + (theSelectBlock isNil or: [theSelectBlock value: aBraceNode]) ifFalse: + [^nil]. theBlock value: aBraceNode. ^super visitBraceNode: aBraceNode! Item was added: + ----- Method: ParseNodeEnumerator>>ofBlock:select: (in category 'initialize-release') ----- + ofBlock: aBlock select: aSelectBlock + theBlock := aBlock. + theSelectBlock := aSelectBlock! Item was added: + ----- Method: MethodNode>>preenLocalIfNotNilArg (in category 'converting') ----- + preenLocalIfNotNilArg + "Try and spot a (var := expr) ifNil: [...] ifNotNil: [...] where var is only used in the ifNotNil: block + and convert it to expr ifNil: [...] ifNotNil: [:var| ...]. Deal both with the pretty-print case where + the block already declares the variable and the decompile case where it does not." + + | varsToHide | + varsToHide := Set new. + self nodesDo: + [:node| | variable | + (node isMessageNode + and: [node macroPrinter == #printIfNilNotNil:indent: + and: [node receiver isMessageNode + and: [node receiver selector key == #== + and: [node receiver receiver isAssignmentNode + and: [(variable := node receiver receiver variable) isTemp + and: [variable isRemote not + and: [variable isOnlySubnodeOf: node in: self]]]]]]]) ifTrue: + [node arguments last arguments isEmpty + ifTrue: [node arguments last arguments: { variable }. + varsToHide add: variable] + ifFalse: [self assert: node arguments last arguments asArray = { variable }]. + node receiver receiver: node receiver receiver value]]. + varsToHide notEmpty ifTrue: + [self nodesDo: + [:node| + ((node == self or: [node isBlockNode]) + and: [node temporaries anySatisfy: [:temp| varsToHide includes: temp]]) ifTrue: + [node temporaries: (node temporaries reject: [:temp| varsToHide includes: temp])]]]! Item was changed: ----- Method: ParseNodeEnumerator>>visitReturnNode: (in category 'visiting') ----- visitReturnNode: aReturnNode + (theSelectBlock isNil or: [theSelectBlock value: aReturnNode]) ifFalse: + [^nil]. theBlock value: aReturnNode. ^super visitReturnNode: aReturnNode! Item was changed: ParseNodeVisitor subclass: #ParseNodeEnumerator + instanceVariableNames: 'theBlock theSelectBlock' - instanceVariableNames: 'theBlock' classVariableNames: '' poolDictionaries: '' category: 'Compiler-Support'! + !ParseNodeEnumerator commentStamp: 'eem 8/31/2010 11:41' prior: 0! + ParseNodeEnumerator implements ParseNode>>nodesDo:. It can be used to enumerate an entire tree via + aParseNode accept: (ParseNodeEnumerator ofBlock: aBlock) + or selectively, excluding the node and subnodes for which selectBlock answers false, via + aParseNode accept: (ParseNodeEnumerator + ofBlock: aBlock + select: selectBlock) + + Here's a doIt that generates and compiles the visiting methods: + - !ParseNodeEnumerator commentStamp: '<historical>' prior: 0! self superclass selectors do: [:s| self compile: (String streamContents: [:str| | arg | arg := 'a', (s allButFirst: 5) allButLast. str nextPutAll: s, ' ', arg; crtab; + nextPutAll: '(theSelectBlock isNil or: [theSelectBlock value: '; nextPutAll: arg; nextPutAll: ']) ifFalse:'; crtab; + tab: 2; nextPutAll: '[^nil].'; crtab; nextPutAll: 'theBlock value: '; nextPutAll: arg; nextPut: $.; crtab; nextPutAll: '^super '; nextPutAll: s, ' ', arg])]! Item was changed: ----- Method: ParseNodeEnumerator>>visitMethodNode: (in category 'visiting') ----- visitMethodNode: aMethodNode + (theSelectBlock isNil or: [theSelectBlock value: aMethodNode]) ifFalse: + [^nil]. theBlock value: aMethodNode. ^super visitMethodNode: aMethodNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitFieldNode: (in category 'visiting') ----- visitFieldNode: aFieldNode + (theSelectBlock isNil or: [theSelectBlock value: aFieldNode]) ifFalse: + [^nil]. theBlock value: aFieldNode. ^super visitFieldNode: aFieldNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitVariableNode: (in category 'visiting') ----- visitVariableNode: aVariableNode + (theSelectBlock isNil or: [theSelectBlock value: aVariableNode]) ifFalse: + [^nil]. theBlock value: aVariableNode. ^super visitVariableNode: aVariableNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitNewArrayNode: (in category 'visiting') ----- visitNewArrayNode: aNewArrayNode + (theSelectBlock isNil or: [theSelectBlock value: aNewArrayNode]) ifFalse: + [^nil]. theBlock value: aNewArrayNode. ^super visitNewArrayNode: aNewArrayNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitLiteralNode: (in category 'visiting') ----- visitLiteralNode: aLiteralNode + (theSelectBlock isNil or: [theSelectBlock value: aLiteralNode]) ifFalse: + [^nil]. theBlock value: aLiteralNode. ^super visitLiteralNode: aLiteralNode! Item was changed: ----- Method: BlockNode>>temporaries (in category 'accessing') ----- temporaries + ^temporaries ifNil: [#()]! - ^temporaries! Item was changed: ----- Method: ParseNodeEnumerator>>visitRemoteTempVectorNode: (in category 'visiting') ----- visitRemoteTempVectorNode: aRemoteTempVectorNode + (theSelectBlock isNil or: [theSelectBlock value: aRemoteTempVectorNode]) ifFalse: + [^nil]. theBlock value: aRemoteTempVectorNode. ^super visitRemoteTempVectorNode: aRemoteTempVectorNode! Item was changed: ----- Method: ParseNodeEnumerator>>visitLiteralVariableNode: (in category 'visiting') ----- visitLiteralVariableNode: aLiteralVariableNode + (theSelectBlock isNil or: [theSelectBlock value: aLiteralVariableNode]) ifFalse: + [^nil]. theBlock value: aLiteralVariableNode. ^super visitLiteralVariableNode: aLiteralVariableNode! Item was changed: ----- Method: Decompiler>>decompile:in:method:using: (in category 'public access') ----- decompile: aSelector in: aClass method: aMethod using: aConstructor | block node | constructor := aConstructor. method := aMethod. self initSymbols: aClass. "create symbol tables" method isQuick ifTrue: [block := self quickMethod] ifFalse: [stack := OrderedCollection new: method frameSize. caseExits := OrderedCollection new. statements := OrderedCollection new: 20. numLocalTemps := 0. super method: method pc: method initialPC. "skip primitive error code store if necessary" (method primitive ~= 0 and: [self willStore]) ifTrue: [pc := pc + 2. tempVars := tempVars asOrderedCollection]. block := self blockTo: method endPC + 1. stack isEmpty ifFalse: [self error: 'stack not empty']]. node := constructor codeMethod: aSelector block: block tempVars: tempVars primitive: method primitive class: aClass. method primitive > 0 ifTrue: [node removeAndRenameLastTempIfErrorCode]. + ^node preen! - ^node! Item was removed: - ----- Method: ParseNode>>optimizedBlockHoistTempsInto: (in category 'code generation (closures)') ----- - optimizedBlockHoistTempsInto: scopeBlock "<BlockNode>" - "This is a No-op for all nodes except non-optimized BlockNodes." - ^self!

1 0

The Trunk: System-eem.366.mcz
by commits＠source.squeak.org 31 Aug '10

31 Aug '10

Eliot Miranda uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-eem.366.mcz ==================== Summary ==================== Name: System-eem.366 Author: eem Time: 31 August 2010, 10:47:17.97 am UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd Ancestors: System-nice.365 Make sure system notifications for Smalltalk are up-to-date on start-up. Fix voiding of Smalltalk's endian cache which needs to be done in a timely manner. =============== Diff against System-nice.365 =============== Item was changed: ----- Method: SmalltalkImage class>>startUp (in category 'class initialization') ----- startUp + SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:! - "XXXX: This is broken. SmalltalkImage startUp happens quite late in the startup sequence; earlier startups may very well need the information about the endianness of the platform." - EndianCache := nil. - ! Item was changed: ----- Method: SmalltalkImage>>processShutDownList: (in category 'snapshot and quit') ----- processShutDownList: quitting + "Send #shutDown to each class that needs to wrap up before a snapshot. + Also void the endianness chace; this can't safely be done on start-up because + Smalltalk is too late in the start-up sequence." - "Send #shutDown to each class that needs to wrap up before a snapshot." + EndianCache := nil. + self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting! - self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting. - !

1 0

Jump to page: