Squeak-dev February 2013

squeak-dev@lists.squeakfoundation.org

61 participants
225 discussions

The Trunk: Kernel-nice.741.mcz
by commits＠source.squeak.org 24 Feb '13

24 Feb '13

Nicolas Cellier uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-nice.741.mcz ==================== Summary ==================== Name: Kernel-nice.741 Author: nice Time: 24 February 2013, 5:32:56.978 pm UUID: 15a282b0-84ac-4723-b44c-7dd91e9aebf0 Ancestors: Kernel-eem.740 Reduce the number of hardcoded constants used by #raisedTo:modulo: This will enable smooth transition to next generation of LargeIntegersPlugin. =============== Diff against Kernel-eem.740 =============== Item was added: + ----- Method: Integer>>montgomeryDigitBase (in category 'private') ----- + montgomeryDigitBase + "Answer the base used by Montgomery algorithm." + ^1 << self montgomeryDigitLength! Item was added: + ----- Method: Integer>>montgomeryDigitLength (in category 'private') ----- + montgomeryDigitLength + "Answer the number of bits composing a digit in Montgomery algorithm. + Primitive use either 8 or 32 bits digits" + <primitive: 'primMontgomeryDigitLength' module:'LargeIntegers'> + ^8 "Legacy plugin which did not have this primitive did use 8 bits digits"! Item was added: + ----- Method: Integer>>montgomeryDigitMax (in category 'private') ----- + montgomeryDigitMax + "Answer the maximum value of a digit used in Montgomery algorithm." + + ^1 << self montgomeryDigitLength - 1! Item was added: + ----- Method: Integer>>montgomeryNumberOfDigits (in category 'private') ----- + montgomeryNumberOfDigits + "Answer the number of montgomery digits required to represent the receiver." + ^self digitLength * 8 + (self montgomeryDigitLength - 1) // self montgomeryDigitLength! Item was changed: ----- Method: Integer>>montgomeryRaisedTo:times:modulo:mInvModB: (in category 'private') ----- montgomeryRaisedTo: n times: y modulo: m mInvModB: mInv "Private - do a Montgomery exponentiation of self modulo m. The operation is equivalent to (self/y raisedTo: n)*y \\ m, + with y is (b raisedTo: m montgomeryNumberOfDigits), + with (m bitAnd: b-1) * mInv \\ b = (b-1) + with b = self montgomeryDigitBase (either 1<<8 or 1<<32)" - with y is (256 raisedTo: m digitLength), - with (m bitAnd: 255) * mInv \\ 256 = 255." | pow j k w index oddPowersOfSelf square | "Precompute powers of self for odd bit patterns xxxx1 up to length w + 1. The width w is chosen with respect to the total bit length of n, such that each bit pattern will on average be encoutered P times in the whole bit sequence of n. This costs (2 raisedTo: w) multiplications, but more will be saved later (see below)." k := n highBit. w := (k highBit - 1 >> 1 min: 16) max: 1. oddPowersOfSelf := Array new: 1 << w. oddPowersOfSelf at: 1 put: (pow := self). square := self montgomeryTimes: self modulo: m mInvModB: mInv. 2 to: oddPowersOfSelf size do: [:i | pow := oddPowersOfSelf at: i put: (pow montgomeryTimes: square modulo: m mInvModB: mInv)]. "Now exponentiate by searching precomputed bit patterns with a sliding window" pow := y. [k > 0] whileTrue: [pow := pow montgomeryTimes: pow modulo: m mInvModB: mInv. "Skip bits set to zero (the sliding window)" (n bitAt: k) = 0 ifFalse: ["Find longest odd bit pattern up to window length (w + 1)" j := k - w max: 1. [j < k and: [(n bitAt: j) = 0]] whileTrue: [j := j + 1]. "We found a bit pattern of length k-j+1; perform the square powers for each bit (same cost as bitwise algorithm); compute the index of this bit pattern in the precomputed powers." index := 0. [k > j] whileTrue: [pow := pow montgomeryTimes: pow modulo: m mInvModB: mInv. index := index << 1 + (n bitAt: k). k := k - 1]. "Perform a single multiplication for the whole bit pattern. This saves up to (k-j) multiplications versus a naive algorithm operating bit by bit" pow := pow montgomeryTimes: (oddPowersOfSelf at: index + 1) modulo: m mInvModB: mInv]. k := k - 1]. ^pow! Item was changed: ----- Method: Integer>>montgomeryTimes:modulo:mInvModB: (in category 'private') ----- montgomeryTimes: a modulo: m mInvModB: mInv "Answer the result of a Montgomery multiplication + self * a * (b raisedTo: m montgomeryNumberOfDigits) inv \\ m - self * a * (256 raisedTo: m digitLength) inv \\ m NOTE: it is assumed that: + self montgomeryNumberOfDigits <= m montgomeryNumberOfDigits + a montgomeryNumberOfDigits <= m montgomeryNumberOfDigits + mInv * m \\ b = (-1 \\ b) = (b-1) (this implies m odd) + where b = self montgomeryDigitBase - self digitLength <= m digitLength - a digitLength <= m digitLength - mInv * m \\ 256 = (-1 \\ 256) = 255 (this implies m odd) Answer nil in case of absent plugin or other failure." <primitive: 'primMontgomeryTimesModulo' module:'LargeIntegers'> ^nil! Item was changed: ----- Method: Integer>>raisedTo:modulo: (in category 'mathematical functions') ----- raisedTo: n modulo: m "Answer the modular exponential. Note: this implementation is optimized for case of large integers raised to large powers." | a s mInv | n = 0 ifTrue: [^1]. (self >= m or: [self < 0]) ifTrue: [^self \\ m raisedTo: n modulo: m]. n < 0 ifTrue: [^(self reciprocalModulo: m) raisedTo: n negated modulo: m]. (n < 4096 or: [m even]) ifTrue: ["Overhead of Montgomery method might cost more than naive divisions, use naive" ^self slidingLeftRightRaisedTo: n modulo: m]. + mInv := self montgomeryDigitBase - ((m bitAnd: self montgomeryDigitMax) reciprocalModulo: self montgomeryDigitBase). - mInv := 256 - ((m bitAnd: 255) reciprocalModulo: 256). + "Initialize the result to R=self montgomeryDigitModulo raisedTo: m montgomeryNumberOfDigits" + a := (1 bitShift: m montgomeryNumberOfDigits * m montgomeryDigitLength) \\ m. - "Initialize the result to R=256 raisedTo: m digitLength" - a := (1 bitShift: m digitLength*8) \\ m. "Montgomerize self (multiply by R)" (s := self montgomeryTimes: (a*a \\ m) modulo: m mInvModB: mInv) ifNil: ["No Montgomery primitive available ? fallback to naive divisions" ^self slidingLeftRightRaisedTo: n modulo: m]. "Exponentiate self*R" a := s montgomeryRaisedTo: n times: a modulo: m mInvModB: mInv. "Demontgomerize the result (divide by R)" ^a montgomeryTimes: 1 modulo: m mInvModB: mInv!

1 0

[JOB][Research] Postdoc position: IDEs
by Marcus Denker 24 Feb '13

24 Feb '13

Infrastructure for new generation IDEs ===================================== About Inria and the job ----------------------- Inria, with its academic, institutional and industrial partners, is commited to major research and innovation projects in the field of computational sciences. The institute disseminates across France thanks to its eight research centres. The Inria Lille - Nord Europe research centre, inaugurated in 2008, employs 357 people, including 250 scientists, in its seventeen research teams. Recognised for its significant contribution to the social and economic development of the Nord - Pas-de-Calais region, the Inria Lille - Nord Europe research centre promotes a policy of close cooperation with major businesses and small enterprises. By encouraging synergies between researchers and industrial partners, Inria contributes to the transfer of skills and expertise in computational technologies and provides access to top-level European and international research in order to support innovation and businesses, particularly in the region of Lille. Whether designing innovative software for business or logistics, modelling living cells or fusion plasma, or developing medical simulators or interfaces to facilitate human-computer interaction, our research opens up new possibilities that can revolutionise common practice and contribute to a better understanding of the natural phenomena which surround us. The goal of the RMoD research team at Inria Lille is to support re-modularization of object-oriented applications. This objective is tackled from two complementary perspectives: reengineering and modularity constructs for programming languages. For more information on RMOD, see http://rmod.lille.inria.fr Mission ------- The objectives will be to reconsider and develop a new infrastructure to build new and modern IDEs. The goal of this postdoc is to help the RMOD team rethinking the infrastructure of Pharo from the point of view of its user interface and interaction foundation as well as code navigation. The following topics will be analysed and rethought : - Alternate models of event handling - Decomposing responsibilities of event handler and dispatchers. - Alternative ways to navigate code - Queries to access code elements - Smart handling of coding contexts - Management of window plague - Support for contextual refactorings and automated code transformation. Skills and profile ------------------ - English - Pharo: http://www.pharo.org - User interface design, Vector graphics - IDE design and user interactions Benefits --------- - Possibility of French courses - Help for housing - Participation for transportation - Scientific Resident card and help for husband/wife visa Additional information ----------------------- - Duration : 16 months - Salary: 2 620,84 € gross/month - Monthly salary after taxes : around 2 138 € (medical insurance included) - For the first selections, please apply before March 2013, 22nd. - Before applying, please contact the scientist advisor: stephane.ducasse(a)inria.fr - More information: http://rmod.lille.inria.fr/web/pier/blog/2013-02-22 Security and defense procedure ------------------------------ In the interests of protecting its scientific and technological assets, Inria is a restricted-access establishment. Consequently, it follows special regulations for welcoming any person who wishes to work with the institute. The final acceptance of each candidate thus depends on applying this security and defense procedure.

1 0

The Trunk: Kernel-eem.740.mcz
by commits＠source.squeak.org 24 Feb '13

24 Feb '13

Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.740.mcz ==================== Summary ==================== Name: Kernel-eem.740 Author: eem Time: 23 February 2013, 5:42:23.379 pm UUID: 9dce4ab5-fac8-4dc8-bbb7-9f9ca5b37fc6 Ancestors: Kernel-fbs.739 Move the code to set the owning method of an AdditionalMethodState to the setter away from clients. Add an anti-sharing check. =============== Diff against Kernel-fbs.739 =============== Item was added: + ----- Method: AdditionalMethodState>>method (in category 'accessing') ----- + method + ^method! Item was changed: ----- Method: CompiledMethod>>copyWithTrailerBytes: (in category 'copying') ----- copyWithTrailerBytes: trailer "Testing: (CompiledMethod compiledMethodAt: #copyWithTrailerBytes:) tempNamesPut: 'copy end ' " + | copy end start | - | copy end start penultimateLiteral | start := self initialPC. end := self endPC. copy := trailer createMethod: end - start + 1 class: self class header: self header. 1 to: self numLiterals do: [:i | copy literalAt: i put: (self literalAt: i)]. - (penultimateLiteral := self penultimateLiteral) isMethodProperties ifTrue: - [copy penultimateLiteral: (penultimateLiteral copy - setMethod: copy; - yourself)]. start to: end do: [:i | copy at: i put: (self at: i)]. + copy postCopy. ^copy! Item was changed: ----- Method: CompiledMethod>>penultimateLiteral: (in category 'private') ----- penultimateLiteral: anObject + "Set the penultimate literal of the receiver, which holds either the + receiver's selector or its properties (which will hold the selector). + If it is an AdditionalMethodState set the state's ownership to this + method" - "Answer the penultimate literal of the receiver, which holds either - the receiver's selector or its properties (which will hold the selector)." | pIndex | + (pIndex := self numLiterals - 1) <= 0 ifTrue: + [self error: 'insufficient literals']. + self literalAt: pIndex put: anObject. + anObject isMethodProperties ifTrue: + [(anObject method ~~ nil + and: [anObject method ~~ self + and: [anObject method penultimateLiteral == anObject]]) ifTrue: + [self error: 'a method''s AdditionalMethodState should not be shared']. + anObject setMethod: self. + anObject pragmas do: [:p| p setMethod: self]]! - (pIndex := self numLiterals - 1) > 0 - ifTrue: [self literalAt: pIndex put: anObject] - ifFalse: [self error: 'insufficient literals']! Item was changed: ----- Method: CompiledMethod>>postCopy (in category 'copying') ----- postCopy | penultimateLiteral | (penultimateLiteral := self penultimateLiteral) isMethodProperties ifTrue: + [self penultimateLiteral: penultimateLiteral copy]! - [self penultimateLiteral: (penultimateLiteral copy - setMethod: self; - yourself). - self pragmas do: - [:p| p setMethod: self]]! Item was changed: ----- Method: CompiledMethod>>propertyValueAt:put: (in category 'accessing-pragmas & properties') ----- propertyValueAt: propName put: propValue "Set or add the property with key propName and value propValue. If the receiver does not yet have a method properties create one and replace the selector with it. Otherwise, either relace propValue in the method properties or replace method properties with one containing the new property." | propertiesOrSelector | (propertiesOrSelector := self penultimateLiteral) isMethodProperties ifFalse: + [self penultimateLiteral: (self class methodPropertiesClass - [self penultimateLiteral: ((self class methodPropertiesClass selector: propertiesOrSelector with: (Association key: propName asSymbol + value: propValue)). - value: propValue)) - setMethod: self; - yourself). ^propValue]. (propertiesOrSelector includesProperty: propName) ifTrue: [^propertiesOrSelector at: propName put: propValue]. self penultimateLiteral: (propertiesOrSelector copyWith: (Association + key: propName asSymbol + value: propValue)). - key: propName asSymbol - value: propValue)). ^propValue!

1 0

Daily Commit Log
by commits＠source.squeak.org 24 Feb '13

24 Feb '13

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2013-February/005718.h… Name: Graphics-nice.200 Ancestors: Graphics-eem.199 Bugfix: reading a XBM image with bits specified in decimal would fail to read a '0' byte. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2013-February/005719.h… Name: KernelTests-nice.244 Ancestors: KernelTests-fbs.243 Avoid using ReadWriteStream gratuitously when we just need a WriteStream. =============================================

1 0

[ANN] BioSqueak 0.4
by Hernán Morales Durand 24 Feb '13

24 Feb '13

Hi, Few days ago I created a port of BioSmalltalk for Squeak too. BioSmalltalk is a library for doing Bioinformatics with Smalltalk. This port is labelled "BioSqueak" and I expect to release a version for Windows sometime soon. You can find it in: http://code.google.com/p/biosmalltalk/downloads/list I'm very interested in feedback. Thanks for reading. Hernán -- Hernán Morales Institute of Veterinary Genetics (IGEVET) http://igevet.fcv.unlp.edu.ar National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

3 6

The Trunk: KernelTests-nice.244.mcz
by commits＠source.squeak.org 23 Feb '13

23 Feb '13

Nicolas Cellier uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-nice.244.mcz ==================== Summary ==================== Name: KernelTests-nice.244 Author: nice Time: 23 February 2013, 8:49:05.862 pm UUID: 7b3445ea-0910-4ee4-a6c7-c7305f930764 Ancestors: KernelTests-fbs.243 Avoid using ReadWriteStream gratuitously when we just need a WriteStream. =============== Diff against KernelTests-fbs.243 =============== Item was changed: ----- Method: DateAndTimeEpochTest>>testPrintOn (in category 'testing') ----- testPrintOn + | ref ws | + ref := '1901-01-01T00:00:00+00:00'. + ws := '' writeStream. + aDateAndTime printOn: ws. + self assert: ws contents = ref. + ref := 'a TimeZone(ETZ)'. + ws := '' writeStream. + aTimeZone printOn: ws. + self assert: ws contents = ref! - | cs rw | - cs := ReadStream on: '1901-01-01T00:00:00+00:00'. - rw := ReadWriteStream on: ''. - aDateAndTime printOn: rw. - self assert: rw contents = cs contents. - cs := ReadStream on: 'a TimeZone(ETZ)'. - rw := ReadWriteStream on: ''. - aTimeZone printOn: rw. - self assert: rw contents = cs contents! Item was changed: ----- Method: DateAndTimeLeapTest>>testPrintOn (in category 'testing') ----- testPrintOn + | ref ws | + ref := '2004-02-29T13:33:00+02:00'. + ws := '' writeStream. + aDateAndTime printOn: ws. + self assert: ws contents = ref. + ref := 'a TimeZone(UTC)'. + ws := '' writeStream. + aTimeZone printOn: ws. + self assert: ws contents = ref ! - | cs rw | - cs := ReadStream on: '2004-02-29T13:33:00+02:00'. - rw := ReadWriteStream on: ''. - aDateAndTime printOn: rw. - self assert: rw contents = cs contents. - cs := ReadStream on: 'a TimeZone(UTC)'. - rw := ReadWriteStream on: ''. - aTimeZone printOn: rw. - self assert: rw contents = cs contents ! Item was changed: ----- Method: DateTest>>testPrintOn (in category 'testing') ----- testPrintOn + | ref ws | + ref := '23 January 2004'. + ws := '' writeStream. + aDate printOn: ws. + self assert: ws contents = ref! - | cs rw | - cs := ReadStream on: '23 January 2004'. - rw := ReadWriteStream on: ''. - aDate printOn: rw. - self assert: rw contents = cs contents! Item was changed: ----- Method: DateTest>>testPrintOnFormat (in category 'testing') ----- testPrintOnFormat + | ref ws | + ref :='04*Jan*23'. + ws := '' writeStream. + aDate printOn: ws format: #(3 2 1 $* 2 2). + self assert: ws contents = ref! - | cs rw | - cs := ReadStream on: '04*Jan*23'. - rw := ReadWriteStream on: ''. - aDate printOn: rw format: #(3 2 1 $* 2 2). - self assert: rw contents = cs contents! Item was changed: ----- Method: DateTest>>testStoreOn (in category 'testing') ----- testStoreOn + | ref ws | + ref := '''23 January 2004'' asDate'. + ws := '' writeStream. + aDate storeOn: ws. + self assert: ws contents = ref! - | cs rw | - cs := ReadStream on: '''23 January 2004'' asDate'. - rw := ReadWriteStream on: ''. - aDate storeOn: rw. - self assert: rw contents = cs contents! Item was changed: ----- Method: DurationTest>>testPrintOn (in category 'testing') ----- testPrintOn + | ref ws | + ref := '1:02:03:04.000000005'. + ws := '' writeStream. + aDuration printOn: ws. + self assert: ws contents = ref! - |cs rw | - cs := ReadStream on: '1:02:03:04.000000005'. - rw := ReadWriteStream on: ''. - aDuration printOn: rw. - self assert: rw contents = cs contents.! Item was changed: ----- Method: IntegerTest>>testPrintOnBaseShowRadix (in category 'tests - printing') ----- testPrintOnBaseShowRadix | s | + s := '' writeStream. - s := ReadWriteStream on: ''. 123 printOn: s base: 10 showRadix: false. self assert: (s contents = '123'). + s := '' writeStream. - s := ReadWriteStream on: ''. 123 printOn: s base: 10 showRadix: true. self assert: (s contents = '10r123'). + s := '' writeStream. - s := ReadWriteStream on: ''. 123 printOn: s base: 8 showRadix: false. self assert: (s contents = '173'). + s := '' writeStream. - s := ReadWriteStream on: ''. 123 printOn: s base: 8 showRadix: true. self assert: (s contents = '8r173').! Item was changed: ----- Method: StopwatchTest>>testPrintOn (in category 'testing') ----- testPrintOn + | ref ws | + ref := 'a Stopwatch(suspended:0:00:00:00)'. + ws := '' writeStream. + aStopwatch printOn: ws. + self assert: ws contents = ref! - | cs rw | - cs := ReadStream on: 'a Stopwatch(suspended:0:00:00:00)'. - rw := ReadWriteStream on: ''. - aStopwatch printOn: rw. - self assert: rw contents = cs contents! Item was changed: ----- Method: TimeStampTest>>testPrintOn (in category 'testing') ----- testPrintOn + | ref ws | + ref := '2 January 2004 12:34:56 am'. + ws := '' writeStream. + aTimeStamp printOn: ws. + self assert: ws contents = ref! - | cs rw | - cs := ReadStream on: '2 January 2004 12:34:56 am'. - rw := ReadWriteStream on: ''. - aTimeStamp printOn: rw. - self assert: rw contents = cs contents! Item was changed: ----- Method: TimeStampTest>>testStoreOn (in category 'testing') ----- testStoreOn + | ref ws | + ref := '''2 January 2004 12:34:56 am'' asTimeStamp'. + ws := '' writeStream. + aTimeStamp storeOn: ws. + self assert: ws contents = ref! - | cs rw | - cs := ReadStream on: '''2 January 2004 12:34:56 am'' asTimeStamp'. - rw := ReadWriteStream on: ''. - aTimeStamp storeOn: rw. - self assert: rw contents = cs contents! Item was changed: ----- Method: TimespanTest>>testPrintOn (in category 'testing') ----- testPrintOn + | ref ws | + ref := 'a Timespan(2005-01-01T00:00:00+00:00D7:00:00:00)'. + ws := '' writeStream. + aTimespan printOn: ws. + self assert: ws contents = ref - | cs rw | - cs := ReadStream on: 'a Timespan(2005-01-01T00:00:00+00:00D7:00:00:00)'. - rw := ReadWriteStream on: ''. - aTimespan printOn: rw. - self assert: rw contents = cs contents ! Item was changed: ----- Method: YearMonthWeekTest>>testMonthPrintOn (in category 'testing') ----- testMonthPrintOn + | aMonth ws | + aMonth := Month starting: DateAndTime new duration: 31 days. + ws := '' writeStream. + aMonth printOn: ws. + self assert: ws contents = 'January 1901'.! - | aMonth cs rw | - aMonth := Month starting: DateAndTime new duration: 31 days. - cs := ReadStream on: 'January 1901'. - rw := ReadWriteStream on: ''. - aMonth printOn: rw. - self assert: rw contents = cs contents.! Item was changed: ----- Method: YearMonthWeekTest>>testYearPrintOn (in category 'testing') ----- testYearPrintOn + | aYear ws | + aYear := Year starting: DateAndTime new duration: 365 days. + ws := '' writeStream. + aYear printOn: ws. + self assert: ws contents = 'a Year (1901)'.! - | aYear cs rw | - aYear := Year starting: DateAndTime new duration: 365 days. - cs := ReadStream on: 'a Year (1901)'. - rw := ReadWriteStream on: ''. - aYear printOn: rw. - self assert: rw contents = cs contents.!

1 0

Re: [squeak-dev] The Inbox: Files-kfr.120.mcz
by tim Rowledge 23 Feb '13

23 Feb '13

OK, I'm startled to see this. I'm trying to follow Frank's advice for submitting a small change; a) I looked in the inbox repository and spotted Files-kfr.120.mcz b) saw that it seemed to have some updates to the filedirectory stuff that my change relates to c) merged it into my image d) noted the MC browser displayed '* Files (kfr.120)' as I'd expect e) realised it showed it only in Trunk f) wondered what to do to save my working copy back to the inbox repository And there I got a bit puzzled. So far as I can tell I caused this email by copying the package that was already in inbox to … inbox. I doubt that is the right thing to do and it certainly seems to result in the wrong diff; nothing there about my change. What am I supposed to do here? I not going to try copying the Files package from Trunk to inbox in case it moves the entire thing and screws life up later. On 22-02-2013, at 11:54 PM, commits(a)source.squeak.org wrote: > A new version of Files was added to project The Inbox: > http://source.squeak.org/inbox/Files-kfr.120.mcz > > ==================== Summary ==================== > > Name: Files-kfr.120 > Author: kfr > Time: 12 November 2012, 6:23:28.531 pm > UUID: 4a518133-203f-bd43-9fce-78b8dcfb337d > Ancestors: Files-cmm.119 > > Fix for test failure on Windows > > =============== Diff against Files-cmm.119 =============== > > Item was added: > + ----- Method: DosFileDirectory>>relativeNameIfAbsoluteFor: (in category 'path access') ----- > + relativeNameIfAbsoluteFor: aFileName > + "Answer either the relative name for aFileName, if aFileName names a file in me or > + subdirectories, or aFileName's absolute path if it isn't in me or subdirectories. > + P.S. Ths is what I'd expect relativeNameFor: to do, but it is taken and means > + exactly the opposite, i.e. the absolute path for a relative name." > + | fullNameSize fullName fileNameSize | > + (aFileName isEmpty or: [aFileName first ~= self driveName first]) ifTrue: > + [self error: 'this method expects an absolute filename']. > + fullNameSize := (fullName := self fullName) size. > + fileNameSize := aFileName size. > + ^(aFileName beginsWith: fullName) > + ifTrue: [(fileNameSize = fullNameSize > + or: [fileNameSize - 1 = fullNameSize > + and: [(aFileName at: fileNameSize) = self pathNameDelimiter]]) > + ifTrue: [self class currentDirectoryNickname] > + ifFalse: [aFileName copyFrom: fullNameSize + 2 to: fileNameSize]] > + ifFalse: [aFileName] > + > + "SourceFiles asArray collect: [:sf| FileDirectory default relativeNameIfAbsoluteFor: sf fullName]" > + "FileDirectory default relativeNameIfAbsoluteFor: FileDirectory default fullName" "should be dot" > + "FileDirectory default relativeNameIfAbsoluteFor: FileDirectory default fullName, FileDirectory default slash" "should also be dot"! > > tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Raptus regaliter = Royally screwed

2 3

The Trunk: Graphics-nice.200.mcz
by commits＠source.squeak.org 23 Feb '13

23 Feb '13

Nicolas Cellier uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-nice.200.mcz ==================== Summary ==================== Name: Graphics-nice.200 Author: nice Time: 23 February 2013, 7:29:22.44 pm UUID: eeff1466-d298-4c92-ac73-5f968dfc52c3 Ancestors: Graphics-eem.199 Bugfix: reading a XBM image with bits specified in decimal would fail to read a '0' byte. =============== Diff against Graphics-eem.199 =============== Item was changed: ----- Method: XBMReadWriter>>parseByteValue (in category 'private') ----- parseByteValue "skip over separators and return next bytevalue parsed as a C language number: 0ddd is an octal digit. 0xddd is a hex digit. ddd is decimal." | source mybase | stream skipSeparators. + source := stream upToAnyOf: CharacterSet separators. + source = '0' ifTrue: [^0].. - source := ReadWriteStream on: String new. - [stream atEnd or: [ stream peek isSeparator ]] - whileFalse: [source nextPut: self next asUppercase]. mybase := 10. "Base 10 default" + source := source asUppercase readStream. + (source peekFor: $0) ifTrue: [ - source reset. - (source peek = $0) ifTrue: [ mybase := 8. "Octal or Hex, say its Octal unless overridden." + (source peekFor: $X) ifTrue: [ - source next. - (source peek = $X) ifTrue: [ mybase := 16. "Ah. It's Hex." - source next. ] ]. ^ Integer readFrom: source base: mybase!

1 0

Re: Would anyone care for some noise?
by David Faught 23 Feb '13

23 Feb '13

Here are my notes from the Procedural Textures Croquet/OpenGL/GLSL project. I had this in a personal wiki - it loses something as plain text. I haven't come across the code anywhere, and I fear it was lost a couple of years ago when I had a hard-drive failure. Time to redo it in WebGL anyway! Cheers, Dave ProceduralTextures DaveFaught, 10 August 2009 (created 3 May 2006) tags: Croquet This is an open community project to procedurally build some cool textures for use in the Croquet environment. Plans for this project are still fluid. There are other active projects in the Croquet rendering area that may at some point present code conflicts with this project. We will attempt to make use of the best alternatives available. The inspiration for the actual procedural textures is largely due to Jerzy Karczmarczuk's Clastic tutorial paper, and so this project is intended to be a library of general functions that can be combined in various ways, rather than a finished set of textures. The Plan The current Croquet SDK code base will be used for the OpenGL support and Tweak 2D UI support. The framework will put the project strictly in the local processing arena, outside of Croquet's replication and collaboration model, at least for now. Current Status The current code for this project is in the PublicContribs repository at: http://hedgehog.software.umn.edu:8888/PublicContribs in the Tweak-OpenGL and ((OpenGL-OpenGL packages. It is necessary to manually do "OGLExtManager initialize" after loading the OpenGL-OpenGL package. Andreas also has an updated OpenGL package in the Hedgehog repository that needs to be merged in.)) <- I believe that this can be all replaced by UMN's new OpenGL packages in the Jabberwocky repository. This also depends on a fix for Mantis #6553, which can temporarily be a pretty trivial do-it-yourself kind of thing. Just change VectorColor#asVector4 so that it returns a Vector4 instance instead of a Vector3. The current Tweak-OpenGL package contains: Two, yes count them, two(2) different classes for a basic OpenGL display in Tweak. One is a subclass of CPlayer and is based on a hack of Bert Freudenberg's Croquet Jasmine-based COpenGLPlayer, and the other is a subclass of CPanel and was donated by Andreas Raab. The CPanel version can be launched directly from Morphic, and the CPlayer version needs to be opened in an already-open Tweak environment. There are a few other differences. Two examples of the translated NeHe Tutorial #5 (the first one that has 3D objects), one for each of the basic Tweak OpenGL classes. The beginnings of a GPUinfo query class to display the level of OpenGL support that the video card and drivers supply. Currently this is primarily used to verify GLSL and FramebufferObject support as required by the Wrinkle application. Two versions of the Wrinkle application, the main product of this project. The first version, Wrinkle1, uses a single fragment(pixel) shader program at a time and displays the resulting texture dynamically. The second version, Wrinkle2, is more advanced through combining two dynamic procedural textures and allows saving a snapshot of the result to a .png or .jpg file by use of an OpenGL FramebufferObject. There are short video clips at http://www.youtube.com/watch?v=Eo22Gdi_b9Mand http://www.youtube.com/watch?v=qBHbMxplM5c It has taken about 2 years to get the simple method working (calendar time, not working time :-) A similar page to this one is on the Consortium wiki at http://croquetconsortium.org/index.php/Procedural_Texturing Procedural Code The procedural code is targetted to run on the Graphics Processor Unit (GPU) of the 3D graphics video card, using the OpenGL Shading Language (GLSL or glslang). Tobias Germer supplied the GLSL support for Croquet Jasmine, Joshua Gargus supplied the NullTerminatedStringArray class, and Dave Faught supplied the FrameBufferObject support. The former simple method, used by Wrinkle1, is: - Compile the shaders that will generate the texture. - Enable the shaders. - Render an OpenGL geometry with proper texture coordinates to dynamically display the generated texture. - Interactively pass parameters to the running shaders from the Tweak UI. The current method, used by Wrinkle2, is: - Create an FBO with an attached texture. - Compile the shaders that will generate the texture. - Every render cycle: — Enable the shaders. — Interactively pass parameters to the running shaders from the Tweak UI. — Render the shaders into the FBO with texture coordinates. — Disable the shaders and FBO. — Render an OpenGL geometry to the display with texture coordinates mapped to the FBO's texture in the normal manner. — Allow a snapshot of the FBO texture to be saved to a bitmap file, such as png. To get the texture back from the GPU. This step uses glReadPixels(), which is syncronous. The input x and y values to the procedure are supplied by the OpenGL geometry texture coordinates, and so are each in the interval 0.0 to 1.0. This is different than many other implementations where the resulting bitmap pixel coordinates, for example between 0 and 127, are used. The results of the functions are assumed to be in the interval -1.0 to 1.0, and may be forced to that by using the fract() function. The function results are then generally mapped to an RGB color space, where each of the components are in the interval 0.0 to 1.0. Some of this process is purposely vague in order to promote experimentation, but there are limitations imposed on the process by the GPU hardware. One general procedure might therefore look like this: /* convert the input x and y from a 0.0 : 1.0 interval to a -1.0 : 1.0 interval */ myX = (x * 2.0) - 1.0; myY = (y * 2.0) - 1.0; /* do some interesting function or combination of functions */ myZ = myX * myY; ... /* ensure that the result in in the -1.0 : 1.0 interval */ myZ = fract(myZ); /* convert the result to a 0.0 : 1.0 interval */ myZ = (myZ + 1.0) / 2.0; /* map the result into an RGB color space */ color = mix (cAqua, cGold, myZ); UI Design There is some dynamic interaction between the Tweak UI (sliders and buttons) and the compiled shader programs, although the UI is not expected to ever get to the level that is achieved by the ArtOfIllusion Texture Editor. There will have to be a tradeoff between the code restrictions of smaller GPUs and the desire for procedural function flexibility. The desire to accomodate smaller GPUs pretty much rules out the AOI TexEd toolkit approach, so a more fixed stack with sliders for each stage would be appropriate, and by definition more limited. How much of a stack can be accommodated or is desirable? There are a few different classes of functions that may feed this, for example ones that take a single parameter z=f(x) and those that take two parameters z=f(x,y). The fact that they (all?) produce a single output means that they cannot simply be linked in series. Tweak Considerations (orig. from the mailing list) Yes, I too have had problems when switching back out of a Tweak Project to Morphic, and I have for the moment elected not to deep dive into assisting with the debugging in this area. The result is that I generally don't use a Tweak Project at all. Note that there is an environmental difference in opening a "Tweak Project" and opening a "Tweak Project Window" from the open menu. I have not had the same problems with a Tweak Project Window, and in fact it generally seems to cooperate with Morphic more cleanly. It is actually much easier to develop and test code using a Tweak Project Window because of this cleaner interaction with Morphic. So the way I go about developing with the OpenGL player in Tweak is to make my code changes with the Morphic class browser and other nice Morphic code tools, and test out the code with a Tweak Project Window (which can remain open or minimized while going back to the Morphic browser for more changes). When I think the code is relatively clean, then I save the image. Andreas Raab has provided an alternative OpenGL Tweak panel which can be launched directly from Squeak. This panel may be a better alternative for some projects. Background Here are a few resources for general procedural texturing: http://users.info.unicaen.fr/~karczma/Work/Clastic_distr/clastic.html http://mrl.nyu.edu/~perlin/ http://graphics.cs.uiuc.edu/~jch/papers/ http://conal.net/Pan/ "Texturing and Modeling, A Procedural Approach" by Ebert, et al. is an excellent book on this subject. Also, check out the procedural texture editor in the Open Source 3D modeler Art Of Illusion. You can use the VRML export feature of AOI and select "Create Image Files for Textures" to export 2D procedural textures that can be imported to Croquet with the VRMLImporter. Take a look at the AOI tutorial, Procedural Texture and Material Editor, Chapter 9, "Example Textures" for an idea what the GUI looks like. Only AOI's textures can be exported to VRML, and end up being both textures and materials in Croquet. In AOI, materials are more like OpenGL shader programs, and cannot be expressed in VRML. http://www.artofillusion.org http://www.artofillusion.org/docs/texedtut/chapter9 Besides Clastic and the ArtOfIllusion Texture Editor, a couple of other free tools for creating procedural textures are .werkkzeug 3 TE, and mental mill Artist Edition that comes with the NVidia's FX Composer 2 beta 4. http://www.werkkzeug.com/ http://developer.nvidia.com/object/fx_composer_home.html http://www.mentalimages.com/2_4_mentalmill/index.html Michael Kleiber did some nice extensions to Croquet Jasmine to use OGL shader programs for his thesis. http://www.kleibi.com/index?page=univ Other shader languages that might be considered at some point are Stanford's BrookGPU or UW's Sh. http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/ http://www.graphics.stanford.edu/~hanrahan/talks/gp2/walk001.html http://graphics.stanford.edu/projects/brookgpu/ http://merrimac.stanford.edu/ http://merrimac.stanford.edu/brook/ http://libsh.org/ http://www.shadertech.com http://developer.3dlabs.com http://conal.net/Vertigo/ In order to have the GPU run the code for doing procedural textures, a higher level of GPU functionality is required than that needed to run normal Croquet. A recommended minimum GPU chipset is the NVidia GeforceFX series, or the ATI Radeon 9500. http://developer.nvidia.com/object/General_FAQ.html#s2 http://www.ati.com/developer/atiopengl.pdf More recent NVidia (Forceware 60 or newer) and ATI (Catalyst 4.5 or newer) drivers include the GLSL compiler within the drivers for Windows and Linux. Apple takes a much larger role in writing drivers for OS X (the Windows and Linux drivers are substantially the same code base, at least for NVIDIA), but finally did finish their glslang support. http://www.opengl.org/documentation/oglsl.html http://www.3dshaders.com http://www.lighthouse3d.com/opengl/glsl/ The new OpenGL FrameBuffer object is a new extension that is platform-independent and is more flexible than PBuffers, but just became generally available in the NVidia Forceware 75 drivers released in June 2005. Not sure exactly which release of ATI drivers contains FrameBuffer object support, but there is support in the October 2005 ATI Radeon SDK. http://www.opengl.org/documentation/extensions/EXT_framebuffer_object.txt http://download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/Open… http://www.nvnews.net/vbulletin/showthread.php?t=49157 http://www.ati.com/developer/ The class comment of OGLExtManager explains what needs to be done to add new OpenGL extensions. OGLExtManager does not support platform-specific extensions. Some related code Here is some simple Croquet/Squeak code to generate a one-shot texture and display it. Based on example 1 in Clastic (see above). Does not require any special graphics support beyond running Squeak. This gives an idea of where we're headed, but this is not the method we will use. Define the class AFirstTry as a subclass of Form, and then enter this method in AFirstTry: plot1 "plot a function" " (AFirstTry extent: 128@128 depth: 32) plot1 asMorph openInWorld " | xmin xmax xincr ymin ymax yincr x y z scaled | xmin := -1. xmax := 1. xincr := (xmax - xmin) / (self width). ymin := -1. ymax := 1. yincr := (ymax - ymin) / (self height). scaled := 0.1. 1 to: self width do: [ :xpixel | x := (xmin + (xincr * xpixel)) / scaled. 1 to: self height do: [ :ypixel | y := (ymin + (yincr * ypixel)) / scaled. " the main mapping function " z := ((x sin + y) sin + x) sin - (((y sin + x) sin + y) sin). self colorAt: xpixel@ypixel put: (Color r: z g: 0 b: (1-z)). ]. ]. "xfun1 (V2 x y) = sin(x+sin(y+sin x)) - sin(y+sin(x+sin y)) xfun2 (V2 x y) = floor(sin(x+sin(y+sin x))) - floor(sin(y+sin(x+sin y))) " To execute the code, highlight the code in the comment and DoIt. NVidia GPU Shader Capabilities The table uses DirectX nomenclature (i.e., Vertex Shader and Pixel Shader version numbers). For GeForce FX and newer GPUs that are capable of flow control, the static instruction count represents the number of instructions in a program as it is compiled. The dynamic instruction count represents the number of instructions actually executed. In practice, the dynamic count can be vastly higher than the static count due to looping and subroutine calls. GPU DX Vertex Shading Capability Pixel Shading Capability GeForce FX 2.0+ 256 static instructions 512 static instructions 65,535 dynamic instructions 512 dynamic instructions GeForce 6 Series 3.0 512 static instructions 2,048 static instructions 65,535 dynamic instructions 65,535 dynamic instructions A personal note from daf: Using the GPU to do the processing for procedural textures through vertex and pixel/fragment shaders is a current and exciting area of experimentation for many developers inside and outside of the Croquet community. While I am very interested in exploring this area, I am also a bit disappointed that I have to code the actual shader programs in a variant of C, instead of Smalltalk. Maybe someday this can be remedied by an industrious Croquet developer as an embedded language extension. Look at PyGPU, Vertigo or UW's Sh in the links above for ideas.

2 1

Daily Commit Log
by commits＠source.squeak.org 23 Feb '13

23 Feb '13

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2013-February/005717.h… Name: Balloon-dtl.20 Ancestors: Balloon-egp.19 Check for sending ShortRunArray class>>swapRuns and ShortIntegerArray class>>swapShortObjects is needed only at image startup time, so use startUp: resuming rather than startUp. Categorize in system startup. =============================================

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
23
Older →

Jump to page: