Squeak-dev June 2014

squeak-dev@lists.squeakfoundation.org

41 participants
191 discussions

can't start Squeak on one Ubuntu system anymore
by Chris Muller 05 Jun '14

05 Jun '14

On one machine only, I'm getting an error when I try to start any image: -------------- could not find display driver vm-display-X11; either: - check that /usr/local/lib/squeak/4.0-2776//vm-display-X11.so exists, or - use the '-plugins <path>' option to tell me where it is, or - remove DISPLAY from your environment. --------------- Of course, none of those suggestions worked, and I have been running Squeak for a long time on this box with no problems. The same image starts fine on other machines, so I'm guessing something has gotten hosed up with my Ubuntu 14.04 installation on this one box? Any suggestions are appreciated. Thanks!

9 22

Fwd: (FileDirectory default directoryContentsFor: '') explore.
by Frank Shearar 04 Jun '14

04 Jun '14

Hi Folks, Ken Dickey and the Cuis team found some... unexpected behaviour in FileDirectory, and just as importantly, have found a fix. Please take a look at the change, and if we're OK with it, some kind soul can push it to Trunk :) There's at least one bug, in that Juan Vuletich found that on Windows opening a FileList causes an infinite recursion. Thanks, frank ---------- Forwarded message ---------- From: Ken Dickey <Ken.Dickey(a)whidbey.com> Date: 3 June 2014 03:57 Subject: (FileDirectory default directoryContentsFor: '') explore. To: Frank Shearar <frank.shearar(a)gmail.com> Hi Frank, In case you missed the Cuis thread on this: Attached is my suggested fix for the schizophrenic behavior of (FileDirectory default directoryContentsFor: '') explore. which on Linux gives directory entries with file names and info from my home directory but with directory info from the image launch directory. This is the same behavior on Cuis current and Squeak 4.5. I am not on the Squeak developers' list, but I suspect you will do the proper thing here. ;^) Cheers, -KenD

2 3

Meet Swiff
by Edgar J. De Cleene 04 Jun '14

04 Jun '14

https://www.youtube.com/watch?v=l62x8Oq_QP4

6 5

[REMINDER] CFP - IWST 2014 - Deadline June, 15
by jannik laval 03 Jun '14

03 Jun '14

[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST14 — International Workshop on Smalltalk Technologies Cambridge, England; August 19, 2014 http://www.esug.org/Conferences/2014/IWST14 ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- Submission deadline: June 15, 2014 Notification deadline: July 15, 2014 Workshop : August 19, 2014 All accepted papers will be published in ACM DL (To be confirmed) ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: Aspect-oriented programming, Design patterns, Experience reports, Frameworks, Implementation, new dialects or languages implemented in Smalltalk, Interaction with other languages, Meta-programming and Meta-modeling, Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank Lam Research Corporation for its financial contribution that makes it possible a price for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://www.easychair.org/conferences/?conf=iwst2014 ------------------- Program chairs ------------------- Alain Plantec (UMR 6265 Lab-STICC, University of Brest, France) Jannik Laval (Ecole des Mines de Douai, France) -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

2 3

Re: [squeak-dev] The Trunk: Kernel-cmm.855.mcz
by Chris Muller 03 Jun '14

03 Jun '14

I wouldn't be surprised if there wasn't more low-hanging fruit like this. DateAndTime class>>#now is purposefully "slow" to assure DateAndTime now < DateAndTime now. Dave, I'm not sure whether you preserved that behavior, if not it might not be a very fair benchmark comparison.. On Mon, Jun 2, 2014 at 9:53 AM, <commits(a)source.squeak.org> wrote: > Chris Muller uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-cmm.855.mcz > > ==================== Summary ==================== > > Name: Kernel-cmm.855 > Author: cmm > Time: 2 June 2014, 9:53:24.175 am > UUID: 478f3548-e587-4dd9-8962-d6ba6dbe2035 > Ancestors: Kernel-eem.854 > > - A simple fix for an 8X performance improvement in DateAndTime>>#< as reported by LXTestDateAndTimePerformance. > > =============== Diff against Kernel-eem.854 =============== > > Item was changed: > ----- Method: DateAndTime>>< (in category 'ansi protocol') ----- > + < comparand > - < comparand > "comparand conforms to protocol DateAndTime, > or can be converted into something that conforms." > + | lvalue rvalue comparandAsDateAndTime | > - | lticks rticks comparandAsDateAndTime | > comparandAsDateAndTime := comparand asDateAndTime. > offset = comparandAsDateAndTime offset > + ifTrue: > + [ lvalue := self. > + rvalue := comparandAsDateAndTime ] > + ifFalse: > + [ lvalue := self asUTC. > + rvalue := comparandAsDateAndTime asUTC ]. > + ^ lvalue julianDayNumber < rvalue julianDayNumber or: > + [ lvalue julianDayNumber > rvalue julianDayNumber > + ifTrue: [ false ] > + ifFalse: > + [ lvalue secondsSinceMidnight < rvalue secondsSinceMidnight or: > + [ lvalue secondsSinceMidnight > rvalue secondsSinceMidnight > + ifTrue: [ false ] > + ifFalse: [ lvalue nanoSecond < rvalue nanoSecond ] ] ] ]! > - ifTrue: [lticks := self ticks. > - rticks := comparandAsDateAndTime ticks] > - ifFalse: [lticks := self asUTC ticks. > - rticks := comparandAsDateAndTime asUTC ticks]. > - ^ lticks first < rticks first > - or: [lticks first > rticks first > - ifTrue: [false] > - ifFalse: [lticks second < rticks second > - or: [lticks second > rticks second > - ifTrue: [false] > - ifFalse: [lticks third < rticks third]]]] > - ! > > Item was changed: > ----- Method: DateAndTime>>= (in category 'ansi protocol') ----- > = aDateAndTimeOrTimeStamp > self == aDateAndTimeOrTimeStamp ifTrue: [ ^ true ]. > ((aDateAndTimeOrTimeStamp isKindOf: self class) > or: [aDateAndTimeOrTimeStamp isKindOf: DateAndTime orOf: TimeStamp]) > ifFalse: [ ^ false ]. > ^ self offset = aDateAndTimeOrTimeStamp offset > ifTrue: [ self hasEqualTicks: aDateAndTimeOrTimeStamp ] > + ifFalse: [ self asUTC hasEqualTicks: aDateAndTimeOrTimeStamp asUTC ]! > - ifFalse: [ self asUTC ticks = aDateAndTimeOrTimeStamp asUTC ticks ]! > >

2 2

Daily Commit Log
by commits＠source.squeak.org 03 Jun '14

03 Jun '14

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2014-June/007072.html Name: Kernel-cmm.855 Ancestors: Kernel-eem.854 - A simple fix for an 8X performance improvement in DateAndTime>>#< as reported by LXTestDateAndTimePerformance. =============================================

1 0

Re: [squeak-dev] The Trunk: Kernel-eem.852.mcz
by Nicolas Cellier 02 Jun '14

02 Jun '14

2014-05-19 20:50 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.852.mcz > > ==================== Summary ==================== > > Name: Kernel-eem.852 > Author: eem > Time: 19 May 2014, 11:49:49.951 am > UUID: 6d0add2f-b4ae-4e90-9b0d-7c938c4f4c1c > Ancestors: Kernel-eem.851 > > Change scanning methods in InstructionStream and > CompiledMethod to double-dispatch through > CompiledMethod>>#encoderClass to provide pluggable > multiple bytecode set support. The sign of a method's > header chooses which of two bytecode sets are in effect, > choosing between PrimaryBytecodeSetEncoderClass > (header >= 0), and SecondaryBytecodeSetEncoderClass > (header <= 0). > > =============== Diff against Kernel-eem.851 =============== > > Item was changed: > ----- Method: CompiledMethod > class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive: (in > category 'instance creation') ----- > newBytes: numberOfBytes trailerBytes: trailer nArgs: nArgs nTemps: > nTemps nStack: stackSize nLits: nLits primitive: primitiveIndex > "Answer an instance of me. The header is specified by the message > + arguments. The remaining parts are not as yet determined." > - arguments. The remaining parts are not as yet determined." > | largeBit primBits | > nTemps > 63 ifTrue: > [^ self error: 'Cannot compile -- too many temporary > variables']. > nLits > 255 ifTrue: > + [^ self error: 'Cannot compile -- too many literals']. > - [^ self error: 'Cannot compile -- too many literals > variables']. > largeBit := (nTemps + stackSize) > SmallFrame ifTrue: [1] ifFalse: > [0]. > primBits := primitiveIndex <= 16r1FF > ifTrue: [primitiveIndex] > ifFalse: ["For now the high bit of primitive no. is in the > 29th bit of header" > primitiveIndex > 16r3FF ifTrue: [self > error: 'prim num too large']. > (primitiveIndex bitAnd: 16r1FF) + > ((primitiveIndex bitAnd: 16r200) bitShift: 19)]. > > ^trailer > createMethod: numberOfBytes > class: self > header: (nArgs bitShift: 24) + > (nTemps bitShift: 18) + > (largeBit bitShift: 17) + > (nLits bitShift: 9) + > primBits! > > Item was changed: > ----- Method: CompiledMethod > class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive:flag: (in > category 'instance creation') ----- > newBytes: numberOfBytes trailerBytes: trailer nArgs: nArgs nTemps: > nTemps nStack: stackSize nLits: nLits primitive: primitiveIndex flag: flag > "Answer an instance of me. The header is specified by the message > + arguments. The remaining parts are not as yet determined." > - arguments. The remaining parts are not as yet determined." > | largeBit primBits flagBit | > nTemps > 63 ifTrue: > [^ self error: 'Cannot compile -- too many temporary > variables']. > nLits > 255 ifTrue: > + [^ self error: 'Cannot compile -- too many literals']. > - [^ self error: 'Cannot compile -- too many literals > variables']. > largeBit := (nTemps + stackSize) > SmallFrame ifTrue: [1] ifFalse: > [0]. > > "For now the high bit of the primitive no. is in a high bit of the > header" > primBits := (primitiveIndex bitAnd: 16r1FF) + ((primitiveIndex > bitAnd: 16r200) bitShift: 19). > > flagBit := flag ifTrue: [ 1 ] ifFalse: [ 0 ]. > > - "Copy the source code trailer to the end" > ^trailer > createMethod: numberOfBytes > class: self > header: (nArgs bitShift: 24) + > (nTemps bitShift: 18) + > (largeBit bitShift: 17) + > (nLits bitShift: 9) + > primBits + > (flagBit bitShift: 29)! > > Item was changed: > ----- Method: CompiledMethod>>containsBlockClosures (in category > 'closures') ----- > containsBlockClosures > + ^self scanner scanFor: self encoderClass createClosureScanBlock! > - ^ self scanner scanFor: [ :bc | bc = 143 "push closure bytecode" ]! > > Item was changed: > ----- Method: CompiledMethod>>header (in category 'literals') ----- > header > "Answer the word containing the information about the form of the > + receiver and the form of the context needed to run the receiver. > + There are two different formats, selected by the sign bit. These > are > - receiver and the form of the context needed to run the receiver." > > + Original Squeak V3: > + 30:sign:0 29:flag 28:prim (high bit) 27-24:numArgs > 23-18:numTemps 17:largeFrameFlag 16-9:numLits 8-0:prim (low 9 bits) > + > + Alternate Bytecode Set > + 30:sign:1 29-28:accessModifier 27-24:numArgs > 23-18:numTemps 17:largeFrameFlag 16:hasPrimitive 15-0:numLits > + > + i.e. the Alternate Bytecode Set expands the number of literals to > 65535 by assuming a CallPrimitive bytecode." > + > ^self objectAt: 1! > > Item was changed: > ----- Method: CompiledMethod>>isBlueBookCompiled (in category 'testing') > ----- > isBlueBookCompiled > + "Answer whether the receiver was compiled using the old > Smalltalk-80 blocks > + compiler. This is used to help DebuggerMethodMap choose which > mechanisms > + to use to inspect (debug) activations of the receiver." > - "Answer whether the receiver was compiled using the closure > compiler. > - This is used to help DebuggerMethodMap choose which mechanisms to > - use to inspect activations of the receiver. > - This method answers false negatives in that it only identifies > methods > - that create old BlockClosures or use the new BlockClosure > bytecodes. > - It cannot tell if a method which uses neither the old nor the new > block > - bytecodes is compiled with the blue-book compiler or the new > compiler. > - But since methods that don't create blocks have essentially the > same > - code when compiled with either compiler this makes little > difference." > > + ^self encoderClass supportsClosures not! > - ^((InstructionStream on: self) scanFor: > - [:instr | > - (instr >= 138 and: [instr <= 143]) ifTrue: [^false]. > - instr = 200]) > - or: [(self hasLiteral: #blockCopy:) > - and: [self messages includes: #blockCopy:]]! > > Item was changed: > ----- Method: CompiledMethod>>isClosureCompiled (in category 'testing') > ----- > isClosureCompiled > "Answer whether the receiver was compiled using the closure > compiler. > This is used to help DebuggerMethodMap choose which mechanisms to > + use to inspect (debug) activations of the receiver." > - use to inspect activations of the receiver. > - This method answers false negatives in that it only identifies > methods > - that create new BlockClosures or use the new BlockClosure > bytecodes. > - But since methods that don't create blocks have essentially the > same > - code when compiled with either compiler this makes little > difference." > > + ^self encoderClass supportsClosures! > - ^((InstructionStream on: self) scanFor: [:instr | instr >= 138 > and: [instr <= 143]]) > - or: [(self hasLiteral: #closureCopy:copiedValues:) > - and: [self messages includes: > #closureCopy:copiedValues:]]! > > Note that this change makes ClosureCompilerTest>>#testSourceRangeAccessForBlueBookInjectInto fail But the test itself is for pre-closure byteCodes (using EncoderForV3, or so called Blue Book blocks with blockCopy byteCode) In my image, I have no blue book CompiledMethod, if I believe this snippet: CompiledMethod allInstances count: [:e | ((InstructionStream on: e) scanFor: [:instr | instr = 200]) or: [(e hasLiteral: #blockCopy:) and: [e messages includes: #blockCopy:]]]. Do we really want to support this old thing? Or shall we remove this test and support of previous bytecode set (EncoderForV3)? Or is there a danger that some old ImageSegment bring some zombies back? Or are these things still usefull for some boostrap voodoo? Currently, debugging such compiled method fails with sticky debuggers... Some bytes are rotting, we lack tests, a single person is active/fluent on this part, so dropping support is a reasonnable option.

1 0

The Trunk: Kernel-cmm.855.mcz
by commits＠source.squeak.org 02 Jun '14

02 Jun '14

Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.855.mcz ==================== Summary ==================== Name: Kernel-cmm.855 Author: cmm Time: 2 June 2014, 9:53:24.175 am UUID: 478f3548-e587-4dd9-8962-d6ba6dbe2035 Ancestors: Kernel-eem.854 - A simple fix for an 8X performance improvement in DateAndTime>>#< as reported by LXTestDateAndTimePerformance. =============== Diff against Kernel-eem.854 =============== Item was changed: ----- Method: DateAndTime>>< (in category 'ansi protocol') ----- + < comparand - < comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms." + | lvalue rvalue comparandAsDateAndTime | - | lticks rticks comparandAsDateAndTime | comparandAsDateAndTime := comparand asDateAndTime. offset = comparandAsDateAndTime offset + ifTrue: + [ lvalue := self. + rvalue := comparandAsDateAndTime ] + ifFalse: + [ lvalue := self asUTC. + rvalue := comparandAsDateAndTime asUTC ]. + ^ lvalue julianDayNumber < rvalue julianDayNumber or: + [ lvalue julianDayNumber > rvalue julianDayNumber + ifTrue: [ false ] + ifFalse: + [ lvalue secondsSinceMidnight < rvalue secondsSinceMidnight or: + [ lvalue secondsSinceMidnight > rvalue secondsSinceMidnight + ifTrue: [ false ] + ifFalse: [ lvalue nanoSecond < rvalue nanoSecond ] ] ] ]! - ifTrue: [lticks := self ticks. - rticks := comparandAsDateAndTime ticks] - ifFalse: [lticks := self asUTC ticks. - rticks := comparandAsDateAndTime asUTC ticks]. - ^ lticks first < rticks first - or: [lticks first > rticks first - ifTrue: [false] - ifFalse: [lticks second < rticks second - or: [lticks second > rticks second - ifTrue: [false] - ifFalse: [lticks third < rticks third]]]] - ! Item was changed: ----- Method: DateAndTime>>= (in category 'ansi protocol') ----- = aDateAndTimeOrTimeStamp self == aDateAndTimeOrTimeStamp ifTrue: [ ^ true ]. ((aDateAndTimeOrTimeStamp isKindOf: self class) or: [aDateAndTimeOrTimeStamp isKindOf: DateAndTime orOf: TimeStamp]) ifFalse: [ ^ false ]. ^ self offset = aDateAndTimeOrTimeStamp offset ifTrue: [ self hasEqualTicks: aDateAndTimeOrTimeStamp ] + ifFalse: [ self asUTC hasEqualTicks: aDateAndTimeOrTimeStamp asUTC ]! - ifFalse: [ self asUTC ticks = aDateAndTimeOrTimeStamp asUTC ticks ]!

1 0

SMServer beta update
by Chris Cunnington 02 Jun '14

02 Jun '14

I'm in the weeds at the moment, so there's nothing new to see. Next week I expect to have some forms working. Chris

2 2

FunSqueak 4.6 in process feedback
by Edgar De Cleene 02 Jun '14

02 Jun '14

Hello folks. I on #squeak IRC inside the upcoming image. So I wish feedback, love letters and death threats. Today I stay about one more hour, but tell here when I listen you. Amigos de habla hispana, recordar que existe ³La hora Latina² Edgar

1 0

Jump to page: