Squeak-dev July 2012

squeak-dev@lists.squeakfoundation.org

55 participants
189 discussions

Hey, Sean: a Jenkins question for you
by Chris Cunnington 01 Aug '12

01 Aug '12

False alarm, I think. I don't think this is a Jenkins problem. It's just me baffling myself with a symbolic link. I used one to make the Jenkins workspace directory accessible from the teamjenkins directory to provide FTP access. Chris

2 1

First green ball on Jenkins
by Chris Cunnington 01 Aug '12

01 Aug '12

http://squeakci.org/ Frank, has made the first green ball appear on the Jenkins server. We invite you to look at this beautiful, multi-shaded green icon right there, large as life. Yea, Frank! Chris

5 6

turning off garbage collection
by Chris Muller 01 Aug '12

01 Aug '12

I'm trying to investigate a reproducible Cog crash and beginning to wonder whether Cog may have some sort of timing issue with the garbage collector. Is there an easy way to turn off the garbage collector in the image?

3 3

Hey, Sean: a Jenkins question for you
by Chris Cunnington 31 Jul '12

31 Jul '12

Hi Sean, I recall you saying next time I should just ask. So I'm asking. Frank and I cannot figure out a permissions problem we are having with the workspace. The teamjenkins user does not seem to have the permission to delete things from the workspace. This is clearly seen when the workspace is accessed by ftp and Fetch is used to try to delete a file. Shell access, which you first pointed out, has been re-activated. So that's not the problem. Thanks, Chris

1 0

Re: Squeak release process - CI server
by Chris Cunnington 31 Jul '12

31 Jul '12

HDTestReport runPackages: #( 'HelpSystem-Tests' ). "Save and Quit" WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: true andQuit: true ]. or something more succinct: HDTestReport runPackages: ((WADevelopment allPackages select: [ :each | each name includesSubString: '-Tests-' ]) collect: [ :each | each name ]). <the simple answer> tests.st is in the FTP directory. It contains the content above. Add test names as strings in the array like 'HelpSystem-Tests'. Or, iterate over some packages for '-Tests-' </the simple answer> <longer explanation/probably a rant> I don't think GitHub has anything to do with it. The Pharo Jenkins server doesn't use it. That's just where Lukas decided to make his scripts available. https://github.com/renggli/builder/tree/master/scripts https://github.com/renggli/builder/blob/master/build.sh Lukas has a system with two parts: scripts; and, the build.sh shell script. There are loads of scripts lying around on the Pharo Jenkins server. They are attached and combined dynamically by a ~160 line shell script called build.sh. So you'd write something like this: build.sh -i Omnibrowser -i Greco -i Roman -i Etc That collects a bunch of scripts. All of them look like the content above: string names in an array. build.sh merges these scripts elegantly into one single stream. There is no tangible difference between that and having a file called tests.st where you cut and paste in the test names as strings. Is Lukas's system elegant? Yes. Do I want to wade through a ~160 shell script to faithfully reproduce that? Let me put it this way: why would anybody write a shell script over ~100 lines? Even if it was an init script? It seems to me build.sh could have been written in another scripting language and been both shorter and easier to comprehend for the next guy who came along. It's not 1983. </longer explanation/probably a rant> Chris "I don't think you can do that via the Jenkins web UI. Putting the scripts on github like Lukas did makes contributing convenient. Then you can have a really simple Jenkins job that just downloads the scripts and runs one." This is interesting, but I don't think it works that way. If I understand what you're saying, build.sh would pull down scripts from Github. I don't think that's even possible. Why does Github use SSL? To password protect scripts it gives away for free? I don't think so. Only humans can download content from Github. Try putting a picture gif on Github and then link to it from the webpage you're building. Github uses SSL to enforce an interface. They don't want people linking to its resources. Pharo Jenkins has all the scripts locally in a directory somewhere. I don't think you can clone individual files on demand programmaticlly. I'm willing to be wrong, but I feel confident that things are as I just described.

4 14

The Inbox: Collections-ael.481.mcz
by Aran Lunzer 30 Jul '12

30 Jul '12

This is a proposed fix for the following behaviour: Creating a Dictionary (or subclass) using newFrom: another dictionary, or as:, reuses the associations from the original collection. Thus some updates to the new collection affect the old, and vice versa. Example using #as: orig := PluggableDictionary new. orig at: #one put: 'foo'; at: #two put: 0@0. new := orig as: Dictionary. new at: #one put: 'bar'. orig ---> a PluggableDictionary(#one->'bar' #two->0@0 ) Aran -- Aran Lunzer Viewpoints Research Institute

1 0

The Inbox: CollectionsTests-ael.187.mcz
by commits＠source.squeak.org 30 Jul '12

30 Jul '12

A new version of CollectionsTests was added to project The Inbox: http://source.squeak.org/inbox/CollectionsTests-ael.187.mcz ==================== Summary ==================== Name: CollectionsTests-ael.187 Author: ael Time: 30 July 2012, 2:40:57.923 pm UUID: b4b909c2-e655-4b7e-94f8-0f5c40a227d0 Ancestors: CollectionsTests-ul.186 test case for isolation of dictionary created using newFrom: =============== Diff against CollectionsTests-ul.186 =============== Item was added: + ----- Method: DictionaryTest>>testNewFromIsolation (in category 'basic tests') ----- + testNewFromIsolation + "self run:#testNewFromIsolation" + "self debug:#testNewFromIsolation" + + | dict1 dict2 | + dict1 := Dictionary new. + dict1 at: #one put: 'foo'; at: #two put: 0@0. + dict2 := Dictionary newFrom: dict1. + dict2 at: #one put: 'bar'. + + self assert: (dict1 at: #one) = 'foo'. + !

1 0

The Inbox: Collections-ael.481.mcz
by commits＠source.squeak.org 30 Jul '12

30 Jul '12

A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ael.481.mcz ==================== Summary ==================== Name: Collections-ael.481 Author: ael Time: 30 July 2012, 2:40:08.671 pm UUID: c2a7afc0-37ac-404b-ae81-bf782e1dd254 Ancestors: Collections-cwp.480 remove spurious sharing of associations between a dictionary and another created from it =============== Diff against Collections-cwp.480 =============== Item was changed: ----- Method: Dictionary class>>newFrom: (in category 'instance creation') ----- newFrom: aDict "Answer an instance of me containing the same associations as aDict. Error if any key appears twice." | newDictionary | newDictionary := self new: aDict size. aDict associationsDo: [:x | (newDictionary includesKey: x key) ifTrue: [self error: 'Duplicate key: ', x key printString] + ifFalse: [newDictionary add: x copy]]. - ifFalse: [newDictionary add: x]]. ^ newDictionary " NewDictionary newFrom: {1->#a. 2->#b. 3->#c} {1->#a. 2->#b. 3->#c} as: NewDictionary NewDictionary newFrom: {1->#a. 2->#b. 1->#c} {1->#a. 2->#b. 1->#c} as: NewDictionary "!

1 0

Documentation/Comment per package
by Enrico Schwass 30 Jul '12

30 Jul '12

Hello, I wonder if there is a way to describe a certain package. You can put comments on class side. But what if you want to describe the intent of a package or the relation of classes inside a package and how to use them. Is there a way to put information along packages? I was digging into PackageInfo but dont know how to use/extent it. TIA Enno

10 27

Re: [squeak-dev] The Inbox: PackageInfo-Base-bf.65.mcz
by Levente Uzonyi 30 Jul '12

30 Jul '12

On Sat, 28 Jul 2012, commits(a)source.squeak.org wrote: > Bert Freudenberg uploaded a new version of PackageInfo-Base to project The Inbox: > http://source.squeak.org/inbox/PackageInfo-Base-bf.65.mcz > > ==================== Summary ==================== > > Name: PackageInfo-Base-bf.65 > Author: bf > Time: 28 July 2012, 2:20:30.545 pm > UUID: 52c0359f-bd7e-4f1f-9a33-95b5cef7abb4 > Ancestors: PackageInfo-Base-bf.64 > > Add per-package comments. > > =============== Diff against PackageInfo-Base-bf.64 =============== > > Item was changed: > Object subclass: #PackageInfo > + instanceVariableNames: 'packageName methodCategoryPrefix preamble postscript preambleOfRemoval postscriptOfRemoval comment' > - instanceVariableNames: 'packageName methodCategoryPrefix preamble postscript preambleOfRemoval postscriptOfRemoval' > classVariableNames: '' > poolDictionaries: '' > category: 'PackageInfo-Base'! > PackageInfo class > instanceVariableNames: 'default'! > > !PackageInfo commentStamp: 'bf 7/28/2012 14:11' prior: 0! > PackageInfo is used by the system to figure out which classes and methods belong to which package. By default, class categories and method categories are matched against my packageName, but subclasses could override this behavior. > > For an interesting use of PackageInfo subclasses have a look at OMeta2. It presents the same code base as two different packages, one using decompiled code for bootstrapping, the other using the actual OMeta syntax.! > PackageInfo class > instanceVariableNames: 'default'! > > Item was added: > + ----- Method: PackageInfo>>comment (in category 'preamble/postscript') ----- > + comment > + ^ comment ifNil: [ > + comment := StringHolder new contents: self commentDefault]! Wouldn't it be better to use the setter method here, to avoid the code duplication? > > Item was added: > + ----- Method: PackageInfo>>comment: (in category 'preamble/postscript') ----- > + comment: aString > + comment := StringHolder new contents: aString! > > Item was added: > + ----- Method: PackageInfo>>commentDefault (in category 'preamble/postscript') ----- > + commentDefault > + ^ 'THIS PACKAGE HAS NO COMMENT'! > > Item was added: > + ----- Method: PackageInfo>>hasComment (in category 'preamble/postscript') ----- > + hasComment > + ^ self isScript: comment not: self commentDefault! Shouldn't the first argument be self comment, instead of the instance variable comment? If the value of comment is nil (it is, before #comment or #comment: is sent), then it will be shown as if the package has comment. Levente > > >

2 1

Jump to page: