From lewis at mail.msen.com Tue Sep 1 00:21:46 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Tue Sep 1 00:21:49 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: <20150901002146.GA8787@shell.msen.com> I would ask that someone please measure the real-world performance benefit of adding these (or any other) numbered primitives. Maybe it's a lot, maybe it's not, but when in doubt leave it out. Dave On Mon, Aug 31, 2015 at 10:25:59AM -0700, Eliot Miranda wrote: > Hi Chrises, > > my vote would be to write these as 12 numbered primitives, (2,4 & 8 > bytes) * (at: & at:put:) * (big & little endian) because they can be > performance critical and implementing them like this means the maximum > efficiency in both 32-bit and 64-bit Spur, plus the possibility of the JIT > implementing the primitives. > > On Sun, Aug 30, 2015 at 10:01 PM, Chris Cunningham > wrote: > > > Hi Chris, > > > > I'm all for having the fastest that in the image that works. If you could > > make your version handle endianess, then I'm all for including it (at least > > in the 3 variants that are faster). My first use for this (interface for > > KAFKA) apparently requires bigEndianess, so I really want that supported. > > > > It might be best to keep my naming, though - it follows the name pattern > > that is already in the class. Or will yours also support 128? > > > > -cbc > > > > On Sun, Aug 30, 2015 at 2:38 PM, Chris Muller wrote: > > > >> Hi Chris, I think these methods belong in the image with the fastest > >> implementation we can do. > >> > >> I implemented 64-bit unsigned access for Ma Serializer back in 2005. > >> I modeled my implementation after Andreas' original approach which > >> tries to avoid LI arithmetic. I was curious whether your > >> implementations would be faster, because if they are then it could > >> benefit Magma. After loading "Ma Serializer" 1.5 (or head) into a > >> trunk image, I used the following script to take comparison > >> measurements: > >> > >> | smallN largeN maBa cbBa | smallN := ((2 raisedTo: 13) to: (2 > >> raisedTo: 14)) atRandom. > >> largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. > >> maBa := ByteArray new: 8. > >> cbBa := ByteArray new: 8. > >> maBa maUint: 64 at: 0 put: largeN. > >> cbBa unsignedLong64At: 1 put: largeN bigEndian: false. > >> self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 > >> bigEndian: false). > >> { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN > >> bigEndian: false] bench. > >> 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. > >> 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false. ] > >> bench. > >> 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. > >> 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN > >> bigEndian: false] bench. > >> 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. > >> 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false ] > >> bench. > >> 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. > >> } > >> > >> Here are the results: > >> > >> 'cbc smallN write'->'3,110,000 per second. 322 nanoseconds per run.' . > >> 'ma smallN write'->'4,770,000 per second. 210 nanoseconds per run.' . > >> 'cbc smallN access'->'4,300,000 per second. 233 nanoseconds per run.' . > >> 'ma smallN access'->'16,400,000 per second. 60.9 nanoseconds per run.' . > >> 'cbc largeN write'->'907,000 per second. 1.1 microseconds per run.' . > >> 'ma largeN write'->'6,620,000 per second. 151 nanoseconds per run.' . > >> 'cbc largeN access'->'1,900,000 per second. 527 nanoseconds per run.' . > >> 'ma largeN access'->'1,020,000 per second. 982 nanoseconds per run.' > >> > >> It looks like your 64-bit access is 86% faster for accessing the > >> high-end of the 64-bit range, but slower in the other 3 metrics. > >> Noticeably, it was only 14% as fast for writing the high-end of the > >> 64-bit range, and similarly as much slower for small-number access.. > >> > >> > >> On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham > >> wrote: > >> > Hi. > >> > > >> > I've committed a change to the inbox with changes to allow > >> getting/putting > >> > 64bit values to ByteArrays (similar to 32 and 16 bit accessors). Could > >> this > >> > be added to trunk? > >> > > >> > Also, first time I used the selective commit function - very nice! the > >> > changes I didn't want committed didn't, in fact, get commited. Just the > >> > desirable bits! > >> > > >> > -cbc > >> > > >> > > >> > > >> > >> > > > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot > From avalloud at smalltalk.comcastbiz.net Tue Sep 1 00:52:52 2015 From: avalloud at smalltalk.comcastbiz.net (Andres Valloud) Date: Tue Sep 1 00:52:56 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: <55E4F6E4.3070407@smalltalk.comcastbiz.net> FWIW... IMO it's better to enable access to the relevant compiler intrinsic with platform specific macros, rather than implementing instructions such as Intel's BSWAP or MOVBE by hand. In HPS, isolating endianness concerns from the large integer arithmetic primitives with such macros enabled 25-40% faster performance on big endian platforms. Just as importantly, the intrinsic approach takes significantly less code to implement. On 8/31/15 10:25 , Eliot Miranda wrote: > Hi Chrises, > > my vote would be to write these as 12 numbered primitives, (2,4 & 8 > bytes) * (at: & at:put:) * (big & little endian) because they can be > performance critical and implementing them like this means the maximum > efficiency in both 32-bit and 64-bit Spur, plus the possibility of the > JIT implementing the primitives. > > On Sun, Aug 30, 2015 at 10:01 PM, Chris Cunningham > > wrote: > > Hi Chris, > > I'm all for having the fastest that in the image that works. If you > could make your version handle endianess, then I'm all for including > it (at least in the 3 variants that are faster). My first use for > this (interface for KAFKA) apparently requires bigEndianess, so I > really want that supported. > > It might be best to keep my naming, though - it follows the name > pattern that is already in the class. Or will yours also support 128? > > -cbc > > On Sun, Aug 30, 2015 at 2:38 PM, Chris Muller > wrote: > > Hi Chris, I think these methods belong in the image with the fastest > implementation we can do. > > I implemented 64-bit unsigned access for Ma Serializer back in 2005. > I modeled my implementation after Andreas' original approach which > tries to avoid LI arithmetic. I was curious whether your > implementations would be faster, because if they are then it could > benefit Magma. After loading "Ma Serializer" 1.5 (or head) into a > trunk image, I used the following script to take comparison > measurements: > > | smallN largeN maBa cbBa | smallN := ((2 raisedTo: 13) to: (2 > raisedTo: 14)) atRandom. > largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. > maBa := ByteArray new: 8. > cbBa := ByteArray new: 8. > maBa maUint: 64 at: 0 put: largeN. > cbBa unsignedLong64At: 1 put: largeN bigEndian: false. > self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 > bigEndian: false). > { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN > bigEndian: false] bench. > 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. > 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: > false. ] bench. > 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. > 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN > bigEndian: false] bench. > 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. > 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: > false ] bench. > 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. > } > > Here are the results: > > 'cbc smallN write'->'3,110,000 per second. 322 nanoseconds per > run.' . > 'ma smallN write'->'4,770,000 per second. 210 nanoseconds per > run.' . > 'cbc smallN access'->'4,300,000 per second. 233 nanoseconds per > run.' . > 'ma smallN access'->'16,400,000 per second. 60.9 nanoseconds > per run.' . > 'cbc largeN write'->'907,000 per second. 1.1 microseconds per > run.' . > 'ma largeN write'->'6,620,000 per second. 151 nanoseconds per > run.' . > 'cbc largeN access'->'1,900,000 per second. 527 nanoseconds per > run.' . > 'ma largeN access'->'1,020,000 per second. 982 nanoseconds per > run.' > > It looks like your 64-bit access is 86% faster for accessing the > high-end of the 64-bit range, but slower in the other 3 metrics. > Noticeably, it was only 14% as fast for writing the high-end of the > 64-bit range, and similarly as much slower for small-number access.. > > > On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham > > wrote: > > Hi. > > > > I've committed a change to the inbox with changes to allow > getting/putting > > 64bit values to ByteArrays (similar to 32 and 16 bit > accessors). Could this > > be added to trunk? > > > > Also, first time I used the selective commit function - very > nice! the > > changes I didn't want committed didn't, in fact, get > commited. Just the > > desirable bits! > > > > -cbc > > > > > > > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot > > > From commits at source.squeak.org Tue Sep 1 03:34:23 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 03:34:23 2015 Subject: [squeak-dev] The Inbox: Collections-cbc.652.mcz Message-ID: A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-cbc.652.mcz ==================== Summary ==================== Name: Collections-cbc.652 Author: cbc Time: 31 August 2015, 8:32:50.179 pm UUID: 88079716-328d-4a41-8838-595e6782882c Ancestors: Collections-cbc.651 #unsignedLong64At:put:bigEndian: on average fast. =============== Diff against Collections-cbc.651 =============== Item was changed: ----- Method: ByteArray>>unsignedLong64At:put:bigEndian: (in category 'platform independent access') ----- + unsignedLong64At: index put: value bigEndian: aBool + "Minimize largeInteger arithmetic" + | ix | + aBool ifFalse: [ + ix := index - 1. + 1 to: 8 do: [:pos| + self at: ix + pos put: (value digitAt: pos) - unsignedLong64At: index put: val bigEndian: aBool - aBool - ifTrue: [ - self unsignedLongAt: index put: (val bitShift: -32) bigEndian: true. - self unsignedLongAt: index+4 put: (val bitAnd: 16rFFFFFFFF) bigEndian: true. - ] - ifFalse: [ - self unsignedLongAt: index put: (val bitAnd: 16rFFFFFFFF) bigEndian: false. - self unsignedLongAt: index+4 put: (val bitShift: -32) bigEndian: false. ]. + ] ifTrue: [ + ix := index + 8. + 1 to: 8 do: [:pos| + self at: ix - pos put: (value digitAt: pos) + ]. + ]. + ^value - ^val ! From casey.obrien.r at gmail.com Tue Sep 1 08:19:25 2015 From: casey.obrien.r at gmail.com (Casey Ransberger) Date: Tue Sep 1 08:19:28 2015 Subject: [squeak-dev] phantomfive? Message-ID: Does anyone here happen to post things places as phantomfive? Saw a post on /. that I was happy to see, thought I'd reach out. Sorry everyone who isn't that person for the noise! Cheers, --Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150901/79a6a9b3/attachment.htm From commits at source.squeak.org Tue Sep 1 12:39:50 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 12:39:52 2015 Subject: [squeak-dev] The Trunk: Graphics-topa.316.mcz Message-ID: Tobias Pape uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-topa.316.mcz ==================== Summary ==================== Name: Graphics-topa.316 Author: topa Time: 1 September 2015, 2:39:12.844 pm UUID: e14b128c-1aa2-4132-8fb2-b704a219c17e Ancestors: Graphics-mt.315 Move TextPrinter from ST80 to Graphics, as Morphic now also uses it. TextPrinter uses ST80's Paragraph but already guardes around it if not present. =============== Diff against Graphics-mt.315 =============== Item was added: + Object subclass: #TextPrinter + instanceVariableNames: 'form para paperSize landscape resolution depth offset columns docTitle noHeader noFooter' + classVariableNames: 'DefaultPaperSize DefaultTextPrinter' + poolDictionaries: '' + category: 'Graphics-Text'! Item was added: + ----- Method: TextPrinter class>>defaultPaperSize (in category 'accessing') ----- + defaultPaperSize + ^DefaultPaperSize! Item was added: + ----- Method: TextPrinter class>>defaultPaperSize: (in category 'accessing') ----- + defaultPaperSize: aPoint + DefaultPaperSize := aPoint! Item was added: + ----- Method: TextPrinter class>>defaultTextPrinter (in category 'accessing') ----- + defaultTextPrinter + "This is the global default TextPrinter instance." + DefaultTextPrinter isNil ifTrue: [DefaultTextPrinter := self new]. + ^DefaultTextPrinter! Item was added: + ----- Method: TextPrinter class>>initialize (in category 'class initialization') ----- + initialize + "TextPrinter initialize" + self defaultPaperSize: self paperSizeA4.! Item was added: + ----- Method: TextPrinter class>>mm2in: (in category 'paper sizes') ----- + mm2in: aPoint + "Convert aPoint from millimeters to inches" + ^aPoint / 25.4! Item was added: + ----- Method: TextPrinter class>>paperSize10x14 (in category 'paper sizes') ----- + paperSize10x14 + ^10.0@14.0! Item was added: + ----- Method: TextPrinter class>>paperSize11x17 (in category 'paper sizes') ----- + paperSize11x17 + ^11.0@17.0! Item was added: + ----- Method: TextPrinter class>>paperSizeA3 (in category 'paper sizes') ----- + paperSizeA3 + ^self mm2in: 297@420! Item was added: + ----- Method: TextPrinter class>>paperSizeA4 (in category 'paper sizes') ----- + paperSizeA4 + ^self mm2in: 210@297! Item was added: + ----- Method: TextPrinter class>>paperSizeA5 (in category 'paper sizes') ----- + paperSizeA5 + ^self mm2in: 148@210! Item was added: + ----- Method: TextPrinter class>>paperSizeB4 (in category 'paper sizes') ----- + paperSizeB4 + ^self mm2in: 250@354! Item was added: + ----- Method: TextPrinter class>>paperSizeB5 (in category 'paper sizes') ----- + paperSizeB5 + ^self mm2in: 182@257! Item was added: + ----- Method: TextPrinter class>>paperSizeCSheet (in category 'paper sizes') ----- + paperSizeCSheet + ^17.0@22.0! Item was added: + ----- Method: TextPrinter class>>paperSizeDSheet (in category 'paper sizes') ----- + paperSizeDSheet + ^22.0@34.0! Item was added: + ----- Method: TextPrinter class>>paperSizeESheet (in category 'paper sizes') ----- + paperSizeESheet + ^34.0@44.0! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelope10 (in category 'paper sizes') ----- + paperSizeEnvelope10 + ^4.125@9.5 + ! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelope11 (in category 'paper sizes') ----- + paperSizeEnvelope11 + ^4.5@10.375! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelope12 (in category 'paper sizes') ----- + paperSizeEnvelope12 + ^4.75@11! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelope14 (in category 'paper sizes') ----- + paperSizeEnvelope14 + ^5.0@11.5! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelope9 (in category 'paper sizes') ----- + paperSizeEnvelope9 + ^3.875@8.875! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeB4 (in category 'paper sizes') ----- + paperSizeEnvelopeB4 + ^self mm2in: 250@353! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeB5 (in category 'paper sizes') ----- + paperSizeEnvelopeB5 + ^self mm2in: 176@250! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeB6 (in category 'paper sizes') ----- + paperSizeEnvelopeB6 + ^self mm2in: 176@125! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeC3 (in category 'paper sizes') ----- + paperSizeEnvelopeC3 + ^self mm2in: 324@458! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeC4 (in category 'paper sizes') ----- + paperSizeEnvelopeC4 + ^self mm2in: 229@324! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeC5 (in category 'paper sizes') ----- + paperSizeEnvelopeC5 + ^self mm2in: 162@229! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeC6 (in category 'paper sizes') ----- + paperSizeEnvelopeC6 + ^self mm2in: 114@162! Item was added: + ----- Method: TextPrinter class>>paperSizeEnvelopeC65 (in category 'paper sizes') ----- + paperSizeEnvelopeC65 + ^self mm2in: 114@229! Item was added: + ----- Method: TextPrinter class>>paperSizeFanfoldGerman (in category 'paper sizes') ----- + paperSizeFanfoldGerman + "German standard fanfold" + ^8.5@12.0! Item was added: + ----- Method: TextPrinter class>>paperSizeFanfoldLegalGerman (in category 'paper sizes') ----- + paperSizeFanfoldLegalGerman + "German legal fanfold" + ^8.5@13.0! Item was added: + ----- Method: TextPrinter class>>paperSizeFanfoldUS (in category 'paper sizes') ----- + paperSizeFanfoldUS + "US standard fanfold" + ^14.875@11.0! Item was added: + ----- Method: TextPrinter class>>paperSizeFolio (in category 'paper sizes') ----- + paperSizeFolio + ^8.5@13.0! Item was added: + ----- Method: TextPrinter class>>paperSizeLegal (in category 'paper sizes') ----- + paperSizeLegal + ^8.5@14.0! Item was added: + ----- Method: TextPrinter class>>paperSizeLetter (in category 'paper sizes') ----- + paperSizeLetter + ^8.5@11.0! Item was added: + ----- Method: TextPrinter class>>paperSizeNote (in category 'paper sizes') ----- + paperSizeNote + ^8.5@11.0! Item was added: + ----- Method: TextPrinter class>>paperSizeTabloid (in category 'paper sizes') ----- + paperSizeTabloid + ^11.0@17.0! Item was added: + ----- Method: TextPrinter>>bestColor (in category 'accessing') ----- + bestColor + "Set the reproduction quality to true color" + depth := 32.! Item was added: + ----- Method: TextPrinter>>blackAndWhite (in category 'accessing') ----- + blackAndWhite + "Set the reproduction quality to black and white" + depth := 1.! Item was added: + ----- Method: TextPrinter>>columnRect: (in category 'formatting') ----- + columnRect: n + "Return a rectangle describing the n-th column" + | area left right | + area := self textArea. + left := area left + ((n-1) * self columnWidth). + left := left + ((n-1) * self columnSkip). + right := left + self columnWidth. + ^(self in2pix: left @ area top) corner: + (self in2pix: right @ area bottom)! Item was added: + ----- Method: TextPrinter>>columnSkip (in category 'formatting') ----- + columnSkip + "Return the separating space between two columns in inches" + ^0.2! Item was added: + ----- Method: TextPrinter>>columnWidth (in category 'formatting') ----- + columnWidth + ^(self textWidth - ((self columns-1) * self columnSkip)) / self columns! Item was added: + ----- Method: TextPrinter>>columns (in category 'accessing') ----- + columns + ^columns! Item was added: + ----- Method: TextPrinter>>columns: (in category 'accessing') ----- + columns: aNumber + columns := aNumber asInteger max: 1.! Item was added: + ----- Method: TextPrinter>>defaultPaperSize (in category 'initialize') ----- + defaultPaperSize + "Return the default paper size (inches) for printing" + ^self class defaultPaperSize! Item was added: + ----- Method: TextPrinter>>defaultResolution (in category 'initialize') ----- + defaultResolution + "Return the default resolution (DPI) for printing" + ^TextStyle pixelsPerInch asPoint! Item was added: + ----- Method: TextPrinter>>documentTitle (in category 'accessing') ----- + documentTitle + ^docTitle! Item was added: + ----- Method: TextPrinter>>documentTitle: (in category 'accessing') ----- + documentTitle: aString + docTitle := aString! Item was added: + ----- Method: TextPrinter>>flushPage (in category 'printing') ----- + flushPage + "The current page has been set up. Send it to the printer." + form primPrintHScale: self resolution x vScale: self resolution y landscape: self landscape. + "Uncomment the following for testing" + "form displayOn: Display. (Delay forSeconds: 5) wait." + ! Item was added: + ----- Method: TextPrinter>>footerHeight (in category 'footer') ----- + footerHeight + "Return the (additional) height of the footer in inches." + self noFooter ifTrue:[^0.0]. + ^(self pix2in: 0@TextStyle default lineGrid) y * 2! Item was added: + ----- Method: TextPrinter>>footerParagraph (in category 'footer') ----- + footerParagraph + "Return a paragraph for the footer" + | fPara rect paragraphClass | + paragraphClass := Smalltalk at: #Paragraph + ifAbsent: [^ self notify: 'MVC class Paragraph not present']. + fPara := paragraphClass new. + fPara destinationForm: form. + rect := (self in2pix: self textArea bottomLeft) corner: + (self in2pix: self textArea bottomRight + (0.0@self footerHeight)). + fPara clippingRectangle: rect. + fPara compositionRectangle: rect. + ^fPara! Item was added: + ----- Method: TextPrinter>>formatColumn:startingWith: (in category 'formatting') ----- + formatColumn: columnNum startingWith: anIndex + "Format a new column starting at the given string index. Return the string index indicating the start of the next column or nil if no more columns need printing." + | colRect blk | + colRect := self columnRect: columnNum. + anIndex > 1 ifTrue:[para text: (para text copyFrom: anIndex to: para text size)]. + para compositionRectangle: colRect. + para clippingRectangle: colRect. + para composeAll. + para displayOn: form. + para visibleRectangle corner y <= colRect extent y ifTrue:[^nil]. + "More columns -- find the character block of the last line and adjust clip rect" + blk := para characterBlockAtPoint: para visibleRectangle bottomLeft. + para clearVisibleRectangle. "Make sure that the background is clean" + para clippingRectangle: (colRect topLeft corner: colRect right@blk top). + para displayOn: form. + ^blk stringIndex.! Item was added: + ----- Method: TextPrinter>>formatPage:startingWith: (in category 'formatting') ----- + formatPage: pageNum startingWith: anIndex + "Format a new page starting at the given string index. Return the string index indicating the start of the next page or nil if no more pages need printing." + | nextIndex | + nextIndex := anIndex. + 1 to: self columns do:[:i| + nextIndex := self formatColumn: i startingWith: nextIndex. + nextIndex isNil ifTrue:[^nil]. + ]. + ^nextIndex! Item was added: + ----- Method: TextPrinter>>goodColor (in category 'accessing') ----- + goodColor + "Set the reproduction quality to 8 bit color depth" + depth := 8.! Item was added: + ----- Method: TextPrinter>>headerHeight (in category 'header') ----- + headerHeight + "Return the (additional) height of the header in inches." + self noHeader ifTrue:[^0.0]. + ^(self pix2in: 0@TextStyle default lineGrid) y * 2! Item was added: + ----- Method: TextPrinter>>headerParagraph (in category 'header') ----- + headerParagraph + "Return a paragraph for the footer" + | hPara rect paragraphClass | + paragraphClass := Smalltalk at: #Paragraph + ifAbsent: [^ self notify: 'MVC class Paragraph not present']. + hPara := paragraphClass new. + hPara destinationForm: form. + rect := (self in2pix: self textArea topLeft - (0.0@self headerHeight)) corner: + (self in2pix: self textArea topRight). + hPara clippingRectangle: rect. + hPara compositionRectangle: rect. + ^hPara! Item was added: + ----- Method: TextPrinter>>in2mm: (in category 'other') ----- + in2mm: aPoint + "Convert aPoint from millimeters to inches" + ^aPoint * 25.4! Item was added: + ----- Method: TextPrinter>>in2pix: (in category 'other') ----- + in2pix: aPoint + "Convert aPoint from inches to actual pixels" + ^(aPoint * self resolution) rounded! Item was added: + ----- Method: TextPrinter>>initialize (in category 'initialize') ----- + initialize + self paperSize: self defaultPaperSize. + self resolution: self defaultResolution. + self blackAndWhite. + self landscape: false. + self offsetRect: (1.0@1.0 corner: 1.0@1.0). + self columns: 1. + self noHeader: false. + self noFooter: false. + self documentTitle: 'Squeak Document (from ', Date today printString,')'.! Item was added: + ----- Method: TextPrinter>>landscape (in category 'accessing') ----- + landscape + ^landscape! Item was added: + ----- Method: TextPrinter>>landscape: (in category 'accessing') ----- + landscape: aBoolean + landscape := aBoolean! Item was added: + ----- Method: TextPrinter>>mm2in: (in category 'other') ----- + mm2in: aPoint + "Convert aPoint from millimeters to inches" + ^aPoint / 25.4! Item was added: + ----- Method: TextPrinter>>mm2pix: (in category 'other') ----- + mm2pix: aPoint + "Convert aPoint from millimeters to actual pixels" + ^self in2pix: (self mm2in: aPoint)! Item was added: + ----- Method: TextPrinter>>noFooter (in category 'accessing') ----- + noFooter + ^noFooter! Item was added: + ----- Method: TextPrinter>>noFooter: (in category 'accessing') ----- + noFooter: aBoolean + "Turn off footer printing" + noFooter := aBoolean.! Item was added: + ----- Method: TextPrinter>>noHeader (in category 'accessing') ----- + noHeader + ^noHeader! Item was added: + ----- Method: TextPrinter>>noHeader: (in category 'accessing') ----- + noHeader: aBoolean + "Turn off header printing" + noHeader := aBoolean.! Item was added: + ----- Method: TextPrinter>>offsetRect (in category 'accessing') ----- + offsetRect + ^offset! Item was added: + ----- Method: TextPrinter>>offsetRect: (in category 'accessing') ----- + offsetRect: aRectangle + "Set the offset rectangle" + offset := aRectangle! Item was added: + ----- Method: TextPrinter>>paperSize (in category 'accessing') ----- + paperSize + ^paperSize! Item was added: + ----- Method: TextPrinter>>paperSize: (in category 'accessing') ----- + paperSize: aPoint + paperSize := aPoint! Item was added: + ----- Method: TextPrinter>>pix2in: (in category 'other') ----- + pix2in: aPoint + "Convert aPoint from a pixel value to inches" + ^aPoint / self resolution! Item was added: + ----- Method: TextPrinter>>pix2mm: (in category 'other') ----- + pix2mm: aPoint + "Convert aPoint from a pixel value to millimeters" + ^self in2mm: (self pix2in: aPoint)! Item was added: + ----- Method: TextPrinter>>pixelSize (in category 'private') ----- + pixelSize + "Return the size of the page in pixels" + ^self in2pix: (self realPaperSize)! Item was added: + ----- Method: TextPrinter>>printFooter: (in category 'footer') ----- + printFooter: pageNumber + "Print the footer for the given page number" + | fPara | + self noFooter ifTrue:[^self]. + fPara := self footerParagraph. + fPara centered. + fPara text: ('Page ', pageNumber printString) asText. + fPara displayOn: form.! Item was added: + ----- Method: TextPrinter>>printHeader: (in category 'header') ----- + printHeader: pageNumber + "Print the header for the given page number" + | fPara | + self noHeader ifTrue:[^self]. + fPara := self headerParagraph. + fPara centered. + fPara text: self documentTitle asText. + fPara displayOn: form.! Item was added: + ----- Method: TextPrinter>>printParagraph (in category 'printing') ----- + printParagraph + | pageNum nextIndex | + para destinationForm: form. + pageNum := 1. + nextIndex := 1. + [form fillColor: Color white. + self printHeader: pageNum. + self printFooter: pageNum. + nextIndex := self formatPage: pageNum startingWith: nextIndex. + self flushPage. + nextIndex isNil] whileFalse:[pageNum := pageNum + 1].! Item was added: + ----- Method: TextPrinter>>printText: (in category 'printing') ----- + printText: aText + "Print aText" + | paragraphClass | + form isNil ifTrue:[ + form := Form extent: self pixelSize depth: depth. + ]. + paragraphClass := Smalltalk at: #Paragraph + ifAbsent: [^ self notify: 'MVC class Paragraph not present']. + para := paragraphClass withText: aText asText. + Cursor wait showWhile:[ + self printParagraph. + ].! Item was added: + ----- Method: TextPrinter>>realPaperSize (in category 'private') ----- + realPaperSize + ^self landscape + ifTrue:[self paperSize y @ self paperSize x] + ifFalse:[self paperSize]! Item was added: + ----- Method: TextPrinter>>resolution (in category 'accessing') ----- + resolution + ^resolution! Item was added: + ----- Method: TextPrinter>>resolution: (in category 'accessing') ----- + resolution: aPoint + resolution := aPoint! Item was added: + ----- Method: TextPrinter>>textArea (in category 'formatting') ----- + textArea + ^(self offsetRect origin + (0.0@self headerHeight)) corner: + (self realPaperSize - self offsetRect corner - (0.0@self footerHeight))! Item was added: + ----- Method: TextPrinter>>textWidth (in category 'formatting') ----- + textWidth + ^self textArea extent x! From commits at source.squeak.org Tue Sep 1 12:40:36 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 12:40:37 2015 Subject: [squeak-dev] The Trunk: ST80-topa.186.mcz Message-ID: Tobias Pape uploaded a new version of ST80 to project The Trunk: http://source.squeak.org/trunk/ST80-topa.186.mcz ==================== Summary ==================== Name: ST80-topa.186 Author: topa Time: 1 September 2015, 2:40:17.113 pm UUID: b35ea863-0a29-4a97-ac34-dd6d1e2bf1d8 Ancestors: ST80-mt.185 Move TextPrinter from ST80 to Graphics, as Morphic now also uses it. TextPrinter uses ST80's Paragraph but already guardes around it if not present. =============== Diff against ST80-mt.185 =============== Item was removed: - Object subclass: #TextPrinter - instanceVariableNames: 'form para paperSize landscape resolution depth offset columns docTitle noHeader noFooter' - classVariableNames: 'DefaultPaperSize DefaultTextPrinter' - poolDictionaries: '' - category: 'ST80-Support'! Item was removed: - ----- Method: TextPrinter class>>defaultPaperSize (in category 'accessing') ----- - defaultPaperSize - ^DefaultPaperSize! Item was removed: - ----- Method: TextPrinter class>>defaultPaperSize: (in category 'accessing') ----- - defaultPaperSize: aPoint - DefaultPaperSize := aPoint! Item was removed: - ----- Method: TextPrinter class>>defaultTextPrinter (in category 'accessing') ----- - defaultTextPrinter - "This is the global default TextPrinter instance." - DefaultTextPrinter isNil ifTrue: [DefaultTextPrinter := self new]. - ^DefaultTextPrinter! Item was removed: - ----- Method: TextPrinter class>>initialize (in category 'class initialization') ----- - initialize - "TextPrinter initialize" - self defaultPaperSize: self paperSizeA4.! Item was removed: - ----- Method: TextPrinter class>>mm2in: (in category 'paper sizes') ----- - mm2in: aPoint - "Convert aPoint from millimeters to inches" - ^aPoint / 25.4! Item was removed: - ----- Method: TextPrinter class>>paperSize10x14 (in category 'paper sizes') ----- - paperSize10x14 - ^10.0@14.0! Item was removed: - ----- Method: TextPrinter class>>paperSize11x17 (in category 'paper sizes') ----- - paperSize11x17 - ^11.0@17.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeA3 (in category 'paper sizes') ----- - paperSizeA3 - ^self mm2in: 297@420! Item was removed: - ----- Method: TextPrinter class>>paperSizeA4 (in category 'paper sizes') ----- - paperSizeA4 - ^self mm2in: 210@297! Item was removed: - ----- Method: TextPrinter class>>paperSizeA5 (in category 'paper sizes') ----- - paperSizeA5 - ^self mm2in: 148@210! Item was removed: - ----- Method: TextPrinter class>>paperSizeB4 (in category 'paper sizes') ----- - paperSizeB4 - ^self mm2in: 250@354! Item was removed: - ----- Method: TextPrinter class>>paperSizeB5 (in category 'paper sizes') ----- - paperSizeB5 - ^self mm2in: 182@257! Item was removed: - ----- Method: TextPrinter class>>paperSizeCSheet (in category 'paper sizes') ----- - paperSizeCSheet - ^17.0@22.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeDSheet (in category 'paper sizes') ----- - paperSizeDSheet - ^22.0@34.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeESheet (in category 'paper sizes') ----- - paperSizeESheet - ^34.0@44.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelope10 (in category 'paper sizes') ----- - paperSizeEnvelope10 - ^4.125@9.5 - ! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelope11 (in category 'paper sizes') ----- - paperSizeEnvelope11 - ^4.5@10.375! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelope12 (in category 'paper sizes') ----- - paperSizeEnvelope12 - ^4.75@11! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelope14 (in category 'paper sizes') ----- - paperSizeEnvelope14 - ^5.0@11.5! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelope9 (in category 'paper sizes') ----- - paperSizeEnvelope9 - ^3.875@8.875! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeB4 (in category 'paper sizes') ----- - paperSizeEnvelopeB4 - ^self mm2in: 250@353! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeB5 (in category 'paper sizes') ----- - paperSizeEnvelopeB5 - ^self mm2in: 176@250! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeB6 (in category 'paper sizes') ----- - paperSizeEnvelopeB6 - ^self mm2in: 176@125! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeC3 (in category 'paper sizes') ----- - paperSizeEnvelopeC3 - ^self mm2in: 324@458! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeC4 (in category 'paper sizes') ----- - paperSizeEnvelopeC4 - ^self mm2in: 229@324! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeC5 (in category 'paper sizes') ----- - paperSizeEnvelopeC5 - ^self mm2in: 162@229! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeC6 (in category 'paper sizes') ----- - paperSizeEnvelopeC6 - ^self mm2in: 114@162! Item was removed: - ----- Method: TextPrinter class>>paperSizeEnvelopeC65 (in category 'paper sizes') ----- - paperSizeEnvelopeC65 - ^self mm2in: 114@229! Item was removed: - ----- Method: TextPrinter class>>paperSizeFanfoldGerman (in category 'paper sizes') ----- - paperSizeFanfoldGerman - "German standard fanfold" - ^8.5@12.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeFanfoldLegalGerman (in category 'paper sizes') ----- - paperSizeFanfoldLegalGerman - "German legal fanfold" - ^8.5@13.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeFanfoldUS (in category 'paper sizes') ----- - paperSizeFanfoldUS - "US standard fanfold" - ^14.875@11.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeFolio (in category 'paper sizes') ----- - paperSizeFolio - ^8.5@13.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeLegal (in category 'paper sizes') ----- - paperSizeLegal - ^8.5@14.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeLetter (in category 'paper sizes') ----- - paperSizeLetter - ^8.5@11.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeNote (in category 'paper sizes') ----- - paperSizeNote - ^8.5@11.0! Item was removed: - ----- Method: TextPrinter class>>paperSizeTabloid (in category 'paper sizes') ----- - paperSizeTabloid - ^11.0@17.0! Item was removed: - ----- Method: TextPrinter>>bestColor (in category 'accessing') ----- - bestColor - "Set the reproduction quality to true color" - depth := 32.! Item was removed: - ----- Method: TextPrinter>>blackAndWhite (in category 'accessing') ----- - blackAndWhite - "Set the reproduction quality to black and white" - depth := 1.! Item was removed: - ----- Method: TextPrinter>>columnRect: (in category 'formatting') ----- - columnRect: n - "Return a rectangle describing the n-th column" - | area left right | - area := self textArea. - left := area left + ((n-1) * self columnWidth). - left := left + ((n-1) * self columnSkip). - right := left + self columnWidth. - ^(self in2pix: left @ area top) corner: - (self in2pix: right @ area bottom)! Item was removed: - ----- Method: TextPrinter>>columnSkip (in category 'formatting') ----- - columnSkip - "Return the separating space between two columns in inches" - ^0.2! Item was removed: - ----- Method: TextPrinter>>columnWidth (in category 'formatting') ----- - columnWidth - ^(self textWidth - ((self columns-1) * self columnSkip)) / self columns! Item was removed: - ----- Method: TextPrinter>>columns (in category 'accessing') ----- - columns - ^columns! Item was removed: - ----- Method: TextPrinter>>columns: (in category 'accessing') ----- - columns: aNumber - columns := aNumber asInteger max: 1.! Item was removed: - ----- Method: TextPrinter>>defaultPaperSize (in category 'initialize') ----- - defaultPaperSize - "Return the default paper size (inches) for printing" - ^self class defaultPaperSize! Item was removed: - ----- Method: TextPrinter>>defaultResolution (in category 'initialize') ----- - defaultResolution - "Return the default resolution (DPI) for printing" - ^TextStyle pixelsPerInch asPoint! Item was removed: - ----- Method: TextPrinter>>documentTitle (in category 'accessing') ----- - documentTitle - ^docTitle! Item was removed: - ----- Method: TextPrinter>>documentTitle: (in category 'accessing') ----- - documentTitle: aString - docTitle := aString! Item was removed: - ----- Method: TextPrinter>>flushPage (in category 'printing') ----- - flushPage - "The current page has been set up. Send it to the printer." - form primPrintHScale: self resolution x vScale: self resolution y landscape: self landscape. - "Uncomment the following for testing" - "form displayOn: Display. (Delay forSeconds: 5) wait." - ! Item was removed: - ----- Method: TextPrinter>>footerHeight (in category 'footer') ----- - footerHeight - "Return the (additional) height of the footer in inches." - self noFooter ifTrue:[^0.0]. - ^(self pix2in: 0@TextStyle default lineGrid) y * 2! Item was removed: - ----- Method: TextPrinter>>footerParagraph (in category 'footer') ----- - footerParagraph - "Return a paragraph for the footer" - | fPara rect paragraphClass | - paragraphClass := Smalltalk at: #Paragraph - ifAbsent: [^ self notify: 'MVC class Paragraph not present']. - fPara := paragraphClass new. - fPara destinationForm: form. - rect := (self in2pix: self textArea bottomLeft) corner: - (self in2pix: self textArea bottomRight + (0.0@self footerHeight)). - fPara clippingRectangle: rect. - fPara compositionRectangle: rect. - ^fPara! Item was removed: - ----- Method: TextPrinter>>formatColumn:startingWith: (in category 'formatting') ----- - formatColumn: columnNum startingWith: anIndex - "Format a new column starting at the given string index. Return the string index indicating the start of the next column or nil if no more columns need printing." - | colRect blk | - colRect := self columnRect: columnNum. - anIndex > 1 ifTrue:[para text: (para text copyFrom: anIndex to: para text size)]. - para compositionRectangle: colRect. - para clippingRectangle: colRect. - para composeAll. - para displayOn: form. - para visibleRectangle corner y <= colRect extent y ifTrue:[^nil]. - "More columns -- find the character block of the last line and adjust clip rect" - blk := para characterBlockAtPoint: para visibleRectangle bottomLeft. - para clearVisibleRectangle. "Make sure that the background is clean" - para clippingRectangle: (colRect topLeft corner: colRect right@blk top). - para displayOn: form. - ^blk stringIndex.! Item was removed: - ----- Method: TextPrinter>>formatPage:startingWith: (in category 'formatting') ----- - formatPage: pageNum startingWith: anIndex - "Format a new page starting at the given string index. Return the string index indicating the start of the next page or nil if no more pages need printing." - | nextIndex | - nextIndex := anIndex. - 1 to: self columns do:[:i| - nextIndex := self formatColumn: i startingWith: nextIndex. - nextIndex isNil ifTrue:[^nil]. - ]. - ^nextIndex! Item was removed: - ----- Method: TextPrinter>>goodColor (in category 'accessing') ----- - goodColor - "Set the reproduction quality to 8 bit color depth" - depth := 8.! Item was removed: - ----- Method: TextPrinter>>headerHeight (in category 'header') ----- - headerHeight - "Return the (additional) height of the header in inches." - self noHeader ifTrue:[^0.0]. - ^(self pix2in: 0@TextStyle default lineGrid) y * 2! Item was removed: - ----- Method: TextPrinter>>headerParagraph (in category 'header') ----- - headerParagraph - "Return a paragraph for the footer" - | hPara rect paragraphClass | - paragraphClass := Smalltalk at: #Paragraph - ifAbsent: [^ self notify: 'MVC class Paragraph not present']. - hPara := paragraphClass new. - hPara destinationForm: form. - rect := (self in2pix: self textArea topLeft - (0.0@self headerHeight)) corner: - (self in2pix: self textArea topRight). - hPara clippingRectangle: rect. - hPara compositionRectangle: rect. - ^hPara! Item was removed: - ----- Method: TextPrinter>>in2mm: (in category 'other') ----- - in2mm: aPoint - "Convert aPoint from millimeters to inches" - ^aPoint * 25.4! Item was removed: - ----- Method: TextPrinter>>in2pix: (in category 'other') ----- - in2pix: aPoint - "Convert aPoint from inches to actual pixels" - ^(aPoint * self resolution) rounded! Item was removed: - ----- Method: TextPrinter>>initialize (in category 'initialize') ----- - initialize - self paperSize: self defaultPaperSize. - self resolution: self defaultResolution. - self blackAndWhite. - self landscape: false. - self offsetRect: (1.0@1.0 corner: 1.0@1.0). - self columns: 1. - self noHeader: false. - self noFooter: false. - self documentTitle: 'Squeak Document (from ', Date today printString,')'.! Item was removed: - ----- Method: TextPrinter>>landscape (in category 'accessing') ----- - landscape - ^landscape! Item was removed: - ----- Method: TextPrinter>>landscape: (in category 'accessing') ----- - landscape: aBoolean - landscape := aBoolean! Item was removed: - ----- Method: TextPrinter>>mm2in: (in category 'other') ----- - mm2in: aPoint - "Convert aPoint from millimeters to inches" - ^aPoint / 25.4! Item was removed: - ----- Method: TextPrinter>>mm2pix: (in category 'other') ----- - mm2pix: aPoint - "Convert aPoint from millimeters to actual pixels" - ^self in2pix: (self mm2in: aPoint)! Item was removed: - ----- Method: TextPrinter>>noFooter (in category 'accessing') ----- - noFooter - ^noFooter! Item was removed: - ----- Method: TextPrinter>>noFooter: (in category 'accessing') ----- - noFooter: aBoolean - "Turn off footer printing" - noFooter := aBoolean.! Item was removed: - ----- Method: TextPrinter>>noHeader (in category 'accessing') ----- - noHeader - ^noHeader! Item was removed: - ----- Method: TextPrinter>>noHeader: (in category 'accessing') ----- - noHeader: aBoolean - "Turn off header printing" - noHeader := aBoolean.! Item was removed: - ----- Method: TextPrinter>>offsetRect (in category 'accessing') ----- - offsetRect - ^offset! Item was removed: - ----- Method: TextPrinter>>offsetRect: (in category 'accessing') ----- - offsetRect: aRectangle - "Set the offset rectangle" - offset := aRectangle! Item was removed: - ----- Method: TextPrinter>>paperSize (in category 'accessing') ----- - paperSize - ^paperSize! Item was removed: - ----- Method: TextPrinter>>paperSize: (in category 'accessing') ----- - paperSize: aPoint - paperSize := aPoint! Item was removed: - ----- Method: TextPrinter>>pix2in: (in category 'other') ----- - pix2in: aPoint - "Convert aPoint from a pixel value to inches" - ^aPoint / self resolution! Item was removed: - ----- Method: TextPrinter>>pix2mm: (in category 'other') ----- - pix2mm: aPoint - "Convert aPoint from a pixel value to millimeters" - ^self in2mm: (self pix2in: aPoint)! Item was removed: - ----- Method: TextPrinter>>pixelSize (in category 'private') ----- - pixelSize - "Return the size of the page in pixels" - ^self in2pix: (self realPaperSize)! Item was removed: - ----- Method: TextPrinter>>printFooter: (in category 'footer') ----- - printFooter: pageNumber - "Print the footer for the given page number" - | fPara | - self noFooter ifTrue:[^self]. - fPara := self footerParagraph. - fPara centered. - fPara text: ('Page ', pageNumber printString) asText. - fPara displayOn: form.! Item was removed: - ----- Method: TextPrinter>>printHeader: (in category 'header') ----- - printHeader: pageNumber - "Print the header for the given page number" - | fPara | - self noHeader ifTrue:[^self]. - fPara := self headerParagraph. - fPara centered. - fPara text: self documentTitle asText. - fPara displayOn: form.! Item was removed: - ----- Method: TextPrinter>>printParagraph (in category 'printing') ----- - printParagraph - | pageNum nextIndex | - para destinationForm: form. - pageNum := 1. - nextIndex := 1. - [form fillColor: Color white. - self printHeader: pageNum. - self printFooter: pageNum. - nextIndex := self formatPage: pageNum startingWith: nextIndex. - self flushPage. - nextIndex isNil] whileFalse:[pageNum := pageNum + 1].! Item was removed: - ----- Method: TextPrinter>>printText: (in category 'printing') ----- - printText: aText - "Print aText" - | paragraphClass | - form isNil ifTrue:[ - form := Form extent: self pixelSize depth: depth. - ]. - paragraphClass := Smalltalk at: #Paragraph - ifAbsent: [^ self notify: 'MVC class Paragraph not present']. - para := paragraphClass withText: aText asText. - Cursor wait showWhile:[ - self printParagraph. - ].! Item was removed: - ----- Method: TextPrinter>>realPaperSize (in category 'private') ----- - realPaperSize - ^self landscape - ifTrue:[self paperSize y @ self paperSize x] - ifFalse:[self paperSize]! Item was removed: - ----- Method: TextPrinter>>resolution (in category 'accessing') ----- - resolution - ^resolution! Item was removed: - ----- Method: TextPrinter>>resolution: (in category 'accessing') ----- - resolution: aPoint - resolution := aPoint! Item was removed: - ----- Method: TextPrinter>>textArea (in category 'formatting') ----- - textArea - ^(self offsetRect origin + (0.0@self headerHeight)) corner: - (self realPaperSize - self offsetRect corner - (0.0@self footerHeight))! Item was removed: - ----- Method: TextPrinter>>textWidth (in category 'formatting') ----- - textWidth - ^self textArea extent x! From commits at source.squeak.org Tue Sep 1 12:42:24 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 12:42:26 2015 Subject: [squeak-dev] The Trunk: Tests-topa.330.mcz Message-ID: Tobias Pape uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-topa.330.mcz ==================== Summary ==================== Name: Tests-topa.330 Author: topa Time: 1 September 2015, 2:42:05.272 pm UUID: f8a88aaf-8f89-4359-b735-c97edb4b73b1 Ancestors: Tests-mt.329 Network rightfully depens on WebClient, now that it is our default HTTP(S) client. =============== Diff against Tests-mt.329 =============== Item was changed: ----- Method: PackageDependencyTest>>testNetwork (in category 'tests') ----- testNetwork self testPackage: 'Network' dependsExactlyOn: #( Collections Compiler Compression Files Graphics Kernel Morphic System 'ToolBuilder-Kernel' + 'WebClient-Core' ).! From commits at source.squeak.org Tue Sep 1 12:57:27 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 12:57:28 2015 Subject: [squeak-dev] The Trunk: TrueType-topa.40.mcz Message-ID: Tobias Pape uploaded a new version of TrueType to project The Trunk: http://source.squeak.org/trunk/TrueType-topa.40.mcz ==================== Summary ==================== Name: TrueType-topa.40 Author: topa Time: 1 September 2015, 2:57:19.158 pm UUID: 9abe9053-6bf7-4a8a-b769-caf1d6bbbc97 Ancestors: TrueType-topa.39 Use all glyphs in a Font, not just 256 (fix by Vasya Chajko) =============== Diff against TrueType-topa.39 =============== Item was changed: ----- Method: TTCFontReader>>processCharMap: (in category 'as yet unclassified') ----- processCharMap: assoc "Process the given character map" | glyph cmap encode0 encode1 char value null | cmap := assoc value. null := (glyphs at: (cmap at: Character space asUnicode + 1) + 1) copy. null contours: #(). encode0 := Array new: 256 withAll: glyphs first. encode1 := Array new: 65536 withAll: glyphs first. 0 to: 255 do: [:i | char := Character value: i. glyph := glyphs at: (cmap at: char asUnicode + 1) + 1. encode0 at: i+1 put: glyph. ]. Character separators do: [:c | encode0 at: (c asciiValue + 1) put: null. ]. 0 to: 65536 - 1 do: [:i | value := cmap at: i+1. value = 65535 ifFalse: [ "???" | g | + g := glyphs at: value+1 ifAbsent: [ null. ]. - g := glyphs at: value+1. (g isKindOf: TTCompositeGlyph) ifFalse: [ encode1 at: i+1 put: g. ] ifTrue: [ g basicGlyphs: (((glyphs at: value+1) basicGlyphs) collect: [:t | t key->(glyphs at: (t value glyphIndex+1))]). encode1 at: i+1 put: g ]. ] ]. ^ {encode0. encode1}. ! Item was changed: ----- Method: TTFontReader>>decodeCmapFmtTable: (in category 'private') ----- decodeCmapFmtTable: entry | cmapFmt length entryCount segCount segments offset cmap firstCode | cmapFmt := entry nextUShort. length := entry nextUShort. entry skip: 2. "skip version" cmapFmt = 0 ifTrue: "byte encoded table" [length := length - 6. "should be always 256" length <= 0 ifTrue: [^ nil]. "but sometimes, this table is empty" cmap := Array new: length. entry nextBytes: length into: cmap startingAt: entry offset. ^ cmap]. cmapFmt = 4 ifTrue: "segment mapping to deltavalues" [segCount := entry nextUShort // 2. entry skip: 6. "skip searchRange, entrySelector, rangeShift" segments := Array new: segCount. segments := (1 to: segCount) collect: [:e | Array new: 4]. 1 to: segCount do: [:i | (segments at: i) at: 2 put: entry nextUShort]. "endCount" entry skip: 2. "skip reservedPad" 1 to: segCount do: [:i | (segments at: i) at: 1 put: entry nextUShort]. "startCount" 1 to: segCount do: [:i | (segments at: i) at: 3 put: entry nextShort]. "idDelta" offset := entry offset. 1 to: segCount do: [:i | (segments at: i) at: 4 put: entry nextUShort]. "idRangeOffset" entryCount := segments inject: 0 into: [:max :seg | max max: seg second]. cmap := Array new: entryCount+1 withAll: 0.. segments withIndexDo: [:seg :si | | code | seg first to: seg second do: [:i | + seg last > 0 ifTrue: - i < 256 ifTrue: - [seg last > 0 ifTrue: ["offset to glypthIdArray - this is really C-magic!!" entry offset: i - seg first - 1 * 2 + seg last + si + si + offset. code := entry nextUShort. code > 0 ifTrue: [code := code + seg third]] ifFalse: ["simple offset" code := i + seg third]. + cmap at: i + 1 put: code"]"]]. - cmap at: i + 1 put: code]]]. ^ cmap]. cmapFmt = 6 ifTrue: "trimmed table" [firstCode := entry nextUShort. entryCount := entry nextUShort. cmap := Array new: entryCount + firstCode withAll: 0. entryCount timesRepeat: [cmap at: (firstCode := firstCode + 1) put: entry nextUShort]. ^ cmap]. ^ nil! From Das.Linux at gmx.de Tue Sep 1 12:58:14 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Sep 1 12:58:17 2015 Subject: [squeak-dev] [Bug] Cannot use non-english characters even after loading a proper font In-Reply-To: <55E0BB95.2040602@gmail.com> References: <1439679369.9270.2@mglap> <55E0BB95.2040602@gmail.com> Message-ID: <26336CD0-773A-4408-858F-13EFE0D23DC6@gmx.de> Hi ????, On 28.08.2015, at 21:50, ???? ????? wrote: > 16.08.2015 4:56, Mateusz Grotek ?????: >> Hi, >> First of all thank you for the new version of Squeak. It's really great. >> >> Special thanks for Tobias and Marcel for the font import tool! It works perfectly. >> >> Nevertheless I have noticed that there is a regression in Squeak 4.6/5.0 in the font handling. It's not possible anymore to use non-english characters even after loading a font that contains them (I've changed the code font and tried to use the characters in a workspace). > Unnamed1.1.cs >> Can anyone verify? >> >> Mateusz I included your changeset into trunk. Thank you! Best regards -Tobias From asqueaker at gmail.com Tue Sep 1 15:31:51 2015 From: asqueaker at gmail.com (Chris Muller) Date: Tue Sep 1 15:31:54 2015 Subject: [squeak-dev] The Trunk: Tests-topa.330.mcz In-Reply-To: <55e59d34.af148c0a.7c61a.3537SMTPIN_ADDED_MISSING@mx.google.com> References: <55e59d34.af148c0a.7c61a.3537SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: WebClient is an HTTP application, Network deals in low-level sockets. Shouldn't WebClient depend on Network instead of vice-versa? On Tue, Sep 1, 2015 at 7:42 AM, wrote: > Tobias Pape uploaded a new version of Tests to project The Trunk: > http://source.squeak.org/trunk/Tests-topa.330.mcz > > ==================== Summary ==================== > > Name: Tests-topa.330 > Author: topa > Time: 1 September 2015, 2:42:05.272 pm > UUID: f8a88aaf-8f89-4359-b735-c97edb4b73b1 > Ancestors: Tests-mt.329 > > Network rightfully depens on WebClient, now that it is our default HTTP(S) client. > > =============== Diff against Tests-mt.329 =============== > > Item was changed: > ----- Method: PackageDependencyTest>>testNetwork (in category 'tests') ----- > testNetwork > self testPackage: 'Network' dependsExactlyOn: #( > Collections > Compiler > Compression > Files > Graphics > Kernel > Morphic > System > 'ToolBuilder-Kernel' > + 'WebClient-Core' > ).! > > From karlramberg at gmail.com Tue Sep 1 17:18:12 2015 From: karlramberg at gmail.com (karl ramberg) Date: Tue Sep 1 17:18:15 2015 Subject: [squeak-dev] The Trunk: TrueType-topa.40.mcz In-Reply-To: <55e5a0bd.02eb8c0a.882d6.ffff8aefSMTPIN_ADDED_MISSING@mx.google.com> References: <55e5a0bd.02eb8c0a.882d6.ffff8aefSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Hi, Here I think it would be clearer to remove the out commented "]" ! Karl On Tue, Sep 1, 2015 at 2:57 PM, wrote: > Tobias Pape uploaded a new version of TrueType to project The Trunk: > http://source.squeak.org/trunk/TrueType-topa.40.mcz > > ==================== Summary ==================== > > Name: TrueType-topa.40 > Author: topa > Time: 1 September 2015, 2:57:19.158 pm > UUID: 9abe9053-6bf7-4a8a-b769-caf1d6bbbc97 > Ancestors: TrueType-topa.39 > > Use all glyphs in a Font, not just 256 (fix by Vasya Chajko) > > =============== Diff against TrueType-topa.39 =============== > > Item was changed: > ----- Method: TTCFontReader>>processCharMap: (in category 'as yet > unclassified') ----- > processCharMap: assoc > "Process the given character map" > > | glyph cmap encode0 encode1 char value null | > cmap := assoc value. > null := (glyphs at: (cmap at: Character space asUnicode + 1) + 1) > copy. > null contours: #(). > > encode0 := Array new: 256 withAll: glyphs first. > encode1 := Array new: 65536 withAll: glyphs first. > > 0 to: 255 do: [:i | > char := Character value: i. > glyph := glyphs at: (cmap at: char asUnicode + 1) + 1. > encode0 at: i+1 put: glyph. > ]. > Character separators do: [:c | > encode0 at: (c asciiValue + 1) put: null. > ]. > 0 to: 65536 - 1 do: [:i | > value := cmap at: i+1. > value = 65535 ifFalse: [ "???" > | g | > + g := glyphs at: value+1 ifAbsent: [ null. ]. > - g := glyphs at: value+1. > (g isKindOf: TTCompositeGlyph) ifFalse: [ > encode1 at: i+1 put: g. > ] ifTrue: [ > g basicGlyphs: (((glyphs at: value+1) > basicGlyphs) collect: [:t | t key->(glyphs at: (t value glyphIndex+1))]). > encode1 at: i+1 put: g > ]. > ] > ]. > > ^ {encode0. encode1}. > ! > > Item was changed: > ----- Method: TTFontReader>>decodeCmapFmtTable: (in category 'private') > ----- > decodeCmapFmtTable: entry > | cmapFmt length entryCount segCount segments offset cmap > firstCode | > cmapFmt := entry nextUShort. > length := entry nextUShort. > entry skip: 2. "skip version" > > cmapFmt = 0 ifTrue: "byte encoded table" > [length := length - 6. "should be always 256" > length <= 0 ifTrue: [^ nil]. "but sometimes, this table > is empty" > cmap := Array new: length. > entry nextBytes: length into: cmap startingAt: entry > offset. > ^ cmap]. > > cmapFmt = 4 ifTrue: "segment mapping to deltavalues" > [segCount := entry nextUShort // 2. > entry skip: 6. "skip searchRange, entrySelector, > rangeShift" > segments := Array new: segCount. > segments := (1 to: segCount) collect: [:e | Array new: 4]. > 1 to: segCount do: [:i | (segments at: i) at: 2 put: entry > nextUShort]. "endCount" > entry skip: 2. "skip reservedPad" > 1 to: segCount do: [:i | (segments at: i) at: 1 put: entry > nextUShort]. "startCount" > 1 to: segCount do: [:i | (segments at: i) at: 3 put: entry > nextShort]. "idDelta" > offset := entry offset. > 1 to: segCount do: [:i | (segments at: i) at: 4 put: entry > nextUShort]. "idRangeOffset" > entryCount := segments inject: 0 into: [:max :seg | max > max: seg second]. > cmap := Array new: entryCount+1 withAll: 0.. > segments withIndexDo: > [:seg :si | | code | > seg first to: seg second do: > [:i | > + seg last > 0 ifTrue: > - i < 256 ifTrue: > - [seg last > 0 ifTrue: > ["offset to glypthIdArray > - this is really C-magic!!" > entry offset: i - seg > first - 1 * 2 + seg last + si + si + offset. > code := entry nextUShort. > code > 0 ifTrue: [code := > code + seg third]] > ifFalse: > ["simple offset" > code := i + seg third]. > + cmap at: i + 1 put: code"]"]]. > - cmap at: i + 1 put: code]]]. > ^ cmap]. > > cmapFmt = 6 ifTrue: "trimmed table" > [firstCode := entry nextUShort. > entryCount := entry nextUShort. > cmap := Array new: entryCount + firstCode withAll: 0. > entryCount timesRepeat: > [cmap at: (firstCode := firstCode + 1) put: entry > nextUShort]. > ^ cmap]. > ^ nil! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150901/88a129c7/attachment.htm From Yoshiki.Ohshima at acm.org Tue Sep 1 18:07:29 2015 From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima) Date: Tue Sep 1 18:07:32 2015 Subject: [squeak-dev] Get raw 24 Bit image data into a Form In-Reply-To: References: <55E1CC31.8020601@gmx.net> Message-ID: > P.S.: This is usually the point when someone comes up with a pure bitblt > solution providing further significant speedups. Yeah, kind of the topic I like^^; The following is not tested but I'm putting this out just to illustrates the idea: ------------------------------------------------------------ f := Form extent: 1296@972 depth: 32. "f will contain the resulting 32-bit form." hDest := Form new hackBits: f bits. "hDest is a view on the bits of f that treats the bits as 4 pixel wide 8 bit form." alpha := Form extent: 1@972 depth: 8. alpha fillColor: (Bitmap with: 16rFFFFFFFF). "A one-pixel wide narrow bitmap of white. You actually don't need this and do the fill with bounding box in below, but just to show something." orig := ByteArray new: 300. "Let us say this is the original byte array." hOrig := Form extent: 3@(972*1296) depth: 8. hOrig bits copyFromByteArray: orig. "hOrig is 3-pixel wide form." alpha displayOn: hDest at: 0@0. hOrig displayOn: hDest at: 1@0. -------------------------------------------------------------- -- -- Yoshiki From Das.Linux at gmx.de Tue Sep 1 18:13:26 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Sep 1 18:13:29 2015 Subject: [squeak-dev] The Trunk: Tests-topa.330.mcz In-Reply-To: References: <55e59d34.af148c0a.7c61a.3537SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <63ACD033-BEA5-4929-A141-26B949E8B70C@gmx.de> On 01.09.2015, at 17:31, Chris Muller wrote: > WebClient is an HTTP application, Network deals in low-level sockets. > Shouldn't WebClient depend on Network instead of vice-versa? > Well, the ?old? http client was directly in the networking package. This dependency just happens to be because the override-methods from WebClient-HTTP (that make WebClient the default HTTP client used by Network) have been removed and WebClient is now hard-coded. Best regards -Tobias > On Tue, Sep 1, 2015 at 7:42 AM, wrote: >> Tobias Pape uploaded a new version of Tests to project The Trunk: >> http://source.squeak.org/trunk/Tests-topa.330.mcz >> >> ==================== Summary ==================== >> >> Name: Tests-topa.330 >> Author: topa >> Time: 1 September 2015, 2:42:05.272 pm >> UUID: f8a88aaf-8f89-4359-b735-c97edb4b73b1 >> Ancestors: Tests-mt.329 >> >> Network rightfully depens on WebClient, now that it is our default HTTP(S) client. >> >> =============== Diff against Tests-mt.329 =============== >> >> Item was changed: >> ----- Method: PackageDependencyTest>>testNetwork (in category 'tests') ----- >> testNetwork >> self testPackage: 'Network' dependsExactlyOn: #( >> Collections >> Compiler >> Compression >> Files >> Graphics >> Kernel >> Morphic >> System >> 'ToolBuilder-Kernel' >> + 'WebClient-Core' >> ).! From Das.Linux at gmx.de Tue Sep 1 18:13:43 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Sep 1 18:13:47 2015 Subject: [squeak-dev] The Trunk: TrueType-topa.40.mcz In-Reply-To: References: <55e5a0bd.02eb8c0a.882d6.ffff8aefSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 01.09.2015, at 19:18, karl ramberg wrote: > Hi, > Here I think it would be clearer to remove the out commented "]" ! Yes, I missed that, sorry. > > Karl > > On Tue, Sep 1, 2015 at 2:57 PM, wrote: > Tobias Pape uploaded a new version of TrueType to project The Trunk: > http://source.squeak.org/trunk/TrueType-topa.40.mcz > > ==================== Summary ==================== > > Name: TrueType-topa.40 > Author: topa > Time: 1 September 2015, 2:57:19.158 pm > UUID: 9abe9053-6bf7-4a8a-b769-caf1d6bbbc97 > Ancestors: TrueType-topa.39 > > Use all glyphs in a Font, not just 256 (fix by Vasya Chajko) > > =============== Diff against TrueType-topa.39 =============== > > Item was changed: From commits at source.squeak.org Tue Sep 1 18:16:17 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 18:16:18 2015 Subject: [squeak-dev] The Trunk: TrueType-topa.41.mcz Message-ID: Tobias Pape uploaded a new version of TrueType to project The Trunk: http://source.squeak.org/trunk/TrueType-topa.41.mcz ==================== Summary ==================== Name: TrueType-topa.41 Author: topa Time: 1 September 2015, 8:16:08.356 pm UUID: 0d684bf6-4a41-4e84-8277-b44b93575029 Ancestors: TrueType-topa.40 Remove spurious comment =============== Diff against TrueType-topa.40 =============== Item was changed: ----- Method: TTFontReader>>decodeCmapFmtTable: (in category 'private') ----- decodeCmapFmtTable: entry | cmapFmt length entryCount segCount segments offset cmap firstCode | cmapFmt := entry nextUShort. length := entry nextUShort. entry skip: 2. "skip version" cmapFmt = 0 ifTrue: "byte encoded table" [length := length - 6. "should be always 256" length <= 0 ifTrue: [^ nil]. "but sometimes, this table is empty" cmap := Array new: length. entry nextBytes: length into: cmap startingAt: entry offset. ^ cmap]. cmapFmt = 4 ifTrue: "segment mapping to deltavalues" [segCount := entry nextUShort // 2. entry skip: 6. "skip searchRange, entrySelector, rangeShift" segments := Array new: segCount. segments := (1 to: segCount) collect: [:e | Array new: 4]. 1 to: segCount do: [:i | (segments at: i) at: 2 put: entry nextUShort]. "endCount" entry skip: 2. "skip reservedPad" 1 to: segCount do: [:i | (segments at: i) at: 1 put: entry nextUShort]. "startCount" 1 to: segCount do: [:i | (segments at: i) at: 3 put: entry nextShort]. "idDelta" offset := entry offset. 1 to: segCount do: [:i | (segments at: i) at: 4 put: entry nextUShort]. "idRangeOffset" entryCount := segments inject: 0 into: [:max :seg | max max: seg second]. cmap := Array new: entryCount+1 withAll: 0.. segments withIndexDo: [:seg :si | | code | seg first to: seg second do: [:i | seg last > 0 ifTrue: ["offset to glypthIdArray - this is really C-magic!!" entry offset: i - seg first - 1 * 2 + seg last + si + si + offset. code := entry nextUShort. code > 0 ifTrue: [code := code + seg third]] ifFalse: ["simple offset" code := i + seg third]. + cmap at: i + 1 put: code]]. - cmap at: i + 1 put: code"]"]]. ^ cmap]. cmapFmt = 6 ifTrue: "trimmed table" [firstCode := entry nextUShort. entryCount := entry nextUShort. cmap := Array new: entryCount + firstCode withAll: 0. entryCount timesRepeat: [cmap at: (firstCode := firstCode + 1) put: entry nextUShort]. ^ cmap]. ^ nil! From karlramberg at gmail.com Tue Sep 1 18:33:13 2015 From: karlramberg at gmail.com (karl ramberg) Date: Tue Sep 1 18:33:16 2015 Subject: [squeak-dev] The Trunk: TrueType-topa.40.mcz In-Reply-To: References: <55e5a0bd.02eb8c0a.882d6.ffff8aefSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Thanks :-) Karl On Tue, Sep 1, 2015 at 8:13 PM, Tobias Pape wrote: > > On 01.09.2015, at 19:18, karl ramberg wrote: > > > Hi, > > Here I think it would be clearer to remove the out commented "]" ! > > Yes, I missed that, sorry. > > > > > Karl > > > > On Tue, Sep 1, 2015 at 2:57 PM, wrote: > > Tobias Pape uploaded a new version of TrueType to project The Trunk: > > http://source.squeak.org/trunk/TrueType-topa.40.mcz > > > > ==================== Summary ==================== > > > > Name: TrueType-topa.40 > > Author: topa > > Time: 1 September 2015, 2:57:19.158 pm > > UUID: 9abe9053-6bf7-4a8a-b769-caf1d6bbbc97 > > Ancestors: TrueType-topa.39 > > > > Use all glyphs in a Font, not just 256 (fix by Vasya Chajko) > > > > =============== Diff against TrueType-topa.39 =============== > > > > Item was changed: > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150901/48162810/attachment.htm From commits at source.squeak.org Tue Sep 1 19:39:48 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 19:39:49 2015 Subject: [squeak-dev] The Trunk: Collections-cbc.650.mcz Message-ID: Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cbc.650.mcz ==================== Summary ==================== Name: Collections-cbc.650 Author: cbc Time: 28 August 2015, 3:56:04.013 pm UUID: 35dc53fb-613d-f84a-bd9d-ffc19957feb8 Ancestors: Collections-ul.649 Add ByteArray methods to deal with long64bit values. =============== Diff against Collections-ul.649 =============== Item was added: + ----- Method: ByteArray>>unsignedLong64At:bigEndian: (in category 'platform independent access') ----- + unsignedLong64At: index bigEndian: aBool + | n1 n2 | + aBool + ifTrue: [ + n2 := self unsignedLongAt: index bigEndian: true. + n1 := self unsignedLongAt: index+4 bigEndian: true. + ] + ifFalse: [ + n1 := self unsignedLongAt: index bigEndian: false. + n2 := self unsignedLongAt: index+4 bigEndian: false. + ]. + ^(n2 bitShift: 32) + n1! Item was added: + ----- Method: ByteArray>>unsignedLong64At:put:bigEndian: (in category 'platform independent access') ----- + unsignedLong64At: index put: val bigEndian: aBool + aBool + ifTrue: [ + self unsignedLongAt: index put: (val bitShift: -32) bigEndian: true. + self unsignedLongAt: index+4 put: (val bitAnd: 16rFFFFFFFF) bigEndian: true. + ] + ifFalse: [ + self unsignedLongAt: index put: (val bitAnd: 16rFFFFFFFF) bigEndian: false. + self unsignedLongAt: index+4 put: (val bitShift: -32) bigEndian: false. + ]. + ^val + ! From commits at source.squeak.org Tue Sep 1 19:39:58 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 19:39:59 2015 Subject: [squeak-dev] The Trunk: Collections-cbc.651.mcz Message-ID: Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cbc.651.mcz ==================== Summary ==================== Name: Collections-cbc.651 Author: cbc Time: 31 August 2015, 3:53:15.138 pm UUID: 1d7408f6-a290-0d4b-8b83-6a6a2e4f325e Ancestors: Collections-cbc.650 Faster #unsignedLong64At:bigEndian: =============== Diff against Collections-cbc.650 =============== Item was changed: ----- Method: ByteArray>>unsignedLong64At:bigEndian: (in category 'platform independent access') ----- unsignedLong64At: index bigEndian: aBool + "Avoid as much largeInteger as we can" + | b0 b2 b3 b5 b6 w n2 n3 | + + aBool ifFalse: [ + w := self at: index. + b6 := self at: index+1. + b5 := self at: index+2. + n2 := self at: index+3. + b3 := self at: index+4. + b2 := self at: index+5. + n3 := self at: index+6. + b0 := self at: index+7. + ] ifTrue: [ + b0 := self at: index. + n3 := self at: index+1. + b2 := self at: index+2. + b3 := self at: index+3. + n2 := self at: index+4. + b5 := self at: index+5. + b6 := self at: index+6. + w := self at: index+7. + ]. + + "Minimize LargeInteger arithmetic" + b6 = 0 ifFalse:[w := (b6 bitShift: 8) + w]. + b5 = 0 ifFalse:[w := (b5 bitShift: 16) + w]. + + b3 = 0 ifFalse:[n2 := (b3 bitShift: 8) + n2]. + b2 = 0 ifFalse:[n2 := (b2 bitShift: 16) + n2]. + n2 == 0 ifFalse: [w := (n2 bitShift: 24) + w]. + + b0 = 0 ifFalse:[n3 := (b0 bitShift: 8) + n3]. + n3 == 0 ifFalse: [w := (n3 bitShift: 48) + w]. + + ^w! - | n1 n2 | - aBool - ifTrue: [ - n2 := self unsignedLongAt: index bigEndian: true. - n1 := self unsignedLongAt: index+4 bigEndian: true. - ] - ifFalse: [ - n1 := self unsignedLongAt: index bigEndian: false. - n2 := self unsignedLongAt: index+4 bigEndian: false. - ]. - ^(n2 bitShift: 32) + n1! From commits at source.squeak.org Tue Sep 1 19:40:24 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 19:40:26 2015 Subject: [squeak-dev] The Trunk: Collections-cbc.652.mcz Message-ID: Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cbc.652.mcz ==================== Summary ==================== Name: Collections-cbc.652 Author: cbc Time: 31 August 2015, 8:32:50.179 pm UUID: 88079716-328d-4a41-8838-595e6782882c Ancestors: Collections-cbc.651 #unsignedLong64At:put:bigEndian: on average fast. =============== Diff against Collections-cbc.651 =============== Item was changed: ----- Method: ByteArray>>unsignedLong64At:put:bigEndian: (in category 'platform independent access') ----- + unsignedLong64At: index put: value bigEndian: aBool + "Minimize largeInteger arithmetic" + | ix | + aBool ifFalse: [ + ix := index - 1. + 1 to: 8 do: [:pos| + self at: ix + pos put: (value digitAt: pos) - unsignedLong64At: index put: val bigEndian: aBool - aBool - ifTrue: [ - self unsignedLongAt: index put: (val bitShift: -32) bigEndian: true. - self unsignedLongAt: index+4 put: (val bitAnd: 16rFFFFFFFF) bigEndian: true. - ] - ifFalse: [ - self unsignedLongAt: index put: (val bitAnd: 16rFFFFFFFF) bigEndian: false. - self unsignedLongAt: index+4 put: (val bitShift: -32) bigEndian: false. ]. + ] ifTrue: [ + ix := index + 8. + 1 to: 8 do: [:pos| + self at: ix - pos put: (value digitAt: pos) + ]. + ]. + ^value - ^val ! From tim at rowledge.org Tue Sep 1 19:49:14 2015 From: tim at rowledge.org (tim Rowledge) Date: Tue Sep 1 19:49:19 2015 Subject: [squeak-dev] securing SAR/MCZ files, certificates, etc Message-ID: <60CC3F57-0515-463B-8EBC-1C51600D4B33@rowledge.org> I mentioned working on using SAR files and/or MCZ as a way to distribute device driver add-ons for Pi Scratch a while ago. The basics are working nicely and it?s time to ask for advice on securing the files. I?ve noticed assorted ssl/encryption/certificate checking related emails whizz by but never paid a lot of attention in the past. An interesting additional issue for my use is that the file will need to be loadable/decryptable/checkable very fast, even on a Pi, since it will need to be reloaded (from file, not over the net) each time the user asks for a device needing one of these drivers. We don?t need to be utterly paranoid about the security since nobody is doing anything l crazy with this, like, oh, taking one up to the ISS? Pointers to stuff to read, load, try, all appreciated from those with experience. No, I haven?t googled much about it since I know too little to be able to make a sensible start without advice. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CWB: Carry With Borrow From edgardec2005 at gmail.com Tue Sep 1 20:04:15 2015 From: edgardec2005 at gmail.com (Edgar De Cleene) Date: Tue Sep 1 20:04:24 2015 Subject: [squeak-dev] securing SAR/MCZ files, certificates, etc In-Reply-To: <60CC3F57-0515-463B-8EBC-1C51600D4B33@rowledge.org> References: <60CC3F57-0515-463B-8EBC-1C51600D4B33@rowledge.org> Message-ID: <227B0810-88B8-4390-B794-68EFF1188344@gmail.com> String new enigma2015: 'I mentioned working on using SAR files and/or MCZ as a way to distribute device driver add-ons for Pi Scratch a while ago. ? Gives 'LDxmF(f.Fm|D+.CXfF%D.FD9gfF%Dc''jDyf^mgD1F|B.CD$_ED1gD1D+1*D(.D|fg(Cf69(mD|m5fGmD|Cf5mCD1||z.FgDy.CDrfDcGC1(GODD1D+Of^mD1%.HD? Having the input could be cracked, but if not ??. If like, i send private to you > On Sep 1, 2015, at 4:49 PM, tim Rowledge wrote: > > I mentioned working on using SAR files and/or MCZ as a way to distribute device driver add-ons for Pi Scratch a while ago. The basics are working nicely and it?s time to ask for advice on securing the files. I?ve noticed assorted ssl/encryption/certificate checking related emails whizz by but never paid a lot of attention in the past. > > An interesting additional issue for my use is that the file will need to be loadable/decryptable/checkable very fast, even on a Pi, since it will need to be reloaded (from file, not over the net) each time the user asks for a device needing one of these drivers. We don?t need to be utterly paranoid about the security since nobody is doing anything l crazy with this, like, oh, taking one up to the ISS? > > Pointers to stuff to read, load, try, all appreciated from those with experience. No, I haven?t googled much about it since I know too little to be able to make a sensible start without advice. > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: CWB: Carry With Borrow > > > From tim at rowledge.org Tue Sep 1 20:31:12 2015 From: tim at rowledge.org (tim Rowledge) Date: Tue Sep 1 20:31:18 2015 Subject: [squeak-dev] securing SAR/MCZ files, certificates, etc In-Reply-To: <227B0810-88B8-4390-B794-68EFF1188344@gmail.com> References: <60CC3F57-0515-463B-8EBC-1C51600D4B33@rowledge.org> <227B0810-88B8-4390-B794-68EFF1188344@gmail.com> Message-ID: On 01-09-2015, at 1:04 PM, Edgar De Cleene wrote: > String new enigma2015: > 'I mentioned working on using SAR files and/or MCZ as a way to distribute device driver add-ons for Pi Scratch a while ago. ? > > Gives > > 'LDxmF(f.Fm|D+.CXfF%D.FD9gfF%Dc''jDyf^mgD1F|B.CD$_ED1gD1D+1*D(.D|fg(Cf69(mD|m5fGmD|Cf5mCD1||z.FgDy.CDrfDcGC1(GODD1D+Of^mD1%.HD? > > Having the input could be cracked, but if not ??. > If like, i send private to you Sounds interesting. I?d love to take a look! tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Couldn't find his way through a maze even if the rats helped him. From commits at source.squeak.org Tue Sep 1 20:44:10 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 20:44:12 2015 Subject: [squeak-dev] The Trunk: Compression-cmm.48.mcz Message-ID: Chris Muller uploaded a new version of Compression to project The Trunk: http://source.squeak.org/trunk/Compression-cmm.48.mcz ==================== Summary ==================== Name: Compression-cmm.48 Author: cmm Time: 1 September 2015, 3:43:17.149 pm UUID: 833287cb-44f0-42e8-9419-bd8cde39dd0a Ancestors: Compression-dtl.47 Allow zipping of directories with thousands of files, without creating thousands of instances of simultaneously open FileStream's in the image. =============== Diff against Compression-dtl.47 =============== Item was added: + ----- Method: ZipArchiveMember>>openStreamWhile: (in category 'private-writing') ----- + openStreamWhile: aBlock + ^ aBlock value! Item was changed: ----- Method: ZipArchiveMember>>writeTo: (in category 'writing') ----- + writeTo: aStream + self openStreamWhile: + [ self rewindData. + writeLocalHeaderRelativeOffset := aStream position. + self + writeLocalFileHeaderTo: aStream ; + writeDataTo: aStream ; + refreshLocalFileHeaderTo: aStream ]! - writeTo: aStream - self rewindData. - writeLocalHeaderRelativeOffset := aStream position. - self writeLocalFileHeaderTo: aStream. - self writeDataTo: aStream. - self refreshLocalFileHeaderTo: aStream.! Item was changed: ----- Method: ZipNewFileMember>>from: (in category 'initialization') ----- from: aFileName | entry | compressionMethod := CompressionStored. "Now get the size, attributes, and timestamps, and see if the file exists" stream := StandardFileStream readOnlyFileNamed: aFileName. self localFileName: (externalFileName := stream name). entry := stream directoryEntry. compressedSize := uncompressedSize := entry fileSize. desiredCompressionMethod := compressedSize > 0 ifTrue: [ CompressionDeflated ] ifFalse: [ CompressionStored ]. + self setLastModFileDateTimeFrom: entry modificationTime. + stream close! - self setLastModFileDateTimeFrom: entry modificationTime - ! Item was added: + ----- Method: ZipNewFileMember>>openStreamWhile: (in category 'private-writing') ----- + openStreamWhile: aBlock + stream open. + ^ aBlock ensure: [ stream close ]! From commits at source.squeak.org Tue Sep 1 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 1 21:55:03 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150901215502.25610.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008937.html Name: Graphics-topa.316 Ancestors: Graphics-mt.315 Move TextPrinter from ST80 to Graphics, as Morphic now also uses it. TextPrinter uses ST80's Paragraph but already guardes around it if not present. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008938.html Name: ST80-topa.186 Ancestors: ST80-mt.185 Move TextPrinter from ST80 to Graphics, as Morphic now also uses it. TextPrinter uses ST80's Paragraph but already guardes around it if not present. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008939.html Name: Tests-topa.330 Ancestors: Tests-mt.329 Network rightfully depens on WebClient, now that it is our default HTTP(S) client. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008940.html Name: TrueType-topa.40 Ancestors: TrueType-topa.39 Use all glyphs in a Font, not just 256 (fix by Vasya Chajko) ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008941.html Name: TrueType-topa.41 Ancestors: TrueType-topa.40 Remove spurious comment ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008942.html Name: Collections-cbc.650 Ancestors: Collections-ul.649 Add ByteArray methods to deal with long64bit values. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008943.html Name: Collections-cbc.651 Ancestors: Collections-cbc.650 Faster #unsignedLong64At:bigEndian: ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008944.html Name: Collections-cbc.652 Ancestors: Collections-cbc.651 #unsignedLong64At:put:bigEndian: on average fast. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008945.html Name: Compression-cmm.48 Ancestors: Compression-dtl.47 Allow zipping of directories with thousands of files, without creating thousands of instances of simultaneously open FileStream's in the image. ============================================= From edgardec2005 at gmail.com Wed Sep 2 11:11:26 2015 From: edgardec2005 at gmail.com (Edgar De Cleene) Date: Wed Sep 2 11:11:55 2015 Subject: [squeak-dev] securing SAR/MCZ files, certificates, etc In-Reply-To: References: <60CC3F57-0515-463B-8EBC-1C51600D4B33@rowledge.org> <227B0810-88B8-4390-B794-68EFF1188344@gmail.com> Message-ID: <87A15409-B2BF-4CBA-8B09-7F6D17F99B4E@gmail.com> I assume you connect the raspberry to some another computer via TCP or via old serial cable . Which is so cook some more complete and not only the encoder. And if you was really paranoic, the encoder could change for each string. > On Sep 1, 2015, at 5:31 PM, tim Rowledge wrote: > > > On 01-09-2015, at 1:04 PM, Edgar De Cleene wrote: > >> String new enigma2015: >> 'I mentioned working on using SAR files and/or MCZ as a way to distribute device driver add-ons for Pi Scratch a while ago. ? >> >> Gives >> >> 'LDxmF(f.Fm|D+.CXfF%D.FD9gfF%Dc''jDyf^mgD1F|B.CD$_ED1gD1D+1*D(.D|fg(Cf69(mD|m5fGmD|Cf5mCD1||z.FgDy.CDrfDcGC1(GODD1D+Of^mD1%.HD? >> >> Having the input could be cracked, but if not ??. >> If like, i send private to you > > Sounds interesting. I?d love to take a look! > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Useful random insult:- Couldn't find his way through a maze even if the rats helped him. > > > From hmm at heeg.de Wed Sep 2 11:54:18 2015 From: hmm at heeg.de (Hans-Martin Mosner) Date: Wed Sep 2 11:54:26 2015 Subject: [squeak-dev] securing SAR/MCZ files, certificates, etc In-Reply-To: <60CC3F57-0515-463B-8EBC-1C51600D4B33@rowledge.org> References: <60CC3F57-0515-463B-8EBC-1C51600D4B33@rowledge.org> Message-ID: <3af590ace282609051281a440bbdbea3@heeg.de> Am 01.09.2015 21:49, schrieb tim Rowledge: > I mentioned working on using SAR files and/or MCZ as a way to > distribute device driver add-ons for Pi Scratch a while ago. The > basics are working nicely and it?s time to ask for advice on securing > the files. I?ve noticed assorted ssl/encryption/certificate checking > related emails whizz by but never paid a lot of attention in the past. > I'd go with the "industry standard" (read: Java) solution even if it's from Mordor. JAR files are just ZIP files with another extension, just as SAR and MCZ files (correct me if I'm wrong). So the jarsigner signature mechanisms should be applicable. We have a cryptography package which includes most functionality already (x.509 stuff and various algorithms). Don't know how much work it would be to implement signing ZIP files and checking their signatures, probably an evening or two for someone who's sufficiently fluent with crypto stuff. However, this would imply that the Pi Scratch images would need to have (a subset of) the Cryptography classes loaded. Edgar, I don't know what the #enigma2015: method actually does. Is it an encryption algorithm? If yes, a standard one or homebrew? How does it relate to digital signatures? If this weren't a use case with pretty low security requirements, I'd put on my hobby cryptographer hat and shout at the top of my lungs "YOU MUST NEVER USE CRYPTO ALGORITHMS THAT HAVE NOT BEEN DESIGNED AND THOROUGHLY ANALYZED BY EXPERTS IN THE FIELD!!!11eleven!!" Cheers, Hans-Martin From eliot.miranda at gmail.com Wed Sep 2 22:41:11 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Sep 2 22:41:14 2015 Subject: [squeak-dev] The Trunk: Monticello-eem.617.mcz In-Reply-To: <41C01C00-13BF-42D8-BCCB-E6E56550B92C@gmx.de> References: <41C01C00-13BF-42D8-BCCB-E6E56550B92C@gmx.de> Message-ID: Hi Tobias, On Thu, Aug 27, 2015 at 10:56 PM, Tobias Pape wrote: > Hi Eliot, > > On 28.08.2015, at 00:09, commits@source.squeak.org wrote: > > > Item was added: > > + ----- Method: ChangeSorter>>monticelloChangeSetMenu: (in category > '*Monticello-changeSet menu') ----- > > + monticelloChangeSetMenu: aMenu > > + > > + > > + "Sigh, when implementing menu pragmas this is not what I had in > mind..." > > + aMenu add: 'delete Monticello load change sets' action: > #deleteMonticelloChangeSets. > > + (aMenu submorphs > > + detect: [:m| m > isMenuItemMorph and: [m contents beginsWith: 'destroy change set']] > > + ifNone: []) ifNotNil: > > + [:destroyItem| | item | > > + aMenu removeMorph: (item := aMenu submorphs last). > > + aMenu addMorph: item after: destroyItem]. > > + ^aMenu! > > Can you explain what you want to achieve > and how I can make this more convenient? > We can talk this over when we meet in Palo Alto, but the idea is an important one, and I'm paying for having been too lazy to write it up properly. Let me try and give a quick sketch here. The goals are to - allow package load to augment menus without the original definitions of those menus knowing anything about the subsequently loaded packages. - to allow menus to be augmented with single actions defined in methods that implement those actions - and, depending on menu implementation, either - if menus are created every time a user invokes a menu, then to simply include the relevant extensions in the menu - if menus are stored in variables, to automatically construct, or reconstruct the menu when either loading or unloading of a package changes the items in a menu We design menu pragmas in action methods to specify - the (name of the) menu to be extended - the text of the menu entry - information regarding what group of items the menu item belongs with - information regarding the menu item's relative order with respect to other elements in the group Rationale: With this specification a package can extend any number of menus in tools simply by being loaded, with no collisions with any other packages defining extensions on those menus. Tools become freely pluggable, and system configurations constructed from different sets of loaded packages are decoupled; we don't need many menu definitions, just an initial base menu which is extended with the current set of extensions. For this to work we need to "name" menus, and to use some numbering scheme to define groups (menu entries between lines) and elements within each group. One simple scheme is to use numbers: - the definitions of initial base menus number groups, so that the first group (the items before the first line) is numbered group 10, and the second group 20, and so on, allowing extensions to specify new groups by using group numbers that are not a multiple of 10 - the definitions of entries within groups are numbered, again in multiples of 10, so that the extension can fit anywhere in the group So given MenuMorph fromArray: { {'find...(f)' translated. #find}. {'find again (g)' translated. #findAgain}. {'set search string (h)' translated. #setSearchString}. #-. {'do again (j)' translated. #again}. {'undo (z)' translated. #undo}. #-. {'copy (c)' translated. #copySelection}. {'cut (x)' translated. #cut}. {'paste (v)' translated. #paste}. {'paste...' translated. #pasteRecent}. #-. {'set font... (k)' translated. #offerFontMenu}. {'set style... (K)' translated. #changeStyle}. {'set alignment...' translated. #chooseAlignment}. " #-. {'more...' translated. #shiftedTextPaneMenuRequest}. " } you could imagine the following numberings: 10.01 find 10.02 findAgain 10.03 setSearchString - 20.01 again 20.02 undo - 30.01 copySelection 30.02 cut 30.03 paste 30.04 pasteRecent - 40.01 offerFontMenu 40.02 changeStyle 40.03 chooseAlignment So I can specify e.g. a new group inserted before the first one by using, e.g. 5.005 as an index, and can slot an item between again and undo using 20.015, etc. This gives us menu pragmas that look like: TextEditor methodsFor: '*SpellChecker-extensions' stamp: 'mad hacker 9/9/1999' spellCheck ...code implementing spell checking... (note that the action, #spellCheck, is implicit, it is the selector of the method containing the pragma) and - if menus are created every time a user invokes a menu, then search for pragmas within the relevant class hierarchy, compute, sort and insert individual extensions to the menu - if menus are stored in variables, to have compilation and method removal send a message to the class to/from which method(s) are added/removed so that the class can recompute menus (as in the line above) when code is added/removed. What I saw in ChangeSorter was quite different. It seems to be a way of specifying entire menus, and I'm not sure how these menus are to be combined. Maybe I'm misunderstanding the way the scheme is supposed to work. What I've described above is very close to the one that pragmas came from in the first place, which was my attempt to decouple the components that could be loaded into VisualWorks when we decomposed the system into easily loadable parcels. Up until that point VisualWorks had had all its tool menus predefined, disabling items that were to do with components delivered as file-ins that weren't yet filed-in. It was too rigid. It didn't allow for future expansion. And so I had the idea of menu pragmas to decouple things. Steve Dahl then came up with the scheme to define a base menu, number its items appropriately, and extend the menu. One of the things that's really nice about the VisualWorks scheme is that the menu pragma itself is actually implemented (remember that pragmas are Message instances with literal parameters). The class MenuBuilder (IIRC) implemented various menu pragma methods so the patten is - in the method that defines the base menu, define the base menu, create an editor on it, ask the editor to collect the pragmas and augment the menu with those found - the menu editor then collects the menu pragmas and then performs each one to collect the information from it So one can find other menu pragmas using senders, and find the editor using implementors, and one can extend the scheme by adding additional methods to MenuEditor, again possibly loaded from packages. HTH _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150902/94b83351/attachment.htm From frankiecheezoli at yahoo.com Wed Sep 2 22:51:55 2015 From: frankiecheezoli at yahoo.com (frankiec) Date: Wed Sep 2 22:57:48 2015 Subject: [squeak-dev] Re: Regex In-Reply-To: <1441017802917-4847093.post@n4.nabble.com> References: <1441010369545-4847054.post@n4.nabble.com> <1441017802917-4847093.post@n4.nabble.com> Message-ID: <1441234315333-4847767.post@n4.nabble.com> OK, I avoided this problem by adding the http://source.squeak.org/trunk path to the Monticello Browser. As a new Smalltalker, I wish these things were documented a little bit better. ;) -- View this message in context: http://forum.world.st/Regex-tp4842477p4847767.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From craig at netjam.org Wed Sep 2 23:21:49 2015 From: craig at netjam.org (Craig Latta) Date: Wed Sep 2 23:21:54 2015 Subject: [squeak-dev] menu pragmas (was "The Trunk: Monticello-eem.617.mcz") Message-ID: Hi all-- This is just a new thread to make Eliot's description of menu pragmas more prominent in the list archives. Perhaps there are others who, like me, don't read all the "trunk" threads in their entirety and might miss stuff like this. thanks, -C *** Tobias writes to Eliot: > Can you explain what you want to achieve [with menu pragmas] and how > I can make [their use] more convenient? Eliot responds: > We can talk this over when we meet in Palo Alto, but the idea is an > important one, and I'm paying for having been too lazy to write it up > properly. Let me try and give a quick sketch here. > > The goals are to: > > - allow package load to augment menus without the original definitions > of those menus knowing anything about the subsequently loaded > packages. > - to allow menus to be augmented with single actions defined in > methods that implement those actions > - and, depending on menu implementation, either > - if menus are created every time a user invokes a menu, then to > simply include the relevant extensions in the menu > - if menus are stored in variables, to automatically construct, or > reconstruct the menu when either loading or unloading of a package > changes the items in a menu > > We design menu pragmas in action methods to specify: > - the (name of the) menu to be extended > - the text of the menu entry > - information regarding what group of items the menu item belongs with > - information regarding the menu item's relative order with respect to > other elements in the group > > Rationale: > With this specification a package can extend any number of menus in > tools simply by being loaded, with no collisions with any other > packages defining extensions on those menus. Tools become freely > pluggable, and system configurations constructed from different sets > of loaded packages are decoupled; we don't need many menu > definitions, just an initial base menu which is extended with the > current set of extensions. > > For this to work we need to "name" menus, and to use some numbering > scheme to define groups (menu entries between lines) and elements > within each group. One simple scheme is to use numbers: > > - the definitions of initial base menus number groups, so that the > first group (the items before the first line) is numbered group 10, > and the second group 20, and so on, allowing extensions to specify > new groups by using group numbers that are not a multiple of 10 > - the definitions of entries within groups are numbered, again in > multiples of 10, so that the extension can fit anywhere in the > group > > So given: > > MenuMorph fromArray: { > {'find...(f)' translated. #find}. > {'find again (g)' translated. #findAgain}. > {'set search string (h)' translated. #setSearchString}. > #-. > {'do again (j)' translated. #again}. > {'undo (z)' translated. #undo}. > #-. > {'copy (c)' translated. #copySelection}. > {'cut (x)' translated. #cut}. > {'paste (v)' translated. #paste}. > {'paste...' translated. #pasteRecent}. > #-. > {'set font... (k)' translated. #offerFontMenu}. > {'set style... (K)' translated. #changeStyle}. > {'set alignment...' translated. #chooseAlignment}. > " > #-. > {'more...' translated. #shiftedTextPaneMenuRequest}. > " > } > > you could imagine the following numberings: > > 10.01 find > 10.02 findAgain > 10.03 setSearchString > - > 20.01 again > 20.02 undo > - > 30.01 copySelection > 30.02 cut > 30.03 paste > 30.04 pasteRecent > - > 40.01 offerFontMenu > 40.02 changeStyle > 40.03 chooseAlignment > > So I can specify e.g. a new group inserted before the first one by > using, e.g. 5.005 as an index, and can slot an item between again and > undo using 20.015, etc. > > This gives us menu pragmas that look like: > > TextEditor methodsFor: '*SpellChecker-extensions' stamp: 'mad hacker > 9/9/1999' > spellCheck > label: 'spell check selection (s)' > position: 10.035> > ...code implementing spell checking... > > (note that the action, #spellCheck, is implicit, it is the selector of > the method containing the pragma) > > and: > > - if menus are created every time a user invokes a menu, then search > for pragmas within the relevant class hierarchy, compute, sort and > insert individual extensions to the menu > - if menus are stored in variables, to have compilation and method > removal send a message to the class to/from which method(s) are > added/removed so that the class can recompute menus (as in the line > above) when code is added/removed. > > What I saw in ChangeSorter was quite different. It seems to be a way > of specifying entire menus, and I'm not sure how these menus are to be > combined. Maybe I'm misunderstanding the way the scheme is supposed > to work. What I've described above is very close to the one that > pragmas came from in the first place, which was my attempt to > decouple the components that could be loaded into VisualWorks when we > decomposed the system into easily loadable parcels. Up until that > point VisualWorks had had all its tool menus predefined, disabling > items that were to do with components delivered as file-ins that > weren't yet filed-in. It was too rigid. It didn't allow for future > expansion. And so I had the idea of menu pragmas to decouple > things. Steve Dahl then came up with the scheme to define a base > menu, number its items appropriately, and extend the menu. > > One of the things that's really nice about the VisualWorks scheme is > that the menu pragma itself is actually implemented (remember that > pragmas are Message instances with literal parameters). The class > MenuBuilder (IIRC) implemented various menu pragma methods so the > pattern is: > > - in the method that defines the base menu, define the base menu, > create an editor on it, ask the editor to collect the pragmas and > augment the menu with those found > - the menu editor then collects the menu pragmas and then performs > each one to collect the information from it > > So one can find other menu pragmas using senders, and find the editor > using implementors, and one can extend the scheme by adding additional > methods to MenuEditor, again possibly loaded from packages. > > > HTH > > _,,,^..^,,,_ > best, Eliot -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From commits at source.squeak.org Thu Sep 3 00:03:41 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 00:03:43 2015 Subject: [squeak-dev] The Trunk: MonticelloConfigurations-dtl.137.mcz Message-ID: David T. Lewis uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-dtl.137.mcz ==================== Summary ==================== Name: MonticelloConfigurations-dtl.137 Author: dtl Time: 28 August 2015, 10:22:42.408 pm UUID: 420cae25-4016-48ba-8101-1881773d5098 Ancestors: MonticelloConfigurations-dtl.136 Fix updating the default update map name from preferences. Change constructor to avoid conflict with setter used by the preference. When the preference for default update map changes, initialize with a new default updater. The previous updater for the default update URL is replaced because its remembered position in the update stream will not be valid for a different update map sequence. Therefore ask confirmation from the user before accepting the preference change. Class var UpdateMapName is no longer needed, remove it. The LastUpdateMap class var was retained to support transition to instance based updaters. Remove it now. =============== Diff against MonticelloConfigurations-dtl.136 =============== Item was changed: Object subclass: #MCMcmUpdater instanceVariableNames: 'updateMapName lastUpdateMap' + classVariableNames: 'DefaultUpdateURL SkipPackages UpdateFromServerAtStartup UpdateMissingPackages Updaters' - classVariableNames: 'DefaultUpdateURL LastUpdateMap SkipPackages UpdateFromServerAtStartup UpdateMapName UpdateMissingPackages Updaters' poolDictionaries: '' category: 'MonticelloConfigurations'! + !MCMcmUpdater commentStamp: 'dtl 8/28/2015 22:07' prior: 0! - !MCMcmUpdater commentStamp: 'dtl 5/4/2015 16:03' prior: 0! MCMcmUpdater provides utility methods for updating Monticello packages from Monticello configurations. When Monticello configurations are stored in a repository (or repositories), MCMcmUpdater acts as an update stream. It first ensures that each configuration map has been loaded in sequence, then updates the last configuration map to the most recent version for each specified package, and finally loads these versions to produce a fully updated configuration. Currently if a set of packages are unloaded from the image, using this class to reload them may cause problems, depending on what dependencies those classes have. Success is not assured. Removing packages via SmalltalkImage>>unloadAllKnownPackages will be successful, it flags the packages removed so that they are not loaded by this utility. If you wish to not have MCMcmUpdater update packages, there are two ways to handle this: 1) To have MCMcmUpdater not update any packages not currently in the image set the UpdateMissingPackages preference to false: MCMcmUpdater updateMissingPackages: false Note that any new packages added to the repositories will not be picked up when this is turned off. 2) To have MCMcmUpdater not update a specific package, evaluate MCMcmUpdater disableUpdatesOfPackage: Class Variables definitions: DefaultUpdateURL - String: the URL that will be checked by default for updates. This would be set for a common standard location to check. Updaters - A dictionary of MCMcmUpdater instances keyed by repository URL. SkipPackages - Set of Strings: names of packages to not update in MCMcmUpdater (empty by default). UpdateMissingPackages - Boolean: if true (default), new packages in the update config map will be loaded unless they are in SkipPackages. If false, packages not currently loaded in the image will not be loaded by MCMcmUpdater. (This can be dangerous if packages are split - use at your own risk). Instance Variables: updateMapName - Base name of the files used for this updater, typically a name such as 'update' or 'update.spur'. lastUpdateMap - Dictionary of Integer: version number of the last loaded update map per repository. Keeps track of the last configuration map, so that the utility will not have to run through the full history in the repositories each time you ask to update. ! Item was changed: ----- Method: MCMcmUpdater class>>default (in category 'instance creation') ----- default "The default instance for system updates. Uses a default update map name that may be set as a preference to enable a specific update stream for a repository." ^ self updaters at: self defaultUpdateURL + ifAbsentPut: [self updateMapNamed: self updateMapName]! - ifAbsentPut: [self updateMapName: self updateMapName]! Item was changed: ----- Method: MCMcmUpdater class>>initialize (in category 'class initialization') ----- initialize "MCMcmUpdater initialize" - LastUpdateMap ifNil:[ - LastUpdateMap := Dictionary new. - ]. DefaultUpdateURL ifNil:[ DefaultUpdateURL := MCHttpRepository trunkUrlString. ]. Updaters := nil. - self flag: #FIXME. - "The next line is to faciliate updating from class-side methods to instance based. - Building a new default update map is very time consuming, so do not do it. - Delete this after the transition is complete. Also delete class var LastUpdateMap - and its initialization above. -dtl May 2015" - LastUpdateMap ifNotNil: [ self default lastUpdateMap: LastUpdateMap ] ! Item was changed: ----- Method: MCMcmUpdater class>>updateFromRepositories:using:baseName: (in category 'updating') ----- updateFromRepositories: repositoryUrls using: updaterUrlKey baseName: baseName "Update all repositoryUrls using an MCMcmUpdater identified by updaterUrlKey, and using update map baseName" + ^ (self updateMapNamed: baseName repository: updaterUrlKey) - ^ (self updateMapName: baseName repository: updaterUrlKey) updateFromRepositories: repositoryUrls! Item was changed: ----- Method: MCMcmUpdater class>>updateFromRepository:baseName: (in category 'updating') ----- updateFromRepository: updaterUrlKey baseName: baseName "Update using an MCMcmUpdater identified by updaterUrlKey, and using update map baseName" + ^ (self updateMapNamed: baseName repository: updaterUrlKey) - ^ (self updateMapName: baseName repository: updaterUrlKey) updateFrom: updaterUrlKey! Item was changed: ----- Method: MCMcmUpdater class>>updateMapName (in category 'preferences') ----- updateMapName + "The default update map name" - "Name for update map, without version info" + ^ 'update'! - ^UpdateMapName ifNil: ['update']! Item was changed: + ----- Method: MCMcmUpdater class>>updateMapName: (in category 'preferences') ----- + updateMapName: mapName + "The default update map name for the default updater. If this is changed, + then the default updater must be replaced because its remembered position + in the update map sequence will not be valid for the new update map." - ----- Method: MCMcmUpdater class>>updateMapName: (in category 'instance creation') ----- - updateMapName: baseName - "Answer a new instance with a base update name baseName such as - 'update' or 'update.oscog' " + self default updateMapName = mapName + ifFalse: [(self confirm: 'Initializing updater for ' , DefaultUpdateURL , ' to use new update stream ' , mapName) + ifTrue: [self updaters + at: self defaultUpdateURL + put: (self updateMapNamed: mapName)]]! - ^ self new updateMapName: baseName! Item was removed: - ----- Method: MCMcmUpdater class>>updateMapName:repository: (in category 'instance creation') ----- - updateMapName: baseName repository: url - "Answer an instance for the given repository URL with a base update name - baseName. The instance will be updated in the Updaters dictionary if baseName - has changed." - - | updater | - updater := self updaters at: url ifAbsentPut: [ self updateMapName: baseName ]. - updater updateMapName = baseName - ifFalse: [ ^ self updaters at: url put: (self updateMapName: baseName )]. - ^ updater - ! Item was added: + ----- Method: MCMcmUpdater class>>updateMapNamed: (in category 'instance creation') ----- + updateMapNamed: baseName + "Answer a new instance with a base update name baseName such as + 'update' or 'update.oscog' " + + ^ self new + updateMapName: baseName; + lastUpdateMap: Dictionary new! Item was added: + ----- Method: MCMcmUpdater class>>updateMapNamed:repository: (in category 'instance creation') ----- + updateMapNamed: baseName repository: url + "Answer an instance for the given repository URL with a base update name + baseName. The instance will be updated in the Updaters dictionary if baseName + has changed." + + | updater | + updater := self updaters at: url ifAbsentPut: [ self updateMapNamed: baseName ]. + updater updateMapName = baseName + ifFalse: [ ^ self updaters at: url put: (self updateMapNamed: baseName )]. + ^ updater + ! From eliot.miranda at gmail.com Thu Sep 3 01:16:06 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Sep 3 01:16:08 2015 Subject: [squeak-dev] Grrrr, how come I can't deselect in a list browser?? Message-ID: Hi All, so I just noticed that there are a few methods which carriage returns in the time stamp, which is confusing and should be fixed, so I did this to get a list of said methods: CurrentReadOnlySourceFiles cacheDuring: [self systemNavigation browseAllSelect: [:m| m timeStamp includes: Character cr]] Cool, now I have a list of the methods I need to file-out to quickly fix their time stamps and the list has the first method selected. But no matter how many times I click on that method or any other the list browser resolutely refuses to deselect, completely sabotaging my useful modification of the file out item in list browsers, committed at least a year ago now, such that when nothing is selected all methods in the list get filed out. I can find no preference which restores unselectability. Can who ever changed this undo the change please? I am /not/ going to sit there like a monkey and filter out each individual method. Yes, I *could* try and deselect by inspecting the thing, but, you know what, I shouldn't have to, it should deselect like it used to, when I loved it like I used to. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150902/c70e3bf8/attachment.htm From commits at source.squeak.org Thu Sep 3 01:26:27 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 01:26:27 2015 Subject: [squeak-dev] The Trunk: Collections-eem.653.mcz Message-ID: Eliot Miranda uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-eem.653.mcz ==================== Summary ==================== Name: Collections-eem.653 Author: eem Time: 2 September 2015, 6:26:05.268 pm UUID: dfc67d6b-1eaf-42c5-929d-b136b4d28ef0 Ancestors: Collections-cbc.652 Remove carriage returns from some time stamps. Nuke unused private method in old finalization scheme. =============== Diff against Collections-cbc.652 =============== Item was changed: ----- Method: PluggableDictionary class>>integerDictionary (in category 'instance creation') ----- integerDictionary ^ self new hashBlock: [:integer | integer hash \\ 1064164 * 1009]! Item was changed: ----- Method: PluggableSet class>>integerSet (in category 'instance creation') ----- integerSet ^self new hashBlock: [:integer | integer hash \\ 1064164 * 1009]! Item was removed: - ----- Method: WeakArray class>>pvtCreateTemporaryObjectIn: (in category 'private') ----- - pvtCreateTemporaryObjectIn: tempObject - "We have to create the temporary object in a separate stack frame" - tempObject at: 1 put: Object new! From commits at source.squeak.org Thu Sep 3 01:27:38 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 01:27:40 2015 Subject: [squeak-dev] The Trunk: Balloon-eem.27.mcz Message-ID: Eliot Miranda uploaded a new version of Balloon to project The Trunk: http://source.squeak.org/trunk/Balloon-eem.27.mcz ==================== Summary ==================== Name: Balloon-eem.27 Author: eem Time: 2 September 2015, 6:24:15.595 pm UUID: 8a4e1c60-2480-434a-b65a-37f6cb45c131 Ancestors: Balloon-tfel.26 Remove carriage returns from some time stamps =============== Diff against Balloon-tfel.26 =============== Item was changed: ----- Method: Bezier3Segment class>>from:to: (in category 'instance creation') ----- from: p1 to: p2 ^ self new from: p1 via: (p1 interpolateTo: p2 at: 0.3333) and: (p1 interpolateTo: p2 at: 0.66667) to: p2! Item was changed: ----- Method: Bezier3Segment class>>from:via:and:to: (in category 'instance creation') ----- from: p1 via: p2 and: p3 to: p4 ^ self new from: p1 via: p2 and: p3 to: p4! Item was changed: ----- Method: CompressedBoundaryShape>>bounds (in category 'accessing') ----- bounds | min max width | points isEmpty ifTrue:[^0@0 corner: 1@1]. min := max := points first. points do:[:pt| min := min min: pt. max := max max: pt ]. width := 0. lineWidths valuesDo:[:w| width := width max: w]. ^(min corner: max) insetBy: (width negated asPoint)! From commits at source.squeak.org Thu Sep 3 01:28:07 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 01:28:08 2015 Subject: [squeak-dev] The Trunk: Collections-eem.653.mcz Message-ID: Eliot Miranda uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-eem.653.mcz ==================== Summary ==================== Name: Collections-eem.653 Author: eem Time: 2 September 2015, 6:26:05.268 pm UUID: dfc67d6b-1eaf-42c5-929d-b136b4d28ef0 Ancestors: Collections-cbc.652 Remove carriage returns from some time stamps. Nuke unused private method in old finalization scheme. =============== Diff against Collections-cbc.652 =============== Item was changed: ----- Method: PluggableDictionary class>>integerDictionary (in category 'instance creation') ----- integerDictionary ^ self new hashBlock: [:integer | integer hash \\ 1064164 * 1009]! Item was changed: ----- Method: PluggableSet class>>integerSet (in category 'instance creation') ----- integerSet ^self new hashBlock: [:integer | integer hash \\ 1064164 * 1009]! Item was removed: - ----- Method: WeakArray class>>pvtCreateTemporaryObjectIn: (in category 'private') ----- - pvtCreateTemporaryObjectIn: tempObject - "We have to create the temporary object in a separate stack frame" - tempObject at: 1 put: Object new! From commits at source.squeak.org Thu Sep 3 01:28:34 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 01:28:35 2015 Subject: [squeak-dev] The Trunk: EToys-eem.130.mcz Message-ID: Eliot Miranda uploaded a new version of EToys to project The Trunk: http://source.squeak.org/trunk/EToys-eem.130.mcz ==================== Summary ==================== Name: EToys-eem.130 Author: eem Time: 2 September 2015, 6:26:49.282 pm UUID: 97b8dbd3-1f68-4ec0-9eb6-74e9fadc1c6d Ancestors: EToys-mt.129 Remove carriage returns from a time stamp =============== Diff against EToys-mt.129 =============== Item was changed: ----- Method: ScriptEditorMorph>>fixUponLoad:seg: (in category 'objects from disk') ----- fixUponLoad: aProject seg: anImageSegment "We are in an old project that is being loaded from disk. Fix up conventions that have changed." (aProject projectParameters at: #substitutedFont ifAbsent: [#none]) ~~ #none ifTrue: [ self setProperty: #needsLayoutFixed toValue: true ]. ^ super fixUponLoad: aProject seg: anImageSegment! From commits at source.squeak.org Thu Sep 3 01:29:50 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 01:29:51 2015 Subject: [squeak-dev] The Trunk: Graphics-eem.317.mcz Message-ID: Eliot Miranda uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-eem.317.mcz ==================== Summary ==================== Name: Graphics-eem.317 Author: eem Time: 2 September 2015, 6:29:23.818 pm UUID: 93cbbfd8-00b5-48d8-9ef6-174661f41fa7 Ancestors: Graphics-topa.316 Remove carriage returns from some time stamps =============== Diff against Graphics-topa.316 =============== Item was changed: ----- Method: HostWindowProxy class>>isActiveHostWindowProxyClass (in category 'system startup') ----- isActiveHostWindowProxyClass "subclasses must override this" self subclassResponsibility! Item was changed: ----- Method: HostWindowProxy class>>on: (in category 'initialize-release') ----- on: aSourceForm "Build a new window proxy by finding the appropriate platform specific subclass and setting it up for this Form-like argument" ^ActiveProxyClass new on: aSourceForm! Item was changed: ----- Method: ImageReadWriter class>>putForm:onStream: (in category 'image reading/writing') ----- putForm: aForm onStream: aWriteStream "Store the given form on a file of the given name." | writer | writer := self on: aWriteStream. Cursor write showWhile: [writer nextPutImage: aForm]. writer close. ! From commits at source.squeak.org Thu Sep 3 01:31:22 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 01:31:25 2015 Subject: [squeak-dev] The Trunk: Morphic-eem.1003.mcz Message-ID: Eliot Miranda uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-eem.1003.mcz ==================== Summary ==================== Name: Morphic-eem.1003 Author: eem Time: 2 September 2015, 6:30:31.822 pm UUID: 6acf30a2-82ed-49ea-b87f-85b16c6be607 Ancestors: Morphic-eem.1002 Remove carriage returns from a time stamp =============== Diff against Morphic-eem.1002 =============== Item was changed: ----- Method: MorphicModel>>model: (in category 'initialization') ----- model: anObject "Set my model and make me me a dependent of the given object." model ifNotNil: [model removeDependent: self]. anObject ifNotNil: [anObject addDependent: self]. model := anObject. ! From commits at source.squeak.org Thu Sep 3 01:32:00 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 01:32:02 2015 Subject: [squeak-dev] The Trunk: ST80-eem.187.mcz Message-ID: Eliot Miranda uploaded a new version of ST80 to project The Trunk: http://source.squeak.org/trunk/ST80-eem.187.mcz ==================== Summary ==================== Name: ST80-eem.187 Author: eem Time: 2 September 2015, 6:31:44.86 pm UUID: bea748a4-2680-414e-87d1-a1378120637f Ancestors: ST80-topa.186 Remove carriage returns from a time stamp =============== Diff against ST80-topa.186 =============== Item was changed: ----- Method: PluggableTextView>>model: (in category 'model access') ----- model: aLockedModel "Refer to the comment in View|model:." self model: aLockedModel controller: controller. self editString: self getText. ! From asqueaker at gmail.com Thu Sep 3 03:07:13 2015 From: asqueaker at gmail.com (Chris Muller) Date: Thu Sep 3 03:07:16 2015 Subject: [squeak-dev] Grrrr, how come I can't deselect in a list browser?? In-Reply-To: References: Message-ID: Hi Eliot, its a bug that just needs to be fixed. IIRC, the code is there to make it (AlternatePluggableListMorphOfMany) work just like windows: Shift-click selects the b point of a range, Control-click toggles under the mouse cursor. But because Morphic hijacks the Control key override to present a menu with a lot of duplicate items on it, the Control-toggle functionality does not work. In the meantime, there are a couple of workarounds: 1) select all the methods, then invert the selection (Shift+Command+I "<--- capital eye"). 2) select all the methods, then file them out? Does that work? If not, it should. 3) Turn off the "traceMessages" preference, then re-run your script to capture the methods. The regular PluggableListMorphOfMany deselection works. HTH, Chris On Wed, Sep 2, 2015 at 8:16 PM, Eliot Miranda wrote: > Hi All, > > so I just noticed that there are a few methods which carriage returns in > the time stamp, which is confusing and should be fixed, so I did this to get > a list of said methods: > > CurrentReadOnlySourceFiles cacheDuring: > [self systemNavigation browseAllSelect: [:m| m timeStamp includes: Character > cr]] > > Cool, now I have a list of the methods I need to file-out to quickly fix > their time stamps and the list has the first method selected. But no matter > how many times I click on that method or any other the list browser > resolutely refuses to deselect, completely sabotaging my useful modification > of the file out item in list browsers, committed at least a year ago now, > such that when nothing is selected all methods in the list get filed out. > > I can find no preference which restores unselectability. Can who ever > changed this undo the change please? I am /not/ going to sit there like a > monkey and filter out each individual method. Yes, I *could* try and > deselect by inspecting the thing, but, you know what, I shouldn't have to, > it should deselect like it used to, when I loved it like I used to. > > _,,,^..^,,,_ > best, Eliot > > > From Marcel.Taeumel at hpi.de Thu Sep 3 05:59:13 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Thu Sep 3 06:05:08 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: References: Message-ID: <1441259953070-4847814.post@n4.nabble.com> Hi Eliot, just disable the preference "traceMessages". It makes MessageSet be replaced by MessageTrace, which uses a multi-selection list morph. That does not provide de-selection behavior. But we seriously *must* fix that mess with having subclasses for different selection behavior in list morphs. There should only be one PluggableListMorph that supports the common selection modes. You know, it's on my list. :P Best, Marcel P.S.: Arf woof LeChuck!! GRRRRRRRRR!! Woof woof woof ruff ruff... Wor-roof wuf Governor Marley. A-OOOOOOOOOOOOO!!!!! Ruff ruff ruff bow-roo wuf rowwf arroof LeChuck, GRRRRRR!!!!! Arf oof-oof Monkey Island?! *sniff sniff* -- View this message in context: http://forum.world.st/Grrrr-how-come-I-can-t-deselect-in-a-list-browser-tp4847776p4847814.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From Marcel.Taeumel at hpi.de Thu Sep 3 06:00:42 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Thu Sep 3 06:06:37 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: References: Message-ID: <1441260042517-4847816.post@n4.nabble.com> Hi Chris, no, Morphic does not hijack the control key, the VM does. It converts a control+leftclick into a right click... *sigh* Best, Marcel -- View this message in context: http://forum.world.st/Grrrr-how-come-I-can-t-deselect-in-a-list-browser-tp4847776p4847816.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From Das.Linux at gmx.de Thu Sep 3 06:44:57 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu Sep 3 06:45:02 2015 Subject: [squeak-dev] menu pragmas (was "The Trunk: Monticello-eem.617.mcz") In-Reply-To: References: Message-ID: Hi all On 03.09.2015, at 01:21, Craig Latta wrote: > > Hi all-- > > This is just a new thread to make Eliot's description of menu > pragmas more prominent in the list archives. Perhaps there are others > who, like me, don't read all the "trunk" threads in their entirety and > might miss stuff like this. I read that and I'll comment on all that later. Still on vacation and on my way to the beach. Probably tonight (CEST) :) Best -Tobias > > > thanks, > > -C > > *** > > Tobias writes to Eliot: > >> Can you explain what you want to achieve [with menu pragmas] and how >> I can make [their use] more convenient? > > Eliot responds: > >> We can talk this over when we meet in Palo Alto, but the idea is an >> important one, and I'm paying for having been too lazy to write it up >> properly. Let me try and give a quick sketch here. >> >> The goals are to: >> >> - allow package load to augment menus without the original definitions >> of those menus knowing anything about the subsequently loaded >> packages. >> - to allow menus to be augmented with single actions defined in >> methods that implement those actions >> - and, depending on menu implementation, either >> - if menus are created every time a user invokes a menu, then to >> simply include the relevant extensions in the menu >> - if menus are stored in variables, to automatically construct, or >> reconstruct the menu when either loading or unloading of a package >> changes the items in a menu >> >> We design menu pragmas in action methods to specify: > >> - the (name of the) menu to be extended >> - the text of the menu entry >> - information regarding what group of items the menu item belongs with >> - information regarding the menu item's relative order with respect to >> other elements in the group >> >> Rationale: >> With this specification a package can extend any number of menus in >> tools simply by being loaded, with no collisions with any other >> packages defining extensions on those menus. Tools become freely >> pluggable, and system configurations constructed from different sets >> of loaded packages are decoupled; we don't need many menu >> definitions, just an initial base menu which is extended with the >> current set of extensions. >> >> For this to work we need to "name" menus, and to use some numbering >> scheme to define groups (menu entries between lines) and elements >> within each group. One simple scheme is to use numbers: >> >> - the definitions of initial base menus number groups, so that the >> first group (the items before the first line) is numbered group 10, >> and the second group 20, and so on, allowing extensions to specify >> new groups by using group numbers that are not a multiple of 10 >> - the definitions of entries within groups are numbered, again in >> multiples of 10, so that the extension can fit anywhere in the >> group >> >> So given: >> >> MenuMorph fromArray: { >> {'find...(f)' translated. #find}. >> {'find again (g)' translated. #findAgain}. >> {'set search string (h)' translated. #setSearchString}. >> #-. >> {'do again (j)' translated. #again}. >> {'undo (z)' translated. #undo}. >> #-. >> {'copy (c)' translated. #copySelection}. >> {'cut (x)' translated. #cut}. >> {'paste (v)' translated. #paste}. >> {'paste...' translated. #pasteRecent}. >> #-. >> {'set font... (k)' translated. #offerFontMenu}. >> {'set style... (K)' translated. #changeStyle}. >> {'set alignment...' translated. #chooseAlignment}. >> " >> #-. >> {'more...' translated. #shiftedTextPaneMenuRequest}. >> " >> } >> >> you could imagine the following numberings: >> >> 10.01 find >> 10.02 findAgain >> 10.03 setSearchString >> - >> 20.01 again >> 20.02 undo >> - >> 30.01 copySelection >> 30.02 cut >> 30.03 paste >> 30.04 pasteRecent >> - >> 40.01 offerFontMenu >> 40.02 changeStyle >> 40.03 chooseAlignment >> >> So I can specify e.g. a new group inserted before the first one by >> using, e.g. 5.005 as an index, and can slot an item between again and >> undo using 20.015, etc. >> >> This gives us menu pragmas that look like: >> >> TextEditor methodsFor: '*SpellChecker-extensions' stamp: 'mad hacker >> 9/9/1999' >> spellCheck >> > label: 'spell check selection (s)' >> position: 10.035> >> ...code implementing spell checking... >> >> (note that the action, #spellCheck, is implicit, it is the selector of >> the method containing the pragma) >> >> and: >> >> - if menus are created every time a user invokes a menu, then search >> for pragmas within the relevant class hierarchy, compute, sort and >> insert individual extensions to the menu >> - if menus are stored in variables, to have compilation and method >> removal send a message to the class to/from which method(s) are >> added/removed so that the class can recompute menus (as in the line >> above) when code is added/removed. >> >> What I saw in ChangeSorter was quite different. It seems to be a way >> of specifying entire menus, and I'm not sure how these menus are to be >> combined. Maybe I'm misunderstanding the way the scheme is supposed >> to work. What I've described above is very close to the one that >> pragmas came from in the first place, which was my attempt to >> decouple the components that could be loaded into VisualWorks when we >> decomposed the system into easily loadable parcels. Up until that >> point VisualWorks had had all its tool menus predefined, disabling >> items that were to do with components delivered as file-ins that >> weren't yet filed-in. It was too rigid. It didn't allow for future >> expansion. And so I had the idea of menu pragmas to decouple >> things. Steve Dahl then came up with the scheme to define a base >> menu, number its items appropriately, and extend the menu. >> >> One of the things that's really nice about the VisualWorks scheme is >> that the menu pragma itself is actually implemented (remember that >> pragmas are Message instances with literal parameters). The class >> MenuBuilder (IIRC) implemented various menu pragma methods so the >> pattern is: >> >> - in the method that defines the base menu, define the base menu, >> create an editor on it, ask the editor to collect the pragmas and >> augment the menu with those found >> - the menu editor then collects the menu pragmas and then performs >> each one to collect the information from it >> >> So one can find other menu pragmas using senders, and find the editor >> using implementors, and one can extend the scheme by adding additional >> methods to MenuEditor, again possibly loaded from packages. >> >> >> HTH >> >> _,,,^..^,,,_ >> best, Eliot > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > From Das.Linux at gmx.de Thu Sep 3 06:46:05 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu Sep 3 06:46:08 2015 Subject: [squeak-dev] The Trunk: Collections-eem.653.mcz Message-ID: <103E42BB-4E21-4444-BB92-5290E50E4FF0@gmx.de> Why is pvtCreateTemporaryObjectIn: removed? Best regards -Tobias On 03.09.2015, at 01:27, commits@source.squeak.org wrote: > Eliot Miranda uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-eem.653.mcz > > ==================== Summary ==================== > > Name: Collections-eem.653 > Author: eem > Time: 2 September 2015, 6:26:05.268 pm > UUID: dfc67d6b-1eaf-42c5-929d-b136b4d28ef0 > Ancestors: Collections-cbc.652 > > Remove carriage returns from some time stamps. > Nuke unused private method in old finalization scheme. > > =============== Diff against Collections-cbc.652 =============== > > Item was changed: From Marcel.Taeumel at hpi.de Thu Sep 3 11:30:42 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Thu Sep 3 11:36:40 2015 Subject: [squeak-dev] #firstOrLess: and #lastOrLess: ? Message-ID: <1441279842980-4847874.post@n4.nabble.com> Hi -- Is there a better way to get a limited number of elements from a collection but accept less if the collection is not big enough? someObjects size >= 5 ifTrue: [someObjects first: 5] ifFalse: [someObjects]. Could we add a #firstOrLess:? Similar thoughts on #firstOrNil, #lastOrNil, and #lastOrLess:. Best, Marcel -- View this message in context: http://forum.world.st/firstOrLess-and-lastOrLess-tp4847874.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From craig at netjam.org Thu Sep 3 12:22:08 2015 From: craig at netjam.org (Craig Latta) Date: Thu Sep 3 12:22:31 2015 Subject: [squeak-dev] FFI callbacks Message-ID: Hi all-- I'd like to use a C shared library via FFI from Squeak or Pharo. Specifically, I want to call a C function which takes as one of its parameters a pointer to an array of callback function addresses. Does one of the FFI approaches floating around handle that, and provide a relatively pleasant mapping between Smalltalk block closures and C callback function addresses? I was doing this so far in GemStone, but apparently its FFI only supports passing callback function addresses one at a time as direct parameters of C callouts. I suppose I could write a wrapper C library around the one I really want to use, that provides the callback setup interface that GemStone expects, but whenever I have to write actual C code I start to think "Hm, why don't I just use a Smalltalk VM for which I have the source?" :) All the fancy distributed object-database stuff that my project also wants can wait for a bit. thanks! -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From craig at netjam.org Thu Sep 3 12:24:22 2015 From: craig at netjam.org (Craig Latta) Date: Thu Sep 3 12:25:08 2015 Subject: [squeak-dev] re: #firstOrLess: and #lastOrLess: ? In-Reply-To: <1441279842980-4847874.post@n4.nabble.com> References: <1441279842980-4847874.post@n4.nabble.com> Message-ID: Hi Marcel-- > Is there a better way to get a limited number of elements from a > collection but accept less if the collection is not big enough? Traditionally, that would be Stream>>nextAvailable:. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From karlramberg at gmail.com Thu Sep 3 14:00:33 2015 From: karlramberg at gmail.com (karl ramberg) Date: Thu Sep 3 14:00:39 2015 Subject: [squeak-dev] #firstOrLess: and #lastOrLess: ? In-Reply-To: <1441279842980-4847874.post@n4.nabble.com> References: <1441279842980-4847874.post@n4.nabble.com> Message-ID: The name firstOrLess: is a little confusing. Maybe something like collectMax: Karl On Thu, Sep 3, 2015 at 1:30 PM, marcel.taeumel wrote: > Hi -- > > Is there a better way to get a limited number of elements from a collection > but accept less if the collection is not big enough? > > someObjects size >= 5 > ifTrue: [someObjects first: 5] > ifFalse: [someObjects]. > > Could we add a #firstOrLess:? Similar thoughts on #firstOrNil, #lastOrNil, > and #lastOrLess:. > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/firstOrLess-and-lastOrLess-tp4847874.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150903/9276fe5e/attachment-0001.htm From Marcel.Taeumel at hpi.de Thu Sep 3 14:32:03 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Thu Sep 3 14:38:01 2015 Subject: [squeak-dev] Re: #firstOrLess: and #lastOrLess: ? In-Reply-To: References: <1441279842980-4847874.post@n4.nabble.com> Message-ID: <1441290723273-4847907.post@n4.nabble.com> It's no "collect" but a "first: n", which returns the first n elements from a collection. So #nextAvailable: reads nice but this is stream semantics. There is no #next for collections. -- View this message in context: http://forum.world.st/firstOrLess-and-lastOrLess-tp4847874p4847907.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From craig at netjam.org Thu Sep 3 14:40:19 2015 From: craig at netjam.org (Craig Latta) Date: Thu Sep 3 14:40:34 2015 Subject: [squeak-dev] re: #firstOrLess: and #lastOrLess: ? In-Reply-To: <1441290723273-4847907.post@n4.nabble.com> References: <1441279842980-4847874.post@n4.nabble.com> <1441290723273-4847907.post@n4.nabble.com> Message-ID: > ...#nextAvailable: reads nice but this is stream semantics. There is > no #next for collections. That was a suggestion that you should be using a stream. :) -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From asqueaker at gmail.com Thu Sep 3 14:40:39 2015 From: asqueaker at gmail.com (Chris Muller) Date: Thu Sep 3 14:40:43 2015 Subject: [squeak-dev] Re: #firstOrLess: and #lastOrLess: ? In-Reply-To: <1441290723273-4847907.post@n4.nabble.com> References: <1441279842980-4847874.post@n4.nabble.com> <1441290723273-4847907.post@n4.nabble.com> Message-ID: If you *DID* implement a new method, I'd call it, "upToFirst:". someObjects upToFirst: 5 However, I don't think its worth expanding the API; I would just do someObject first: (5 min: someObject size) It's not that hard to read. On Thu, Sep 3, 2015 at 9:32 AM, marcel.taeumel wrote: > It's no "collect" but a "first: n", which returns the first n elements from a > collection. So #nextAvailable: reads nice but this is stream semantics. > There is no #next for collections. > > > > -- > View this message in context: http://forum.world.st/firstOrLess-and-lastOrLess-tp4847874p4847907.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > From eliot.miranda at gmail.com Thu Sep 3 15:07:16 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Sep 3 15:07:23 2015 Subject: [squeak-dev] Re: #firstOrLess: and #lastOrLess: ? In-Reply-To: References: <1441279842980-4847874.post@n4.nabble.com> <1441290723273-4847907.post@n4.nabble.com> Message-ID: <8FFDA3CA-F503-4171-B907-3A0823BAB176@gmail.com> Sent from my iPhone > On Sep 3, 2015, at 7:40 AM, Chris Muller wrote: > > If you *DID* implement a new method, I'd call it, "upToFirst:". > > someObjects upToFirst: 5 I find this slightly ambiguous with upTo: and upThrough:. Why not atMostFirst: and atMostLast: ? > > However, I don't think its worth expanding the API; I would just do > > someObject first: (5 min: someObject size) > > It's not that hard to read. > >> On Thu, Sep 3, 2015 at 9:32 AM, marcel.taeumel wrote: >> It's no "collect" but a "first: n", which returns the first n elements from a >> collection. So #nextAvailable: reads nice but this is stream semantics. >> There is no #next for collections. >> >> >> >> -- >> View this message in context: http://forum.world.st/firstOrLess-and-lastOrLess-tp4847874p4847907.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >> > From asqueaker at gmail.com Thu Sep 3 15:09:29 2015 From: asqueaker at gmail.com (Chris Muller) Date: Thu Sep 3 15:09:30 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: <1441259953070-4847814.post@n4.nabble.com> References: <1441259953070-4847814.post@n4.nabble.com> Message-ID: > But we seriously *must* fix that mess with having subclasses for different > selection behavior in list morphs. There should only be one > PluggableListMorph that supports the common selection modes. "*Must* fix"? Really? Its just 13 methods! They're the very first methods I ever wrote for Squeak back in January 2002, and have used heavily ever since. If the VM won't be fixed can't we just find another fix for the deselection bug? > You know, it's on my list. :P This widget provides a specific set of low-level gestures optimized for list pruning, which is what traceMessages needs. If you go "cleaning it up" and reducing it to a lowest-common-denominator functionality, there really could be some woofing and barking around here. :) Ha ha, no seriously, if you feel the need to clean it, lets please review the usage cases, there are very good reasons I took the trouble to write that instead of using the original.. From tim at rowledge.org Thu Sep 3 17:01:12 2015 From: tim at rowledge.org (tim Rowledge) Date: Thu Sep 3 17:01:16 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: <1441260042517-4847816.post@n4.nabble.com> References: <1441260042517-4847816.post@n4.nabble.com> Message-ID: <1EB44556-40FE-475C-B3FA-EBA8862B8DD4@rowledge.org> On 02-09-2015, at 11:00 PM, marcel.taeumel wrote: > Hi Chris, > > no, Morphic does not hijack the control key, the VM does. It converts a > control+leftclick into a right click... *sigh* Oh, it?s not *that* simple. Different vms do different things, usually in the name of being helpful. There?s far too much low-level codewhere it seems obvious that person A thought the vm should deal with some issue and person B didn?t know, or disagreed, and so handled it in the image. And, err, miaow. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FSE: Fake Serious Error From asqueaker at gmail.com Thu Sep 3 18:50:46 2015 From: asqueaker at gmail.com (Chris Muller) Date: Thu Sep 3 18:50:48 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: <1441259953070-4847814.post@n4.nabble.com> References: <1441259953070-4847814.post@n4.nabble.com> Message-ID: Hi Marcel, I know what you are saying now, keep the same behaviors with boolean options (or whatever) all in one class instead of subclassing. For a moment I thought you meant to simply delete AlternatePluggableListMOrphOfMany (sheesh, what a name). Sorry for the poor humor. Incidentally, the reason it is that kind of subclasssing mess is, back in 2002, Squeak was being developed at a big company and one never knew what the next version of Squeak would bring, so it was an inhibiting factor for making very many base changes. By making my own subclass, I could keep my code separate. Eventually it was integrated into the base image, but left as-is because it had been simply working for so long. I'm trying to remember if there are any other differences in requirements between the two other than the swipe gesture getting all the elements -- maybe that would be a good behavior for where we use the standard PluggableListMorphOfMany..? (And fix the deselection, of course). On Thu, Sep 3, 2015 at 12:59 AM, marcel.taeumel wrote: > Hi Eliot, > > just disable the preference "traceMessages". It makes MessageSet be replaced > by MessageTrace, which uses a multi-selection list morph. That does not > provide de-selection behavior. > > But we seriously *must* fix that mess with having subclasses for different > selection behavior in list morphs. There should only be one > PluggableListMorph that supports the common selection modes. > > You know, it's on my list. :P > > Best, > Marcel > > P.S.: Arf woof LeChuck!! GRRRRRRRRR!! Woof woof woof ruff ruff... Wor-roof > wuf Governor Marley. A-OOOOOOOOOOOOO!!!!! Ruff ruff ruff bow-roo wuf rowwf > arroof LeChuck, GRRRRRR!!!!! Arf oof-oof Monkey Island?! *sniff sniff* > > > > -- > View this message in context: http://forum.world.st/Grrrr-how-come-I-can-t-deselect-in-a-list-browser-tp4847776p4847814.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > From commits at source.squeak.org Thu Sep 3 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 3 21:55:03 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150903215502.2935.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008946.html Name: MonticelloConfigurations-dtl.137 Ancestors: MonticelloConfigurations-dtl.136 Fix updating the default update map name from preferences. Change constructor to avoid conflict with setter used by the preference. When the preference for default update map changes, initialize with a new default updater. The previous updater for the default update URL is replaced because its remembered position in the update stream will not be valid for a different update map sequence. Therefore ask confirmation from the user before accepting the preference change. Class var UpdateMapName is no longer needed, remove it. The LastUpdateMap class var was retained to support transition to instance based updaters. Remove it now. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008947.html Name: Collections-eem.653 Ancestors: Collections-cbc.652 Remove carriage returns from some time stamps. Nuke unused private method in old finalization scheme. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008948.html Name: Balloon-eem.27 Ancestors: Balloon-tfel.26 Remove carriage returns from some time stamps ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008949.html Name: Collections-eem.653 Ancestors: Collections-cbc.652 Remove carriage returns from some time stamps. Nuke unused private method in old finalization scheme. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008950.html Name: EToys-eem.130 Ancestors: EToys-mt.129 Remove carriage returns from a time stamp ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008951.html Name: Graphics-eem.317 Ancestors: Graphics-topa.316 Remove carriage returns from some time stamps ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008952.html Name: Morphic-eem.1003 Ancestors: Morphic-eem.1002 Remove carriage returns from a time stamp ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008953.html Name: ST80-eem.187 Ancestors: ST80-topa.186 Remove carriage returns from a time stamp ============================================= From eliot.miranda at gmail.com Thu Sep 3 23:07:49 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Sep 3 23:07:53 2015 Subject: [squeak-dev] FFI callbacks In-Reply-To: References: Message-ID: Hi Craig, you need Alien-eem.24 Here's Alien class>>exampleCqsort "Call the libc qsort function (which requires a callback)." "Alien exampleCqsort" "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / 100.0" | cb rand nElements sizeofDouble values orig sort | rand := Random new. values := Alien newC: (nElements := 100) * (sizeofDouble := 8). 1 to: values dataSize by: sizeofDouble do: [:i| values doubleAt: i put: rand next]. orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values doubleAt: i]. cb := Callback signature: #(int (*)(const void *, const void *)) block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. (Alien lookup: 'qsort' inLibrary: Alien libcName) primFFICallResult: nil with: values pointer with: nElements with: sizeofDouble with: cb thunk. sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values doubleAt: i]. values free. ^orig -> sort The above example uses Alien to make the callout. To use it with the FFI simply pass cb pointer as the argument as is done above. Implementation: The way that it works is in two parts - the VM passes up a pointer to a structure from which all arguments, stacked and in registers (because the VM has copied the register args into the struct) can be accessed, and through which the result can be returned. - the image level provides marshalling methods that match the signature in the callback So e.g. with a callback of Callback signature: #(int (*)(const void *, const void *)) block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] the marshalling methods are in Callback's signature protocol: Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien ^callbackContext wordResult: (block value: (Alien forPointer: (spAlien unsignedLongAt: 1)) value: (Alien forPointer: (spAlien unsignedLongAt: 5))) where spAlien is an Alien pointing to a VMCallbackContext32. For ARM support we would add Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien intRegArgs: regsAlien ^callbackContext wordResult: (block value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) Basically the idea is that the selector of the method doesn't matter except for the number of arguments. What's important is the pragma which defines the signature and the ABI for which this is a valid marshalling method. When the callback is instantiated, Callback introspects to find the marshalling method that matches the signature. If one doesn't already exist you can write one. Hopefully we'll write an ABI compiler that will automatically generate these marshalling methods according to the platform's ABI, but for now its a manual process. But at least it's open and flexible. When the callback is invoked the evaluator is performed with the current callbackContext and pointer(s) to the arguments. There is a 32-bit and a 64-bit callback context, and it can have a stack pointer, integer register args and floating point register args. So it's general enough for any callback. To pass back the result, a value is assigned into the struct via the accessor in the marshalling method and control returns to teh point where teh callback comes in, and this uses a primitive to return. Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive longjmp's back to the entry point in the VM which extracts the result and the code for the kind of result and returns: Callback class>>invokeCallbackContext: vmCallbackContextAddress "" "^" "The low-level entry-point for callbacks sent from the VM/IA32ABI plugin. Return via primReturnFromContext:through:. thisContext's sender is the call-out context." | callbackAlien type | callbackAlien := (Smalltalk wordSize = 4 ifTrue: [VMCallbackContext32] ifFalse: [VMCallbackContext64]) atAddress: vmCallbackContextAddress. [type := Callback evaluateCallbackForContext: callbackAlien] ifCurtailed: [self error: 'attempt to non-local return across a callback']. type ifNil: [type := 1. callbackAlien wordResult: -1]. callbackAlien primReturnAs: type fromContext: thisContext On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta wrote: > > Hi all-- > > I'd like to use a C shared library via FFI from Squeak or Pharo. > Specifically, I want to call a C function which takes as one of its > parameters a pointer to an array of callback function addresses. Does > one of the FFI approaches floating around handle that, and provide a > relatively pleasant mapping between Smalltalk block closures and C > callback function addresses? > > I was doing this so far in GemStone, but apparently its FFI only > supports passing callback function addresses one at a time as direct > parameters of C callouts. I suppose I could write a wrapper C library > around the one I really want to use, that provides the callback setup > interface that GemStone expects, but whenever I have to write actual C > code I start to think "Hm, why don't I just use a Smalltalk VM for which > I have the source?" :) All the fancy distributed object-database stuff > that my project also wants can wait for a bit. > > > thanks! > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150903/84bb7f82/attachment.htm From eliot.miranda at gmail.com Thu Sep 3 23:37:57 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Sep 3 23:38:00 2015 Subject: [squeak-dev] Process Priorities in Finalization Message-ID: Hi All, can anyone who understands finalization tell me if changing the priority of the finalization process can kill things. I'm seeing the sources file get closed after a while when running my revised finalization code, and I can't see exactly why. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150903/89546121/attachment.htm From brasspen at gmail.com Fri Sep 4 01:05:07 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Fri Sep 4 01:05:11 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: Message-ID: <55E8EE43.7040608@gmail.com> This community needs a repository for plugins. A directory at http://ftp.squeak.org ought to do it. If I want to try Alien I need the plugin. Where am I going to get that? I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see it is not saying Newspeak and realize it compiles a plugin called IA32ABI, which - coincidentally - is the name of the plugin the error Alien exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> moduleName returns IA32ABI). Does anybody know what the Genie plugin does? Does Paul DeBrucker need to store a BerkeleyDB plugin dll he got by emailing somebody on GitHub? If I understand this correctly, if such a directory existed, then all a person would need to do to try the above Alien code would be to download a pre-compiled plugin from - say - http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM directory and start the image. Then check with SmalltalkImage current listLoadedModules to see if you're ready to go. I nominate Fabio Niephaus to be the person the community can send pre-compiled plugins for inclusion in such a directory. Eliot's been banging away about Alien for some time [1]. If a person could go, get the plugin and give the code shot, he could have more productive conversations about Alien. So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in an idle moment, you could email it to Fabio? And when, Fabio, you've created the directory in http://ftp.squeak.org you could announce it here on Squeak-dev? FWIW, Chris [1] http://wiki.squeak.org/squeak/uploads/6100/ On 2015-09-03 7:07 PM, Eliot Miranda wrote: > Hi Craig, > > you need Alien-eem.24 > > Here's Alien class>>exampleCqsort > "Call the libc qsort function (which requires a callback)." > "Alien exampleCqsort" > "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / > 100.0" > | cb rand nElements sizeofDouble values orig sort | > rand := Random new. > values := Alien newC: (nElements := 100) * (sizeofDouble := 8). > 1 to: values dataSize by: sizeofDouble do: > [:i| values doubleAt: i put: rand next]. > orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values > doubleAt: i]. > cb := Callback > signature: #(int (*)(const void *, const void *)) > block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. > (Alien lookup: 'qsort' inLibrary: Alien libcName) > primFFICallResult: nil > with: values pointer > with: nElements > with: sizeofDouble > with: cb thunk. > sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values > doubleAt: i]. > values free. > ^orig -> sort > > The above example uses Alien to make the callout. To use it with the > FFI simply pass cb pointer as the argument as is done above. > > > Implementation: > > The way that it works is in two parts > - the VM passes up a pointer to a structure from which all arguments, > stacked and in registers (because the VM has copied the register args > into the struct) can be accessed, and through which the result can be > returned. > - the image level provides marshalling methods that match the > signature in the callback > > So e.g. with a callback of > Callback > signature: #(int (*)(const void *, const void *)) > block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] > the marshalling methods are in Callback's signature protocol: > > Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien > > ^callbackContext wordResult: > (block > value: (Alien forPointer: (spAlien unsignedLongAt: 1)) > value: (Alien forPointer: (spAlien unsignedLongAt: 5))) > > where spAlien is an Alien pointing to a VMCallbackContext32. > > For ARM support we would add > > Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien > intRegArgs: regsAlien > > ^callbackContext wordResult: > (block > value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) > value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) > > Basically the idea is that the selector of the method doesn't matter > except for the number of arguments. What's important is the pragma > which defines the signature and the ABI for which this is a valid > marshalling method. > > When the callback is instantiated, Callback introspects to find the > marshalling method that matches the signature. If one doesn't already > exist you can write one. Hopefully we'll write an ABI compiler that > will automatically generate these marshalling methods according to the > platform's ABI, but for now its a manual process. But at least it's > open and flexible. When the callback is invoked the evaluator is > performed with the current callbackContext and pointer(s) to the > arguments. There is a 32-bit and a 64-bit callback context, and it can > have a stack pointer, integer register args and floating point > register args. So it's general enough for any callback. > > To pass back the result, a value is assigned into the struct via the > accessor in the marshalling method and control returns to teh point > where teh callback comes in, and this uses a primitive to return. > Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive > longjmp's back to the entry point in the VM which extracts the result > and the code for the kind of result and returns: > > Callback class>>invokeCallbackContext: vmCallbackContextAddress > "" "^" > "The low-level entry-point for callbacks sent from the VM/IA32ABI plugin. > Return via primReturnFromContext:through:. thisContext's sender is the > call-out context." > | callbackAlien type | > callbackAlien := (Smalltalk wordSize = 4 > ifTrue: [VMCallbackContext32] > ifFalse: [VMCallbackContext64]) > atAddress: vmCallbackContextAddress. > [type := Callback evaluateCallbackForContext: callbackAlien] > ifCurtailed: [self error: 'attempt to non-local return across a > callback']. > type ifNil: > [type := 1. callbackAlien wordResult: -1]. > callbackAlien primReturnAs: type fromContext: thisContext > > On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta > wrote: > > > Hi all-- > > I'd like to use a C shared library via FFI from Squeak or Pharo. > Specifically, I want to call a C function which takes as one of its > parameters a pointer to an array of callback function addresses. Does > one of the FFI approaches floating around handle that, and provide a > relatively pleasant mapping between Smalltalk block closures and C > callback function addresses? > > I was doing this so far in GemStone, but apparently its FFI only > supports passing callback function addresses one at a time as direct > parameters of C callouts. I suppose I could write a wrapper C library > around the one I really want to use, that provides the callback setup > interface that GemStone expects, but whenever I have to write actual C > code I start to think "Hm, why don't I just use a Smalltalk VM for > which > I have the source?" :) All the fancy distributed object-database > stuff > that my project also wants can wait for a bit. > > > thanks! > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > > > > -- > _,,,^..^,,,_ > best, Eliot > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150903/15feca28/attachment.htm From lewis at mail.msen.com Fri Sep 4 01:31:16 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Sep 4 01:31:20 2015 Subject: [squeak-dev] Process Priorities in Finalization In-Reply-To: References: Message-ID: <20150904013116.GA67624@shell.msen.com> On Thu, Sep 03, 2015 at 04:37:57PM -0700, Eliot Miranda wrote: > Hi All, > > can anyone who understands finalization tell me if changing the > priority of the finalization process can kill things. I'm seeing the > sources file get closed after a while when running my revised finalization > code, and I can't see exactly why. > > _,,,^..^,,,_ > best, Eliot I won't pretend to be a person who understands finalization, but one way or another I am quite sure that the answer to your first question is going to be yes. The finalizer runs at UserInterruptPriority, which is between UserSchedulingPriority and LowIOPriority. On the face of it this seems to make good sense. What are you trying to change it to and why? I have a general rule of thumb that says "raising the priority of anything will produce the opposite of the intended effect". This is not a very scientific priniciple, but it is usually not wrong (*). Dave (*) Oddly enough, this seems to be equally applicable to scheduling priorities in the domain of project management. From lewis at mail.msen.com Fri Sep 4 02:07:11 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Sep 4 02:07:13 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: <55E8EE43.7040608@gmail.com> References: <55E8EE43.7040608@gmail.com> Message-ID: <20150904020711.GB67624@shell.msen.com> On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote: > This community needs a repository for plugins. A directory at > http://ftp.squeak.org ought to do it. > > If I want to try Alien I need the plugin. Where am I going to get that? > I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see it > is not saying Newspeak and realize it compiles a plugin called IA32ABI, > which - coincidentally - is the name of the plugin the error Alien > exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> moduleName > returns IA32ABI). > > Does anybody know what the Genie plugin does? Does Paul DeBrucker need > to store a BerkeleyDB plugin dll he got by emailing somebody on GitHub? > > If I understand this correctly, if such a directory existed, then all a > person would need to do to try the above Alien code would be to download > a pre-compiled plugin from - say - > http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM directory > and start the image. Then check with SmalltalkImage current > listLoadedModules to see if you're ready to go. > > I nominate Fabio Niephaus to be the person the community can send > pre-compiled plugins for inclusion in such a directory. Eliot's been > banging away about Alien for some time [1]. If a person could go, get > the plugin and give the code shot, he could have more productive > conversations about Alien. > > So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in an > idle moment, you could email it to Fabio? And when, Fabio, you've > created the directory in http://ftp.squeak.org you could announce it > here on Squeak-dev? > > FWIW, > > Chris A word of caution: I think the idea is good in principle, but it needs to be accompanied by a commitment by someone to do the hard work of keeping track of dependencies on the various flavors of OS, image word size, VM word size, spur/V3, and so forth. If someone would like to take that on, great. That said, we don't want to start a project that gets 80% completed, and then expect "the community" to do the rest of the work. I cannot speak for Fabio, but I don't think it is fair for us to expect him to take on this kind of workload unless he has indicated an interest in doing it. Maybe a restricted repository focused just on compiled plugins known to work with the Spur VM on a limited range of OS flavors would be helpful at this stage. It probably does not belong on ftp.squeak.org, but it could be a very useful resource if someone (Chris Cunnington?) wants to set it up. Dave > > [1] http://wiki.squeak.org/squeak/uploads/6100/ > > On 2015-09-03 7:07 PM, Eliot Miranda wrote: > >Hi Craig, > > > > you need Alien-eem.24 > > > >Here's Alien class>>exampleCqsort > >"Call the libc qsort function (which requires a callback)." > >"Alien exampleCqsort" > >"(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / > >100.0" > >| cb rand nElements sizeofDouble values orig sort | > >rand := Random new. > >values := Alien newC: (nElements := 100) * (sizeofDouble := 8). > >1 to: values dataSize by: sizeofDouble do: > >[:i| values doubleAt: i put: rand next]. > >orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values > >doubleAt: i]. > >cb := Callback > >signature: #(int (*)(const void *, const void *)) > >block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. > >(Alien lookup: 'qsort' inLibrary: Alien libcName) > >primFFICallResult: nil > >with: values pointer > >with: nElements > >with: sizeofDouble > >with: cb thunk. > >sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values > >doubleAt: i]. > >values free. > >^orig -> sort > > > >The above example uses Alien to make the callout. To use it with the > >FFI simply pass cb pointer as the argument as is done above. > > > > > >Implementation: > > > >The way that it works is in two parts > >- the VM passes up a pointer to a structure from which all arguments, > >stacked and in registers (because the VM has copied the register args > >into the struct) can be accessed, and through which the result can be > >returned. > >- the image level provides marshalling methods that match the > >signature in the callback > > > >So e.g. with a callback of > >Callback > >signature: #(int (*)(const void *, const void *)) > >block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] > >the marshalling methods are in Callback's signature protocol: > > > >Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien > > > >^callbackContext wordResult: > >(block > >value: (Alien forPointer: (spAlien unsignedLongAt: 1)) > >value: (Alien forPointer: (spAlien unsignedLongAt: 5))) > > > >where spAlien is an Alien pointing to a VMCallbackContext32. > > > >For ARM support we would add > > > >Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien > >intRegArgs: regsAlien > > > >^callbackContext wordResult: > >(block > >value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) > >value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) > > > >Basically the idea is that the selector of the method doesn't matter > >except for the number of arguments. What's important is the pragma > >which defines the signature and the ABI for which this is a valid > >marshalling method. > > > >When the callback is instantiated, Callback introspects to find the > >marshalling method that matches the signature. If one doesn't already > >exist you can write one. Hopefully we'll write an ABI compiler that > >will automatically generate these marshalling methods according to the > >platform's ABI, but for now its a manual process. But at least it's > >open and flexible. When the callback is invoked the evaluator is > >performed with the current callbackContext and pointer(s) to the > >arguments. There is a 32-bit and a 64-bit callback context, and it can > >have a stack pointer, integer register args and floating point > >register args. So it's general enough for any callback. > > > >To pass back the result, a value is assigned into the struct via the > >accessor in the marshalling method and control returns to teh point > >where teh callback comes in, and this uses a primitive to return. > >Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive > >longjmp's back to the entry point in the VM which extracts the result > >and the code for the kind of result and returns: > > > >Callback class>>invokeCallbackContext: vmCallbackContextAddress > >"" "^" > >"The low-level entry-point for callbacks sent from the VM/IA32ABI plugin. > >Return via primReturnFromContext:through:. thisContext's sender is the > >call-out context." > >| callbackAlien type | > >callbackAlien := (Smalltalk wordSize = 4 > >ifTrue: [VMCallbackContext32] > >ifFalse: [VMCallbackContext64]) > >atAddress: vmCallbackContextAddress. > >[type := Callback evaluateCallbackForContext: callbackAlien] > >ifCurtailed: [self error: 'attempt to non-local return across a > >callback']. > >type ifNil: > >[type := 1. callbackAlien wordResult: -1]. > >callbackAlien primReturnAs: type fromContext: thisContext > > > >On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta >> wrote: > > > > > > Hi all-- > > > > I'd like to use a C shared library via FFI from Squeak or Pharo. > > Specifically, I want to call a C function which takes as one of its > > parameters a pointer to an array of callback function addresses. Does > > one of the FFI approaches floating around handle that, and provide a > > relatively pleasant mapping between Smalltalk block closures and C > > callback function addresses? > > > > I was doing this so far in GemStone, but apparently its FFI only > > supports passing callback function addresses one at a time as direct > > parameters of C callouts. I suppose I could write a wrapper C library > > around the one I really want to use, that provides the callback setup > > interface that GemStone expects, but whenever I have to write actual C > > code I start to think "Hm, why don't I just use a Smalltalk VM for > > which > > I have the source?" :) All the fancy distributed object-database > > stuff > > that my project also wants can wait for a bit. > > > > > > thanks! > > > > -C > > > > -- > > Craig Latta > > netjam.org > > +31 6 2757 7177 (SMS ok) > > + 1 415 287 3547 (no SMS) > > > > > > > > > > > >-- > >_,,,^..^,,,_ > >best, Eliot > > > > > > From brasspen at gmail.com Fri Sep 4 02:49:09 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Fri Sep 4 02:49:13 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: <20150904020711.GB67624@shell.msen.com> References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> Message-ID: <55E906A5.1080209@gmail.com> I'm certainly interested in participating in something that addresses this situation. I do think that anything is better than the current situation. A bucket of any kind in an agreed upon location seems like a good place to start. I hadn't considered that plugins would need meta data or labels. Perhaps the best thing is to leave it as an open question for a few weeks before settling on any kind of solution. A common location for plugins is about as far as my thinking takes me at the moment. I'm sure the collective imagination of the community can come up with a better idea. Chris On 2015-09-03 10:07 PM, David T. Lewis wrote: > On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote: >> This community needs a repository for plugins. A directory at >> http://ftp.squeak.org ought to do it. >> >> If I want to try Alien I need the plugin. Where am I going to get that? >> I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see it >> is not saying Newspeak and realize it compiles a plugin called IA32ABI, >> which - coincidentally - is the name of the plugin the error Alien >> exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> moduleName >> returns IA32ABI). >> >> Does anybody know what the Genie plugin does? Does Paul DeBrucker need >> to store a BerkeleyDB plugin dll he got by emailing somebody on GitHub? >> >> If I understand this correctly, if such a directory existed, then all a >> person would need to do to try the above Alien code would be to download >> a pre-compiled plugin from - say - >> http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM directory >> and start the image. Then check with SmalltalkImage current >> listLoadedModules to see if you're ready to go. >> >> I nominate Fabio Niephaus to be the person the community can send >> pre-compiled plugins for inclusion in such a directory. Eliot's been >> banging away about Alien for some time [1]. If a person could go, get >> the plugin and give the code shot, he could have more productive >> conversations about Alien. >> >> So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in an >> idle moment, you could email it to Fabio? And when, Fabio, you've >> created the directory in http://ftp.squeak.org you could announce it >> here on Squeak-dev? >> >> FWIW, >> >> Chris > A word of caution: > > I think the idea is good in principle, but it needs to be accompanied > by a commitment by someone to do the hard work of keeping track of > dependencies on the various flavors of OS, image word size, VM word size, > spur/V3, and so forth. If someone would like to take that on, great. > That said, we don't want to start a project that gets 80% completed, and > then expect "the community" to do the rest of the work. > > I cannot speak for Fabio, but I don't think it is fair for us to expect > him to take on this kind of workload unless he has indicated an interest > in doing it. > > Maybe a restricted repository focused just on compiled plugins known > to work with the Spur VM on a limited range of OS flavors would be helpful > at this stage. It probably does not belong on ftp.squeak.org, but it could > be a very useful resource if someone (Chris Cunnington?) wants to set it up. > > Dave > > >> [1] http://wiki.squeak.org/squeak/uploads/6100/ >> >> On 2015-09-03 7:07 PM, Eliot Miranda wrote: >>> Hi Craig, >>> >>> you need Alien-eem.24 >>> >>> Here's Alien class>>exampleCqsort >>> "Call the libc qsort function (which requires a callback)." >>> "Alien exampleCqsort" >>> "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / >>> 100.0" >>> | cb rand nElements sizeofDouble values orig sort | >>> rand := Random new. >>> values := Alien newC: (nElements := 100) * (sizeofDouble := 8). >>> 1 to: values dataSize by: sizeofDouble do: >>> [:i| values doubleAt: i put: rand next]. >>> orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>> doubleAt: i]. >>> cb := Callback >>> signature: #(int (*)(const void *, const void *)) >>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. >>> (Alien lookup: 'qsort' inLibrary: Alien libcName) >>> primFFICallResult: nil >>> with: values pointer >>> with: nElements >>> with: sizeofDouble >>> with: cb thunk. >>> sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>> doubleAt: i]. >>> values free. >>> ^orig -> sort >>> >>> The above example uses Alien to make the callout. To use it with the >>> FFI simply pass cb pointer as the argument as is done above. >>> >>> >>> Implementation: >>> >>> The way that it works is in two parts >>> - the VM passes up a pointer to a structure from which all arguments, >>> stacked and in registers (because the VM has copied the register args >>> into the struct) can be accessed, and through which the result can be >>> returned. >>> - the image level provides marshalling methods that match the >>> signature in the callback >>> >>> So e.g. with a callback of >>> Callback >>> signature: #(int (*)(const void *, const void *)) >>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] >>> the marshalling methods are in Callback's signature protocol: >>> >>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>> >>> ^callbackContext wordResult: >>> (block >>> value: (Alien forPointer: (spAlien unsignedLongAt: 1)) >>> value: (Alien forPointer: (spAlien unsignedLongAt: 5))) >>> >>> where spAlien is an Alien pointing to a VMCallbackContext32. >>> >>> For ARM support we would add >>> >>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>> intRegArgs: regsAlien >>> >>> ^callbackContext wordResult: >>> (block >>> value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) >>> value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) >>> >>> Basically the idea is that the selector of the method doesn't matter >>> except for the number of arguments. What's important is the pragma >>> which defines the signature and the ABI for which this is a valid >>> marshalling method. >>> >>> When the callback is instantiated, Callback introspects to find the >>> marshalling method that matches the signature. If one doesn't already >>> exist you can write one. Hopefully we'll write an ABI compiler that >>> will automatically generate these marshalling methods according to the >>> platform's ABI, but for now its a manual process. But at least it's >>> open and flexible. When the callback is invoked the evaluator is >>> performed with the current callbackContext and pointer(s) to the >>> arguments. There is a 32-bit and a 64-bit callback context, and it can >>> have a stack pointer, integer register args and floating point >>> register args. So it's general enough for any callback. >>> >>> To pass back the result, a value is assigned into the struct via the >>> accessor in the marshalling method and control returns to teh point >>> where teh callback comes in, and this uses a primitive to return. >>> Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive >>> longjmp's back to the entry point in the VM which extracts the result >>> and the code for the kind of result and returns: >>> >>> Callback class>>invokeCallbackContext: vmCallbackContextAddress >>> "" "^" >>> "The low-level entry-point for callbacks sent from the VM/IA32ABI plugin. >>> Return via primReturnFromContext:through:. thisContext's sender is the >>> call-out context." >>> | callbackAlien type | >>> callbackAlien := (Smalltalk wordSize = 4 >>> ifTrue: [VMCallbackContext32] >>> ifFalse: [VMCallbackContext64]) >>> atAddress: vmCallbackContextAddress. >>> [type := Callback evaluateCallbackForContext: callbackAlien] >>> ifCurtailed: [self error: 'attempt to non-local return across a >>> callback']. >>> type ifNil: >>> [type := 1. callbackAlien wordResult: -1]. >>> callbackAlien primReturnAs: type fromContext: thisContext >>> >>> On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta >> > wrote: >>> >>> >>> Hi all-- >>> >>> I'd like to use a C shared library via FFI from Squeak or Pharo. >>> Specifically, I want to call a C function which takes as one of its >>> parameters a pointer to an array of callback function addresses. Does >>> one of the FFI approaches floating around handle that, and provide a >>> relatively pleasant mapping between Smalltalk block closures and C >>> callback function addresses? >>> >>> I was doing this so far in GemStone, but apparently its FFI only >>> supports passing callback function addresses one at a time as direct >>> parameters of C callouts. I suppose I could write a wrapper C library >>> around the one I really want to use, that provides the callback setup >>> interface that GemStone expects, but whenever I have to write actual C >>> code I start to think "Hm, why don't I just use a Smalltalk VM for >>> which >>> I have the source?" :) All the fancy distributed object-database >>> stuff >>> that my project also wants can wait for a bit. >>> >>> >>> thanks! >>> >>> -C >>> >>> -- >>> Craig Latta >>> netjam.org >>> +31 6 2757 7177 (SMS ok) >>> + 1 415 287 3547 (no SMS) >>> >>> >>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >>> > From hannes.hirzel at gmail.com Fri Sep 4 03:45:58 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Fri Sep 4 03:46:01 2015 Subject: [squeak-dev] Re: #firstOrLess: and #lastOrLess: ? In-Reply-To: <8FFDA3CA-F503-4171-B907-3A0823BAB176@gmail.com> References: <1441279842980-4847874.post@n4.nabble.com> <1441290723273-4847907.post@n4.nabble.com> <8FFDA3CA-F503-4171-B907-3A0823BAB176@gmail.com> Message-ID: On 9/3/15, Eliot Miranda wrote: > > > Sent from my iPhone > >> On Sep 3, 2015, at 7:40 AM, Chris Muller wrote: >> >> If you *DID* implement a new method, I'd call it, "upToFirst:". >> >> someObjects upToFirst: 5 > > I find this slightly ambiguous with upTo: and upThrough:. Why not > atMostFirst: and atMostLast: ? +1 > >> >> However, I don't think its worth expanding the API; I would just do >> >> someObject first: (5 min: someObject size) >> >> It's not that hard to read. >> >>> On Thu, Sep 3, 2015 at 9:32 AM, marcel.taeumel >>> wrote: >>> It's no "collect" but a "first: n", which returns the first n elements >>> from a >>> collection. So #nextAvailable: reads nice but this is stream semantics. >>> There is no #next for collections. >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/firstOrLess-and-lastOrLess-tp4847874p4847907.html >>> Sent from the Squeak - Dev mailing list archive at Nabble.com. >>> >> > > From asqueaker at gmail.com Fri Sep 4 03:46:08 2015 From: asqueaker at gmail.com (Chris Muller) Date: Fri Sep 4 03:46:11 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: <55E906A5.1080209@gmail.com> References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> Message-ID: > I do think that anything is better than the current situation. A bucket of > any kind in an agreed upon location seems like a good place to start. I totally agree! > I > hadn't considered that plugins would need meta data or labels. They could be put into a .zip file and stored and cataloged somewhere which would be a well-known place for Squeak. And, each plugin would be tagged with one or more hierarchical Category's to indicate the platform and whatever else we wanted... And, if the plugin is compiled and hosted somewhere else, like GitHub, then the Squeak-well-known place should direct the user to THAT external place instead of hosting copies on squeak.org servers... Except as a backup, of course.. Hmm, if only we have something that could do all that... Oh wait, we do!!!! ;-) > Perhaps the best thing is to leave it as an open question for a few weeks > before settling on any kind of solution. A common location for plugins is > about as far as my thinking takes me at the moment. I'm sure the collective > imagination of the community can come up with a better idea. > > Chris > > > On 2015-09-03 10:07 PM, David T. Lewis wrote: >> >> On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote: >>> >>> This community needs a repository for plugins. A directory at >>> http://ftp.squeak.org ought to do it. >>> >>> If I want to try Alien I need the plugin. Where am I going to get that? >>> I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see it >>> is not saying Newspeak and realize it compiles a plugin called IA32ABI, >>> which - coincidentally - is the name of the plugin the error Alien >>> exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> moduleName >>> returns IA32ABI). >>> >>> Does anybody know what the Genie plugin does? Does Paul DeBrucker need >>> to store a BerkeleyDB plugin dll he got by emailing somebody on GitHub? >>> >>> If I understand this correctly, if such a directory existed, then all a >>> person would need to do to try the above Alien code would be to download >>> a pre-compiled plugin from - say - >>> http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM directory >>> and start the image. Then check with SmalltalkImage current >>> listLoadedModules to see if you're ready to go. >>> >>> I nominate Fabio Niephaus to be the person the community can send >>> pre-compiled plugins for inclusion in such a directory. Eliot's been >>> banging away about Alien for some time [1]. If a person could go, get >>> the plugin and give the code shot, he could have more productive >>> conversations about Alien. >>> >>> So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in an >>> idle moment, you could email it to Fabio? And when, Fabio, you've >>> created the directory in http://ftp.squeak.org you could announce it >>> here on Squeak-dev? >>> >>> FWIW, >>> >>> Chris >> >> A word of caution: >> >> I think the idea is good in principle, but it needs to be accompanied >> by a commitment by someone to do the hard work of keeping track of >> dependencies on the various flavors of OS, image word size, VM word size, >> spur/V3, and so forth. If someone would like to take that on, great. >> That said, we don't want to start a project that gets 80% completed, and >> then expect "the community" to do the rest of the work. >> >> I cannot speak for Fabio, but I don't think it is fair for us to expect >> him to take on this kind of workload unless he has indicated an interest >> in doing it. >> >> Maybe a restricted repository focused just on compiled plugins known >> to work with the Spur VM on a limited range of OS flavors would be helpful >> at this stage. It probably does not belong on ftp.squeak.org, but it could >> be a very useful resource if someone (Chris Cunnington?) wants to set it >> up. >> >> Dave >> >> >>> [1] http://wiki.squeak.org/squeak/uploads/6100/ >>> >>> On 2015-09-03 7:07 PM, Eliot Miranda wrote: >>>> >>>> Hi Craig, >>>> >>>> you need Alien-eem.24 >>>> >>>> Here's Alien class>>exampleCqsort >>>> "Call the libc qsort function (which requires a callback)." >>>> "Alien exampleCqsort" >>>> "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / >>>> 100.0" >>>> | cb rand nElements sizeofDouble values orig sort | >>>> rand := Random new. >>>> values := Alien newC: (nElements := 100) * (sizeofDouble := 8). >>>> 1 to: values dataSize by: sizeofDouble do: >>>> [:i| values doubleAt: i put: rand next]. >>>> orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>>> doubleAt: i]. >>>> cb := Callback >>>> signature: #(int (*)(const void *, const void *)) >>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. >>>> (Alien lookup: 'qsort' inLibrary: Alien libcName) >>>> primFFICallResult: nil >>>> with: values pointer >>>> with: nElements >>>> with: sizeofDouble >>>> with: cb thunk. >>>> sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>>> doubleAt: i]. >>>> values free. >>>> ^orig -> sort >>>> >>>> The above example uses Alien to make the callout. To use it with the >>>> FFI simply pass cb pointer as the argument as is done above. >>>> >>>> >>>> Implementation: >>>> >>>> The way that it works is in two parts >>>> - the VM passes up a pointer to a structure from which all arguments, >>>> stacked and in registers (because the VM has copied the register args >>>> into the struct) can be accessed, and through which the result can be >>>> returned. >>>> - the image level provides marshalling methods that match the >>>> signature in the callback >>>> >>>> So e.g. with a callback of >>>> Callback >>>> signature: #(int (*)(const void *, const void *)) >>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] >>>> the marshalling methods are in Callback's signature protocol: >>>> >>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>>> >>>> ^callbackContext wordResult: >>>> (block >>>> value: (Alien forPointer: (spAlien unsignedLongAt: 1)) >>>> value: (Alien forPointer: (spAlien unsignedLongAt: 5))) >>>> >>>> where spAlien is an Alien pointing to a VMCallbackContext32. >>>> >>>> For ARM support we would add >>>> >>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>>> intRegArgs: regsAlien >>>> >>>> ^callbackContext wordResult: >>>> (block >>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) >>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) >>>> >>>> Basically the idea is that the selector of the method doesn't matter >>>> except for the number of arguments. What's important is the pragma >>>> which defines the signature and the ABI for which this is a valid >>>> marshalling method. >>>> >>>> When the callback is instantiated, Callback introspects to find the >>>> marshalling method that matches the signature. If one doesn't already >>>> exist you can write one. Hopefully we'll write an ABI compiler that >>>> will automatically generate these marshalling methods according to the >>>> platform's ABI, but for now its a manual process. But at least it's >>>> open and flexible. When the callback is invoked the evaluator is >>>> performed with the current callbackContext and pointer(s) to the >>>> arguments. There is a 32-bit and a 64-bit callback context, and it can >>>> have a stack pointer, integer register args and floating point >>>> register args. So it's general enough for any callback. >>>> >>>> To pass back the result, a value is assigned into the struct via the >>>> accessor in the marshalling method and control returns to teh point >>>> where teh callback comes in, and this uses a primitive to return. >>>> Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive >>>> longjmp's back to the entry point in the VM which extracts the result >>>> and the code for the kind of result and returns: >>>> >>>> Callback class>>invokeCallbackContext: vmCallbackContextAddress >>>> "" "^" >>>> "The low-level entry-point for callbacks sent from the VM/IA32ABI >>>> plugin. >>>> Return via primReturnFromContext:through:. thisContext's sender is the >>>> call-out context." >>>> | callbackAlien type | >>>> callbackAlien := (Smalltalk wordSize = 4 >>>> ifTrue: [VMCallbackContext32] >>>> ifFalse: [VMCallbackContext64]) >>>> atAddress: vmCallbackContextAddress. >>>> [type := Callback evaluateCallbackForContext: callbackAlien] >>>> ifCurtailed: [self error: 'attempt to non-local return across a >>>> callback']. >>>> type ifNil: >>>> [type := 1. callbackAlien wordResult: -1]. >>>> callbackAlien primReturnAs: type fromContext: thisContext >>>> >>>> On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta >>> > wrote: >>>> >>>> >>>> Hi all-- >>>> >>>> I'd like to use a C shared library via FFI from Squeak or >>>> Pharo. >>>> Specifically, I want to call a C function which takes as one of its >>>> parameters a pointer to an array of callback function addresses. >>>> Does >>>> one of the FFI approaches floating around handle that, and provide a >>>> relatively pleasant mapping between Smalltalk block closures and C >>>> callback function addresses? >>>> >>>> I was doing this so far in GemStone, but apparently its FFI >>>> only >>>> supports passing callback function addresses one at a time as direct >>>> parameters of C callouts. I suppose I could write a wrapper C >>>> library >>>> around the one I really want to use, that provides the callback >>>> setup >>>> interface that GemStone expects, but whenever I have to write actual >>>> C >>>> code I start to think "Hm, why don't I just use a Smalltalk VM for >>>> which >>>> I have the source?" :) All the fancy distributed object-database >>>> stuff >>>> that my project also wants can wait for a bit. >>>> >>>> >>>> thanks! >>>> >>>> -C >>>> >>>> -- >>>> Craig Latta >>>> netjam.org >>>> +31 6 2757 7177 (SMS ok) >>>> + 1 415 287 3547 (no SMS) >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>>> >> > > From Das.Linux at gmx.de Fri Sep 4 06:01:10 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Fri Sep 4 06:01:15 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> Message-ID: <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> On 04.09.2015, at 05:46, Chris Muller wrote: >> I do think that anything is better than the current situation. A bucket of >> any kind in an agreed upon location seems like a good place to start. > > I totally agree! what about http://github.com/squeak-vm/plugins or http://github.com/squeak-smalltalk/vm-plugins Best -tobias PS: we should look at https://github.com/search?q=squeak+vm > >> I >> hadn't considered that plugins would need meta data or labels. > > They could be put into a .zip file and stored and cataloged somewhere > which would be a well-known place for Squeak. And, each plugin would > be tagged with one or more hierarchical Category's to indicate the > platform and whatever else we wanted... > > And, if the plugin is compiled and hosted somewhere else, like GitHub, > then the Squeak-well-known place should direct the user to THAT > external place instead of hosting copies on squeak.org servers... > Except as a backup, of course.. > > Hmm, if only we have something that could do all that... Oh wait, > we do!!!! ;-) > >> Perhaps the best thing is to leave it as an open question for a few weeks >> before settling on any kind of solution. A common location for plugins is >> about as far as my thinking takes me at the moment. I'm sure the collective >> imagination of the community can come up with a better idea. >> >> Chris >> >> >> On 2015-09-03 10:07 PM, David T. Lewis wrote: >>> >>> On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote: >>>> >>>> This community needs a repository for plugins. A directory at >>>> http://ftp.squeak.org ought to do it. >>>> >>>> If I want to try Alien I need the plugin. Where am I going to get that? >>>> I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see it >>>> is not saying Newspeak and realize it compiles a plugin called IA32ABI, >>>> which - coincidentally - is the name of the plugin the error Alien >>>> exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> moduleName >>>> returns IA32ABI). >>>> >>>> Does anybody know what the Genie plugin does? Does Paul DeBrucker need >>>> to store a BerkeleyDB plugin dll he got by emailing somebody on GitHub? >>>> >>>> If I understand this correctly, if such a directory existed, then all a >>>> person would need to do to try the above Alien code would be to download >>>> a pre-compiled plugin from - say - >>>> http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM directory >>>> and start the image. Then check with SmalltalkImage current >>>> listLoadedModules to see if you're ready to go. >>>> >>>> I nominate Fabio Niephaus to be the person the community can send >>>> pre-compiled plugins for inclusion in such a directory. Eliot's been >>>> banging away about Alien for some time [1]. If a person could go, get >>>> the plugin and give the code shot, he could have more productive >>>> conversations about Alien. >>>> >>>> So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in an >>>> idle moment, you could email it to Fabio? And when, Fabio, you've >>>> created the directory in http://ftp.squeak.org you could announce it >>>> here on Squeak-dev? >>>> >>>> FWIW, >>>> >>>> Chris >>> >>> A word of caution: >>> >>> I think the idea is good in principle, but it needs to be accompanied >>> by a commitment by someone to do the hard work of keeping track of >>> dependencies on the various flavors of OS, image word size, VM word size, >>> spur/V3, and so forth. If someone would like to take that on, great. >>> That said, we don't want to start a project that gets 80% completed, and >>> then expect "the community" to do the rest of the work. >>> >>> I cannot speak for Fabio, but I don't think it is fair for us to expect >>> him to take on this kind of workload unless he has indicated an interest >>> in doing it. >>> >>> Maybe a restricted repository focused just on compiled plugins known >>> to work with the Spur VM on a limited range of OS flavors would be helpful >>> at this stage. It probably does not belong on ftp.squeak.org, but it could >>> be a very useful resource if someone (Chris Cunnington?) wants to set it >>> up. >>> >>> Dave >>> >>> >>>> [1] http://wiki.squeak.org/squeak/uploads/6100/ >>>> >>>> On 2015-09-03 7:07 PM, Eliot Miranda wrote: >>>>> >>>>> Hi Craig, >>>>> >>>>> you need Alien-eem.24 >>>>> >>>>> Here's Alien class>>exampleCqsort >>>>> "Call the libc qsort function (which requires a callback)." >>>>> "Alien exampleCqsort" >>>>> "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / >>>>> 100.0" >>>>> | cb rand nElements sizeofDouble values orig sort | >>>>> rand := Random new. >>>>> values := Alien newC: (nElements := 100) * (sizeofDouble := 8). >>>>> 1 to: values dataSize by: sizeofDouble do: >>>>> [:i| values doubleAt: i put: rand next]. >>>>> orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>>>> doubleAt: i]. >>>>> cb := Callback >>>>> signature: #(int (*)(const void *, const void *)) >>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. >>>>> (Alien lookup: 'qsort' inLibrary: Alien libcName) >>>>> primFFICallResult: nil >>>>> with: values pointer >>>>> with: nElements >>>>> with: sizeofDouble >>>>> with: cb thunk. >>>>> sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>>>> doubleAt: i]. >>>>> values free. >>>>> ^orig -> sort >>>>> >>>>> The above example uses Alien to make the callout. To use it with the >>>>> FFI simply pass cb pointer as the argument as is done above. >>>>> >>>>> >>>>> Implementation: >>>>> >>>>> The way that it works is in two parts >>>>> - the VM passes up a pointer to a structure from which all arguments, >>>>> stacked and in registers (because the VM has copied the register args >>>>> into the struct) can be accessed, and through which the result can be >>>>> returned. >>>>> - the image level provides marshalling methods that match the >>>>> signature in the callback >>>>> >>>>> So e.g. with a callback of >>>>> Callback >>>>> signature: #(int (*)(const void *, const void *)) >>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] >>>>> the marshalling methods are in Callback's signature protocol: >>>>> >>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>>>> >>>>> ^callbackContext wordResult: >>>>> (block >>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 1)) >>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 5))) >>>>> >>>>> where spAlien is an Alien pointing to a VMCallbackContext32. >>>>> >>>>> For ARM support we would add >>>>> >>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>>>> intRegArgs: regsAlien >>>>> >>>>> ^callbackContext wordResult: >>>>> (block >>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) >>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) >>>>> >>>>> Basically the idea is that the selector of the method doesn't matter >>>>> except for the number of arguments. What's important is the pragma >>>>> which defines the signature and the ABI for which this is a valid >>>>> marshalling method. >>>>> >>>>> When the callback is instantiated, Callback introspects to find the >>>>> marshalling method that matches the signature. If one doesn't already >>>>> exist you can write one. Hopefully we'll write an ABI compiler that >>>>> will automatically generate these marshalling methods according to the >>>>> platform's ABI, but for now its a manual process. But at least it's >>>>> open and flexible. When the callback is invoked the evaluator is >>>>> performed with the current callbackContext and pointer(s) to the >>>>> arguments. There is a 32-bit and a 64-bit callback context, and it can >>>>> have a stack pointer, integer register args and floating point >>>>> register args. So it's general enough for any callback. >>>>> >>>>> To pass back the result, a value is assigned into the struct via the >>>>> accessor in the marshalling method and control returns to teh point >>>>> where teh callback comes in, and this uses a primitive to return. >>>>> Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive >>>>> longjmp's back to the entry point in the VM which extracts the result >>>>> and the code for the kind of result and returns: >>>>> >>>>> Callback class>>invokeCallbackContext: vmCallbackContextAddress >>>>> "" "^" >>>>> "The low-level entry-point for callbacks sent from the VM/IA32ABI >>>>> plugin. >>>>> Return via primReturnFromContext:through:. thisContext's sender is the >>>>> call-out context." >>>>> | callbackAlien type | >>>>> callbackAlien := (Smalltalk wordSize = 4 >>>>> ifTrue: [VMCallbackContext32] >>>>> ifFalse: [VMCallbackContext64]) >>>>> atAddress: vmCallbackContextAddress. >>>>> [type := Callback evaluateCallbackForContext: callbackAlien] >>>>> ifCurtailed: [self error: 'attempt to non-local return across a >>>>> callback']. >>>>> type ifNil: >>>>> [type := 1. callbackAlien wordResult: -1]. >>>>> callbackAlien primReturnAs: type fromContext: thisContext >>>>> >>>>> On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta >>>> > wrote: >>>>> >>>>> >>>>> Hi all-- >>>>> >>>>> I'd like to use a C shared library via FFI from Squeak or >>>>> Pharo. >>>>> Specifically, I want to call a C function which takes as one of its >>>>> parameters a pointer to an array of callback function addresses. >>>>> Does >>>>> one of the FFI approaches floating around handle that, and provide a >>>>> relatively pleasant mapping between Smalltalk block closures and C >>>>> callback function addresses? >>>>> >>>>> I was doing this so far in GemStone, but apparently its FFI >>>>> only >>>>> supports passing callback function addresses one at a time as direct >>>>> parameters of C callouts. I suppose I could write a wrapper C >>>>> library >>>>> around the one I really want to use, that provides the callback >>>>> setup >>>>> interface that GemStone expects, but whenever I have to write actual >>>>> C >>>>> code I start to think "Hm, why don't I just use a Smalltalk VM for >>>>> which >>>>> I have the source?" :) All the fancy distributed object-database >>>>> stuff >>>>> that my project also wants can wait for a bit. >>>>> >>>>> >>>>> thanks! >>>>> >>>>> -C >>>>> >>>>> -- >>>>> Craig Latta >>>>> netjam.org >>>>> +31 6 2757 7177 (SMS ok) >>>>> + 1 415 287 3547 (no SMS) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> _,,,^..^,,,_ >>>>> best, Eliot From commits at source.squeak.org Fri Sep 4 06:38:08 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 4 06:38:10 2015 Subject: [squeak-dev] The Trunk: Morphic-mt.1004.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1004.mcz ==================== Summary ==================== Name: Morphic-mt.1004 Author: mt Time: 4 September 2015, 8:37:36.913 am UUID: a6373ade-f974-0e41-8609-316d092a7215 Ancestors: Morphic-eem.1003 Do not degrade rounded rectangles to ovals if the radius happens to be bigger than the extent. Ovals do not look at all like rectangles. Especially wide ones. =============== Diff against Morphic-eem.1003 =============== Item was changed: ----- Method: BalloonCanvas>>frameRoundRect:radius:width:color: (in category 'drawing-rectangles') ----- frameRoundRect: aRectangle radius: radius width: borderWidth color: borderColor | outerPoints innerRect innerRadius innerPoints | (borderWidth isZero or:[borderColor isTransparent]) ifTrue:[^self]. radius asPoint <= (0@0) ifTrue:[^self frameRectangle: aRectangle width: borderWidth color: borderColor]. - (radius * 2) asPoint >= aRectangle extent - ifTrue:[^self frameOval: aRectangle width: borderWidth color: borderColor]. "decompose inner rectangle into bezier shape" innerRect := aRectangle insetBy: borderWidth. innerRect area <= 0 ifTrue:[^self fillRoundRect: aRectangle radius: radius fillStyle: borderColor]. innerRadius := (radius - borderWidth) asPoint. innerPoints := self makeRoundRectShape: innerRect radius: innerRadius. "decompose outer rectangle into bezier shape" outerPoints := self makeRoundRectShape: aRectangle radius: radius. self drawGeneralBezierShape: (Array with: outerPoints with: innerPoints) color: borderColor borderWidth: 0 borderColor: nil.! Item was changed: ----- Method: FormCanvas>>frameRoundRect:radius:width:color: (in category 'drawing-rectangles') ----- frameRoundRect: aRectangle radius: radius width: borderWidth color: borderColor "Frame a rounded rectangle with the given attributes." | innerRect | (borderWidth isZero or:[borderColor isTransparent]) ifTrue:[^self]. radius asPoint <= (0@0) ifTrue:[^self frameRectangle: aRectangle width: borderWidth color: borderColor]. - (radius * 2) asPoint >= aRectangle extent - ifTrue:[^self frameOval: aRectangle width: borderWidth color: borderColor]. "decompose inner rectangle into bezier shape" innerRect := aRectangle insetBy: borderWidth. innerRect area <= 0 ifTrue:[^self fillRoundRect: aRectangle radius: radius fillStyle: borderColor]. self setFillColor: borderColor. port frameRoundRect: (aRectangle translateBy: origin) truncated radius: radius truncated borderWidth: borderWidth truncated. ! From frank.shearar at gmail.com Fri Sep 4 08:26:38 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Fri Sep 4 08:26:42 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: On 4 September 2015 at 07:01, Tobias Pape wrote: > > On 04.09.2015, at 05:46, Chris Muller wrote: > >>> I do think that anything is better than the current situation. A bucket of >>> any kind in an agreed upon location seems like a good place to start. >> >> I totally agree! > > what about > > http://github.com/squeak-vm/plugins > > or > > http://github.com/squeak-smalltalk/vm-plugins My preferred choice: the organisation already exists. frank > Best > -tobias > > PS: we should look at https://github.com/search?q=squeak+vm > >> >>> I >>> hadn't considered that plugins would need meta data or labels. >> >> They could be put into a .zip file and stored and cataloged somewhere >> which would be a well-known place for Squeak. And, each plugin would >> be tagged with one or more hierarchical Category's to indicate the >> platform and whatever else we wanted... >> >> And, if the plugin is compiled and hosted somewhere else, like GitHub, >> then the Squeak-well-known place should direct the user to THAT >> external place instead of hosting copies on squeak.org servers... >> Except as a backup, of course.. >> >> Hmm, if only we have something that could do all that... Oh wait, >> we do!!!! ;-) >> >>> Perhaps the best thing is to leave it as an open question for a few weeks >>> before settling on any kind of solution. A common location for plugins is >>> about as far as my thinking takes me at the moment. I'm sure the collective >>> imagination of the community can come up with a better idea. >>> >>> Chris >>> >>> >>> On 2015-09-03 10:07 PM, David T. Lewis wrote: >>>> >>>> On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote: >>>>> >>>>> This community needs a repository for plugins. A directory at >>>>> http://ftp.squeak.org ought to do it. >>>>> >>>>> If I want to try Alien I need the plugin. Where am I going to get that? >>>>> I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see it >>>>> is not saying Newspeak and realize it compiles a plugin called IA32ABI, >>>>> which - coincidentally - is the name of the plugin the error Alien >>>>> exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> moduleName >>>>> returns IA32ABI). >>>>> >>>>> Does anybody know what the Genie plugin does? Does Paul DeBrucker need >>>>> to store a BerkeleyDB plugin dll he got by emailing somebody on GitHub? >>>>> >>>>> If I understand this correctly, if such a directory existed, then all a >>>>> person would need to do to try the above Alien code would be to download >>>>> a pre-compiled plugin from - say - >>>>> http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM directory >>>>> and start the image. Then check with SmalltalkImage current >>>>> listLoadedModules to see if you're ready to go. >>>>> >>>>> I nominate Fabio Niephaus to be the person the community can send >>>>> pre-compiled plugins for inclusion in such a directory. Eliot's been >>>>> banging away about Alien for some time [1]. If a person could go, get >>>>> the plugin and give the code shot, he could have more productive >>>>> conversations about Alien. >>>>> >>>>> So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in an >>>>> idle moment, you could email it to Fabio? And when, Fabio, you've >>>>> created the directory in http://ftp.squeak.org you could announce it >>>>> here on Squeak-dev? >>>>> >>>>> FWIW, >>>>> >>>>> Chris >>>> >>>> A word of caution: >>>> >>>> I think the idea is good in principle, but it needs to be accompanied >>>> by a commitment by someone to do the hard work of keeping track of >>>> dependencies on the various flavors of OS, image word size, VM word size, >>>> spur/V3, and so forth. If someone would like to take that on, great. >>>> That said, we don't want to start a project that gets 80% completed, and >>>> then expect "the community" to do the rest of the work. >>>> >>>> I cannot speak for Fabio, but I don't think it is fair for us to expect >>>> him to take on this kind of workload unless he has indicated an interest >>>> in doing it. >>>> >>>> Maybe a restricted repository focused just on compiled plugins known >>>> to work with the Spur VM on a limited range of OS flavors would be helpful >>>> at this stage. It probably does not belong on ftp.squeak.org, but it could >>>> be a very useful resource if someone (Chris Cunnington?) wants to set it >>>> up. >>>> >>>> Dave >>>> >>>> >>>>> [1] http://wiki.squeak.org/squeak/uploads/6100/ >>>>> >>>>> On 2015-09-03 7:07 PM, Eliot Miranda wrote: >>>>>> >>>>>> Hi Craig, >>>>>> >>>>>> you need Alien-eem.24 >>>>>> >>>>>> Here's Alien class>>exampleCqsort >>>>>> "Call the libc qsort function (which requires a callback)." >>>>>> "Alien exampleCqsort" >>>>>> "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / >>>>>> 100.0" >>>>>> | cb rand nElements sizeofDouble values orig sort | >>>>>> rand := Random new. >>>>>> values := Alien newC: (nElements := 100) * (sizeofDouble := 8). >>>>>> 1 to: values dataSize by: sizeofDouble do: >>>>>> [:i| values doubleAt: i put: rand next]. >>>>>> orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>>>>> doubleAt: i]. >>>>>> cb := Callback >>>>>> signature: #(int (*)(const void *, const void *)) >>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign]. >>>>>> (Alien lookup: 'qsort' inLibrary: Alien libcName) >>>>>> primFFICallResult: nil >>>>>> with: values pointer >>>>>> with: nElements >>>>>> with: sizeofDouble >>>>>> with: cb thunk. >>>>>> sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| values >>>>>> doubleAt: i]. >>>>>> values free. >>>>>> ^orig -> sort >>>>>> >>>>>> The above example uses Alien to make the callout. To use it with the >>>>>> FFI simply pass cb pointer as the argument as is done above. >>>>>> >>>>>> >>>>>> Implementation: >>>>>> >>>>>> The way that it works is in two parts >>>>>> - the VM passes up a pointer to a structure from which all arguments, >>>>>> stacked and in registers (because the VM has copied the register args >>>>>> into the struct) can be accessed, and through which the result can be >>>>>> returned. >>>>>> - the image level provides marshalling methods that match the >>>>>> signature in the callback >>>>>> >>>>>> So e.g. with a callback of >>>>>> Callback >>>>>> signature: #(int (*)(const void *, const void *)) >>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign] >>>>>> the marshalling methods are in Callback's signature protocol: >>>>>> >>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>>>>> >>>>>> ^callbackContext wordResult: >>>>>> (block >>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 1)) >>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 5))) >>>>>> >>>>>> where spAlien is an Alien pointing to a VMCallbackContext32. >>>>>> >>>>>> For ARM support we would add >>>>>> >>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >>>>>> intRegArgs: regsAlien >>>>>> >>>>>> ^callbackContext wordResult: >>>>>> (block >>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) >>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) >>>>>> >>>>>> Basically the idea is that the selector of the method doesn't matter >>>>>> except for the number of arguments. What's important is the pragma >>>>>> which defines the signature and the ABI for which this is a valid >>>>>> marshalling method. >>>>>> >>>>>> When the callback is instantiated, Callback introspects to find the >>>>>> marshalling method that matches the signature. If one doesn't already >>>>>> exist you can write one. Hopefully we'll write an ABI compiler that >>>>>> will automatically generate these marshalling methods according to the >>>>>> platform's ABI, but for now its a manual process. But at least it's >>>>>> open and flexible. When the callback is invoked the evaluator is >>>>>> performed with the current callbackContext and pointer(s) to the >>>>>> arguments. There is a 32-bit and a 64-bit callback context, and it can >>>>>> have a stack pointer, integer register args and floating point >>>>>> register args. So it's general enough for any callback. >>>>>> >>>>>> To pass back the result, a value is assigned into the struct via the >>>>>> accessor in the marshalling method and control returns to teh point >>>>>> where teh callback comes in, and this uses a primitive to return. >>>>>> Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive >>>>>> longjmp's back to the entry point in the VM which extracts the result >>>>>> and the code for the kind of result and returns: >>>>>> >>>>>> Callback class>>invokeCallbackContext: vmCallbackContextAddress >>>>>> "" "^" >>>>>> "The low-level entry-point for callbacks sent from the VM/IA32ABI >>>>>> plugin. >>>>>> Return via primReturnFromContext:through:. thisContext's sender is the >>>>>> call-out context." >>>>>> | callbackAlien type | >>>>>> callbackAlien := (Smalltalk wordSize = 4 >>>>>> ifTrue: [VMCallbackContext32] >>>>>> ifFalse: [VMCallbackContext64]) >>>>>> atAddress: vmCallbackContextAddress. >>>>>> [type := Callback evaluateCallbackForContext: callbackAlien] >>>>>> ifCurtailed: [self error: 'attempt to non-local return across a >>>>>> callback']. >>>>>> type ifNil: >>>>>> [type := 1. callbackAlien wordResult: -1]. >>>>>> callbackAlien primReturnAs: type fromContext: thisContext >>>>>> >>>>>> On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta >>>>> > wrote: >>>>>> >>>>>> >>>>>> Hi all-- >>>>>> >>>>>> I'd like to use a C shared library via FFI from Squeak or >>>>>> Pharo. >>>>>> Specifically, I want to call a C function which takes as one of its >>>>>> parameters a pointer to an array of callback function addresses. >>>>>> Does >>>>>> one of the FFI approaches floating around handle that, and provide a >>>>>> relatively pleasant mapping between Smalltalk block closures and C >>>>>> callback function addresses? >>>>>> >>>>>> I was doing this so far in GemStone, but apparently its FFI >>>>>> only >>>>>> supports passing callback function addresses one at a time as direct >>>>>> parameters of C callouts. I suppose I could write a wrapper C >>>>>> library >>>>>> around the one I really want to use, that provides the callback >>>>>> setup >>>>>> interface that GemStone expects, but whenever I have to write actual >>>>>> C >>>>>> code I start to think "Hm, why don't I just use a Smalltalk VM for >>>>>> which >>>>>> I have the source?" :) All the fancy distributed object-database >>>>>> stuff >>>>>> that my project also wants can wait for a bit. >>>>>> >>>>>> >>>>>> thanks! >>>>>> >>>>>> -C >>>>>> >>>>>> -- >>>>>> Craig Latta >>>>>> netjam.org >>>>>> +31 6 2757 7177 (SMS ok) >>>>>> + 1 415 287 3547 (no SMS) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> _,,,^..^,,,_ >>>>>> best, Eliot > > > From hannes.hirzel at gmail.com Fri Sep 4 11:29:57 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Fri Sep 4 11:30:01 2015 Subject: [squeak-dev] menu pragmas (was "The Trunk: Monticello-eem.617.mcz") In-Reply-To: References: Message-ID: I saved the proposal here http://wiki.squeak.org/squeak/6210 until there is time for discussion. It is also advisable to check what Pharo has been doing and what is planned in Cuis. --Hannes On 9/3/15, Tobias Pape wrote: > Hi all > > On 03.09.2015, at 01:21, Craig Latta wrote: > >> >> Hi all-- >> >> This is just a new thread to make Eliot's description of menu >> pragmas more prominent in the list archives. Perhaps there are others >> who, like me, don't read all the "trunk" threads in their entirety and >> might miss stuff like this. > > > I read that and I'll comment on all that later. > Still on vacation and on my way to the beach. > Probably tonight (CEST) :) > > Best > -Tobias > >> >> >> thanks, >> >> -C >> >> *** >> >> Tobias writes to Eliot: >> >>> Can you explain what you want to achieve [with menu pragmas] and how >>> I can make [their use] more convenient? >> >> Eliot responds: >> >>> We can talk this over when we meet in Palo Alto, but the idea is an >>> important one, and I'm paying for having been too lazy to write it up >>> properly. Let me try and give a quick sketch here. >>> >>> The goals are to: >>> >>> - allow package load to augment menus without the original definitions >>> of those menus knowing anything about the subsequently loaded >>> packages. >>> - to allow menus to be augmented with single actions defined in >>> methods that implement those actions >>> - and, depending on menu implementation, either >>> - if menus are created every time a user invokes a menu, then to >>> simply include the relevant extensions in the menu >>> - if menus are stored in variables, to automatically construct, or >>> reconstruct the menu when either loading or unloading of a package >>> changes the items in a menu >>> >>> We design menu pragmas in action methods to specify: >> >>> - the (name of the) menu to be extended >>> - the text of the menu entry >>> - information regarding what group of items the menu item belongs with >>> - information regarding the menu item's relative order with respect to >>> other elements in the group >>> >>> Rationale: >>> With this specification a package can extend any number of menus in >>> tools simply by being loaded, with no collisions with any other >>> packages defining extensions on those menus. Tools become freely >>> pluggable, and system configurations constructed from different sets >>> of loaded packages are decoupled; we don't need many menu >>> definitions, just an initial base menu which is extended with the >>> current set of extensions. >>> >>> For this to work we need to "name" menus, and to use some numbering >>> scheme to define groups (menu entries between lines) and elements >>> within each group. One simple scheme is to use numbers: >>> >>> - the definitions of initial base menus number groups, so that the >>> first group (the items before the first line) is numbered group 10, >>> and the second group 20, and so on, allowing extensions to specify >>> new groups by using group numbers that are not a multiple of 10 >>> - the definitions of entries within groups are numbered, again in >>> multiples of 10, so that the extension can fit anywhere in the >>> group >>> >>> So given: >>> >>> MenuMorph fromArray: { >>> {'find...(f)' translated. #find}. >>> {'find again (g)' translated. #findAgain}. >>> {'set search string (h)' translated. #setSearchString}. >>> #-. >>> {'do again (j)' translated. #again}. >>> {'undo (z)' translated. #undo}. >>> #-. >>> {'copy (c)' translated. #copySelection}. >>> {'cut (x)' translated. #cut}. >>> {'paste (v)' translated. #paste}. >>> {'paste...' translated. #pasteRecent}. >>> #-. >>> {'set font... (k)' translated. #offerFontMenu}. >>> {'set style... (K)' translated. #changeStyle}. >>> {'set alignment...' translated. #chooseAlignment}. >>> " >>> #-. >>> {'more...' translated. #shiftedTextPaneMenuRequest}. >>> " >>> } >>> >>> you could imagine the following numberings: >>> >>> 10.01 find >>> 10.02 findAgain >>> 10.03 setSearchString >>> - >>> 20.01 again >>> 20.02 undo >>> - >>> 30.01 copySelection >>> 30.02 cut >>> 30.03 paste >>> 30.04 pasteRecent >>> - >>> 40.01 offerFontMenu >>> 40.02 changeStyle >>> 40.03 chooseAlignment >>> >>> So I can specify e.g. a new group inserted before the first one by >>> using, e.g. 5.005 as an index, and can slot an item between again and >>> undo using 20.015, etc. >>> >>> This gives us menu pragmas that look like: >>> >>> TextEditor methodsFor: '*SpellChecker-extensions' stamp: 'mad hacker >>> 9/9/1999' >>> spellCheck >>> >> label: 'spell check selection (s)' >>> position: 10.035> >>> ...code implementing spell checking... >>> >>> (note that the action, #spellCheck, is implicit, it is the selector of >>> the method containing the pragma) >>> >>> and: >>> >>> - if menus are created every time a user invokes a menu, then search >>> for pragmas within the relevant class hierarchy, compute, sort and >>> insert individual extensions to the menu >>> - if menus are stored in variables, to have compilation and method >>> removal send a message to the class to/from which method(s) are >>> added/removed so that the class can recompute menus (as in the line >>> above) when code is added/removed. >>> >>> What I saw in ChangeSorter was quite different. It seems to be a way >>> of specifying entire menus, and I'm not sure how these menus are to be >>> combined. Maybe I'm misunderstanding the way the scheme is supposed >>> to work. What I've described above is very close to the one that >>> pragmas came from in the first place, which was my attempt to >>> decouple the components that could be loaded into VisualWorks when we >>> decomposed the system into easily loadable parcels. Up until that >>> point VisualWorks had had all its tool menus predefined, disabling >>> items that were to do with components delivered as file-ins that >>> weren't yet filed-in. It was too rigid. It didn't allow for future >>> expansion. And so I had the idea of menu pragmas to decouple >>> things. Steve Dahl then came up with the scheme to define a base >>> menu, number its items appropriately, and extend the menu. >>> >>> One of the things that's really nice about the VisualWorks scheme is >>> that the menu pragma itself is actually implemented (remember that >>> pragmas are Message instances with literal parameters). The class >>> MenuBuilder (IIRC) implemented various menu pragma methods so the >>> pattern is: >>> >>> - in the method that defines the base menu, define the base menu, >>> create an editor on it, ask the editor to collect the pragmas and >>> augment the menu with those found >>> - the menu editor then collects the menu pragmas and then performs >>> each one to collect the information from it >>> >>> So one can find other menu pragmas using senders, and find the editor >>> using implementors, and one can extend the scheme by adding additional >>> methods to MenuEditor, again possibly loaded from packages. >>> >>> >>> HTH >>> >>> _,,,^..^,,,_ >>> best, Eliot >> >> -- >> Craig Latta >> netjam.org >> +31 6 2757 7177 (SMS ok) >> + 1 415 287 3547 (no SMS) >> >> > > > From Marcel.Taeumel at hpi.de Fri Sep 4 15:30:09 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Fri Sep 4 15:36:14 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: References: <1441259953070-4847814.post@n4.nabble.com> Message-ID: <1441380609226-4848084.post@n4.nabble.com> I like this model for handling selection modes: http://doc.qt.io/qt-4.8/qabstractitemview.html#SelectionMode-enum Best, Marcel -- View this message in context: http://forum.world.st/Grrrr-how-come-I-can-t-deselect-in-a-list-browser-tp4847776p4848084.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From nicolas.cellier.aka.nice at gmail.com Fri Sep 4 16:59:48 2015 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Fri Sep 4 16:59:51 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: <1441380609226-4848084.post@n4.nabble.com> References: <1441259953070-4847814.post@n4.nabble.com> <1441380609226-4848084.post@n4.nabble.com> Message-ID: But there doesn't seem to be a way to have none item selected in this model, does it? If the intention is to file out all, the logic would indeed be to select all and operate on the selection. Alas, allmost no action is multi-selection ready. It's certainly valuable to have actions able to operate on multiple selections in the long term... But in the short term it's not the simplest thing that could possibly work. The change of Eliot was a quick hack, no selection <=> operate on all... IMHO, the continuous-integration strategy should be to restore this behavior in the interim until the multi-selection is ready. Cheers Nicolas 2015-09-04 17:30 GMT+02:00 marcel.taeumel : > I like this model for handling selection modes: > http://doc.qt.io/qt-4.8/qabstractitemview.html#SelectionMode-enum > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/Grrrr-how-come-I-can-t-deselect-in-a-list-browser-tp4847776p4848084.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150904/5c869a92/attachment.htm From commits at source.squeak.org Fri Sep 4 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 4 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150904215502.3665.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008954.html Name: Morphic-mt.1004 Ancestors: Morphic-eem.1003 Do not degrade rounded rectangles to ovals if the radius happens to be bigger than the extent. Ovals do not look at all like rectangles. Especially wide ones. ============================================= From lists at fniephaus.com Fri Sep 4 22:06:33 2015 From: lists at fniephaus.com (Fabio Niephaus) Date: Fri Sep 4 22:06:45 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: On Fri, Sep 4, 2015 at 9:26 AM Frank Shearar wrote: > On 4 September 2015 at 07:01, Tobias Pape wrote: > > > > On 04.09.2015, at 05:46, Chris Muller wrote: > > > >>> I do think that anything is better than the current situation. A > bucket of > >>> any kind in an agreed upon location seems like a good place to start. > >> > >> I totally agree! > > > > what about > > > > http://github.com/squeak-vm/plugins > > > > or > > > > http://github.com/squeak-smalltalk/vm-plugins > > My preferred choice: the organisation already exists. > > frank > > > Best > > -tobias > > > > PS: we should look at https://github.com/search?q=squeak+vm > > > >> > >>> I > >>> hadn't considered that plugins would need meta data or labels. > >> > >> They could be put into a .zip file and stored and cataloged somewhere > >> which would be a well-known place for Squeak. And, each plugin would > >> be tagged with one or more hierarchical Category's to indicate the > >> platform and whatever else we wanted... > >> > >> And, if the plugin is compiled and hosted somewhere else, like GitHub, > >> then the Squeak-well-known place should direct the user to THAT > >> external place instead of hosting copies on squeak.org servers... > >> Except as a backup, of course.. > >> > >> Hmm, if only we have something that could do all that... Oh wait, > >> we do!!!! ;-) > >> > >>> Perhaps the best thing is to leave it as an open question for a few > weeks > >>> before settling on any kind of solution. A common location for plugins > is > >>> about as far as my thinking takes me at the moment. I'm sure the > collective > >>> imagination of the community can come up with a better idea. > >>> > >>> Chris > >>> > >>> > >>> On 2015-09-03 10:07 PM, David T. Lewis wrote: > >>>> > >>>> On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote: > >>>>> > >>>>> This community needs a repository for plugins. A directory at > >>>>> http://ftp.squeak.org ought to do it. > >>>>> > >>>>> If I want to try Alien I need the plugin. Where am I going to get > that? > >>>>> I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see > it > >>>>> is not saying Newspeak and realize it compiles a plugin called > IA32ABI, > >>>>> which - coincidentally - is the name of the plugin the error Alien > >>>>> exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> > moduleName > >>>>> returns IA32ABI). > >>>>> > >>>>> Does anybody know what the Genie plugin does? Does Paul DeBrucker > need > >>>>> to store a BerkeleyDB plugin dll he got by emailing somebody on > GitHub? > >>>>> > >>>>> If I understand this correctly, if such a directory existed, then > all a > >>>>> person would need to do to try the above Alien code would be to > download > >>>>> a pre-compiled plugin from - say - > >>>>> http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM > directory > >>>>> and start the image. Then check with SmalltalkImage current > >>>>> listLoadedModules to see if you're ready to go. > >>>>> > >>>>> I nominate Fabio Niephaus to be the person the community can send > >>>>> pre-compiled plugins for inclusion in such a directory. Eliot's been > >>>>> banging away about Alien for some time [1]. If a person could go, get > >>>>> the plugin and give the code shot, he could have more productive > >>>>> conversations about Alien. > >>>>> > >>>>> So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in > an > >>>>> idle moment, you could email it to Fabio? And when, Fabio, you've > >>>>> created the directory in http://ftp.squeak.org you could announce it > >>>>> here on Squeak-dev? > >>>>> > >>>>> FWIW, > >>>>> > >>>>> Chris > >>>> > >>>> A word of caution: > >>>> > >>>> I think the idea is good in principle, but it needs to be accompanied > >>>> by a commitment by someone to do the hard work of keeping track of > >>>> dependencies on the various flavors of OS, image word size, VM word > size, > >>>> spur/V3, and so forth. If someone would like to take that on, great. > >>>> That said, we don't want to start a project that gets 80% completed, > and > >>>> then expect "the community" to do the rest of the work. > >>>> > >>>> I cannot speak for Fabio, but I don't think it is fair for us to > expect > >>>> him to take on this kind of workload unless he has indicated an > interest > >>>> in doing it. > >>>> > >>>> Maybe a restricted repository focused just on compiled plugins known > >>>> to work with the Spur VM on a limited range of OS flavors would be > helpful > >>>> at this stage. It probably does not belong on ftp.squeak.org, but it > could > >>>> be a very useful resource if someone (Chris Cunnington?) wants to set > it > >>>> up. > >>>> > >>>> Dave > >>>> > >>>> > >>>>> [1] http://wiki.squeak.org/squeak/uploads/6100/ > >>>>> > >>>>> On 2015-09-03 7:07 PM, Eliot Miranda wrote: > >>>>>> > >>>>>> Hi Craig, > >>>>>> > >>>>>> you need Alien-eem.24 > >>>>>> > >>>>>> Here's Alien class>>exampleCqsort > >>>>>> "Call the libc qsort function (which requires a callback)." > >>>>>> "Alien exampleCqsort" > >>>>>> "(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) > / > >>>>>> 100.0" > >>>>>> | cb rand nElements sizeofDouble values orig sort | > >>>>>> rand := Random new. > >>>>>> values := Alien newC: (nElements := 100) * (sizeofDouble := 8). > >>>>>> 1 to: values dataSize by: sizeofDouble do: > >>>>>> [:i| values doubleAt: i put: rand next]. > >>>>>> orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| > values > >>>>>> doubleAt: i]. > >>>>>> cb := Callback > >>>>>> signature: #(int (*)(const void *, const void *)) > >>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) > sign]. > >>>>>> (Alien lookup: 'qsort' inLibrary: Alien libcName) > >>>>>> primFFICallResult: nil > >>>>>> with: values pointer > >>>>>> with: nElements > >>>>>> with: sizeofDouble > >>>>>> with: cb thunk. > >>>>>> sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| > values > >>>>>> doubleAt: i]. > >>>>>> values free. > >>>>>> ^orig -> sort > >>>>>> > >>>>>> The above example uses Alien to make the callout. To use it with > the > >>>>>> FFI simply pass cb pointer as the argument as is done above. > >>>>>> > >>>>>> > >>>>>> Implementation: > >>>>>> > >>>>>> The way that it works is in two parts > >>>>>> - the VM passes up a pointer to a structure from which all > arguments, > >>>>>> stacked and in registers (because the VM has copied the register > args > >>>>>> into the struct) can be accessed, and through which the result can > be > >>>>>> returned. > >>>>>> - the image level provides marshalling methods that match the > >>>>>> signature in the callback > >>>>>> > >>>>>> So e.g. with a callback of > >>>>>> Callback > >>>>>> signature: #(int (*)(const void *, const void *)) > >>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) > sign] > >>>>>> the marshalling methods are in Callback's signature protocol: > >>>>>> > >>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien > >>>>>> > >>>>>> ^callbackContext wordResult: > >>>>>> (block > >>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 1)) > >>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 5))) > >>>>>> > >>>>>> where spAlien is an Alien pointing to a VMCallbackContext32. > >>>>>> > >>>>>> For ARM support we would add > >>>>>> > >>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien > >>>>>> intRegArgs: regsAlien > >>>>>> > >>>>>> ^callbackContext wordResult: > >>>>>> (block > >>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) > >>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) > >>>>>> > >>>>>> Basically the idea is that the selector of the method doesn't matter > >>>>>> except for the number of arguments. What's important is the pragma > >>>>>> which defines the signature and the ABI for which this is a valid > >>>>>> marshalling method. > >>>>>> > >>>>>> When the callback is instantiated, Callback introspects to find the > >>>>>> marshalling method that matches the signature. If one doesn't > already > >>>>>> exist you can write one. Hopefully we'll write an ABI compiler that > >>>>>> will automatically generate these marshalling methods according to > the > >>>>>> platform's ABI, but for now its a manual process. But at least it's > >>>>>> open and flexible. When the callback is invoked the evaluator is > >>>>>> performed with the current callbackContext and pointer(s) to the > >>>>>> arguments. There is a 32-bit and a 64-bit callback context, and it > can > >>>>>> have a stack pointer, integer register args and floating point > >>>>>> register args. So it's general enough for any callback. > >>>>>> > >>>>>> To pass back the result, a value is assigned into the struct via the > >>>>>> accessor in the marshalling method and control returns to teh point > >>>>>> where teh callback comes in, and this uses a primitive to return. > >>>>>> Inside the callbackCOntext is a jmpbuf from a setjmp. The primitive > >>>>>> longjmp's back to the entry point in the VM which extracts the > result > >>>>>> and the code for the kind of result and returns: > >>>>>> > >>>>>> Callback class>>invokeCallbackContext: vmCallbackContextAddress > >>>>>> "" "^" > >>>>>> "The low-level entry-point for callbacks sent from the VM/IA32ABI > >>>>>> plugin. > >>>>>> Return via primReturnFromContext:through:. thisContext's sender is > the > >>>>>> call-out context." > >>>>>> | callbackAlien type | > >>>>>> callbackAlien := (Smalltalk wordSize = 4 > >>>>>> ifTrue: [VMCallbackContext32] > >>>>>> ifFalse: [VMCallbackContext64]) > >>>>>> atAddress: vmCallbackContextAddress. > >>>>>> [type := Callback evaluateCallbackForContext: callbackAlien] > >>>>>> ifCurtailed: [self error: 'attempt to non-local return across a > >>>>>> callback']. > >>>>>> type ifNil: > >>>>>> [type := 1. callbackAlien wordResult: -1]. > >>>>>> callbackAlien primReturnAs: type fromContext: thisContext > >>>>>> > >>>>>> On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta >>>>>> > wrote: > >>>>>> > >>>>>> > >>>>>> Hi all-- > >>>>>> > >>>>>> I'd like to use a C shared library via FFI from Squeak or > >>>>>> Pharo. > >>>>>> Specifically, I want to call a C function which takes as one of > its > >>>>>> parameters a pointer to an array of callback function addresses. > >>>>>> Does > >>>>>> one of the FFI approaches floating around handle that, and > provide a > >>>>>> relatively pleasant mapping between Smalltalk block closures and > C > >>>>>> callback function addresses? > >>>>>> > >>>>>> I was doing this so far in GemStone, but apparently its FFI > >>>>>> only > >>>>>> supports passing callback function addresses one at a time as > direct > >>>>>> parameters of C callouts. I suppose I could write a wrapper C > >>>>>> library > >>>>>> around the one I really want to use, that provides the callback > >>>>>> setup > >>>>>> interface that GemStone expects, but whenever I have to write > actual > >>>>>> C > >>>>>> code I start to think "Hm, why don't I just use a Smalltalk VM > for > >>>>>> which > >>>>>> I have the source?" :) All the fancy distributed object-database > >>>>>> stuff > >>>>>> that my project also wants can wait for a bit. > >>>>>> > >>>>>> > >>>>>> thanks! > >>>>>> > >>>>>> -C > >>>>>> > >>>>>> -- > >>>>>> Craig Latta > >>>>>> netjam.org > >>>>>> +31 6 2757 7177 (SMS ok) > >>>>>> + 1 415 287 3547 (no SMS) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> _,,,^..^,,,_ > >>>>>> best, Eliot > > > > > > > > I'd agree that the best thing for now is to leave it as an open question and then we should go for a solution that everyone feels comfortable with. I'm not sure though if a single GitHub repository will do the trick considering the meta information mentioned by David. However, we could e.g. use different branches for different Squeak versions, but we really need to think this through. A related question: how hard would it be to build plugins automatically (e.g. on Travis CI or on AppVeyor) from source? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150904/f3d955b3/attachment-0001.htm From hannes.hirzel at gmail.com Sat Sep 5 05:31:10 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Sat Sep 5 05:31:13 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: What about using new SqueakMap entries to find the plugins? The plugins may be in many places. --Hannes On 9/5/15, Fabio Niephaus wrote: > On Fri, Sep 4, 2015 at 9:26 AM Frank Shearar > wrote: > >> On 4 September 2015 at 07:01, Tobias Pape wrote: >> > >> > On 04.09.2015, at 05:46, Chris Muller wrote: >> > >> >>> I do think that anything is better than the current situation. A >> bucket of >> >>> any kind in an agreed upon location seems like a good place to start. >> >> >> >> I totally agree! >> > >> > what about >> > >> > http://github.com/squeak-vm/plugins >> > >> > or >> > >> > http://github.com/squeak-smalltalk/vm-plugins >> >> My preferred choice: the organisation already exists. >> >> frank >> >> > Best >> > -tobias >> > >> > PS: we should look at https://github.com/search?q=squeak+vm >> > >> >> >> >>> I >> >>> hadn't considered that plugins would need meta data or labels. >> >> >> >> They could be put into a .zip file and stored and cataloged somewhere >> >> which would be a well-known place for Squeak. And, each plugin would >> >> be tagged with one or more hierarchical Category's to indicate the >> >> platform and whatever else we wanted... >> >> >> >> And, if the plugin is compiled and hosted somewhere else, like GitHub, >> >> then the Squeak-well-known place should direct the user to THAT >> >> external place instead of hosting copies on squeak.org servers... >> >> Except as a backup, of course.. >> >> >> >> Hmm, if only we have something that could do all that... Oh wait, >> >> we do!!!! ;-) >> >> >> >>> Perhaps the best thing is to leave it as an open question for a few >> weeks >> >>> before settling on any kind of solution. A common location for >> >>> plugins >> is >> >>> about as far as my thinking takes me at the moment. I'm sure the >> collective >> >>> imagination of the community can come up with a better idea. >> >>> >> >>> Chris >> >>> >> >>> >> >>> On 2015-09-03 10:07 PM, David T. Lewis wrote: >> >>>> >> >>>> On Thu, Sep 03, 2015 at 09:05:07PM -0400, Chris Cunnington wrote: >> >>>>> >> >>>>> This community needs a repository for plugins. A directory at >> >>>>> http://ftp.squeak.org ought to do it. >> >>>>> >> >>>>> If I want to try Alien I need the plugin. Where am I going to get >> that? >> >>>>> I could get VMMaker, read NewSqueakIA32ABIPlugin three times to see >> it >> >>>>> is not saying Newspeak and realize it compiles a plugin called >> IA32ABI, >> >>>>> which - coincidentally - is the name of the plugin the error Alien >> >>>>> exampleCqsort will gives me. (NewSqueakIA32ABIPlugin class>> >> moduleName >> >>>>> returns IA32ABI). >> >>>>> >> >>>>> Does anybody know what the Genie plugin does? Does Paul DeBrucker >> need >> >>>>> to store a BerkeleyDB plugin dll he got by emailing somebody on >> GitHub? >> >>>>> >> >>>>> If I understand this correctly, if such a directory existed, then >> all a >> >>>>> person would need to do to try the above Alien code would be to >> download >> >>>>> a pre-compiled plugin from - say - >> >>>>> http://ftp.squeak/plugins/Alien/fooVersion, put it in their VM >> directory >> >>>>> and start the image. Then check with SmalltalkImage current >> >>>>> listLoadedModules to see if you're ready to go. >> >>>>> >> >>>>> I nominate Fabio Niephaus to be the person the community can send >> >>>>> pre-compiled plugins for inclusion in such a directory. Eliot's >> >>>>> been >> >>>>> banging away about Alien for some time [1]. If a person could go, >> >>>>> get >> >>>>> the plugin and give the code shot, he could have more productive >> >>>>> conversations about Alien. >> >>>>> >> >>>>> So, if, Eliot, you have a pre-compiled plugin for Alien, perhaps in >> an >> >>>>> idle moment, you could email it to Fabio? And when, Fabio, you've >> >>>>> created the directory in http://ftp.squeak.org you could announce >> >>>>> it >> >>>>> here on Squeak-dev? >> >>>>> >> >>>>> FWIW, >> >>>>> >> >>>>> Chris >> >>>> >> >>>> A word of caution: >> >>>> >> >>>> I think the idea is good in principle, but it needs to be >> >>>> accompanied >> >>>> by a commitment by someone to do the hard work of keeping track of >> >>>> dependencies on the various flavors of OS, image word size, VM word >> size, >> >>>> spur/V3, and so forth. If someone would like to take that on, great. >> >>>> That said, we don't want to start a project that gets 80% completed, >> and >> >>>> then expect "the community" to do the rest of the work. >> >>>> >> >>>> I cannot speak for Fabio, but I don't think it is fair for us to >> expect >> >>>> him to take on this kind of workload unless he has indicated an >> interest >> >>>> in doing it. >> >>>> >> >>>> Maybe a restricted repository focused just on compiled plugins known >> >>>> to work with the Spur VM on a limited range of OS flavors would be >> helpful >> >>>> at this stage. It probably does not belong on ftp.squeak.org, but it >> could >> >>>> be a very useful resource if someone (Chris Cunnington?) wants to >> >>>> set >> it >> >>>> up. >> >>>> >> >>>> Dave >> >>>> >> >>>> >> >>>>> [1] http://wiki.squeak.org/squeak/uploads/6100/ >> >>>>> >> >>>>> On 2015-09-03 7:07 PM, Eliot Miranda wrote: >> >>>>>> >> >>>>>> Hi Craig, >> >>>>>> >> >>>>>> you need Alien-eem.24 >> >>>>>> >> >>>>>> Here's Alien class>>exampleCqsort >> >>>>>> "Call the libc qsort function (which requires a callback)." >> >>>>>> "Alien exampleCqsort" >> >>>>>> "(Time millisecondsToRun: [100 timesRepeat: [Alien >> >>>>>> exampleCqsort]]) >> / >> >>>>>> 100.0" >> >>>>>> | cb rand nElements sizeofDouble values orig sort | >> >>>>>> rand := Random new. >> >>>>>> values := Alien newC: (nElements := 100) * (sizeofDouble := 8). >> >>>>>> 1 to: values dataSize by: sizeofDouble do: >> >>>>>> [:i| values doubleAt: i put: rand next]. >> >>>>>> orig := (1 to: values dataSize by: sizeofDouble) collect: [:i| >> values >> >>>>>> doubleAt: i]. >> >>>>>> cb := Callback >> >>>>>> signature: #(int (*)(const void *, const void *)) >> >>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) >> sign]. >> >>>>>> (Alien lookup: 'qsort' inLibrary: Alien libcName) >> >>>>>> primFFICallResult: nil >> >>>>>> with: values pointer >> >>>>>> with: nElements >> >>>>>> with: sizeofDouble >> >>>>>> with: cb thunk. >> >>>>>> sort := (1 to: values dataSize by: sizeofDouble) collect: [:i| >> values >> >>>>>> doubleAt: i]. >> >>>>>> values free. >> >>>>>> ^orig -> sort >> >>>>>> >> >>>>>> The above example uses Alien to make the callout. To use it with >> the >> >>>>>> FFI simply pass cb pointer as the argument as is done above. >> >>>>>> >> >>>>>> >> >>>>>> Implementation: >> >>>>>> >> >>>>>> The way that it works is in two parts >> >>>>>> - the VM passes up a pointer to a structure from which all >> arguments, >> >>>>>> stacked and in registers (because the VM has copied the register >> args >> >>>>>> into the struct) can be accessed, and through which the result can >> be >> >>>>>> returned. >> >>>>>> - the image level provides marshalling methods that match the >> >>>>>> signature in the callback >> >>>>>> >> >>>>>> So e.g. with a callback of >> >>>>>> Callback >> >>>>>> signature: #(int (*)(const void *, const void *)) >> >>>>>> block: [ :arg1 :arg2 | ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) >> sign] >> >>>>>> the marshalling methods are in Callback's signature protocol: >> >>>>>> >> >>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >> >>>>>> >> >>>>>> ^callbackContext wordResult: >> >>>>>> (block >> >>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 1)) >> >>>>>> value: (Alien forPointer: (spAlien unsignedLongAt: 5))) >> >>>>>> >> >>>>>> where spAlien is an Alien pointing to a VMCallbackContext32. >> >>>>>> >> >>>>>> For ARM support we would add >> >>>>>> >> >>>>>> Callback>>voidstarvoidstarRetint: callbackContext sp: spAlien >> >>>>>> intRegArgs: regsAlien >> >>>>>> >> >>>>>> ^callbackContext wordResult: >> >>>>>> (block >> >>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 1)) >> >>>>>> value: (Alien forPointer: (regsAlien unsignedLongAt: 5))) >> >>>>>> >> >>>>>> Basically the idea is that the selector of the method doesn't >> >>>>>> matter >> >>>>>> except for the number of arguments. What's important is the >> >>>>>> pragma >> >>>>>> which defines the signature and the ABI for which this is a valid >> >>>>>> marshalling method. >> >>>>>> >> >>>>>> When the callback is instantiated, Callback introspects to find >> >>>>>> the >> >>>>>> marshalling method that matches the signature. If one doesn't >> already >> >>>>>> exist you can write one. Hopefully we'll write an ABI compiler >> >>>>>> that >> >>>>>> will automatically generate these marshalling methods according to >> the >> >>>>>> platform's ABI, but for now its a manual process. But at least >> >>>>>> it's >> >>>>>> open and flexible. When the callback is invoked the evaluator is >> >>>>>> performed with the current callbackContext and pointer(s) to the >> >>>>>> arguments. There is a 32-bit and a 64-bit callback context, and it >> can >> >>>>>> have a stack pointer, integer register args and floating point >> >>>>>> register args. So it's general enough for any callback. >> >>>>>> >> >>>>>> To pass back the result, a value is assigned into the struct via >> >>>>>> the >> >>>>>> accessor in the marshalling method and control returns to teh >> >>>>>> point >> >>>>>> where teh callback comes in, and this uses a primitive to return. >> >>>>>> Inside the callbackCOntext is a jmpbuf from a setjmp. The >> >>>>>> primitive >> >>>>>> longjmp's back to the entry point in the VM which extracts the >> result >> >>>>>> and the code for the kind of result and returns: >> >>>>>> >> >>>>>> Callback class>>invokeCallbackContext: vmCallbackContextAddress >> >>>>>> "" "^" >> >>>>>> "The low-level entry-point for callbacks sent from the VM/IA32ABI >> >>>>>> plugin. >> >>>>>> Return via primReturnFromContext:through:. thisContext's sender >> >>>>>> is >> the >> >>>>>> call-out context." >> >>>>>> | callbackAlien type | >> >>>>>> callbackAlien := (Smalltalk wordSize = 4 >> >>>>>> ifTrue: [VMCallbackContext32] >> >>>>>> ifFalse: [VMCallbackContext64]) >> >>>>>> atAddress: vmCallbackContextAddress. >> >>>>>> [type := Callback evaluateCallbackForContext: callbackAlien] >> >>>>>> ifCurtailed: [self error: 'attempt to non-local return across a >> >>>>>> callback']. >> >>>>>> type ifNil: >> >>>>>> [type := 1. callbackAlien wordResult: -1]. >> >>>>>> callbackAlien primReturnAs: type fromContext: thisContext >> >>>>>> >> >>>>>> On Thu, Sep 3, 2015 at 5:22 AM, Craig Latta > >>>>>> > wrote: >> >>>>>> >> >>>>>> >> >>>>>> Hi all-- >> >>>>>> >> >>>>>> I'd like to use a C shared library via FFI from Squeak or >> >>>>>> Pharo. >> >>>>>> Specifically, I want to call a C function which takes as one of >> its >> >>>>>> parameters a pointer to an array of callback function >> >>>>>> addresses. >> >>>>>> Does >> >>>>>> one of the FFI approaches floating around handle that, and >> provide a >> >>>>>> relatively pleasant mapping between Smalltalk block closures >> >>>>>> and >> C >> >>>>>> callback function addresses? >> >>>>>> >> >>>>>> I was doing this so far in GemStone, but apparently its >> >>>>>> FFI >> >>>>>> only >> >>>>>> supports passing callback function addresses one at a time as >> direct >> >>>>>> parameters of C callouts. I suppose I could write a wrapper C >> >>>>>> library >> >>>>>> around the one I really want to use, that provides the callback >> >>>>>> setup >> >>>>>> interface that GemStone expects, but whenever I have to write >> actual >> >>>>>> C >> >>>>>> code I start to think "Hm, why don't I just use a Smalltalk VM >> for >> >>>>>> which >> >>>>>> I have the source?" :) All the fancy distributed >> >>>>>> object-database >> >>>>>> stuff >> >>>>>> that my project also wants can wait for a bit. >> >>>>>> >> >>>>>> >> >>>>>> thanks! >> >>>>>> >> >>>>>> -C >> >>>>>> >> >>>>>> -- >> >>>>>> Craig Latta >> >>>>>> netjam.org >> >>>>>> +31 6 2757 7177 (SMS ok) >> >>>>>> + 1 415 287 3547 (no SMS) >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> _,,,^..^,,,_ >> >>>>>> best, Eliot >> > >> > >> > >> >> > I'd agree that the best thing for now is to leave it as an open question > and then we should go for a solution that everyone feels comfortable > with. > > I'm not sure though if a single GitHub repository will do the trick > considering the meta information mentioned by David. > However, we could e.g. use different branches for different Squeak > versions, but we really need to think this through. > > A related question: how hard would it be to build plugins > automatically (e.g. on Travis CI or on AppVeyor) from source? > From Das.Linux at gmx.de Sat Sep 5 06:16:08 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat Sep 5 06:16:12 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: On 05.09.2015, at 07:31, H. Hirzel wrote: > What about using new SqueakMap entries to find the plugins? > > The plugins may be in many places. This won't help for the binaries, tho. Best regards -Tobias From hannes.hirzel at gmail.com Sat Sep 5 07:19:28 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Sat Sep 5 07:19:31 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: I mean to use the function of SqueakMap being a catalogue which references artefacts available elsewhere. For dealing with binaries additional provision has to be made to deal with it. --Hannes On 9/5/15, Tobias Pape wrote: > > On 05.09.2015, at 07:31, H. Hirzel wrote: > >> What about using new SqueakMap entries to find the plugins? >> >> The plugins may be in many places. > > This won't help for the binaries, tho. > > Best regards > -Tobias > > > From hannes.hirzel at gmail.com Sat Sep 5 08:15:29 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Sat Sep 5 08:15:32 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: Or better a repository here https://github.com/squeak-smalltalk On 9/5/15, H. Hirzel wrote: > I mean to use the function of SqueakMap being a catalogue which > references artefacts available elsewhere. > > For dealing with binaries additional provision has to be made to deal with > it. > > --Hannes > > On 9/5/15, Tobias Pape wrote: >> >> On 05.09.2015, at 07:31, H. Hirzel wrote: >> >>> What about using new SqueakMap entries to find the plugins? >>> >>> The plugins may be in many places. >> >> This won't help for the binaries, tho. >> >> Best regards >> -Tobias >> >> >> > From hannes.hirzel at gmail.com Sat Sep 5 15:32:24 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Sat Sep 5 15:32:27 2015 Subject: [squeak-dev] Updating SAR builder tool In-Reply-To: References: <02A6AB19-EEF7-4E42-AFE9-9C90FD6E5DAB@rowledge.org> <20150828011912.GB98083@shell.msen.com> <0B7902AB-FBEF-4235-BC1B-E133EFBFB7C0@gmail.com> <3586E956-0DB3-4239-BB26-E5F2C7B90863@rowledge.org> <2FD28CBD-E286-4A32-9C33-80A9B2480ACF@me.com> Message-ID: What about adding Edgar's extension of PackageInfo and Monticello to allow resources (jpg, png, mp3) to be added to mcz files? --Hannes On 8/30/15, Edgar De Cleene wrote: > Sure you could made good use of this, and thanks for your music > >> On Aug 29, 2015, at 11:29, Raymond Asselin wrote: >> >> Muchos gratias Edgar >> >> Au plaisir >> Raymond Asselin >> >>> Le 2015-08-29 ? 06:31, Edgar De Cleene a ?crit >>> : >>> >>> The quick dirty how to >>> >>> https://youtu.be/EZucdZZCdYY >>> >>> And Tim I say ?Dave? in the video but is dedicated to all good people >>> here >>> >>> >>>> On Aug 28, 2015, at 1:46 PM, tim Rowledge wrote: >>>> >>>> >>>>> On 28-08-2015, at 12:51 AM, Edgar De Cleene >>>>> wrote: >>>>> >>>>> And why do not take my idea of have a Monticello thing what mimics .sar >>>>> ? >>>> >>>> If you have a better solution, I?m all for using it. All I need is a way >>>> to be able to deliver some code/resources to users so they can use their >>>> shiny new SuperMegaHAT. That might mean ARM executable files, images, >>>> html files for the help system, sound files, whatever. >>>> >>>> I wasn?t even aware that MC could handle non-code stuff, but then the >>>> list of things about MC that I am unaware of may as well be considered >>>> an uncountable infinite set. >>>> >>>> >>>> tim >>>> -- >>>> tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim >>>> Strange OpCodes: MII: Mask all Interrupts and then Interrupt >>> >>> >> > > > From craig at netjam.org Sat Sep 5 16:23:35 2015 From: craig at netjam.org (Craig Latta) Date: Sat Sep 5 16:23:39 2015 Subject: [squeak-dev] re: FFI callbacks In-Reply-To: References: Message-ID: <55EB1707.5090106@netjam.org> > you need Alien-eem.24... [many useful details] Thanks, Eliot! I'll give it a try. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From asqueaker at gmail.com Sat Sep 5 17:16:19 2015 From: asqueaker at gmail.com (Chris Muller) Date: Sat Sep 5 17:16:23 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: On Sat, Sep 5, 2015 at 2:19 AM, H. Hirzel wrote: > I mean to use the function of SqueakMap being a catalogue which > references artefacts available elsewhere. Yep, binaries are no problem for SqueakMap, it was designed to solve exactly this problem -- the cataloging of any software, in any format, hosted at any location. > For dealing with binaries additional provision has to be made to deal with it. No additional provisions need to be made, except possibly adding a "Plugin" category. From Das.Linux at gmx.de Sat Sep 5 21:47:15 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat Sep 5 21:47:20 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: On 05.09.2015, at 19:16, Chris Muller wrote: > On Sat, Sep 5, 2015 at 2:19 AM, H. Hirzel wrote: >> I mean to use the function of SqueakMap being a catalogue which >> references artefacts available elsewhere. > > Yep, binaries are no problem for SqueakMap, it was designed to solve > exactly this problem -- the cataloging of any software, in any format, > hosted at any location. > >> For dealing with binaries additional provision has to be made to deal with it. > > No additional provisions need to be made, except possibly adding a > "Plugin" category. I'm unsure. Its external things, nothing that is in image. In my humble option, the 'execute anything' approach of SqueakMap has its appeal, but I don't think its sustainable. I'd like to keep existing stuff there, but I'd refrain from putting new projects there, or only if SqueakMap would support Metacello natively. Best regards -Tobias From ma.chris.m at gmail.com Sat Sep 5 23:47:42 2015 From: ma.chris.m at gmail.com (Chris Muller) Date: Sat Sep 5 23:48:25 2015 Subject: [squeak-dev] Plugin Repository Needed [was FFI callbacks] In-Reply-To: References: <55E8EE43.7040608@gmail.com> <20150904020711.GB67624@shell.msen.com> <55E906A5.1080209@gmail.com> <20FFB3DD-C0DF-4ECE-BA35-E4084CEDEE83@gmx.de> Message-ID: >> On Sat, Sep 5, 2015 at 2:19 AM, H. Hirzel wrote: >>> I mean to use the function of SqueakMap being a catalogue which >>> references artefacts available elsewhere. >> >> Yep, binaries are no problem for SqueakMap, it was designed to solve >> exactly this problem -- the cataloging of any software, in any format, >> hosted at any location. >> >>> For dealing with binaries additional provision has to be made to deal with it. >> >> No additional provisions need to be made, except possibly adding a >> "Plugin" category. > > I'm unsure. Its external things, nothing that is in image. The image knows where the VM is installed. With SqueakMap you could browse all entries in the new "Plugin" Category, and simply right-click "Install" any of them straight into the system on the spot, without ever leaving the image. SqueakMap automatically backs things up in its local cache, so there'd be a copy there too.. > In my humble option, the 'execute anything' approach of SqueakMap has > its appeal, but I don't think its sustainable. Actually, sustainability and avoiding bit-rot were major core requirements [1] of the 2011 effort, and, in fact, having a catalog of pure Smalltalk snippets organized and hierarchically tagged, is of the aspects that has contributed to its sustainability. If you are going to say something is unsustainable, please say why.. > I'd like to keep existing stuff > there, Right, and that's why "existing stuff" remains still accessible to this day, and thru tommorrow, because it this approach _is_ sustainable. If it weren't, they wouldn't be.. > but I'd refrain from putting new projects there, or only if SqueakMap > would support Metacello natively. I really don't understand why you feel threatened by SqueakMap -- or why you feel it is a substitute or alternative to Metacello. It's just documentation for goodness' sake. Is it okay with you if some of us document some project locations to help newbies and ourselves? What about that new user just last week? He wanted to install Seaside into Squeak 5. Now, if seaside.st or squeak.org/projects would just refer users exclusively to SqueakMap for installation, then he would have been playing with Seaside in under 5 minutes because, guess what, Seaside 3.1.1 installs flawlessly into Squeak 5 from SqueakMap right now. Unfortunately, seaside.st and squeak.org/projects decides instead to provide the little snippets of code for installation right there on the web-page (hard-coded? how is that for sustainable?) which, surprise surprise, *don't work*. Another user, left high-and-dry. Cases like his bother me, and are what caused me to expend all that effort in 2011 to solve this issue. If there's something wrong with it, could you help me fix it instead of tearing it down? I think most people like Squeak to have an "App Store", and want their projects to be visible there, that's why we are already up to 23 packages in there for 5.0. If making SqueakMap support Metacello natively would win your support, it would make me very happy. It already supports about 5 or 10 other formats natively, why not? - Chris [1] -- http://wiki.squeak.org/squeak/6183 From brasspen at gmail.com Sun Sep 6 16:20:16 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Sun Sep 6 16:20:20 2015 Subject: [squeak-dev] Trying Alien Message-ID: <55EC67C0.8020801@gmail.com> I forgot that there are two kinds of plugins: internal and external. And IA32ABI is both internal and included in each Cog virtual machine. If I download Squeak 5.0 onto my Ubuntu 15.04 laptop from the homepage and execute: Smalltalk listBuiltinModules do: [:ea| Transcript cr; show: ea] I can see IA32ABI is clearly loaded. Then I can go to squeaksource.com/Alien and load Alien into then execute in a Workspace. Alien exampleCqsort. This will produce an array of numbers. (Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / 100.0 This will return ~1.0. So, it looks like trying it out is not so hard. I'm not sure what it all means, but I have a successful control experiment at this point to work with. Perhaps I need to read the documentation now to explain what I'm seeing? A plugin repository would not account for internal plugins, but I still think it's a good idea. It could focus and foster external plugin hacking. The issue about what kind of repository (ftp.squeak.org, GitHub, TravisCI) is where a URL will point. Wherever client that socket is accessed by, either SqueakMap or a browser, seems to be a subordinate issue people could decide for themselves. Chris From tim at rowledge.org Sun Sep 6 17:46:45 2015 From: tim at rowledge.org (tim Rowledge) Date: Sun Sep 6 17:46:50 2015 Subject: [squeak-dev] Trying Alien In-Reply-To: <55EC67C0.8020801@gmail.com> References: <55EC67C0.8020801@gmail.com> Message-ID: <51BB12D2-7FB6-452C-92CE-A44D52D77D75@rowledge.org> On 06-09-2015, at 9:20 AM, Chris Cunnington wrote: > A plugin repository would not account for internal plugins, but I still think it's a good idea. It could focus and foster external plugin hacking. Well, yes and no - don?t forget that all plugins are supposed to be compilable for either case and that the vm is supposed to check for an external plugin before looking at the internal ones. That latter part was intended to allow for over-riding buggy internal plugins in our original ?spec?, such as it was. Part of any plugin repository should be the inclusion of all plugins; then we can easily grab one to test if an internal plugin is suspected buggy. We shouldn?t forget that plugins are unloadable too. Or at least, they?re supposed to be! This is intended to help in development and testing of the plugins; you can write, build, try (which loads) and unload, rinse & repeat. Even internal plugins can be unloaded and in fact you ought to be able to have a running system, grab a new/fixed/experimental external version of XYPlugin, unload the already in use internal XYPlugin and make a call to an XYPlugin routine. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level. From commits at source.squeak.org Sun Sep 6 20:47:10 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sun Sep 6 20:47:12 2015 Subject: [squeak-dev] The Trunk: CollectionsTests-ul.249.mcz Message-ID: Levente Uzonyi uploaded a new version of CollectionsTests to project The Trunk: http://source.squeak.org/trunk/CollectionsTests-ul.249.mcz ==================== Summary ==================== Name: CollectionsTests-ul.249 Author: ul Time: 6 September 2015, 5:07:02.126 pm UUID: 1ea5b300-f467-4693-91b6-92bcf967bc54 Ancestors: CollectionsTests-eem.248 Added thorough tests for the integer accessors of ByteArray's platform independent access category. =============== Diff against CollectionsTests-eem.248 =============== Item was added: + ----- Method: ByteArrayTest>>byteArrayFor:bits:bigEndian: (in category 'testing - platform independent access') ----- + byteArrayFor: signedValue bits: bits bigEndian: bigEndian + + | unsignedValue size result | + unsignedValue := signedValue negative + ifTrue: [ signedValue + (1 bitShift: bits) ] + ifFalse: [ signedValue ]. + size := bits // 8. + result := ByteArray new: size. + 1 to: size do: [ :index | + result at: index put: (unsignedValue digitAt: index) ]. + bigEndian ifTrue: [ result reverseInPlace ]. + ^result + ! Item was removed: - ----- Method: ByteArrayTest>>testByteArrayLongAtPreservesSign (in category 'as yet unclassified') ----- - testByteArrayLongAtPreservesSign - | ba value | - ba := ByteArray new: 4. - value := -1. - ba longAt: 1 put: value bigEndian: true. - self assert: (ba longAt: 1 bigEndian: true) = value. - ba longAt: 1 put: value bigEndian: false. - self assert: (ba longAt: 1 bigEndian: false) = value.! Item was added: + ----- Method: ByteArrayTest>>testPlatformIndepentendIntegerAccessorsAtBitBorders (in category 'testing - platform independent access') ----- + testPlatformIndepentendIntegerAccessorsAtBitBorders + + #( + shortAt:put:bigEndian: shortAt:bigEndian: false 16 + longAt:put:bigEndian: longAt:bigEndian: false 32 + unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16 + unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32 + unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64 + ) groupsDo: [ :setter :getter :unsigned :storageBits | + self + verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter: setter + getter: getter + unsigned: unsigned + storageBits: storageBits ]! Item was added: + ----- Method: ByteArrayTest>>testPlatformIndepentendIntegerAccessorsWithRandomValues (in category 'testing - platform independent access') ----- + testPlatformIndepentendIntegerAccessorsWithRandomValues + + | random | + random := Random seed: 36rSqueak. + #( + shortAt:put:bigEndian: shortAt:bigEndian: false 16 + longAt:put:bigEndian: longAt:bigEndian: false 32 + unsignedShortAt:put:bigEndian: unsignedShortAt:bigEndian: true 16 + unsignedLongAt:put:bigEndian: unsignedLongAt:bigEndian: true 32 + unsignedLong64At:put:bigEndian: unsignedLong64At:bigEndian: true 64 + ) groupsDo: [ :setter :getter :unsigned :storageBits | + self + verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter: setter + getter: getter + unsigned: unsigned + storageBits: storageBits + random: random ]! Item was added: + ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter:getter:unsigned:storageBits: (in category 'testing - platform independent access') ----- + verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter: setter getter: getter unsigned: unsigned storageBits: storageBits + + | byteArray minValue maxValue baseValues | + byteArray := ByteArray new: storageBits // 8. + unsigned + ifTrue: [ + minValue := 0. + maxValue := 1 << storageBits - 1. + baseValues := #(0 1) ] + ifFalse: [ + minValue := -1 << (storageBits - 1). + maxValue := 1 << (storageBits - 1) - 1. + baseValues := #(-1 0 1) ]. + #(true false) do: [ :bigEndian | + 0 to: storageBits - 1 do: [ :bits | + baseValues do: [ :baseValue | + | centerValue | + centerValue := baseValue << bits. + centerValue - 1 to: centerValue + 1 do: [ :value | + (value between: minValue and: maxValue) ifTrue: [ + self + verifyPlatformIndepentendIntegerAccessorsMatch: byteArray + for: value + setter: setter + getter: getter + storageBits: storageBits + bigEndian: bigEndian ] ] ] ] ] + ! Item was added: + ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: (in category 'testing - platform independent access') ----- + verifyPlatformIndepentendIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian + + | expectedSetterResult getterResult | + expectedSetterResult := self byteArrayFor: value bits: storageBits bigEndian: bigEndian. + byteArray perform: setter with: 1 with: value with: bigEndian. + self assert: expectedSetterResult equals: byteArray. + getterResult := byteArray perform: getter with: 1 with: bigEndian. + self assert: value equals: getterResult! Item was added: + ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter:getter:unsigned:storageBits:random: (in category 'testing - platform independent access') ----- + verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter: setter getter: getter unsigned: unsigned storageBits: storageBits random: random + + | byteArray randomMax randomOffset | + byteArray := ByteArray new: storageBits // 8. + randomMax := 1 << storageBits. + randomOffset := unsigned + ifTrue: [ -1 ] + ifFalse: [ -1 << (storageBits - 1) - 1 ]. + 10000 timesRepeat: [ + | value | + value := (random nextInt: randomMax) + randomOffset. + #(true false) do: [ :bigEndian | + self + verifyPlatformIndepentendIntegerAccessorsMatch: byteArray + for: value + setter: setter + getter: getter + storageBits: storageBits + bigEndian: bigEndian ] ]! From commits at source.squeak.org Sun Sep 6 21:50:16 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sun Sep 6 21:50:18 2015 Subject: [squeak-dev] The Trunk: Collections-ul.654.mcz Message-ID: Levente Uzonyi uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ul.654.mcz ==================== Summary ==================== Name: Collections-ul.654 Author: ul Time: 6 September 2015, 11:42:17.51 pm UUID: 12c2810c-d06f-4ae8-86b4-67ca6f1d6d79 Ancestors: Collections-eem.653 Optimized all integer accessor methods in ByteArray's platform independent access category. =============== Diff against Collections-eem.653 =============== Item was changed: ----- Method: ByteArray>>longAt:bigEndian: (in category 'platform independent access') ----- + longAt: index bigEndian: bigEndian + "Return a 32-bit integer quantity starting from the given byte index. Use #normalize where necessary to ensure compatibility with non-30-bit SmallIntegers." + + | byte result | + bigEndian ifFalse: [ + (byte := self at: index + 3) <= 16r7F ifTrue: [ "Is the result non-negative?" + byte <= 16r3F ifTrue: [ + ^(((byte bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index) ]. + ^(LargePositiveInteger new: 4) + replaceFrom: 1 + to: 4 + with: self + startingAt: index; + normalize ]. + "Negative" + byte >= 16rC0 ifTrue: [ + ^-1 - (((((byte bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 1) bitXor: 16rFFFFFF) bitShift: 8) + ((self at: index) bitXor: 16rFF)) ]. + (result := LargeNegativeInteger new: 4) + digitAt: 4 put: ((self at: index + 3) bitXor: 16rFF); + digitAt: 3 put: ((self at: index + 2) bitXor: 16rFF); + digitAt: 2 put: ((self at: index + 1) bitXor: 16rFF). + (byte := ((self at: index) bitXor: 16rFF) + 1) <= 16rFF ifTrue: [ + ^result + digitAt: 1 put: byte; + normalize ]. + ^result + digitAt: 1 put: 16rFF; + - 1 "It's tempting to do the subtraction in a loop, to avoid the LargeInteger creation, but it's actually slower than this." ]. + (byte := self at: index) <= 16r7F ifTrue: [ "Is the result non-negative?" + byte <= 16r3F ifTrue: [ + ^(((byte bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 3) ]. + ^(LargePositiveInteger new: 4) + digitAt: 1 put: (self at: index + 3); + digitAt: 2 put: (self at: index + 2); + digitAt: 3 put: (self at: index + 1); + digitAt: 4 put: byte; + normalize ]. + "Negative" + 16rC0 <= byte ifTrue: [ + ^-1 - (((((byte bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index + 2) bitXor: 16rFFFFFF) bitShift: 8) + ((self at: index + 3) bitXor: 16rFF)) ]. + (result := LargeNegativeInteger new: 4) + digitAt: 4 put: (byte bitXor: 16rFF); + digitAt: 3 put: ((self at: index + 1) bitXor: 16rFF); + digitAt: 2 put: ((self at: index + 2) bitXor: 16rFF). + (byte := ((self at: index + 3) bitXor: 16rFF) + 1) <= 16rFF ifTrue: [ + ^result + digitAt: 1 put: byte; + normalize ]. + ^result + digitAt: 1 put: 16rFF; + - 1 "It's tempting to do the subtraction in a loop, to avoid the LargeInteger creation, but it's actually slower than this."! - longAt: index bigEndian: aBool - "Return a 32bit integer quantity starting from the given byte index" - | b0 b1 b2 w h | - aBool ifTrue:[ - b0 := self at: index. - b1 := self at: index+1. - b2 := self at: index+2. - w := self at: index+3. - ] ifFalse:[ - w := self at: index. - b2 := self at: index+1. - b1 := self at: index+2. - b0 := self at: index+3. - ]. - "Minimize LargeInteger arithmetic" - h := ((b0 bitAnd: 16r7F) - (b0 bitAnd: 16r80) bitShift: 8) + b1. - b2 = 0 ifFalse:[w := (b2 bitShift: 8) + w]. - h = 0 ifFalse:[w := (h bitShift: 16) + w]. - ^w! Item was changed: ----- Method: ByteArray>>longAt:put:bigEndian: (in category 'platform independent access') ----- + longAt: index put: value bigEndian: bigEndian + "Store a 32-bit signed integer quantity starting from the given byte index" + + | v v2 | + value isLarge ifTrue: [ + bigEndian ifFalse: [ + value positive ifTrue: [ + self + replaceFrom: index + to: index + 3 + with: value + startingAt: 1. + ^value ]. + v := 0. + [ v <= 3 and: [ (v2 := ((value digitAt: v + 1) bitXor: 16rFF) + 1) = 16r100 ] ] whileTrue: [ + self at: index + v put: 0. + v := v + 1 ]. + self at: index + v put: v2. + v := v + 1. + [ v <= 3 ] whileTrue: [ + self at: index + v put: ((value digitAt: (v := v + 1)) bitXor: 16rFF) ]. + ^value ]. + value positive ifTrue: [ + self + at: index put: (value digitAt: 4); + at: index + 1 put: (value digitAt: 3); + at: index + 2 put: (value digitAt: 2); + at: index + 3 put: (value digitAt: 1). + ^value ]. + v := 3. + [ 0 <= v and: [ (v2 := ((value digitAt: 4 - v) bitXor: 16rFF) + 1) = 16r100 ] ] whileTrue: [ + self at: index + v put: 0. + v := v - 1 ]. + self at: index + v put: v2. + [ 0 <= (v := v - 1) ] whileTrue: [ + self at: index + v put: ((value digitAt: 4 - v) bitXor: 16rFF) ]. + ^value ]. + v := value bitShift: -24. + 0 <= (v := (v bitAnd: 16r7F) - (v bitAnd: 16r80)) ifFalse: [ + v := v + 16r100 ]. + bigEndian ifFalse: [ + self + at: index put: (value bitAnd: 16rFF); + at: index + 1 put: ((value bitShift: -8) bitAnd: 16rFF); + at: index + 2 put: ((value bitShift: -16) bitAnd: 16rFF); + at: index + 3 put: v. + ^value ]. + self + at: index put: v; + at: index + 1 put: ((value bitShift: -16) bitAnd: 16rFF); + at: index + 2 put: ((value bitShift: -8) bitAnd: 16rFF); + at: index + 3 put: (value bitAnd: 16rFF). - longAt: index put: value bigEndian: aBool - "Return a 32bit integer quantity starting from the given byte index" - | b0 b1 b2 b3 | - b0 := value bitShift: -24. - b0 := (b0 bitAnd: 16r7F) - (b0 bitAnd: 16r80). - b0 < 0 ifTrue:[b0 := 256 + b0]. - b1 := (value bitShift: -16) bitAnd: 255. - b2 := (value bitShift: -8) bitAnd: 255. - b3 := value bitAnd: 255. - aBool ifTrue:[ - self at: index put: b0. - self at: index+1 put: b1. - self at: index+2 put: b2. - self at: index+3 put: b3. - ] ifFalse:[ - self at: index put: b3. - self at: index+1 put: b2. - self at: index+2 put: b1. - self at: index+3 put: b0. - ]. ^value! Item was changed: ----- Method: ByteArray>>shortAt:bigEndian: (in category 'platform independent access') ----- + shortAt: index bigEndian: bigEndian + "Return a 16-bit signed integer quantity starting from the given byte index" + + | result | + result := bigEndian + ifFalse: [ ((self at: index + 1) bitShift: 8) + (self at: index) ] + ifTrue: [ ((self at: index) bitShift: 8) + (self at: index + 1) ]. + result < 16r8000 ifTrue: [ ^result ]. + ^result - 16r10000! - shortAt: index bigEndian: aBool - "Return a 16 bit integer quantity starting from the given byte index" - | uShort | - uShort := self unsignedShortAt: index bigEndian: aBool. - ^(uShort bitAnd: 16r7FFF) - (uShort bitAnd: 16r8000)! Item was changed: ----- Method: ByteArray>>shortAt:put:bigEndian: (in category 'platform independent access') ----- + shortAt: index put: value bigEndian: bigEndian + "Store a 16-bit signed integer quantity starting from the given byte index" + + | unsignedValue | + (unsignedValue := value) < 0 ifTrue: [ + unsignedValue := unsignedValue + 16r10000 ]. + bigEndian ifFalse: [ + self + at: index + 1 put: (unsignedValue bitShift: -8); + at: index put: (unsignedValue bitAnd: 16rFF). + ^value ]. + self + at: index put: (unsignedValue bitShift: -8); + at: index + 1 put: (unsignedValue bitAnd: 16rFF). - shortAt: index put: value bigEndian: aBool - "Store a 16 bit integer quantity starting from the given byte index" - self unsignedShortAt: index put: (value bitAnd: 16r7FFF) - (value bitAnd: -16r8000) bigEndian: aBool. ^value! Item was changed: ----- Method: ByteArray>>unsignedLong64At:bigEndian: (in category 'platform independent access') ----- + unsignedLong64At: index bigEndian: bigEndian + "Return a 64-bit unsigned integer quantity starting from the given byte index. Use #normalize where necessary to ensure compatibility with non-30-bit SmallIntegers." - unsignedLong64At: index bigEndian: aBool - "Avoid as much largeInteger as we can" - | b0 b2 b3 b5 b6 w n2 n3 | + | v | + bigEndian ifFalse: [ + (v := self at: index + 7) = 0 ifFalse: [ + ^(LargePositiveInteger new: 8) + digitAt: 1 put: (self at: index); + digitAt: 2 put: (self at: index + 1); + digitAt: 3 put: (self at: index + 2); + digitAt: 4 put: (self at: index + 3); + digitAt: 5 put: (self at: index + 4); + digitAt: 6 put: (self at: index + 5); + digitAt: 7 put: (self at: index + 6); + digitAt: 8 put: v; + normalize ]. + (v := self at: index + 6) = 0 ifFalse: [ + ^(LargePositiveInteger new: 7) + digitAt: 1 put: (self at: index); + digitAt: 2 put: (self at: index + 1); + digitAt: 3 put: (self at: index + 2); + digitAt: 4 put: (self at: index + 3); + digitAt: 5 put: (self at: index + 4); + digitAt: 6 put: (self at: index + 5); + digitAt: 7 put: v; + normalize ]. + (v := self at: index + 5) = 0 ifFalse: [ + ^(LargePositiveInteger new: 6) + digitAt: 1 put: (self at: index); + digitAt: 2 put: (self at: index + 1); + digitAt: 3 put: (self at: index + 2); + digitAt: 4 put: (self at: index + 3); + digitAt: 5 put: (self at: index + 4); + digitAt: 6 put: v; + normalize ]. + (v := self at: index + 4) = 0 ifFalse: [ + ^(LargePositiveInteger new: 5) + digitAt: 1 put: (self at: index); + digitAt: 2 put: (self at: index + 1); + digitAt: 3 put: (self at: index + 2); + digitAt: 4 put: (self at: index + 3); + digitAt: 5 put: v; + normalize ]. + (v := self at: index + 3) <= 16r3F ifFalse: [ + ^(LargePositiveInteger new: 4) + digitAt: 1 put: (self at: index); + digitAt: 2 put: (self at: index + 1); + digitAt: 3 put: (self at: index + 2); + digitAt: 4 put: v; + normalize ]. + ^(((v bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index) ]. + (v := self at: index) = 0 ifFalse: [ + ^(LargePositiveInteger new: 8) + digitAt: 1 put: (self at: index + 7); + digitAt: 2 put: (self at: index + 6); + digitAt: 3 put: (self at: index + 5); + digitAt: 4 put: (self at: index + 4); + digitAt: 5 put: (self at: index + 3); + digitAt: 6 put: (self at: index + 2); + digitAt: 7 put: (self at: index + 1); + digitAt: 8 put: v; + normalize ]. + (v := self at: index + 1) = 0 ifFalse: [ + ^(LargePositiveInteger new: 7) + digitAt: 1 put: (self at: index + 7); + digitAt: 2 put: (self at: index + 6); + digitAt: 3 put: (self at: index + 5); + digitAt: 4 put: (self at: index + 4); + digitAt: 5 put: (self at: index + 3); + digitAt: 6 put: (self at: index + 2); + digitAt: 7 put: v; + normalize ]. + (v := self at: index + 2) = 0 ifFalse: [ + ^(LargePositiveInteger new: 6) + digitAt: 1 put: (self at: index + 7); + digitAt: 2 put: (self at: index + 6); + digitAt: 3 put: (self at: index + 5); + digitAt: 4 put: (self at: index + 4); + digitAt: 5 put: (self at: index + 3); + digitAt: 6 put: v; + normalize ]. + (v := self at: index + 3) = 0 ifFalse: [ + ^(LargePositiveInteger new: 5) + digitAt: 1 put: (self at: index + 7); + digitAt: 2 put: (self at: index + 6); + digitAt: 3 put: (self at: index + 5); + digitAt: 4 put: (self at: index + 4); + digitAt: 5 put: v; + normalize ]. + (v := self at: index + 4) <= 16r3F ifFalse: [ + ^(LargePositiveInteger new: 4) + digitAt: 1 put: (self at: index + 7); + digitAt: 2 put: (self at: index + 6); + digitAt: 3 put: (self at: index + 5); + digitAt: 4 put: v; + normalize ]. + ^(((v bitShift: 8) + (self at: index + 5) bitShift: 8) + (self at: index + 6) bitShift: 8) + (self at: index + 7)! - aBool ifFalse: [ - w := self at: index. - b6 := self at: index+1. - b5 := self at: index+2. - n2 := self at: index+3. - b3 := self at: index+4. - b2 := self at: index+5. - n3 := self at: index+6. - b0 := self at: index+7. - ] ifTrue: [ - b0 := self at: index. - n3 := self at: index+1. - b2 := self at: index+2. - b3 := self at: index+3. - n2 := self at: index+4. - b5 := self at: index+5. - b6 := self at: index+6. - w := self at: index+7. - ]. - - "Minimize LargeInteger arithmetic" - b6 = 0 ifFalse:[w := (b6 bitShift: 8) + w]. - b5 = 0 ifFalse:[w := (b5 bitShift: 16) + w]. - - b3 = 0 ifFalse:[n2 := (b3 bitShift: 8) + n2]. - b2 = 0 ifFalse:[n2 := (b2 bitShift: 16) + n2]. - n2 == 0 ifFalse: [w := (n2 bitShift: 24) + w]. - - b0 = 0 ifFalse:[n3 := (b0 bitShift: 8) + n3]. - n3 == 0 ifFalse: [w := (n3 bitShift: 48) + w]. - - ^w! Item was changed: ----- Method: ByteArray>>unsignedLong64At:put:bigEndian: (in category 'platform independent access') ----- + unsignedLong64At: index put: value bigEndian: bigEndian + "Store a 64-bit unsigned integer quantity starting from the given byte index" + + value isLarge + ifTrue: [ + | i size | + size := value digitLength. + bigEndian ifFalse: [ + self + replaceFrom: index + to: index + size - 1 + with: value + startingAt: 1; + replaceFrom: index + size + to: index + 7 + with: #[0 0 0 0] + startingAt: 1. + ^value ]. + i := 1. + [ i <= size ] whileTrue: [ + self at: index + 8 - i put: (value digitAt: i). + i := i + 1 ]. + [ i <= 8 ] whileTrue: [ + self at: index + 8 - i put: 0. + i := i + 1 ] ] + ifFalse: [ + bigEndian ifFalse: [ + self + at: index put: (value bitAnd: 16rFF); + at: index + 1 put: ((value bitShift: -8) bitAnd: 16rFF); + at: index + 2 put: ((value bitShift: -16) bitAnd: 16rFF); + at: index + 3 put: (value bitShift: -24); + replaceFrom: index + 4 + to: index + 7 + with: #[0 0 0 0] + startingAt: 1. + ^value ]. + self + replaceFrom: index + to: index + 3 + with: #[0 0 0 0] + startingAt: 1; + at: index + 4 put: (value bitShift: -24); + at: index + 5 put: ((value bitShift: -16) bitAnd: 16rFF); + at: index + 6 put: ((value bitShift: -8) bitAnd: 16rFF); + at: index + 7 put: (value bitAnd: 16rFF) ]. + ^value! - unsignedLong64At: index put: value bigEndian: aBool - "Minimize largeInteger arithmetic" - | ix | - aBool ifFalse: [ - ix := index - 1. - 1 to: 8 do: [:pos| - self at: ix + pos put: (value digitAt: pos) - ]. - ] ifTrue: [ - ix := index + 8. - 1 to: 8 do: [:pos| - self at: ix - pos put: (value digitAt: pos) - ]. - ]. - ^value - ! Item was changed: ----- Method: ByteArray>>unsignedLongAt:bigEndian: (in category 'platform independent access') ----- + unsignedLongAt: index bigEndian: bigEndian + "Return a 32-bit unsigned integer quantity starting from the given byte index. Use #normalize where necessary to ensure compatibility with non-30-bit SmallIntegers." + + | byte | + bigEndian ifTrue: [ + (byte := self at: index) <= 16r3F ifTrue: [ + ^(((byte bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 3) ]. + ^(LargePositiveInteger new: 4) + digitAt: 1 put: (self at: index + 3); + digitAt: 2 put: (self at: index + 2); + digitAt: 3 put: (self at: index + 1); + digitAt: 4 put: byte; + normalize ]. + (byte := self at: index + 3) <= 16r3F ifTrue: [ + ^(((byte bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index) ]. + ^(LargePositiveInteger new: 4) + replaceFrom: 1 + to: 4 + with: self + startingAt: index; + normalize + ! - unsignedLongAt: index bigEndian: aBool - "Return a 32bit unsigned integer quantity starting from the given byte index" - | b0 b1 b2 w | - aBool ifTrue:[ - b0 := self at: index. - b1 := self at: index+1. - b2 := self at: index+2. - w := self at: index+3. - ] ifFalse:[ - w := self at: index. - b2 := self at: index+1. - b1 := self at: index+2. - b0 := self at: index+3. - ]. - "Minimize LargeInteger arithmetic" - b2 = 0 ifFalse:[w := (b2 bitShift: 8) + w]. - b1 = 0 ifFalse:[w := (b1 bitShift: 16) + w]. - b0 = 0 ifFalse:[w := (b0 bitShift: 24) + w]. - ^w! Item was changed: ----- Method: ByteArray>>unsignedLongAt:put:bigEndian: (in category 'platform independent access') ----- + unsignedLongAt: index put: value bigEndian: bigEndian + "Store a 32-bit unsigned integer quantity starting from the given byte index" + + value isLarge + ifTrue: [ + bigEndian ifFalse: [ + self + replaceFrom: index + to: index + 3 + with: value + startingAt: 1. + ^value ]. + self + at: index put: (value digitAt: 4); + at: index + 1 put: (value digitAt: 3); + at: index + 2 put: (value digitAt: 2); + at: index +3 put: (value digitAt: 1) ] + ifFalse: [ + bigEndian ifFalse: [ + self + at: index put: (value bitAnd: 16rFF); + at: index + 1 put: ((value bitShift: -8) bitAnd: 16rFF); + at: index + 2 put: ((value bitShift: -16) bitAnd: 16rFF); + at: index + 3 put: (value bitShift: -24). + ^value ]. + self + at: index put: (value bitShift: -24); + at: index + 1 put: ((value bitShift: -16) bitAnd: 16rFF); + at: index + 2 put: ((value bitShift: -8) bitAnd: 16rFF); + at: index + 3 put: (value bitAnd: 16rFF) ]. - unsignedLongAt: index put: value bigEndian: aBool - "Store a 32bit unsigned integer quantity starting from the given byte index" - | b0 b1 b2 b3 | - b0 := value bitShift: -24. - b1 := (value bitShift: -16) bitAnd: 255. - b2 := (value bitShift: -8) bitAnd: 255. - b3 := value bitAnd: 255. - aBool ifTrue:[ - self at: index put: b0. - self at: index+1 put: b1. - self at: index+2 put: b2. - self at: index+3 put: b3. - ] ifFalse:[ - self at: index put: b3. - self at: index+1 put: b2. - self at: index+2 put: b1. - self at: index+3 put: b0. - ]. ^value! Item was changed: ----- Method: ByteArray>>unsignedShortAt:bigEndian: (in category 'platform independent access') ----- + unsignedShortAt: index bigEndian: bigEndian + "Return a 16-bit unsigned integer quantity starting from the given byte index" + + bigEndian ifFalse: [ ^((self at: index + 1) bitShift: 8) + (self at: index) ]. + ^((self at: index) bitShift: 8) + (self at: index + 1) + ! - unsignedShortAt: index bigEndian: aBool - "Return a 16 bit unsigned integer quantity starting from the given byte index" - ^aBool - ifTrue:[((self at: index) bitShift: 8) + (self at: index+1)] - ifFalse:[((self at: index+1) bitShift: 8) + (self at: index)].! Item was changed: ----- Method: ByteArray>>unsignedShortAt:put:bigEndian: (in category 'platform independent access') ----- + unsignedShortAt: index put: value bigEndian: bigEndian + "Store a 16-bit unsigned integer quantity starting from the given byte index" + + bigEndian ifFalse: [ + self + at: index + 1 put: (value bitShift: -8); + at: index put: (value bitAnd: 16rFF). + ^value ]. + self + at: index put: (value bitShift: -8); + at: index+1 put: (value bitAnd: 16rFF). - unsignedShortAt: index put: value bigEndian: aBool - "Store a 16 bit unsigned integer quantity starting from the given byte index" - aBool ifTrue:[ - self at: index put: (value bitShift: -8). - self at: index+1 put: (value bitAnd: 255). - ] ifFalse:[ - self at: index+1 put: (value bitShift: -8). - self at: index put: (value bitAnd: 255). - ]. ^value! From commits at source.squeak.org Sun Sep 6 21:55:01 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sun Sep 6 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150906215501.13751.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008955.html Name: CollectionsTests-ul.249 Ancestors: CollectionsTests-eem.248 Added thorough tests for the integer accessors of ByteArray's platform independent access category. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008956.html Name: Collections-ul.654 Ancestors: Collections-eem.653 Optimized all integer accessor methods in ByteArray's platform independent access category. ============================================= From Marcel.Taeumel at hpi.de Mon Sep 7 11:19:38 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Sep 7 11:26:02 2015 Subject: [squeak-dev] Re: Grrrr, how come I can't deselect in a list browser?? In-Reply-To: References: <1441259953070-4847814.post@n4.nabble.com> <1441380609226-4848084.post@n4.nabble.com> Message-ID: <1441624778475-4848556.post@n4.nabble.com> Both QAbstractItemView::ExtendedSelection and QAbstractItemView::MultiSelection support toggling selection states of individual items. Having this, no selection is possible. Additionally, there is the concept of a current item (i.e. previously clicked). Best, Marcel -- View this message in context: http://forum.world.st/Grrrr-how-come-I-can-t-deselect-in-a-list-browser-tp4847776p4848556.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From Das.Linux at gmx.de Mon Sep 7 21:59:41 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon Sep 7 21:59:45 2015 Subject: [squeak-dev] Socket tests may choke Message-ID: <0FEBD3AC-493B-44FD-8319-A7F30EB81C3A@gmx.de> Hi all I'm just debugging strange things on a jenkins slave (thanks Tony!) and found that some socket tests choke because: - localhost there is 127.0.0.1 - BUT the local host name (squeak-debian32, but irrelevant) is 127.0.1.1 This is documented for debian systems[1]. Yet, in SocketTest, there's a testRemoteAddress, that uses a listenerSocket (that on that system will listen on 127.0.1.1) but once it accepts a client connection (from 127.0.1.1), the serverSocket (that gets initalized via the listenerSocket) reports 127.0.0.1 for its remote address, and hence the test fails. Similar for testLocalAddress, when connecting to 127.0.1.1, the clients local address reports 127.0.0.1. Is primitiveSocketLocalAddress broken? Best regards -Tobias [1]: https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution From commits at source.squeak.org Mon Sep 7 22:05:40 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Sep 7 22:05:42 2015 Subject: [squeak-dev] The Trunk: NetworkTests-topa.38.mcz Message-ID: Tobias Pape uploaded a new version of NetworkTests to project The Trunk: http://source.squeak.org/trunk/NetworkTests-topa.38.mcz ==================== Summary ==================== Name: NetworkTests-topa.38 Author: topa Time: 8 September 2015, 12:05:34.399 am UUID: b3158c4f-00ca-4175-960d-222c670439e6 Ancestors: NetworkTests-fbs.37 - Getting peer names can take some time. - Looking up 'localhost' directly is more reliable to return a consistent address upon connect-to than localHostName. =============== Diff against NetworkTests-fbs.37 =============== Item was changed: ----- Method: SocketTest>>listenerAddress (in category 'setup') ----- listenerAddress + ^NetNameResolver addressForName: 'localhost' - ^NetNameResolver localHostAddress ! Item was changed: ----- Method: SocketTest>>testPeerName (in category 'tests') ----- testPeerName "None of these should throw an exception." + "This can actually take a while, depending on networks availability" + + Socket new peerName. self testServerAccept. listenerSocket peerName. clientSocket peerName. serverSocket peerName.! From Das.Linux at gmx.de Mon Sep 7 22:13:19 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon Sep 7 22:13:23 2015 Subject: [squeak-dev] The Trunk: Tests-mt.328.mcz Message-ID: <2393F2A9-605A-497A-9B9C-94193D93257A@gmx.de> Hey, On 27.08.2015, at 08:54, commits@source.squeak.org wrote: > Marcel Taeumel uploaded a new version of Tests to project The Trunk: > http://source.squeak.org/trunk/Tests-mt.328.mcz > > ==================== Summary ==================== > > Name: Tests-mt.328 > Author: mt > Time: 27 August 2015, 10:54:02.079 am > UUID: 2b490fe8-250d-2e48-84c2-41d50b1ae410 > Ancestors: Tests-eem.327 > > New tests for preferences. [?] > > Item was added: > + ----- Method: PreferencesTest>>test08DNUFallback (in category 'tests') ----- > + test08DNUFallback > + > + sut setPreference: #foo toValue: 123. > + sut class removeSelectorSilently: #foo. > + > + self assert: (sut perform: #foo) = 123. > + self assert: (sut perform: #unknownSelector) isNil.! Why the last one? Is that necessary? First, absent primitives used to return `false`, not `nil`. This may or may not be good, but then again, some software out there sends messages to all classes in the system and expects unknown messages to error. Best regards -Tobias From commits at source.squeak.org Mon Sep 7 22:28:28 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Mon Sep 7 22:28:29 2015 Subject: [squeak-dev] The Trunk: Tests-topa.331.mcz Message-ID: Tobias Pape uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-topa.331.mcz ==================== Summary ==================== Name: Tests-topa.331 Author: topa Time: 8 September 2015, 12:28:17.044 am UUID: abea6634-58e9-4e11-86c7-ba5fba13edd0 Ancestors: Tests-topa.330 Since the annotation pane fixes, the Tests are no longer sure which TextMorph to query for the results. Help by reducing the number of TextMorphs by temporarily disable the annotation panes during testing. =============== Diff against Tests-topa.330 =============== Item was changed: MCTestCase subclass: #MCSnapshotBrowserTest + instanceVariableNames: 'model morph originalAnnotationPanePref' - instanceVariableNames: 'model morph' classVariableNames: '' poolDictionaries: '' category: 'Tests-Monticello'! Item was changed: ----- Method: MCSnapshotBrowserTest>>setUp (in category 'running') ----- setUp + "to not disturb the tests" + originalAnnotationPanePref := Preferences annotationPanes. + Preferences disable: #annotationPanes. model := MCSnapshotBrowser forSnapshot: MCSnapshotResource current snapshot. self buildWindow! Item was added: + ----- Method: MCSnapshotBrowserTest>>tearDown (in category 'running') ----- + tearDown + originalAnnotationPanePref ifTrue: [Preferences enable: #annotationPanes]. + super tearDown.! From Das.Linux at gmx.de Mon Sep 7 22:36:25 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon Sep 7 22:36:28 2015 Subject: [squeak-dev] ExceptionTests / Wrong error handler Message-ID: Hi all We have a failure (regression?) in ExceptionTests when running on SPUR: ExceptionTests>>testHandlerFromAction Receiver: ExceptionTests>>#testHandlerFromAction Arguments and temporary variables: result: 'inner' Receiver's instance variables: testSelector: #testHandlerFromAction timeout: nil The wrong error handler is triggered. VM problem or image problem? Best regards -Tobias From Marcel.Taeumel at hpi.de Tue Sep 8 05:08:51 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Tue Sep 8 05:15:20 2015 Subject: [squeak-dev] Re: ExceptionTests / Wrong error handler In-Reply-To: References: Message-ID: <1441688931009-4848715.post@n4.nabble.com> Is primitive 199 still a marker only? There seems to be no in-image handling of this behavior. Thus, I suspect the comment in BlockClosure >> #on:do: is wrong. Or is the more VM magic involved and the primitive 201 (BlockClosure >> #value) walks the stack and looks for "handlerActive == true"?! -- View this message in context: http://forum.world.st/ExceptionTests-Wrong-error-handler-tp4848699p4848715.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From leves at elte.hu Tue Sep 8 08:58:44 2015 From: leves at elte.hu (Levente Uzonyi) Date: Tue Sep 8 08:58:47 2015 Subject: [squeak-dev] ExceptionTests / Wrong error handler In-Reply-To: References: Message-ID: Hi Tobias, That test is a feature request. It has been around since 4.3 or so, and is waiting for a volunteer to implement the requested behavior. IIRC there have been attempts to do it, but no one took the time to review the proposed solutions. Levente On Tue, 8 Sep 2015, Tobias Pape wrote: > Hi all > > We have a failure (regression?) in ExceptionTests > when running on SPUR: > > ExceptionTests>>testHandlerFromAction > Receiver: ExceptionTests>>#testHandlerFromAction > Arguments and temporary variables: > result: 'inner' > Receiver's instance variables: > testSelector: #testHandlerFromAction > timeout: nil > > The wrong error handler is triggered. > VM problem or image problem? > > Best regards > -Tobias > > From leves at elte.hu Tue Sep 8 09:09:25 2015 From: leves at elte.hu (Levente Uzonyi) Date: Tue Sep 8 09:09:27 2015 Subject: [squeak-dev] Re: Regex In-Reply-To: <1441234315333-4847767.post@n4.nabble.com> References: <1441010369545-4847054.post@n4.nabble.com> <1441017802917-4847093.post@n4.nabble.com> <1441234315333-4847767.post@n4.nabble.com> Message-ID: Hi Frankie, I just saw that you tried loading the packages from the Inbox, which is not a repository for storing packages permanently, when the packages had already been moved to the Trunk. It's great that you found the solution. Levente On Wed, 2 Sep 2015, frankiec wrote: > OK, I avoided this problem by adding the http://source.squeak.org/trunk path > to the Monticello Browser. > > As a new Smalltalker, I wish these things were documented a little bit > better. ;) > > > > -- > View this message in context: http://forum.world.st/Regex-tp4842477p4847767.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > From leves at elte.hu Tue Sep 8 09:42:06 2015 From: leves at elte.hu (Levente Uzonyi) Date: Tue Sep 8 09:42:11 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: Hi All, A bit later than I wanted to, but I've finally uploaded my versions to the Trunk. I guess I went as far as possible with getting the "fastest implementation". I modified your benchmark to use the same numbers, so that the measurements could be repeated. I got the following: Before: {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per run.'. 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per run.'. 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per run.'. 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per run.'}. After: {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. As you can see, everything became faster except for smallN access. This is the side-effect of optimizing for the average case instead of specific cases - like zero bytes. I decided not to use that trick, because it decreased the overall performance. I also wrote a benchmark which measures reads and writes together. It generates random numbers which can be represented using a given number of bits. The result is an array of run times where values having and odd index belong to big-endian access, and even ones to little-endian. | byteArray inputs random storageBits unsigned | Smalltalk garbageCollect. random := Random seed: 36rSqueak. storageBits := 64. unsigned := true. byteArray := ByteArray new: storageBits // 8 * 2. inputs := Array new: 100000. (2 to: storageBits * 2 + 1) collect: [ :descriptor | "lowest bit describes endianness, the rest the number of bits." | limit bigEndian offset | bigEndian := descriptor odd. limit := 1 << (descriptor >> 1) - 1. unsigned ifTrue: [ offset := -1 ] ifFalse: [ offset := -1- (limit >> 1) ]. inputs replace: [ :each | (random nextInt: limit) + offset ]. [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ :startIndex | 1 to: inputs size do: [ :inputIndex | byteArray unsignedLong64At: startIndex put: (inputs at: inputIndex) bigEndian: bigEndian; unsignedLong64At: startIndex bigEndian: bigEndian ] ] ] timeToRun ]. I ran it with various accessors and got the following results: "short" #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 28 28 28 28 28 28 26 28 28 28) "average asFloat 27.625". #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 20 20 20 20 20 22 20 20 20 20) "average asFloat 19.5". "long" #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 70 72 72 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 72 76 70 76 72 76 70 76 72 76 72 74 72 76 72 74 72 76 570 584) "average asFloat 87.28125". #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 72 72 74 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 74 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 74 72 116 122) "average asFloat 73.625". "unsigned short" #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 20 20 20 20 18 20 18 18 18 18) "average asFloat 18.5". #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18) "average asFloat 18.125". "unsigned long" #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 52 54 52 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 60 58 56 56 60 62 60 62 62 62 60 62 60 62 62 62 384 400 520 694) "average asFloat 82.40625". #(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 62 64 64 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) "average asFloat 69.09375". "unsigned long 64" #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 312 306 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 316 314 318 316 316 318 316 318 316 316 316 318 318 316 316 326 324 326 322 326 322 328 324 326 322 326 322 510 520 592 592 634 618 636 640 652 666 642 644 660 648 642 660 652 646 662 658 636 648 626 632 650 628 632 612 632 620 622 636 626 626 644 632 750 748 812 822 828 858 842 862 898 880 896 840 870 896 926 870 1034 846 880 834 876 824 860 818 848 824 826 864 820 848 820 828) "average asFloat 536.109375". #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 166 170 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 170 166 172 166 172 164 174 166 170 168 172 166 172 166 172 166 170 164 170 166 172 164 172 166 172 166 170 238 272 264 484 282 344 284 356 292 362 294 364 288 362 292 366 294 368 290 364 294 374 294 374 296 370 294 374 288 370 290 366 290 368 292 364 302 382 304 388 302 390 298 392 298 384 302 388 302 390 298 386 308 398 304 400 504 402 298 402 298 398 302 398 294 400 298 396). "average asFloat 259.359375" Levente On Sun, 30 Aug 2015, Chris Muller wrote: > Hi Chris, I think these methods belong in the image with the fastest > implementation we can do. > > I implemented 64-bit unsigned access for Ma Serializer back in 2005. > I modeled my implementation after Andreas' original approach which > tries to avoid LI arithmetic. I was curious whether your > implementations would be faster, because if they are then it could > benefit Magma. After loading "Ma Serializer" 1.5 (or head) into a > trunk image, I used the following script to take comparison > measurements: > > | smallN largeN maBa cbBa | smallN := ((2 raisedTo: 13) to: (2 > raisedTo: 14)) atRandom. > largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. > maBa := ByteArray new: 8. > cbBa := ByteArray new: 8. > maBa maUint: 64 at: 0 put: largeN. > cbBa unsignedLong64At: 1 put: largeN bigEndian: false. > self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 > bigEndian: false). > { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN > bigEndian: false] bench. > 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. > 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false. ] bench. > 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. > 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN > bigEndian: false] bench. > 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. > 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false ] bench. > 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. > } > > Here are the results: > > 'cbc smallN write'->'3,110,000 per second. 322 nanoseconds per run.' . > 'ma smallN write'->'4,770,000 per second. 210 nanoseconds per run.' . > 'cbc smallN access'->'4,300,000 per second. 233 nanoseconds per run.' . > 'ma smallN access'->'16,400,000 per second. 60.9 nanoseconds per run.' . > 'cbc largeN write'->'907,000 per second. 1.1 microseconds per run.' . > 'ma largeN write'->'6,620,000 per second. 151 nanoseconds per run.' . > 'cbc largeN access'->'1,900,000 per second. 527 nanoseconds per run.' . > 'ma largeN access'->'1,020,000 per second. 982 nanoseconds per run.' > > It looks like your 64-bit access is 86% faster for accessing the > high-end of the 64-bit range, but slower in the other 3 metrics. > Noticeably, it was only 14% as fast for writing the high-end of the > 64-bit range, and similarly as much slower for small-number access.. > > > On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham > wrote: >> Hi. >> >> I've committed a change to the inbox with changes to allow getting/putting >> 64bit values to ByteArrays (similar to 32 and 16 bit accessors). Could this >> be added to trunk? >> >> Also, first time I used the selective commit function - very nice! the >> changes I didn't want committed didn't, in fact, get commited. Just the >> desirable bits! >> >> -cbc >> >> >> > > From Das.Linux at gmx.de Tue Sep 8 11:17:45 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Sep 8 11:17:49 2015 Subject: [squeak-dev] ExceptionTests / Wrong error handler In-Reply-To: References: Message-ID: <3E46FFE5-8FC2-420D-93E6-62C53866D17E@gmx.de> On 08.09.2015, at 10:58, Levente Uzonyi wrote: > Hi Tobias, > > That test is a feature request. It has been around since 4.3 or so, and is waiting for a volunteer to implement the requested behavior. IIRC there have been attempts to do it, but no one took the time to review the proposed solutions. > So this should be an expected failure then? Best regards -Tobias > Levente > > On Tue, 8 Sep 2015, Tobias Pape wrote: > >> Hi all >> >> We have a failure (regression?) in ExceptionTests >> when running on SPUR: >> >> ExceptionTests>>testHandlerFromAction >> Receiver: ExceptionTests>>#testHandlerFromAction >> Arguments and temporary variables: >> result: 'inner' >> Receiver's instance variables: >> testSelector: #testHandlerFromAction >> timeout: nil >> >> The wrong error handler is triggered. >> VM problem or image problem? >> >> Best regards >> -Tobias From eliot.miranda at gmail.com Tue Sep 8 12:35:49 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 8 12:35:52 2015 Subject: [squeak-dev] ExceptionTests / Wrong error handler In-Reply-To: References: Message-ID: Hi Tobias, On Mon, Sep 7, 2015 at 3:36 PM, Tobias Pape wrote: > Hi all > > We have a failure (regression?) in ExceptionTests > when running on SPUR: > Off topic, but I prefer Spur (as I prefer Cog). They're just names. No acronymics. > > ExceptionTests>>testHandlerFromAction > Receiver: ExceptionTests>>#testHandlerFromAction > Arguments and temporary variables: > result: 'inner' > Receiver's instance variables: > testSelector: #testHandlerFromAction > timeout: nil > > The wrong error handler is triggered. > VM problem or image problem? > > Best regards > -Tobias > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150908/62a43316/attachment.htm From Das.Linux at gmx.de Tue Sep 8 12:40:47 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue Sep 8 12:40:50 2015 Subject: [squeak-dev] ExceptionTests / Wrong error handler In-Reply-To: References: Message-ID: <9CB2FD77-8BB5-4570-84C5-9A029B71C8E9@gmx.de> On 08.09.2015, at 14:35, Eliot Miranda wrote: > Hi Tobias, > > On Mon, Sep 7, 2015 at 3:36 PM, Tobias Pape wrote: > Hi all > > We have a failure (regression?) in ExceptionTests > when running on SPUR: > > Off topic, but I prefer Spur (as I prefer Cog). They're just names. No acronymics. Oh sorry. I always get confused with the SPUR jit [1], not content-wise but spelling-wise. best regards -Tobias [1]: https://dl.acm.org/citation.cfm?id=1869517 From eliot.miranda at gmail.com Tue Sep 8 12:42:36 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 8 12:42:38 2015 Subject: [squeak-dev] ExceptionTests / Wrong error handler In-Reply-To: <9CB2FD77-8BB5-4570-84C5-9A029B71C8E9@gmx.de> References: <9CB2FD77-8BB5-4570-84C5-9A029B71C8E9@gmx.de> Message-ID: On Tue, Sep 8, 2015 at 5:40 AM, Tobias Pape wrote: > > On 08.09.2015, at 14:35, Eliot Miranda wrote: > > > Hi Tobias, > > > > On Mon, Sep 7, 2015 at 3:36 PM, Tobias Pape wrote: > > Hi all > > > > We have a failure (regression?) in ExceptionTests > > when running on SPUR: > > > > Off topic, but I prefer Spur (as I prefer Cog). They're just names. No > acronymics. > > Oh sorry. I always get confused with the SPUR jit [1], not content-wise > but spelling-wise. > No problem, but then that's an even better reason to use "Spur", to disambiguate :-). > best regards > -Tobias > > > [1]: https://dl.acm.org/citation.cfm?id=1869517 > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150908/5dbbdedc/attachment.htm From eliot.miranda at gmail.com Tue Sep 8 13:48:38 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 8 13:48:42 2015 Subject: [squeak-dev] Re: [Pharo-dev] chunk file format (unrecoverable changes) In-Reply-To: References: Message-ID: Hi Nicolai, On Mon, Sep 7, 2015 at 1:21 PM, Nicolai Hess wrote: > > > 2015-09-07 20:10 GMT+02:00 Eliot Miranda : > >> >> >> On Sun, Sep 6, 2015 at 12:56 PM, Nicolai Hess wrote: >> >>> Do we have a documentation about the format of >>> - class definitions >>> - methods >>> - class comments >>> for the changes file ? >>> >> >> >> Google "specification of smalltalk chunk format" and you will see: >> >> Overviews: Chunk File Format >> >> Smalltalk Interchange Format - Draft Smalltalk Standard v1.9 >> >> The Smalltalk fileOut format - 1 >> >> >> and more. >> > > > Thank you eliot > (should have google that myself !) > > >> >> >>> >>> I am asking because some entries are using two separator >>> "! !" >>> and some only one >>> "!" >>> >> >> Indeed. It's in the spec. ! ! ends a run of methods in the same >> protocol. ! ends a method or a doit, etc. Read the spec. >> > > ah! grouping multiple methods for one protocol. > Forgive me, I don't mean to complain, but... It's rather sad now I look at it that the specification misses a very cool thing about the format. Glenn Krasner invented it and he's no dummy. What the specs miss out is that the syntax for a protocol is actually a general escape mechanism. For example in !Object methodsFor: 'testing'! isUnderstood ^false! ! the fileIn parser evaluates Object methodsFor: 'testing' and then asks that object to scanFrom: the stream. And the above answers a ClassCategoryReader that reads chunks, compiling them and adding them to the relevant category, until it finds an empty chunk (hence ! ! is not special syntax, but actually a chunk followed by an empty chunk). So one /could/, if one wanted, add another kind of reader, for example !Preferences loadSavedPreferences! beCool true! beKnowledgeable true! rememberOnersHistorytLestOneWishesToRepeatIt true! ! and have this not file in, but store preferences. I think that's neat, and it's very sad that the ANSI standard did;t define this but reduced the mechanism to support only protocols, and thence cause people to wonder why the syntax was so weird, when in fact it was very simple and wonderfully extensible. Now I'm not blaming the standards process; the real problem here is that the scheme wasn't documented other than by its implementation and so the flexibility was never made apparent to the standardizers, and anyway they wanted an interchange format, which is not what Squeak and Pharo chunk readers provide; they provide an extensible format. The ANSI standard /could/ however have specified that the syntax is indeed extensible as described, but that conforming implementations are only expected to provide ClassCategoryReaders, and are expected to raise an error if given expressions they don't recognize, or some such. Also, given this history you can see why a single ! following a method definition isn't seen anymore; we've put the stamp information in the ClassCategoryreader so it can only parse a single method. If we'd done something like this (and I'm not suggesting that's a good idea) !Object methodsFor: 'testing'! [stamp: 'mad 01/04/2015 12:00'] isUnderstood ^#barely! [stamp: 'mad 01/04/2015 12:01'] isMisunderstood ^#almostCertainly! ! we'd still see the single !'s after methods. Two key points for me are - specify carefully and visibly - extensible standards are better than fixed standards And we have a problem with the "Recover lost changes" browser >>> (https://pharo.fogbugz.com/f/cases/16498/unrecoverable-changes) >>> and I am not sure if this is a bug on the code importer >>> or if it is a bug on how we write changes to the changes file. >>> >> _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150908/c016ee41/attachment.htm From cunningham.cb at gmail.com Tue Sep 8 15:21:56 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Tue Sep 8 15:21:59 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: Levente, Interesting. I have a question and a concern about your implementation, though: Question: why in the micro checks, is the Write faster than the Access: {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. yet in your more thorough benchmark, the Write twice as slow as the Access? "unsigned long 64" (put, or Write) "average asFloat 536.109375". (Access) "average asFloat 259.359375" any ideas? the concern is that your code is nicely optimized for our current 32bit vm - but once we go to 64 bit, I think it will fail. Should we be concerned? -cbc On Tue, Sep 8, 2015 at 2:42 AM, Levente Uzonyi wrote: > Hi All, > > A bit later than I wanted to, but I've finally uploaded my versions to the > Trunk. I guess I went as far as possible with getting the "fastest > implementation". > I modified your benchmark to use the same numbers, so that the > measurements could be repeated. I got the following: > > Before: > {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per run.'. > 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per run.'. > 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per run.'. > 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per run.'}. > > After: > {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. > 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. > 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. > 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. > > As you can see, everything became faster except for smallN access. This is > the side-effect of optimizing for the average case instead of specific > cases - like zero bytes. I decided not to use that trick, because it > decreased the overall performance. > > I also wrote a benchmark which measures reads and writes together. It > generates random numbers which can be represented using a given number of > bits. The result is an array of run times where values having and odd index > belong to big-endian access, and even ones to little-endian. > > | byteArray inputs random storageBits unsigned | > Smalltalk garbageCollect. > random := Random seed: 36rSqueak. > storageBits := 64. > unsigned := true. > byteArray := ByteArray new: storageBits // 8 * 2. > inputs := Array new: 100000. > (2 to: storageBits * 2 + 1) collect: [ :descriptor | > "lowest bit describes endianness, the rest the number of bits." > | limit bigEndian offset | > bigEndian := descriptor odd. > limit := 1 << (descriptor >> 1) - 1. > unsigned > ifTrue: [ offset := -1 ] > ifFalse: [ offset := -1- (limit >> 1) ]. > inputs replace: [ :each | (random nextInt: limit) + offset ]. > [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ :startIndex | > 1 to: inputs size do: [ :inputIndex | > byteArray > unsignedLong64At: startIndex > put: (inputs at: inputIndex) > bigEndian: bigEndian; > unsignedLong64At: startIndex > bigEndian: bigEndian ] ] ] > timeToRun ]. > > I ran it with various accessors and got the following results: > > "short" > #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 28 28 > 28 28 28 28 26 28 28 28) "average asFloat 27.625". > #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 20 20 > 20 20 20 22 20 20 20 20) "average asFloat 19.5". > > "long" > #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 70 72 > 72 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 72 76 70 76 72 > 76 70 76 72 76 72 74 72 76 72 74 72 76 570 584) "average asFloat 87.28125". > #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 72 72 > 74 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 74 72 72 72 72 > 72 72 72 72 72 72 72 72 72 72 72 74 72 116 122) "average asFloat 73.625". > > "unsigned short" > #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 20 20 > 20 20 18 20 18 18 18 18) "average asFloat 18.5". > #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 > 18 18 18 18 18 18 18 18) "average asFloat 18.125". > > "unsigned long" > #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 52 54 > 52 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 60 58 56 56 60 > 62 60 62 62 62 60 62 60 62 62 62 384 400 520 694) "average asFloat > 82.40625". > #(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 62 64 64 > 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) "average asFloat > 69.09375". > > "unsigned long 64" > #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 312 306 > 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 316 314 318 316 > 316 318 316 318 316 316 316 318 318 316 316 326 324 326 322 326 322 328 324 > 326 322 326 322 510 520 592 592 634 618 636 640 652 666 642 644 660 648 642 > 660 652 646 662 658 636 648 626 632 650 628 632 612 632 620 622 636 626 626 > 644 632 750 748 812 822 828 858 842 862 898 880 896 840 870 896 926 870 > 1034 846 880 834 876 824 860 818 848 824 826 864 820 848 820 828) "average > asFloat 536.109375". > #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 166 170 > 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 170 166 172 166 > 172 164 174 166 170 168 172 166 172 166 172 166 170 164 170 166 172 164 172 > 166 172 166 170 238 272 264 484 282 344 284 356 292 362 294 364 288 362 292 > 366 294 368 290 364 294 374 294 374 296 370 294 374 288 370 290 366 290 368 > 292 364 302 382 304 388 302 390 298 392 298 384 302 388 302 390 298 386 308 > 398 304 400 504 402 298 402 298 398 302 398 294 400 298 396). "average > asFloat 259.359375" > > > Levente > > > On Sun, 30 Aug 2015, Chris Muller wrote: > > Hi Chris, I think these methods belong in the image with the fastest >> implementation we can do. >> >> I implemented 64-bit unsigned access for Ma Serializer back in 2005. >> I modeled my implementation after Andreas' original approach which >> tries to avoid LI arithmetic. I was curious whether your >> implementations would be faster, because if they are then it could >> benefit Magma. After loading "Ma Serializer" 1.5 (or head) into a >> trunk image, I used the following script to take comparison >> measurements: >> >> | smallN largeN maBa cbBa | smallN := ((2 raisedTo: 13) to: (2 >> raisedTo: 14)) atRandom. >> largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. >> maBa := ByteArray new: 8. >> cbBa := ByteArray new: 8. >> maBa maUint: 64 at: 0 put: largeN. >> cbBa unsignedLong64At: 1 put: largeN bigEndian: false. >> self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 >> bigEndian: false). >> { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN >> bigEndian: false] bench. >> 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. >> 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false. ] >> bench. >> 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. >> 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN >> bigEndian: false] bench. >> 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. >> 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false ] >> bench. >> 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. >> } >> >> Here are the results: >> >> 'cbc smallN write'->'3,110,000 per second. 322 nanoseconds per run.' . >> 'ma smallN write'->'4,770,000 per second. 210 nanoseconds per run.' . >> 'cbc smallN access'->'4,300,000 per second. 233 nanoseconds per run.' . >> 'ma smallN access'->'16,400,000 per second. 60.9 nanoseconds per run.' . >> 'cbc largeN write'->'907,000 per second. 1.1 microseconds per run.' . >> 'ma largeN write'->'6,620,000 per second. 151 nanoseconds per run.' . >> 'cbc largeN access'->'1,900,000 per second. 527 nanoseconds per run.' . >> 'ma largeN access'->'1,020,000 per second. 982 nanoseconds per run.' >> >> It looks like your 64-bit access is 86% faster for accessing the >> high-end of the 64-bit range, but slower in the other 3 metrics. >> Noticeably, it was only 14% as fast for writing the high-end of the >> 64-bit range, and similarly as much slower for small-number access.. >> >> >> On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham >> wrote: >> >>> Hi. >>> >>> I've committed a change to the inbox with changes to allow >>> getting/putting >>> 64bit values to ByteArrays (similar to 32 and 16 bit accessors). Could >>> this >>> be added to trunk? >>> >>> Also, first time I used the selective commit function - very nice! the >>> changes I didn't want committed didn't, in fact, get commited. Just the >>> desirable bits! >>> >>> -cbc >>> >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150908/651f04b3/attachment.htm From leves at elte.hu Tue Sep 8 15:34:30 2015 From: leves at elte.hu (Levente Uzonyi) Date: Tue Sep 8 15:34:38 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: Hi Chris, I added the #normalize sends to avoid the creation of spurious LargeIntegers in 64-bit images (there are two places where I relied on #-'s ability to work on unnormalized input). I didn't have a chance to test it, but I expect it to work correctly. Even if the code is sub-optimal in 64-bit, it shouldn't be any slower than in 32-bit. Levente On Tue, 8 Sep 2015, Chris Cunningham wrote: > Levente, > Interesting.? I have a question and a concern about your implementation, though: > > Question: why in the micro checks, is the Write faster than the Access: > {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. > 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. > 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. > 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. > yet in your more thorough benchmark, the Write twice as slow as the Access? > "unsigned long 64" > (put, or Write) "average asFloat 536.109375". > (Access) "average asFloat 259.359375" > any ideas? > > the concern is that your code is nicely optimized for our current 32bit vm - but once we go to 64 bit, I think it will fail.? Should we be > concerned? > > -cbc > > On Tue, Sep 8, 2015 at 2:42 AM, Levente Uzonyi wrote: > Hi All, > > A bit later than I wanted to, but I've finally uploaded my versions to the Trunk. I guess I went as far as possible with getting the > "fastest implementation". > I modified your benchmark to use the same numbers, so that the measurements could be repeated. I got the following: > > Before: > {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per run.'. > 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per run.'. > 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per run.'. > 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per run.'}. > > After: > {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. > 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. > 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. > 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. > > As you can see, everything became faster except for smallN access. This is the side-effect of optimizing for the average case instead > of specific cases - like zero bytes. I decided not to use that trick, because it decreased the overall performance. > > I also wrote a benchmark which measures reads and writes together. It generates random numbers which can be represented using a given > number of bits. The result is an array of run times where values having and odd index belong to big-endian access, and even ones to > little-endian. > > | byteArray inputs random storageBits unsigned | > Smalltalk garbageCollect. > random := Random seed: 36rSqueak. > storageBits := 64. > unsigned := true. > byteArray := ByteArray new: storageBits // 8 * 2. > inputs := Array new: 100000. > (2 to: storageBits * 2 + 1) collect: [ :descriptor | > ? ? ? ? "lowest bit describes endianness, the rest the number of bits." > ? ? ? ? | limit bigEndian offset | > ? ? ? ? bigEndian := descriptor odd. > ? ? ? ? limit := 1 << (descriptor >> 1) - 1. > ? ? ? ? unsigned > ? ? ? ? ? ? ? ? ifTrue: [ offset := -1 ] > ? ? ? ? ? ? ? ? ifFalse: [ offset := -1- (limit >> 1) ]. > ? ? ? ? inputs replace: [ :each | (random nextInt: limit) + offset ]. > ? ? ? ? [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ :startIndex | > ? ? ? ? ? ? ? ? 1 to: inputs size do: [ :inputIndex | > ? ? ? ? ? ? ? ? ? ? ? ? byteArray > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsignedLong64At: startIndex > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? put: (inputs at: inputIndex) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigEndian: bigEndian; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsignedLong64At: startIndex > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigEndian: bigEndian ] ] ] timeToRun ]. > > I ran it with various accessors and got the following results: > > "short" > #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 28 28 28 28 28 28 26 28 28 28) "average asFloat 27.625". > #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 20 20 20 20 20 22 20 20 20 20) "average asFloat 19.5". > > "long" > #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 70 72 72 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 > 72 76 70 76 72 76 70 76 72 76 72 74 72 76 72 74 72 76 570 584) "average asFloat 87.28125". > #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 72 72 74 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 > 74 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 74 72 116 122) "average asFloat 73.625". > > "unsigned short" > #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 20 20 20 20 18 20 18 18 18 18) "average asFloat 18.5". > #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18) "average asFloat 18.125". > > "unsigned long" > #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 52 54 52 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 > 60 58 56 56 60 62 60 62 62 62 60 62 60 62 62 62 384 400 520 694) "average asFloat 82.40625". > ?#(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 62 64 64 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 > 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) "average asFloat 69.09375". > > "unsigned long 64" > #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 312 306 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 > 316 314 318 316 316 318 316 318 316 316 316 318 318 316 316 326 324 326 322 326 322 328 324 326 322 326 322 510 520 592 592 634 618 > 636 640 652 666 642 644 660 648 642 660 652 646 662 658 636 648 626 632 650 628 632 612 632 620 622 636 626 626 644 632 750 748 812 > 822 828 858 842 862 898 880 896 840 870 896 926 870 1034 846 880 834 876 824 860 818 848 824 826 864 820 848 820 828) "average asFloat > 536.109375". > #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 166 170 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 > 170 166 172 166 172 164 174 166 170 168 172 166 172 166 172 166 170 164 170 166 172 164 172 166 172 166 170 238 272 264 484 282 344 > 284 356 292 362 294 364 288 362 292 366 294 368 290 364 294 374 294 374 296 370 294 374 288 370 290 366 290 368 292 364 302 382 304 > 388 302 390 298 392 298 384 302 388 302 390 298 386 308 398 304 400 504 402 298 402 298 398 302 398 294 400 298 396). "average asFloat > 259.359375" > > > Levente > > On Sun, 30 Aug 2015, Chris Muller wrote: > > Hi Chris, I think these methods belong in the image with the fastest > implementation we can do. > > I implemented 64-bit unsigned access for Ma Serializer back in 2005. > I modeled my implementation after Andreas' original approach which > tries to avoid LI arithmetic.? I was curious whether your > implementations would be faster, because if they are then it could > benefit Magma.? After loading "Ma Serializer" 1.5 (or head) into a > trunk image, I used the following script to take comparison > measurements: > > | smallN largeN maBa cbBa |? smallN := ((2 raisedTo: 13) to: (2 > raisedTo: 14)) atRandom. > largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. > maBa := ByteArray new: 8. > cbBa := ByteArray new: 8. > maBa maUint: 64 at: 0 put: largeN. > cbBa unsignedLong64At: 1 put: largeN bigEndian: false. > self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 > bigEndian: false). > { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN > bigEndian: false] bench. > 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. > 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false. ] bench. > 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. > 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN > bigEndian: false] bench. > 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. > 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false ] bench. > 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. > } > > Here are the results: > > 'cbc smallN write'->'3,110,000 per second.? 322 nanoseconds per run.' . > 'ma smallN write'->'4,770,000 per second.? 210 nanoseconds per run.' . > 'cbc smallN access'->'4,300,000 per second.? 233 nanoseconds per run.' . > 'ma smallN access'->'16,400,000 per second.? 60.9 nanoseconds per run.' . > 'cbc largeN write'->'907,000 per second.? 1.1 microseconds per run.' . > 'ma largeN write'->'6,620,000 per second.? 151 nanoseconds per run.' . > 'cbc largeN access'->'1,900,000 per second.? 527 nanoseconds per run.' . > 'ma largeN access'->'1,020,000 per second.? 982 nanoseconds per run.' > > It looks like your 64-bit access is 86% faster for accessing the > high-end of the 64-bit range, but slower in the other 3 metrics. > Noticeably, it was only 14% as fast for writing the high-end of the > 64-bit range, and similarly as much slower for small-number access.. > > > On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham > wrote: > Hi. > > I've committed a change to the inbox with changes to allow getting/putting > 64bit values to ByteArrays (similar to 32 and 16 bit accessors).? Could this > be added to trunk? > > Also, first time I used the selective commit function - very nice!? the > changes I didn't want committed didn't, in fact, get commited.? Just the > desirable bits! > > -cbc > > > > > > > > > From leves at elte.hu Tue Sep 8 16:25:54 2015 From: leves at elte.hu (Levente Uzonyi) Date: Tue Sep 8 16:25:58 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: I forgot to answer your other questions. On Tue, 8 Sep 2015, Chris Cunningham wrote: > Levente, > Interesting.? I have a question and a concern about your implementation, though: > > Question: why in the micro checks, is the Write faster than the Access: Because Access means allocation of new objects (LargeIntegers), while Write simply means copying bytes. > {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. > 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. > 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. > 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. > yet in your more thorough benchmark, the Write twice as slow as the Access? For each pair of lines the first one was measured _before_ my changes, the second one was measured _after_ them. The benchmark measures read and write together, so 536.109375 stands for the average number of milliseconds to read and write ninemillion numbers using your variant of the 64-bit methods on my machine. > "unsigned long 64" > (put, or Write) "average asFloat 536.109375". > (Access) "average asFloat 259.359375" > any ideas? So this is (read and write Before) "average asFloat 536.109375" (read and write After) "average asFloat 259.359375" Levente > > the concern is that your code is nicely optimized for our current 32bit vm - but once we go to 64 bit, I think it will fail.? Should we be > concerned? > > -cbc > > On Tue, Sep 8, 2015 at 2:42 AM, Levente Uzonyi wrote: > Hi All, > > A bit later than I wanted to, but I've finally uploaded my versions to the Trunk. I guess I went as far as possible with getting the > "fastest implementation". > I modified your benchmark to use the same numbers, so that the measurements could be repeated. I got the following: > > Before: > {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per run.'. > 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per run.'. > 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per run.'. > 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per run.'}. > > After: > {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. > 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. > 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. > 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. > > As you can see, everything became faster except for smallN access. This is the side-effect of optimizing for the average case instead > of specific cases - like zero bytes. I decided not to use that trick, because it decreased the overall performance. > > I also wrote a benchmark which measures reads and writes together. It generates random numbers which can be represented using a given > number of bits. The result is an array of run times where values having and odd index belong to big-endian access, and even ones to > little-endian. > > | byteArray inputs random storageBits unsigned | > Smalltalk garbageCollect. > random := Random seed: 36rSqueak. > storageBits := 64. > unsigned := true. > byteArray := ByteArray new: storageBits // 8 * 2. > inputs := Array new: 100000. > (2 to: storageBits * 2 + 1) collect: [ :descriptor | > ? ? ? ? "lowest bit describes endianness, the rest the number of bits." > ? ? ? ? | limit bigEndian offset | > ? ? ? ? bigEndian := descriptor odd. > ? ? ? ? limit := 1 << (descriptor >> 1) - 1. > ? ? ? ? unsigned > ? ? ? ? ? ? ? ? ifTrue: [ offset := -1 ] > ? ? ? ? ? ? ? ? ifFalse: [ offset := -1- (limit >> 1) ]. > ? ? ? ? inputs replace: [ :each | (random nextInt: limit) + offset ]. > ? ? ? ? [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ :startIndex | > ? ? ? ? ? ? ? ? 1 to: inputs size do: [ :inputIndex | > ? ? ? ? ? ? ? ? ? ? ? ? byteArray > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsignedLong64At: startIndex > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? put: (inputs at: inputIndex) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigEndian: bigEndian; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsignedLong64At: startIndex > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigEndian: bigEndian ] ] ] timeToRun ]. > > I ran it with various accessors and got the following results: > > "short" > #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 28 28 28 28 28 28 26 28 28 28) "average asFloat 27.625". > #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 20 20 20 20 20 22 20 20 20 20) "average asFloat 19.5". > > "long" > #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 70 72 72 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 > 72 76 70 76 72 76 70 76 72 76 72 74 72 76 72 74 72 76 570 584) "average asFloat 87.28125". > #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 72 72 74 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 > 74 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 74 72 116 122) "average asFloat 73.625". > > "unsigned short" > #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 20 20 20 20 18 20 18 18 18 18) "average asFloat 18.5". > #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18) "average asFloat 18.125". > > "unsigned long" > #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 52 54 52 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 > 60 58 56 56 60 62 60 62 62 62 60 62 60 62 62 62 384 400 520 694) "average asFloat 82.40625". > ?#(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 62 64 64 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 > 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) "average asFloat 69.09375". > > "unsigned long 64" > #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 312 306 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 > 316 314 318 316 316 318 316 318 316 316 316 318 318 316 316 326 324 326 322 326 322 328 324 326 322 326 322 510 520 592 592 634 618 > 636 640 652 666 642 644 660 648 642 660 652 646 662 658 636 648 626 632 650 628 632 612 632 620 622 636 626 626 644 632 750 748 812 > 822 828 858 842 862 898 880 896 840 870 896 926 870 1034 846 880 834 876 824 860 818 848 824 826 864 820 848 820 828) "average asFloat > 536.109375". > #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 166 170 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 > 170 166 172 166 172 164 174 166 170 168 172 166 172 166 172 166 170 164 170 166 172 164 172 166 172 166 170 238 272 264 484 282 344 > 284 356 292 362 294 364 288 362 292 366 294 368 290 364 294 374 294 374 296 370 294 374 288 370 290 366 290 368 292 364 302 382 304 > 388 302 390 298 392 298 384 302 388 302 390 298 386 308 398 304 400 504 402 298 402 298 398 302 398 294 400 298 396). "average asFloat > 259.359375" > > > Levente > > On Sun, 30 Aug 2015, Chris Muller wrote: > > Hi Chris, I think these methods belong in the image with the fastest > implementation we can do. > > I implemented 64-bit unsigned access for Ma Serializer back in 2005. > I modeled my implementation after Andreas' original approach which > tries to avoid LI arithmetic.? I was curious whether your > implementations would be faster, because if they are then it could > benefit Magma.? After loading "Ma Serializer" 1.5 (or head) into a > trunk image, I used the following script to take comparison > measurements: > > | smallN largeN maBa cbBa |? smallN := ((2 raisedTo: 13) to: (2 > raisedTo: 14)) atRandom. > largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. > maBa := ByteArray new: 8. > cbBa := ByteArray new: 8. > maBa maUint: 64 at: 0 put: largeN. > cbBa unsignedLong64At: 1 put: largeN bigEndian: false. > self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 > bigEndian: false). > { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN > bigEndian: false] bench. > 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. > 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false. ] bench. > 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. > 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN > bigEndian: false] bench. > 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. > 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false ] bench. > 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. > } > > Here are the results: > > 'cbc smallN write'->'3,110,000 per second.? 322 nanoseconds per run.' . > 'ma smallN write'->'4,770,000 per second.? 210 nanoseconds per run.' . > 'cbc smallN access'->'4,300,000 per second.? 233 nanoseconds per run.' . > 'ma smallN access'->'16,400,000 per second.? 60.9 nanoseconds per run.' . > 'cbc largeN write'->'907,000 per second.? 1.1 microseconds per run.' . > 'ma largeN write'->'6,620,000 per second.? 151 nanoseconds per run.' . > 'cbc largeN access'->'1,900,000 per second.? 527 nanoseconds per run.' . > 'ma largeN access'->'1,020,000 per second.? 982 nanoseconds per run.' > > It looks like your 64-bit access is 86% faster for accessing the > high-end of the 64-bit range, but slower in the other 3 metrics. > Noticeably, it was only 14% as fast for writing the high-end of the > 64-bit range, and similarly as much slower for small-number access.. > > > On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham > wrote: > Hi. > > I've committed a change to the inbox with changes to allow getting/putting > 64bit values to ByteArrays (similar to 32 and 16 bit accessors).? Could this > be added to trunk? > > Also, first time I used the selective commit function - very nice!? the > changes I didn't want committed didn't, in fact, get commited.? Just the > desirable bits! > > -cbc > > > > > > > > > From asqueaker at gmail.com Tue Sep 8 19:30:13 2015 From: asqueaker at gmail.com (Chris Muller) Date: Tue Sep 8 19:30:15 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: (Ha! What an amazing thread!) Levente, why am I not surprised that you could manage to squeeze yet even more efficiency out of it. If there were an eXtreme sports for programming, you'd win the gold medal... :) I've got to try this on the MagmaBenchmarker right now, I'll let you know in a bit.. On Tue, Sep 8, 2015 at 4:42 AM, Levente Uzonyi wrote: > Hi All, > > A bit later than I wanted to, but I've finally uploaded my versions to the > Trunk. I guess I went as far as possible with getting the "fastest > implementation". > I modified your benchmark to use the same numbers, so that the measurements > could be repeated. I got the following: > > Before: > {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per run.'. > 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per run.'. > 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per run.'. > 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per run.'}. > > After: > {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. > 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. > 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. > 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. > > As you can see, everything became faster except for smallN access. This is > the side-effect of optimizing for the average case instead of specific cases > - like zero bytes. I decided not to use that trick, because it decreased the > overall performance. > > I also wrote a benchmark which measures reads and writes together. It > generates random numbers which can be represented using a given number of > bits. The result is an array of run times where values having and odd index > belong to big-endian access, and even ones to little-endian. > > | byteArray inputs random storageBits unsigned | > Smalltalk garbageCollect. > random := Random seed: 36rSqueak. > storageBits := 64. > unsigned := true. > byteArray := ByteArray new: storageBits // 8 * 2. > inputs := Array new: 100000. > (2 to: storageBits * 2 + 1) collect: [ :descriptor | > "lowest bit describes endianness, the rest the number of bits." > | limit bigEndian offset | > bigEndian := descriptor odd. > limit := 1 << (descriptor >> 1) - 1. > unsigned > ifTrue: [ offset := -1 ] > ifFalse: [ offset := -1- (limit >> 1) ]. > inputs replace: [ :each | (random nextInt: limit) + offset ]. > [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ :startIndex | > 1 to: inputs size do: [ :inputIndex | > byteArray > unsignedLong64At: startIndex > put: (inputs at: inputIndex) > bigEndian: bigEndian; > unsignedLong64At: startIndex > bigEndian: bigEndian ] ] ] timeToRun > ]. > > I ran it with various accessors and got the following results: > > "short" > #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 28 28 28 > 28 28 28 26 28 28 28) "average asFloat 27.625". > #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 20 20 20 > 20 20 22 20 20 20 20) "average asFloat 19.5". > > "long" > #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 70 72 72 > 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 72 76 70 76 72 76 > 70 76 72 76 72 74 72 76 72 74 72 76 570 584) "average asFloat 87.28125". > #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 72 72 74 > 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 74 72 72 72 72 72 > 72 72 72 72 72 72 72 72 72 72 74 72 116 122) "average asFloat 73.625". > > "unsigned short" > #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 20 20 20 > 20 18 20 18 18 18 18) "average asFloat 18.5". > #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 > 18 18 18 18 18 18 18) "average asFloat 18.125". > > "unsigned long" > #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 52 54 52 > 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 60 58 56 56 60 62 > 60 62 62 62 60 62 60 62 62 62 384 400 520 694) "average asFloat 82.40625". > #(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 62 64 64 > 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 64 64 64 64 64 > 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) "average asFloat > 69.09375". > > "unsigned long 64" > #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 312 306 > 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 316 314 318 316 > 316 318 316 318 316 316 316 318 318 316 316 326 324 326 322 326 322 328 324 > 326 322 326 322 510 520 592 592 634 618 636 640 652 666 642 644 660 648 642 > 660 652 646 662 658 636 648 626 632 650 628 632 612 632 620 622 636 626 626 > 644 632 750 748 812 822 828 858 842 862 898 880 896 840 870 896 926 870 1034 > 846 880 834 876 824 860 818 848 824 826 864 820 848 820 828) "average > asFloat 536.109375". > #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 166 170 > 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 170 166 172 166 > 172 164 174 166 170 168 172 166 172 166 172 166 170 164 170 166 172 164 172 > 166 172 166 170 238 272 264 484 282 344 284 356 292 362 294 364 288 362 292 > 366 294 368 290 364 294 374 294 374 296 370 294 374 288 370 290 366 290 368 > 292 364 302 382 304 388 302 390 298 392 298 384 302 388 302 390 298 386 308 > 398 304 400 504 402 298 402 298 398 302 398 294 400 298 396). "average > asFloat 259.359375" > > > Levente > > > On Sun, 30 Aug 2015, Chris Muller wrote: > >> Hi Chris, I think these methods belong in the image with the fastest >> implementation we can do. >> >> I implemented 64-bit unsigned access for Ma Serializer back in 2005. >> I modeled my implementation after Andreas' original approach which >> tries to avoid LI arithmetic. I was curious whether your >> implementations would be faster, because if they are then it could >> benefit Magma. After loading "Ma Serializer" 1.5 (or head) into a >> trunk image, I used the following script to take comparison >> measurements: >> >> | smallN largeN maBa cbBa | smallN := ((2 raisedTo: 13) to: (2 >> raisedTo: 14)) atRandom. >> largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. >> maBa := ByteArray new: 8. >> cbBa := ByteArray new: 8. >> maBa maUint: 64 at: 0 put: largeN. >> cbBa unsignedLong64At: 1 put: largeN bigEndian: false. >> self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 >> bigEndian: false). >> { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN >> bigEndian: false] bench. >> 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. >> 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false. ] >> bench. >> 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. >> 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN >> bigEndian: false] bench. >> 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. >> 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false ] >> bench. >> 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. >> } >> >> Here are the results: >> >> 'cbc smallN write'->'3,110,000 per second. 322 nanoseconds per run.' . >> 'ma smallN write'->'4,770,000 per second. 210 nanoseconds per run.' . >> 'cbc smallN access'->'4,300,000 per second. 233 nanoseconds per run.' . >> 'ma smallN access'->'16,400,000 per second. 60.9 nanoseconds per run.' . >> 'cbc largeN write'->'907,000 per second. 1.1 microseconds per run.' . >> 'ma largeN write'->'6,620,000 per second. 151 nanoseconds per run.' . >> 'cbc largeN access'->'1,900,000 per second. 527 nanoseconds per run.' . >> 'ma largeN access'->'1,020,000 per second. 982 nanoseconds per run.' >> >> It looks like your 64-bit access is 86% faster for accessing the >> high-end of the 64-bit range, but slower in the other 3 metrics. >> Noticeably, it was only 14% as fast for writing the high-end of the >> 64-bit range, and similarly as much slower for small-number access.. >> >> >> On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham >> wrote: >>> >>> Hi. >>> >>> I've committed a change to the inbox with changes to allow >>> getting/putting >>> 64bit values to ByteArrays (similar to 32 and 16 bit accessors). Could >>> this >>> be added to trunk? >>> >>> Also, first time I used the selective commit function - very nice! the >>> changes I didn't want committed didn't, in fact, get commited. Just the >>> desirable bits! >>> >>> -cbc >>> >>> >>> >> >> > From commits at source.squeak.org Tue Sep 8 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 8 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150908215502.14137.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008957.html Name: NetworkTests-topa.38 Ancestors: NetworkTests-fbs.37 - Getting peer names can take some time. - Looking up 'localhost' directly is more reliable to return a consistent address upon connect-to than localHostName. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008958.html Name: Tests-topa.331 Ancestors: Tests-topa.330 Since the annotation pane fixes, the Tests are no longer sure which TextMorph to query for the results. Help by reducing the number of TextMorphs by temporarily disable the annotation panes during testing. ============================================= From cunningham.cb at gmail.com Tue Sep 8 22:11:33 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Tue Sep 8 22:11:35 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: Ok, it makes sense now. Well, it made sense before, I was just slow to see it. -cbc On Tue, Sep 8, 2015 at 9:25 AM, Levente Uzonyi wrote: > I forgot to answer your other questions. > > On Tue, 8 Sep 2015, Chris Cunningham wrote: > > Levente, >> Interesting. I have a question and a concern about your implementation, >> though: >> >> Question: why in the micro checks, is the Write faster than the Access: >> > > Because Access means allocation of new objects (LargeIntegers), while > Write simply means copying bytes. > > {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. >> 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. >> 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. >> 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. >> yet in your more thorough benchmark, the Write twice as slow as the >> Access? >> > > For each pair of lines the first one was measured _before_ my changes, the > second one was measured _after_ them. The benchmark measures read and write > together, so 536.109375 stands for the average number of milliseconds to > read and write ninemillion numbers using your variant of the 64-bit methods > on my machine. > > "unsigned long 64" >> (put, or Write) "average asFloat 536.109375". >> (Access) "average asFloat 259.359375" >> any ideas? >> > > So this is > > (read and write Before) "average asFloat 536.109375" > (read and write After) "average asFloat 259.359375" > > > Levente > > > >> the concern is that your code is nicely optimized for our current 32bit >> vm - but once we go to 64 bit, I think it will fail. Should we be >> concerned? >> >> -cbc >> >> On Tue, Sep 8, 2015 at 2:42 AM, Levente Uzonyi wrote: >> Hi All, >> >> A bit later than I wanted to, but I've finally uploaded my versions >> to the Trunk. I guess I went as far as possible with getting the >> "fastest implementation". >> I modified your benchmark to use the same numbers, so that the >> measurements could be repeated. I got the following: >> >> Before: >> {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per >> run.'. >> 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per >> run.'. >> 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per >> run.'. >> 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per >> run.'}. >> >> After: >> {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per >> run.'. >> 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per >> run.'. >> 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per >> run.'. >> 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per >> run.'}. >> >> As you can see, everything became faster except for smallN access. >> This is the side-effect of optimizing for the average case instead >> of specific cases - like zero bytes. I decided not to use that >> trick, because it decreased the overall performance. >> >> I also wrote a benchmark which measures reads and writes together. >> It generates random numbers which can be represented using a given >> number of bits. The result is an array of run times where values >> having and odd index belong to big-endian access, and even ones to >> little-endian. >> >> | byteArray inputs random storageBits unsigned | >> Smalltalk garbageCollect. >> random := Random seed: 36rSqueak. >> storageBits := 64. >> unsigned := true. >> byteArray := ByteArray new: storageBits // 8 * 2. >> inputs := Array new: 100000. >> (2 to: storageBits * 2 + 1) collect: [ :descriptor | >> "lowest bit describes endianness, the rest the number of >> bits." >> | limit bigEndian offset | >> bigEndian := descriptor odd. >> limit := 1 << (descriptor >> 1) - 1. >> unsigned >> ifTrue: [ offset := -1 ] >> ifFalse: [ offset := -1- (limit >> 1) ]. >> inputs replace: [ :each | (random nextInt: limit) + offset >> ]. >> [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ >> :startIndex | >> 1 to: inputs size do: [ :inputIndex | >> byteArray >> unsignedLong64At: startIndex >> put: (inputs at: inputIndex) >> bigEndian: bigEndian; >> unsignedLong64At: startIndex >> bigEndian: bigEndian ] ] ] >> timeToRun ]. >> >> I ran it with various accessors and got the following results: >> >> "short" >> #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 >> 28 28 28 28 28 28 26 28 28 28) "average asFloat 27.625". >> #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 >> 20 20 20 20 20 22 20 20 20 20) "average asFloat 19.5". >> >> "long" >> #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 >> 70 72 72 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 >> 72 76 70 76 72 76 70 76 72 76 72 74 72 76 72 74 72 76 570 584) >> "average asFloat 87.28125". >> #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 >> 72 72 74 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 >> 74 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 74 72 116 122) >> "average asFloat 73.625". >> >> "unsigned short" >> #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 >> 20 20 20 20 18 20 18 18 18 18) "average asFloat 18.5". >> #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 >> 18 18 18 18 18 18 18 18 18 18) "average asFloat 18.125". >> >> "unsigned long" >> #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 >> 52 54 52 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 >> 60 58 56 56 60 62 60 62 62 62 60 62 60 62 62 62 384 400 520 694) >> "average asFloat 82.40625". >> #(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 >> 62 64 64 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 >> 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) >> "average asFloat 69.09375". >> >> "unsigned long 64" >> #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 >> 312 306 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 >> 316 314 318 316 316 318 316 318 316 316 316 318 318 316 316 326 324 >> 326 322 326 322 328 324 326 322 326 322 510 520 592 592 634 618 >> 636 640 652 666 642 644 660 648 642 660 652 646 662 658 636 648 626 >> 632 650 628 632 612 632 620 622 636 626 626 644 632 750 748 812 >> 822 828 858 842 862 898 880 896 840 870 896 926 870 1034 846 880 >> 834 876 824 860 818 848 824 826 864 820 848 820 828) "average asFloat >> 536.109375". >> #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 >> 166 170 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 >> 170 166 172 166 172 164 174 166 170 168 172 166 172 166 172 166 170 >> 164 170 166 172 164 172 166 172 166 170 238 272 264 484 282 344 >> 284 356 292 362 294 364 288 362 292 366 294 368 290 364 294 374 294 >> 374 296 370 294 374 288 370 290 366 290 368 292 364 302 382 304 >> 388 302 390 298 392 298 384 302 388 302 390 298 386 308 398 304 400 >> 504 402 298 402 298 398 302 398 294 400 298 396). "average asFloat >> 259.359375" >> >> >> Levente >> >> On Sun, 30 Aug 2015, Chris Muller wrote: >> >> Hi Chris, I think these methods belong in the image with the >> fastest >> implementation we can do. >> >> I implemented 64-bit unsigned access for Ma Serializer back >> in 2005. >> I modeled my implementation after Andreas' original approach >> which >> tries to avoid LI arithmetic. I was curious whether your >> implementations would be faster, because if they are then it >> could >> benefit Magma. After loading "Ma Serializer" 1.5 (or head) >> into a >> trunk image, I used the following script to take comparison >> measurements: >> >> | smallN largeN maBa cbBa | smallN := ((2 raisedTo: 13) to: >> (2 >> raisedTo: 14)) atRandom. >> largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. >> maBa := ByteArray new: 8. >> cbBa := ByteArray new: 8. >> maBa maUint: 64 at: 0 put: largeN. >> cbBa unsignedLong64At: 1 put: largeN bigEndian: false. >> self assert: (cbBa maUnsigned64At: 1) = (maBa >> unsignedLong64At: 1 >> bigEndian: false). >> { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN >> bigEndian: false] bench. >> 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] >> bench. >> 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: >> false. ] bench. >> 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. >> 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN >> bigEndian: false] bench. >> 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] >> bench. >> 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: >> false ] bench. >> 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. >> } >> >> Here are the results: >> >> 'cbc smallN write'->'3,110,000 per second. 322 nanoseconds >> per run.' . >> 'ma smallN write'->'4,770,000 per second. 210 nanoseconds >> per run.' . >> 'cbc smallN access'->'4,300,000 per second. 233 nanoseconds >> per run.' . >> 'ma smallN access'->'16,400,000 per second. 60.9 nanoseconds >> per run.' . >> 'cbc largeN write'->'907,000 per second. 1.1 microseconds >> per run.' . >> 'ma largeN write'->'6,620,000 per second. 151 nanoseconds >> per run.' . >> 'cbc largeN access'->'1,900,000 per second. 527 nanoseconds >> per run.' . >> 'ma largeN access'->'1,020,000 per second. 982 nanoseconds >> per run.' >> >> It looks like your 64-bit access is 86% faster for accessing >> the >> high-end of the 64-bit range, but slower in the other 3 >> metrics. >> Noticeably, it was only 14% as fast for writing the high-end >> of the >> 64-bit range, and similarly as much slower for small-number >> access.. >> >> >> On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham >> wrote: >> Hi. >> >> I've committed a change to the inbox with changes to >> allow getting/putting >> 64bit values to ByteArrays (similar to 32 and 16 bit >> accessors). Could this >> be added to trunk? >> >> Also, first time I used the selective commit function - >> very nice! the >> changes I didn't want committed didn't, in fact, get >> commited. Just the >> desirable bits! >> >> -cbc >> >> >> >> >> >> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150908/7ed0d1a1/attachment.htm From lewis at mail.msen.com Wed Sep 9 00:46:15 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Wed Sep 9 00:46:16 2015 Subject: [squeak-dev] Socket tests may choke In-Reply-To: <0FEBD3AC-493B-44FD-8319-A7F30EB81C3A@gmx.de> References: <0FEBD3AC-493B-44FD-8319-A7F30EB81C3A@gmx.de> Message-ID: <20150909004615.GA95026@shell.msen.com> On Mon, Sep 07, 2015 at 11:59:41PM +0200, Tobias Pape wrote: > Hi all > > I'm just debugging strange things on a jenkins slave > (thanks Tony!) and found that some socket tests choke > because: > - localhost there is 127.0.0.1 > - BUT the local host name (squeak-debian32, but irrelevant) is 127.0.1.1 > This is documented for debian systems[1]. > > Yet, in SocketTest, there's a testRemoteAddress, that uses a > listenerSocket (that on that system will listen on 127.0.1.1) but once it > accepts a client connection (from 127.0.1.1), the serverSocket (that gets initalized > via the listenerSocket) reports 127.0.0.1 for its remote address, and hence the test fails. > > Similar for testLocalAddress, when connecting to 127.0.1.1, the clients local address > reports 127.0.0.1. Is primitiveSocketLocalAddress broken? I don't think that primitiveSocketLocalAddress is broken. It correctly answers the address associated with the local host name, which is not necessarily the same as the address associated with the name 'localhost'. The update that you did in NetworkTests-topa.38 looks like the right thing to do. It uses the address associated with the name 'localhost', not the address associated with the local host name, and that would be the intended behavior for the tests. Dave > > Best regards > -Tobias > > > [1]: https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution From cunningham.cb at gmail.com Wed Sep 9 15:42:02 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Wed Sep 9 15:42:05 2015 Subject: [squeak-dev] ByteArray accessors - questions about some of the accessors Message-ID: Hi. First and foremost, this is not about an issue caused by the recent enhancements to the ByteArray accessors for 64-bit manipulation, but rather a series of questions that has been brewing in my mind during the discussions. I notice that I can't pass negative numbers to the various #unsigned..At:put:bigEndian: methods. While this may be on purpose (since they are UNSIGNED), it is still annoying. I happen to know that our numbers are stored roughly two-complement, meaning that -1 is the same as 16rFF, 16rFFFF, 16rFFFFFFFF, etc - whatever size I choose (since our digits are never end - we essentially have a infinite length twos compliment negative numbers). Yet I can't store them with the unsigned, getting an improper store each time I try. All of these fail: ba at: 1 put: -1 ba unsignedShortAt: 1 put: -1 bigEndian: false ba unsignedLongAt: 1 put: -1 bigEndian: false ba unsignedLong64At: 1 put: -1 bigEndian: false Is this intentional, and I should stop trying to abuse the methods? If so, I'll stop. Still: ba at: 1 put: -1 ba shortAt: 1 put: -1 bigEndian: false ba longAt: 1 put: -1 bigEndian: false ba long64At: 1 put: -1 bigEndian: false Only the second and third of the above work- we haven't yet added the fourth one, and apparently we signed byte access has never been there. (And there are uses of signed bytes out there - google it - but I have not personally needed it. Still, we could/should be complete.) The other issue found (by accident) is that #longAt:put:bigEndian and #unsignedLongAt:put:bigEndian: allow for arbitrarily large numbers to be passed to them - way bigger than 32 bits - and stores the end 32 bits off of them to the array. (Except you can't pass SOME negative numbers like -1 to #unsignedLongAt:put:bigEndian: - go figure). This should be fixed - but it is a very long-standing bug. -cbc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/2ae7adfd/attachment.htm From lewis at mail.msen.com Wed Sep 9 16:17:17 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Wed Sep 9 16:17:20 2015 Subject: [squeak-dev] ByteArray accessors - questions about some of the accessors In-Reply-To: References: Message-ID: <4478.136.2.1.102.1441815437.squirrel@webmail.msen.com> Hi Chris, I have not been following these updates too closely, but I can say without hesitation that using -1 as shorthand for 16rff or 16rffff (or whatever) in the context of unsigned integer fields would be a bad thing to do, and if our accessors are treating it as an error, then that is good. It might be good to document this in the form of unit tests that explain that the failure is intentional. Dave > Hi. > > First and foremost, this is not about an issue caused by the recent > enhancements to the ByteArray accessors for 64-bit manipulation, but > rather > a series of questions that has been brewing in my mind during the > discussions. > > I notice that I can't pass negative numbers to the various > #unsigned..At:put:bigEndian: methods. While this may be on purpose > (since > they are UNSIGNED), it is still annoying. I happen to know that our > numbers are stored roughly two-complement, meaning that -1 is the same as > 16rFF, 16rFFFF, 16rFFFFFFFF, etc - whatever size I choose (since our > digits > are never end - we essentially have a infinite length twos compliment > negative numbers). Yet I can't store them with the unsigned, getting an > improper store each time I try. All of these fail: > > ba at: 1 put: -1 > ba unsignedShortAt: 1 put: -1 bigEndian: false > ba unsignedLongAt: 1 put: -1 bigEndian: false > ba unsignedLong64At: 1 put: -1 bigEndian: false > > Is this intentional, and I should stop trying to abuse the methods? If > so, > I'll stop. > > Still: > > ba at: 1 put: -1 > ba shortAt: 1 put: -1 bigEndian: false > ba longAt: 1 put: -1 bigEndian: false > ba long64At: 1 put: -1 bigEndian: false > > Only the second and third of the above work- we haven't yet added the > fourth one, and apparently we signed byte access has never been there. > (And there are uses of signed bytes out there - google it - but I have > not > personally needed it. Still, we could/should be complete.) > > The other issue found (by accident) is that #longAt:put:bigEndian and > #unsignedLongAt:put:bigEndian: allow for arbitrarily large numbers to be > passed to them - way bigger than 32 bits - and stores the end 32 bits off > of them to the array. (Except you can't pass SOME negative numbers like > -1 > to #unsignedLongAt:put:bigEndian: - go figure). This should be fixed - > but > it is a very long-standing bug. > > -cbc > > From tim at rowledge.org Wed Sep 9 18:17:08 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 9 18:17:12 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI Message-ID: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> I?m trying - and so far failing - to do what should surely be a very simple thing. This isn?t a new situation? especially on unix. I have a single C file with just two functions. I have a matching H file. I want to make them into a dynamic library that I can call via FFI. This really shouldn?t be rocket science stuff! So far I can a) compile the C file (well duh) b) link it as a shared library c) install it in /usr/local/lib (next to another library that I can use from FFI already, so I know the path gets looked at) d) set the permissions to match the working library e) use from a simple C program to prove it works However, all I get from squeak is an error that the external module is not found. I?ll take a look with a debug vm but I?d be very happy to hear that I?m forgetting some trivial flag or incantation that can short-circuit the ?fun? of using gdb. Here is the code and makefile - https://copy.com/DGDbpJM4wnHQrDUG What I?ve been doing to build & try is make clean make sudo install -m 0755 libmadgwickIMU..s0.1 /usr/local/lib/libmadgwickIMU.so.1 sudo ln -sf /usr/local/lib/libmadgwickIMU.so.1 /usr/local/lib/libmadwickIMU.so sudo ldconfig gcc -Wall -o testing testing.c -lmadwickIMU ./testing ?testing? seem to do the right thing. Going into squeak (cog/spur/pi) and trying a method like - invSqrt: floatval # ^self externalCallFailed - just gives me the not found module error. I?ve restarted squeak after building the lib, I?ve opened a new terminal after building the lib (just in case there?s some stupid path-exporting nonsense I don?t understand etc) and I?ve made sure to smile only on the left side. What on earth am I forgetting? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Braccae illae virides cum subucula rosea et tunica Caledonia-quam elenganter concinnatur! = Those green pants go so well with that pink shirt and the plaid jacket! From cunningham.cb at gmail.com Wed Sep 9 18:33:13 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Wed Sep 9 18:33:15 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> Message-ID: Hmm. Maybe try creating the class method: moduleName ^'madgwickIMU' (assuming you haven't already). -cbc On Wed, Sep 9, 2015 at 11:17 AM, tim Rowledge wrote: > I?m trying - and so far failing - to do what should surely be a very > simple thing. This isn?t a new situation? > especially on unix. > > I have a single C file with just two functions. I have a matching H file. > I want to make them into a dynamic library that I can call via FFI. This > really shouldn?t be rocket science stuff! > > So far I can > a) compile the C file (well duh) > b) link it as a shared library > c) install it in /usr/local/lib (next to another library that I can use > from FFI already, so I know the path gets looked at) > d) set the permissions to match the working library > e) use from a simple C program to prove it works > > However, all I get from squeak is an error that the external module is not > found. I?ll take a look with a debug vm but I?d be very happy to hear that > I?m forgetting some trivial flag or incantation that can short-circuit the > ?fun? of using gdb. > > Here is the code and makefile - > https://copy.com/DGDbpJM4wnHQrDUG > > What I?ve been doing to build & try is > make clean > make > sudo install -m 0755 libmadgwickIMU..s0.1 > /usr/local/lib/libmadgwickIMU.so.1 > sudo ln -sf /usr/local/lib/libmadgwickIMU.so.1 > /usr/local/lib/libmadwickIMU.so > sudo ldconfig > gcc -Wall -o testing testing.c -lmadwickIMU > ./testing > > ?testing? seem to do the right thing. Going into squeak (cog/spur/pi) and > trying a method like - > invSqrt: floatval > # > ^self externalCallFailed > - just gives me the not found module error. > > I?ve restarted squeak after building the lib, I?ve opened a new terminal > after building the lib (just in case there?s some stupid path-exporting > nonsense I don?t understand etc) and I?ve made sure to smile only on the > left side. What on earth am I forgetting? > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Useful Latin Phrases:- Braccae illae virides cum subucula rosea et tunica > Caledonia-quam elenganter concinnatur! = Those green pants go so well with > that pink shirt and the plaid jacket! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/43b22f9c/attachment.htm From commits at source.squeak.org Wed Sep 9 18:38:07 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 9 18:38:08 2015 Subject: [squeak-dev] The Trunk: CollectionsTests-ul.250.mcz Message-ID: Levente Uzonyi uploaded a new version of CollectionsTests to project The Trunk: http://source.squeak.org/trunk/CollectionsTests-ul.250.mcz ==================== Summary ==================== Name: CollectionsTests-ul.250 Author: ul Time: 9 September 2015, 8:33:02.788 pm UUID: eab1e808-8b9c-4d1e-beaa-d6476b070026 Ancestors: CollectionsTests-ul.249 ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: checks all possible index ranges of the given ByteArray. =============== Diff against CollectionsTests-ul.249 =============== Item was changed: ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter:getter:unsigned:storageBits: (in category 'testing - platform independent access') ----- verifyPlatformIndepentendIntegerAccessorsAtBitBordersSetter: setter getter: getter unsigned: unsigned storageBits: storageBits | byteArray minValue maxValue baseValues | + byteArray := ByteArray new: storageBits // 8 * 2. - byteArray := ByteArray new: storageBits // 8. unsigned ifTrue: [ minValue := 0. maxValue := 1 << storageBits - 1. baseValues := #(0 1) ] ifFalse: [ minValue := -1 << (storageBits - 1). maxValue := 1 << (storageBits - 1) - 1. baseValues := #(-1 0 1) ]. #(true false) do: [ :bigEndian | 0 to: storageBits - 1 do: [ :bits | baseValues do: [ :baseValue | | centerValue | centerValue := baseValue << bits. centerValue - 1 to: centerValue + 1 do: [ :value | (value between: minValue and: maxValue) ifTrue: [ self verifyPlatformIndepentendIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian ] ] ] ] ] ! Item was changed: ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: (in category 'testing - platform independent access') ----- verifyPlatformIndepentendIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian + | expectedSetterResult getterResult bytes | - | expectedSetterResult getterResult | expectedSetterResult := self byteArrayFor: value bits: storageBits bigEndian: bigEndian. + bytes := storageBits // 8. + 1 to: byteArray size - bytes + 1 do: [ :index | + byteArray + perform: setter + with: index + with: value + with: bigEndian. + 1 to: bytes do: [ :byteIndex | + self + assert: (expectedSetterResult at: byteIndex) + equals: (byteArray at: index + byteIndex - 1) ]. + getterResult := byteArray + perform: getter + with: index + with: bigEndian. + self assert: value equals: getterResult ]! - byteArray perform: setter with: 1 with: value with: bigEndian. - self assert: expectedSetterResult equals: byteArray. - getterResult := byteArray perform: getter with: 1 with: bigEndian. - self assert: value equals: getterResult! Item was changed: ----- Method: ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter:getter:unsigned:storageBits:random: (in category 'testing - platform independent access') ----- verifyPlatformIndepentendIntegerAccessorsWithRandomValuesSetter: setter getter: getter unsigned: unsigned storageBits: storageBits random: random | byteArray randomMax randomOffset | + byteArray := ByteArray new: storageBits // 8 * 2. - byteArray := ByteArray new: storageBits // 8. randomMax := 1 << storageBits. randomOffset := unsigned ifTrue: [ -1 ] ifFalse: [ -1 << (storageBits - 1) - 1 ]. 10000 timesRepeat: [ | value | value := (random nextInt: randomMax) + randomOffset. #(true false) do: [ :bigEndian | self verifyPlatformIndepentendIntegerAccessorsMatch: byteArray for: value setter: setter getter: getter storageBits: storageBits bigEndian: bigEndian ] ]! From commits at source.squeak.org Wed Sep 9 18:38:27 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 9 18:38:29 2015 Subject: [squeak-dev] The Trunk: Collections-ul.655.mcz Message-ID: Levente Uzonyi uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ul.655.mcz ==================== Summary ==================== Name: Collections-ul.655 Author: ul Time: 9 September 2015, 8:30:27.564 pm UUID: 179eb75e-eb8d-4c16-8934-158921d1ff81 Ancestors: Collections-ul.654 - 64-bit compatible and faster ByteArray>>unsignedLong64At:put:bigEndian: - faster ByteArray>>unsignedLong64At:bigEndian: =============== Diff against Collections-ul.654 =============== Item was changed: ----- Method: ByteArray>>longAt:bigEndian: (in category 'platform independent access') ----- longAt: index bigEndian: bigEndian "Return a 32-bit integer quantity starting from the given byte index. Use #normalize where necessary to ensure compatibility with non-30-bit SmallIntegers." | byte result | bigEndian ifFalse: [ (byte := self at: index + 3) <= 16r7F ifTrue: [ "Is the result non-negative?" byte <= 16r3F ifTrue: [ ^(((byte bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index) ]. ^(LargePositiveInteger new: 4) replaceFrom: 1 + to: 4 + with: self + startingAt: index; - to: 4 - with: self - startingAt: index; normalize ]. "Negative" byte >= 16rC0 ifTrue: [ ^-1 - (((((byte bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 1) bitXor: 16rFFFFFF) bitShift: 8) + ((self at: index) bitXor: 16rFF)) ]. (result := LargeNegativeInteger new: 4) digitAt: 4 put: ((self at: index + 3) bitXor: 16rFF); digitAt: 3 put: ((self at: index + 2) bitXor: 16rFF); digitAt: 2 put: ((self at: index + 1) bitXor: 16rFF). (byte := ((self at: index) bitXor: 16rFF) + 1) <= 16rFF ifTrue: [ ^result digitAt: 1 put: byte; normalize ]. ^result digitAt: 1 put: 16rFF; + - 1 "It's tempting to do the subtraction in a loop to avoid the LargeInteger creation, but it's actually slower than this." ]. - - 1 "It's tempting to do the subtraction in a loop, to avoid the LargeInteger creation, but it's actually slower than this." ]. (byte := self at: index) <= 16r7F ifTrue: [ "Is the result non-negative?" byte <= 16r3F ifTrue: [ ^(((byte bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 3) ]. ^(LargePositiveInteger new: 4) digitAt: 1 put: (self at: index + 3); digitAt: 2 put: (self at: index + 2); digitAt: 3 put: (self at: index + 1); digitAt: 4 put: byte; normalize ]. "Negative" 16rC0 <= byte ifTrue: [ ^-1 - (((((byte bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index + 2) bitXor: 16rFFFFFF) bitShift: 8) + ((self at: index + 3) bitXor: 16rFF)) ]. (result := LargeNegativeInteger new: 4) digitAt: 4 put: (byte bitXor: 16rFF); digitAt: 3 put: ((self at: index + 1) bitXor: 16rFF); digitAt: 2 put: ((self at: index + 2) bitXor: 16rFF). (byte := ((self at: index + 3) bitXor: 16rFF) + 1) <= 16rFF ifTrue: [ ^result digitAt: 1 put: byte; normalize ]. ^result digitAt: 1 put: 16rFF; + - 1 "It's tempting to do the subtraction in a loop to avoid the LargeInteger creation, but it's actually slower than this."! - - 1 "It's tempting to do the subtraction in a loop, to avoid the LargeInteger creation, but it's actually slower than this."! Item was changed: ----- Method: ByteArray>>unsignedLong64At:bigEndian: (in category 'platform independent access') ----- unsignedLong64At: index bigEndian: bigEndian "Return a 64-bit unsigned integer quantity starting from the given byte index. Use #normalize where necessary to ensure compatibility with non-30-bit SmallIntegers." | v | bigEndian ifFalse: [ (v := self at: index + 7) = 0 ifFalse: [ ^(LargePositiveInteger new: 8) + replaceFrom: 1 + to: 8 + with: self + startingAt: index; - digitAt: 1 put: (self at: index); - digitAt: 2 put: (self at: index + 1); - digitAt: 3 put: (self at: index + 2); - digitAt: 4 put: (self at: index + 3); - digitAt: 5 put: (self at: index + 4); - digitAt: 6 put: (self at: index + 5); - digitAt: 7 put: (self at: index + 6); - digitAt: 8 put: v; normalize ]. (v := self at: index + 6) = 0 ifFalse: [ ^(LargePositiveInteger new: 7) + replaceFrom: 1 + to: 7 + with: self + startingAt: index; - digitAt: 1 put: (self at: index); - digitAt: 2 put: (self at: index + 1); - digitAt: 3 put: (self at: index + 2); - digitAt: 4 put: (self at: index + 3); - digitAt: 5 put: (self at: index + 4); - digitAt: 6 put: (self at: index + 5); - digitAt: 7 put: v; normalize ]. (v := self at: index + 5) = 0 ifFalse: [ ^(LargePositiveInteger new: 6) + replaceFrom: 1 + to: 6 + with: self + startingAt: index; - digitAt: 1 put: (self at: index); - digitAt: 2 put: (self at: index + 1); - digitAt: 3 put: (self at: index + 2); - digitAt: 4 put: (self at: index + 3); - digitAt: 5 put: (self at: index + 4); - digitAt: 6 put: v; normalize ]. (v := self at: index + 4) = 0 ifFalse: [ ^(LargePositiveInteger new: 5) + replaceFrom: 1 + to: 5 + with: self + startingAt: index; - digitAt: 1 put: (self at: index); - digitAt: 2 put: (self at: index + 1); - digitAt: 3 put: (self at: index + 2); - digitAt: 4 put: (self at: index + 3); - digitAt: 5 put: v; normalize ]. (v := self at: index + 3) <= 16r3F ifFalse: [ ^(LargePositiveInteger new: 4) + replaceFrom: 1 + to: 4 + with: self + startingAt: index; - digitAt: 1 put: (self at: index); - digitAt: 2 put: (self at: index + 1); - digitAt: 3 put: (self at: index + 2); - digitAt: 4 put: v; normalize ]. ^(((v bitShift: 8) + (self at: index + 2) bitShift: 8) + (self at: index + 1) bitShift: 8) + (self at: index) ]. (v := self at: index) = 0 ifFalse: [ ^(LargePositiveInteger new: 8) digitAt: 1 put: (self at: index + 7); digitAt: 2 put: (self at: index + 6); digitAt: 3 put: (self at: index + 5); digitAt: 4 put: (self at: index + 4); digitAt: 5 put: (self at: index + 3); digitAt: 6 put: (self at: index + 2); digitAt: 7 put: (self at: index + 1); digitAt: 8 put: v; normalize ]. (v := self at: index + 1) = 0 ifFalse: [ ^(LargePositiveInteger new: 7) digitAt: 1 put: (self at: index + 7); digitAt: 2 put: (self at: index + 6); digitAt: 3 put: (self at: index + 5); digitAt: 4 put: (self at: index + 4); digitAt: 5 put: (self at: index + 3); digitAt: 6 put: (self at: index + 2); digitAt: 7 put: v; normalize ]. (v := self at: index + 2) = 0 ifFalse: [ ^(LargePositiveInteger new: 6) digitAt: 1 put: (self at: index + 7); digitAt: 2 put: (self at: index + 6); digitAt: 3 put: (self at: index + 5); digitAt: 4 put: (self at: index + 4); digitAt: 5 put: (self at: index + 3); digitAt: 6 put: v; normalize ]. (v := self at: index + 3) = 0 ifFalse: [ ^(LargePositiveInteger new: 5) digitAt: 1 put: (self at: index + 7); digitAt: 2 put: (self at: index + 6); digitAt: 3 put: (self at: index + 5); digitAt: 4 put: (self at: index + 4); digitAt: 5 put: v; normalize ]. (v := self at: index + 4) <= 16r3F ifFalse: [ ^(LargePositiveInteger new: 4) digitAt: 1 put: (self at: index + 7); digitAt: 2 put: (self at: index + 6); digitAt: 3 put: (self at: index + 5); digitAt: 4 put: v; normalize ]. ^(((v bitShift: 8) + (self at: index + 5) bitShift: 8) + (self at: index + 6) bitShift: 8) + (self at: index + 7)! Item was changed: ----- Method: ByteArray>>unsignedLong64At:put:bigEndian: (in category 'platform independent access') ----- unsignedLong64At: index put: value bigEndian: bigEndian "Store a 64-bit unsigned integer quantity starting from the given byte index" + | i j | + value isLarge ifTrue: [ + i := value digitLength. + bigEndian ifFalse: [ - value isLarge - ifTrue: [ - | i size | - size := value digitLength. - bigEndian ifFalse: [ - self - replaceFrom: index - to: index + size - 1 - with: value - startingAt: 1; - replaceFrom: index + size - to: index + 7 - with: #[0 0 0 0] - startingAt: 1. - ^value ]. - i := 1. - [ i <= size ] whileTrue: [ - self at: index + 8 - i put: (value digitAt: i). - i := i + 1 ]. - [ i <= 8 ] whileTrue: [ - self at: index + 8 - i put: 0. - i := i + 1 ] ] - ifFalse: [ - bigEndian ifFalse: [ - self - at: index put: (value bitAnd: 16rFF); - at: index + 1 put: ((value bitShift: -8) bitAnd: 16rFF); - at: index + 2 put: ((value bitShift: -16) bitAnd: 16rFF); - at: index + 3 put: (value bitShift: -24); - replaceFrom: index + 4 - to: index + 7 - with: #[0 0 0 0] - startingAt: 1. - ^value ]. self replaceFrom: index + to: index + i - 1 + with: value - to: index + 3 - with: #[0 0 0 0] startingAt: 1; + replaceFrom: index + i + to: index + 7 + with: #[0 0 0 0 0 0 0 0] + startingAt: 1. + ^value ]. + j := index + 8. + i <= 7 ifTrue: [ + self + replaceFrom: index + to: j - i - 1 + with: #[0 0 0 0 0 0 0 0] + startingAt: 1 ]. + [ 1 <= i ] whileTrue: [ + self at: j - i put: (value digitAt: i). + i := i - 1 ]. + ^value ]. + bigEndian ifFalse: [ + j := index - 1. + i := value. + [ 1 <= i ] whileTrue: [ + self at: (j := j + 1) put: (i bitAnd: 16rFF). + i := i bitShift: -8 ]. + self replaceFrom: j + 1 + to: index + 7 + with: #[0 0 0 0 0 0 0 0] + startingAt: 1. + ^value ]. + j := index + 8. + i := value. + [ 1 <= i ] whileTrue: [ + self at: (j := j - 1) put: (i bitAnd: 16rFF). + i := i bitShift: -8 ]. + self replaceFrom: index + to: j - 1 + with: #[0 0 0 0 0 0 0 0] + startingAt: 1. - at: index + 4 put: (value bitShift: -24); - at: index + 5 put: ((value bitShift: -16) bitAnd: 16rFF); - at: index + 6 put: ((value bitShift: -8) bitAnd: 16rFF); - at: index + 7 put: (value bitAnd: 16rFF) ]. ^value! From tim at rowledge.org Wed Sep 9 18:40:19 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 9 18:40:24 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> Message-ID: <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> On 09-09-2015, at 11:33 AM, Chris Cunningham wrote: > Hmm. Maybe try creating the class method: > > moduleName > ^'madgwickIMU' > > (assuming you haven't already). Ah, but that would be for a plugin, whereas this is a simple C library. Or *should* be, if I got it right. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: XER: Exclusive ERror From cunningham.cb at gmail.com Wed Sep 9 18:44:30 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Wed Sep 9 18:44:33 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> Message-ID: On Wed, Sep 9, 2015 at 11:40 AM, tim Rowledge wrote: > > On 09-09-2015, at 11:33 AM, Chris Cunningham > wrote: > > > Hmm. Maybe try creating the class method: > > > > moduleName > > ^'madgwickIMU' > > > > (assuming you haven't already). > > Ah, but that would be for a plugin, whereas this is a simple C library. Or > *should* be, if I got it right. > > ok. Does FFI know to prepend the lib and postpend the .so in Unix for you? I'm curious. -cbc > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: XER: Exclusive ERror > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/4f6374e3/attachment.htm From tim at rowledge.org Wed Sep 9 18:55:14 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 9 18:55:18 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> Message-ID: <31FDC339-4275-4558-A72C-B91335E1A56D@rowledge.org> On 09-09-2015, at 11:44 AM, Chris Cunningham wrote: > ok. Does FFI know to prepend the lib and postpend the .so in Unix for you? I'm curious. Well, it does for other libraries; for example calling libwiringPi.so you use # tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SNARF: System Normalize And Reset Flags From nicolaihess at web.de Wed Sep 9 19:26:41 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Wed Sep 9 19:26:44 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <31FDC339-4275-4558-A72C-B91335E1A56D@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> <31FDC339-4275-4558-A72C-B91335E1A56D@rowledge.org> Message-ID: How do you start squeak ? Is there a squeak shell script that may modify the library lookup path? you could try to start squeak with LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH squeak 2015-09-09 20:55 GMT+02:00 tim Rowledge : > > On 09-09-2015, at 11:44 AM, Chris Cunningham > wrote: > > ok. Does FFI know to prepend the lib and postpend the .so in Unix for > you? I'm curious. > > Well, it does for other libraries; for example calling libwiringPi.so you > use # > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: SNARF: System Normalize And Reset Flags > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/6a898b52/attachment.htm From tim at rowledge.org Wed Sep 9 19:41:39 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 9 19:41:43 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> <31FDC339-4275-4558-A72C-B91335E1A56D@rowledge.org> Message-ID: On 09-09-2015, at 12:26 PM, Nicolai Hess wrote: > How do you start squeak ? > Is there a squeak shell script that may modify the library lookup path? > > you could try to start squeak with > LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH squeak OK, tried that to no avail; but the wiringPi library in the same directory works :-) What fun, eh? ldconfig -p | grep mad shows ?libmadgwickIMU.so (libc6,hard-float) => /usr/local/lib.libmadgwickIMU.so Into the joys of gdb right now, just starting to (attempt to) load the lib. I wonder if it?ll be friendly? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim In the long run, every program becomes rococco, and then rubble. From brasspen at gmail.com Wed Sep 9 19:55:35 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Wed Sep 9 19:55:39 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <31FDC339-4275-4558-A72C-B91335E1A56D@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> <31FDC339-4275-4558-A72C-B91335E1A56D@rowledge.org> Message-ID: I think you may have typed "W" one to many times in this Makefile and you're adding them where they don't belong. I detect a rogue W in the name madgwick. @$(CC) -shared -Wl,-soname,libmadgwickIMU.so -o lib--------->w<---------madgwickIMU.so.$(VERSION) -lm $(OBJ) Also, when I compile on this Ubuntu 15.04 I get an error. [1] FWIW, Chris [1] $ make [Compile] MadgwickAHRS.c MadgwickAHRS.c: In function ?invSqrt?: MadgwickAHRS.c:218:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] long i = *(long*)&y; ^ MadgwickAHRS.c:220:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] y = *(float*)&i; ^ [Link (Dynamic)] On Wed, Sep 9, 2015 at 2:55 PM, tim Rowledge wrote: > > On 09-09-2015, at 11:44 AM, Chris Cunningham > wrote: > > ok. Does FFI know to prepend the lib and postpend the .so in Unix for > you? I'm curious. > > Well, it does for other libraries; for example calling libwiringPi.so you > use # > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: SNARF: System Normalize And Reset Flags > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/37c49094/attachment.htm From tim at rowledge.org Wed Sep 9 20:13:17 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 9 20:13:21 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <9AB1D999-99C4-4038-9FD6-0B79FFD6E229@rowledge.org> <31FDC339-4275-4558-A72C-B91335E1A56D@rowledge.org> Message-ID: <3E67B514-D99A-4155-9C20-24DC870689A6@rowledge.org> On 09-09-2015, at 12:55 PM, Chris Cunnington wrote: > I think you may have typed "W" one to many times in this Makefile and you're adding them where they don't belong. I detect a rogue W in the name madgwick. Ah, just for a moment there I thought you?d spotted the dumb mistake. But I was ?correcting? that in the install stuff and fixing the makefile etc resulted in exactly the same result. Sigh. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa. From kbrown at mac.com Wed Sep 9 21:07:48 2015 From: kbrown at mac.com (Ken G. Brown) Date: Wed Sep 9 21:08:01 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> Message-ID: <569392A5-A2F3-4179-BCE7-FAD646BAD8A3@mac.com> > > On Sep 9, 2015, at 12:17, tim Rowledge wrote: > > sudo install -m 0755 libmadgwickIMU..s0.1 /usr/local/lib/libmadgwickIMU.so.1 > sudo ln -sf /usr/local/lib/libmadgwickIMU.so.1 /usr/local/lib/libmadwickIMU.so ^ Is there a reason for the madwick instead of madgwick? Ken > On Sep 9, 2015, at 12:17, tim Rowledge wrote: > > I?m trying - and so far failing - to do what should surely be a very simple thing. This isn?t a new situation? > especially on unix. > > I have a single C file with just two functions. I have a matching H file. I want to make them into a dynamic library that I can call via FFI. This really shouldn?t be rocket science stuff! > > So far I can > a) compile the C file (well duh) > b) link it as a shared library > c) install it in /usr/local/lib (next to another library that I can use from FFI already, so I know the path gets looked at) > d) set the permissions to match the working library > e) use from a simple C program to prove it works > > However, all I get from squeak is an error that the external module is not found. I?ll take a look with a debug vm but I?d be very happy to hear that I?m forgetting some trivial flag or incantation that can short-circuit the ?fun? of using gdb. > > Here is the code and makefile - > https://copy.com/DGDbpJM4wnHQrDUG > > What I?ve been doing to build & try is > make clean > make > sudo install -m 0755 libmadgwickIMU..s0.1 /usr/local/lib/libmadgwickIMU.so.1 > sudo ln -sf /usr/local/lib/libmadgwickIMU.so.1 /usr/local/lib/libmadwickIMU.so > sudo ldconfig > gcc -Wall -o testing testing.c -lmadwickIMU > ./testing > > ?testing? seem to do the right thing. Going into squeak (cog/spur/pi) and trying a method like - > invSqrt: floatval > # > ^self externalCallFailed > - just gives me the not found module error. > > I?ve restarted squeak after building the lib, I?ve opened a new terminal after building the lib (just in case there?s some stupid path-exporting nonsense I don?t understand etc) and I?ve made sure to smile only on the left side. What on earth am I forgetting? > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Useful Latin Phrases:- Braccae illae virides cum subucula rosea et tunica Caledonia-quam elenganter concinnatur! = Those green pants go so well with that pink shirt and the plaid jacket! > > > From leves at elte.hu Wed Sep 9 21:11:18 2015 From: leves at elte.hu (Levente Uzonyi) Date: Wed Sep 9 21:11:22 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: After thinking a bit more about this, I came to the conclusion that while I paid attention to handle reader methods in 64-bit images correctly, some of the writer methods are incorrect for "large" SmallInteger inputs. First I implemented the missing parts for 61-bit SmallIntegers using a general purpose loop, but it turned out that the loop is significantly faster for smaller numbers, and only slightly slower for larger ones, so I decided to nuke the special case for 30-bit SmallIntegers. I also found further possiblities to optimize writes, so the average is down from 259 to 236 milliseconds. Chris Muller's benchmark gives { 'cbc smallN write'->'12,200,000 per second. 81.7 nanoseconds per run.' . 'cbc smallN access'->'10,300,000 per second. 96.8 nanoseconds per run.' . 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.' . 'cbc largeN access'->'5,270,000 per second. 190 nanoseconds per run.'} Which means +20% speed for smallN writes, and +18% for largeN access. Levente P.S.: I still couldn't test the code in my 64-bit Spur image, because it won't respond to any input after startup. On Tue, 8 Sep 2015, Levente Uzonyi wrote: > Hi Chris, > > I added the #normalize sends to avoid the creation of spurious LargeIntegers > in 64-bit images (there are two places where I relied on #-'s ability to work > on unnormalized input). I didn't have a chance to test it, but I expect it to > work correctly. Even if the code is sub-optimal in 64-bit, it shouldn't be > any slower than in 32-bit. > > Levente > > On Tue, 8 Sep 2015, Chris Cunningham wrote: > >> Levente, >> Interesting.? I have a question and a concern about your implementation, >> though: >> >> Question: why in the micro checks, is the Write faster than the Access: >> {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. >> 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. >> 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. >> 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. >> yet in your more thorough benchmark, the Write twice as slow as the Access? >> "unsigned long 64" >> (put, or Write) "average asFloat 536.109375". >> (Access) "average asFloat 259.359375" >> any ideas? >> >> the concern is that your code is nicely optimized for our current 32bit vm >> - but once we go to 64 bit, I think it will fail.? Should we be >> concerned? >> >> -cbc >> >> On Tue, Sep 8, 2015 at 2:42 AM, Levente Uzonyi wrote: >> Hi All, >> >> A bit later than I wanted to, but I've finally uploaded my versions >> to the Trunk. I guess I went as far as possible with getting the >> "fastest implementation". >> I modified your benchmark to use the same numbers, so that the >> measurements could be repeated. I got the following: >> >> Before: >> {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per >> run.'. >> 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per >> run.'. >> 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per run.'. >> 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per >> run.'}. >> >> After: >> {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per >> run.'. >> 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per >> run.'. >> 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per >> run.'. >> 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per >> run.'}. >> >> As you can see, everything became faster except for smallN access. >> This is the side-effect of optimizing for the average case instead >> of specific cases - like zero bytes. I decided not to use that trick, >> because it decreased the overall performance. >> >> I also wrote a benchmark which measures reads and writes together. It >> generates random numbers which can be represented using a given >> number of bits. The result is an array of run times where values >> having and odd index belong to big-endian access, and even ones to >> little-endian. >> >> | byteArray inputs random storageBits unsigned | >> Smalltalk garbageCollect. >> random := Random seed: 36rSqueak. >> storageBits := 64. >> unsigned := true. >> byteArray := ByteArray new: storageBits // 8 * 2. >> inputs := Array new: 100000. >> (2 to: storageBits * 2 + 1) collect: [ :descriptor | >> ? ? ? ? "lowest bit describes endianness, the rest the number of >> bits." >> ? ? ? ? | limit bigEndian offset | >> ? ? ? ? bigEndian := descriptor odd. >> ? ? ? ? limit := 1 << (descriptor >> 1) - 1. >> ? ? ? ? unsigned >> ? ? ? ? ? ? ? ? ifTrue: [ offset := -1 ] >> ? ? ? ? ? ? ? ? ifFalse: [ offset := -1- (limit >> 1) ]. >> ? ? ? ? inputs replace: [ :each | (random nextInt: limit) + offset ]. >> ? ? ? ? [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ >> :startIndex | >> ? ? ? ? ? ? ? ? 1 to: inputs size do: [ :inputIndex | >> ? ? ? ? ? ? ? ? ? ? ? ? byteArray >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsignedLong64At: startIndex >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? put: (inputs at: inputIndex) >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigEndian: bigEndian; >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsignedLong64At: startIndex >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? bigEndian: bigEndian ] ] ] >> timeToRun ]. >> >> I ran it with various accessors and got the following results: >> >> "short" >> #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 >> 28 28 28 28 28 28 26 28 28 28) "average asFloat 27.625". >> #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 >> 20 20 20 20 20 22 20 20 20 20) "average asFloat 19.5". >> >> "long" >> #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 >> 70 72 72 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 >> 72 76 70 76 72 76 70 76 72 76 72 74 72 76 72 74 72 76 570 584) >> "average asFloat 87.28125". >> #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 >> 72 72 74 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 >> 74 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 74 72 116 122) >> "average asFloat 73.625". >> >> "unsigned short" >> #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 >> 20 20 20 20 18 20 18 18 18 18) "average asFloat 18.5". >> #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 >> 18 18 18 18 18 18 18 18 18 18) "average asFloat 18.125". >> >> "unsigned long" >> #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 >> 52 54 52 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 >> 60 58 56 56 60 62 60 62 62 62 60 62 60 62 62 62 384 400 520 694) >> "average asFloat 82.40625". >> ?#(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 62 >> 64 64 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 >> 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) >> "average asFloat 69.09375". >> >> "unsigned long 64" >> #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 312 >> 306 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 >> 316 314 318 316 316 318 316 318 316 316 316 318 318 316 316 326 324 >> 326 322 326 322 328 324 326 322 326 322 510 520 592 592 634 618 >> 636 640 652 666 642 644 660 648 642 660 652 646 662 658 636 648 626 >> 632 650 628 632 612 632 620 622 636 626 626 644 632 750 748 812 >> 822 828 858 842 862 898 880 896 840 870 896 926 870 1034 846 880 834 >> 876 824 860 818 848 824 826 864 820 848 820 828) "average asFloat >> 536.109375". >> #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 166 >> 170 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 >> 170 166 172 166 172 164 174 166 170 168 172 166 172 166 172 166 170 >> 164 170 166 172 164 172 166 172 166 170 238 272 264 484 282 344 >> 284 356 292 362 294 364 288 362 292 366 294 368 290 364 294 374 294 >> 374 296 370 294 374 288 370 290 366 290 368 292 364 302 382 304 >> 388 302 390 298 392 298 384 302 388 302 390 298 386 308 398 304 400 >> 504 402 298 402 298 398 302 398 294 400 298 396). "average asFloat >> 259.359375" >> >> >> Levente >> >> On Sun, 30 Aug 2015, Chris Muller wrote: >> >> Hi Chris, I think these methods belong in the image with the >> fastest >> implementation we can do. >> >> I implemented 64-bit unsigned access for Ma Serializer back in >> 2005. >> I modeled my implementation after Andreas' original approach >> which >> tries to avoid LI arithmetic.? I was curious whether your >> implementations would be faster, because if they are then it >> could >> benefit Magma.? After loading "Ma Serializer" 1.5 (or head) >> into a >> trunk image, I used the following script to take comparison >> measurements: >> >> | smallN largeN maBa cbBa |? smallN := ((2 raisedTo: 13) to: (2 >> raisedTo: 14)) atRandom. >> largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. >> maBa := ByteArray new: 8. >> cbBa := ByteArray new: 8. >> maBa maUint: 64 at: 0 put: largeN. >> cbBa unsignedLong64At: 1 put: largeN bigEndian: false. >> self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: >> 1 >> bigEndian: false). >> { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN >> bigEndian: false] bench. >> 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] >> bench. >> 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: >> false. ] bench. >> 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. >> 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN >> bigEndian: false] bench. >> 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] >> bench. >> 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: >> false ] bench. >> 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. >> } >> >> Here are the results: >> >> 'cbc smallN write'->'3,110,000 per second.? 322 nanoseconds per >> run.' . >> 'ma smallN write'->'4,770,000 per second.? 210 nanoseconds per >> run.' . >> 'cbc smallN access'->'4,300,000 per second.? 233 nanoseconds >> per run.' . >> 'ma smallN access'->'16,400,000 per second.? 60.9 nanoseconds >> per run.' . >> 'cbc largeN write'->'907,000 per second.? 1.1 microseconds per >> run.' . >> 'ma largeN write'->'6,620,000 per second.? 151 nanoseconds per >> run.' . >> 'cbc largeN access'->'1,900,000 per second.? 527 nanoseconds >> per run.' . >> 'ma largeN access'->'1,020,000 per second.? 982 nanoseconds per >> run.' >> >> It looks like your 64-bit access is 86% faster for accessing >> the >> high-end of the 64-bit range, but slower in the other 3 >> metrics. >> Noticeably, it was only 14% as fast for writing the high-end of >> the >> 64-bit range, and similarly as much slower for small-number >> access.. >> >> >> On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham >> wrote: >> Hi. >> >> I've committed a change to the inbox with changes to >> allow getting/putting >> 64bit values to ByteArrays (similar to 32 and 16 bit >> accessors).? Could this >> be added to trunk? >> >> Also, first time I used the selective commit function - >> very nice!? the >> changes I didn't want committed didn't, in fact, get >> commited.? Just the >> desirable bits! >> >> -cbc >> >> >> >> >> >> >> >> > From tim at rowledge.org Wed Sep 9 21:13:51 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 9 21:13:56 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <569392A5-A2F3-4179-BCE7-FAD646BAD8A3@mac.com> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <569392A5-A2F3-4179-BCE7-FAD646BAD8A3@mac.com> Message-ID: On 09-09-2015, at 2:07 PM, Ken G. Brown wrote: >> >> On Sep 9, 2015, at 12:17, tim Rowledge wrote: >> >> sudo install -m 0755 libmadgwickIMU..s0.1 /usr/local/lib/libmadgwickIMU.so.1 >> sudo ln -sf /usr/local/lib/libmadgwickIMU.so.1 /usr/local/lib/libmadwickIMU.so > ^ > Is there a reason for the madwick instead of madgwick? Sigh; yes, a stupid typo when writing the email. Not in the ?actual? commandline. Now I?m running dbg through loading te wiringpi library that it *does* find ok, to see where it thinks it finds it. This is getting really a bit daft. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The substance "Hey Y'all, watch this!" is known by the state of California to be hazardous to your health. From leves at elte.hu Wed Sep 9 21:20:20 2015 From: leves at elte.hu (Levente Uzonyi) Date: Wed Sep 9 21:20:24 2015 Subject: [squeak-dev] ByteArray accessors - questions about some of the accessors In-Reply-To: <4478.136.2.1.102.1441815437.squirrel@webmail.msen.com> References: <4478.136.2.1.102.1441815437.squirrel@webmail.msen.com> Message-ID: These methods don't validate their arguments, just like most other Smalltalk methods. I'm pretty sure the unsigned*put* methods would accept LargeNegativeIntegers as input. The same applies to the signed methods with larger than acceptable inputs (e.g. shortAt:put:bigEndian: will accept 65535 and store it as if it were -1). Levente On Wed, 9 Sep 2015, David T. Lewis wrote: > Hi Chris, > > I have not been following these updates too closely, but I can say without > hesitation that using -1 as shorthand for 16rff or 16rffff (or whatever) > in the context of unsigned integer fields would be a bad thing to do, and > if our accessors are treating it as an error, then that is good. > > It might be good to document this in the form of unit tests that explain > that the failure is intentional. > > Dave > >> Hi. >> >> First and foremost, this is not about an issue caused by the recent >> enhancements to the ByteArray accessors for 64-bit manipulation, but >> rather >> a series of questions that has been brewing in my mind during the >> discussions. >> >> I notice that I can't pass negative numbers to the various >> #unsigned..At:put:bigEndian: methods. While this may be on purpose >> (since >> they are UNSIGNED), it is still annoying. I happen to know that our >> numbers are stored roughly two-complement, meaning that -1 is the same as >> 16rFF, 16rFFFF, 16rFFFFFFFF, etc - whatever size I choose (since our >> digits >> are never end - we essentially have a infinite length twos compliment >> negative numbers). Yet I can't store them with the unsigned, getting an >> improper store each time I try. All of these fail: >> >> ba at: 1 put: -1 >> ba unsignedShortAt: 1 put: -1 bigEndian: false >> ba unsignedLongAt: 1 put: -1 bigEndian: false >> ba unsignedLong64At: 1 put: -1 bigEndian: false >> >> Is this intentional, and I should stop trying to abuse the methods? If >> so, >> I'll stop. >> >> Still: >> >> ba at: 1 put: -1 >> ba shortAt: 1 put: -1 bigEndian: false >> ba longAt: 1 put: -1 bigEndian: false >> ba long64At: 1 put: -1 bigEndian: false >> >> Only the second and third of the above work- we haven't yet added the >> fourth one, and apparently we signed byte access has never been there. >> (And there are uses of signed bytes out there - google it - but I have >> not >> personally needed it. Still, we could/should be complete.) >> >> The other issue found (by accident) is that #longAt:put:bigEndian and >> #unsignedLongAt:put:bigEndian: allow for arbitrarily large numbers to be >> passed to them - way bigger than 32 bits - and stores the end 32 bits off >> of them to the array. (Except you can't pass SOME negative numbers like >> -1 >> to #unsignedLongAt:put:bigEndian: - go figure). This should be fixed - >> but >> it is a very long-standing bug. >> >> -cbc >> >> > > > > From commits at source.squeak.org Wed Sep 9 21:55:01 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 9 21:55:02 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150909215501.25229.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008959.html Name: CollectionsTests-ul.250 Ancestors: CollectionsTests-ul.249 ByteArrayTest>>verifyPlatformIndepentendIntegerAccessorsMatch:for:setter:getter:storageBits:bigEndian: checks all possible index ranges of the given ByteArray. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008960.html Name: Collections-ul.655 Ancestors: Collections-ul.654 - 64-bit compatible and faster ByteArray>>unsignedLong64At:put:bigEndian: - faster ByteArray>>unsignedLong64At:bigEndian: ============================================= From eliot.miranda at gmail.com Wed Sep 9 23:25:38 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Sep 9 23:25:46 2015 Subject: [squeak-dev] ByteArray accessors for 64-bit manipulation In-Reply-To: References: Message-ID: <8A91B316-E055-485E-A8DA-E960FB704E72@gmail.com> Hi Levente, Sent from my iPhone > On Sep 9, 2015, at 2:11 PM, Levente Uzonyi wrote: > > After thinking a bit more about this, I came to the conclusion that while I paid attention to handle reader methods in 64-bit images correctly, some of the writer methods are incorrect for "large" SmallInteger inputs. > First I implemented the missing parts for 61-bit SmallIntegers using a general purpose loop, but it turned out that the loop is significantly faster for smaller numbers, and only slightly slower for larger ones, so I decided to nuke the special case for 30-bit SmallIntegers. > I also found further possiblities to optimize writes, so the average is down from 259 to 236 milliseconds. Chris Muller's benchmark gives > > { > 'cbc smallN write'->'12,200,000 per second. 81.7 nanoseconds per run.' . > 'cbc smallN access'->'10,300,000 per second. 96.8 nanoseconds per run.' . > 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.' . > 'cbc largeN access'->'5,270,000 per second. 190 nanoseconds per run.'} > > Which means +20% speed for smallN writes, and +18% for largeN access. > > Levente > > P.S.: I still couldn't test the code in my 64-bit Spur image, because it won't respond to any input after startup. IIRC that's due to a bug in earlier versions of the bootstrap in converting negative integers, or perhaps larger positive smallintegers. Anyway I *think* that the latest Spur 64 but VM image combination works properly now. Apologies. > >> On Tue, 8 Sep 2015, Levente Uzonyi wrote: >> >> Hi Chris, >> >> I added the #normalize sends to avoid the creation of spurious LargeIntegers in 64-bit images (there are two places where I relied on #-'s ability to work on unnormalized input). I didn't have a chance to test it, but I expect it to work correctly. Even if the code is sub-optimal in 64-bit, it shouldn't be any slower than in 32-bit. >> >> Levente >> >>> On Tue, 8 Sep 2015, Chris Cunningham wrote: >>> >>> Levente, >>> Interesting. I have a question and a concern about your implementation, though: >>> Question: why in the micro checks, is the Write faster than the Access: >>> {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. >>> 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. >>> 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. >>> 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. >>> yet in your more thorough benchmark, the Write twice as slow as the Access? >>> "unsigned long 64" >>> (put, or Write) "average asFloat 536.109375". >>> (Access) "average asFloat 259.359375" >>> any ideas? >>> the concern is that your code is nicely optimized for our current 32bit vm - but once we go to 64 bit, I think it will fail. Should we be >>> concerned? >>> -cbc >>> On Tue, Sep 8, 2015 at 2:42 AM, Levente Uzonyi wrote: >>> Hi All, >>> >>> A bit later than I wanted to, but I've finally uploaded my versions to the Trunk. I guess I went as far as possible with getting the >>> "fastest implementation". >>> I modified your benchmark to use the same numbers, so that the measurements could be repeated. I got the following: >>> >>> Before: >>> {'cbc smallN write'->'3,710,000 per second. 269 nanoseconds per run.'. >>> 'cbc smallN access'->'12,000,000 per second. 83.4 nanoseconds per run.'. >>> 'cbc largeN write'->'5,430,000 per second. 184 nanoseconds per run.'. >>> 'cbc largeN access'->'1,370,000 per second. 732 nanoseconds per run.'}. >>> >>> After: >>> {'cbc smallN write'->'10,400,000 per second. 95.8 nanoseconds per run.'. >>> 'cbc smallN access'->'10,300,000 per second. 97.4 nanoseconds per run.'. >>> 'cbc largeN write'->'12,400,000 per second. 80.4 nanoseconds per run.'. >>> 'cbc largeN access'->'3,920,000 per second. 255 nanoseconds per run.'}. >>> >>> As you can see, everything became faster except for smallN access. This is the side-effect of optimizing for the average case instead >>> of specific cases - like zero bytes. I decided not to use that trick, because it decreased the overall performance. >>> >>> I also wrote a benchmark which measures reads and writes together. It generates random numbers which can be represented using a given >>> number of bits. The result is an array of run times where values having and odd index belong to big-endian access, and even ones to >>> little-endian. >>> >>> | byteArray inputs random storageBits unsigned | >>> Smalltalk garbageCollect. >>> random := Random seed: 36rSqueak. >>> storageBits := 64. >>> unsigned := true. >>> byteArray := ByteArray new: storageBits // 8 * 2. >>> inputs := Array new: 100000. >>> (2 to: storageBits * 2 + 1) collect: [ :descriptor | >>> "lowest bit describes endianness, the rest the number of bits." >>> | limit bigEndian offset | >>> bigEndian := descriptor odd. >>> limit := 1 << (descriptor >> 1) - 1. >>> unsigned >>> ifTrue: [ offset := -1 ] >>> ifFalse: [ offset := -1- (limit >> 1) ]. >>> inputs replace: [ :each | (random nextInt: limit) + offset ]. >>> [ 1 to: byteArray size - (storageBits // 8 - 1) do: [ :startIndex | >>> 1 to: inputs size do: [ :inputIndex | >>> byteArray >>> unsignedLong64At: startIndex >>> put: (inputs at: inputIndex) >>> bigEndian: bigEndian; >>> unsignedLong64At: startIndex >>> bigEndian: bigEndian ] ] ] timeToRun ]. >>> >>> I ran it with various accessors and got the following results: >>> >>> "short" >>> #(28 28 26 26 26 28 26 28 26 28 28 28 26 28 28 28 28 28 28 30 28 28 28 28 28 28 28 28 26 28 28 28) "average asFloat 27.625". >>> #(16 18 18 20 18 20 20 20 18 20 18 18 20 20 20 20 20 20 20 20 18 20 20 20 20 20 20 22 20 20 20 20) "average asFloat 19.5". >>> >>> "long" >>> #(62 62 66 68 68 70 68 70 68 70 68 70 68 70 68 70 68 70 70 74 70 72 70 72 72 74 72 72 70 74 70 72 70 72 72 76 72 76 72 76 72 76 72 74 >>> 72 76 70 76 72 76 70 76 72 76 72 74 72 76 72 74 72 76 570 584) "average asFloat 87.28125". >>> #(66 66 70 70 72 72 72 72 72 72 74 72 72 74 72 72 74 72 74 72 72 72 72 72 74 72 74 72 72 72 72 74 72 74 72 72 72 72 72 74 74 72 72 74 >>> 74 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 74 72 116 122) "average asFloat 73.625". >>> >>> "unsigned short" >>> #(18 18 18 20 16 18 18 18 18 18 18 18 18 20 18 20 18 18 18 18 18 20 20 20 20 20 18 20 18 18 18 18) "average asFloat 18.5". >>> #(18 18 18 20 20 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18) "average asFloat 18.125". >>> >>> "unsigned long" >>> #(46 48 48 50 50 50 48 48 50 48 48 48 46 48 46 48 52 54 52 52 52 54 52 54 52 52 54 54 52 54 52 54 58 58 58 58 58 58 58 58 58 58 56 58 >>> 60 58 56 56 60 62 60 62 62 62 60 62 60 62 62 62 384 400 520 694) "average asFloat 82.40625". >>> #(62 62 62 64 64 62 62 62 62 64 64 64 64 64 64 64 62 62 64 62 64 62 64 64 64 64 64 64 64 64 64 64 64 64 62 62 64 64 64 64 62 64 64 64 >>> 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 62 100 108 106 298) "average asFloat 69.09375". >>> >>> "unsigned long 64" >>> #(300 300 300 300 300 300 300 300 300 300 300 300 300 298 302 300 312 306 308 310 308 306 308 308 310 308 308 308 310 308 312 308 318 >>> 316 314 318 316 316 318 316 318 316 316 316 318 318 316 316 326 324 326 322 326 322 328 324 326 322 326 322 510 520 592 592 634 618 >>> 636 640 652 666 642 644 660 648 642 660 652 646 662 658 636 648 626 632 650 628 632 612 632 620 622 636 626 626 644 632 750 748 812 >>> 822 828 858 842 862 898 880 896 840 870 896 926 870 1034 846 880 834 876 824 860 818 848 824 826 864 820 848 820 828) "average asFloat >>> 536.109375". >>> #(166 174 168 174 170 176 168 172 166 172 164 170 166 170 166 172 166 170 166 172 166 172 166 170 166 170 164 170 170 170 168 176 164 >>> 170 166 172 166 172 164 174 166 170 168 172 166 172 166 172 166 170 164 170 166 172 164 172 166 172 166 170 238 272 264 484 282 344 >>> 284 356 292 362 294 364 288 362 292 366 294 368 290 364 294 374 294 374 296 370 294 374 288 370 290 366 290 368 292 364 302 382 304 >>> 388 302 390 298 392 298 384 302 388 302 390 298 386 308 398 304 400 504 402 298 402 298 398 302 398 294 400 298 396). "average asFloat >>> 259.359375" >>> >>> Levente >>> >>> On Sun, 30 Aug 2015, Chris Muller wrote: >>> >>> Hi Chris, I think these methods belong in the image with the fastest >>> implementation we can do. >>> >>> I implemented 64-bit unsigned access for Ma Serializer back in 2005. >>> I modeled my implementation after Andreas' original approach which >>> tries to avoid LI arithmetic. I was curious whether your >>> implementations would be faster, because if they are then it could >>> benefit Magma. After loading "Ma Serializer" 1.5 (or head) into a >>> trunk image, I used the following script to take comparison >>> measurements: >>> >>> | smallN largeN maBa cbBa | smallN := ((2 raisedTo: 13) to: (2 >>> raisedTo: 14)) atRandom. >>> largeN := ((2 raisedTo: 63) to: (2 raisedTo: 64)) atRandom. >>> maBa := ByteArray new: 8. >>> cbBa := ByteArray new: 8. >>> maBa maUint: 64 at: 0 put: largeN. >>> cbBa unsignedLong64At: 1 put: largeN bigEndian: false. >>> self assert: (cbBa maUnsigned64At: 1) = (maBa unsignedLong64At: 1 >>> bigEndian: false). >>> { 'cbc smallN write' -> [ cbBa unsignedLong64At: 1 put: smallN >>> bigEndian: false] bench. >>> 'ma smallN write' -> [cbBa maUint: 64 at: 0 put: smallN ] bench. >>> 'cbc smallN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false. ] bench. >>> 'ma smallN access' -> [ cbBa maUnsigned64At: 1] bench. >>> 'cbc largeN write' -> [ cbBa unsignedLong64At: 1 put: largeN >>> bigEndian: false] bench. >>> 'ma largeN write' -> [cbBa maUint: 64 at: 0 put: largeN ] bench. >>> 'cbc largeN access' -> [ cbBa unsignedLong64At: 1 bigEndian: false ] bench. >>> 'ma largeN access' -> [ cbBa maUnsigned64At: 1] bench. >>> } >>> >>> Here are the results: >>> >>> 'cbc smallN write'->'3,110,000 per second. 322 nanoseconds per run.' . >>> 'ma smallN write'->'4,770,000 per second. 210 nanoseconds per run.' . >>> 'cbc smallN access'->'4,300,000 per second. 233 nanoseconds per run.' . >>> 'ma smallN access'->'16,400,000 per second. 60.9 nanoseconds per run.' . >>> 'cbc largeN write'->'907,000 per second. 1.1 microseconds per run.' . >>> 'ma largeN write'->'6,620,000 per second. 151 nanoseconds per run.' . >>> 'cbc largeN access'->'1,900,000 per second. 527 nanoseconds per run.' . >>> 'ma largeN access'->'1,020,000 per second. 982 nanoseconds per run.' >>> >>> It looks like your 64-bit access is 86% faster for accessing the >>> high-end of the 64-bit range, but slower in the other 3 metrics. >>> Noticeably, it was only 14% as fast for writing the high-end of the >>> 64-bit range, and similarly as much slower for small-number access.. >>> >>> On Fri, Aug 28, 2015 at 6:01 PM, Chris Cunningham >>> wrote: >>> Hi. >>> >>> I've committed a change to the inbox with changes to allow getting/putting >>> 64bit values to ByteArrays (similar to 32 and 16 bit accessors). Could this >>> be added to trunk? >>> >>> Also, first time I used the selective commit function - very nice! the >>> changes I didn't want committed didn't, in fact, get commited. Just the >>> desirable bits! >>> >>> -cbc > From tim at rowledge.org Wed Sep 9 23:27:37 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 9 23:27:42 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <569392A5-A2F3-4179-BCE7-FAD646BAD8A3@mac.com> Message-ID: So after too much annoyance I finally found the stupid problem. It?s an object lesson in ?stupid things OSs do to people?. I?m sure somebody somewhere thought it was a good idea to scatter libraries around the place and then make it possible for applications to not know about all of them. The result is that you end up with shell scripts that try to work out what the library paths are and set environment variables and/or pass arguments along, often to yet another script. Eventually you get to some code in the application that has to look up something involving all this cruft and just have to hope it was all done reasonably well. And of course, no two *nix versions actually agree on what the paths should be. What a concept! Thus my situation today; a library lives in /usr/local/lib and I naively make another library and sit it next to that. After all, the first library works ok, right? No problem. But the damn scripts don?t actually do anything with this path, as I discovered after a tedious pair of debugging runs when the *working* library didn?t work. I happened upon looking at all the places where the module loading code seemed to peek. And lo! A link from one such place to the %$^ing /usr/local/lib/libwiringPi.so file. Sigh. Make a link for my new library and it actually loads. Mind you, it returns a Character instead of a Float, so something else is happening now. I still can?t work out how that link got there. I still can?t work out how the ldconfig cache-thingy doesn?t let the library load. I still can?t work out why RISC OS isn?t the normal OS. Thanks for the assorted suggestions! tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Ready to check in at the HaHa Hilton. From lewis at mail.msen.com Thu Sep 10 01:53:03 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Thu Sep 10 01:53:05 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> Message-ID: <20150910015303.GA58560@shell.msen.com> On Wed, Sep 09, 2015 at 11:17:08AM -0700, tim Rowledge wrote: > I?m trying - and so far failing - to do what should surely be a very simple > thing. This isn?t a new situation? especially on unix. > > I have a single C file with just two functions. I have a matching H file. > I want to make them into a dynamic library that I can call via FFI. This > really shouldn?t be rocket science stuff! I assume there is some good reason that you would not do an end run around all that rocket science and just write a plugin? After all, you are the person who wrote the excellent early papers on how to extend the VM with plugins, and most of what little I know of VMs came from reading your early work on the topic. I would hate to be the one to deny a masochist his private pleasures, but really, why not not just do it the easy way? Dave From brasspen at gmail.com Thu Sep 10 02:20:15 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Thu Sep 10 02:20:20 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <20150910015303.GA58560@shell.msen.com> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> Message-ID: <55F0E8DF.1040501@gmail.com> http://sdmeta.gforge.inria.fr/FreeBooks/CollectiveNBlueBook/greenberg.pdf Write it in Smalltalk: #reverseInPlaceFrom:to: | temp | 0 to: to - from // 2 do: [:index | temp ? self at: from + index. self at: from + index put: (self at: to-index). self at: to-index put: temp] Re-write it as Slang: #primReverseFromto self export: true. self var: #rcvr declareC: 'int *rcvr'. to ? interpreterProxy stackIntegerValue: 0. from ? interpreterProxy stackIntegerValue: 1. rcvrOop ? interpreterProxy stackObjectValue: 2. rcvr ? self cCoerce: (interpreterProxy firstIndexableField: rcvrOop) to: 'int *'. interpreterProxy success: (from >= 1 and: [from+1 <= to]). interpreterProxy success: (to <= (interpreterProxy stSizeOf: rcvrOop)). interpreterProxy failed ifTrue: [^nil]. rcvr ? rcvr - 1. "adjust for 1-based indexing." 0 to: to-from/2 do: [:index | t ? rcvr at: from + index. rcvr at: from + index put: (rcvr at: to-index). rcvr at: to-index put: t]. interpreterProxy pop: 3 thenPush: rcvrOop Or subclass the long lost TestCodeGenerator to do it for you! Chris For those of you watching at home, the article above has the HelloWorld of plugins. Igor changed is slightly for a lecture in 2011 to make a plugin called TheUniversalAnswer. It returns 42. #answerSeventeen self export: true. interpreterProxy pop: 1 thenPush: (interpreterProxy integerObjectOf: 17) All you need now is a compiling rig with two VMs and two images. The VM you start your VMMaker image with. The VM you compile from the VMMaker source you just generated. And the pristine target image you start with the VM you just compiled to prove it works. Your spiral into plugin compiling madness starts with this handy script: http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-October/166038.html On 2015-09-09 9:53 PM, David T. Lewis wrote: > On Wed, Sep 09, 2015 at 11:17:08AM -0700, tim Rowledge wrote: >> I?m trying - and so far failing - to do what should surely be a very simple >> thing. This isn?t a new situation? especially on unix. >> >> I have a single C file with just two functions. I have a matching H file. >> I want to make them into a dynamic library that I can call via FFI. This >> really shouldn?t be rocket science stuff! > > I assume there is some good reason that you would not do an end run > around all that rocket science and just write a plugin? After all, you > are the person who wrote the excellent early papers on how to extend the > VM with plugins, and most of what little I know of VMs came from reading > your early work on the topic. > > I would hate to be the one to deny a masochist his private pleasures, but > really, why not not just do it the easy way? > > > Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/4576e953/attachment.htm From cunningham.cb at gmail.com Thu Sep 10 03:45:52 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Thu Sep 10 03:45:55 2015 Subject: [squeak-dev] ByteArray accessors - questions about some of the accessors In-Reply-To: References: <4478.136.2.1.102.1441815437.squirrel@webmail.msen.com> Message-ID: On Wed, Sep 9, 2015 at 2:20 PM, Levente Uzonyi wrote: > These methods don't validate their arguments, just like most other > Smalltalk methods. I'm pretty sure the unsigned*put* methods would accept > LargeNegativeIntegers as input. The same applies to the signed methods with > larger than acceptable inputs (e.g. shortAt:put:bigEndian: will accept > 65535 and store it as if it were -1). > > > On Wed, 9 Sep 2015, David T. Lewis wrote: > > Hi Chris, >> >> I have not been following these updates too closely, but I can say without >> hesitation that using -1 as shorthand for 16rff or 16rffff (or whatever) >> in the context of unsigned integer fields would be a bad thing to do, and >> if our accessors are treating it as an error, then that is good. >> >> It might be good to document this in the form of unit tests that explain >> that the failure is intentional. >> >> Dave >> > So, I agree with Dave on this being a bad practice, and stop doing it. And his suggestion of documenting these in a form of tests makes sense, too. But first, what is the right test? Looking at the behavior of these ByteArray accessors both before and after tweaking them to make them fast, I'd like some consensus on what we want as an answer. There has been a slight change in the behavior of #longAt:put:bigEndian:, which is more consistent with the signed version, although I think I liked the old behavior better (and would prefer to have both versions change to mirror that behavior). Once this is set, then consistent tests can also be build for the new unsignedLong64At:put:bigEndian: method as well. Here is the (rather lengthy) examples: largeNegative := -16rFFFFFFFFFF. smallNegative := -16rF. largePositive := 16rFFFFFFFFFF. smallPositive := 16rF. largeNegative isLarge "==> true " smallPositive isLarge "==> false" largePositive isLarge "==> true" smallPositive isLarge "==> false" largeNegative < 0 "==> true" smallPositive < 0 "==> false" largePositive < 0 "==> false" smallPositive < 0 "==> false" ba := ByteArray new: 8. Prior to UL speed/clarity improvements: ------------------------------------------------------------ ba at: 1 put: smallPositive " ==> 15 " ba at: 1 put: smallNegative " ==> improper store - error" ba at: 1 put: largePositive " ==> improper store - error" ba at: 1 put: largeNegative " ==> improper store - error" ba shortAt: 1 put: smallPositive bigEndian: false " ==> 15 " ba shortAt: 1 put: smallNegative bigEndian: false " ==> -15 " ba shortAt: 1 put: largePositive bigEndian: false " ==> improper store - error" ba shortAt: 1 put: largeNegative bigEndian: false " ==> improper store - error" ba unsignedShortAt: 1 put: smallPositive bigEndian: false " ==> 15 " ba unsignedShortAt: 1 put: smallNegative bigEndian: false " ==> improper store - error" ba unsignedShortAt: 1 put: largePositive bigEndian: false " ==> improper store - error" ba unsignedShortAt: 1 put: largeNegative bigEndian: false " ==> improper store - error" ba longAt: 1 put: smallPositive bigEndian: false " ==> 15 " ba longAt: 1 put: smallNegative bigEndian: false " ==> -15 " ba longAt: 1 put: largePositive bigEndian: false " ==> 1099511627775" (ba longAt: 1 bigEndian: false) " ==> -1" largePositive digitLength " ==> 5" ba longAt: 1 put: largeNegative bigEndian: false " ==> -1099511627775" (ba longAt: 1 bigEndian: false) " ==> 1" largeNegative digitLength " ==> 5" ^^^ This is what the code did - which is not ideal. Picked digits out of the middle of a number and stored them! ba unsignedLongAt: 1 put: smallPositive bigEndian: false " ==> 15 " ba unsignedLongAt: 1 put: smallNegative bigEndian: false " ==> improper store - error" ba unsignedLongAt: 1 put: largePositive bigEndian: false " ==> improper store - error" ba unsignedLongAt: 1 put: largeNegative bigEndian: false " ==> improper store - error" After UL speed/clarity improvements: ------------------------------------------------------------ #at:put: did not change (untouched by UL) #shortAt:put:bigEndian: and #unsignedShortAt:put:bigEndian: work exactly as before #longAt:put:bigEndian: works exactly as before. #unsignedLongAt:put:bigEndian:, however, has changed behavior: ba unsignedLongAt: 1 put: smallPositive bigEndian: false " ==> 15 " ba unsignedLongAt: 1 put: smallNegative bigEndian: false " ==> improper store - error" ba unsignedLongAt: 1 put: largePositive bigEndian: false " ==> 1099511627775" ba unsignedLongAt: 1 put: largeNegative bigEndian: false " ==> -1099511627775" (ba unsignedLongAt: 1 bigEndian: false) " ==> 4294967295" largePositive digitLength " ==> 5" (ba unsignedLongAt: 1 bigEndian: false) " ==> 4294967295" largeNegative digitLength " ==> 5" I'd prefer to see both #longAt:put:bigEndian: and #unsignedLongAt:put:bigEndian: raise errors when the largeInteger has more than 5 digits - it should fail as it does for all the other cases. Note that once we switch to 64Bit VM/Image, I expect that these will fail as well (since they will use the SmallInteger branch of the code). -cbc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/c4a905cd/attachment.htm From commits at source.squeak.org Thu Sep 10 12:41:24 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 10 12:41:25 2015 Subject: [squeak-dev] The Trunk: Morphic-mt.1005.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1005.mcz ==================== Summary ==================== Name: Morphic-mt.1005 Author: mt Time: 10 September 2015, 2:40:42.838 pm UUID: d77f85b5-c861-d347-93c6-fb0bce9283b9 Ancestors: Morphic-mt.1004 Fixes a memory leak that occurs when handling drop events and an error occurs. Primarily, this is related to step messages holding strong references to their receivers. Stepping will only stop if #delete is called on a morph. =============== Diff against Morphic-mt.1004 =============== Item was changed: ----- Method: HandMorph>>dropMorph:event: (in category 'grabbing/dropping') ----- dropMorph: aMorph event: anEvent "Drop the given morph which was carried by the hand" | event dropped | (anEvent isMouseUp and:[aMorph shouldDropOnMouseUp not]) ifTrue:[^self]. "Note: For robustness in drag and drop handling we remove the morph BEFORE we drop him, but we keep his owner set to the hand. This prevents system lockups when there is a problem in drop handling (for example if there's an error in #wantsToBeDroppedInto:). THIS TECHNIQUE IS NOT RECOMMENDED FOR CASUAL USE." self privateRemove: aMorph. aMorph privateOwner: self. dropped := aMorph. (dropped hasProperty: #addedFlexAtGrab) ifTrue:[dropped := aMorph removeFlexShell]. event := DropEvent new setPosition: self position contents: dropped hand: self. + + [ "In case of an error, ensure that the morph-to-be-dropped will be disposed. Otherwise it may confuse garbage handler. See the sends of #privateRemove: and #privateOwner: above." + self sendEvent: event focus: nil. + event wasHandled ifFalse: [aMorph rejectDropMorphEvent: event] ] + ensure: [ aMorph owner == self ifTrue: [aMorph delete] ]. + - self sendEvent: event focus: nil. - event wasHandled ifFalse:[aMorph rejectDropMorphEvent: event]. - aMorph owner == self ifTrue:[aMorph delete]. self mouseOverHandler processMouseOver: anEvent.! From tim at rowledge.org Thu Sep 10 17:29:24 2015 From: tim at rowledge.org (tim Rowledge) Date: Thu Sep 10 17:29:28 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <20150910015303.GA58560@shell.msen.com> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> Message-ID: <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> On 09-09-2015, at 6:53 PM, David T. Lewis wrote: > On Wed, Sep 09, 2015 at 11:17:08AM -0700, tim Rowledge wrote: >> I?m trying - and so far failing - to do what should surely be a very simple >> thing. This isn?t a new situation? especially on unix. >> >> I have a single C file with just two functions. I have a matching H file. >> I want to make them into a dynamic library that I can call via FFI. This >> really shouldn?t be rocket science stuff! > > > I assume there is some good reason that you would not do an end run > around all that rocket science and just write a plugin? Well I *did* originally point out that there was probably a really stupid mistake in my process and that is pretty much it. In my defence I was in the midst of FFI-ing to multiple external libraries for assorted Pi add-on doohickeys and getting somewhat inured to the idea. But I think I may re-do it as a plugin today, not least because it seems that the ARM ffi interface has a problem with returning floats; they come back as Character null. I may not be a great IEEE floating point standard expert but that doesn?t seem quite right. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Not enough sense to come in out of the rain. From eliot.miranda at gmail.com Thu Sep 10 19:33:49 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Thu Sep 10 19:33:53 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> Message-ID: On Thu, Sep 10, 2015 at 10:29 AM, tim Rowledge wrote: > > On 09-09-2015, at 6:53 PM, David T. Lewis wrote: > > > On Wed, Sep 09, 2015 at 11:17:08AM -0700, tim Rowledge wrote: > >> I?m trying - and so far failing - to do what should surely be a very > simple > >> thing. This isn?t a new situation? especially on unix. > >> > >> I have a single C file with just two functions. I have a matching H > file. > >> I want to make them into a dynamic library that I can call via FFI. This > >> really shouldn?t be rocket science stuff! > > > > > > I assume there is some good reason that you would not do an end run > > around all that rocket science and just write a plugin? > > Well I *did* originally point out that there was probably a really stupid > mistake in my process and that is pretty much it. In my defence I was in > the midst of FFI-ing to multiple external libraries for assorted Pi add-on > doohickeys and getting somewhat inured to the idea. > > But I think I may re-do it as a plugin today, not least because it seems > that the ARM ffi interface has a problem with returning floats; they come > back as Character null. I may not be a great IEEE floating point standard > expert but that doesn?t seem quite right. > I'm sure this can be fixed. Have you talked to Doug McPherson? _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150910/5d2e3450/attachment.htm From commits at source.squeak.org Thu Sep 10 21:55:01 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 10 21:55:02 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150910215501.22649.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008961.html Name: Morphic-mt.1005 Ancestors: Morphic-mt.1004 Fixes a memory leak that occurs when handling drop events and an error occurs. Primarily, this is related to step messages holding strong references to their receivers. Stepping will only stop if #delete is called on a morph. ============================================= From tim at rowledge.org Fri Sep 11 01:55:55 2015 From: tim at rowledge.org (tim Rowledge) Date: Fri Sep 11 01:55:59 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> Message-ID: <2B51A8BA-8E28-4A6B-9F1A-679554EAB91F@rowledge.org> On 10-09-2015, at 12:33 PM, Eliot Miranda wrote: > But I think I may re-do it as a plugin today, not least because it seems that the ARM ffi interface has a problem with returning floats; they come back as Character null. I may not be a great IEEE floating point standard expert but that doesn?t seem quite right. > > I'm sure this can be fixed. Have you talked to Doug McPherson? Yup. And after much head-scratching because I?ve completely forgotten how plugin building works, I finally have a plugin that takes 9 float values, does unspeakable things to them and spits out a four float quaternion answer. On a Pi2 it test at ~ 8 micro-sec per call, which isn?t bad for 270+ floating point operations including 150 divides. The next fun is feeding live IMU data to it and finding away to display something meaningful as a result. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BOMB: Burn Out Memory Banks From lewis at mail.msen.com Fri Sep 11 02:29:30 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Sep 11 02:29:32 2015 Subject: [squeak-dev] Building a linux/Pi library to call via FFI In-Reply-To: <2B51A8BA-8E28-4A6B-9F1A-679554EAB91F@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <2B51A8BA-8E28-4A6B-9F1A-679554EAB91F@rowledge.org> Message-ID: <20150911022930.GA8120@shell.msen.com> On Thu, Sep 10, 2015 at 06:55:55PM -0700, tim Rowledge wrote: > > On 10-09-2015, at 12:33 PM, Eliot Miranda wrote: > > But I think I may re-do it as a plugin today, not least because it seems that the ARM ffi interface has a problem with returning floats; they come back as Character null. I may not be a great IEEE floating point standard expert but that doesn?t seem quite right. > > > > I'm sure this can be fixed. Have you talked to Doug McPherson? > > Yup. > > And after much head-scratching because I?ve completely forgotten how plugin building works, I finally have a plugin that takes 9 float values, does unspeakable things to them and spits out a four float quaternion answer. On a Pi2 it test at ~ 8 micro-sec per call, which isn?t bad for 270+ floating point operations including 150 divides. The next fun is feeding live IMU data to it and finding away to display something meaningful as a result. > Can you send a copy of your plugin as a fileout, change set, or mcz? I am expecting that you have one primitive with 9 double precision Float objects as parameters that are coerced to single precision floats and passed as parameters to MadgwickAHRSupdate(), which deposits the results into the q0, q1, q2, and q3 variables, which are coerced back to double precision Float objects and pushed back to the image as the result. Is that right? Thanks, Dave From casey.obrien.r at gmail.com Fri Sep 11 05:59:23 2015 From: casey.obrien.r at gmail.com (Casey Ransberger) Date: Fri Sep 11 05:59:29 2015 Subject: [squeak-dev] Squeak on iOS at last? Message-ID: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> When I heard that Apple was competing with Surface Pro I went looking for the only feature of the Surface Pro that I wanted in Apple's new tablet: side loading. It looks like Apple has dropped the $99 a year for not even necessarily selling anything on the App Store requirement. It's not exactly side-loading, because end users would still have to build the VM from C sources in Xcode before installing it, but it's something. The upshot is, since we can't ship via app-store, we can do a source distribution and get around the stupid App Store rules that hate us so. Thus, we don't have to rely on weird flaky crap like jailbreaks or have a guy paying for a dev account out of the goodness of his heart to distribute test keys for the system to those brave enough to run it without a proper touch interface. I may buy another iPad yet. Guessing most people familiar with the sitch are probably up to date, but for anyone who missed this detail, Casey to the rescue. http://9to5mac.com/2015/06/10/xcode-7-allows-anyone-to-download-build-and-sideload-ios-apps-for-free/ From nicolaihess at web.de Fri Sep 11 08:38:22 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Fri Sep 11 08:38:27 2015 Subject: [squeak-dev] Bugtracker maintainer Message-ID: anyone maintaining the bugtracker entries? I would like to close some issues (reported by me). btw should I continue reporting bugs to the bugtracker, or should I use the ML only? nicolai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150911/19efc5b9/attachment.htm From hannes.hirzel at gmail.com Fri Sep 11 08:45:52 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Fri Sep 11 08:45:56 2015 Subject: [squeak-dev] SqueakMap error -- display of installed packages Message-ID: Hello Error report: If in SqueakMap both options are ticked 'New safely available packages' 'Installed packages' nothing is shown. However if I only tick 'Installed packages' then the installed package is shown. So the selection is not cumulative. Regards Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: SqueakMap_Package_list_empty_error_condition.png Type: image/png Size: 43513 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150911/32abc4ea/SqueakMap_Package_list_empty_error_condition.png From frank.shearar at gmail.com Fri Sep 11 09:06:02 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Fri Sep 11 09:06:06 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: On 11 September 2015 at 09:38, Nicolai Hess wrote: > anyone maintaining the bugtracker entries? > I would like to close some issues (reported by me). Feel free to do so! > btw should I continue reporting bugs to the bugtracker, or should > I use the ML only? Please do continue to report issues to the bugtracker. frank > nicolai From frank.shearar at gmail.com Fri Sep 11 09:13:31 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Fri Sep 11 09:13:34 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets Message-ID: Mantis lets us configure default owners of tickets for various subprojects. It's a bit.... out of date. (A "default owner" of a subproject means that if you don't explicitly assign a ticket to someone, this is the person to whom you implicitly assign the ticket.) Any, Box-Admins both point to KenCausey, who must be tired of receiving the occasional mail on these topics. Here are our current mappings: Any: KenCausey Box-Admins: KenCausey CI: FrankShearar Documentation: casey Games: asm IRC: frankcag Monticello: avi News: gcorriga Release Packaging: FrankShearar SqueakMap: gokr ToDo: RalphJohnson Traits: dvf www.squeak.org: KarlRamberg I'm guessing they're so out of date because we tend not to use bugs.squeak.org very much (sadly). I'm happy to stay default owner on my subprojects, unless someone else would like to take the can. But certainly there are some projects that really ought to change owner. Being the default owner doesn't imply that you have to fix the bugs! It just means there's a clear point of contact: someone will definitely see the bug report because it lands in their mailbox. The traffic from being an owner is... minimal. As in "because almost no one uses the bugtracker you'll likely never see a mail" :) frank From nicolaihess at web.de Fri Sep 11 10:20:07 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Fri Sep 11 10:20:10 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: 2015-09-11 11:06 GMT+02:00 Frank Shearar : > On 11 September 2015 at 09:38, Nicolai Hess wrote: > > anyone maintaining the bugtracker entries? > > I would like to close some issues (reported by me). > > Feel free to do so! > If I only knew how. I can only open reports and add notes. > > > btw should I continue reporting bugs to the bugtracker, or should > > I use the ML only? > > Please do continue to report issues to the bugtracker. > > frank > > > nicolai > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150911/aef019cf/attachment.htm From nicolaihess at web.de Fri Sep 11 11:57:08 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Fri Sep 11 11:57:12 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: 2015-09-11 12:20 GMT+02:00 Nicolai Hess : > > > 2015-09-11 11:06 GMT+02:00 Frank Shearar : > >> On 11 September 2015 at 09:38, Nicolai Hess wrote: >> > anyone maintaining the bugtracker entries? >> > I would like to close some issues (reported by me). >> >> Feel free to do so! >> > > If I only knew how. I can only open reports and add notes. > > >> >> > btw should I continue reporting bugs to the bugtracker, or should >> > I use the ML only? >> >> Please do continue to report issues to the bugtracker. >> > BTW, we need a 5.0 for the "Product Version" ( Bugtracker->Report Issue -> Enter report details > >> frank >> >> > nicolai >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150911/42c3c22f/attachment-0001.htm From frank.shearar at gmail.com Fri Sep 11 12:27:55 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Fri Sep 11 12:27:57 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: On 11 September 2015 at 11:20, Nicolai Hess wrote: > > > 2015-09-11 11:06 GMT+02:00 Frank Shearar : >> >> On 11 September 2015 at 09:38, Nicolai Hess wrote: >> > anyone maintaining the bugtracker entries? >> > I would like to close some issues (reported by me). >> >> Feel free to do so! > > > If I only knew how. I can only open reports and add notes. You're now an Updater :) Let's see if that's sufficient. If not, let me know. Also, thanks for the heads-up re versions; I've added a 4.5 and a 5.0. (Broader note: if adding a new version to bugs.squeak.org isn't part of the documented release process, it should be.) frank >> > btw should I continue reporting bugs to the bugtracker, or should >> > I use the ML only? >> >> Please do continue to report issues to the bugtracker. >> >> frank >> >> > nicolai From brasspen at gmail.com Fri Sep 11 16:01:33 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Fri Sep 11 16:01:39 2015 Subject: [squeak-dev] Criteria For Plugin Compatibility Message-ID: <55F2FADD.1020608@gmail.com> I had the idea that a plugin from one VM could be dragged into another VM's directory and that it could be used just by starting up the image. I've done a little experimenting and it seems more of an idea of a reality. The functionality is there, but VM developers over the years have not seen this as a priority. Typically plugins and their VMs are compiled together. Or a person adds one by recompiling a VM compilation rig they already have. As I had a rig for the Interpreter VM I decided to compile a plugin and see if I could drag it around to other VM directories for use. Most times it didn't work. I compiled a TheUniversalAnswer plugin which returns 42. I moved it from a 4.14.1-3430 VM to a 4.14.1-3414 VM. I could get it to work if I did not use the squeak.sh start script. That is, I dragged so.vm-sound-null, so.TheUniversalAnswer and so.vm-display-X11 into the same directory as the VM binary. That worked. The only way to see the external plugins is with #listLoadedModules. But, irritatingly, modules are loaded as needed, so once you have proof of using the primitive from the plugin, yea, it will appear as a result of that Smalltalk listLoadedModules message. So, it's not that useful. I dragged so.TheUniversalAnswer around to other VMs such as 4.0.3-2202 and 4.13.10-3268 without success. And the unload selectors #forgetModule: and unloadModule:, which both use primitive 571 don't appear to work on my Ubuntu 15.04. So, I don't know if a community of plugins passed around is in the offing. What I have learned is that many of the answers are in sqUnixExternalPrims.c. The issues are really where does the VM look for primitives and what does it do when it finds one. It appears to me, after reading both the non-Cog and Cog versions of that file, that this an interesting area poorly documented that VM developers alter in haste to get on to something else. It's pretty important stuff, though. Do you start the VM with the binary on the path? Do you use squeak.sh? Where is the VM looking for stuff. Where will FFI look for stuff. And so on. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150911/659c4798/attachment.htm From asqueaker at gmail.com Fri Sep 11 16:22:52 2015 From: asqueaker at gmail.com (Chris Muller) Date: Fri Sep 11 16:22:54 2015 Subject: [squeak-dev] SqueakMap error -- display of installed packages In-Reply-To: References: Message-ID: Right, it looks like the filters form a conjunction. Probably intentional, but not necessarily what we still want today. SqueakMap client window could stand to be scrtuinized and improved. On Fri, Sep 11, 2015 at 3:45 AM, H. Hirzel wrote: > Hello > > Error report: > > If in SqueakMap both options are ticked > > 'New safely available packages' > 'Installed packages' > > nothing is shown. > > However if I only tick > 'Installed packages' > > then the installed package is shown. So the selection is not cumulative. > > > Regards > Hannes > > > From eliot.miranda at gmail.com Fri Sep 11 18:54:25 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Sep 11 18:54:27 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: References: Message-ID: Hi Frank, On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar wrote: > Mantis lets us configure default owners of tickets for various > subprojects. It's a bit.... out of date. (A "default owner" of a > subproject means that if you don't explicitly assign a ticket to > someone, this is the person to whom you implicitly assign the ticket.) > > Any, Box-Admins both point to KenCausey, who must be tired of > receiving the occasional mail on these topics. > > Here are our current mappings: > Any: KenCausey > Box-Admins: KenCausey > CI: FrankShearar > Documentation: casey > Games: asm > IRC: frankcag > Monticello: avi > News: gcorriga > Release Packaging: FrankShearar > SqueakMap: gokr > ToDo: RalphJohnson > Traits: dvf > www.squeak.org: KarlRamberg > I hope we could add VM and I could be an owner or Dave could be. > > I'm guessing they're so out of date because we tend not to use > bugs.squeak.org very much (sadly). > > I'm happy to stay default owner on my subprojects, unless someone else > would like to take the can. But certainly there are some projects that > really ought to change owner. > > Being the default owner doesn't imply that you have to fix the bugs! > It just means there's a clear point of contact: someone will > definitely see the bug report because it lands in their mailbox. > > The traffic from being an owner is... minimal. As in "because almost > no one uses the bugtracker you'll likely never see a mail" :) > > frank > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150911/87412241/attachment.htm From eliot.miranda at gmail.com Fri Sep 11 19:00:21 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri Sep 11 19:00:25 2015 Subject: [squeak-dev] Criteria For Plugin Compatibility In-Reply-To: <55F2FADD.1020608@gmail.com> References: <55F2FADD.1020608@gmail.com> Message-ID: Hi Chris, On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington wrote: > I had the idea that a plugin from one VM could be dragged into another > VM's directory and that it could be used just by starting up the image. > I've done a little experimenting and it seems more of an idea of a reality. > The functionality is there, but VM developers over the years have not seen > this as a priority. Typically plugins and their VMs are compiled together. > Or a person adds one by recompiling a VM compilation rig they already have. > The problems I see with this are a) a plugin compiled for Spur may not work with V3 or vice verse. The issue is the header size of an object. Some plugins, but not all, use this define, and the header sizes between Spur and V3 are incompatible. b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't work with 32-bit VMs. Period. Now there are platform-level packaging technologies, such as fat binaries on Mac OS X, that allow one to construct plugins that contain more than one binary. But this is a lot of work to build and maintain. So personally I wouldn't put much effort into this level of drag-and-drop compatibility. Instead I'd put energy into good error messages so that when plugins don't work the user can find out why, and that when the wrong kind of plugin is used the VM doesn't just stumble along, maybe producing incorrect results, but instead puts the plugin out with a comprehensible complaint. Does this make sense? I know its a downer, but what you propose is, IMO, not affordable given our resources. And I must say, *this is a VM-DEV discussion, not a general purpose Squeak discussion*, yes? As I had a rig for the Interpreter VM I decided to compile a plugin and see > if I could drag it around to other VM directories for use. Most times it > didn't work. > > I compiled a TheUniversalAnswer plugin which returns 42. I moved it from a > 4.14.1-3430 VM to a 4.14.1-3414 VM. I could get it to work if I did not use > the squeak.sh start script. That is, I dragged so.vm-sound-null, > so.TheUniversalAnswer and so.vm-display-X11 into the same directory as the > VM binary. That worked. > > The only way to see the external plugins is with #listLoadedModules. But, > irritatingly, modules are loaded as needed, so once you have proof of using > the primitive from the plugin, yea, it will appear as a result of that > Smalltalk listLoadedModules message. So, it's not that useful. > > I dragged so.TheUniversalAnswer around to other VMs such as 4.0.3-2202 and > 4.13.10-3268 without success. And the unload selectors #forgetModule: and > unloadModule:, which both use primitive 571 don't appear to work on my > Ubuntu 15.04. > > So, I don't know if a community of plugins passed around is in the offing. > What I have learned is that many of the answers are in > sqUnixExternalPrims.c. The issues are really where does the VM look for > primitives and what does it do when it finds one. It appears to me, after > reading both the non-Cog and Cog versions of that file, that this an > interesting area poorly documented that VM developers alter in haste to get > on to something else. > > It's pretty important stuff, though. Do you start the VM with the binary > on the path? Do you use squeak.sh? Where is the VM looking for stuff. Where > will FFI look for stuff. And so on. > > Chris > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150911/cae51a3c/attachment.htm From lewis at mail.msen.com Fri Sep 11 19:05:40 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Sep 11 19:05:42 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: References: Message-ID: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> Hi Eliot, I'm not sure how it's configured, but do we have a VM category, and the issues are getting automatically assigned to me. The Mantis tracker is quite helpful for VM issues that cannot be immediately resolved on the mailing lists. Dave > Hi Frank, > > On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar > wrote: > >> Mantis lets us configure default owners of tickets for various >> subprojects. It's a bit.... out of date. (A "default owner" of a >> subproject means that if you don't explicitly assign a ticket to >> someone, this is the person to whom you implicitly assign the ticket.) >> >> Any, Box-Admins both point to KenCausey, who must be tired of >> receiving the occasional mail on these topics. >> >> Here are our current mappings: >> Any: KenCausey >> Box-Admins: KenCausey >> CI: FrankShearar >> Documentation: casey >> Games: asm >> IRC: frankcag >> Monticello: avi >> News: gcorriga >> Release Packaging: FrankShearar >> SqueakMap: gokr >> ToDo: RalphJohnson >> Traits: dvf >> www.squeak.org: KarlRamberg >> > > I hope we could add VM and I could be an owner or Dave could be. > > >> >> I'm guessing they're so out of date because we tend not to use >> bugs.squeak.org very much (sadly). >> >> I'm happy to stay default owner on my subprojects, unless someone else >> would like to take the can. But certainly there are some projects that >> really ought to change owner. >> >> Being the default owner doesn't imply that you have to fix the bugs! >> It just means there's a clear point of contact: someone will >> definitely see the bug report because it lands in their mailbox. >> >> The traffic from being an owner is... minimal. As in "because almost >> no one uses the bugtracker you'll likely never see a mail" :) >> >> frank >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > > From lewis at mail.msen.com Fri Sep 11 19:16:27 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Fri Sep 11 19:16:36 2015 Subject: [Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility In-Reply-To: References: <55F2FADD.1020608@gmail.com> Message-ID: <45428.136.2.1.105.1441998987.squirrel@webmail.msen.com> Eliot, I agree. Indeed, even with an interpreter VM it has long been the case that a plugin compiled as 64 bit will not work on a VM compiled for 64 bit and vice versa. With the number of variations of 32/64, Spur/V3, and so forth, I don't think that this is a problem worth worrying about. Better to just be a aware that plugins are not readily interchangeable in those cases. Dave > Hi Chris, > > On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington > wrote: > >> I had the idea that a plugin from one VM could be dragged into another >> VM's directory and that it could be used just by starting up the image. >> I've done a little experimenting and it seems more of an idea of a >> reality. >> The functionality is there, but VM developers over the years have not >> seen >> this as a priority. Typically plugins and their VMs are compiled >> together. >> Or a person adds one by recompiling a VM compilation rig they already >> have. >> > > The problems I see with this are > > a) a plugin compiled for Spur may not work with V3 or vice verse. The > issue is the header size of an object. Some plugins, but not all, use > this > define, and the header sizes between Spur and V3 are incompatible. > > b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't > work > with 32-bit VMs. Period. > > Now there are platform-level packaging technologies, such as fat binaries > on Mac OS X, that allow one to construct plugins that contain more than > one > binary. But this is a lot of work to build and maintain. > > So personally I wouldn't put much effort into this level of drag-and-drop > compatibility. Instead I'd put energy into good error messages so that > when plugins don't work the user can find out why, and that when the wrong > kind of plugin is used the VM doesn't just stumble along, maybe producing > incorrect results, but instead puts the plugin out with a comprehensible > complaint. > > Does this make sense? I know its a downer, but what you propose is, IMO, > not affordable given our resources. > > > And I must say, *this is a VM-DEV discussion, not a general purpose Squeak > discussion*, yes? > > As I had a rig for the Interpreter VM I decided to compile a plugin and > see >> if I could drag it around to other VM directories for use. Most times it >> didn't work. >> >> I compiled a TheUniversalAnswer plugin which returns 42. I moved it from >> a >> 4.14.1-3430 VM to a 4.14.1-3414 VM. I could get it to work if I did not >> use >> the squeak.sh start script. That is, I dragged so.vm-sound-null, >> so.TheUniversalAnswer and so.vm-display-X11 into the same directory as >> the >> VM binary. That worked. >> >> The only way to see the external plugins is with #listLoadedModules. >> But, >> irritatingly, modules are loaded as needed, so once you have proof of >> using >> the primitive from the plugin, yea, it will appear as a result of that >> Smalltalk listLoadedModules message. So, it's not that useful. >> >> I dragged so.TheUniversalAnswer around to other VMs such as 4.0.3-2202 >> and >> 4.13.10-3268 without success. And the unload selectors #forgetModule: >> and >> unloadModule:, which both use primitive 571 don't appear to work on my >> Ubuntu 15.04. >> >> So, I don't know if a community of plugins passed around is in the >> offing. >> What I have learned is that many of the answers are in >> sqUnixExternalPrims.c. The issues are really where does the VM look for >> primitives and what does it do when it finds one. It appears to me, >> after >> reading both the non-Cog and Cog versions of that file, that this an >> interesting area poorly documented that VM developers alter in haste to >> get >> on to something else. >> >> It's pretty important stuff, though. Do you start the VM with the binary >> on the path? Do you use squeak.sh? Where is the VM looking for stuff. >> Where >> will FFI look for stuff. And so on. >> >> Chris >> >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > From tim at rowledge.org Fri Sep 11 19:18:41 2015 From: tim at rowledge.org (tim Rowledge) Date: Fri Sep 11 19:18:56 2015 Subject: [squeak-dev] Criteria For Plugin Compatibility In-Reply-To: References: <55F2FADD.1020608@gmail.com> Message-ID: On 11-09-2015, at 12:00 PM, Eliot Miranda wrote: > a) a plugin compiled for Spur may not work with V3 or vice verse. The issue is the header size of an object. Some plugins, but not all, use this define, and the header sizes between Spur and V3 are incompatible. > > b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't work with 32-bit VMs. Period. At the very least we should make sure the version checking that was designed specifically to help handle this is actually getting used properly. That ought to prevent crashes and help with providing some decent error messages. > > Now there are platform-level packaging technologies, such as fat binaries on Mac OS X, that allow one to construct plugins that contain more than one binary. But this is a lot of work to build and maintain. I suspect we could avoid that by using the versioning stuff to indicate which plugin file(s) the user/system fetches? As I (re)discovered this week, the unix vm plugin/library loading is amazingly convoluted and looks in more directories than I think my Pi actually has. And it uses the name you give it prepended with ?lib? and appended with ?.so? and ?dylib?, so searching for a plugin/lib involves an awful lot of checking and file testing. Looking in the platforms/unix/vm/sqUnixExternalPrims.c you can see what is being done. Note that ther eare two completely different approaches in that code and the Cog VM is using (so far as I can tell) the NOT USE_SIMPLIFIED_PLUGIN_LOGIC branch. The (somewhat old) copy of the plain interpreter VM equivalent I have around DOES use the simplified logic. We should probably clean that up... tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- AMICUS PURIAE - Platonic friend From commits at source.squeak.org Fri Sep 11 22:00:28 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 11 22:00:28 2015 Subject: [squeak-dev] The Trunk: EToys-cmm.131.mcz Message-ID: Chris Muller uploaded a new version of EToys to project The Trunk: http://source.squeak.org/trunk/EToys-cmm.131.mcz ==================== Summary ==================== Name: EToys-cmm.131 Author: cmm Time: 11 September 2015, 4:59:34.968 pm UUID: 94d94c4d-c84a-4e56-9697-3b550241e7f6 Ancestors: EToys-eem.130 Fix some preference accessing due to the recent change to Preferences class>>#doesNotUnderstand:. =============== Diff against EToys-eem.130 =============== Item was changed: ----- Method: Morph class>>additionsToViewerCategoryUserEvents (in category '*eToys-customevents-user events') ----- additionsToViewerCategoryUserEvents "Answer further viewer additions relating to user-defined events; these appear in the 'scripting' category" + ^ (Preferences valueOfFlag: #allowEtoyUserCustomEvents) - ^ Preferences allowEtoyUserCustomEvents ifTrue: [ #(scripting ( (command triggerCustomEvent: 'trigger a user-defined (global) event' CustomEvents) (slot triggeringObject 'the object that is triggering an event, either user-defined or pre-defined' Player readOnly Player getTriggeringObject unused unused)))] ifFalse: [#(scripting ())]! Item was changed: ----- Method: Morph>>enforceTileColorPolicy (in category '*Etoys-support') ----- enforceTileColorPolicy + (Preferences valueOfFlag: #coloredTilesEnabled) - Preferences coloredTilesEnabled ifTrue: [self makeAllTilesColored] ifFalse: [self makeAllTilesGreen]! Item was changed: ----- Method: Player>>getAllowEtoyUserCustomEvents (in category 'slot getters/setters') ----- getAllowEtoyUserCustomEvents "Answer whether to use the vector vocabulary." + ^ Preferences valueOfFlag: #allowEtoyUserCustomEvents! - ^ Preferences allowEtoyUserCustomEvents! Item was changed: ----- Method: ScriptInstantiation>>presentScriptStatusPopUp (in category 'customevents-status control') ----- presentScriptStatusPopUp "Put up a menu of status alternatives and carry out the request" | reply m menu submenu | menu := MenuMorph new. self addStatusChoices: #( normal " -- run when called" ) toMenu: menu. self addStatusChoices: #( paused "ready to run all the time" ticking "run all the time" ) toMenu: menu. self addStatusChoices: (ScriptingSystem standardEventStati copyFrom: 1 to: 3) toMenu: menu. self addStatusChoices: (ScriptingSystem standardEventStati allButFirst: 3) toMenu: menu. self addStatusChoices: #(opening "when I am being opened" closing "when I am being closed" ) toMenu: menu. submenu := MenuMorph new. self addStatusChoices: (ScriptingSystem globalCustomEventNamesFor: player) toSubMenu: submenu forMenu: menu. menu add: 'more... ' translated subMenu: submenu. + (Preferences valueOfFlag: #allowEtoyUserCustomEvents) ifTrue: [ - (Preferences allowEtoyUserCustomEvents) ifTrue: [ submenu addLine. self addStatusChoices: ScriptingSystem userCustomEventNames toSubMenu: submenu forMenu: menu. submenu addLine. self addStatusChoices: (Array streamContents: [ :s | s nextPut: { 'define a new custom event'. #defineNewEvent }. ScriptingSystem userCustomEventNames isEmpty ifFalse: [ s nextPut: { 'delete a custom event'. #deleteCustomEvent } ]]) toSubMenu: submenu forMenu: menu ]. menu addLine. self addStatusChoices: #( ('what do these mean?'explainStatusAlternatives) ('apply my status to all siblings' assignStatusToAllSiblings) ) toMenu: menu. menu addTitle: 'When should this script run?' translated. menu submorphs last delete. menu invokeModal. reply := menu modalSelection. reply == #explainStatusAlternatives ifTrue: [^ self explainStatusAlternatives]. reply == #assignStatusToAllSiblings ifTrue: [^ self assignStatusToAllSiblings]. reply == #defineNewEvent ifTrue: [ ^self defineNewEvent ]. reply == #deleteCustomEvent ifTrue: [ ^self deleteCustomEvent ]. reply ifNotNil: [self status: reply. "Gets event handlers fixed up" reply == #paused ifTrue: [m := player costume. (m isKindOf: SpeakerMorph) ifTrue: [m stopSound]]. self updateAllStatusMorphs] ! Item was changed: ----- Method: StandardScriptingSystem>>statusHelpStringFor: (in category '*Etoys-customevents-help dictionary') ----- statusHelpStringFor: aPlayer ^String streamContents: [ :stream | stream nextPutAll: 'normal -- run when called paused -- ready to run all the time ticking -- run all the time mouseDown -- run when mouse goes down on me mouseStillDown -- while mouse still down mouseUp -- when mouse comes back up mouseEnter -- when mouse enters my bounds, button up mouseLeave -- when mouse exits my bounds, button up mouseEnterDragging -- when mouse enters my bounds, button down mouseLeaveDragging -- when mouse exits my bounds, button down opening -- when I am being opened closing -- when I am being closed' translated. "'keyStroke -- run when user hits a key' " stream cr; cr; nextPutAll: 'More events:' translated; cr. (self customEventNamesAndHelpStringsFor: aPlayer) do: [ :array | stream cr; nextPutAll: array first; nextPutAll: ' -- '. array second do: [ :help | stream nextPutAll: help translated ] separatedBy: [ stream nextPutAll: ' or ' translated ]]. + (Preferences valueOfFlag: #allowEtoyUserCustomEvents) ifTrue: [ - (Preferences allowEtoyUserCustomEvents) ifTrue: [ self userCustomEventNames isEmpty ifFalse: [ stream cr; cr; nextPutAll: 'User custom events:' translated; cr. self currentWorld userCustomEventsRegistry keysAndValuesDo: [ :key :value | stream cr; nextPutAll: key; nextPutAll: ' -- '; nextPutAll: value ]]]]! From commits at source.squeak.org Fri Sep 11 22:06:24 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 11 22:06:25 2015 Subject: [squeak-dev] The Trunk: Protocols-cmm.50.mcz Message-ID: Chris Muller uploaded a new version of Protocols to project The Trunk: http://source.squeak.org/trunk/Protocols-cmm.50.mcz ==================== Summary ==================== Name: Protocols-cmm.50 Author: cmm Time: 11 September 2015, 5:06:16.322 pm UUID: 87f9e0ae-06a7-45f7-8887-20b1751cd251 Ancestors: Protocols-ul.49 Fix a preference access. =============== Diff against Protocols-ul.49 =============== Item was changed: ----- Method: Vocabulary class>>typeChoices (in category 'type vocabularies') ----- typeChoices "Answer a list of all user-choosable data types" | vocabulariesForType | vocabulariesForType := self allStandardVocabularies select: [:e | e representsAType]. + (Preferences valueOfFlag: #allowEtoyUserCustomEvents) ifFalse: [vocabulariesForType removeKey: #CustomEvents ifAbsent: []]. - Preferences allowEtoyUserCustomEvents ifFalse: [vocabulariesForType removeKey: #CustomEvents ifAbsent: []]. ^vocabulariesForType keys sort! From commits at source.squeak.org Fri Sep 11 23:14:20 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 11 23:14:22 2015 Subject: [squeak-dev] The Inbox: Collections-cbc.656.mcz Message-ID: A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-cbc.656.mcz ==================== Summary ==================== Name: Collections-cbc.656 Author: cbc Time: 11 September 2015, 4:14:08.929 pm UUID: 2dc0b8f9-096a-cc45-91cd-1236f24dff30 Ancestors: Collections-ul.655 Add signed 64bit putting to ByteArray. Not ready for merging yet - need 64bit reading as well. =============== Diff against Collections-ul.655 =============== Item was added: + ----- Method: ByteArray>>long64At:put:bigEndian: (in category 'platform independent access') ----- + long64At: index put: value bigEndian: bigEndian + "Store a 64-bit signed integer quantity starting from the given byte index" + | i j v | + value positive ifTrue: [^self unsignedLong64At: index put: value bigEndian: bigEndian]. + value isLarge ifTrue: [ + bigEndian ifFalse: [ + i := value digitLength. + j := 0. + [ j < i and: [ (v := ((value digitAt: j + 1) bitXor: 16rFF) + 1) = 16r100 ] ] whileTrue: [ + self at: index + j put: 0. + j := j + 1. ]. + self at: index + j put: v. + j := j + 1. + [ j < i ] whileTrue: [ self at: index + j put: ((value digitAt: (j := j + 1)) bitXor: 16rFF) ]. + ^value + ]. + "bigEndian == true" + j := value digitLength - 1. + [ 0 <= j and: [ (v := ((value digitAt: 4 - j) bitXor: 16rFF) + 1) = 16r100 ] ] whileTrue: [ + self at: index + j put: 0. + j := j= 1. ]. + self at: index + j put: v. + [ 0 <= (j := j - 1) ] whileTrue: [ self at: index + v put: ((value digitAt: 4 - 4) bitXor: 16rFF) ]. + ^value + ]. + "value is NOT large" + v := value bitShift: (-8 * (value digitLength - 1)). + 0 <= (v := (v bitAnd: 16r7F) - (v bitAnd: 16r80)) ifFalse: [ + v := v + 16r100 ]. + bigEndian ifFalse: [ + j := index - 1. + i := value. + 1 to: value digitLength - 1 do: [:x| + self at: (j := j + 1) put: (i bitAnd: 16rFF). + i := i bitShift: -8. + i <= 1 + ]. + self at: (j := j + 1) put: v. + self replaceFrom: j + 1 + to: index + 7 + with: #[ 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF ] + startingAt: 1. + ^value ]. + "bigEndian == true" + self at: index + 7 put: v. + j := index + 7. + i := value. + 1 to: value digitLength - 1 do: [:x| + self at: (j := j - 1) put: (i bitAnd: 16rFF). + i := i bitShift: -8 ]. + self replaceFrom: index + to: j - 1 + with: #[ 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF ] + startingAt: 1. + ^value! From tim at rowledge.org Sat Sep 12 02:01:57 2015 From: tim at rowledge.org (tim Rowledge) Date: Sat Sep 12 02:02:02 2015 Subject: [squeak-dev] SmalltalkInspect podcast #028 Message-ID: <7DC4C033-C82C-4B8D-BED6-4B7A233E1948@rowledge.org> Marten Feldtmann has put up the latest issue of the SmalltalkInspect, featuring yours truly waffling on about ARM/Pi/Cog/Scratch. http://smalltalkinspect.podspot.de/post/028-en-current-situation-smaltalk-under-piarm/ Hopefully I successfully managed to credit people that have contributed; if I failed to credit you, my apologies. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as his trigger finger tired. From lewis at mail.msen.com Sat Sep 12 02:57:40 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sat Sep 12 02:57:43 2015 Subject: [squeak-dev] SmalltalkInspect podcast #028 In-Reply-To: <7DC4C033-C82C-4B8D-BED6-4B7A233E1948@rowledge.org> References: <7DC4C033-C82C-4B8D-BED6-4B7A233E1948@rowledge.org> Message-ID: <20150912025740.GA55064@shell.msen.com> On Fri, Sep 11, 2015 at 07:01:57PM -0700, tim Rowledge wrote: > Marten Feldtmann has put up the latest issue of the SmalltalkInspect, featuring yours truly waffling on about ARM/Pi/Cog/Scratch. > http://smalltalkinspect.podspot.de/post/028-en-current-situation-smaltalk-under-piarm/ Great! Thanks for the link, really good podcast. So that reminds me ... it would be good if we could access the latest Scratch for Pi in a Montecello repository. Is that possible? I would really like to be able to open a new ScratchProject within a standard Squeak image. Dave From hannes.hirzel at gmail.com Sat Sep 12 13:47:57 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Sat Sep 12 13:48:00 2015 Subject: [squeak-dev] SqueakMap error -- display of installed packages In-Reply-To: References: Message-ID: The SqueakMap Package Loader window has as model an instance of SMLoaderPlus And this are the selectors of interest SMLoaderPlus>>filterInstalled ^[:package | package isInstalled] SMLoaderPlus>>filterSafelyAvailable ^[:package | package isSafelyAvailable] SMLoaderPlus has an instance variable called 'filters' which has as content an OrderedCollection(#filterInstalled #filterSafelyAvailable) for the case at hand, i.e. when both are selected. This instance variable is accessed by SMLoaderPlus >>packageListCalculated "Return a list of the SMPackages that should be visible by applying all the filters. Also filter based on the currently selected category - if any." ^ self packages select: [:p | filters allSatisfy: [:currFilter | currFilter isSymbol ifTrue: [(self perform: currFilter) value: p] ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]] #allSatisfy: is used which means that this is an 'and' operation. If it is replaced by #anySatisfy: it starts working as intended. On 9/11/15, Chris Muller wrote: > Right, it looks like the filters form a conjunction. Probably > intentional, but not necessarily what we still want today. SqueakMap > client window could stand to be scrtuinized and improved. > > On Fri, Sep 11, 2015 at 3:45 AM, H. Hirzel wrote: >> Hello >> >> Error report: >> >> If in SqueakMap both options are ticked >> >> 'New safely available packages' >> 'Installed packages' >> >> nothing is shown. >> >> However if I only tick >> 'Installed packages' >> >> then the installed package is shown. So the selection is not cumulative. >> >> >> Regards >> Hannes >> >> >> > > From karlramberg at gmail.com Sat Sep 12 18:43:42 2015 From: karlramberg at gmail.com (karl ramberg) Date: Sat Sep 12 18:43:44 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> References: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> Message-ID: These are all the categories on bugs.squeak.org. I'm not sure all have a default maintainer. But it is a huge list of mostly dead projects AST Aida Any Applescript BFAV BabySRE Balloon Balloon3D BitArray Box-Admins Browser Browser Booster CI Celeste Collections CommandShell Compiler Compression Connectors Cryptography DejaVu Fonts DictionaryBrowser Documentation Dr Geo DuoSystemBrowser Environments Etoys Exceptions ExternalWebBrowser FFI FileMan Files Folktale FractalMorph FreeType Plus GOODS Games Genie Glorp Graphics HTTPClient Hedgehog HelpSystem Hierarchy List Morph IRC IRCBot Installer Jabber Janitorial Jasmine Java Serialization Kabungu Kernel KernelImage KomHttpServer LanguageEditor LevelPlayingField Logic expressions MVC Magma Magritte Mantis MemoryUsage MinimalMorphic Monticello Morphic MorphicWrappers Movies Multilingual Mysql Driver Nebraska Network NewCompiler News Numerical Analysis ODBC OS-Acorn OS-Linux OS-Mac OS-Win32 OSProcess Obscure Bugs OmniBrowser OmniBrowser-Tools PackageInfo Pier PlusTools Polymorph PreferenceBrowser Prolog Refactoring Browser Release Packaging RemoteFrameBuffer Rio RoelTyper SARBuilder SARInstaller SPort ST80 SUnit SUnitGUI SVI Scamper Seaside Seaside AXAnnouncementsMenu Shout SmaCC SmallDEVS SmallWiki Sound Speech Squeak 64 bit Squeak-Dev SqueakMap SqueakSource StarBrowser Swazoo Swazoo-HTTP System TestBrowser ToDo ToolBuilder Tools Toothpick Traits TrueType Universes VBRegex VM Whisker Whisker++ WriteBarrier WxSqueak XML-Yaxo www.squeak.org any eCompletion Karl On Fri, Sep 11, 2015 at 9:05 PM, David T. Lewis wrote: > Hi Eliot, > > I'm not sure how it's configured, but do we have a VM category, and the > issues are getting automatically assigned to me. The Mantis tracker is > quite helpful for VM issues that cannot be immediately resolved on the > mailing lists. > > Dave > > > Hi Frank, > > > > On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar > > wrote: > > > >> Mantis lets us configure default owners of tickets for various > >> subprojects. It's a bit.... out of date. (A "default owner" of a > >> subproject means that if you don't explicitly assign a ticket to > >> someone, this is the person to whom you implicitly assign the ticket.) > >> > >> Any, Box-Admins both point to KenCausey, who must be tired of > >> receiving the occasional mail on these topics. > >> > >> Here are our current mappings: > >> Any: KenCausey > >> Box-Admins: KenCausey > >> CI: FrankShearar > >> Documentation: casey > >> Games: asm > >> IRC: frankcag > >> Monticello: avi > >> News: gcorriga > >> Release Packaging: FrankShearar > >> SqueakMap: gokr > >> ToDo: RalphJohnson > >> Traits: dvf > >> www.squeak.org: KarlRamberg > >> > > > > I hope we could add VM and I could be an owner or Dave could be. > > > > > >> > >> I'm guessing they're so out of date because we tend not to use > >> bugs.squeak.org very much (sadly). > >> > >> I'm happy to stay default owner on my subprojects, unless someone else > >> would like to take the can. But certainly there are some projects that > >> really ought to change owner. > >> > >> Being the default owner doesn't imply that you have to fix the bugs! > >> It just means there's a clear point of contact: someone will > >> definitely see the bug report because it lands in their mailbox. > >> > >> The traffic from being an owner is... minimal. As in "because almost > >> no one uses the bugtracker you'll likely never see a mail" :) > >> > >> frank > >> > >> > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150912/96870e48/attachment.htm From stephan at stack.nl Sat Sep 12 18:46:47 2015 From: stephan at stack.nl (Stephan Eggermont) Date: Sat Sep 12 18:46:56 2015 Subject: [squeak-dev] forum.world.st dead? Message-ID: Anyone know what's wrong with forum.world.st? Stephan From Das.Linux at gmx.de Sat Sep 12 18:57:12 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat Sep 12 18:57:16 2015 Subject: [squeak-dev] forum.world.st dead? In-Reply-To: References: Message-ID: <90B6EB2A-548F-4B1A-872A-4C61C20A6F3C@gmx.de> On 12.09.2015, at 20:46, Stephan Eggermont wrote: > Anyone know what's wrong with forum.world.st? I don't know? somehow the dns records are dead. Some Geert Claes has the domain registered (as I noted in the Slack) but does somebody actually know him (cause I don't)? Can someone contact him? Best regards -Tobias From commits at source.squeak.org Sat Sep 12 19:08:31 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sat Sep 12 19:08:32 2015 Subject: [squeak-dev] The Trunk: SMLoader-dtl.84.mcz Message-ID: David T. Lewis uploaded a new version of SMLoader to project The Trunk: http://source.squeak.org/trunk/SMLoader-dtl.84.mcz ==================== Summary ==================== Name: SMLoader-dtl.84 Author: dtl Time: 12 September 2015, 3:08:24.536 pm UUID: fdf44fdf-dad6-4d7e-9649-23df09a403c0 Ancestors: SMLoader-ul.83 Package loader fix by Hannes Hirzel. Explanation and fix provided on squeak-dev http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-September/185962.html The package loader should display 'New safely-available packages' OR 'Installed packages' (previously displayed AND of the selected categories) =============== Diff against SMLoader-ul.83 =============== Item was changed: ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') ----- packageListCalculated "Return a list of the SMPackages that should be visible by applying all the filters. Also filter based on the currently selected category - if any." ^ self packages select: [:p | + filters anySatisfy: [:currFilter | - filters allSatisfy: [:currFilter | currFilter isSymbol ifTrue: [(self perform: currFilter) value: p] ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]! From lewis at mail.msen.com Sat Sep 12 19:11:11 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sat Sep 12 19:11:14 2015 Subject: [squeak-dev] SqueakMap error -- display of installed packages In-Reply-To: References: Message-ID: <20150912191111.GA26124@shell.msen.com> On Sat, Sep 12, 2015 at 03:47:57PM +0200, H. Hirzel wrote: > The SqueakMap Package Loader window has as model an instance of SMLoaderPlus > > And this are the selectors of interest > > SMLoaderPlus>>filterInstalled > ^[:package | package isInstalled] > > SMLoaderPlus>>filterSafelyAvailable > ^[:package | package isSafelyAvailable] > > SMLoaderPlus has an instance variable called 'filters' which has as content > > an OrderedCollection(#filterInstalled #filterSafelyAvailable) > > for the case at hand, i.e. when both are selected. > > > This instance variable is accessed by > > SMLoaderPlus >>packageListCalculated > "Return a list of the SMPackages that should be visible > by applying all the filters. Also filter based on the currently > selected category - if any." > ^ self packages select: [:p | > filters allSatisfy: [:currFilter | > currFilter isSymbol > ifTrue: [(self perform: currFilter) value: p] > ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]] > > > > #allSatisfy: > > is used which means that this is an 'and' operation. > > > If it is replaced by > > #anySatisfy: > > it starts working as intended. Thank you for fixing this! I put your update into trunk. Dave > > > > On 9/11/15, Chris Muller wrote: > > Right, it looks like the filters form a conjunction. Probably > > intentional, but not necessarily what we still want today. SqueakMap > > client window could stand to be scrtuinized and improved. > > > > On Fri, Sep 11, 2015 at 3:45 AM, H. Hirzel wrote: > >> Hello > >> > >> Error report: > >> > >> If in SqueakMap both options are ticked > >> > >> 'New safely available packages' > >> 'Installed packages' > >> > >> nothing is shown. > >> > >> However if I only tick > >> 'Installed packages' > >> > >> then the installed package is shown. So the selection is not cumulative. > >> > >> > >> Regards > >> Hannes > >> > >> > >> > > > > From Das.Linux at gmx.de Sat Sep 12 20:19:41 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat Sep 12 20:19:48 2015 Subject: [squeak-dev] Fwd: Search for world.st admin ... References: Message-ID: > ---------- Forwarded message ---------- > From: Geert Claes > Date: 12 September 2015 at 17:40 > Subject: Search for world.st admin ... > > Hello Smalltalkers, > > I am looking for someone who would like to take over all admin duties for managing the world.st i.e. The World of Smalltalk and associated online forums. > > I have put in significant effort in setting it all up some years ago now, especially combining all varies mailing lists on Nabble under a common Smalltalk grouping was tedious. > > Anyhow, I do find myself less and less engaged with Smalltalk as I am too busy with other things. I reckon ideally it should be someone who is open to all Smalltalk dialects as the idea of world.st was to inform the world about every Smalltalk flavour. > > The administration doesn't require a lot of effort really. The website is at the moment a simple Google Site and all forums use Nabble and the DNS record are now directly with nic.st. Sean already kindly assists in keeping the Nabble forums clean of spammers but I would now like to hand over all admin duties completely. The world.st domain name is kindly sponsored by ESUG, so it doesn't cost anything to run really. > > I was recently forced to change DNS server for the second time since the start as there were some issues. Paul just kindly notified me that there are once again some issues with the web presence of world.st. > > Soo, candidates? Feel free to forward or post the following message on what you deem to be a relevant mailing lists. > > Cheers, > > Geert > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150912/1e084463/attachment-0001.htm From nicolaihess at web.de Sat Sep 12 20:24:18 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Sat Sep 12 20:24:22 2015 Subject: [squeak-dev] Re: [Vm-dev] Re: [Pharo-dev] Maintainer of FFI-Package In-Reply-To: References: <9C89D936-D2C5-4B6C-AF76-38488FF1EA61@gmail.com> Message-ID: 2014-09-28 22:04 GMT+02:00 Nicolai Hess : > Thank you David, > Thank you Eliot > > 2014-09-28 21:24 GMT+02:00 Eliot Miranda : > >> >> Hi Nicolai, >> >> On Sep 28, 2014, at 2:19 AM, Nicolai Hess wrote: >> >> > Who is the maintainer of the FFI-Package for >> > Squeak and/or Pharo ? >> >> I guess I'm the de facto maintainer because I'm the one who has changed >> things most recently, reimplementing the FFI plugin via the >> ThreadedFFIPlugin. >> >> >> > I especially interested in the FFI-Unix examples >> > and the state on working FFI on linux for current squeak release >> > (AFAIK it does not work with "squeak all in one" 4.5) >> >> Can you give me a reproducible case? I'd this with a Cog,Stack or >> Interpreter VM? Which specific things fail and how? >> > > Image > ----- > > /home/nicolai/Downloads/Squeak-4.5-All-in-One.app/Contents/Resources/Squeak4.5-13680.image > Squeak4.5 > latest update: #13680 > Current Change Set: Unnamed1 > Image format 6505 (32 bit) > > Virtual Machine > --------------- > > /home/nicolai/Downloads/Squeak-4.5-All-in-One.app/Contents/Linux-i686/lib/squeak/4.0-2776/squeak > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] > Unix built on Aug 22 2013 10:35:37 Compiler: 4.1.2 20080704 (Red Hat > 4.1.2-48) > platform sources revision VM: r2776 > http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins > CoInterpreter VMMaker.oscog-eem.331 uuid: > 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013 > StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: > 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013 > > Load > Name: FFI-Pools-eem.3 > Name: FFI-Kernel-eem.26 > Name: FFI-Tests-djm.7 > > Run FFI-Test -> 32 run, 24 passes, 0 expected failures, 0 failures, 8 > errors, 0 unexpected passes > > Load > Name: FFI-Unix-mtf.4 > > run X11Display class>>#coloredRectangles > -> Error: Could not coerse arguments > > Load newer cogvm > Virtual Machine > --------------- > > /media/Programs/squeak/Squeak-4.5-All-in-One.app/coglinux/lib/squeak/4.0-2987/squeak > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.746] > Unix built on Jun 11 2014 14:59:18 Compiler: 4.1.2 20080704 (Red Hat > 4.1.2-48) > platform sources revision VM: r2987 > http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2014-06-11 14:26:16 > -0700 Plugins: r2954 > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins > CoInterpreter VMMaker.oscog-eem.746 uuid: > cc4961d3-e629-4e28-b308-88eab314a8c9 Jun 11 2014 > StackToRegisterMappingCogit VMMaker.oscog-eem.766 uuid: > 3045c341-cfbf-494c-a7b1-fb29c26a7340 Jun 11 2014 > > Run FFI-Test -> 32 run, 32 passes, 0 expected failures, 0 failures, 0 > errors, 0 unexpected passes > > > The error in FFI-Unix is strange. The last package comment from > Name: FFI-Unix-mtf.4 > Author: mtf > is > "made the XLib examples actually work (Window is an unsigned int handle, > not a struct)" > > That the window is an int handle and not a struct explains why this > version replaces the parent class > of XDrawable from ExternalStructur to Object. But all calls with an > XDrawable still have this > object as parameter ( and not its instance var "xid"). I don't understand > how this ever > worked (or was there some kind of automatic argument conversion like: > transform an object with an instvar -> a int, if the function expects an > int handle?) > > Sure we can replace all XDrawable arguments in X11 calls from "aXDrawable" > to "aXDrawable xid". > But I only wonder, did this ever work and if Author "mtf" did the last > change, can I contact > him or is he still maintaining the FF-Unix examples? > > I would like to raise this topic again. Nothing has changed, the linux example still don't work and I can not get information about who maintains the unix-examples. >From my analysis (see above), the fix may be simple (in another discussion around that time some one else asked how to make that working, and confirmed it works with that fix). But I am confused because the latest update for the examples had the comment "made the XLib examlpes actually work". So maybe my usage or version of FFI is wrong. The last time I asked, someone said this works for him with the current stable vm, but it was actually the latest cog vm he used. But now, a year later, with the current 4.6 cog and 5.0 spur vm, some FFI unit tests still failing so maybe I am using the wrong FFI package (FFI-Kernel-EstebanLorenzano.27) ? (BTW, there is a typo in ExternalAddress class >> loadSymbol: moduleSymbol module: module ^ self primitiveFail it should call ^ self primitiveFailed > > > > >> > regards >> > Nicolai >> >> Eliot (phone) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150912/192c7337/attachment.htm From nicolaihess at web.de Sat Sep 12 20:51:20 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Sat Sep 12 20:51:22 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: 2015-09-11 11:06 GMT+02:00 Frank Shearar : > On 11 September 2015 at 09:38, Nicolai Hess wrote: > > anyone maintaining the bugtracker entries? > > I would like to close some issues (reported by me). > > Feel free to do so! > > > btw should I continue reporting bugs to the bugtracker, or should > > I use the ML only? > > Please do continue to report issues to the bugtracker. > Ok, but maybe I will send the reports to the ML as well. The last time I reported some issues on the bugtracker for the upcoming releases, they didn't not get much attentions. There were some issues reported for the 4.3 and 4.4 release and they are outdated now, as I am an "updater" now, I can close those myself, but two issues are reported for project "squeak website", can someone else close this issues please. Some time after the 4.4 (or 4.5?) release, I asked several times on the ML for the release plan for the VM, because I had some serious problems with getting FFI to work with the included VM (it was quite old), but I got no responds. And as the prerelease for 4.6 was announced, I asked if it has a squeak vm release candidate too, but again, I got no response. Is the Squeak release always only about the image? > > frank > > > nicolai > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150912/138875bf/attachment.htm From commits at source.squeak.org Sat Sep 12 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sat Sep 12 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150912215502.21752.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008962.html Name: EToys-cmm.131 Ancestors: EToys-eem.130 Fix some preference accessing due to the recent change to Preferences class>>#doesNotUnderstand:. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008963.html Name: Protocols-cmm.50 Ancestors: Protocols-ul.49 Fix a preference access. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008964.html Name: SMLoader-dtl.84 Ancestors: SMLoader-ul.83 Package loader fix by Hannes Hirzel. Explanation and fix provided on squeak-dev http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-September/185962.html The package loader should display 'New safely-available packages' OR 'Installed packages' (previously displayed AND of the selected categories) ============================================= From lewis at mail.msen.com Sat Sep 12 22:29:37 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sat Sep 12 22:29:39 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: <20150912222937.GB58421@shell.msen.com> On Sat, Sep 12, 2015 at 10:51:20PM +0200, Nicolai Hess wrote: > 2015-09-11 11:06 GMT+02:00 Frank Shearar : > > > On 11 September 2015 at 09:38, Nicolai Hess wrote: > > > anyone maintaining the bugtracker entries? > > > I would like to close some issues (reported by me). > > > > Feel free to do so! > > > > > btw should I continue reporting bugs to the bugtracker, or should > > > I use the ML only? > > > > Please do continue to report issues to the bugtracker. > > > > Ok, but maybe I will send the reports to the ML as well. The last time > I reported some issues on the bugtracker for the upcoming releases, > they didn't not get much attentions. I think you are right to do that. The bug tracker is important for issues that may not be easily resolved, or that may require the cooperation of several people for resolution. FFI problems tend to be like this, so documenting them on the bug tracker may be helpful both for you and for other people who encounter these issues. Reporting issues on the mailing lists is also good, especially if discussion is needed. So for issues such as FFI problems: Document this issue as well as you can on the bug tracker, and take it to the mailing list for discussion. Exactly as you have been doing. > There were some issues reported for the 4.3 and 4.4 release and they are > outdated now, > as I am an "updater" now, I can close those myself, but two issues are > reported > for project "squeak website", can someone else close this issues please. > > Some time after the 4.4 (or 4.5?) release, I asked several times on the ML > for > the release plan for the VM, because I had some serious problems with > getting > FFI to work with the included VM (it was quite old), but I got no responds. > And as the prerelease for 4.6 was announced, I asked if it has a squeak vm > release candidate too, > but again, I got no response. > Is the Squeak release always only about the image? As a general rule, yes. But in the case of Squeak 4.6/5.0, definitely no. Usually, a Squeak image should run on a range of VMs, and conversely, a VM is expected to be able to run a wide range of images. The Squeak 4.6 and 5.0 releases are different. Here we are making significant change to the actual object formats in the Squeak image, along with major changes in the VMs that take advantage of the new format. This requires a coordinated release of image and VM. You may expect additional changes of this nature as Squeak moves toward 64-bit images and VMs, so for perhaps the next year or so we should expect close coupling of released images with compatible VMs. Maybe after that we will settle back into a cadence in which image releases are relatively independent of VM versions. Dave From lewis at mail.msen.com Sun Sep 13 01:47:50 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sun Sep 13 01:47:53 2015 Subject: [squeak-dev] MadgwickAHRS plugin and support code (was: Building a linux/Pi library to call via FFI) In-Reply-To: <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> Message-ID: <20150913014750.GA98785@shell.msen.com> On Thu, Sep 10, 2015 at 10:29:24AM -0700, tim Rowledge wrote: > > On 09-09-2015, at 6:53 PM, David T. Lewis wrote: > > > On Wed, Sep 09, 2015 at 11:17:08AM -0700, tim Rowledge wrote: > >> I?m trying - and so far failing - to do what should surely be a very simple > >> thing. This isn?t a new situation? especially on unix. > >> > >> I have a single C file with just two functions. I have a matching H file. > >> I want to make them into a dynamic library that I can call via FFI. This > >> really shouldn?t be rocket science stuff! > > > > > > I assume there is some good reason that you would not do an end run > > around all that rocket science and just write a plugin? > > Well I *did* originally point out that there was probably a really stupid mistake in my process and that is pretty much it. In my defence I was in the midst of FFI-ing to multiple external libraries for assorted Pi add-on doohickeys and getting somewhat inured to the idea. > > But I think I may re-do it as a plugin today, not least because it seems that the ARM ffi interface has a problem with returning floats; they come back as Character null. I may not be a great IEEE floating point standard expert but that doesn?t seem quite right. > I don't know what got into me, but I brewed up a nice pot of coffee this morning and ended up with http://squeaksource.com/MadgwickAHRS/ This is a plugin, accessor class, and unit tests that claim to demonstrate that the plugin works. I used FloatArray for parameter passing, on the theory that users of the plugin may be doing float (not double) arithmetic, so it may be more efficient to pass values in that manner. It works with 32/64 bit image and host, and the plugin builds without complaint (trunk with Ian's Cmake build) if you put the library source files MadgwickAHRS.c and MadgwickAHRS.h in platforms/Cross/plugins/MadgwickAHRS/ The MadgwickAHRS library is licensed GPL, so it would be best to link the plugin dynamically to e.g. /usr/local/iib/libwmadgwickIMU.so.1 rather than static link to the C code as I have done so far. If there is any interest in the plugin, I'll see if I can figure out the linker magic. See class MadgwickAHRSTest for examples. Repository is at http://www.squeaksource.com/MadgwickAHRS Tim, I added you as developer on the squeaksource.com repository in case you want to make use of this. Dave From brasspen at gmail.com Sun Sep 13 03:18:16 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Sun Sep 13 03:18:19 2015 Subject: [squeak-dev] MadgwickAHRS plugin and support code (was: Building a linux/Pi library to call via FFI) In-Reply-To: <20150913014750.GA98785@shell.msen.com> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> Message-ID: Cool. I'm going to try this out. Chris On Sep 12, 2015 7:47 PM, "David T. Lewis" wrote: > On Thu, Sep 10, 2015 at 10:29:24AM -0700, tim Rowledge wrote: > > > > On 09-09-2015, at 6:53 PM, David T. Lewis wrote: > > > > > On Wed, Sep 09, 2015 at 11:17:08AM -0700, tim Rowledge wrote: > > >> I?m trying - and so far failing - to do what should surely be a very > simple > > >> thing. This isn?t a new situation? especially on unix. > > >> > > >> I have a single C file with just two functions. I have a matching H > file. > > >> I want to make them into a dynamic library that I can call via FFI. > This > > >> really shouldn?t be rocket science stuff! > > > > > > > > > I assume there is some good reason that you would not do an end run > > > around all that rocket science and just write a plugin? > > > > Well I *did* originally point out that there was probably a really > stupid mistake in my process and that is pretty much it. In my defence I > was in the midst of FFI-ing to multiple external libraries for assorted Pi > add-on doohickeys and getting somewhat inured to the idea. > > > > But I think I may re-do it as a plugin today, not least because it seems > that the ARM ffi interface has a problem with returning floats; they come > back as Character null. I may not be a great IEEE floating point standard > expert but that doesn?t seem quite right. > > > > I don't know what got into me, but I brewed up a nice pot of coffee this > morning and ended up with http://squeaksource.com/MadgwickAHRS/ > > This is a plugin, accessor class, and unit tests that claim to demonstrate > that the plugin works. > > I used FloatArray for parameter passing, on the theory that users of the > plugin may be doing float (not double) arithmetic, so it may be more > efficient to pass values in that manner. > > It works with 32/64 bit image and host, and the plugin builds without > complaint > (trunk with Ian's Cmake build) if you put the library source files > MadgwickAHRS.c and MadgwickAHRS.h in platforms/Cross/plugins/MadgwickAHRS/ > > The MadgwickAHRS library is licensed GPL, so it would be best to link > the plugin dynamically to e.g. /usr/local/iib/libwmadgwickIMU.so.1 > rather than static link to the C code as I have done so far. If there > is any interest in the plugin, I'll see if I can figure out the linker > magic. > > See class MadgwickAHRSTest for examples. > > Repository is at http://www.squeaksource.com/MadgwickAHRS > > Tim, I added you as developer on the squeaksource.com repository in case > you > want to make use of this. > > Dave > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150912/87b05571/attachment.htm From tim at rowledge.org Sun Sep 13 03:49:50 2015 From: tim at rowledge.org (tim Rowledge) Date: Sun Sep 13 03:49:56 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code (was: Building a linux/Pi library to call via FFI) In-Reply-To: <20150913014750.GA98785@shell.msen.com> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> Message-ID: On 12-09-2015, at 6:47 PM, David T. Lewis wrote: > I don't know what got into me, but I brewed up a nice pot of coffee this > morning and ended up with http://squeaksource.com/MadgwickAHRS/ > > This is a plugin, accessor class, and unit tests that claim to demonstrate > that the plugin works. > > I used FloatArray for parameter passing, on the theory that users of the > plugin may be doing float (not double) arithmetic, so it may be more > efficient to pass values in that manner. Cool! I did actually write one as well, but I used an array of BoxedFloat64 (or whatever it is) for input and create a 4 element array for the quaternion result. I considered a FloatArray as well but a) I?ve never used one before, so I?m scared of them b) Won?t they be arrays of 64bit float values on a 64-bit image? c) I?m pretty sure I will have to create a bunch of floats when reading the IMU chip anyway, so since I have them, might at well stick?em in an array. I did consider making the array 13 long so the result could be just appended. Might be worth trying? The good news is that on a Pi 2 the call as-is costs ~8micro-sec, which considering it apparently uses ~50 +, 60 -, 150 *, 14 / and 5 sqrt floating point calls is quite impressive. And yes, I suppose we?ll need to keep this as an external plugin to dodge the gnu-stasi. Sigh. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Same difference From lewis at mail.msen.com Sun Sep 13 04:31:58 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sun Sep 13 04:32:00 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code (was: Building a linux/Pi library to call via FFI) In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> Message-ID: <20150913043158.GA25812@shell.msen.com> On Sat, Sep 12, 2015 at 08:49:50PM -0700, tim Rowledge wrote: > > On 12-09-2015, at 6:47 PM, David T. Lewis wrote: > > I don't know what got into me, but I brewed up a nice pot of coffee this > > morning and ended up with http://squeaksource.com/MadgwickAHRS/ > > > > This is a plugin, accessor class, and unit tests that claim to demonstrate > > that the plugin works. > > > > I used FloatArray for parameter passing, on the theory that users of the > > plugin may be doing float (not double) arithmetic, so it may be more > > efficient to pass values in that manner. > > Cool! I did actually write one as well, but I used an array of BoxedFloat64 (or whatever it is) for input and create a 4 element array for the quaternion result. I considered a FloatArray as well but > a) I?ve never used one before, so I?m scared of them Well it's basically the only convenient way to deal with float (as opposed to double) floating point values. In Squeak, a Float is a C double, and AFIK the only thing that directly represents single precision floats is FloatArray. You would be justified in being scared of them, especially if any of this sounds like it makes sense. But it does work and it might be more efficient than arrays of Float (C doubles). Or maybe not, I don't have any way to measure it. But I tried to set things up so that the FloatArray things can be reused to avoid allocations and type conversions, so maybe it will help. > b) Won?t they be arrays of 64bit float values on a 64-bit image? On the 64 bit V3 image, no. For 64 bit Spur, I am not sure. But by definition I would expect FloatArray to contain single precision float values in any image format, so there is a good chance that it will work on 64 bit Spur also. I did test on 64 bit V3, and that passes the unit tests. > c) I?m pretty sure I will have to create a bunch of floats when reading the IMU chip anyway, so since I have them, might at well stick?em in an array. > I was mainly thinking of matching the parameters to MadgwickAHRSupdate(), which are single precision float. I don't know anything about IMU chips, so I don't have a clue if that is a good fit. And I had to look up "IMU" on Google, so that should give you an idea of my level of expertise. > I did consider making the array 13 long so the result could be just appended. Might be worth trying? > That would work also. I don't think there would be a performance difference either way, so whichever is easier to understand and document is probably good. > The good news is that on a Pi 2 the call as-is costs ~8micro-sec, which considering it apparently uses ~50 +, 60 -, 150 *, 14 / and 5 sqrt floating point calls is quite impressive. > > And yes, I suppose we?ll need to keep this as an external plugin to dodge the gnu-stasi. Sigh. > Building external is easy, not an issue. But I think we need to keep the GPL source code out of the platforms/Cross tree to prevent license confusion, so that means linking to an installed library rather than linking the GPL code directly into the plugin. That should not be a problem but I have not actually done it yet. Dave From herbertkoenig at gmx.net Sun Sep 13 11:34:32 2015 From: herbertkoenig at gmx.net (=?UTF-8?Q?Herbert_K=c3=b6nig?=) Date: Sun Sep 13 11:34:36 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code In-Reply-To: <20150913043158.GA25812@shell.msen.com> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> <20150913043158.GA25812@shell.msen.com> Message-ID: <55F55F48.3050009@gmx.net> Hi, Am 13.09.2015 um 06:31 schrieb David T. Lewis: > Well it's basically the only convenient way to deal with float (as > opposed to double) floating point values. In Squeak, a Float is a C > double, and AFIK the only thing that directly represents single > precision floats is FloatArray. You would be justified in being scared > of them, especially if any of this sounds like it makes sense. But it > does work and it might be more efficient than arrays of Float (C > doubles). Or maybe not, I don't have any way to measure it. But I > tried to set things up so that the FloatArray things can be reused to > avoid allocations and type conversions, so maybe it will help. FloatArray offers a lot of speed up as long as the operations provided by Float array are sufficient. Getting Squeak Floats into and out of Float Array is expensive. This: Time millisecondsToRun: [|array1 array2| array1 := (1.0 to: 10000.0 by: 0.1) asArray. array2 := (10000.0 to: 1.0 by: -0.1) asArray. 1000 timesRepeat: [|result| result := array1 * array2]] 22 seconds is not much slower than using FloatArray Time millisecondsToRun: [|array1 array2| array1 := (1.0 to: 10000.0 by: 0.1) asArray. array2 := (10000.0 to: 1.0 by: -0.1) asArray. 1000 timesRepeat: [|result| result := (array1 asFloatArray * array2 asFloatArray)]] 19 seconds If you change the last line to use more operations supported by FloatArray like: result := (array1 asFloatArray * array2 asFloatArray + 7.0 * 3.0) sum with FloatArrays you get the same speed, without the conversion to FloatArray it takes three times as long. If you need to use FloatArray>>at: and #at:put very often FloatArrays may get slower than Arrays of Float. So benchmark and benchmark again. And if your values get small, FloatArray may round them to zero which is bad for division. I used FloatArray a lot for Audio processing and neural networks but they need to be handled with care. I ended up using both depending on the algorithm. Cheers, Herbert From herbertkoenig at gmx.net Sun Sep 13 12:29:24 2015 From: herbertkoenig at gmx.net (=?UTF-8?Q?Herbert_K=c3=b6nig?=) Date: Sun Sep 13 12:29:26 2015 Subject: [squeak-dev] Get raw 24 Bit image data into a Form In-Reply-To: <2651B287-7CC9-4B15-9BA2-7BB378A8ACF9@rowledge.org> References: <55E1CC31.8020601@gmx.net> <55E31EF1.8010505@gmx.net> <2651B287-7CC9-4B15-9BA2-7BB378A8ACF9@rowledge.org> Message-ID: <55F56C24.5030300@gmx.net> Am 30.08.2015 um 20:04 schrieb tim Rowledge: > > As an example on my Pi2 - > sudo modprobe bcm2835-v4l2 > - to get the video4linux2 driver loaded > |frameForm| > (CameraPlugin cameraName: 1) ifNotNil: [|n frameExtent t| > (CameraPlugin openCamera: 1 width: 1296 height: 832) ifNotNil: [ > frameForm := Form extent: (CameraPlugin frameExtent: 1) depth: 32. > frameExtent := frameForm extent. > Delay waitMSecs: 400]. > t := Time millisecondsToRun: [n := CameraPlugin getFrameForCamera: 1 into: frameForm bits]. > CameraPlugin closeCamera: 1. > n = 0 ifTrue: [^ false]. > frameForm display. > t] I tucked that away. It seems very promising if I want to do other things with the camera like triggering on external sensors. As stated earlier in my current application I can live with bmp import and the camera's problems with bmp. I just wanted to make sure my camera board didn't degrade. Thanks, Herbert From eliot.miranda at gmail.com Sun Sep 13 14:57:02 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun Sep 13 14:57:13 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: Hi Nicolai, > On Sep 12, 2015, at 1:51 PM, Nicolai Hess wrote: > > > > 2015-09-11 11:06 GMT+02:00 Frank Shearar : >> On 11 September 2015 at 09:38, Nicolai Hess wrote: >> > anyone maintaining the bugtracker entries? >> > I would like to close some issues (reported by me). >> >> Feel free to do so! >> >> > btw should I continue reporting bugs to the bugtracker, or should >> > I use the ML only? >> >> Please do continue to report issues to the bugtracker. > > Ok, but maybe I will send the reports to the ML as well. The last time > I reported some issues on the bugtracker for the upcoming releases, > they didn't not get much attentions. > There were some issues reported for the 4.3 and 4.4 release and they are outdated now, > as I am an "updater" now, I can close those myself, but two issues are reported > for project "squeak website", can someone else close this issues please. > > Some time after the 4.4 (or 4.5?) release, I asked several times on the ML for > the release plan for the VM, because I had some serious problems with getting > FFI to work with the included VM (it was quite old), but I got no responds. I don't remember any traffic on vm-dev asking for this. > And as the prerelease for 4.6 was announced, I asked if it has a squeak vm release candidate too, > but again, I got no response. > Is the Squeak release always only about the image? On the contrary. This release, we released the Spur VM (squeak v5) which has a brand new object representation never before used in any system, and providing much better performance. The VM also includes SSL plugins compiled by Tobias Pape that are statically-linked against their cryptographic libraries. >> frank >> >> > nicolai Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150913/76e1e281/attachment.htm From btc at openinworld.com Sun Sep 13 15:23:37 2015 From: btc at openinworld.com (Ben Coman) Date: Sun Sep 13 15:23:59 2015 Subject: [squeak-dev] MadgwickAHRS plugin and support code (was: Building a linux/Pi library to call via FFI) In-Reply-To: <20150913014750.GA98785@shell.msen.com> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> Message-ID: On Sun, Sep 13, 2015 at 9:47 AM, David T. Lewis wrote: > On Thu, Sep 10, 2015 at 10:29:24AM -0700, tim Rowledge wrote: >> >> On 09-09-2015, at 6:53 PM, David T. Lewis wrote: >> >> > On Wed, Sep 09, 2015 at 11:17:08AM -0700, tim Rowledge wrote: >> >> I?m trying - and so far failing - to do what should surely be a very simple >> >> thing. This isn?t a new situation? especially on unix. >> >> >> >> I have a single C file with just two functions. I have a matching H file. >> >> I want to make them into a dynamic library that I can call via FFI. This >> >> really shouldn?t be rocket science stuff! >> > >> > >> > I assume there is some good reason that you would not do an end run >> > around all that rocket science and just write a plugin? >> >> Well I *did* originally point out that there was probably a really stupid mistake in my process and that is pretty much it. In my defence I was in the midst of FFI-ing to multiple external libraries for assorted Pi add-on doohickeys and getting somewhat inured to the idea. >> >> But I think I may re-do it as a plugin today, not least because it seems that the ARM ffi interface has a problem with returning floats; they come back as Character null. I may not be a great IEEE floating point standard expert but that doesn?t seem quite right. >> > > I don't know what got into me, but I brewed up a nice pot of coffee this > morning and ended up with http://squeaksource.com/MadgwickAHRS/ > > This is a plugin, accessor class, and unit tests that claim to demonstrate > that the plugin works. > > I used FloatArray for parameter passing, on the theory that users of the > plugin may be doing float (not double) arithmetic, so it may be more > efficient to pass values in that manner. > > It works with 32/64 bit image and host, and the plugin builds without complaint > (trunk with Ian's Cmake build) if you put the library source files > MadgwickAHRS.c and MadgwickAHRS.h in platforms/Cross/plugins/MadgwickAHRS/ > > The MadgwickAHRS library is licensed GPL, so it would be best to link > the plugin dynamically to e.g. /usr/local/iib/libwmadgwickIMU.so.1 > rather than static link to the C code as I have done so far. Unfortunately the distinction you make between static and dynamic linking is incorrect for GPL code [1][2], and true only for LGPL code. Now I notice that although [3] indicates the license is GPL, [3] points to original post [4] which was LGPL. A little confusing since neither [3] nor [4] state a license in the C source files. It seems [4] is the same author, so maybe its worth a polite query as to why the license changed from LGPL to GPL. [1] http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic [2] http://www.dwheeler.com/essays/floss-license-slide.html [3] http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/ [4] https://code.google.com/p/imumargalgorithm30042010sohm/ cheers -ben From tim at rowledge.org Sun Sep 13 16:46:04 2015 From: tim at rowledge.org (tim Rowledge) Date: Sun Sep 13 16:46:09 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code (was: Building a linux/Pi library to call via FFI) In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> <20150913043158.GA25812@shell.msen.com> Message-ID: <0702C367-B244-40E5-B78C-05E2552C5D54@rowledge.org> On 13-09-2015, at 8:26 AM, Ben Coman wrote: > Unfortunately the distinction you make between static and dynamic > linking is incorrect for GPL code [1][2], and true only for LGPL code. > > Now I notice that although [3] indicates the license is GPL, [3] > points to original post [4] which was LGPL. A little confusing since > neither [3] nor [4] state a license in the C source files. It seems > [4] is the same author, so maybe its worth a polite query as to why > the license changed from LGPL to GPL. > > [1] http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic > [2] http://www.dwheeler.com/essays/floss-license-slide.html > [3] http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms/ > [4] https://code.google.com/p/imumargalgorithm30042010sohm/ Ah, this brings back memories of arguing license for month after month?. To further confuse things, the madgwick code isn?t released as a library but rather just as some code to include in your own system. And the page for the c++ (hack, spit) version shows it as creative commons share-alike 3.0 And as an extra bit of excitement, I spotted a webpage where some corrections to the algorithm were mentioned along with a claim that the x-io site copies would be soon updated. Dating back at least a couple of years... tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- If his IQ was two points higher he'd be a rock. From eliot.miranda at gmail.com Sun Sep 13 17:41:06 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sun Sep 13 17:41:12 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: <20150912222937.GB58421@shell.msen.com> References: <20150912222937.GB58421@shell.msen.com> Message-ID: <7D282FE0-0D67-4128-BC39-2FBE6D567A79@gmail.com> > On Sep 12, 2015, at 3:29 PM, David T. Lewis wrote: > >> On Sat, Sep 12, 2015 at 10:51:20PM +0200, Nicolai Hess wrote: >> 2015-09-11 11:06 GMT+02:00 Frank Shearar : >> >>>> On 11 September 2015 at 09:38, Nicolai Hess wrote: >>>> anyone maintaining the bugtracker entries? >>>> I would like to close some issues (reported by me). >>> >>> Feel free to do so! >>> >>>> btw should I continue reporting bugs to the bugtracker, or should >>>> I use the ML only? >>> >>> Please do continue to report issues to the bugtracker. >> >> Ok, but maybe I will send the reports to the ML as well. The last time >> I reported some issues on the bugtracker for the upcoming releases, >> they didn't not get much attentions. > > I think you are right to do that. The bug tracker is important for issues > that may not be easily resolved, or that may require the cooperation of > several people for resolution. FFI problems tend to be like this, so > documenting them on the bug tracker may be helpful both for you and for > other people who encounter these issues. > > Reporting issues on the mailing lists is also good, especially if discussion > is needed. > > So for issues such as FFI problems: Document this issue as well as you can > on the bug tracker, and take it to the mailing list for discussion. Exactly > as you have been doing. +1, but the most important thing for me is a reproducible case, preferably an image that exhibits the bug in startup without needing my intervention (selecting doit etc). And it's nice to have the platform mentioned somewhere obvious. >> There were some issues reported for the 4.3 and 4.4 release and they are >> outdated now, >> as I am an "updater" now, I can close those myself, but two issues are >> reported >> for project "squeak website", can someone else close this issues please. >> >> Some time after the 4.4 (or 4.5?) release, I asked several times on the ML >> for >> the release plan for the VM, because I had some serious problems with >> getting >> FFI to work with the included VM (it was quite old), but I got no responds. >> And as the prerelease for 4.6 was announced, I asked if it has a squeak vm >> release candidate too, >> but again, I got no response. >> Is the Squeak release always only about the image? > > As a general rule, yes. But in the case of Squeak 4.6/5.0, definitely no. > > Usually, a Squeak image should run on a range of VMs, and conversely, a VM > is expected to be able to run a wide range of images. > > The Squeak 4.6 and 5.0 releases are different. Here we are making significant > change to the actual object formats in the Squeak image, along with major > changes in the VMs that take advantage of the new format. This requires a > coordinated release of image and VM. You may expect additional changes of this > nature as Squeak moves toward 64-bit images and VMs, so for perhaps the next > year or so we should expect close coupling of released images with compatible > VMs. Maybe after that we will settle back into a cadence in which image releases > are relatively independent of VM versions. +1. I think it's going to take a good few months for Spur to settle down. For example, properly fixing image segment loading just took a reworking of the segment load primitive to alter the segment word array so it answers the objects loaded. A number of new facilities (ephemerons, pinning) may cause a bug tail when people start really using them. It may be wise to plan on a maintenance release, say 5.1, which will aim to be more stable. > Dave > > From nicolaihess at web.de Sun Sep 13 19:42:47 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Sun Sep 13 19:42:50 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: 2015-09-11 14:27 GMT+02:00 Frank Shearar : > On 11 September 2015 at 11:20, Nicolai Hess wrote: > > > > > > 2015-09-11 11:06 GMT+02:00 Frank Shearar : > >> > >> On 11 September 2015 at 09:38, Nicolai Hess wrote: > >> > anyone maintaining the bugtracker entries? > >> > I would like to close some issues (reported by me). > >> > >> Feel free to do so! > > > > > > If I only knew how. I can only open reports and add notes. > > You're now an Updater :) Let's see if that's sufficient. If not, let me > know. > I can only update and close issues for the "Squeak" project, but I added some issues (some time ago) for others too (squeak website/squeak packages/VM) Can I become an updater for those projects too or should I mail the persons mainting that projects ? nicolai > > Also, thanks for the heads-up re versions; I've added a 4.5 and a 5.0. > > (Broader note: if adding a new version to bugs.squeak.org isn't part > of the documented release process, it should be.) > > frank > > >> > btw should I continue reporting bugs to the bugtracker, or should > >> > I use the ML only? > >> > >> Please do continue to report issues to the bugtracker. > >> > >> frank > >> > >> > nicolai > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150913/32b9e1ff/attachment.htm From lewis at mail.msen.com Sun Sep 13 20:18:23 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sun Sep 13 20:18:25 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code In-Reply-To: <55F55F48.3050009@gmx.net> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> <20150913043158.GA25812@shell.msen.com> <55F55F48.3050009@gmx.net> Message-ID: <20150913201823.GA84695@shell.msen.com> On Sun, Sep 13, 2015 at 01:34:32PM +0200, Herbert K??nig wrote: > Hi, > > Am 13.09.2015 um 06:31 schrieb David T. Lewis: > >Well it's basically the only convenient way to deal with float (as > >opposed to double) floating point values. In Squeak, a Float is a C > >double, and AFIK the only thing that directly represents single > >precision floats is FloatArray. You would be justified in being scared > >of them, especially if any of this sounds like it makes sense. But it > >does work and it might be more efficient than arrays of Float (C > >doubles). Or maybe not, I don't have any way to measure it. But I > >tried to set things up so that the FloatArray things can be reused to > >avoid allocations and type conversions, so maybe it will help. > > FloatArray offers a lot of speed up as long as the operations provided > by Float array are sufficient. Getting Squeak Floats into and out of > Float Array is expensive. > This: > Time millisecondsToRun: > [|array1 array2| > array1 := (1.0 to: 10000.0 by: 0.1) asArray. > array2 := (10000.0 to: 1.0 by: -0.1) asArray. > 1000 timesRepeat: [|result| > result := array1 * array2]] > 22 seconds > is not much slower than using FloatArray > Time millisecondsToRun: > [|array1 array2| > array1 := (1.0 to: 10000.0 by: 0.1) asArray. > array2 := (10000.0 to: 1.0 by: -0.1) asArray. > 1000 timesRepeat: [|result| > result := (array1 asFloatArray * array2 asFloatArray)]] > 19 seconds > If you change the last line to use more operations supported by > FloatArray like: > result := (array1 asFloatArray * array2 asFloatArray + 7.0 * > 3.0) sum > with FloatArrays you get the same speed, without the conversion to > FloatArray it takes three times as long. > > If you need to use FloatArray>>at: and #at:put very often FloatArrays > may get slower than Arrays of Float. > So benchmark and benchmark again. > > And if your values get small, FloatArray may round them to zero which is > bad for division. > > I used FloatArray a lot for Audio processing and neural networks but > they need to be handled with care. > I ended up using both depending on the algorithm. Herbert, Thanks, that is good to know. Indeed it might be faster to just use arrays of Float, and it might be worth trying both ways to see which is better. Dave From nicolaihess at web.de Sun Sep 13 20:23:42 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Sun Sep 13 20:23:45 2015 Subject: [squeak-dev] two small bugs (vm related) Message-ID: I am about to close some old mantis reports. There are two issues related to the vm and easy to solve ( I think). http://bugs.squeak.org/view.php?id=7265 0007265: Bug in Matrix2x3Plugin okayIntValue: Method okayIntValue: value uses argument to compare with lower bound, m23ResultX for upper bound. okayIntValue: value ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823 asFloat]) should be: okayIntValue: value ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat]) I looked at the Matrix2x3Plugin code, and the wrong comparsion is still there. http://bugs.squeak.org/view.php?id=7756 0007756: InputSensor>>cursorPoint: uses primitive 91 (primitiveTestDisplayDepth) Either we remove the code from InputSensor, or we add another new primitive for setting the mouse cursor. (Maybe we don't need this functionality or this is already possible with the hostwindow plugin?) nicolai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150913/117bc08a/attachment.htm From lewis at mail.msen.com Sun Sep 13 23:17:51 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sun Sep 13 23:17:55 2015 Subject: [squeak-dev] Mantis 0007265: Bug in Matrix2x3Plugin okayIntValue: (was: two small bugs (vm related)) In-Reply-To: References: Message-ID: <20150913231751.GA11523@shell.msen.com> On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote: > > I am about to close some old mantis reports. > > There are two issues related to the vm and easy to solve ( I think). > > http://bugs.squeak.org/view.php?id=7265 > > 0007265: Bug in Matrix2x3Plugin okayIntValue: > Method > okayIntValue: value > uses argument to compare with lower bound, m23ResultX for upper bound. > > okayIntValue: value > ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823 asFloat]) > > should be: > okayIntValue: value > ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat]) > > I looked at the Matrix2x3Plugin code, and the wrong comparsion > is still there. I am quite sure you are right about this, just from looking at the code. But I do want to check - the method is from ar 1998, so it has been in all the VMs for a very long time. How did you find the problem? Is there a test or an example that shows the issue? After fixing the method as you suggest, it will test for integer values with bit values in the range 11000000000000000000000000000000 through 00111111111111111111111111111111, which presumably maps to a range of acceptable values for use in the Matrix2x3Plugin floating point operations. So that looks quite reasonable, but I am puzzled that this check has been wrong since 1998, so that is why I ask. Thanks! Dave From lewis at mail.msen.com Sun Sep 13 23:37:56 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Sun Sep 13 23:37:58 2015 Subject: [squeak-dev] Mantis 0007756: InputSensor>>cursorPoint: uses primitive 91 (primitiveTestDisplayDepth) (was: two small bugs (vm related)) In-Reply-To: References: Message-ID: <20150913233756.GB11523@shell.msen.com> On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote: > > http://bugs.squeak.org/view.php?id=7756 > 0007756: InputSensor>>cursorPoint: uses primitive 91 > (primitiveTestDisplayDepth) > > Either we remove the code from InputSensor, or we add another > new primitive for setting the mouse cursor. > (Maybe we don't need this functionality or this is already possible with > the hostwindow plugin?) The primitive number assignments are set in #initializePrimitiveTable in the VM code (VMMaker package). This shows: (91 primitiveTestDisplayDepth) "Blue Book: primitiveCursorLocPut" So this tells me that primitive 91 was originally used for a primitive that set the cursor location, but that this primitive was abandoned a long time ago, and eventually someone decide to use 91 for a different purpose (testing display depth). That means that you are right in thinking that the InputSensor code is obsolete and should be removed or fixed. But I think that InputSensor itself has been replaced by EventSensor, and probably has no function in a modern Squeak image. It is referenced by class Controller (MVC) but the Sensor in an MVC project is an EventSensor, so I suspect that it may now be possible to remove InputSensor entirely. I have not actually tried this yet, but the test would be to remove InputSensor and all of the references to it, then see if MVC still works. Dave From geert.wl.claes at gmail.com Mon Sep 14 09:35:59 2015 From: geert.wl.claes at gmail.com (Geert Claes) Date: Mon Sep 14 09:43:12 2015 Subject: [squeak-dev] Re: forum.world.st dead? In-Reply-To: <90B6EB2A-548F-4B1A-872A-4C61C20A6F3C@gmx.de> References: <90B6EB2A-548F-4B1A-872A-4C61C20A6F3C@gmx.de> Message-ID: <1442223359846-4849956.post@n4.nabble.com> Back up. DNS issues -- View this message in context: http://forum.world.st/forum-world-st-dead-tp4849785p4849956.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From frank.shearar at gmail.com Mon Sep 14 10:01:34 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Mon Sep 14 10:01:37 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: On 13 September 2015 at 20:42, Nicolai Hess wrote: > > > 2015-09-11 14:27 GMT+02:00 Frank Shearar : >> >> On 11 September 2015 at 11:20, Nicolai Hess wrote: >> > >> > >> > 2015-09-11 11:06 GMT+02:00 Frank Shearar : >> >> >> >> On 11 September 2015 at 09:38, Nicolai Hess wrote: >> >> > anyone maintaining the bugtracker entries? >> >> > I would like to close some issues (reported by me). >> >> >> >> Feel free to do so! >> > >> > >> > If I only knew how. I can only open reports and add notes. >> >> You're now an Updater :) Let's see if that's sufficient. If not, let me >> know. > > > I can only update and close issues for the "Squeak" project, but I added > some > issues (some time ago) for others too (squeak website/squeak packages/VM) > > Can I become an updater for those projects too or should I mail the persons > mainting that projects ? All VM stuff _should_ be under the Squeak project. There are "Squeak Website" and "Squeak Packages" projects, but I have no idea how much they're used. I'm only a reporter on the projects anyway, so mailing people's your best bet. frank > nicolai > > >> >> >> Also, thanks for the heads-up re versions; I've added a 4.5 and a 5.0. >> >> (Broader note: if adding a new version to bugs.squeak.org isn't part >> of the documented release process, it should be.) >> >> frank >> >> >> > btw should I continue reporting bugs to the bugtracker, or should >> >> > I use the ML only? >> >> >> >> Please do continue to report issues to the bugtracker. >> >> >> >> frank >> >> >> >> > nicolai From frank.shearar at gmail.com Mon Sep 14 10:10:46 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Mon Sep 14 10:10:48 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> References: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> Message-ID: On 11 September 2015 at 20:05, David T. Lewis wrote: > Hi Eliot, > > I'm not sure how it's configured, but do we have a VM category, and the > issues are getting automatically assigned to me. The Mantis tracker is > quite helpful for VM issues that cannot be immediately resolved on the > mailing lists. My apologies for leaving you off the list, Dave. Indeed, we already have a VM category, and you are its default owner. frank > Dave > >> Hi Frank, >> >> On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar >> wrote: >> >>> Mantis lets us configure default owners of tickets for various >>> subprojects. It's a bit.... out of date. (A "default owner" of a >>> subproject means that if you don't explicitly assign a ticket to >>> someone, this is the person to whom you implicitly assign the ticket.) >>> >>> Any, Box-Admins both point to KenCausey, who must be tired of >>> receiving the occasional mail on these topics. >>> >>> Here are our current mappings: >>> Any: KenCausey >>> Box-Admins: KenCausey >>> CI: FrankShearar >>> Documentation: casey >>> Games: asm >>> IRC: frankcag >>> Monticello: avi >>> News: gcorriga >>> Release Packaging: FrankShearar >>> SqueakMap: gokr >>> ToDo: RalphJohnson >>> Traits: dvf >>> www.squeak.org: KarlRamberg >>> >> >> I hope we could add VM and I could be an owner or Dave could be. >> >> >>> >>> I'm guessing they're so out of date because we tend not to use >>> bugs.squeak.org very much (sadly). >>> >>> I'm happy to stay default owner on my subprojects, unless someone else >>> would like to take the can. But certainly there are some projects that >>> really ought to change owner. >>> >>> Being the default owner doesn't imply that you have to fix the bugs! >>> It just means there's a clear point of contact: someone will >>> definitely see the bug report because it lands in their mailbox. >>> >>> The traffic from being an owner is... minimal. As in "because almost >>> no one uses the bugtracker you'll likely never see a mail" :) >>> >>> frank >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> > > > From lists at fniephaus.com Mon Sep 14 10:17:35 2015 From: lists at fniephaus.com (Fabio Niephaus) Date: Mon Sep 14 10:17:47 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: References: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> Message-ID: Since I created and maintain the new Squeak website, feel free to list me as the owner. Best, Fabio On Mon 14 Sep 2015 at 12:10 Frank Shearar wrote: > On 11 September 2015 at 20:05, David T. Lewis wrote: > > Hi Eliot, > > > > I'm not sure how it's configured, but do we have a VM category, and the > > issues are getting automatically assigned to me. The Mantis tracker is > > quite helpful for VM issues that cannot be immediately resolved on the > > mailing lists. > > My apologies for leaving you off the list, Dave. Indeed, we already > have a VM category, and you are its default owner. > > frank > > > Dave > > > >> Hi Frank, > >> > >> On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar > > >> wrote: > >> > >>> Mantis lets us configure default owners of tickets for various > >>> subprojects. It's a bit.... out of date. (A "default owner" of a > >>> subproject means that if you don't explicitly assign a ticket to > >>> someone, this is the person to whom you implicitly assign the ticket.) > >>> > >>> Any, Box-Admins both point to KenCausey, who must be tired of > >>> receiving the occasional mail on these topics. > >>> > >>> Here are our current mappings: > >>> Any: KenCausey > >>> Box-Admins: KenCausey > >>> CI: FrankShearar > >>> Documentation: casey > >>> Games: asm > >>> IRC: frankcag > >>> Monticello: avi > >>> News: gcorriga > >>> Release Packaging: FrankShearar > >>> SqueakMap: gokr > >>> ToDo: RalphJohnson > >>> Traits: dvf > >>> www.squeak.org: KarlRamberg > >>> > >> > >> I hope we could add VM and I could be an owner or Dave could be. > >> > >> > >>> > >>> I'm guessing they're so out of date because we tend not to use > >>> bugs.squeak.org very much (sadly). > >>> > >>> I'm happy to stay default owner on my subprojects, unless someone else > >>> would like to take the can. But certainly there are some projects that > >>> really ought to change owner. > >>> > >>> Being the default owner doesn't imply that you have to fix the bugs! > >>> It just means there's a clear point of contact: someone will > >>> definitely see the bug report because it lands in their mailbox. > >>> > >>> The traffic from being an owner is... minimal. As in "because almost > >>> no one uses the bugtracker you'll likely never see a mail" :) > >>> > >>> frank > >>> > >>> > >> > >> > >> -- > >> _,,,^..^,,,_ > >> best, Eliot > >> > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/b03413a7/attachment.htm From nicolaihess at web.de Mon Sep 14 12:17:43 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Mon Sep 14 12:17:46 2015 Subject: [squeak-dev] Bugtracker maintainer In-Reply-To: References: Message-ID: 2015-09-14 12:01 GMT+02:00 Frank Shearar : > On 13 September 2015 at 20:42, Nicolai Hess wrote: > > > > > > 2015-09-11 14:27 GMT+02:00 Frank Shearar : > >> > >> On 11 September 2015 at 11:20, Nicolai Hess wrote: > >> > > >> > > >> > 2015-09-11 11:06 GMT+02:00 Frank Shearar : > >> >> > >> >> On 11 September 2015 at 09:38, Nicolai Hess > wrote: > >> >> > anyone maintaining the bugtracker entries? > >> >> > I would like to close some issues (reported by me). > >> >> > >> >> Feel free to do so! > >> > > >> > > >> > If I only knew how. I can only open reports and add notes. > >> > >> You're now an Updater :) Let's see if that's sufficient. If not, let me > >> know. > > > > > > I can only update and close issues for the "Squeak" project, but I added > > some > > issues (some time ago) for others too (squeak website/squeak packages/VM) > > > > Can I become an updater for those projects too or should I mail the > persons > > mainting that projects ? > > All VM stuff _should_ be under the Squeak project. > Ah, you are right. I can update the state of Squeak/VM-Issues > > frank > > > nicolai > > > > > >> > >> > >> Also, thanks for the heads-up re versions; I've added a 4.5 and a 5.0. > >> > >> (Broader note: if adding a new version to bugs.squeak.org isn't part > >> of the documented release process, it should be.) > >> > >> frank > >> > >> >> > btw should I continue reporting bugs to the bugtracker, or should > >> >> > I use the ML only? > >> >> > >> >> Please do continue to report issues to the bugtracker. > >> >> > >> >> frank > >> >> > >> >> > nicolai > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/bf6d3287/attachment.htm From cunningham.cb at gmail.com Mon Sep 14 15:58:42 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon Sep 14 15:58:44 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? Message-ID: Because I really, really need too change the color. I can't see where the error is - the 'highlight' color is so faint, it looks like nothing is highlighted at all. It makes tracking down where the error is really, really hard. I had a similar issue a few years ago with the Moose guys - they changed the sliders in the windows to be more aesthetically pleasing, but on some LCD monitors (notably, mine), the color is practically not there at all - like, apparently, this highlight color. Thanks, cbc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/55609c74/attachment.htm From karlramberg at gmail.com Mon Sep 14 17:39:57 2015 From: karlramberg at gmail.com (karl ramberg) Date: Mon Sep 14 17:39:59 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: WorldMenu/apperance/text highlight color Make sure transparency at the top bar in the color picker is set to more opaque Karl On Mon, Sep 14, 2015 at 5:58 PM, Chris Cunningham wrote: > Because I really, really need too change the color. I can't see where the > error is - the 'highlight' color is so faint, it looks like nothing is > highlighted at all. It makes tracking down where the error is really, > really hard. > > I had a similar issue a few years ago with the Moose guys - they changed > the sliders in the windows to be more aesthetically pleasing, but on some > LCD monitors (notably, mine), the color is practically not there at all - > like, apparently, this highlight color. > > Thanks, > cbc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/fed90d41/attachment.htm From cunningham.cb at gmail.com Mon Sep 14 17:58:21 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon Sep 14 17:58:24 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 923 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/9b660d87/image.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 1654 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/9b660d87/image-0001.png From eliot.miranda at gmail.com Mon Sep 14 21:07:14 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Sep 14 21:07:17 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code In-Reply-To: <55F55F48.3050009@gmx.net> References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> <20150913043158.GA25812@shell.msen.com> <55F55F48.3050009@gmx.net> Message-ID: Hi Herbert, On Sun, Sep 13, 2015 at 4:34 AM, Herbert K?nig wrote: > Hi, > > Am 13.09.2015 um 06:31 schrieb David T. Lewis: > >> Well it's basically the only convenient way to deal with float (as >> opposed to double) floating point values. In Squeak, a Float is a C double, >> and AFIK the only thing that directly represents single precision floats is >> FloatArray. You would be justified in being scared of them, especially if >> any of this sounds like it makes sense. But it does work and it might be >> more efficient than arrays of Float (C doubles). Or maybe not, I don't have >> any way to measure it. But I tried to set things up so that the FloatArray >> things can be reused to avoid allocations and type conversions, so maybe it >> will help. >> > > FloatArray offers a lot of speed up as long as the operations provided by > Float array are sufficient. Getting Squeak Floats into and out of Float > Array is expensive. > This: > Time millisecondsToRun: > [|array1 array2| > array1 := (1.0 to: 10000.0 by: 0.1) asArray. > array2 := (10000.0 to: 1.0 by: -0.1) asArray. > 1000 timesRepeat: [|result| > result := array1 * array2]] > 22 seconds > is not much slower than using FloatArray > Time millisecondsToRun: > [|array1 array2| > array1 := (1.0 to: 10000.0 by: 0.1) asArray. > array2 := (10000.0 to: 1.0 by: -0.1) asArray. > 1000 timesRepeat: [|result| > result := (array1 asFloatArray * array2 asFloatArray)]] > 19 seconds > If you change the last line to use more operations supported by FloatArray > like: > result := (array1 asFloatArray * array2 asFloatArray + 7.0 * 3.0) > sum > with FloatArrays you get the same speed, without the conversion to > FloatArray it takes three times as long. > > If you need to use FloatArray>>at: and #at:put very often FloatArrays may > get slower than Arrays of Float. > So benchmark and benchmark again. > That's right. Using FloatArray implies an object allocation on every at:, to construct the (boxed) Float result. 64-bit Spur will change this equation because most of the time the floats fetched will be immediate, instances of SmallFloat64. And indeed they may make it attractive to have a 64-bit float array type. > And if your values get small, FloatArray may round them to zero which is > bad for division. > > I used FloatArray a lot for Audio processing and neural networks but they > need to be handled with care. > I ended up using both depending on the algorithm. > > Cheers, > > Herbert > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/09bd1bbd/attachment.htm From leves at elte.hu Mon Sep 14 21:33:35 2015 From: leves at elte.hu (Levente Uzonyi) Date: Mon Sep 14 21:33:40 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> <20150913043158.GA25812@shell.msen.com> <55F55F48.3050009@gmx.net> Message-ID: We might as well have primitives which write their result into an object passed as parameter, or primitives which update the receiver, like the ones provided by KedamaFloatArray. But with SmallFloat64 being on the way, it's not that tempting to write such primitives. Levente On Mon, 14 Sep 2015, Eliot Miranda wrote: > Hi Herbert, > > On Sun, Sep 13, 2015 at 4:34 AM, Herbert K?nig wrote: > Hi, > > Am 13.09.2015 um 06:31 schrieb David T. Lewis: > Well it's basically the only convenient way to deal with float (as opposed to double) floating point values. In Squeak, a > Float is a C double, and AFIK the only thing that directly represents single precision floats is FloatArray. You would be > justified in being scared of them, especially if any of this sounds like it makes sense. But it does work and it might be > more efficient than arrays of Float (C doubles). Or maybe not, I don't have any way to measure it. But I tried to set > things up so that the FloatArray things can be reused to avoid allocations and type conversions, so maybe it will help. > > > FloatArray offers a lot of speed up as long as the operations provided by Float array are sufficient. Getting Squeak Floats into and > out of Float Array is expensive. > This: > Time millisecondsToRun: > ? ? [|array1 array2| > ? ? array1 := (1.0 to: 10000.0 by: 0.1) asArray. > ? ? array2 := (10000.0 to: 1.0 by: -0.1) asArray. > ? ? 1000 timesRepeat: [|result| > ? ? ? ? result := array1? * array2]] > 22 seconds > is not much slower than using FloatArray > Time millisecondsToRun: > ? ? [|array1 array2| > ? ? array1 := (1.0 to: 10000.0 by: 0.1) asArray. > ? ? array2 := (10000.0 to: 1.0 by: -0.1) asArray. > ? ? 1000 timesRepeat: [|result| > ? ? ? ? result := (array1 asFloatArray * array2 asFloatArray)]] > 19 seconds > If you change the last line to use more operations supported by FloatArray like: > ? ? ? ? result := (array1 asFloatArray * array2 asFloatArray + 7.0 * 3.0) sum > with FloatArrays you get the same speed, without the conversion to FloatArray it takes three times as long. > > If you need to use FloatArray>>at: and #at:put very often FloatArrays may get slower than Arrays of Float. > So benchmark and benchmark again. > > > That's right.? Using FloatArray implies an object allocation on every at:, to construct the (boxed) Float result. ?64-bit Spur will change this > equation because most of the time the floats fetched will be immediate, instances of SmallFloat64.? And indeed they may make it attractive to have > a 64-bit float array type. > > > And if your values get small, FloatArray may round them to zero which is bad for division. > > I used FloatArray a lot for? Audio processing and neural networks but they need to be handled with care. > I ended up using both depending on the algorithm. > > Cheers, > > Herbert > > > > > > > -- > _,,,^..^,,,_ > best,?Eliot > > From eliot.miranda at gmail.com Mon Sep 14 21:40:04 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Sep 14 21:40:07 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 923 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/638c944e/image.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 1654 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/638c944e/image-0001.png From craig at netjam.org Tue Sep 15 00:00:08 2015 From: craig at netjam.org (Craig Latta) Date: Tue Sep 15 00:00:25 2015 Subject: [squeak-dev] re: FFI callbacks In-Reply-To: <55EB1707.5090106@netjam.org> References: <55EB1707.5090106@netjam.org> Message-ID: Hi all-- I loaded Alien-eem.25 into Squeak 5.0.15110 on Mac OS 10.11.15A279b from the Monticello HTTP repository at [1]. I ran AlienSunit in the Test Runner, and it Squeak. Before I get into posting error logs, can anyone confirm that AlienSunit runs successfully on their machine, on any host platform, or that I shouldn't expect it to run successfully? Are there other Monticello packages I should be loading, and if so, in what order? thanks! -C [1] http://www.squeaksource.com/Alien -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From lewis at mail.msen.com Tue Sep 15 00:12:04 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Tue Sep 15 00:12:06 2015 Subject: [squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code In-Reply-To: References: <05549645-393D-4B85-A8F1-94520E56660B@rowledge.org> <20150910015303.GA58560@shell.msen.com> <7E032E10-BC7B-4E8F-81F8-BE309C703A43@rowledge.org> <20150913014750.GA98785@shell.msen.com> <20150913043158.GA25812@shell.msen.com> <55F55F48.3050009@gmx.net> Message-ID: <20150915001204.GA90079@shell.msen.com> On Mon, Sep 14, 2015 at 11:33:35PM +0200, Levente Uzonyi wrote: > We might as well have primitives which write their result into an object > passed as parameter, or primitives which update the receiver, like the > ones provided by KedamaFloatArray. But with SmallFloat64 being on the way, > it's not that tempting to write such primitives. > > Levente Actually, that is exactly what I did. The caller provides a pre-allocated (and potentially reusable) FloatArray of size 4, and the primitive copies four result values into the array fields. There is no need for allocating Float objects within the primitive, and no need to convert float to double in the primitive. This may or may not be useful depending on how the primitive is used, but it does allow the user an opportunity to optimize both by reusing an existing FloatArray instance for the results, and by allocating new Float object only if and when the elements of that array are actually read and used. I would expect that FloatArray will still have 32-bit float values in a 64-bit object memory, after all that is what it was designed to do. The need to allocate Float objects and do conversion from single to double floats should go away with 64-bits, so that should be a win. I expect that updates for MadgwickAHRSPlugin should be minimal. Dave > > On Mon, 14 Sep 2015, Eliot Miranda wrote: > > >Hi Herbert, > > > >On Sun, Sep 13, 2015 at 4:34 AM, Herbert K??nig > >wrote: > > Hi, > > > > Am 13.09.2015 um 06:31 schrieb David T. Lewis: > > Well it's basically the only convenient way to deal with float > > (as opposed to double) floating point values. In Squeak, a > > Float is a C double, and AFIK the only thing that directly > > represents single precision floats is FloatArray. You would be > > justified in being scared of them, especially if any of this > > sounds like it makes sense. But it does work and it might be > > more efficient than arrays of Float (C doubles). Or maybe not, > > I don't have any way to measure it. But I tried to set > > things up so that the FloatArray things can be reused to avoid > > allocations and type conversions, so maybe it will help. > > > > > > FloatArray offers a lot of speed up as long as the operations > > provided by Float array are sufficient. Getting Squeak Floats into > > and > > out of Float Array is expensive. > > This: > > Time millisecondsToRun: > > ?? ?? [|array1 array2| > > ?? ?? array1 := (1.0 to: 10000.0 by: 0.1) asArray. > > ?? ?? array2 := (10000.0 to: 1.0 by: -0.1) asArray. > > ?? ?? 1000 timesRepeat: [|result| > > ?? ?? ?? ?? result := array1?? * array2]] > > 22 seconds > > is not much slower than using FloatArray > > Time millisecondsToRun: > > ?? ?? [|array1 array2| > > ?? ?? array1 := (1.0 to: 10000.0 by: 0.1) asArray. > > ?? ?? array2 := (10000.0 to: 1.0 by: -0.1) asArray. > > ?? ?? 1000 timesRepeat: [|result| > > ?? ?? ?? ?? result := (array1 asFloatArray * array2 asFloatArray)]] > > 19 seconds > > If you change the last line to use more operations supported by > > FloatArray like: > > ?? ?? ?? ?? result := (array1 asFloatArray * array2 asFloatArray + > > 7.0 * 3.0) sum > > with FloatArrays you get the same speed, without the conversion to > > FloatArray it takes three times as long. > > > > If you need to use FloatArray>>at: and #at:put very often > > FloatArrays may get slower than Arrays of Float. > > So benchmark and benchmark again. > > > > > >That's right.?? Using FloatArray implies an object allocation on every > >at:, to construct the (boxed) Float result. ??64-bit Spur will change this > >equation because most of the time the floats fetched will be immediate, > >instances of SmallFloat64.?? And indeed they may make it attractive to have > >a 64-bit float array type. > > > > > > And if your values get small, FloatArray may round them to zero > > which is bad for division. > > > > I used FloatArray a lot for?? Audio processing and neural networks > > but they need to be handled with care. > > I ended up using both depending on the algorithm. > > > > Cheers, > > > > Herbert > > > > > > > > > > > > > >-- > >_,,,^..^,,,_ > >best,??Eliot > > > > > From eliot.miranda at gmail.com Tue Sep 15 00:18:23 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 15 00:18:28 2015 Subject: [squeak-dev] re: FFI callbacks In-Reply-To: References: <55EB1707.5090106@netjam.org> Message-ID: Hi Craig, On Mon, Sep 14, 2015 at 5:00 PM, Craig Latta wrote: > > Hi all-- > > I loaded Alien-eem.25 into Squeak 5.0.15110 on Mac OS 10.11.15A279b > from the Monticello HTTP repository at [1]. I ran AlienSunit in the Test > Runner, and it Squeak. Before I get into posting error logs, can anyone > confirm that AlienSunit runs successfully on their machine, on any host > platform, or that I shouldn't expect it to run successfully? Are there > other Monticello packages I should be loading, and if so, in what order? > I get 15 passes and one failure, that being testLongLong. But that's in my VMMaker image, which has some extras in it. AFAIA tough Alien should just work. I'll look at the testLongLong failure soon cuz I'm starting on the x64 JIT and that requires the above to work to access the processor alien. > > > thanks! > > -C > > [1] http://www.squeaksource.com/Alien > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/7f5dd2e2/attachment-0001.htm From craig at netjam.org Tue Sep 15 00:34:52 2015 From: craig at netjam.org (Craig Latta) Date: Tue Sep 15 00:35:06 2015 Subject: [squeak-dev] re: FFI callbacks In-Reply-To: References: <55EB1707.5090106@netjam.org> Message-ID: Hi Eliot-- > > I loaded Alien-eem.25 into Squeak 5.0.15110 on Mac OS 10.11.15A279b > > from the Monticello HTTP repository at [1]. I ran AlienSunit in the > > Test Runner, and it crashed Squeak. Before I get into posting error > > logs, can anyone confirm that AlienSunit runs successfully on their > > machine, on any host platform, or that I shouldn't expect it to run > > successfully? Are there other Monticello packages I should be > > loading, and if so, in what order? > > I get 15 passes and one failure, that being testLongLong. But that's > in my VMMaker image, which has some extras in it. AFAIA tough Alien > should just work. I'll look at the testLongLong failure soon cuz I'm > starting on the x64 JIT and that requires the above to work to access > the processor alien. Would you please try with the current Squeak 5 release? Also, is it feasible to make FFI calls to a 64-bit C library? thanks again! -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From eliot.miranda at gmail.com Tue Sep 15 01:08:25 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 15 01:08:29 2015 Subject: [squeak-dev] Re: [Pharo-dev] Array literal changes of a compiled method In-Reply-To: References: Message-ID: Hi Juraj, On Mon, Sep 14, 2015 at 4:56 PM, Juraj Kubelka wrote: > Hi, > > I have a test case like that: > -=-=- > testIncrementBy > prefix := MyObject new numbers: #(1 10); yourself. > prefix incrementBy: 10. > self assert: prefix numbers equals: #(1 20). > -=-=- > > and the byte code starts like that: > -=-=- > 57 <40> pushLit: MyObject > 58 send: new > 59 <88> dup > 60 <21> pushConstant: #(1 10) > -=-=- > > If I run the test case, it is green, but the byte code changes into: > -=-=- > 57 <40> pushLit: MyObject > 58 send: new > 59 <88> dup > 60 <21> pushConstant: #(1 *20*) > -=-=- > > The #incrementBy: method looks like: > -=-=- > incrementBy: aNumber > numbers at: 2 put: (numbers at: 2) + aNumber > -=-=- > > Is it correct that it also changes the method byte code? > No, ut this does happen. hat I suspect you're seeing is the fact that in the Pharo and Squeak implementations, literals are not immutable. So if you were to assign to a literal Array in a method's literals that assignment would not cause an error, and worse, would not be visible because the mehtods source code would be unchanged. We shall have a proper fix for this in a future release where we will support fully immutable literals. For now the correct respponse shoudl be to find out where in your code the literal is assigned to and to not do that. Of course adding a copy is also fine. > I can put "#(1 10) copy? into the test case. > I am just curious if it is a feature or bug. > It's a bug, but an ancient one. Some Smalltalks, such as VisualAge and VisualWorks have fixed this by introducing support for immutable objects, but the {haro/Squeak Vms have yet to provide this. I expect to implement it in Spur some time next year. > > Tested in Pharo4.0, Latest update: #40613. > > Cheers, > Juraj > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/d0b3c435/attachment.htm From lewis at mail.msen.com Tue Sep 15 01:19:25 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Tue Sep 15 01:19:28 2015 Subject: [squeak-dev] re: FFI callbacks In-Reply-To: References: <55EB1707.5090106@netjam.org> Message-ID: <20150915011925.GB90079@shell.msen.com> On Tue, Sep 15, 2015 at 02:34:52AM +0200, Craig Latta wrote: > > Also, is it feasible to make FFI calls to a 64-bit C library? > I got 64-bit FFI working about five years ago but we never got it merged into the VM (sorry). See http://bugs.squeak.org/view.php?id=7237 Those patches would be pretty badly bit-rotted by now, so I'm not sure of the current state of affairs. I would anticipate a few issues, because getting it to work in the old FFI was not trivial. It's definitely worth getting this working again, but it may take a bit of work to make it happen. Maybe it's easier with Eliot's more recent work, because I think the assembler glue goes away and that may simplify matters. Dave From eliot.miranda at gmail.com Tue Sep 15 02:15:51 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 15 02:15:54 2015 Subject: [squeak-dev] re: FFI callbacks In-Reply-To: References: <55EB1707.5090106@netjam.org> Message-ID: I get a lock up and a crash with the all-in-one. No problem with the latest VM. No diagnosis as yet. On Mon, Sep 14, 2015 at 5:34 PM, Craig Latta wrote: > > Hi Eliot-- > > > > I loaded Alien-eem.25 into Squeak 5.0.15110 on Mac OS 10.11.15A279b > > > from the Monticello HTTP repository at [1]. I ran AlienSunit in the > > > Test Runner, and it crashed Squeak. Before I get into posting error > > > logs, can anyone confirm that AlienSunit runs successfully on their > > > machine, on any host platform, or that I shouldn't expect it to run > > > successfully? Are there other Monticello packages I should be > > > loading, and if so, in what order? > > > > I get 15 passes and one failure, that being testLongLong. But that's > > in my VMMaker image, which has some extras in it. AFAIA tough Alien > > should just work. I'll look at the testLongLong failure soon cuz I'm > > starting on the x64 JIT and that requires the above to work to access > > the processor alien. > > Would you please try with the current Squeak 5 release? > > Also, is it feasible to make FFI calls to a 64-bit C library? > > > thanks again! > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150914/1998fd51/attachment.htm From lewis at mail.msen.com Tue Sep 15 02:24:56 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Tue Sep 15 02:24:59 2015 Subject: [squeak-dev] Re: [Vm-dev] Mantis 0007265: Bug in Matrix2x3Plugin okayIntValue: (was: two small bugs (vm related)) In-Reply-To: <20150913231751.GA11523@shell.msen.com> References: <20150913231751.GA11523@shell.msen.com> Message-ID: <20150915022456.GA15023@shell.msen.com> On Sun, Sep 13, 2015 at 07:17:51PM -0400, David T. Lewis wrote: > > On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote: > > > > I am about to close some old mantis reports. > > > > There are two issues related to the vm and easy to solve ( I think). > > > > http://bugs.squeak.org/view.php?id=7265 > > > > 0007265: Bug in Matrix2x3Plugin okayIntValue: > > Method > > okayIntValue: value > > uses argument to compare with lower bound, m23ResultX for upper bound. > > > > okayIntValue: value > > ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823 asFloat]) > > > > should be: > > okayIntValue: value > > ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat]) > > > > I looked at the Matrix2x3Plugin code, and the wrong comparsion > > is still there. > > I am quite sure you are right about this, just from looking at the code. > But I do want to check - the method is from ar 1998, so it has been in all > the VMs for a very long time. How did you find the problem? Is there a > test or an example that shows the issue? > > After fixing the method as you suggest, it will test for integer values > with bit values in the range 11000000000000000000000000000000 through > 00111111111111111111111111111111, which presumably maps to a range of > acceptable values for use in the Matrix2x3Plugin floating point operations. > So that looks quite reasonable, but I am puzzled that this check has been > wrong since 1998, so that is why I ask. > I closed issue 7265. Eliot added your fix to Spur/Cog I did likewise for VMM trunk (interpreter VM). Dave From nicolaihess at web.de Tue Sep 15 07:03:47 2015 From: nicolaihess at web.de (Nicolai Hess) Date: Tue Sep 15 07:03:51 2015 Subject: [squeak-dev] Re: [Vm-dev] Mantis 0007265: Bug in Matrix2x3Plugin okayIntValue: (was: two small bugs (vm related)) In-Reply-To: <20150915022456.GA15023@shell.msen.com> References: <20150913231751.GA11523@shell.msen.com> <20150915022456.GA15023@shell.msen.com> Message-ID: Thanks! 2015-09-15 4:24 GMT+02:00 David T. Lewis : > > > On Sun, Sep 13, 2015 at 07:17:51PM -0400, David T. Lewis wrote: > > > > On Sun, Sep 13, 2015 at 10:23:42PM +0200, Nicolai Hess wrote: > > > > > > I am about to close some old mantis reports. > > > > > > There are two issues related to the vm and easy to solve ( I think). > > > > > > http://bugs.squeak.org/view.php?id=7265 > > > > > > 0007265: Bug in Matrix2x3Plugin okayIntValue: > > > Method > > > okayIntValue: value > > > uses argument to compare with lower bound, m23ResultX for upper bound. > > > > > > okayIntValue: value > > > ^(value >= -1073741824 asFloat and:[m23ResultX <= 1073741823 > asFloat]) > > > > > > should be: > > > okayIntValue: value > > > ^(value >= -1073741824 asFloat and:[value <= 1073741823 asFloat]) > > > > > > I looked at the Matrix2x3Plugin code, and the wrong comparsion > > > is still there. > > > > I am quite sure you are right about this, just from looking at the code. > > But I do want to check - the method is from ar 1998, so it has been in > all > > the VMs for a very long time. How did you find the problem? Is there a > > test or an example that shows the issue? > > > > After fixing the method as you suggest, it will test for integer values > > with bit values in the range 11000000000000000000000000000000 through > > 00111111111111111111111111111111, which presumably maps to a range of > > acceptable values for use in the Matrix2x3Plugin floating point > operations. > > So that looks quite reasonable, but I am puzzled that this check has been > > wrong since 1998, so that is why I ask. > > > > I closed issue 7265. Eliot added your fix to Spur/Cog I did likewise for > VMM trunk (interpreter VM). > > Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150915/1fed2a18/attachment.htm From frank.shearar at gmail.com Tue Sep 15 10:22:54 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Tue Sep 15 10:22:57 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: References: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> Message-ID: Do you have an account on bugs.squeak.org? I don't think so, but if you set one up, I'll be happy to set up the permissions for you. frank On 14 September 2015 at 11:17, Fabio Niephaus wrote: > Since I created and maintain the new Squeak website, feel free to list me as > the owner. > > Best, > Fabio > > On Mon 14 Sep 2015 at 12:10 Frank Shearar wrote: >> >> On 11 September 2015 at 20:05, David T. Lewis wrote: >> > Hi Eliot, >> > >> > I'm not sure how it's configured, but do we have a VM category, and the >> > issues are getting automatically assigned to me. The Mantis tracker is >> > quite helpful for VM issues that cannot be immediately resolved on the >> > mailing lists. >> >> My apologies for leaving you off the list, Dave. Indeed, we already >> have a VM category, and you are its default owner. >> >> frank >> >> > Dave >> > >> >> Hi Frank, >> >> >> >> On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar >> >> >> >> wrote: >> >> >> >>> Mantis lets us configure default owners of tickets for various >> >>> subprojects. It's a bit.... out of date. (A "default owner" of a >> >>> subproject means that if you don't explicitly assign a ticket to >> >>> someone, this is the person to whom you implicitly assign the ticket.) >> >>> >> >>> Any, Box-Admins both point to KenCausey, who must be tired of >> >>> receiving the occasional mail on these topics. >> >>> >> >>> Here are our current mappings: >> >>> Any: KenCausey >> >>> Box-Admins: KenCausey >> >>> CI: FrankShearar >> >>> Documentation: casey >> >>> Games: asm >> >>> IRC: frankcag >> >>> Monticello: avi >> >>> News: gcorriga >> >>> Release Packaging: FrankShearar >> >>> SqueakMap: gokr >> >>> ToDo: RalphJohnson >> >>> Traits: dvf >> >>> www.squeak.org: KarlRamberg >> >>> >> >> >> >> I hope we could add VM and I could be an owner or Dave could be. >> >> >> >> >> >>> >> >>> I'm guessing they're so out of date because we tend not to use >> >>> bugs.squeak.org very much (sadly). >> >>> >> >>> I'm happy to stay default owner on my subprojects, unless someone else >> >>> would like to take the can. But certainly there are some projects that >> >>> really ought to change owner. >> >>> >> >>> Being the default owner doesn't imply that you have to fix the bugs! >> >>> It just means there's a clear point of contact: someone will >> >>> definitely see the bug report because it lands in their mailbox. >> >>> >> >>> The traffic from being an owner is... minimal. As in "because almost >> >>> no one uses the bugtracker you'll likely never see a mail" :) >> >>> >> >>> frank >> >>> >> >>> >> >> >> >> >> >> -- >> >> _,,,^..^,,,_ >> >> best, Eliot >> >> >> >> >> > >> > >> > >> > > > From lists at fniephaus.com Tue Sep 15 11:41:15 2015 From: lists at fniephaus.com (Fabio Niephaus) Date: Tue Sep 15 11:41:27 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: References: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> Message-ID: You're right! Just signed up: fniephaus Best, Fabio On Tue 15 Sep 2015 at 06:23 Frank Shearar wrote: > Do you have an account on bugs.squeak.org? I don't think so, but if > you set one up, I'll be happy to set up the permissions for you. > > frank > > On 14 September 2015 at 11:17, Fabio Niephaus wrote: > > Since I created and maintain the new Squeak website, feel free to list > me as > > the owner. > > > > Best, > > Fabio > > > > On Mon 14 Sep 2015 at 12:10 Frank Shearar > wrote: > >> > >> On 11 September 2015 at 20:05, David T. Lewis > wrote: > >> > Hi Eliot, > >> > > >> > I'm not sure how it's configured, but do we have a VM category, and > the > >> > issues are getting automatically assigned to me. The Mantis tracker is > >> > quite helpful for VM issues that cannot be immediately resolved on the > >> > mailing lists. > >> > >> My apologies for leaving you off the list, Dave. Indeed, we already > >> have a VM category, and you are its default owner. > >> > >> frank > >> > >> > Dave > >> > > >> >> Hi Frank, > >> >> > >> >> On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar > >> >> > >> >> wrote: > >> >> > >> >>> Mantis lets us configure default owners of tickets for various > >> >>> subprojects. It's a bit.... out of date. (A "default owner" of a > >> >>> subproject means that if you don't explicitly assign a ticket to > >> >>> someone, this is the person to whom you implicitly assign the > ticket.) > >> >>> > >> >>> Any, Box-Admins both point to KenCausey, who must be tired of > >> >>> receiving the occasional mail on these topics. > >> >>> > >> >>> Here are our current mappings: > >> >>> Any: KenCausey > >> >>> Box-Admins: KenCausey > >> >>> CI: FrankShearar > >> >>> Documentation: casey > >> >>> Games: asm > >> >>> IRC: frankcag > >> >>> Monticello: avi > >> >>> News: gcorriga > >> >>> Release Packaging: FrankShearar > >> >>> SqueakMap: gokr > >> >>> ToDo: RalphJohnson > >> >>> Traits: dvf > >> >>> www.squeak.org: KarlRamberg > >> >>> > >> >> > >> >> I hope we could add VM and I could be an owner or Dave could be. > >> >> > >> >> > >> >>> > >> >>> I'm guessing they're so out of date because we tend not to use > >> >>> bugs.squeak.org very much (sadly). > >> >>> > >> >>> I'm happy to stay default owner on my subprojects, unless someone > else > >> >>> would like to take the can. But certainly there are some projects > that > >> >>> really ought to change owner. > >> >>> > >> >>> Being the default owner doesn't imply that you have to fix the bugs! > >> >>> It just means there's a clear point of contact: someone will > >> >>> definitely see the bug report because it lands in their mailbox. > >> >>> > >> >>> The traffic from being an owner is... minimal. As in "because almost > >> >>> no one uses the bugtracker you'll likely never see a mail" :) > >> >>> > >> >>> frank > >> >>> > >> >>> > >> >> > >> >> > >> >> -- > >> >> _,,,^..^,,,_ > >> >> best, Eliot > >> >> > >> >> > >> > > >> > > >> > > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150915/9219a19a/attachment.htm From frank.shearar at gmail.com Tue Sep 15 12:15:44 2015 From: frank.shearar at gmail.com (Frank Shearar) Date: Tue Sep 15 12:15:47 2015 Subject: [squeak-dev] bugs.squeak.org: default owners of tickets In-Reply-To: References: <3716.136.2.1.105.1441998340.squirrel@webmail.msen.com> Message-ID: OK, you're now the default owner of the www.squeak.org category in the Squeak project. (There is another project, "Squeak Website", but I have no privileges there.) frank On 15 September 2015 at 12:41, Fabio Niephaus wrote: > You're right! Just signed up: fniephaus > > Best, > Fabio > > On Tue 15 Sep 2015 at 06:23 Frank Shearar wrote: >> >> Do you have an account on bugs.squeak.org? I don't think so, but if >> you set one up, I'll be happy to set up the permissions for you. >> >> frank >> >> On 14 September 2015 at 11:17, Fabio Niephaus wrote: >> > Since I created and maintain the new Squeak website, feel free to list >> > me as >> > the owner. >> > >> > Best, >> > Fabio >> > >> > On Mon 14 Sep 2015 at 12:10 Frank Shearar >> > wrote: >> >> >> >> On 11 September 2015 at 20:05, David T. Lewis >> >> wrote: >> >> > Hi Eliot, >> >> > >> >> > I'm not sure how it's configured, but do we have a VM category, and >> >> > the >> >> > issues are getting automatically assigned to me. The Mantis tracker >> >> > is >> >> > quite helpful for VM issues that cannot be immediately resolved on >> >> > the >> >> > mailing lists. >> >> >> >> My apologies for leaving you off the list, Dave. Indeed, we already >> >> have a VM category, and you are its default owner. >> >> >> >> frank >> >> >> >> > Dave >> >> > >> >> >> Hi Frank, >> >> >> >> >> >> On Fri, Sep 11, 2015 at 2:13 AM, Frank Shearar >> >> >> >> >> >> wrote: >> >> >> >> >> >>> Mantis lets us configure default owners of tickets for various >> >> >>> subprojects. It's a bit.... out of date. (A "default owner" of a >> >> >>> subproject means that if you don't explicitly assign a ticket to >> >> >>> someone, this is the person to whom you implicitly assign the >> >> >>> ticket.) >> >> >>> >> >> >>> Any, Box-Admins both point to KenCausey, who must be tired of >> >> >>> receiving the occasional mail on these topics. >> >> >>> >> >> >>> Here are our current mappings: >> >> >>> Any: KenCausey >> >> >>> Box-Admins: KenCausey >> >> >>> CI: FrankShearar >> >> >>> Documentation: casey >> >> >>> Games: asm >> >> >>> IRC: frankcag >> >> >>> Monticello: avi >> >> >>> News: gcorriga >> >> >>> Release Packaging: FrankShearar >> >> >>> SqueakMap: gokr >> >> >>> ToDo: RalphJohnson >> >> >>> Traits: dvf >> >> >>> www.squeak.org: KarlRamberg >> >> >>> >> >> >> >> >> >> I hope we could add VM and I could be an owner or Dave could be. >> >> >> >> >> >> >> >> >>> >> >> >>> I'm guessing they're so out of date because we tend not to use >> >> >>> bugs.squeak.org very much (sadly). >> >> >>> >> >> >>> I'm happy to stay default owner on my subprojects, unless someone >> >> >>> else >> >> >>> would like to take the can. But certainly there are some projects >> >> >>> that >> >> >>> really ought to change owner. >> >> >>> >> >> >>> Being the default owner doesn't imply that you have to fix the >> >> >>> bugs! >> >> >>> It just means there's a clear point of contact: someone will >> >> >>> definitely see the bug report because it lands in their mailbox. >> >> >>> >> >> >>> The traffic from being an owner is... minimal. As in "because >> >> >>> almost >> >> >>> no one uses the bugtracker you'll likely never see a mail" :) >> >> >>> >> >> >>> frank >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> -- >> >> >> _,,,^..^,,,_ >> >> >> best, Eliot >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> >> > >> > >> > >> > > > From eliot.miranda at gmail.com Tue Sep 15 16:30:44 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 15 16:30:48 2015 Subject: [squeak-dev] re: FFI callbacks In-Reply-To: References: <55EB1707.5090106@netjam.org> Message-ID: Hi Craig, On Mon, Sep 14, 2015 at 5:34 PM, Craig Latta wrote: > > Hi Eliot-- > > > > I loaded Alien-eem.25 into Squeak 5.0.15110 on Mac OS 10.11.15A279b > > > from the Monticello HTTP repository at [1]. I ran AlienSunit in the > > > Test Runner, and it crashed Squeak. Before I get into posting error > > > logs, can anyone confirm that AlienSunit runs successfully on their > > > machine, on any host platform, or that I shouldn't expect it to run > > > successfully? Are there other Monticello packages I should be > > > loading, and if so, in what order? > > > > I get 15 passes and one failure, that being testLongLong. But that's > > in my VMMaker image, which has some extras in it. AFAIA tough Alien > > should just work. I'll look at the testLongLong failure soon cuz I'm > > starting on the x64 JIT and that requires the above to work to access > > the processor alien. > > Would you please try with the current Squeak 5 release? > OK, so in an updated Squeak 5 release containing only Alien - the 5.0 All-in-one locks up and core dumps - the same VM from my site (CogSpur.app-15.27.3397.tgz ) fails the testLongLong test but all others pass. So there's something strange about the all-in-one. I'll try and investigate further as time allows but perhaps you could look at the plugins and see whether one of them is rogue, e.g. by removing the external plugins one by one? > > Also, is it feasible to make FFI calls to a 64-bit C library? > Not from a 32-bit executable. One can't even load a 64-bit library into a 32-bit executable. Building a 64-bit version of the 32-bit VM is possible but a lot of work (needs a 674-nit JIT). Instead I'm pursuing a proper all-64-bit solution. > > > thanks again! > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150915/d92063b5/attachment.htm From eliot.miranda at gmail.com Tue Sep 15 17:45:16 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue Sep 15 17:45:18 2015 Subject: [squeak-dev] Re: [Vm-dev] [Pharo-dev] issue with large file path on windows In-Reply-To: <8B8F824C-37DC-4F47-BDF0-A4C12EEAFB14@gmail.com> References: <428322F3-407B-4510-A3CB-A5F35FB642E6@gmail.com> <20150915121333.GA23030@shell.msen.com> <8B8F824C-37DC-4F47-BDF0-A4C12EEAFB14@gmail.com> Message-ID: Hi David, On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano wrote: > > > > On 15 Sep 2015, at 14:13, David T. Lewis wrote: > > > > > > On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote: > >> > >> Pharo uses them. > >> > >> Posix permissions are useful for both linux and mac. > >> Windows uses also the posix permissions that came with MinGW??? I do > not think they are useful but we provide them anyway :) > > > > > > Posix permissions are based on Unix, and are very platform specific. The > > Windows equivalents are semantically different, and other operating > systems > > may exist that are not Unix based at all. > > > > IMO, platform specific functions should go into separate plugins, and not > > in FilePlugin. > > well, I disagree :) > I do not find this approach practical? because in general, there is no > other systems that may exist using other permissions than POSIX. Except > Windows, of course, but even for windows, there are compatibility layers > that we can use. > In the case of the FilePlugin extensions, we choose to stay POSIX because > in general, as its been said before, the job of a virtual machine is been > virtual: to provide an ?abstract machine? common for everything in the > image. I?m not saying that this is possible and even desirable in all > cases, but it should be something to think about. > In that case, we could design a common file permissions different to the > one of Windows and different to POSIX, but I think POSIX does the job just > fine. > > Also, the choice was: POSIX or nothing (because we didn?t have anything > before). > I would be very happy if we agree in a better solution, and we implement > it. > But in the mean time, a not perfect solution is better than none. > I agree with Esteban. IMO, the model of files that the FilePlugin provides access to can and should be a superset of facilities. By not supporting facilities such as permissions or symbolic links or active mount-points we hobble our core file functionality and that makes us a very weak scripting platform. Putting these facilities in add-on packages makes configuration more difficult and means that an elegant implementation in the core file classes, with fallbacks for platforms that don't support the concepts, is very difficult. If we want to support unix-style scripting in Pharo and Squeak (and I think we very much do; there are many areas out there where good scripting is essential) then we need a better File model, and that means not just getting rid of FileDirectory et al, it also means providing the right infrastructure in the FilePlugin, and that means extensions like the one the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO. > Esteban > > > > > Dave > > > > > > > >> > >> Esteban > >> > >> ps: I do not know what are you doing there guys, but you broke my > builds (I???m taking a look at them now) :P > >> > >>> On 15 Sep 2015, at 09:24, Nicolai Hess wrote: > >>> > >>> > >>> > >>> 2015-09-15 4:11 GMT+02:00 Ben Coman btc@openinworld.com>>: > >>> > >>> On Sat, Sep 12, 2015 at 11:00 PM, Nicolai Hess > wrote: > >>>> > >>>> > >>>> > >>>> 2015-09-10 21:31 GMT+02:00 Eliot Miranda >: > >>>>> > >>>>> > >>>>> Hi Nicolai, > >>>>> > >>>>> I'm a bit concerned that this is creating drift with the > "official" Cog source base at > http://www.squeakvm.org/svn/squeak/branches/Cog < > http://www.squeakvm.org/svn/squeak/branches/Cog>. Long filename support > for win32 was recently added by Marcel Taumel in May of this year. Are you > tracking that? How can we keep the sources harmonized? > >>>> > >>>> > >>>> Ok, I removed all of my code again and merged with sqWin32Directory.c > and sqWin32FilePrims.c from the official cog source. > >>>> I left only pharos additions for the fileattributes > (posixpermissions) this should make it easier to merge which the > >>>> squeak vm main branch (wrapped with pharo vm ifdefs). > >>> > >>> What is the purpose of fileattributes? In the interests of further > >>> minimising drift, is this useful to Squeak? > >>> cheers -ben > >>> > >>> I don't know, I don't think we use it at all. And for the different > platforms, the permission attributes > >>> doesn't really *are the same*. For example, the read/write permissions > we are showing for > >>> win32 platform, don't have much to do with win32 access restrictions - > Idon't know about macos. > >>> > >>> > >>> > >>> > >>> > >> > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150915/2baa7bfb/attachment.htm From hannes.hirzel at gmail.com Tue Sep 15 19:17:32 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue Sep 15 19:17:36 2015 Subject: [squeak-dev] SqueakMap error -- display of installed packages In-Reply-To: <20150912191111.GA26124@shell.msen.com> References: <20150912191111.GA26124@shell.msen.com> Message-ID: Interestingly the method SMLoaderPlus >>packageListCalculated was change last time 9 years ago. --Hannes On 9/12/15, David T. Lewis wrote: > On Sat, Sep 12, 2015 at 03:47:57PM +0200, H. Hirzel wrote: >> The SqueakMap Package Loader window has as model an instance of >> SMLoaderPlus >> >> And this are the selectors of interest >> >> SMLoaderPlus>>filterInstalled >> ^[:package | package isInstalled] >> >> SMLoaderPlus>>filterSafelyAvailable >> ^[:package | package isSafelyAvailable] >> >> SMLoaderPlus has an instance variable called 'filters' which has as >> content >> >> an OrderedCollection(#filterInstalled #filterSafelyAvailable) >> >> for the case at hand, i.e. when both are selected. >> >> >> This instance variable is accessed by >> >> SMLoaderPlus >>packageListCalculated >> "Return a list of the SMPackages that should be visible >> by applying all the filters. Also filter based on the currently >> selected category - if any." >> ^ self packages select: [:p | >> filters allSatisfy: [:currFilter | >> currFilter isSymbol >> ifTrue: [(self perform: currFilter) value: p] >> ifFalse: [self package: p filteredByCategory: (map object: >> currFilter)]]] >> >> >> >> #allSatisfy: >> >> is used which means that this is an 'and' operation. >> >> >> If it is replaced by >> >> #anySatisfy: >> >> it starts working as intended. > > Thank you for fixing this! I put your update into trunk. > > Dave > > >> >> >> >> On 9/11/15, Chris Muller wrote: >> > Right, it looks like the filters form a conjunction. Probably >> > intentional, but not necessarily what we still want today. SqueakMap >> > client window could stand to be scrtuinized and improved. >> > >> > On Fri, Sep 11, 2015 at 3:45 AM, H. Hirzel >> > wrote: >> >> Hello >> >> >> >> Error report: >> >> >> >> If in SqueakMap both options are ticked >> >> >> >> 'New safely available packages' >> >> 'Installed packages' >> >> >> >> nothing is shown. >> >> >> >> However if I only tick >> >> 'Installed packages' >> >> >> >> then the installed package is shown. So the selection is not >> >> cumulative. >> >> >> >> >> >> Regards >> >> Hannes >> >> >> >> >> >> >> > >> > > > From commits at source.squeak.org Tue Sep 15 19:58:14 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 15 19:58:15 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz Message-ID: Chris Muller uploaded a new version of SMLoader to project The Trunk: http://source.squeak.org/trunk/SMLoader-cmm.85.mcz ==================== Summary ==================== Name: SMLoader-cmm.85 Author: cmm Time: 15 September 2015, 2:58:07.033 pm UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b Ancestors: SMLoader-dtl.84 Revert dtl.84, because it broke the Catalog filters. =============== Diff against SMLoader-dtl.84 =============== Item was changed: ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') ----- packageListCalculated "Return a list of the SMPackages that should be visible by applying all the filters. Also filter based on the currently selected category - if any." ^ self packages select: [:p | + filters allSatisfy: [:currFilter | - filters anySatisfy: [:currFilter | currFilter isSymbol ifTrue: [(self perform: currFilter) value: p] ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]! From asqueaker at gmail.com Tue Sep 15 20:04:25 2015 From: asqueaker at gmail.com (Chris Muller) Date: Tue Sep 15 20:04:28 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz In-Reply-To: <55f8785b.89dd370a.4e43f.ffffc81dSMTPIN_ADDED_MISSING@mx.google.com> References: <55f8785b.89dd370a.4e43f.ffffc81dSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: After review and some thought, it has become clear to me that Dave's change is incorrect. Please take a look at the SqueakMap filters and consider them from the context of the use-cases -- what users need to do with SqueakMap, and NOT from the context of a database that needs to produce generalized "query results" <---- because it doesn't. "Published" are the ones which have software to install, while "Auto-installable" shows only packages that are installable from the "Install" menu selection within the image. These two filters are useful together in a restricting fashion, not an inflating one, so that newbies can see what's ready to go. It was then that I also realized that Hannes' combination was not a use-case either. The use-cases we have are: 1) user wants to install software or, 2) user wants to see what they have already installed. Seeing a cumulative list of both installed and uninstalled satisfies neither use-case. Nevertheless you may once again "Clear all filters" (which was broken by Dave's commit) if you want to see everything. I still say SqueakMap catalog can and needs improvement, but we need to really consider our changes because its clear that G?ran put a lot of thought into the usage of SqueakMap and its role in the community; so I think we can afford to be a bit more skeptical before thinking something like that was a bug in the first place and for nine years running.. On Tue, Sep 15, 2015 at 2:58 PM, wrote: > Chris Muller uploaded a new version of SMLoader to project The Trunk: > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz > > ==================== Summary ==================== > > Name: SMLoader-cmm.85 > Author: cmm > Time: 15 September 2015, 2:58:07.033 pm > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b > Ancestors: SMLoader-dtl.84 > > Revert dtl.84, because it broke the Catalog filters. > > =============== Diff against SMLoader-dtl.84 =============== > > Item was changed: > ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') ----- > packageListCalculated > "Return a list of the SMPackages that should be visible > by applying all the filters. Also filter based on the currently > selected category - if any." > ^ self packages select: [:p | > + filters allSatisfy: [:currFilter | > - filters anySatisfy: [:currFilter | > currFilter isSymbol > ifTrue: [(self perform: currFilter) value: p] > ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]! > > From hannes.hirzel at gmail.com Tue Sep 15 21:24:41 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Tue Sep 15 21:24:43 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display Message-ID: On 9/15/15, Chris Muller wrote: > After review and some thought, it has become clear to me that Dave's > change is incorrect. Please take a look at the SqueakMap filters and > consider them from the context of the use-cases -- what users need to > do with SqueakMap, and NOT from the context of a database that needs > to produce generalized "query results" <---- because it doesn't. > > "Published" are the ones which have software to install, while > "Auto-installable" shows only packages that are installable from the > "Install" menu selection within the image. These two filters are > useful together in a restricting fashion, not an inflating one, so > that newbies can see what's ready to go. > > It was then that I also realized that Hannes' combination was not a > use-case either. The use-cases we have are: 1) user wants to install > software or, 2) user wants to see what they have already installed. > Seeing a cumulative list of both installed and uninstalled satisfies > neither use-case. I disagree. >From a user interface perspective the problem lies in the fact that it allows me to _select_ 1) show installable software 2) show installed software at the _same_ time. Then I expect to see the set of installable software unified with the set of installed software. What is implemented corresponds to check boxes. What is implemented is radio buttons behaviour. But the radio buttons do not work as it is possible to have more than one buttion active at the same time. Cumulative selections should not be allowed. At the moment they are. The behaviour of the GUI is not what is expected. Some people actually do call this a bug. > Nevertheless you may once again "Clear all filters" (which was broken > by Dave's commit) if you want to see everything. > > I still say SqueakMap catalog can and needs improvement, +1 but we need > to really consider our changes because its clear that G?ran put a lot > of thought into the usage of SqueakMap and its role in the community; Yes, he did but but this surely not the right spot to illustrate this point. The GUI seems to be abandoned as of now. I think it is worthwhile to fix obvious issues. > so I think we can afford to be a bit more skeptical before thinking > something like that was a bug in the first place and for nine years > running.. There could be other reasons for no change in 9 years a) Not many people use it and see it as a legacy app which does not need to be fixed. b) Idiosyncrasies are accepted as other parts of the GUI have similar problems. The fact that there was no change in 9 years is not an argument for the quality as such as you easily can imagine. > > On Tue, Sep 15, 2015 at 2:58 PM, wrote: >> Chris Muller uploaded a new version of SMLoader to project The Trunk: >> http://source.squeak.org/trunk/SMLoader-cmm.85.mcz >> >> ==================== Summary ==================== >> >> Name: SMLoader-cmm.85 >> Author: cmm >> Time: 15 September 2015, 2:58:07.033 pm >> UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b >> Ancestors: SMLoader-dtl.84 >> >> Revert dtl.84, because it broke the Catalog filters. >> >> =============== Diff against SMLoader-dtl.84 =============== >> >> Item was changed: >> ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') >> ----- >> packageListCalculated >> "Return a list of the SMPackages that should be visible >> by applying all the filters. Also filter based on the currently >> selected category - if any." >> ^ self packages select: [:p | >> + filters allSatisfy: [:currFilter | >> - filters anySatisfy: [:currFilter | >> currFilter isSymbol >> ifTrue: [(self perform: currFilter) value: >> p] >> ifFalse: [self package: p >> filteredByCategory: (map object: currFilter)]]]! >> >> > > From commits at source.squeak.org Tue Sep 15 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Tue Sep 15 21:55:05 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150915215502.381.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008965.html Name: SMLoader-cmm.85 Ancestors: SMLoader-dtl.84 Revert dtl.84, because it broke the Catalog filters. ============================================= From ma.chris.m at gmail.com Tue Sep 15 22:35:12 2015 From: ma.chris.m at gmail.com (Chris Muller) Date: Tue Sep 15 22:35:55 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display In-Reply-To: References: Message-ID: On Tue, Sep 15, 2015 at 4:24 PM, H. Hirzel wrote: > On 9/15/15, Chris Muller wrote: >> After review and some thought, it has become clear to me that Dave's >> change is incorrect. Please take a look at the SqueakMap filters and >> consider them from the context of the use-cases -- what users need to >> do with SqueakMap, and NOT from the context of a database that needs >> to produce generalized "query results" <---- because it doesn't. >> >> "Published" are the ones which have software to install, while >> "Auto-installable" shows only packages that are installable from the >> "Install" menu selection within the image. These two filters are >> useful together in a restricting fashion, not an inflating one, so >> that newbies can see what's ready to go. >> >> It was then that I also realized that Hannes' combination was not a >> use-case either. The use-cases we have are: 1) user wants to install >> software or, 2) user wants to see what they have already installed. >> Seeing a cumulative list of both installed and uninstalled satisfies >> neither use-case. > > I disagree. > > From a user interface perspective the problem lies in the fact that it > allows me to _select_ > > 1) show installable software > 2) show installed software > > at the _same_ time. Sure, but those are *filters* you've selected. Filters are things that only remove, they don't add... > Then > I expect to see the set of installable software unified with the set > of installed software. Please read the balloon help on those filters you selected, they decribe their behavior and are performing it correctly. There is actually a plausible use-case for that combination of filters you selected: to show the user the software that is either not installed or is installed but can be upgraded because there's a newer version available. That's actually sounds useful.. > What is implemented corresponds to check boxes. What is implemented is > radio buttons behaviour. No it isn't, because you can have multiple filters in place at once, which we see satsify meaningful use-cases. > But the radio buttons do not work as it is > possible to have more than one buttion active at the same time. > Cumulative selections should not be allowed. At the moment they are. I had actually started an implementation to "group" the filters into groups of radios that would cause others in the same group to be unchecked. That forced me to consider all the use-cases and that's when I realized the purpose of the existing filters. > The behaviour of the GUI is not what is expected. Some people actually > do call this a bug. Reading the balloon help provided by those filters actually helps to understand why its not a bug. Please check that out. And, why do you want to see Installed and Uninstalled all in one list and why not just "Clear all fiters" to do that? Best, Chris From lewis at mail.msen.com Wed Sep 16 00:11:26 2015 From: lewis at mail.msen.com (David T. Lewis) Date: Wed Sep 16 00:11:39 2015 Subject: [squeak-dev] Re: [Vm-dev] [Pharo-dev] issue with large file path on windows In-Reply-To: References: <428322F3-407B-4510-A3CB-A5F35FB642E6@gmail.com> <20150915121333.GA23030@shell.msen.com> <8B8F824C-37DC-4F47-BDF0-A4C12EEAFB14@gmail.com> Message-ID: <20150916001126.GA32054@shell.msen.com> On Tue, Sep 15, 2015 at 10:45:16AM -0700, Eliot Miranda wrote: > > Hi David, > > On Tue, Sep 15, 2015 at 5:45 AM, Esteban Lorenzano > wrote: > > > > > > On 15 Sep 2015, at 14:13, David T. Lewis wrote: > > > > > > > > > On Tue, Sep 15, 2015 at 11:40:48AM +0200, Esteban Lorenzano wrote: > > >> > > >> Pharo uses them. > > >> > > >> Posix permissions are useful for both linux and mac. > > >> Windows uses also the posix permissions that came with MinGW??? I do > > not think they are useful but we provide them anyway :) > > > > > > > > > Posix permissions are based on Unix, and are very platform specific. The > > > Windows equivalents are semantically different, and other operating > > systems > > > may exist that are not Unix based at all. > > > > > > IMO, platform specific functions should go into separate plugins, and not > > > in FilePlugin. > > > > well, I disagree :) > > I do not find this approach practical??? because in general, there is no > > other systems that may exist using other permissions than POSIX. Except > > Windows, of course, but even for windows, there are compatibility layers > > that we can use. > > In the case of the FilePlugin extensions, we choose to stay POSIX because > > in general, as its been said before, the job of a virtual machine is been > > virtual: to provide an ???abstract machine??? common for everything in the > > image. I???m not saying that this is possible and even desirable in all > > cases, but it should be something to think about. > > In that case, we could design a common file permissions different to the > > one of Windows and different to POSIX, but I think POSIX does the job just > > fine. > > > > Also, the choice was: POSIX or nothing (because we didn???t have anything > > before). > > I would be very happy if we agree in a better solution, and we implement > > it. > > But in the mean time, a not perfect solution is better than none. > > > > I agree with Esteban. IMO, the model of files that the FilePlugin provides > access to can and should be a superset of facilities. By not supporting > facilities such as permissions or symbolic links or active mount-points we > hobble our core file functionality and that makes us a very weak scripting > platform. Putting these facilities in add-on packages makes configuration > more difficult and means that an elegant implementation in the core file > classes, with fallbacks for platforms that don't support the concepts, is > very difficult. I do not intend to suggest that these things are not wonderful and good and worthy of being done. What I said is that they should not be put into FilePlugin. Yes it is more difficult to implement features like this in packages, but with all due respect it's not all *that* terribly hard. And I think the too much work argument does not hold up when we are talking about something like FilePlugin that effectively defines minimal core functionality required to bring up an image on a new platform. > > If we want to support unix-style scripting in Pharo and Squeak (and I think > we very much do; there are many areas out there where good scripting is > essential) then we need a better File model, and that means not just > getting rid of FileDirectory et al, it also means providing the right > infrastructure in the FilePlugin, and that means extensions like the one > the Pharo VM folks made. Indeed they haven't gone nearly far enough IMO. Again, I am not saying that these things should not be done. Just that with respect to platform-specific features that can only ever work on a Unix based system, allowing these to creep into the feature set of base system does not seem like a very good idea to me. That's all I am saying. Dave From asqueaker at gmail.com Wed Sep 16 01:56:21 2015 From: asqueaker at gmail.com (Chris Muller) Date: Wed Sep 16 01:56:23 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display In-Reply-To: References: Message-ID: Although changing that allSatsify to anySatisfy is not the right solution, I think you are on to something about the UI. It shouldn't be confusing, but it is, isn't it? I remember now that those filters have confused me before, too, exactly the same way. Maybe we should revamp the filters and possiblly even make them radio buttons to really suggest the correct pattern of usage..? Instead of "Safely available", etc., maybe we should just make it simple and have something like, Installed, Compatible, and Latest..? From goran at krampe.se Wed Sep 16 11:41:40 2015 From: goran at krampe.se (=?UTF-8?Q?G=c3=b6ran_Krampe?=) Date: Wed Sep 16 11:41:45 2015 Subject: [squeak-dev] SqueakMap error -- display of installed packages In-Reply-To: References: <20150912191111.GA26124@shell.msen.com> Message-ID: <55F95574.8080307@krampe.se> On 09/15/2015 09:17 PM, H. Hirzel wrote: > Interestingly the method SMLoaderPlus >>packageListCalculated was > change last time 9 years ago. Well, when I wrote it I really intended to apply all filters in a logical AND operation :) But feel free to do whatever you guys find proper. regards, G?ran From goran at krampe.se Wed Sep 16 11:58:36 2015 From: goran at krampe.se (=?UTF-8?Q?G=c3=b6ran_Krampe?=) Date: Wed Sep 16 11:58:40 2015 Subject: [squeak-dev] Ni - a strange little language Message-ID: <55F9596C.3060108@krampe.se> Hi guys! Just wanted to give a pointer to a little language I am implementing: http://goran.krampe.se/2015/09/16/ni-a-strange-little-language/ Is it a new Smalltalk-80? No. Is it Smalltalkish? Yes. But still quite different. :) The article tries to introduce some of the funkier aspects of Ni. In essence Ni is a homoiconic dynamically typed garbage collected 100% live language similar to Lisp/Rebol/Forth in its simplicity. But it also has Smalltalk keyword syntax, Smalltalk non local return, blocks-as-closures as in Smalltalk and well, perhaps a few more odds and ends similar to Smalltalk. And one of the next steps is adding objects to it. This will be based on a model of cloning and delegation and an object, so a bit closer to Self there. Why would you want to look at it? Because it breaks (or will break) a few barriers that most Smalltalks still suffer from... easy integration with C/C++, multithreading, embeddability and so on. Hope you find it interesting! regards, G?ran PS. Fast? Nope. I mean, its decent for an AST interpreter but I haven't spent time optimizing it yet - it uses dynamically allocated things and methods (dynamic dispatch) quite heavily today. From karlramberg at gmail.com Wed Sep 16 13:55:36 2015 From: karlramberg at gmail.com (karl ramberg) Date: Wed Sep 16 13:55:41 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz In-Reply-To: References: <55f8785b.89dd370a.4e43f.ffffc81dSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Maybe it would be nice if the filters where off when opening the SqueakMap browser. With filters on it seems to be empty and not functioning. There is always warnings about package not being compatible when you try to load them anyway. Karl On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller wrote: > After review and some thought, it has become clear to me that Dave's > change is incorrect. Please take a look at the SqueakMap filters and > consider them from the context of the use-cases -- what users need to > do with SqueakMap, and NOT from the context of a database that needs > to produce generalized "query results" <---- because it doesn't. > > "Published" are the ones which have software to install, while > "Auto-installable" shows only packages that are installable from the > "Install" menu selection within the image. These two filters are > useful together in a restricting fashion, not an inflating one, so > that newbies can see what's ready to go. > > It was then that I also realized that Hannes' combination was not a > use-case either. The use-cases we have are: 1) user wants to install > software or, 2) user wants to see what they have already installed. > Seeing a cumulative list of both installed and uninstalled satisfies > neither use-case. > > Nevertheless you may once again "Clear all filters" (which was broken > by Dave's commit) if you want to see everything. > > I still say SqueakMap catalog can and needs improvement, but we need > to really consider our changes because its clear that G?ran put a lot > of thought into the usage of SqueakMap and its role in the community; > so I think we can afford to be a bit more skeptical before thinking > something like that was a bug in the first place and for nine years > running.. > > > On Tue, Sep 15, 2015 at 2:58 PM, wrote: > > Chris Muller uploaded a new version of SMLoader to project The Trunk: > > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz > > > > ==================== Summary ==================== > > > > Name: SMLoader-cmm.85 > > Author: cmm > > Time: 15 September 2015, 2:58:07.033 pm > > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b > > Ancestors: SMLoader-dtl.84 > > > > Revert dtl.84, because it broke the Catalog filters. > > > > =============== Diff against SMLoader-dtl.84 =============== > > > > Item was changed: > > ----- Method: SMLoaderPlus>>packageListCalculated (in category > 'lists') ----- > > packageListCalculated > > "Return a list of the SMPackages that should be visible > > by applying all the filters. Also filter based on the currently > > selected category - if any." > > ^ self packages select: [:p | > > + filters allSatisfy: [:currFilter | > > - filters anySatisfy: [:currFilter | > > currFilter isSymbol > > ifTrue: [(self perform: currFilter) > value: p] > > ifFalse: [self package: p > filteredByCategory: (map object: currFilter)]]]! > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150916/fd8ae83f/attachment.htm From karlramberg at gmail.com Wed Sep 16 14:03:39 2015 From: karlramberg at gmail.com (karl ramberg) Date: Wed Sep 16 14:03:42 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display In-Reply-To: References: Message-ID: + 1 The filters are for advanced users. Karl On Wed, Sep 16, 2015 at 3:56 AM, Chris Muller wrote: > Although changing that allSatsify to anySatisfy is not the right > solution, I think you are on to something about the UI. It shouldn't > be confusing, but it is, isn't it? I remember now that those filters > have confused me before, too, exactly the same way. > > Maybe we should revamp the filters and possiblly even make them radio > buttons to really suggest the correct pattern of usage..? > > Instead of "Safely available", etc., maybe we should just make it > simple and have something like, Installed, Compatible, and Latest..? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150916/e48f98a7/attachment.htm From ma.chris.m at gmail.com Wed Sep 16 16:39:52 2015 From: ma.chris.m at gmail.com (Chris Muller) Date: Wed Sep 16 16:40:34 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz In-Reply-To: References: <55f8785b.89dd370a.4e43f.ffffc81dSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: > Maybe it would be nice if the filters where off when opening the SqueakMap > browser. With filters on it seems to be empty and not functioning. No. Just a gentle reminder, the best way to talk about SqueakMap and figure out how to improve it is to orient ourselves with the requirements: http://wiki.squeak.org/squeak/6183 Presenting everything in the list would violate requirement #4. Publishers who simply follow these publishing guidelines [1] are able to meet these requirements, and so what users see in the list is what WORKS. If we show "everything" then we're hiding what works, and SM becomes useless again. Why do you say its an empty list? I just checked Squeak 5.0 and there are at least 20 packages showing up in there..? IF nothing were to show up in the list when "Safely-available" filter (and nothing else) is checked, then that's on us as a community. It simply means that we didn't care enough to take the 5 minutes necessary to recertify our packages for the latest Squeak. It is what it is, but let's not fake out the "truth". Thankfully, we DON'T have a blank list in 5.0. Thanks to those in the community who have gotten on board with the publishing guidelines we have packages on SM that actually WORK (if they were done right) and have single one of those requirements met. Users are able to consume those packages with one click instead of being forced to come begging to the list for "how to load it".. We will get there! [1] -- SqueakMap Publishing Guidelines http://wiki.squeak.org/squeak/6182 [2] -- How to designate existing SqueakMap packages for a new version of Squeak http://wiki.squeak.org/squeak/6180 > There is always warnings about package not being compatible when you try to > load them anyway. > > Karl > > On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller wrote: >> >> After review and some thought, it has become clear to me that Dave's >> change is incorrect. Please take a look at the SqueakMap filters and >> consider them from the context of the use-cases -- what users need to >> do with SqueakMap, and NOT from the context of a database that needs >> to produce generalized "query results" <---- because it doesn't. >> >> "Published" are the ones which have software to install, while >> "Auto-installable" shows only packages that are installable from the >> "Install" menu selection within the image. These two filters are >> useful together in a restricting fashion, not an inflating one, so >> that newbies can see what's ready to go. >> >> It was then that I also realized that Hannes' combination was not a >> use-case either. The use-cases we have are: 1) user wants to install >> software or, 2) user wants to see what they have already installed. >> Seeing a cumulative list of both installed and uninstalled satisfies >> neither use-case. >> >> Nevertheless you may once again "Clear all filters" (which was broken >> by Dave's commit) if you want to see everything. >> >> I still say SqueakMap catalog can and needs improvement, but we need >> to really consider our changes because its clear that G?ran put a lot >> of thought into the usage of SqueakMap and its role in the community; >> so I think we can afford to be a bit more skeptical before thinking >> something like that was a bug in the first place and for nine years >> running.. >> >> >> On Tue, Sep 15, 2015 at 2:58 PM, wrote: >> > Chris Muller uploaded a new version of SMLoader to project The Trunk: >> > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz >> > >> > ==================== Summary ==================== >> > >> > Name: SMLoader-cmm.85 >> > Author: cmm >> > Time: 15 September 2015, 2:58:07.033 pm >> > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b >> > Ancestors: SMLoader-dtl.84 >> > >> > Revert dtl.84, because it broke the Catalog filters. >> > >> > =============== Diff against SMLoader-dtl.84 =============== >> > >> > Item was changed: >> > ----- Method: SMLoaderPlus>>packageListCalculated (in category >> > 'lists') ----- >> > packageListCalculated >> > "Return a list of the SMPackages that should be visible >> > by applying all the filters. Also filter based on the currently >> > selected category - if any." >> > ^ self packages select: [:p | >> > + filters allSatisfy: [:currFilter | >> > - filters anySatisfy: [:currFilter | >> > currFilter isSymbol >> > ifTrue: [(self perform: currFilter) >> > value: p] >> > ifFalse: [self package: p >> > filteredByCategory: (map object: currFilter)]]]! >> > >> > >> > From commits at source.squeak.org Wed Sep 16 17:46:32 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 16 17:46:34 2015 Subject: [squeak-dev] The Trunk: Kernel-eem.951.mcz Message-ID: Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.951.mcz ==================== Summary ==================== Name: Kernel-eem.951 Author: eem Time: 16 September 2015, 10:46:01.276 am UUID: 43df7732-200e-421c-9be0-2c6d33244069 Ancestors: Kernel-eem.950 Implement callPrimitive: in the simulator so that, for example, the debugger does not get into an infinite recursion when accepting a new version of a method that has a primitive. Simplify skipCallPrimitive. Fix classCommentBlank so that it always answers the blank, even when there's an existing comment (shurely shome mistake, hic, ed).. =============== Diff against Kernel-eem.950 =============== Item was changed: ----- Method: ClassDescription>>classCommentBlank (in category 'accessing comment') ----- classCommentBlank + ^String streamContents: + [:stream| + stream + nextPutAll: 'A'; + nextPutAll: (self name first isVowel ifTrue: ['n '] ifFalse: [' ']); + nextPutAll: self name; + nextPutAll: ' is xxxxxxxxx.'; + cr; cr; + nextPutAll: 'Instance Variables'. - | existingComment stream | - existingComment := self theNonMetaClass organization classComment. - existingComment isEmpty - ifFalse: [^existingComment]. + self instVarNames asSortedCollection do: [:each | + stream + crtab; nextPutAll: each; + nextPut: $:; + tab: 2; + nextPutAll: '']. + stream cr. + self instVarNames asSortedCollection do: [:each | + stream + cr; nextPutAll: each; + crtab; nextPutAll: '- xxxxx'; cr]]! - stream := WriteStream on: (String new: 100). - stream - nextPutAll: 'A'; - nextPutAll: (self name first isVowel ifTrue: ['n '] ifFalse: [' ']); - nextPutAll: self name; - nextPutAll: ' is xxxxxxxxx.'; - cr; cr; - nextPutAll: 'Instance Variables'. - - self instVarNames asSortedCollection do: [:each | - stream - cr; tab; nextPutAll: each; - nextPut: $:; - tab; tab; - nextPutAll: '']. - - stream cr. - self instVarNames asSortedCollection do: [:each | - stream - cr; nextPutAll: each; - cr; tab; nextPutAll: '- xxxxx'; cr]. - - ^stream contents! Item was changed: ----- Method: InstructionStream>>skipCallPrimitive (in category 'decoding') ----- skipCallPrimitive + "If the receiver's method starts with a callPrimitive: bytecode, skip it." + | method encoderClass callPrimitiveCode | + method := self method. + encoderClass := method encoderClass. + callPrimitiveCode := encoderClass callPrimitiveCode. + (method byteAt: pc) = callPrimitiveCode ifTrue: + [pc := pc + (encoderClass bytecodeSize: callPrimitiveCode)]! - self method encoderClass callPrimitiveCode ifNotNil: - [:callPrimitiveCode| - (self method byteAt: pc) = callPrimitiveCode ifTrue: - [pc := pc + (self method encoderClass bytecodeSize: callPrimitiveCode)]]! Item was added: + ----- Method: MethodContext>>callPrimitive: (in category 'instruction decoding') ----- + callPrimitive: primNumber + "Evaluate the primitive, either normal or inlined, and answer the new context resulting from that + (either the sender if a successful non-inlined primitive, or the current context, if not)." + | maybePrimFailToken | + primNumber >= (1 << 15) ifTrue: "Inlined primitive, cannot fail" + [^self callInlinedPrimitive: primNumber]. + maybePrimFailToken := self doPrimitive: primNumber + method: method + receiver: receiver + args: self arguments. + "Normal primitive. Always at the beginning of methods." + (self isPrimFailToken: maybePrimFailToken) ifFalse: "On success return the result" + [^self methodReturnTop]. + "On failure, store the error code if appropriate and keep interpreting the method" + (method encoderClass isStoreAt: pc in: method) ifTrue: + [self at: stackp put: maybePrimFailToken last]. + ^self! From commits at source.squeak.org Wed Sep 16 18:42:21 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 16 18:42:22 2015 Subject: [squeak-dev] The Trunk: Compiler-eem.308.mcz Message-ID: Eliot Miranda uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-eem.308.mcz ==================== Summary ==================== Name: Compiler-eem.308 Author: eem Time: 16 September 2015, 11:42:08.344 am UUID: 0420593e-81fc-463c-8d0d-5a0cc7de2845 Ancestors: Compiler-eem.307 Addition: Scanner>>typedScan:do:, useful for tools (watch this space). Optimisation: Avoid an expensive visit of the parse tree if there are no temps when checking if they need nilling before being read. Polish: Better error message with bindTemp:. Decompile empty blocks as [] not [nil]. Nuke obsolete method creation methods generateMethodOfClass:trailer:from:. =============== Diff against Compiler-eem.307 =============== Item was changed: ----- Method: BlockNode>>nilReadBeforeWrittenTemps (in category 'code generation (closures)') ----- nilReadBeforeWrittenTemps | visitor readBeforeWritten | + temporaries isEmpty ifTrue: + [^self]. self accept: (visitor := OptimizedBlockLocalTempReadBeforeWrittenVisitor new). readBeforeWritten := visitor readBeforeWritten. temporaries reverseDo: [:temp| ((readBeforeWritten includes: temp) and: [temp isRemote not]) ifTrue: [statements addFirst: (AssignmentNode new variable: temp value: NodeNil)]]! Item was changed: ----- Method: BytecodeEncoder class>>extensionsFor:in:into: (in category 'instruction stream support') ----- extensionsFor: pc in: aCompiledMethod into: trinaryBlock "If the bytecode at pc is an extension, or if the bytecode at pc is preceeded by extensions, then evaluate aTrinaryBlock with the values of extA and extB and number of extension *bytes*. If the bytecode at pc is neither an extension or extended then evaluate with 0, 0, 0." + + | prevPC | + "If there is what appears to be an extension bytecode before this bytecode + then scan for the previous pc to confirm." + (pc - 2 >= aCompiledMethod initialPC + and: [self isExtension: (aCompiledMethod at: pc - 2)]) ifTrue: + [prevPC := aCompiledMethod pcPreviousTo: pc. + (self nonExtensionPcAt: prevPC in: aCompiledMethod) = pc ifTrue: + [^self extensionsAt: prevPC in: aCompiledMethod into: trinaryBlock]]. + ^self extensionsAt: pc in: aCompiledMethod into: trinaryBlock! - - self subclassResponsibility! Item was added: + ----- Method: BytecodeEncoder class>>nonExtensionPcAt:in: (in category 'instruction stream support') ----- + nonExtensionPcAt: pc in: method + "Answer the pc of the actual bytecode at pc in method, skipping past any preceeding extensions." + | thePC bytecode | + thePC := pc. + [self isExtension: (bytecode := method at: thePC)] whileTrue: + [thePC := thePC + (self bytecodeSize: bytecode)]. + ^thePC! Item was removed: - ----- Method: BytecodeEncoder>>generateMethodOfClass:trailer:from: (in category 'method generation') ----- - generateMethodOfClass: aCompiledMethodClass trailer: trailer from: methodNode - "methodNode is the root of a parse tree. Answer an instance of aCompiledMethodClass - in the receiver's bytecode set and using the receiver's method header format. - The argument, trailer, is arbitrary but is typically either the reference to the source code - that is stored with every CompiledMethod, or an encoding of the method's temporary names." - - self subclassResponsibility! Item was changed: ----- Method: Decompiler>>blockTo: (in category 'control') ----- blockTo: end "Decompile a range of code as in statementsTo:, but return a block node." + | exprs block oldBase lastStatementOfBlockIsNil | - | exprs block oldBase | oldBase := blockStackBase. blockStackBase := stack size. exprs := self statementsTo: end. + lastStatementOfBlockIsNil := pc < method endPC and: [exprs notEmpty and: [exprs last == (constTable at: 4)]]. + lastStatementOfBlockIsNil ifTrue: + [exprs := exprs allButLast]. block := constructor codeBlock: exprs returns: lastReturnPc = lastPc. blockStackBase := oldBase. lastReturnPc := -1. "So as not to mislead outer calls" ^block! Item was changed: ----- Method: Encoder>>bindTemp: (in category 'temps') ----- bindTemp: name "Declare a temporary; error not if a field or class variable." scopeTable at: name ifPresent:[:node| "When non-interactive raise the error only if its a duplicate" + node isTemp + ifTrue:[^self notify:'Name already used in this method'] - (node isTemp) - ifTrue:[^self notify:'Name is already defined'] ifFalse:[self warnAboutShadowed: name]]. ^self reallyBind: name! Item was removed: - ----- Method: EncoderForV3>>generateMethodOfClass:trailer:from: (in category 'method generation') ----- - generateMethodOfClass: aCompiledMethodClass trailer: trailer from: methodNode - "The receiver is the root of a parse tree. Answer an instance of aCompiledMethodClass. - The argument, trailer, is arbitrary but is typically either the reference to the source code - that is stored with every CompiledMethod, or an encoding of the method's temporary names." - - | primErrNode blkSize nLits literals header method stack | - primErrNode := methodNode primitiveErrorVariableName ifNotNil: - [self fixTemp: methodNode primitiveErrorVariableName]. - blkSize := (methodNode block sizeCodeForEvaluatedValue: self) - + (primErrNode - ifNil: [0] - ifNotNil: [primErrNode sizeCodeForStore: self "The VM relies on storeIntoTemp: (129)"]). - header := self computeMethodHeaderForNumArgs: methodNode arguments size - numTemps: self maxTemp - numLits: (nLits := (literals := self allLiterals) size) - primitive: methodNode primitive. - method := trailer - createMethod: blkSize - class: aCompiledMethodClass - header: header. - 1 to: nLits do: [:lit | method literalAt: lit put: (literals at: lit)]. - self streamToMethod: method. - stack := ParseStack new init. - primErrNode ifNotNil: [primErrNode emitCodeForStore: stack encoder: self]. - stack position: method numTemps. - [methodNode block emitCodeForEvaluatedValue: stack encoder: self] - on: Error "If an attempt is made to write too much code the method will be asked" - do: [:ex| "to grow, and the grow attempt will fail in CompiledMethod class>>#new:" - ex signalerContext sender method = (CompiledMethod class>>#new:) - ifTrue: [^self error: 'Compiler code size discrepancy'] - ifFalse: [ex pass]]. - stack position ~= (method numTemps + 1) ifTrue: - [^self error: 'Compiler stack discrepancy']. - self methodStreamPosition ~= (method size - trailer size) ifTrue: - [^self error: 'Compiler code size discrepancy']. - method needsFrameSize: stack size - method numTemps. - ^method! Item was removed: - ----- Method: EncoderForV3PlusClosures>>generateMethodOfClass:trailer:from: (in category 'method generation') ----- - generateMethodOfClass: aCompiledMethodClass trailer: trailer from: methodNode - "The receiver is the root of a parse tree. Answer an instance of aCompiledMethodClass. - The argument, trailer, is arbitrary but is typically either the reference to the source code - that is stored with every CompiledMethod, or an encoding of the method's temporary names." - - | primErrNode blkSize nLits locals literals header method stack | - primErrNode := methodNode primitiveErrorVariableName ifNotNil: - [self fixTemp: methodNode primitiveErrorVariableName]. - methodNode ensureClosureAnalysisDone. - self rootNode: methodNode. "this is for BlockNode>>sizeCodeForClosureValue:" - blkSize := (methodNode block sizeCodeForEvaluatedValue: self) - + (primErrNode - ifNil: [0] - ifNotNil: - [primErrNode - index: methodNode arguments size + methodNode temporaries size; - sizeCodeForStore: self "The VM relies on storeIntoTemp: (129)"]). - locals := methodNode arguments, methodNode temporaries, (primErrNode ifNil: [#()] ifNotNil: [{primErrNode}]). - self noteBlockExtent: methodNode block blockExtent hasLocals: locals. - header := self computeMethodHeaderForNumArgs: methodNode arguments size - numTemps: locals size - numLits: (nLits := (literals := self allLiterals) size) - primitive: methodNode primitive. - method := trailer - createMethod: blkSize - class: aCompiledMethodClass - header: header. - 1 to: nLits do: [:lit | method literalAt: lit put: (literals at: lit)]. - self streamToMethod: method. - stack := ParseStack new init. - primErrNode ifNotNil: [primErrNode emitCodeForStore: stack encoder: self]. - stack position: method numTemps. - [methodNode block emitCodeForEvaluatedValue: stack encoder: self] - on: Error "If an attempt is made to write too much code the method will be asked" - do: [:ex| "to grow, and the grow attempt will fail in CompiledMethod class>>#new:" - ex signalerContext sender method = (CompiledMethod class>>#new:) - ifTrue: [^self error: 'Compiler code size discrepancy'] - ifFalse: [ex pass]]. - stack position ~= (method numTemps + 1) ifTrue: - [^self error: 'Compiler stack discrepancy']. - self methodStreamPosition ~= (method size - trailer size) ifTrue: - [^self error: 'Compiler code size discrepancy']. - method needsFrameSize: stack size - method numTemps. - ^method! Item was added: + ----- Method: Scanner>>typedScan:do: (in category 'public access') ----- + typedScan: textOrString do: aBinaryBlock + "Evaluate aBinaryBlock with the token and its type for the first token in input, + mapping literals to type #literal and anything else to type #word." + | theTokensType atNumber theToken | + self initScannerForTokenization. + self scan: (ReadStream on: textOrString asString). + atNumber := hereChar notNil and: [hereChar isDigit]. + theTokensType := tokenType. + theToken := self advance. + (theToken == #- and: [atNumber and: [token isNumber]]) ifTrue: + [theToken := self advance negated]. + theToken isNumber ifTrue: [theTokensType := #number]. + ^aBinaryBlock + value: theToken + value: ((#(number string literal) includes: theTokensType) + ifTrue: [#literal] + ifFalse: [#word])! From commits at source.squeak.org Wed Sep 16 18:48:13 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 16 18:48:15 2015 Subject: [squeak-dev] The Trunk: System-eem.766.mcz Message-ID: Eliot Miranda uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-eem.766.mcz ==================== Summary ==================== Name: System-eem.766 Author: eem Time: 16 September 2015, 11:47:41 am UUID: 9c1c1e34-5f47-43ac-a6de-58be7bc6d6db Ancestors: System-mt.765 Fix some methods with carriage returns in their time stamps. =============== Diff against System-mt.765 =============== Item was changed: ----- Method: DataStream>>objectAt: (in category 'write and read') ----- objectAt: anInteger + "PRIVATE -- Read & return the object at a given stream position. anInteger is a relative file position. " - "PRIVATE -- Read & return the object at a given stream position. 08:18 tk anInteger is a relative file position. " | savedPosn anObject refPosn | savedPosn := byteStream position. "absolute" refPosn := self getCurrentReference. "relative position" byteStream position: anInteger + basePos. "was relative" anObject := self next. self setCurrentReference: refPosn. "relative position" byteStream position: savedPosn. "absolute" ^ anObject! Item was changed: ----- Method: FilePackage>>fullName: (in category 'accessing') ----- fullName: aString fullName := aString! Item was changed: ----- Method: FilePackage>>initialize (in category 'initialize') ----- initialize classes := Dictionary new. classOrder := OrderedCollection new. sourceSystem := ''. doIts := OrderedCollection new.! Item was changed: ----- Method: FilePackage>>packageName (in category 'accessing') ----- packageName ^FileDirectory localNameFor: self fullPackageName! Item was changed: ----- Method: SmartRefStream>>applyConversionMethodsTo:className:varMap: (in category 'import image segment') ----- applyConversionMethodsTo: objectIn className: className varMap: varMap "Modify the object's instance vars to have the proper values for its new shape. Mostly, fill in defaut values of new inst vars. Can substitute an object of a different class. (Beware: if substituted, varMap will not be correct when the new object is asked to convert.)" | anObject prevObject | self flag: #bobconv. anObject := objectIn. [ prevObject := anObject. anObject := anObject convertToCurrentVersion: varMap refStream: self. prevObject == anObject ] whileFalse. + ^anObject! - ^anObject - ! From hannes.hirzel at gmail.com Wed Sep 16 19:01:49 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Wed Sep 16 19:01:51 2015 Subject: [squeak-dev] [Reminder] SqueakMap entries for Squeak 5.0 Message-ID: Repost of what Chris Muller posted today to make it more visible: (includes links to the relevant wiki pages, SqueakMap delivers a one-click installation experience! Questions are welcome ) ------------------------------------------------------------------------------------------------ Just a gentle reminder, the best way to talk about SqueakMap and figure out how to improve it is to orient ourselves with the requirements: http://wiki.squeak.org/squeak/6183 Publishers who simply follow these publishing guidelines [1] are able to meet these requirements, and so what users see in the list is what WORKS. Thankfully, we DON'T have a blank list in 5.0. Thanks to those in the community who have gotten on board with the publishing guidelines we have packages on SM that actually WORK (if they were done right) and have single one of those requirements met. Users are able to consume those packages with one click instead of being forced to come begging to the list for "how to load it".. We will get there! [1] -- SqueakMap Publishing Guidelines http://wiki.squeak.org/squeak/6182 [2] -- How to designate existing SqueakMap packages for a new version of Squeak http://wiki.squeak.org/squeak/6180 From commits at source.squeak.org Wed Sep 16 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 16 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150916215502.6520.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008966.html Name: Kernel-eem.951 Ancestors: Kernel-eem.950 Implement callPrimitive: in the simulator so that, for example, the debugger does not get into an infinite recursion when accepting a new version of a method that has a primitive. Simplify skipCallPrimitive. Fix classCommentBlank so that it always answers the blank, even when there's an existing comment (shurely shome mistake, hic, ed).. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008967.html Name: Compiler-eem.308 Ancestors: Compiler-eem.307 Addition: Scanner>>typedScan:do:, useful for tools (watch this space). Optimisation: Avoid an expensive visit of the parse tree if there are no temps when checking if they need nilling before being read. Polish: Better error message with bindTemp:. Decompile empty blocks as [] not [nil]. Nuke obsolete method creation methods generateMethodOfClass:trailer:from:. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008968.html Name: System-eem.766 Ancestors: System-mt.765 Fix some methods with carriage returns in their time stamps. ============================================= From commits at source.squeak.org Wed Sep 16 23:42:32 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 16 23:42:34 2015 Subject: [squeak-dev] The Trunk: Kernel-eem.952.mcz Message-ID: Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.952.mcz ==================== Summary ==================== Name: Kernel-eem.952 Author: eem Time: 16 September 2015, 4:42:02.543 pm UUID: 31ef882e-64d5-4e23-8e4f-d870d3bc0086 Ancestors: Kernel-eem.951 The comparison of the initial literal in plugin primitive methods needs to compare the first two entries, not the first three. =============== Diff against Kernel-eem.951 =============== Item was changed: ----- Method: CompiledMethod>>= (in category 'comparing') ----- = method "Answer whether the receiver implements the same code as the argument, method. Here ``same code'' means that if the receiver's source is compiled with the same compiler it should produce the same sequence of bytecodes and literals, same trailer and same properties. Hence this definition of #= (only one of many plausible definitions) can be used to quickly identify changes in the compiler's output." | numLits | method isCompiledMethod ifFalse: [^false]. self size = method size ifFalse: [^false]. self header = method header ifFalse: [^false]. "N.B. includes numLiterals comparison." self initialPC to: self endPC do: [:i | (self at: i) = (method at: i) ifFalse: [^false]]. numLits := self numLiterals. 1 to: numLits do: [:i| | lit1 lit2 | lit1 := self literalAt: i. lit2 := method literalAt: i. (lit1 == lit2 or: [lit1 literalEqual: lit2]) ifFalse: [(i = 1 and: [#(117 120) includes: self primitive]) ifTrue: [lit1 isArray ifTrue: + [(lit2 isArray and: [(lit1 first: 2) = (lit2 first: 2)]) ifFalse: - [(lit2 isArray and: [lit1 allButLast = lit2 allButLast]) ifFalse: [^false]] ifFalse: "ExternalLibraryFunction" [(lit1 analogousCodeTo: lit2) ifFalse: [^false]]] ifFalse: [i = (numLits - 1) ifTrue: "properties" [(self properties analogousCodeTo: method properties) ifFalse: [^false]] ifFalse: "last literal (methodClassAssociation) of class-side methods is not unique" [(i = numLits and: [lit1 isVariableBinding and: [lit2 isVariableBinding and: [lit1 key == lit2 key and: [lit1 value == lit2 value]]]]) ifFalse: [^false]]]]]. ^true! From commits at source.squeak.org Thu Sep 17 00:26:34 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 17 00:26:36 2015 Subject: [squeak-dev] The Trunk: Compiler-eem.309.mcz Message-ID: Eliot Miranda uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-eem.309.mcz ==================== Summary ==================== Name: Compiler-eem.309 Author: eem Time: 16 September 2015, 5:26:18.544 pm UUID: 89f65602-802e-41c5-b52c-c85cf61e299f Ancestors: Compiler-eem.308 Fix the compiler to collapse optimized block temps of the same name to the same temp location for a better debugging UX. =============== Diff against Compiler-eem.308 =============== Item was changed: ----- Method: BlockNode>>addHoistedTemps: (in category 'code generation (closures)') ----- addHoistedTemps: additionalTemporaries "" + | tempsToBeMerged additionalTempsToAdd | additionalTemporaries do: [:temp| temp definingScope ifNil: [temp definingScope: self]]. + (temporaries isNil or: [temporaries isEmpty]) ifTrue: + [temporaries := additionalTemporaries copy. + ^self]. + tempsToBeMerged := additionalTemporaries select: + [:t| + t isBlockArg + and: [temporaries anySatisfy: [:existing| existing isBlockArg and: [existing key = t key]]]]. + additionalTempsToAdd := tempsToBeMerged isEmpty + ifTrue: [additionalTemporaries copy] + ifFalse: [additionalTemporaries reject: [:temp| tempsToBeMerged identityIncludes: temp]]. temporaries := (temporaries isNil or: [temporaries isEmpty]) + ifTrue: [additionalTempsToAdd] - ifTrue: [additionalTemporaries copy] ifFalse: [temporaries last isIndirectTempVector + ifTrue: [temporaries allButLast, additionalTempsToAdd, { temporaries last }] + ifFalse: [temporaries, additionalTempsToAdd]]. + tempsToBeMerged do: + [:t| | merge | + merge := temporaries detect: [:existing| existing isBlockArg and: [existing key = t key]]. + merge absorbHoistedTemp: t]! - ifTrue: [temporaries allButLast, additionalTemporaries, { temporaries last }] - ifFalse: [temporaries, additionalTemporaries]]! Item was changed: ----- Method: BytecodeEncoder>>bindTemp: (in category 'temps') ----- bindTemp: name "Declare a temporary; error not if a field or class variable or out-of-scope temp. Read the comment in Encoder>>bindBlockArg:within: and subclass implementations." self supportsClosureOpcodes ifFalse: [^super bindTemp: name]. scopeTable at: name ifPresent: [:node| "When non-interactive raise the error only if it is a duplicate" node isTemp ifTrue:[node scope >= 0 ifTrue: + [^self notify: 'Name already used in this method']] - [^self notify:'Name is already defined']] ifFalse:[self warnAboutShadowed: name]]. ^self reallyBind: name! Item was added: + ----- Method: TempVariableNode>>absorbHoistedTemp: (in category 'code generation (closures)') ----- + absorbHoistedTemp: aTempVar + "Collapse aTempVar into the receiver, being sure to update any closure analysis." + aTempVar copyScopeAccessTo: self. + aTempVar becomeForward: self! Item was added: + ----- Method: TempVariableNode>>copyScopeAccessTo: (in category 'code generation (closures)') ----- + copyScopeAccessTo: aTempVar + "For absorbHoistedTemp:, copy the receiver's reads and writes into the record in aTempVar." + readingScopes ifNotNil: + [readingScopes keysAndValuesDo: + [:scopeBlock :reads| + reads do: + [:location| + aTempVar addReadWithin: scopeBlock "" at: location]]]. + writingScopes ifNotNil: + [writingScopes keysAndValuesDo: + [:scopeBlock :writes| + writes do: + [:location| + aTempVar addWriteWithin: scopeBlock "" at: location]]]! Item was changed: + (PackageInfo named: 'Compiler') postscript: '"Make sure all affected methods are recompiled" + UIManager default + informUser: ''Recompiling affected methods'' + during: + [(self systemNavigation allMethodsSelect: + [:m| | ebc | "All affected methods send one of these optimized selectors..." + (#(to:do: to:by:do: ifNotNil: ifNil:ifNotNil: ifNotNil:ifNil:) anySatisfy: [:l| m refersToLiteral: l]) + "but the textDomain properties confuse method comparison below..." + and: [(m propertyValueAt: #textDomain ifAbsent: nil) isNil + and: [m numTemps > m numArgs "and have non-argument temporaries in them..." + or: [(ebc := m embeddedBlockClosures) notEmpty + and: [ebc anySatisfy: [:bc| bc numTemps > bc numArgs]]]]]]) do: + [:mr| | old new | + old := mr compiledMethod. + "do a test recompile of the method..." + new := (mr actualClass compile: old getSource asString notifying: nil trailer: old trailer ifFail: nil) method. + "and if it changed, report it to the transcript and really recompile it..." + old ~= new ifTrue: + [Transcript cr. old printReferenceOn: Transcript. Transcript flush. + mr actualClass recompile: old selector]]]'! - (PackageInfo named: 'Compiler') postscript: '"Migrate preference value" - Scanner allowBlockArgumentAssignment: Preferences allowBlockArgumentAssignment'! From karlramberg at gmail.com Thu Sep 17 11:09:27 2015 From: karlramberg at gmail.com (karl ramberg) Date: Thu Sep 17 11:09:30 2015 Subject: [squeak-dev] The Trunk: SMLoader-cmm.85.mcz In-Reply-To: References: <55f8785b.89dd370a.4e43f.ffffc81dSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Ok Karl On Wed, Sep 16, 2015 at 6:39 PM, Chris Muller wrote: > > Maybe it would be nice if the filters where off when opening the > SqueakMap > > browser. With filters on it seems to be empty and not functioning. > > No. Just a gentle reminder, the best way to talk about SqueakMap and > figure out how to improve it is to orient ourselves with the > requirements: > > http://wiki.squeak.org/squeak/6183 > > Presenting everything in the list would violate requirement #4. > Publishers who simply follow these publishing guidelines [1] are able > to meet these requirements, and so what users see in the list is what > WORKS. If we show "everything" then we're hiding what works, and SM > becomes useless again. > > Why do you say its an empty list? I just checked Squeak 5.0 and there > are at least 20 packages showing up in there..? > > IF nothing were to show up in the list when "Safely-available" filter > (and nothing else) is checked, then that's on us as a community. It > simply means that we didn't care enough to take the 5 minutes > necessary to recertify our packages for the latest Squeak. It is what > it is, but let's not fake out the "truth". > > Thankfully, we DON'T have a blank list in 5.0. Thanks to those in the > community who have gotten on board with the publishing guidelines we > have packages on SM that actually WORK (if they were done right) and > have single one of those requirements met. Users are able to consume > those packages with one click instead of being forced to come begging > to the list for "how to load it".. > > We will get there! > > [1] -- SqueakMap Publishing Guidelines > http://wiki.squeak.org/squeak/6182 > > [2] -- How to designate existing SqueakMap packages for a new version of > Squeak > http://wiki.squeak.org/squeak/6180 > > > There is always warnings about package not being compatible when you try > to > > load them anyway. > > > > Karl > > > > On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller > wrote: > >> > >> After review and some thought, it has become clear to me that Dave's > >> change is incorrect. Please take a look at the SqueakMap filters and > >> consider them from the context of the use-cases -- what users need to > >> do with SqueakMap, and NOT from the context of a database that needs > >> to produce generalized "query results" <---- because it doesn't. > >> > >> "Published" are the ones which have software to install, while > >> "Auto-installable" shows only packages that are installable from the > >> "Install" menu selection within the image. These two filters are > >> useful together in a restricting fashion, not an inflating one, so > >> that newbies can see what's ready to go. > >> > >> It was then that I also realized that Hannes' combination was not a > >> use-case either. The use-cases we have are: 1) user wants to install > >> software or, 2) user wants to see what they have already installed. > >> Seeing a cumulative list of both installed and uninstalled satisfies > >> neither use-case. > >> > >> Nevertheless you may once again "Clear all filters" (which was broken > >> by Dave's commit) if you want to see everything. > >> > >> I still say SqueakMap catalog can and needs improvement, but we need > >> to really consider our changes because its clear that G?ran put a lot > >> of thought into the usage of SqueakMap and its role in the community; > >> so I think we can afford to be a bit more skeptical before thinking > >> something like that was a bug in the first place and for nine years > >> running.. > >> > >> > >> On Tue, Sep 15, 2015 at 2:58 PM, wrote: > >> > Chris Muller uploaded a new version of SMLoader to project The Trunk: > >> > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz > >> > > >> > ==================== Summary ==================== > >> > > >> > Name: SMLoader-cmm.85 > >> > Author: cmm > >> > Time: 15 September 2015, 2:58:07.033 pm > >> > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b > >> > Ancestors: SMLoader-dtl.84 > >> > > >> > Revert dtl.84, because it broke the Catalog filters. > >> > > >> > =============== Diff against SMLoader-dtl.84 =============== > >> > > >> > Item was changed: > >> > ----- Method: SMLoaderPlus>>packageListCalculated (in category > >> > 'lists') ----- > >> > packageListCalculated > >> > "Return a list of the SMPackages that should be visible > >> > by applying all the filters. Also filter based on the > currently > >> > selected category - if any." > >> > ^ self packages select: [:p | > >> > + filters allSatisfy: [:currFilter | > >> > - filters anySatisfy: [:currFilter | > >> > currFilter isSymbol > >> > ifTrue: [(self perform: currFilter) > >> > value: p] > >> > ifFalse: [self package: p > >> > filteredByCategory: (map object: currFilter)]]]! > >> > > >> > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150917/b5b01ec9/attachment.htm From commits at source.squeak.org Thu Sep 17 20:18:29 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 17 20:18:32 2015 Subject: [squeak-dev] The Trunk: Tools-eem.633.mcz Message-ID: Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-eem.633.mcz ==================== Summary ==================== Name: Tools-eem.633 Author: eem Time: 17 September 2015, 1:18:07.129 pm UUID: 2a5a8395-fa44-4d48-b6ed-a920c18dbc02 Ancestors: Tools-mt.632 Fix hard VM crash when defining quick methods from MNUs in the debugger. The bug is that the sender context (Message>>sentTo:) is doing a perform:withArguments:[inSuperclass:] but the receiver and arguments have already been removed from the context, so simply backing up to the point of send and proceeding will have disastrous consequences; there must be a receiver and arguments on the stack. So if the arguments are unavailable we simply restart the context inmstead of backing up to the point of send. To reproduce: 0. make sure e.g. Object>>#zork is unimplemented 1. evaluate "nil zork" 2. in the debugger examine the doesNotUnderstand: context and then hit proceed. 3. click the Create button and define Object>>#zork ^nil 4. (the debugger sets the active context to Message>>sentTo:) hit proceed Before the VM woudl crash. Now the debugger sets the pc to the start of the Message>>sentTo: method. =============== Diff against Tools-mt.632 =============== Item was changed: ----- Method: Debugger>>contents:notifying: (in category 'accessing') ----- contents: aText notifying: aController "The retrieved information has changed and its source must now be updated. In this case, the retrieved information is the method of the selected context." | result selector classOfMethod category h ctxt newMethod | contextStackIndex = 0 ifTrue: [^false]. self selectedContext isExecutingBlock ifTrue: [h := self selectedContext activeHome. h ifNil: [self inform: 'Method for block not found on stack, can''t edit and continue'. ^false]. (self confirm: 'I will have to revert to the method from\which this block originated. Is that OK?' withCRs) ifFalse: [^false]. self resetContext: h changeContents: false. "N.B. Only reset the contents if the compilation succeeds. If contents are reset when compilation fails both compiler error message and modifications are lost." (result := self contents: aText notifying: aController) ifTrue: [self contentsChanged]. ^result]. classOfMethod := self selectedClass. category := self selectedMessageCategoryName. selector := self selectedClass newParser parseSelector: aText. (selector == self selectedMessageName or: [(self selectedMessageName beginsWith: 'DoIt') and: [selector numArgs = self selectedMessageName numArgs]]) ifFalse: [self inform: 'can''t change selector'. ^false]. selector := classOfMethod compile: aText classified: category notifying: aController. selector ifNil: [^false]. "compile cancelled" contents := aText. newMethod := classOfMethod compiledMethodAt: selector. newMethod isQuick ifTrue: + [self cutBackExecutionToSenderContext]. - [self down. - self selectedContext jump: (self selectedContext previousPc - self selectedContext pc)]. ctxt := interruptedProcess popTo: self selectedContext. ctxt == self selectedContext ifFalse: [self inform: 'Method saved, but current context unchanged\because of unwind error. Click OK to see error' withCRs] ifTrue: [newMethod isQuick ifFalse: [interruptedProcess restartTopWith: newMethod; stepToSendOrReturn]. contextVariablesInspector object: nil]. self resetContext: ctxt. Smalltalk isMorphic ifTrue: [World addAlarm: #changed: withArguments: #(contentsSelection) for: self at: (Time millisecondClockValue + 200)]. ^true! Item was added: + ----- Method: Debugger>>cutBackExecutionToSenderContext (in category 'private') ----- + cutBackExecutionToSenderContext + "When accepting a new version of a method which can't be simulated (i.e. a quick method) we + must cut back to the sender. But this is non-trivial. If the quick method has been reached via + a perform: (as it is when one uses Create toi implement a method from an MNU) then the relevant + arguments won't be on the stack and we can't simply proceed without crashing the VM." + | oldContext context sel | + oldContext := self selectedContext. + self down. + context := self selectedContext. + context jump: (context previousPc - context pc). + sel := context selectorToSendOrSelf. + sel numArgs = oldContext method numArgs + ifTrue: + [context push: oldContext receiver. + oldContext arguments do: + [:arg| context push: arg]] + ifFalse: + [context privRefresh; stepToSendOrReturn]! From commits at source.squeak.org Thu Sep 17 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 17 21:55:03 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150917215502.4357.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008969.html Name: Kernel-eem.952 Ancestors: Kernel-eem.951 The comparison of the initial literal in plugin primitive methods needs to compare the first two entries, not the first three. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008970.html Name: Compiler-eem.309 Ancestors: Compiler-eem.308 Fix the compiler to collapse optimized block temps of the same name to the same temp location for a better debugging UX. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008971.html Name: Tools-eem.633 Ancestors: Tools-mt.632 Fix hard VM crash when defining quick methods from MNUs in the debugger. The bug is that the sender context (Message>>sentTo:) is doing a perform:withArguments:[inSuperclass:] but the receiver and arguments have already been removed from the context, so simply backing up to the point of send and proceeding will have disastrous consequences; there must be a receiver and arguments on the stack. So if the arguments are unavailable we simply restart the context inmstead of backing up to the point of send. To reproduce: 0. make sure e.g. Object>>#zork is unimplemented 1. evaluate "nil zork" 2. in the debugger examine the doesNotUnderstand: context and then hit proceed. 3. click the Create button and define Object>>#zork ^nil 4. (the debugger sets the active context to Message>>sentTo:) hit proceed Before the VM woudl crash. Now the debugger sets the pc to the start of the Message>>sentTo: method. ============================================= From peter at ozzard.org Fri Sep 18 09:47:52 2015 From: peter at ozzard.org (Peter Crowther) Date: Fri Sep 18 09:47:55 2015 Subject: [squeak-dev] Ni - a strange little language In-Reply-To: <55F9596C.3060108@krampe.se> References: <55F9596C.3060108@krampe.se> Message-ID: Congratulations, you made the main headline on The Register as I type this. http://www.theregister.co.uk/2015/09/18/we_are_the_knights_who_code_ni/ Cheers, - Peter On 16 September 2015 at 12:58, G?ran Krampe wrote: > Hi guys! > > Just wanted to give a pointer to a little language I am implementing: > > http://goran.krampe.se/2015/09/16/ni-a-strange-little-language/ > > Is it a new Smalltalk-80? No. > Is it Smalltalkish? Yes. But still quite different. :) > > The article tries to introduce some of the funkier aspects of Ni. In > essence Ni is a homoiconic dynamically typed garbage collected 100% live > language similar to Lisp/Rebol/Forth in its simplicity. > > But it also has Smalltalk keyword syntax, Smalltalk non local return, > blocks-as-closures as in Smalltalk and well, perhaps a few more odds and > ends similar to Smalltalk. > > And one of the next steps is adding objects to it. This will be based on a > model of cloning and delegation and an object, so a bit closer to Self > there. > > Why would you want to look at it? Because it breaks (or will break) a few > barriers that most Smalltalks still suffer from... easy integration with > C/C++, multithreading, embeddability and so on. > > Hope you find it interesting! > > regards, G?ran > > PS. Fast? Nope. I mean, its decent for an AST interpreter but I haven't > spent time optimizing it yet - it uses dynamically allocated things and > methods (dynamic dispatch) quite heavily today. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150918/163a51f9/attachment.htm From hannes.hirzel at gmail.com Fri Sep 18 11:19:21 2015 From: hannes.hirzel at gmail.com (H. Hirzel) Date: Fri Sep 18 11:19:24 2015 Subject: [squeak-dev] Ni - a strange little language In-Reply-To: References: <55F9596C.3060108@krampe.se> Message-ID: Some of the comments on theregister might need some attention. Here some of my questions: a) I wonder how Ni is related to Nim http://nim-lang.org/? b) The Ni article mentinons OrderedCollections and Dictionaries --- where can I find an example which demonstrates how they are used? c) Is there a JSON reader and writer for OrderedCollections and Dictionaries? d) What kind of string operations does it support? e) The Ni to Nim translator is fairly short. e1) How would a Ni to Smalltalk translator look like? (LOC estimate) e2) Or a Smalltalk to Ni translator (LOC estimate)? f) Could Ni be an alternative for plug-in writing of Smalltalk? g) What about speed of compiled Ni / Nim code? --Hannes On 9/18/15, Peter Crowther wrote: > Congratulations, you made the main headline on The Register as I type this. > > http://www.theregister.co.uk/2015/09/18/we_are_the_knights_who_code_ni/ > > Cheers, > > - Peter > > On 16 September 2015 at 12:58, G?ran Krampe wrote: > >> Hi guys! >> >> Just wanted to give a pointer to a little language I am implementing: >> >> http://goran.krampe.se/2015/09/16/ni-a-strange-little-language/ >> >> Is it a new Smalltalk-80? No. >> Is it Smalltalkish? Yes. But still quite different. :) >> >> The article tries to introduce some of the funkier aspects of Ni. In >> essence Ni is a homoiconic dynamically typed garbage collected 100% live >> language similar to Lisp/Rebol/Forth in its simplicity. >> >> But it also has Smalltalk keyword syntax, Smalltalk non local return, >> blocks-as-closures as in Smalltalk and well, perhaps a few more odds and >> ends similar to Smalltalk. >> >> And one of the next steps is adding objects to it. This will be based on >> a >> model of cloning and delegation and an object, so a bit closer to Self >> there. >> >> Why would you want to look at it? Because it breaks (or will break) a few >> barriers that most Smalltalks still suffer from... easy integration with >> C/C++, multithreading, embeddability and so on. >> >> Hope you find it interesting! >> >> regards, G?ran >> >> PS. Fast? Nope. I mean, its decent for an AST interpreter but I haven't >> spent time optimizing it yet - it uses dynamically allocated things and >> methods (dynamic dispatch) quite heavily today. >> >> > From goran at krampe.se Fri Sep 18 11:51:00 2015 From: goran at krampe.se (=?UTF-8?Q?G=c3=b6ran_Krampe?=) Date: Fri Sep 18 11:51:04 2015 Subject: [squeak-dev] Ni - a strange little language In-Reply-To: References: <55F9596C.3060108@krampe.se> Message-ID: <55FBFAA4.4000500@krampe.se> Hi! On 09/18/2015 01:19 PM, H. Hirzel wrote: > Some of the comments on theregister might need some attention. Ahh... yeah. I will try to post some replies later today. I need to register there first I guess. > Here some of my questions: > > a) I wonder how Ni is related to Nim http://nim-lang.org/? 1. Its implemented in Nim. 2. Its meant to mix with Nim, like using Nim libraries easily etc. 3. It reuses as much as possible of Nim mechanisms, like its GC etc. > b) The Ni article mentinons OrderedCollections and Dictionaries --- > where can I find an example which demonstrates how they are used? I mentioned those classes as a reference to Smalltalkers. Ni only has blocks so far (OrderedCollection) but will also have Dictionaries in the form of "objects" like in Javascript kinda. Ni is meant to "keep small" and not fatten up like Smalltalk has done with about 80 different collections. ;) > c) Is there a JSON reader and writer for OrderedCollections and Dictionaries? Hehe, ehm, no? :) But yeah, easy for me to tap into Nim's libraries and add that. > d) What kind of string operations does it support? Not much at all yet, its still a toy. But I will expose the Nim libraries in Ni so there will be no shortage of functionality. The hard part is to select a reasonable complete subset that is small. > e) The Ni to Nim translator is fairly short. Its not a translator, its an interpreter. Ni is never translated to Nim. Although one can entertain such thoughts in the future, since Nim has very powerful code generation mechanisms. > e1) How would a Ni to Smalltalk translator look like? (LOC estimate) No idea, its hard to... see the usefulness I think. > e2) Or a Smalltalk to Ni translator (LOC estimate)? This is more interesting, since I think Ni can be made to look/feel like Smalltalk quite easily. If one would implement a bit of base libraries using the same method names etc, it could map quite easily. But I don't personally intend to make a "Smalltalk duplicate" - that's boring. I borrow what I like, but renew if I think there is better ways. Rebol has lots of interesting techniques for example. A silly trivial example, in Ni I can use "?" in method names. So I want to use that as a convention for methods that return booleans. Like the "end?" call in the code sample. > f) Could Ni be an alternative for plug-in writing of Smalltalk? No, but Nim already is. The SqueakNim tool already autogenerates FFI stubs for Nim, so very easy to use. We use Nim extensively at 3DICC for this. > g) What about speed of compiled Ni / Nim code? Nim code is basically same speed as C/C++. So very fast. It compiles via GCC by generating very efficient C/C++ code. Ni is a plain interpreter. I can probably reach Python speeds with it, but I don't intend to go further. For the moment its completely unoptimized and falls short of that, but on the other hand I can very easily tap into Nim for heavy lifting. Much easier than in Smalltalk. > --Hannes regards, G?ran From mbaehr at email.archlab.tuwien.ac.at Fri Sep 18 12:00:18 2015 From: mbaehr at email.archlab.tuwien.ac.at (=?utf-8?q?Martin_B=C3=A4hr?=) Date: Fri Sep 18 12:00:24 2015 Subject: [squeak-dev] Ni - a strange little language In-Reply-To: References: <55F9596C.3060108@krampe.se> Message-ID: <1442577526-sup-1902@email.archlab.tuwien.ac.at> Excerpts from Peter Crowther's message of 2015-09-18 11:47:52 +0200: > Congratulations, you made the main headline on The Register as I type this. > > http://www.theregister.co.uk/2015/09/18/we_are_the_knights_who_code_ni/ i was going to suggest "the programmers who say ni" and ask if they would bring us the holy grail of software development... greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin B?hr working in china http://societyserver.org/mbaehr/ From goran at krampe.se Fri Sep 18 14:43:31 2015 From: goran at krampe.se (=?UTF-8?Q?G=c3=b6ran_Krampe?=) Date: Fri Sep 18 14:43:37 2015 Subject: [squeak-dev] Ni - a strange little language In-Reply-To: References: <55F9596C.3060108@krampe.se> Message-ID: <55FC2313.5050902@krampe.se> Hey! On 09/18/2015 11:47 AM, Peter Crowther wrote: > Congratulations, you made the main headline on The Register as I type this. > > http://www.theregister.co.uk/2015/09/18/we_are_the_knights_who_code_ni/ Hehe, but that article was.... not an article. Could almost have been written by a robot - perhaps it was. regards, G?ran From herbertkoenig at gmx.net Fri Sep 18 16:06:26 2015 From: herbertkoenig at gmx.net (=?UTF-8?Q?Herbert_K=c3=b6nig?=) Date: Fri Sep 18 16:06:30 2015 Subject: [squeak-dev] Fwd: Squeak 5.0 All in one crashed on my Pi after running 3 weeks at 40% CPU In-Reply-To: <55FC3607.6020905@gmx.net> References: <55FC3607.6020905@gmx.net> Message-ID: <55FC3682.40009@gmx.net> Skipped content of type multipart/alternative-------------- next part -------------- Segmentation fault Fri Sep 18 17:14:02 2015 /home/pi/Squeak-50-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-ARM/lib/squeak/5.0-3410/squeak Squeak VM version: 5.0-3410 Sat Jul 18 21:39:09 PDT 2015 gcc 4.6.3 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-eem.1426 uuid: 94ab92ba-c5c4-4953-8566-a4cd9c38df1f Jul 18 2015 With: StackToRegisterMappingCogit VMMaker.oscog-eem.1427 uuid: c5cb18c5-f69e-4e41-8f87-943a495659b4 Jul 18 2015 Revision: VM: r3410 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2015-07-18 19:15:20 -0700 Plugins: r3405 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Build host: Linux pi2 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux plugin path: /home/pi/Squeak-50-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-ARM/bin/../lib/squeak/5.0-3410 [default: /home/pi/Squeak-50-All-in-One/Squeak-5.0-All-in-One.app/Contents/LinuxAndWindows/Linux-ARM/lib/squeak/5.0-3410/] C stack backtrace & registers: r0 0x00000001 r1 0x000003cc r2 0x000003cc r3 0x00000000 r4 0x001fd710 r5 0x014b5b00 r6 0x0000000d r7 0x011ee450 r8 0x00d91a68 r9 0x018058c0 r10 0x001e898e fp 0xbe7c7680 ip 0x00000513 sp 0xbe77e6c0 lr 0x000a3a38 pc 0xfe341a08 *[0x0] [0x0] Smalltalk stack dump: 0xbe7c7680 M BitBlt>copy:from:in:fillColor:rule: 0x11ee450: a(n) BitBlt 0xbe7c76b4 M [] in PictureCompare>compareSimplified:form2: 0x28e5bb8: a(n) PictureCompare 0xbe7c76e4 M Array(SequenceableCollection)>collect: 0x2a1fb88: a(n) Array 0xbe7c7700 M PictureCompare>compareSimplified:form2: 0x28e5bb8: a(n) PictureCompare 0xbe7c7720 M PictureCompare>compare 0x28e5bb8: a(n) PictureCompare 0xbe7c7760 M PictureCompare>analyzeCameraQuarter 0x28e5bb8: a(n) PictureCompare 0xbe7bf484 M PictureCompare>(nil) 0x28e5bb8: a(n) PictureCompare 0xbe7bf4a8 M Compiler>evaluateCue:ifFail: 0x26483f0: a(n) Compiler 0xbe7bf4d4 I Compiler>evaluateCue:ifFail:logged: 0x26483f0: a(n) Compiler 0xbe7bf4fc M Compiler>evaluate:in:to:notifying:ifFail:logged: 0x26483f0: a(n) Compiler 0xbe7bf53c I [] in SmalltalkEditor(TextEditor)>evaluateSelectionAndDo: 0x28dc748: a(n) SmalltalkEditor 0xbe7bf558 M BlockClosure>on:do: 0x2648610: a(n) BlockClosure 0xbe7bf58c I SmalltalkEditor(TextEditor)>evaluateSelectionAndDo: 0x28dc748: a(n) SmalltalkEditor 0xbe7bf5b0 I SmalltalkEditor(TextEditor)>evaluateSelection 0x28dc748: a(n) SmalltalkEditor 0xbe7bf5d0 I SmalltalkEditor(TextEditor)>doIt 0x28dc748: a(n) SmalltalkEditor 0xbe7bf5e8 M SmalltalkEditor(TextEditor)>doIt: 0x28dc748: a(n) SmalltalkEditor 0xbe7bf60c M SmalltalkEditor(TextEditor)>dispatchOnKeyboardEvent: 0x28dc748: a(n) SmalltalkEditor 0xbe7bf628 M SmalltalkEditor(TextEditor)>keyStroke: 0x28dc748: a(n) SmalltalkEditor 0xbe7bf648 M [] in TextMorphForEditView(TextMorph)>keyStroke: 0x2623128: a(n) TextMorphForEditView 0xbe7bf66c M TextMorphForEditView(TextMorph)>handleInteraction:fromEvent: 0x2623128: a(n) TextMorphForEditView 0xbe7bf68c M TextMorphForEditView>handleInteraction:fromEvent: 0x2623128: a(n) TextMorphForEditView 0xbe7bf6b4 M [] in TextMorphForEditView(TextMorph)>keyStroke: 0x2623128: a(n) TextMorphForEditView 0xbe7bf6d4 I StandardToolSet class>codeCompletionAround:textMorph:keyStroke: 0x1814200: a(n) StandardToolSet class 0xbe7bf6f8 M ToolSet class>codeCompletionAround:textMorph:keyStroke: 0x180f7f8: a(n) ToolSet class 0xbe7bf71c M TextMorphForEditView(TextMorph)>keyStroke: 0x2623128: a(n) TextMorphForEditView 0xbe7bf73c M TextMorphForEditView>keyStroke: 0x2623128: a(n) TextMorphForEditView 0xbe7bf75c M TextMorphForEditView(TextMorph)>handleKeystroke: 0x2623128: a(n) TextMorphForEditView 0xbe77f50c M KeyboardEvent>sentTo: 0x2647ec8: a(n) KeyboardEvent 0xbe77f528 M TextMorphForEditView(Morph)>handleEvent: 0x2623128: a(n) TextMorphForEditView 0xbe77f544 M TextMorphForEditView(Morph)>handleFocusEvent: 0x2623128: a(n) TextMorphForEditView 0xbe77f56c M [] in HandMorph>sendFocusEvent:to:clear: 0x1712518: a(n) HandMorph 0xbe77f588 M BlockClosure>on:do: 0x2647f88: a(n) BlockClosure 0xbe77f5b4 M PasteUpMorph>becomeActiveDuring: 0x1938780: a(n) PasteUpMorph 0xbe77f5d8 M HandMorph>sendFocusEvent:to:clear: 0x1712518: a(n) HandMorph 0xbe77f600 M HandMorph>sendEvent:focus:clear: 0x1712518: a(n) HandMorph 0xbe77f624 M HandMorph>sendKeyboardEvent: 0x1712518: a(n) HandMorph 0xbe77f648 M HandMorph>handleEvent: 0x1712518: a(n) HandMorph 0xbe77f674 M HandMorph>processEvents 0x1712518: a(n) HandMorph 0xbe77f690 M [] in WorldState>doOneCycleNowFor: 0x237ba70: a(n) WorldState 0xbe77f6b4 M Array(SequenceableCollection)>do: 0x14cfa10: a(n) Array 0xbe77f6d0 M WorldState>handsDo: 0x237ba70: a(n) WorldState 0xbe77f6f0 M WorldState>doOneCycleNowFor: 0x237ba70: a(n) WorldState 0xbe77f70c M WorldState>doOneCycleFor: 0x237ba70: a(n) WorldState 0xbe77f728 M PasteUpMorph>doOneCycle 0x1938780: a(n) PasteUpMorph 0xbe77f740 M [] in MorphicProject>spawnNewProcess 0x1a24a30: a(n) MorphicProject 0xbe77f760 I [] in BlockClosure>newProcess 0x2648210: a(n) BlockClosure Most recent primitives copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits @ @ copyBits stack page bytes 4096 available headroom 2788 minimum unused headroom 2260 (Segmentation fault) From tim at rowledge.org Fri Sep 18 17:38:33 2015 From: tim at rowledge.org (tim Rowledge) Date: Fri Sep 18 17:38:36 2015 Subject: [squeak-dev] Fwd: Squeak 5.0 All in one crashed on my Pi after running 3 weeks at 40% CPU In-Reply-To: <55FC3682.40009@gmx.net> References: <55FC3607.6020905@gmx.net> <55FC3682.40009@gmx.net> Message-ID: On 18-09-2015, at 9:06 AM, Herbert K?nig wrote: > since the 5.0 all in one I use it 24/7 on my Pi without any problems. > The recent uninterrupted run was about three weeks (there had been a two > week run before) and a few minutes ago it crashed with no apparent reason. I don?t think I?ve ever run anything for that long continuously. That long implies it isn?t any simple run-out-of-memory problem, or code-generation. The best I can think of right now is that the *data* you had got in this case was a bit ugly and upset the bitblt prim. The only real way to find anything out here would be to run a debug vm under gdb and see what can be found when it crashes. Which with a three-week use case is going to be such fun? Which reminds me, I have no idea if we provide debug build VMs for people to grab? Anyone? tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BNE: Buy Non-IBM Equipment From herbertkoenig at gmx.net Fri Sep 18 17:58:41 2015 From: herbertkoenig at gmx.net (=?UTF-8?Q?Herbert_K=c3=b6nig?=) Date: Fri Sep 18 17:58:45 2015 Subject: [squeak-dev] Fwd: Squeak 5.0 All in one crashed on my Pi after running 3 weeks at 40% CPU In-Reply-To: References: <55FC3607.6020905@gmx.net> <55FC3682.40009@gmx.net> Message-ID: <55FC50D1.50501@gmx.net> And I'm always amazed how stable Squeak runs. If there's such a debug VM I'll try to run it. Now lets talk about ugly bits that upset the blt :-) It was the 360somethingthousandth bmp from the same old garden being watched for pooing cats. No evil deeds the last week. Vigilance! Herbert Am 18.09.2015 um 19:38 schrieb tim Rowledge: > On 18-09-2015, at 9:06 AM, Herbert K?nig wrote: >> since the 5.0 all in one I use it 24/7 on my Pi without any problems. >> The recent uninterrupted run was about three weeks (there had been a two >> week run before) and a few minutes ago it crashed with no apparent reason. > I don?t think I?ve ever run anything for that long continuously. That long implies it isn?t any simple run-out-of-memory problem, or code-generation. The best I can think of right now is that the *data* you had got in this case was a bit ugly and upset the bitblt prim. > The only real way to find anything out here would be to run a debug vm under gdb and see what can be found when it crashes. Which with a three-week use case is going to be such fun? > > Which reminds me, I have no idea if we provide debug build VMs for people to grab? Anyone? > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: BNE: Buy Non-IBM Equipment > > > > From leves at elte.hu Fri Sep 18 23:49:16 2015 From: leves at elte.hu (Levente Uzonyi) Date: Fri Sep 18 23:49:22 2015 Subject: [squeak-dev] The Trunk: Compiler-eem.309.mcz In-Reply-To: References: Message-ID: Thanks Eliot! Those duplicated variable names were quite annoying. Levente On Thu, 17 Sep 2015, commits@source.squeak.org wrote: > Eliot Miranda uploaded a new version of Compiler to project The Trunk: > http://source.squeak.org/trunk/Compiler-eem.309.mcz > > ==================== Summary ==================== > > Name: Compiler-eem.309 > Author: eem > Time: 16 September 2015, 5:26:18.544 pm > UUID: 89f65602-802e-41c5-b52c-c85cf61e299f > Ancestors: Compiler-eem.308 > > Fix the compiler to collapse optimized block temps of the same name to the same temp location for a better debugging UX. > > =============== Diff against Compiler-eem.308 =============== > > Item was changed: > ----- Method: BlockNode>>addHoistedTemps: (in category 'code generation (closures)') ----- > addHoistedTemps: additionalTemporaries "" > + | tempsToBeMerged additionalTempsToAdd | > additionalTemporaries do: > [:temp| > temp definingScope ifNil: > [temp definingScope: self]]. > + (temporaries isNil or: [temporaries isEmpty]) ifTrue: > + [temporaries := additionalTemporaries copy. > + ^self]. > + tempsToBeMerged := additionalTemporaries select: > + [:t| > + t isBlockArg > + and: [temporaries anySatisfy: [:existing| existing isBlockArg and: [existing key = t key]]]]. > + additionalTempsToAdd := tempsToBeMerged isEmpty > + ifTrue: [additionalTemporaries copy] > + ifFalse: [additionalTemporaries reject: [:temp| tempsToBeMerged identityIncludes: temp]]. > temporaries := (temporaries isNil or: [temporaries isEmpty]) > + ifTrue: [additionalTempsToAdd] > - ifTrue: [additionalTemporaries copy] > ifFalse: > [temporaries last isIndirectTempVector > + ifTrue: [temporaries allButLast, additionalTempsToAdd, { temporaries last }] > + ifFalse: [temporaries, additionalTempsToAdd]]. > + tempsToBeMerged do: > + [:t| | merge | > + merge := temporaries detect: [:existing| existing isBlockArg and: [existing key = t key]]. > + merge absorbHoistedTemp: t]! > - ifTrue: [temporaries allButLast, additionalTemporaries, { temporaries last }] > - ifFalse: [temporaries, additionalTemporaries]]! > > Item was changed: > ----- Method: BytecodeEncoder>>bindTemp: (in category 'temps') ----- > bindTemp: name > "Declare a temporary; error not if a field or class variable or out-of-scope temp. > Read the comment in Encoder>>bindBlockArg:within: and subclass implementations." > self supportsClosureOpcodes ifFalse: > [^super bindTemp: name]. > scopeTable at: name ifPresent: > [:node| > "When non-interactive raise the error only if it is a duplicate" > node isTemp > ifTrue:[node scope >= 0 ifTrue: > + [^self notify: 'Name already used in this method']] > - [^self notify:'Name is already defined']] > ifFalse:[self warnAboutShadowed: name]]. > ^self reallyBind: name! > > Item was added: > + ----- Method: TempVariableNode>>absorbHoistedTemp: (in category 'code generation (closures)') ----- > + absorbHoistedTemp: aTempVar > + "Collapse aTempVar into the receiver, being sure to update any closure analysis." > + aTempVar copyScopeAccessTo: self. > + aTempVar becomeForward: self! > > Item was added: > + ----- Method: TempVariableNode>>copyScopeAccessTo: (in category 'code generation (closures)') ----- > + copyScopeAccessTo: aTempVar > + "For absorbHoistedTemp:, copy the receiver's reads and writes into the record in aTempVar." > + readingScopes ifNotNil: > + [readingScopes keysAndValuesDo: > + [:scopeBlock :reads| > + reads do: > + [:location| > + aTempVar addReadWithin: scopeBlock "" at: location]]]. > + writingScopes ifNotNil: > + [writingScopes keysAndValuesDo: > + [:scopeBlock :writes| > + writes do: > + [:location| > + aTempVar addWriteWithin: scopeBlock "" at: location]]]! > > Item was changed: > + (PackageInfo named: 'Compiler') postscript: '"Make sure all affected methods are recompiled" > + UIManager default > + informUser: ''Recompiling affected methods'' > + during: > + [(self systemNavigation allMethodsSelect: > + [:m| | ebc | "All affected methods send one of these optimized selectors..." > + (#(to:do: to:by:do: ifNotNil: ifNil:ifNotNil: ifNotNil:ifNil:) anySatisfy: [:l| m refersToLiteral: l]) > + "but the textDomain properties confuse method comparison below..." > + and: [(m propertyValueAt: #textDomain ifAbsent: nil) isNil > + and: [m numTemps > m numArgs "and have non-argument temporaries in them..." > + or: [(ebc := m embeddedBlockClosures) notEmpty > + and: [ebc anySatisfy: [:bc| bc numTemps > bc numArgs]]]]]]) do: > + [:mr| | old new | > + old := mr compiledMethod. > + "do a test recompile of the method..." > + new := (mr actualClass compile: old getSource asString notifying: nil trailer: old trailer ifFail: nil) method. > + "and if it changed, report it to the transcript and really recompile it..." > + old ~= new ifTrue: > + [Transcript cr. old printReferenceOn: Transcript. Transcript flush. > + mr actualClass recompile: old selector]]]'! > - (PackageInfo named: 'Compiler') postscript: '"Migrate preference value" > - Scanner allowBlockArgumentAssignment: Preferences allowBlockArgumentAssignment'! > > > From bernhard at pieber.com Sun Sep 20 13:40:11 2015 From: bernhard at pieber.com (Bernhard Pieber) Date: Sun Sep 20 13:40:16 2015 Subject: [squeak-dev] MNU when disabling preference Show world main docking bar Message-ID: <63491717-2E73-4072-95BE-F9651960E16E@pieber.com> Dear Squeakers, When I wanted to disable the docking bar I ran into a debugger in an image with latest update #15196. It does not happen in the Squeak5.1-15113.image from the FTP server. The strange thing is that all the showWorldMainDockingBar(:) methods have not changed for years. So far I did not find the reason for this. Maybe someone of you have a suspicion of what change might have caused that. Cheers, Bernhard From bernhard at pieber.com Sun Sep 20 14:08:00 2015 From: bernhard at pieber.com (Bernhard Pieber) Date: Sun Sep 20 14:08:05 2015 Subject: [squeak-dev] Re: MNU when disabling preference Show world main docking bar In-Reply-To: <63491717-2E73-4072-95BE-F9651960E16E@pieber.com> References: <63491717-2E73-4072-95BE-F9651960E16E@pieber.com> Message-ID: <53B8EB9C-47EB-4726-980F-4E6D91832389@pieber.com> I found it. If I revert the change of Preferences class>>#doesNotUnderstand: from 8/27/215 that came with System-topa.764 it works again. I don?t know if this is the right fix as I am sure there was some good reason for the change. Tobias? Cheers, Bernhard P.S. Here is a strange thing. The mail from commits@source.squeak.org look like this: Tobias Pape uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-topa.764.mcz ==================== Summary ==================== Name: System-topa.764 Author: topa Time: 27 August 2015, 11:47:04.664 pm UUID: c205a736-8aff-48c5-8b3b-24ec808d19fd Ancestors: System-topa.763 Do not return nil for unknown preferences in dNU magic but rather bail. =============== Diff against System-topa.763 =============== Item was changed: ----- Method: Preferences class>>doesNotUnderstand: (in category 'get/set') ----- doesNotUnderstand: aMessage "Interpret unary message selectors as preference id." ^ aMessage arguments size > 0 ifTrue: [super doesNotUnderstand: aMessage] + ifFalse: [ + self + valueOfPreference: aMessage selector + ifAbsent: [super doesNotUnderstand: aMessage]]! - ifFalse: [self valueOfPreference: aMessage selector]! However, in my trunk image the previous version of the method with the stamp sw 11/11/1998 11:40 looks like this: doesNotUnderstand: aMessage "Look up the message selector as a flag." aMessage arguments size > 0 ifTrue: [^ super doesNotUnderstand: aMessage]. ^ self valueOfFlag: aMessage selector Does anyone have an explanation why the intermediate version isn?t in my trunk image? > Am 20.09.2015 um 15:40 schrieb Bernhard Pieber : > > Dear Squeakers, > > When I wanted to disable the docking bar I ran into a debugger in an image with latest update #15196. It does not happen in the Squeak5.1-15113.image from the FTP server. > > The strange thing is that all the showWorldMainDockingBar(:) methods have not changed for years. So far I did not find the reason for this. Maybe someone of you have a suspicion of what change might have caused that. > > Cheers, > Bernhard From commits at source.squeak.org Sun Sep 20 14:17:25 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sun Sep 20 14:17:27 2015 Subject: [squeak-dev] The Trunk: Morphic-mt.1006.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1006.mcz ==================== Summary ==================== Name: Morphic-mt.1006 Author: mt Time: 20 September 2015, 4:16:42.826 pm UUID: 9653938a-98f0-4943-b266-64f4bba540b6 Ancestors: Morphic-mt.1005 Fixes the preference for showing the world main docking bar. That preference value is stored only in the project-specific flags. No need to spam the quasi-global preference dictionary with it. =============== Diff against Morphic-mt.1005 =============== Item was changed: ----- Method: MorphicProject>>showWorldMainDockingBar: (in category 'docking bars support') ----- showWorldMainDockingBar: aBoolean "Change the receiver to show the main docking bar" self projectPreferenceFlagDictionary at: #showWorldMainDockingBar put: aBoolean. - (self == Project current - and: [aBoolean ~= Preferences showWorldMainDockingBar]) - ifTrue: [Preferences setPreference: #showWorldMainDockingBar toValue: aBoolean]. self assureMainDockingBarPresenceMatchesPreference! From Marcel.Taeumel at hpi.de Sun Sep 20 14:10:21 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Sun Sep 20 14:18:17 2015 Subject: [squeak-dev] Re: MNU when disabling preference Show world main docking bar In-Reply-To: <63491717-2E73-4072-95BE-F9651960E16E@pieber.com> References: <63491717-2E73-4072-95BE-F9651960E16E@pieber.com> Message-ID: <1442758221519-4851177.post@n4.nabble.com> Fixed: http://forum.world.st/The-Trunk-Morphic-mt-1006-mcz-td4851176.html Just update. :) Best, Marcel -- View this message in context: http://forum.world.st/MNU-when-disabling-preference-Show-world-main-docking-bar-tp4851169p4851177.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From Marcel.Taeumel at hpi.de Sun Sep 20 14:13:56 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Sun Sep 20 14:21:52 2015 Subject: [squeak-dev] Re: MNU when disabling preference Show world main docking bar In-Reply-To: <53B8EB9C-47EB-4726-980F-4E6D91832389@pieber.com> References: <63491717-2E73-4072-95BE-F9651960E16E@pieber.com> <53B8EB9C-47EB-4726-980F-4E6D91832389@pieber.com> Message-ID: <1442758436727-4851180.post@n4.nabble.com> Hi Bernhard, it's a good thing to have less DNU-magic in the Preferences. There is no default value for all kinds of preferences that could possibly be returned there. It used to be "false" but that makes no sense for, e.g., numeric properties. Returnung "nil" would require more #ifNotNil-checks. Raising an error is fair enough. Best, Marcel -- View this message in context: http://forum.world.st/MNU-when-disabling-preference-Show-world-main-docking-bar-tp4851169p4851180.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From karlramberg at gmail.com Sun Sep 20 17:14:00 2015 From: karlramberg at gmail.com (karl ramberg) Date: Sun Sep 20 17:14:04 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: Hi, I tracked it down to NewParagraph>>selectionColor | color | Display depth = 1 ifTrue: [^ Color veryLightGray]. Display depth = 2 ifTrue: [^ Color gray]. color := Preferences textHighlightColor. self focused ifFalse: [color := Color gray: 0.9]. ^ color I liked the previous version of this method better since the unfocused color reflected the your selection color: self focused ifFalse: [color := color alphaMixed: 0.2 with: Color veryVeryLightGray]. It's important to see the color of selection in the Debugger even if the pane not has focus Karl On Mon, Sep 14, 2015 at 5:58 PM, Chris Cunningham wrote: > Because I really, really need too change the color. I can't see where the > error is - the 'highlight' color is so faint, it looks like nothing is > highlighted at all. It makes tracking down where the error is really, > really hard. > > I had a similar issue a few years ago with the Moose guys - they changed > the sliders in the windows to be more aesthetically pleasing, but on some > LCD monitors (notably, mine), the color is practically not there at all - > like, apparently, this highlight color. > > Thanks, > cbc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150920/fb2ad23a/attachment.htm From bernhard at pieber.com Sun Sep 20 17:47:55 2015 From: bernhard at pieber.com (Bernhard Pieber) Date: Sun Sep 20 17:48:01 2015 Subject: [squeak-dev] MNU when disabling preference Show world main docking bar In-Reply-To: <1442758436727-4851180.post@n4.nabble.com> References: <63491717-2E73-4072-95BE-F9651960E16E@pieber.com> <53B8EB9C-47EB-4726-980F-4E6D91832389@pieber.com> <1442758436727-4851180.post@n4.nabble.com> Message-ID: Hi Marcel, I agree. Thanks for the fast fix. This makes reporting bugs more fun. ;-) Cheers, Bernhard > Am 20.09.2015 um 16:13 schrieb marcel.taeumel : > > Hi Bernhard, > > it's a good thing to have less DNU-magic in the Preferences. There is no > default value for all kinds of preferences that could possibly be returned > there. It used to be "false" but that makes no sense for, e.g., numeric > properties. Returnung "nil" would require more #ifNotNil-checks. Raising an > error is fair enough. > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/MNU-when-disabling-preference-Show-world-main-docking-bar-tp4851169p4851180.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > From commits at source.squeak.org Sun Sep 20 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Sun Sep 20 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150920215502.16735.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008972.html Name: Morphic-mt.1006 Ancestors: Morphic-mt.1005 Fixes the preference for showing the world main docking bar. That preference value is stored only in the project-specific flags. No need to spam the quasi-global preference dictionary with it. ============================================= From javier_diaz_r at mac.com Sun Sep 20 23:40:19 2015 From: javier_diaz_r at mac.com (Javier Diaz-Reinoso) Date: Sun Sep 20 23:40:57 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> Message-ID: I am also interested in this, so I wasted a few days and finally have a (original) Squeak 4.1 image working in mi old iPad 2: the clock works, but that is all, I can?t enter anything, I know I need modifications in the image, but before I spend more days in this, can any people who knows send me advice and perhaps a change set with the modifications? > On Sep 11, 2015, at 00:59, Casey Ransberger wrote: > > When I heard that Apple was competing with Surface Pro I went looking for the only feature of the Surface Pro that I wanted in Apple's new tablet: side loading. > > It looks like Apple has dropped the $99 a year for not even necessarily selling anything on the App Store requirement. It's not exactly side-loading, because end users would still have to build the VM from C sources in Xcode before installing it, but it's something. > > The upshot is, since we can't ship via app-store, we can do a source distribution and get around the stupid App Store rules that hate us so. Thus, we don't have to rely on weird flaky crap like jailbreaks or have a guy paying for a dev account out of the goodness of his heart to distribute test keys for the system to those brave enough to run it without a proper touch interface. > > I may buy another iPad yet. > > Guessing most people familiar with the sitch are probably up to date, but for anyone who missed this detail, Casey to the rescue. > > http://9to5mac.com/2015/06/10/xcode-7-allows-anyone-to-download-build-and-sideload-ios-apps-for-free/ -------------- next part -------------- Skipped content of type multipart/related From edgardec2005 at gmail.com Mon Sep 21 09:14:57 2015 From: edgardec2005 at gmail.com (Edgar J. De Cleene) Date: Mon Sep 21 09:15:07 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: Message-ID: I have in some place a Etoys image with Bert changes which runs in old jailbreak iPad and let some touch command by the user. If now is ok have some like this on the modern iPad its a very good news On 9/20/15, 8:40 PM, "Javier Diaz-Reinoso" wrote: > I am also interested in this, so I wasted a few days and finally have a > (original) Squeak 4.1 image working in mi old iPad 2: > > the clock works, but that is all, I can?t enter anything, I know I need > modifications in the image, but before I spend more days in this, can any > people who knows send me advice and perhaps a change set with the > modifications? > >> On Sep 11, 2015, at 00:59, Casey Ransberger wrote: >> >> When I heard that Apple was competing with Surface Pro I went looking for the >> only feature of the Surface Pro that I wanted in Apple's new tablet: side >> loading. >> >> It looks like Apple has dropped the $99 a year for not even necessarily >> selling anything on the App Store requirement. It's not exactly side-loading, >> because end users would still have to build the VM from C sources in Xcode >> before installing it, but it's something. >> >> The upshot is, since we can't ship via app-store, we can do a source >> distribution and get around the stupid App Store rules that hate us so. Thus, >> we don't have to rely on weird flaky crap like jailbreaks or have a guy >> paying for a dev account out of the goodness of his heart to distribute test >> keys for the system to those brave enough to run it without a proper touch >> interface. >> >> I may buy another iPad yet. >> >> Guessing most people familiar with the sitch are probably up to date, but for >> anyone who missed this detail, Casey to the rescue. >> >> http://9to5mac.com/2015/06/10/xcode-7-allows-anyone-to-download-build-and-sid >> eload-ios-apps-for-free/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150921/bca5e0fb/attachment.htm From Marcel.Taeumel at hpi.de Mon Sep 21 11:07:24 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Sep 21 11:15:26 2015 Subject: [squeak-dev] Re: [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: <1442833644343-4851275.post@n4.nabble.com> Hi, that change was related to this: http://forum.world.st/Deceptive-focus-cue-in-4-6-browsers-td4827358.html I would rather not revert it but add some additional selection ranges + colors to paragraphs. You need those anyway to display, for example, search term matches in text boxes. Such an additional range could then be used to highlight the current PC. The button "Where" would not be needed anymore. Hey, we can "save a button"! :) Best, Marcel -- View this message in context: http://forum.world.st/squak-dev-How-do-I-change-the-debugger-highlighting-color-tp4850084p4851275.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From cunningham.cb at gmail.com Mon Sep 21 15:06:29 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Mon Sep 21 15:06:31 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: Thank you Karl for tracking this down. I have reverted it in my image. the problem with the gray is that I just cannot see it. The monitor/my eyes combination just can't make out Color gray: 0.9 as a highlight color - I might as well not have a highlight. -cbc On Sun, Sep 20, 2015 at 10:14 AM, karl ramberg wrote: > Hi, > I tracked it down to > NewParagraph>>selectionColor > | color | Display depth = 1 ifTrue: [^ Color veryLightGray]. Display depth > = 2 ifTrue: [^ Color gray]. color := Preferences textHighlightColor. self > focused ifFalse: [color := Color gray: 0.9]. ^ color > > I liked the previous version of this method better since the > unfocused color reflected the your selection color: > > self focused ifFalse: [color := color alphaMixed: 0.2 with: Color > veryVeryLightGray]. > > > It's important to see the color of selection in the Debugger even if the > pane not has focus > > Karl > > > > On Mon, Sep 14, 2015 at 5:58 PM, Chris Cunningham > wrote: > >> Because I really, really need too change the color. I can't see where the >> error is - the 'highlight' color is so faint, it looks like nothing is >> highlighted at all. It makes tracking down where the error is really, >> really hard. >> >> I had a similar issue a few years ago with the Moose guys - they changed >> the sliders in the windows to be more aesthetically pleasing, but on some >> LCD monitors (notably, mine), the color is practically not there at all - >> like, apparently, this highlight color. >> >> Thanks, >> cbc >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150921/88465c61/attachment.htm From karlramberg at gmail.com Mon Sep 21 15:10:58 2015 From: karlramberg at gmail.com (karl ramberg) Date: Mon Sep 21 15:11:01 2015 Subject: [squeak-dev] Re: [squak-dev] How do I change the debugger highlighting color? In-Reply-To: <1442833644343-4851275.post@n4.nabble.com> References: <1442833644343-4851275.post@n4.nabble.com> Message-ID: I knew I had seen this discussion before :-) Solving one problem creates another. I agree that the additional range would be nice here. Karl On Mon, Sep 21, 2015 at 1:07 PM, marcel.taeumel wrote: > Hi, > > that change was related to this: > http://forum.world.st/Deceptive-focus-cue-in-4-6-browsers-td4827358.html > > I would rather not revert it but add some additional selection ranges + > colors to paragraphs. You need those anyway to display, for example, search > term matches in text boxes. > > Such an additional range could then be used to highlight the current PC. > The > button "Where" would not be needed anymore. Hey, we can "save a button"! :) > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/squak-dev-How-do-I-change-the-debugger-highlighting-color-tp4850084p4851275.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150921/5b172401/attachment.htm From karlramberg at gmail.com Mon Sep 21 15:12:14 2015 From: karlramberg at gmail.com (karl ramberg) Date: Mon Sep 21 15:12:17 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: No problem :-) Karl On Mon, Sep 21, 2015 at 5:06 PM, Chris Cunningham wrote: > Thank you Karl for tracking this down. I have reverted it in my image. > > the problem with the gray is that I just cannot see it. The monitor/my > eyes combination just can't make out Color gray: 0.9 as a highlight color - > I might as well not have a highlight. > > -cbc > > On Sun, Sep 20, 2015 at 10:14 AM, karl ramberg > wrote: > >> Hi, >> I tracked it down to >> NewParagraph>>selectionColor >> | color | Display depth = 1 ifTrue: [^ Color veryLightGray]. Display >> depth = 2 ifTrue: [^ Color gray]. color := Preferences textHighlightColor. >> self focused ifFalse: [color := Color gray: 0.9]. ^ color >> >> I liked the previous version of this method better since the >> unfocused color reflected the your selection color: >> >> self focused ifFalse: [color := color alphaMixed: 0.2 with: Color >> veryVeryLightGray]. >> >> >> It's important to see the color of selection in the Debugger even if the >> pane not has focus >> >> Karl >> >> >> >> On Mon, Sep 14, 2015 at 5:58 PM, Chris Cunningham < >> cunningham.cb@gmail.com> wrote: >> >>> Because I really, really need too change the color. I can't see where >>> the error is - the 'highlight' color is so faint, it looks like nothing is >>> highlighted at all. It makes tracking down where the error is really, >>> really hard. >>> >>> I had a similar issue a few years ago with the Moose guys - they changed >>> the sliders in the windows to be more aesthetically pleasing, but on some >>> LCD monitors (notably, mine), the color is practically not there at all - >>> like, apparently, this highlight color. >>> >>> Thanks, >>> cbc >>> >>> >>> >>> >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150921/98d7b46b/attachment.htm From brasspen at gmail.com Mon Sep 21 15:51:37 2015 From: brasspen at gmail.com (Chris Cunnington) Date: Mon Sep 21 15:51:40 2015 Subject: [squeak-dev] [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: Message-ID: <56002789.6000609@gmail.com> I have a Mac Mini plugged into a 23" LG screen and the highlighting does not appear at all. I have a Mac PowerBook 13" and the light gray highlighting is clearly visible. I suspect that this is varying depending on the screen. I'm reverting for my LG screen. Chris On 2015-09-21 11:06 AM, Chris Cunningham wrote: > Thank you Karl for tracking this down. I have reverted it in my image. > > the problem with the gray is that I just cannot see it. The monitor/my > eyes combination just can't make out Color gray: 0.9 as a highlight > color - I might as well not have a highlight. > > -cbc > > On Sun, Sep 20, 2015 at 10:14 AM, karl ramberg > wrote: > > Hi, > I tracked it down to > NewParagraph>>selectionColor > | color | Display depth = 1 ifTrue: [^ Color veryLightGray]. > Display depth = 2 ifTrue: [^ Color gray]. color := Preferences > textHighlightColor. self focused ifFalse: [color := Color gray: > 0.9]. ^ color > I liked the previous version of this method better since the > unfocused color reflected the your selection color: > self focused ifFalse: [color := color alphaMixed: 0.2 with: Color > veryVeryLightGray]. > It's important to see the color of selection in the Debugger even > if the pane not has focus > Karl > > On Mon, Sep 14, 2015 at 5:58 PM, Chris Cunningham > > wrote: > > Because I really, really need too change the color. I can't > see where the error is - the 'highlight' color is so faint, it > looks like nothing is highlighted at all. It makes tracking > down where the error is really, really hard. > > I had a similar issue a few years ago with the Moose guys - > they changed the sliders in the windows to be more > aesthetically pleasing, but on some LCD monitors (notably, > mine), the color is practically not there at all - like, > apparently, this highlight color. > > Thanks, > cbc > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150921/3ac06ee9/attachment.htm From Marcel.Taeumel at hpi.de Mon Sep 21 16:12:09 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Sep 21 16:20:14 2015 Subject: [squeak-dev] Re: [squak-dev] How do I change the debugger highlighting color? In-Reply-To: <56002789.6000609@gmail.com> References: <56002789.6000609@gmail.com> Message-ID: <1442851929311-4851341.post@n4.nabble.com> Well, there is a configurable textHighlightColor already. Why not making that other one also configurable? Best, Marcel -- View this message in context: http://forum.world.st/squak-dev-How-do-I-change-the-debugger-highlighting-color-tp4850084p4851341.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From asqueaker at gmail.com Mon Sep 21 18:09:56 2015 From: asqueaker at gmail.com (Chris Muller) Date: Mon Sep 21 18:09:58 2015 Subject: [squeak-dev] Re: [squak-dev] How do I change the debugger highlighting color? In-Reply-To: <1442851929311-4851341.post@n4.nabble.com> References: <56002789.6000609@gmail.com> <1442851929311-4851341.post@n4.nabble.com> Message-ID: On Mon, Sep 21, 2015 at 11:12 AM, marcel.taeumel wrote: > Well, there is a configurable textHighlightColor already. Why not making that > other one also configurable? _Everything_ w.r.t. colors should be configurable. We need skins / themes. From tim at rowledge.org Mon Sep 21 18:18:41 2015 From: tim at rowledge.org (tim Rowledge) Date: Mon Sep 21 18:18:45 2015 Subject: [squeak-dev] Re: [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: <56002789.6000609@gmail.com> <1442851929311-4851341.post@n4.nabble.com> Message-ID: On 21-09-2015, at 11:09 AM, Chris Muller wrote: > On Mon, Sep 21, 2015 at 11:12 AM, marcel.taeumel wrote: >> Well, there is a configurable textHighlightColor already. Why not making that >> other one also configurable? > > _Everything_ w.r.t. colors should be configurable. We need skins / themes. > ColorTheme and 9 subclasses? Yet another bunch of stuff that isn?t complete and properly used. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One too many lights out in his Christmas tree. From hrothgar.ofstingan at gmail.com Tue Sep 22 12:32:52 2015 From: hrothgar.ofstingan at gmail.com (Russell N Hyer) Date: Tue Sep 22 12:32:56 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> Message-ID: Thanks Casey for this, that's great news, both for Squeak progress and for general Mac work (I may yet be able to get some work done on my new Apple devices :)) Thanks, Russ On 11 September 2015 at 06:59, Casey Ransberger wrote: > When I heard that Apple was competing with Surface Pro I went looking for > the only feature of the Surface Pro that I wanted in Apple's new tablet: > side loading. > > It looks like Apple has dropped the $99 a year for not even necessarily > selling anything on the App Store requirement. It's not exactly > side-loading, because end users would still have to build the VM from C > sources in Xcode before installing it, but it's something. > > The upshot is, since we can't ship via app-store, we can do a source > distribution and get around the stupid App Store rules that hate us so. > Thus, we don't have to rely on weird flaky crap like jailbreaks or have a > guy paying for a dev account out of the goodness of his heart to distribute > test keys for the system to those brave enough to run it without a proper > touch interface. > > I may buy another iPad yet. > > Guessing most people familiar with the sitch are probably up to date, but > for anyone who missed this detail, Casey to the rescue. > > > http://9to5mac.com/2015/06/10/xcode-7-allows-anyone-to-download-build-and-sideload-ios-apps-for-free/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150922/8a2a10f1/attachment.htm From bert at freudenbergs.de Tue Sep 22 12:39:43 2015 From: bert at freudenbergs.de (Bert Freudenberg) Date: Tue Sep 22 12:39:46 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> Message-ID: <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4115 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150922/cc6db22c/smime.bin From casimiro.barreto at gmail.com Tue Sep 22 13:54:18 2015 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Tue Sep 22 13:54:30 2015 Subject: [squeak-dev] Need an elegant way to solve a simple problem Message-ID: <56015D8A.8060602@gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150922/737e42b7/signature.pgp From Marcel.Taeumel at hpi.de Tue Sep 22 13:53:24 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Tue Sep 22 14:01:34 2015 Subject: [squeak-dev] Re: Need an elegant way to solve a simple problem In-Reply-To: <56015D8A.8060602@gmail.com> References: <56015D8A.8060602@gmail.com> Message-ID: <1442930004243-4851506.post@n4.nabble.com> You can use #withBlanksTrimmed (and #withoutLineEndings) for that. Best, Marcel -- View this message in context: http://forum.world.st/Need-an-elegant-way-to-solve-a-simple-problem-tp4851504p4851506.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From leves at elte.hu Tue Sep 22 14:06:34 2015 From: leves at elte.hu (Levente Uzonyi) Date: Tue Sep 22 14:06:38 2015 Subject: [squeak-dev] Need an elegant way to solve a simple problem In-Reply-To: <56015D8A.8060602@gmail.com> References: <56015D8A.8060602@gmail.com> Message-ID: If stripping leading blanks is okay, then you can use #withBlanksTrimmed. Otherwise you can use the following oneliner: string copyFrom: 1 to: (string lastIndexOfAnyOf: CharacterSet nonSeparators startingAt: string size ifAbsent: string size) Levente On Tue, 22 Sep 2015, Casimiro - GMAIL wrote: > I have a ByteString line. I want to strip blanks and tabs at end of it. Blanks and tabs allowed between words. MxMatcher looks a bit like using a gun to kill a fly. Any suggestion about a time effective way > of solving the problem? (obvious way: asOrderedCollection and then backtrack killing spaces & tabs until find non space/tab char). > > Best regards, > > CdAB > -- > The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, > disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. > > == > > This email may be signed using PGP key ID: 0x4134A417 > > From casimiro.barreto at gmail.com Tue Sep 22 15:09:12 2015 From: casimiro.barreto at gmail.com (Casimiro - GMAIL) Date: Tue Sep 22 15:09:27 2015 Subject: [squeak-dev] Need an elegant way to solve a simple problem In-Reply-To: References: <56015D8A.8060602@gmail.com> Message-ID: <56016F18.4080601@gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150922/fe1300af/signature.pgp From karlramberg at gmail.com Tue Sep 22 16:46:52 2015 From: karlramberg at gmail.com (karl ramberg) Date: Tue Sep 22 16:46:55 2015 Subject: [squeak-dev] Re: [squak-dev] How do I change the debugger highlighting color? In-Reply-To: <1442851929311-4851341.post@n4.nabble.com> References: <56002789.6000609@gmail.com> <1442851929311-4851341.post@n4.nabble.com> Message-ID: What should the unfocused selection highlight be called ? textHighlightUnfocusedColor ? Karl On Mon, Sep 21, 2015 at 6:12 PM, marcel.taeumel wrote: > Well, there is a configurable textHighlightColor already. Why not making > that > other one also configurable? > > Best, > Marcel > > > > -- > View this message in context: > http://forum.world.st/squak-dev-How-do-I-change-the-debugger-highlighting-color-tp4850084p4851341.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150922/d2181393/attachment.htm From cunningham.cb at gmail.com Tue Sep 22 17:00:03 2015 From: cunningham.cb at gmail.com (Chris Cunningham) Date: Tue Sep 22 17:00:07 2015 Subject: [squeak-dev] Re: [squak-dev] How do I change the debugger highlighting color? In-Reply-To: References: <56002789.6000609@gmail.com> <1442851929311-4851341.post@n4.nabble.com> Message-ID: Good question. If I get around to it, I'd allow specific color selection, legacy option (which is whever the highlight color was alpha: 2 with light gray), and (if I got really ambitious) playing with the alpha/other color. I won't have time very soon to do any of this, but if it sticks around long enough, I might get to it. Karl, maybe textUnfocusedHighlightColor ? On Tue, Sep 22, 2015 at 9:46 AM, karl ramberg wrote: > What should the unfocused selection highlight be called ? > > textHighlightUnfocusedColor ? > > Karl > > > On Mon, Sep 21, 2015 at 6:12 PM, marcel.taeumel > wrote: > >> Well, there is a configurable textHighlightColor already. Why not making >> that >> other one also configurable? >> >> Best, >> Marcel >> >> >> >> -- >> View this message in context: >> http://forum.world.st/squak-dev-How-do-I-change-the-debugger-highlighting-color-tp4850084p4851341.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150922/c5264898/attachment-0001.htm From eliot.miranda at gmail.com Wed Sep 23 18:18:20 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed Sep 23 18:18:23 2015 Subject: [squeak-dev] ARM Simulator whitewash... Message-ID: Hi All, anyone with C chops looking for a challenge? The ARM code generator in Cog is in a good state and we're supporting Squeak 5.0 Cog on ARM and building Newspeak Cog VMs for ARM. But the same can't be said of the simulator, with which we develop the code generator. Tim Rowledge recently added support for floating point support for the ARM code generator, which is great for floating point performance, but alas the simulator can't simulate the generated vfp (virtual floating point) instructions. The simulator is derived from Gdb's ARM support, see http://www.squeakvm.org/svn/squeak/branches/Cog/processors/ARM/README http://www.squeakvm.org/svn/squeak/branches/Cog/processors/ARM/gdb-7.6 Is anyone interested in fixing the ARM simulator so that it does correctly simulate vfp instructions? If so, let me know and I can help you set up the relevant environment. _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150923/a443a868/attachment.htm From javier_diaz_r at mac.com Wed Sep 23 20:17:29 2015 From: javier_diaz_r at mac.com (Javier Diaz-Reinoso) Date: Wed Sep 23 20:17:56 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> Message-ID: On Sep 22, 2015, at 07:39, Bert Freudenberg wrote: > > On 21.09.2015, at 01:40, Javier Diaz-Reinoso > wrote: >> >> I am also interested in this, so I wasted a few days and finally have a (original) Squeak 4.1 image working in mi old iPad 2: >> > > Nice! > >> the clock works, but that is all, I can?t enter anything, I know I need modifications in the image, but before I spend more days in this, can any people who knows send me advice and perhaps a change set with the modifications? > > > You can dig around on John McIntosh?s site but I don?t think there?s a comprehensible set of changes yet. I find the file miPhone-Events-EstebanLorenzano.25.mcz who contains your code and code from John McIntosh and Esteban Lorenzano and others, that file don?t load in Squeak, I suppose is for Pharo, but with selective copy-paste I have now a working UI. > > > What I did years ago was adding image-side support for multi-touch, plus an on-screen alt key [*]. That?s not strictly necessary though, the VM could (and IMHO should) generate mouse events itself. Still, you need a way to bring up the keyboard (which I ?solved? back then by hacking the VM to show the keyboard when rotating to portrait orientation). > > The proper way to do this (IMHO) would be by implementing an IMM plugin for iOS just like we have for X11 etc. Morphic calls a plugin function whenever a text input field gets focused, which could be used to trigger the keyboard. But AFAIK nobody has gone that route yet, instead relying on the ObjectiveCBridge plugin to call OS functions directly. > > Your best bet if you want to avoid doing it yourself would be contacting the makers of Pyonkee, the most complex Squeak app in the Apple App Store yet. There is also DrGeo, for which Esteban did the VM work. And since all this is still pretty experimental, continuing this discussion on the VM dev list would be a good idea :) > > - Bert - > > [*] https://www.youtube.com/watch?v=gYrp31fH-Jk I find in a Pharo repository the folder IOSPlugin who is used in DrGeo, is very small but works, in the .mcz is some code to call the plugin from TextMorph>>wantsKeyboardFocus who also is not in Squeak, but inserting the line in TextMorphForEditView>>keyboardFocusChange: is now possible to simple click in a Workspace or Browser and the keyboard appears. Apart from a few fixes I am not really changing the VM, is only in the image. The most desirable change in the VM I think is changing to Cog more speed is always best. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150923/76822222/attachment.htm From tim at rowledge.org Wed Sep 23 20:43:33 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 23 20:43:36 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> Message-ID: <9262BBB4-0912-4A78-BCB4-96715B651D2B@rowledge.org> On 23-09-2015, at 1:17 PM, Javier Diaz-Reinoso wrote: > > Apart from a few fixes I am not really changing the VM, is only in the image. The most desirable change in the VM I think is changing to Cog more speed is always best. > That?ll be a bit of work; the iThings are all ARM64 rather than ARM32. The instruction set is quite different. You *might* find the Apple cpus have the ARM32 handling enabled though. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Spell checkers at maximum! Fire! From javier_diaz_r at mac.com Wed Sep 23 23:05:24 2015 From: javier_diaz_r at mac.com (Javier Diaz-Reinoso) Date: Wed Sep 23 23:05:54 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: <9262BBB4-0912-4A78-BCB4-96715B651D2B@rowledge.org> References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> <9262BBB4-0912-4A78-BCB4-96715B651D2B@rowledge.org> Message-ID: <5483C1C6-D733-4692-A58E-8100CED365A1@mac.com> Not all, the old iPad2 I am using is 32 bits. I tested in an iPad mini 2 (64 bits) and have a crash in longAtPointerput, I think is because int (aka sqInt) is different in 32 and 64 bits, Xcode generate a fat binary with armv7 and arm64 architectures. > On Sep 23, 2015, at 15:43, tim Rowledge wrote: > > > On 23-09-2015, at 1:17 PM, Javier Diaz-Reinoso wrote: >> >> Apart from a few fixes I am not really changing the VM, is only in the image. The most desirable change in the VM I think is changing to Cog more speed is always best. >> > That?ll be a bit of work; the iThings are all ARM64 rather than ARM32. The instruction set is quite different. You *might* find the Apple cpus have the ARM32 handling enabled though. > > tim > -- > tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim > Spell checkers at maximum! Fire! > > > From tim at rowledge.org Thu Sep 24 02:35:09 2015 From: tim at rowledge.org (tim Rowledge) Date: Thu Sep 24 02:35:14 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: <5483C1C6-D733-4692-A58E-8100CED365A1@mac.com> References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> <9262BBB4-0912-4A78-BCB4-96715B651D2B@rowledge.org> <5483C1C6-D733-4692-A58E-8100CED365A1@mac.com> Message-ID: <27514884-1477-41B2-8EA9-8A45282F529F@rowledge.org> > On 23-09-2015, at 4:05 PM, Javier Diaz-Reinoso wrote: > > Not all, the old iPad2 I am using is 32 bits. But? but.. I thought Apple were supposed to use EeeevilAppleRays to blow up old hardware to force the sheeple to buy More! New! Hardware! tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One chip short of a cookie. From craig at netjam.org Thu Sep 24 08:01:54 2015 From: craig at netjam.org (Craig Latta) Date: Thu Sep 24 08:02:09 2015 Subject: [squeak-dev] re: Squeak on iOS at last? In-Reply-To: <27514884-1477-41B2-8EA9-8A45282F529F@rowledge.org> References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> <9262BBB4-0912-4A78-BCB4-96715B651D2B@rowledge.org> <5483C1C6-D733-4692-A58E-8100CED365A1@mac.com> <27514884-1477-41B2-8EA9-8A45282F529F@rowledge.org> Message-ID: > I thought Apple were supposed to use EeeevilAppleRays to blow up old > hardware to force the sheeple to buy More! New! Hardware! Nope, those sheeple buy plenty of other Apple things while they use their Old! Obsolete! Hardware! (maybe even something from iTunes now and then), and for the moment Apple would rather not drive them away. Meanwhile the bleeding-edgers get to use a horrible new font. :) -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From commits at source.squeak.org Thu Sep 24 12:48:33 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 24 12:48:35 2015 Subject: [squeak-dev] The Trunk: MonticelloConfigurations-topa.138.mcz Message-ID: Tobias Pape uploaded a new version of MonticelloConfigurations to project The Trunk: http://source.squeak.org/trunk/MonticelloConfigurations-topa.138.mcz ==================== Summary ==================== Name: MonticelloConfigurations-topa.138 Author: topa Time: 24 September 2015, 2:48:24.846 pm UUID: 153b9666-3723-4eb0-b230-7bc75450b892 Ancestors: MonticelloConfigurations-dtl.137 Do not nil out Updaters on initialize, beacuse this can screw the whole update process. =============== Diff against MonticelloConfigurations-dtl.137 =============== Item was changed: ----- Method: MCMcmUpdater class>>initialize (in category 'class initialization') ----- initialize "MCMcmUpdater initialize" DefaultUpdateURL ifNil:[ DefaultUpdateURL := MCHttpRepository trunkUrlString. ]. + "Call + MCMcmUpdater resetUpdaters + manually if necessary"! - Updaters := nil. - ! Item was added: + ----- Method: MCMcmUpdater class>>resetUpdaters (in category 'class initialization') ----- + resetUpdaters + + Updaters := nil.! From Das.Linux at gmx.de Thu Sep 24 12:59:03 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu Sep 24 12:59:07 2015 Subject: [squeak-dev] The Trunk: MonticelloConfigurations-topa.138.mcz Message-ID: Here's the thing: The change to initialize effects that it is called. Hence, after updating _past_ MonticelloConfigurations-dtl.137, the Updaters classvar of MCMcmUpdater will be nil, and hence every following attempt to update will restart from 1 and, inevitably, fail eventually. (Evidence: all saved images from the CI since september 3) What we can do: - remove the last three .mcm's that reference MonticelloConfigurations-dtl.137 - update-eem.333 - update-eem.334 - update-eem.335 - I don't know whether each of them is an important milestone for loading individually. if so: - replace 333-335 with maps that refer to MonticelloConfigurations-topa.138 to skip 137 if not: - make a new 333 that merges the changes of the old 333-335 and refers to MonticelloConfigurations-topa.138, also to skip 137. Thoughts? Best regards -Tobias On 24.09.2015, at 12:48, commits@source.squeak.org wrote: > Tobias Pape uploaded a new version of MonticelloConfigurations to project The Trunk: > http://source.squeak.org/trunk/MonticelloConfigurations-topa.138.mcz > > ==================== Summary ==================== > > Name: MonticelloConfigurations-topa.138 > Author: topa > Time: 24 September 2015, 2:48:24.846 pm > UUID: 153b9666-3723-4eb0-b230-7bc75450b892 > Ancestors: MonticelloConfigurations-dtl.137 > > Do not nil out Updaters on initialize, beacuse this can screw the whole update process. > > =============== Diff against MonticelloConfigurations-dtl.137 =============== > > Item was changed: From bert at freudenbergs.de Thu Sep 24 13:28:09 2015 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Sep 24 13:28:12 2015 Subject: [squeak-dev] The Trunk: MonticelloConfigurations-topa.138.mcz In-Reply-To: References: Message-ID: <43FC2622-CCC2-49C8-B6FB-CDDF9C9304EC@freudenbergs.de> > On 24.09.2015, at 14:59, Tobias Pape wrote: > > Here's the thing: > > The change to initialize effects that it is called. > Hence, after updating _past_ MonticelloConfigurations-dtl.137, > the Updaters classvar of MCMcmUpdater will be nil, and hence > every following attempt to update will restart from 1 and, > inevitably, fail eventually. > (Evidence: all saved images from the CI since september 3) > > What we can do: > - remove the last three .mcm's that reference MonticelloConfigurations-dtl.137 > - update-eem.333 > - update-eem.334 > - update-eem.335 > - I don't know whether each of them is an important milestone for loading > individually. > if so: > - replace 333-335 with maps that refer to MonticelloConfigurations-topa.138 > to skip 137 > if not: > - make a new 333 that merges the changes of the old 333-335 and > refers to MonticelloConfigurations-topa.138, also to skip 137. > > Thoughts? Simplest to just overwrite them with ones having topa.138 IMHO. Pretty simple to do to. - Bert - > > Best regards > -Tobias > > > On 24.09.2015, at 12:48, commits@source.squeak.org wrote: > >> Tobias Pape uploaded a new version of MonticelloConfigurations to project The Trunk: >> http://source.squeak.org/trunk/MonticelloConfigurations-topa.138.mcz >> >> ==================== Summary ==================== >> >> Name: MonticelloConfigurations-topa.138 >> Author: topa >> Time: 24 September 2015, 2:48:24.846 pm >> UUID: 153b9666-3723-4eb0-b230-7bc75450b892 >> Ancestors: MonticelloConfigurations-dtl.137 >> >> Do not nil out Updaters on initialize, beacuse this can screw the whole update process. >> >> =============== Diff against MonticelloConfigurations-dtl.137 =============== >> >> Item was changed: > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4115 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150924/c8103f3f/smime.bin From Das.Linux at gmx.de Thu Sep 24 13:56:00 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu Sep 24 13:56:18 2015 Subject: [squeak-dev] The Trunk: MonticelloConfigurations-topa.138.mcz In-Reply-To: <43FC2622-CCC2-49C8-B6FB-CDDF9C9304EC@freudenbergs.de> References: <43FC2622-CCC2-49C8-B6FB-CDDF9C9304EC@freudenbergs.de> Message-ID: <29868EFF-CFEE-483B-B128-EE31F5FCE09E@gmx.de> On 24.09.2015, at 15:28, Bert Freudenberg wrote: >> >> On 24.09.2015, at 14:59, Tobias Pape wrote: >> >> Here's the thing: >> >> The change to initialize effects that it is called. >> Hence, after updating _past_ MonticelloConfigurations-dtl.137, >> the Updaters classvar of MCMcmUpdater will be nil, and hence >> every following attempt to update will restart from 1 and, >> inevitably, fail eventually. >> (Evidence: all saved images from the CI since september 3) >> >> What we can do: >> - remove the last three .mcm's that reference MonticelloConfigurations-dtl.137 >> - update-eem.333 >> - update-eem.334 >> - update-eem.335 >> - I don't know whether each of them is an important milestone for loading >> individually. >> if so: >> - replace 333-335 with maps that refer to MonticelloConfigurations-topa.138 >> to skip 137 >> if not: >> - make a new 333 that merges the changes of the old 333-335 and >> refers to MonticelloConfigurations-topa.138, also to skip 137. >> >> Thoughts? > > > Simplest to just overwrite them with ones having topa.138 IMHO. Pretty simple to do to. Could you do that? I'm always confused by the config editor and am afraid to break things :D Best regards -Tobias > > - Bert - > >> >> Best regards >> -Tobias >> >> >> On 24.09.2015, at 12:48, commits@source.squeak.org wrote: >> >>> Tobias Pape uploaded a new version of MonticelloConfigurations to project The Trunk: >>> http://source.squeak.org/trunk/MonticelloConfigurations-topa.138.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: MonticelloConfigurations-topa.138 >>> Author: topa >>> Time: 24 September 2015, 2:48:24.846 pm >>> UUID: 153b9666-3723-4eb0-b230-7bc75450b892 >>> Ancestors: MonticelloConfigurations-dtl.137 >>> >>> Do not nil out Updaters on initialize, beacuse this can screw the whole update process. >>> >>> =============== Diff against MonticelloConfigurations-dtl.137 =============== >>> >>> Item was changed: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1625 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150924/d518d0b6/signature.pgp From geert.wl.claes at gmail.com Thu Sep 24 14:28:42 2015 From: geert.wl.claes at gmail.com (Geert Claes) Date: Thu Sep 24 14:37:06 2015 Subject: [squeak-dev] World.st has a new admin Message-ID: <1443104922508-4851814.post@n4.nabble.com> The admin duties have now been handed over to Sean DeNigris who kindly volunteered to look after the www.world.st web presence as well as the Nabble archived mailing list forums on forum.world.st. As mentioned in a previous post, I did establish The World of Smalltalk some years ago I have now unfortunately too many other things on my plate. So I feel a person who is closer to the Smalltalk action will be better suited to take over the reins and I wish Sean all the best to continue! -- View this message in context: http://forum.world.st/World-st-has-a-new-admin-tp4851814.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From bert at freudenbergs.de Thu Sep 24 14:55:09 2015 From: bert at freudenbergs.de (Bert Freudenberg) Date: Thu Sep 24 14:55:12 2015 Subject: [squeak-dev] The Trunk: MonticelloConfigurations-topa.138.mcz In-Reply-To: <29868EFF-CFEE-483B-B128-EE31F5FCE09E@gmx.de> References: <43FC2622-CCC2-49C8-B6FB-CDDF9C9304EC@freudenbergs.de> <29868EFF-CFEE-483B-B128-EE31F5FCE09E@gmx.de> Message-ID: <67C19646-D736-4499-AA0E-C1BC897F5E1E@freudenbergs.de> > On 24.09.2015, at 15:56, Tobias Pape wrote: > > > On 24.09.2015, at 15:28, Bert Freudenberg wrote: > >>> >>> On 24.09.2015, at 14:59, Tobias Pape wrote: >>> >>> Here's the thing: >>> >>> The change to initialize effects that it is called. >>> Hence, after updating _past_ MonticelloConfigurations-dtl.137, >>> the Updaters classvar of MCMcmUpdater will be nil, and hence >>> every following attempt to update will restart from 1 and, >>> inevitably, fail eventually. >>> (Evidence: all saved images from the CI since september 3) >>> >>> What we can do: >>> - remove the last three .mcm's that reference MonticelloConfigurations-dtl.137 >>> - update-eem.333 >>> - update-eem.334 >>> - update-eem.335 >>> - I don't know whether each of them is an important milestone for loading >>> individually. >>> if so: >>> - replace 333-335 with maps that refer to MonticelloConfigurations-topa.138 >>> to skip 137 >>> if not: >>> - make a new 333 that merges the changes of the old 333-335 and >>> refers to MonticelloConfigurations-topa.138, also to skip 137. >>> >>> Thoughts? >> >> >> Simplest to just overwrite them with ones having topa.138 IMHO. Pretty simple to do to. > > Could you do that? > I'm always confused by the config editor and am afraid to break things :D > > Best regards > -Tobias Hehe. Sure. Done. - Bert - -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4115 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150924/c6c55286/smime.bin From Das.Linux at gmx.de Thu Sep 24 15:10:22 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu Sep 24 15:10:32 2015 Subject: [squeak-dev] The Trunk: MonticelloConfigurations-topa.138.mcz In-Reply-To: <67C19646-D736-4499-AA0E-C1BC897F5E1E@freudenbergs.de> References: <43FC2622-CCC2-49C8-B6FB-CDDF9C9304EC@freudenbergs.de> <29868EFF-CFEE-483B-B128-EE31F5FCE09E@gmx.de> <67C19646-D736-4499-AA0E-C1BC897F5E1E@freudenbergs.de> Message-ID: Thanks! On 24.09.2015, at 16:55, Bert Freudenberg wrote: >> >> On 24.09.2015, at 15:56, Tobias Pape wrote: >> >> >> On 24.09.2015, at 15:28, Bert Freudenberg wrote: >> >>>> >>>> On 24.09.2015, at 14:59, Tobias Pape wrote: >>>> >>>> Here's the thing: >>>> >>>> The change to initialize effects that it is called. >>>> Hence, after updating _past_ MonticelloConfigurations-dtl.137, >>>> the Updaters classvar of MCMcmUpdater will be nil, and hence >>>> every following attempt to update will restart from 1 and, >>>> inevitably, fail eventually. >>>> (Evidence: all saved images from the CI since september 3) >>>> >>>> What we can do: >>>> - remove the last three .mcm's that reference MonticelloConfigurations-dtl.137 >>>> - update-eem.333 >>>> - update-eem.334 >>>> - update-eem.335 >>>> - I don't know whether each of them is an important milestone for loading >>>> individually. >>>> if so: >>>> - replace 333-335 with maps that refer to MonticelloConfigurations-topa.138 >>>> to skip 137 >>>> if not: >>>> - make a new 333 that merges the changes of the old 333-335 and >>>> refers to MonticelloConfigurations-topa.138, also to skip 137. >>>> >>>> Thoughts? >>> >>> >>> Simplest to just overwrite them with ones having topa.138 IMHO. Pretty simple to do to. >> >> Could you do that? >> I'm always confused by the config editor and am afraid to break things :D >> >> Best regards >> -Tobias > > Hehe. Sure. Done. > > - Bert - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1625 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150924/f1fd4181/signature.pgp From tim at rowledge.org Thu Sep 24 17:31:04 2015 From: tim at rowledge.org (tim Rowledge) Date: Thu Sep 24 17:31:09 2015 Subject: [squeak-dev] World.st has a new admin In-Reply-To: <1443104922508-4851814.post@n4.nabble.com> References: <1443104922508-4851814.post@n4.nabble.com> Message-ID: <764E7CD7-237B-44EA-92A9-95ABB943E0B4@rowledge.org> Thanks Geert for having run it and thanks to Sean for taking it over. Our world is full of people just getting on with making things for us; we should thank them more often. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Attitudes are contagious. Mine might kill you From tim at rowledge.org Thu Sep 24 17:37:51 2015 From: tim at rowledge.org (tim Rowledge) Date: Thu Sep 24 17:37:57 2015 Subject: [squeak-dev] Squeak on iOS at last? In-Reply-To: References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> <9262BBB4-0912-4A78-BCB4-96715B651D2B@rowledge.org> <5483C1C6-D733-4692-A58E-8100CED365A1@mac.com> <27514884-1477-41B2-8EA9-8A45282F529F@rowledge.org> Message-ID: <27AD774B-E9D0-42F2-9461-0004FB95CBDD@rowledge.org> > On 24-09-2015, at 1:01 AM, Craig Latta wrote: > > >> I thought Apple were supposed to use EeeevilAppleRays to blow up old >> hardware to force the sheeple to buy More! New! Hardware! > > Nope, those sheeple buy plenty of other Apple things while they use > their Old! Obsolete! Hardware! (maybe even something from iTunes now and > then), and for the moment Apple would rather not drive them away. But that doesn?t fit the Hater Narrative! Maybe if we?re lucky their heads will implode. > Meanwhile the bleeding-edgers get to use a horrible new font. :) Urgh, yes. I finally got around to updating my iMac to yosemite yesterday and that is rather annoying. And just who thought that making a large lump of spotlight materialise in the middle of the display was a good idea? Sigh. I may have to use the Top Secret RCA Alumni Underground to have Words with Jony. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDL: Shift Disk Left From kilon.alios at gmail.com Thu Sep 24 17:56:47 2015 From: kilon.alios at gmail.com (Dimitris Chloupis) Date: Thu Sep 24 17:56:58 2015 Subject: [squeak-dev] Re: [Pharo-dev] World.st has a new admin In-Reply-To: References: <1443104863129-4851811.post@n4.nabble.com> Message-ID: Thank you Sean :) On Thu, Sep 24, 2015 at 8:47 PM Stephan Eggermont wrote: > On 24/09/15 16:27, Geert Claes wrote: > > The admin duties have now been handed over to Sean DeNigris who kindly > > volunteered to look after the www.world.st web presence as well as the > > Nabble archived mailing list forums on forum.world.st. > > Thank you Geert, for taking care of this important community resource > for us for so long, and Sean for stepping in and taking over. > > Stephan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150924/51851c3f/attachment.htm From craig at netjam.org Thu Sep 24 18:40:48 2015 From: craig at netjam.org (Craig Latta) Date: Thu Sep 24 18:41:12 2015 Subject: [squeak-dev] re: Squeak on iOS at last? In-Reply-To: <27AD774B-E9D0-42F2-9461-0004FB95CBDD@rowledge.org> References: <65753F78-F1C4-4234-B823-C748B9836DC5@gmail.com> <90BD9FAA-1B73-496C-89FD-A22B9DAC1F3B@freudenbergs.de> <9262BBB4-0912-4A78-BCB4-96715B651D2B@rowledge.org> <5483C1C6-D733-4692-A58E-8100CED365A1@mac.com> <27514884-1477-41B2-8EA9-8A45282F529F@rowledge.org> <27AD774B-E9D0-42F2-9461-0004FB95CBDD@rowledge.org> Message-ID: > > Meanwhile the bleeding-edgers get to use a horrible new font. :) > > Urgh, yes. I finally got around to updating my iMac to yosemite > yesterday and that is rather annoying. Oh, no, the Yosemite font is great. I meant the El Capitan font. :) > And just who thought that making a large lump of spotlight > materialise in the middle of the display was a good idea? Oh, I do! Hey, this is great: they're doomed no matter what they do (unless, of course, they were to add a few dozen more preferences settings). -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From commits at source.squeak.org Thu Sep 24 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Thu Sep 24 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150924215502.21391.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008973.html Name: MonticelloConfigurations-topa.138 Ancestors: MonticelloConfigurations-dtl.137 Do not nil out Updaters on initialize, beacuse this can screw the whole update process. ============================================= From commits at source.squeak.org Fri Sep 25 15:39:45 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 25 15:39:46 2015 Subject: [squeak-dev] The Trunk: Regex-Tests-Core-ul.3.mcz Message-ID: Levente Uzonyi uploaded a new version of Regex-Tests-Core to project The Trunk: http://source.squeak.org/trunk/Regex-Tests-Core-ul.3.mcz ==================== Summary ==================== Name: Regex-Tests-Core-ul.3 Author: ul Time: 25 September 2015, 5:39:06.012 pm UUID: cf86029f-c2dd-4fe9-a926-d1024319d981 Ancestors: Regex-Tests-Core-ul.2 Added a test for character sets containing escaped characters. =============== Diff against Regex-Tests-Core-ul.2 =============== Item was added: + ----- Method: RxParserTest>>testCharacterSetWithEscapedCharacters (in category 'tests') ----- + testCharacterSetWithEscapedCharacters + "self debug: #testCharacterSetRange" + + { + '[\r]'. String cr. String space. + '[\n]'. String lf. String space. + '[\t]'. String tab. String space. + '[\e]'. Character escape asString. String space. + '[\f]'. Character newPage asString. String space. + '[\]]+'. ']]]'. '[[['. + '[\S]+[\s]+=[\s]+#[^\[(]'. 'foo = #bar'. 'foo = #[1 2 3]'. + '[\d]+'. '123'. 'abc'. + '[\D]+'. 'abc'. '123'. + '[\w]+'. 'a1_b2'. '...'. + '[\W]+'. '...'. 'a1_b2'. + } groupsDo: [ :regexString :inputToAccept :inputToReject | + | regex | + regex := regexString asRegex. + self + assert: (regex search: inputToAccept); + deny: (regex search: inputToReject) ]! From commits at source.squeak.org Fri Sep 25 15:40:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 25 15:40:04 2015 Subject: [squeak-dev] The Trunk: Regex-Core-ul.45.mcz Message-ID: Levente Uzonyi uploaded a new version of Regex-Core to project The Trunk: http://source.squeak.org/trunk/Regex-Core-ul.45.mcz ==================== Summary ==================== Name: Regex-Core-ul.45 Author: ul Time: 25 September 2015, 10:14:55.741 am UUID: 0b7b582a-5091-43e4-95f2-981f236e991c Ancestors: Regex-Core-ul.44 - Allow escaping any character in a character set. - Use RxsCharacter instead of RxsPredicate for single character escapes like \r, \n, etc. - Use nil instead of #epsilon for the extremal stream element in RxParser. - RxParser >> #next returns the value of lookahead. Use it where it makes sense. - RxsPredicate's class variables' initialization is thread-safe. - Reinitialize EscapedLetterSelectors in the postscript. =============== Diff against Regex-Core-ul.44 =============== Item was changed: ----- Method: RxCharSetParser>>parseEscapeChar (in category 'parsing') ----- parseEscapeChar self match: $\. + elements add: ((RxsPredicate forEscapedLetter: lookahead) + ifNil: [ RxsCharacter with: lookahead ]). - $- == lookahead - ifTrue: [elements add: (RxsCharacter with: $-)] - ifFalse: [elements add: (RxsPredicate forEscapedLetter: lookahead)]. self next! Item was changed: ----- Method: RxParser>>atom (in category 'recursive descent') ----- atom "An atom is one of a lot of possibilities, see below." | atom | + (lookahead == nil - (lookahead == #epsilon or: [ lookahead == $| or: [ lookahead == $) or: [ lookahead == $* or: [ lookahead == $+ or: [ lookahead == $? ]]]]]) ifTrue: [ ^RxsEpsilon new ]. lookahead == $( ifTrue: [ " ::= '(' ')' " self match: $(. atom := self regex. self match: $). ^atom ]. lookahead == $[ ifTrue: [ " ::= '[' ']' " self match: $[. atom := self characterSet. self match: $]. ^atom ]. lookahead == $: ifTrue: [ " ::= ':' ':' " self match: $:. atom := self messagePredicate. self match: $:. ^atom ]. lookahead == $. ifTrue: [ "any non-whitespace character" self next. ^RxsContextCondition new beAny]. lookahead == $^ ifTrue: [ "beginning of line condition" self next. ^RxsContextCondition new beBeginningOfLine]. lookahead == $$ ifTrue: [ "end of line condition" self next. ^RxsContextCondition new beEndOfLine]. lookahead == $\ ifTrue: [ " ::= '\' " + self next ifNil: [ self signalParseError: 'bad quotation' ]. + (BackslashConstants includesKey: lookahead) ifTrue: [ + atom := RxsCharacter with: (BackslashConstants at: lookahead). + self next. + ^atom]. - self next. - lookahead == #epsilon - ifTrue: [ self signalParseError: 'bad quotation' ]. - (BackslashConstants includesKey: lookahead) - ifTrue: [ - atom := RxsCharacter with: (BackslashConstants at: lookahead). - self next. - ^atom]. self ifSpecial: lookahead then: [:node | self next. ^node]]. "If passed through the above, the following is a regular character." atom := RxsCharacter with: lookahead. self next. ^atom! Item was changed: ----- Method: RxParser>>branch (in category 'recursive descent') ----- branch " ::= e | " | piece branch | piece := self piece. + (lookahead == nil - (lookahead == #epsilon or: [ lookahead == $| or: [ lookahead == $) ]]) ifTrue: [ branch := nil ] ifFalse: [ branch := self branch ]. ^RxsBranch new initializePiece: piece branch: branch! Item was changed: ----- Method: RxParser>>inputUpTo:errorMessage: (in category 'private') ----- inputUpTo: aCharacter errorMessage: aString "Accumulate input stream until is encountered and answer the accumulated chars as String, not including . Signal error if end of stream is encountered, passing as the error description." | accumulator | accumulator := WriteStream on: (String new: 20). + [ lookahead == aCharacter or: [lookahead == nil ] ] - [ lookahead == aCharacter or: [lookahead == #epsilon] ] whileFalse: [ accumulator nextPut: lookahead. self next]. + lookahead ifNil: [ self signalParseError: aString ]. - lookahead == #epsilon - ifTrue: [ self signalParseError: aString ]. ^accumulator contents! Item was changed: ----- Method: RxParser>>inputUpTo:nestedOn:errorMessage: (in category 'private') ----- inputUpTo: aCharacter nestedOn: anotherCharacter errorMessage: aString "Accumulate input stream until is encountered and answer the accumulated chars as String, not including . Signal error if end of stream is encountered, passing as the error description." | accumulator nestLevel | accumulator := WriteStream on: (String new: 20). nestLevel := 0. + [ lookahead == aCharacter and: [ nestLevel = 0 ] ] whileFalse: [ + lookahead ifNil: [ self signalParseError: aString ]. + lookahead == $\ + ifTrue: [ + self next ifNil: [ self signalParseError: aString ]. + BackslashConstants + at: lookahead + ifPresent: [ :unescapedCharacter | accumulator nextPut: unescapedCharacter ] + ifAbsent: [ + accumulator + nextPut: $\; + nextPut: lookahead ] ] + ifFalse: [ + accumulator nextPut: lookahead. + lookahead == anotherCharacter ifTrue: [ nestLevel := nestLevel + 1 ]. + lookahead == aCharacter ifTrue: [ nestLevel := nestLevel - 1 ] ]. + self next ]. - [lookahead == aCharacter and: [nestLevel = 0]] whileFalse: - [#epsilon == lookahead ifTrue: [self signalParseError: aString]. - accumulator nextPut: lookahead. - lookahead == anotherCharacter ifTrue: [nestLevel := nestLevel + 1]. - lookahead == aCharacter ifTrue: [nestLevel := nestLevel - 1]. - self next]. ^accumulator contents! Item was changed: ----- Method: RxParser>>inputUpToAny:errorMessage: (in category 'private') ----- inputUpToAny: aDelimiterString errorMessage: aString "Accumulate input stream until any character from is encountered and answer the accumulated chars as String, not including the matched characters from the . Signal error if end of stream is encountered, passing as the error description." | accumulator | accumulator := WriteStream on: (String new: 20). + [ lookahead == nil or: [ aDelimiterString includes: lookahead ] ] - [ lookahead == #epsilon or: [ aDelimiterString includes: lookahead ] ] whileFalse: [ accumulator nextPut: lookahead. self next ]. + lookahead ifNil: [ self signalParseError: aString ]. - lookahead == #epsilon - ifTrue: [ self signalParseError: aString ]. ^accumulator contents! Item was changed: ----- Method: RxParser>>next (in category 'private') ----- next "Advance the input storing the just read character as the lookahead." + ^lookahead := input next! - lookahead := input next ifNil: [ #epsilon ]! Item was changed: ----- Method: RxParser>>parseStream: (in category 'accessing') ----- parseStream: aStream "Parse an input from a character stream . On success, answers an RxsRegex -- parse tree root. On error, raises `RxParser syntaxErrorSignal' with the current input stream position as the parameter." | tree | input := aStream. + self next. - lookahead := nil. - self match: nil. tree := self regex. + self match: nil. - self match: #epsilon. ^tree! Item was changed: ----- Method: RxParser>>regex (in category 'recursive descent') ----- regex " ::= e | `|' " | branch regex | branch := self branch. + (lookahead == nil - (lookahead == #epsilon or: [ lookahead == $) ]) ifTrue: [ regex := nil ] ifFalse: [ self match: $|. regex := self regex ]. ^RxsRegex new initializeBranch: branch regex: regex! Item was changed: ----- Method: RxsPredicate class>>forEscapedLetter: (in category 'instance creation') ----- forEscapedLetter: aCharacter + "Return a predicate instance for the given character, or nil if there's no such predicate." + ^EscapedLetterSelectors + at: aCharacter + ifPresent: [ :selector | self new perform: selector ]! - ^self new perform: - (EscapedLetterSelectors - at: aCharacter - ifAbsent: [RxParser signalSyntaxException: 'bad backslash escape'])! Item was changed: ----- Method: RxsPredicate class>>initializeEscapedLetterSelectors (in category 'class initialization') ----- initializeEscapedLetterSelectors "self initializeEscapedLetterSelectors" + EscapedLetterSelectors := Dictionary new - | newEscapedLetterSelectors | - newEscapedLetterSelectors := Dictionary new at: $w put: #beWordConstituent; at: $W put: #beNotWordConstituent; at: $d put: #beDigit; at: $D put: #beNotDigit; at: $s put: #beSpace; at: $S put: #beNotSpace; + yourself! - at: $\ put: #beBackslash; - at: $r put: #beCarriageReturn; - at: $n put: #beLineFeed; - at: $t put: #beTab; - yourself. - EscapedLetterSelectors := newEscapedLetterSelectors! Item was changed: ----- Method: RxsPredicate class>>initializeNamedClassSelectors (in category 'class initialization') ----- initializeNamedClassSelectors "self initializeNamedClassSelectors" + NamedClassSelectors := Dictionary new - (NamedClassSelectors := Dictionary new) at: 'alnum' put: #beAlphaNumeric; at: 'alpha' put: #beAlphabetic; at: 'cntrl' put: #beControl; at: 'digit' put: #beDigit; at: 'graph' put: #beGraphics; at: 'lower' put: #beLowercase; at: 'print' put: #bePrintable; at: 'punct' put: #bePunctuation; at: 'space' put: #beSpace; at: 'upper' put: #beUppercase; + at: 'xdigit' put: #beHexDigit; + yourself! - at: 'xdigit' put: #beHexDigit! Item was removed: - ----- Method: RxsPredicate>>beBackslash (in category 'initialize-release') ----- - beBackslash - - self beCharacter: $\! Item was removed: - ----- Method: RxsPredicate>>beCarriageReturn (in category 'initialize-release') ----- - beCarriageReturn - - self beCharacter: Character cr! Item was removed: - ----- Method: RxsPredicate>>beLineFeed (in category 'initialize-release') ----- - beLineFeed - - self beCharacter: Character lf! Item was removed: - ----- Method: RxsPredicate>>beTab (in category 'initialize-release') ----- - beTab - - self beCharacter: Character tab! Item was changed: + (PackageInfo named: 'Regex-Core') postscript: 'RxsPredicate initializeEscapedLetterSelectors.'! - (PackageInfo named: 'Regex-Core') postscript: 'RxsPredicate initializeEscapedLetterSelectors'! From robert.w.withers at gmail.com Fri Sep 25 16:12:49 2015 From: robert.w.withers at gmail.com (robert) Date: Fri Sep 25 16:12:41 2015 Subject: [squeak-dev] NS` how can I get programmatic reference to a particular category? Message-ID: <56057281.7020202@gmail.com> I must define variableByte subclasses in the category. Categories are not part of the namespace nor or symbols looked for there. SO I need programmatic access. I didn't find anything in the documentation, as it is an implementation issue. Could someone knowledgeable point out how I can do this? ty, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3721 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150925/dd28c8ff/smime.bin From commits at source.squeak.org Fri Sep 25 18:21:52 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 25 18:21:54 2015 Subject: [squeak-dev] The Trunk: 50Deprecated-eem.1.mcz Message-ID: Eliot Miranda uploaded a new version of 50Deprecated to project The Trunk: http://source.squeak.org/trunk/50Deprecated-eem.1.mcz ==================== Summary ==================== Name: 50Deprecated-eem.1 Author: eem Time: 25 September 2015, 11:21:50.573 am UUID: 1cbbbbba-2820-4e14-a6c4-43d69939f7ef Ancestors: First version of unsent deprecated methods for Squeak 5.0. ==================== Snapshot ==================== ----- Method: Dictionary>>fasterKeys (in category '*50Deprecated-accessing') ----- fasterKeys "Contrary to old version of #keys, this method returned an Array rather than a Set. This was faster because no lookup: was performed. But now, #keys also return an Array, so don't use #fasterKeys anymore." self deprecated: 'use #keys'. ^self keys. ! ----- Method: Dictionary>>keyForIdentity: (in category '*50Deprecated-accessing') ----- keyForIdentity: anObject "If anObject is one of the values of the receive, return its key, else return nil. Contrast #keyAtValue: in which there is only an equality check, here there is an identity check" self deprecated: 'Use #keyAtIdentityValue:ifAbsent:'. ^self keyAtIdentityValue: anObject ifAbsent: nil! From commits at source.squeak.org Fri Sep 25 18:35:43 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 25 18:35:44 2015 Subject: [squeak-dev] The Trunk: CollectionsTests-eem.251.mcz Message-ID: Eliot Miranda uploaded a new version of CollectionsTests to project The Trunk: http://source.squeak.org/trunk/CollectionsTests-eem.251.mcz ==================== Summary ==================== Name: CollectionsTests-eem.251 Author: eem Time: 25 September 2015, 11:35:30.23 am UUID: 28351c02-3f12-449e-8d40-bcae2557b843 Ancestors: CollectionsTests-ul.250 Add a test for at:ifAbsent:ifPresentPut: =============== Diff against CollectionsTests-ul.250 =============== Item was added: + ----- Method: DictionaryTest>>testAtIfPresentIfAbsentPut (in category 'basic tests') ----- + testAtIfPresentIfAbsentPut + "Test at:ifPresent:ifAbsentPut:" + | dict present absent | + dict := Dictionary new. + present := absent := false. + self assert: (dict at: #foo ifPresent:[:v| present := true. v] ifAbsentPut:[absent := true. #present]) + equals: #present. + self deny: present. + self assert: absent. + + present := absent := false. + self assert: (dict at: #foo ifPresent:[:v| present := true. v] ifAbsentPut:[absent := true. #absent]) + equals: #present. + self assert: present. + self deny: absent.! From commits at source.squeak.org Fri Sep 25 18:37:09 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 25 18:37:10 2015 Subject: [squeak-dev] The Trunk: Collections-eem.656.mcz Message-ID: Eliot Miranda uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-eem.656.mcz ==================== Summary ==================== Name: Collections-eem.656 Author: eem Time: 25 September 2015, 11:36:48.911 am UUID: 50ec1b3e-c058-4167-889e-836e994b500b Ancestors: Collections-ul.655 Add Dictionary>>at:ifPresent:ifAbsentPut:. Move Dictionary>>fasterKeys & keyForIdentity: to 50Deprecated =============== Diff against Collections-ul.655 =============== Item was added: + ----- Method: Dictionary>>at:ifPresent:ifAbsentPut: (in category 'accessing') ----- + at: key ifPresent: oneArgBlock ifAbsentPut: absentBlock + "Lookup the given key in the receiver. If it is present, answer the value of + evaluating oneArgBlock with the value associated with the key. Otherwise + add the value of absentBlock under the key, and answer that value." + + | index value | + index := self scanFor: key. + (array at: index) ifNotNil: + [:element| + ^oneArgBlock value: element value]. + value := absentBlock value. + self atNewIndex: index put: (Association key: key value: value). + ^value! Item was removed: - ----- Method: Dictionary>>fasterKeys (in category 'accessing') ----- - fasterKeys - "Contrary to old version of #keys, this method returned an Array rather than a Set. - This was faster because no lookup: was performed. - But now, #keys also return an Array, so don't use #fasterKeys anymore." - - self deprecated: 'use #keys'. - - ^self keys. - ! Item was removed: - ----- Method: Dictionary>>keyForIdentity: (in category 'accessing') ----- - keyForIdentity: anObject - "If anObject is one of the values of the receive, return its key, else return nil. Contrast #keyAtValue: in which there is only an equality check, here there is an identity check" - - self deprecated: 'Use #keyAtIdentityValue:ifAbsent:'. - ^self keyAtIdentityValue: anObject ifAbsent: nil! From commits at source.squeak.org Fri Sep 25 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Fri Sep 25 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150925215502.13121.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008974.html Name: Regex-Tests-Core-ul.3 Ancestors: Regex-Tests-Core-ul.2 Added a test for character sets containing escaped characters. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008975.html Name: Regex-Core-ul.45 Ancestors: Regex-Core-ul.44 - Allow escaping any character in a character set. - Use RxsCharacter instead of RxsPredicate for single character escapes like \r, \n, etc. - Use nil instead of #epsilon for the extremal stream element in RxParser. - RxParser >> #next returns the value of lookahead. Use it where it makes sense. - RxsPredicate's class variables' initialization is thread-safe. - Reinitialize EscapedLetterSelectors in the postscript. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008976.html Name: 50Deprecated-eem.1 Ancestors: First version of unsent deprecated methods for Squeak 5.0. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008977.html Name: CollectionsTests-eem.251 Ancestors: CollectionsTests-ul.250 Add a test for at:ifAbsent:ifPresentPut: ============================================= http://lists.squeakfoundation.org/pipermail/packages/2015-September/008978.html Name: Collections-eem.656 Ancestors: Collections-ul.655 Add Dictionary>>at:ifPresent:ifAbsentPut:. Move Dictionary>>fasterKeys & keyForIdentity: to 50Deprecated ============================================= From hmm at heeg.de Sat Sep 26 07:26:01 2015 From: hmm at heeg.de (Hans-Martin Mosner) Date: Sat Sep 26 07:26:05 2015 Subject: [squeak-dev] NS` how can I get programmatic reference to a particular category? In-Reply-To: <56057281.7020202@gmail.com> References: <56057281.7020202@gmail.com> Message-ID: <56064889.5090404@heeg.de> Am 25.09.2015 um 18:12 schrieb robert: > I must define variableByte subclasses in the category. Categories are not part of the namespace nor or symbols looked > for there. SO I need programmatic access. I didn't find anything in the documentation, as it is an implementation > issue. Could someone knowledgeable point out how I can do this? > > ty, > Robert > > > It is somewhat unclear what you want to achieve. Categories are simple strings, and "Smalltalk organization" (a SystemOrganizer) keeps the association between classes and categories. To create a class in a given category, just execute the class creation expression with the proper category, something like this: | nameOfYourClass nameOfYourCategory | nameOfYourClass := #MyNewClass. nameOfYourCategory := 'MyOldCategory'. Object variableByteSubclass: nameOfYourClass instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: nameOfYourCategory Cheers, Hans-Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150926/e3f5d931/attachment.htm From Marcel.Taeumel at hpi.de Sat Sep 26 11:44:52 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Sat Sep 26 11:53:30 2015 Subject: [squeak-dev] Re: The Trunk: 50Deprecated-eem.1.mcz In-Reply-To: References: Message-ID: <1443267892398-4852077.post@n4.nabble.com> It should be 51Deprecated then? ;) Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-50Deprecated-eem-1-mcz-tp4852032p4852077.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From eliot.miranda at gmail.com Sat Sep 26 14:28:13 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Sep 26 14:28:18 2015 Subject: [squeak-dev] Re: The Trunk: 50Deprecated-eem.1.mcz In-Reply-To: <1443267892398-4852077.post@n4.nabble.com> References: <1443267892398-4852077.post@n4.nabble.com> Message-ID: <44C5E6AA-B286-4F05-A71D-DC3858B85915@gmail.com> Hi Marcel, Could you explain? I saw 45Deprecated and 46Deprecated but I didn't see any 47Deprecated and so concluded that the tip deprecated is the same as the current version. But that was a guess. What's the proper rationale? _,,,^..^,,,_ (phone) > On Sep 26, 2015, at 4:44 AM, marcel.taeumel wrote: > > It should be 51Deprecated then? ;) > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/The-Trunk-50Deprecated-eem-1-mcz-tp4852032p4852077.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > From lecteur at zogotounga.net Sat Sep 26 16:36:22 2015 From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=) Date: Sat Sep 26 16:36:20 2015 Subject: [squeak-dev] No MIDI ports found on Linux Message-ID: <5606C986.7080401@zogotounga.net> Hello, Testing the 5.0 all-in-one from squeak.org in a Mint 17.2 running in VirtualBox (Windows 8.1 host), I see that SimpleMIDIPort midiIsSupported returns false with the linux VM, and true with the Windows VM (run though Wine). So it seems to me that the linux MIDIPlugin is broken (or am I missing something ?) Stef From Das.Linux at gmx.de Sat Sep 26 16:51:06 2015 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat Sep 26 16:51:09 2015 Subject: [squeak-dev] The Trunk: 50Deprecated-eem.1.mcz In-Reply-To: <44C5E6AA-B286-4F05-A71D-DC3858B85915@gmail.com> References: <1443267892398-4852077.post@n4.nabble.com> <44C5E6AA-B286-4F05-A71D-DC3858B85915@gmail.com> Message-ID: On 26.09.2015, at 16:28, Eliot Miranda wrote: > Hi Marcel, > > Could you explain? I saw 45Deprecated and 46Deprecated but I didn't see any 47Deprecated and so concluded that the tip deprecated is the same as the current version. But that was a guess. What's the proper rationale? > 46Deprecated is conceptually the same as 50Deprecated, That is anything in those packages was deprecated with the release of 4.6/5.0. Anything newly deprecated has to go to the next release, that is 5.1, so that it is deprecated from 5.1 on. (It cannot be from 5.0 on, because that is out already) Best regards -Tobias > _,,,^..^,,,_ (phone) > >> On Sep 26, 2015, at 4:44 AM, marcel.taeumel wrote: >> >> It should be 51Deprecated then? ;) >> >> Best, >> Marcel >> >> >> >> -- >> View this message in context: http://forum.world.st/The-Trunk-50Deprecated-eem-1-mcz-tp4852032p4852077.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. From robert.w.withers at gmail.com Sat Sep 26 16:52:25 2015 From: robert.w.withers at gmail.com (robert) Date: Sat Sep 26 16:52:15 2015 Subject: [squeak-dev] NS` how can I get programmatic reference to a particular category? In-Reply-To: <56064889.5090404@heeg.de> References: <56057281.7020202@gmail.com> <56064889.5090404@heeg.de> Message-ID: <5606CD49.5090102@gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3721 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150926/eae7fafb/smime.bin From leves at elte.hu Sat Sep 26 17:36:20 2015 From: leves at elte.hu (Levente Uzonyi) Date: Sat Sep 26 17:36:26 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: <5606C986.7080401@zogotounga.net> References: <5606C986.7080401@zogotounga.net> Message-ID: MIDIPlugin doesn't seem to be included in 5.0 all-in-one. Levente On Sat, 26 Sep 2015, St?phane Rollandin wrote: > Hello, > > Testing the 5.0 all-in-one from squeak.org in a Mint 17.2 running in > VirtualBox (Windows 8.1 host), I see that > > SimpleMIDIPort midiIsSupported > > returns false with the linux VM, and true with the Windows VM (run though > Wine). > > So it seems to me that the linux MIDIPlugin is broken (or am I missing > something ?) > > > Stef > > From leves at elte.hu Sat Sep 26 18:03:13 2015 From: leves at elte.hu (Levente Uzonyi) Date: Sat Sep 26 18:03:19 2015 Subject: [squeak-dev] The Trunk: Collections-eem.656.mcz In-Reply-To: References: Message-ID: Implementing #at:ifPresent:ifAbsentPut: without reusing #at:ifAbsent: and #at:ifAbsentPut: implies that it must be defined in some of its subclasses too to make it work. This is the reason why #at:ifAbsentPut: and #at:ifPresent:ifAbsent: reuse the low-level methods, sacrificing performance. Levente On Fri, 25 Sep 2015, commits@source.squeak.org wrote: > Eliot Miranda uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-eem.656.mcz > > ==================== Summary ==================== > > Name: Collections-eem.656 > Author: eem > Time: 25 September 2015, 11:36:48.911 am > UUID: 50ec1b3e-c058-4167-889e-836e994b500b > Ancestors: Collections-ul.655 > > Add Dictionary>>at:ifPresent:ifAbsentPut:. > Move Dictionary>>fasterKeys & keyForIdentity: to 50Deprecated > > =============== Diff against Collections-ul.655 =============== > > Item was added: > + ----- Method: Dictionary>>at:ifPresent:ifAbsentPut: (in category 'accessing') ----- > + at: key ifPresent: oneArgBlock ifAbsentPut: absentBlock > + "Lookup the given key in the receiver. If it is present, answer the value of > + evaluating oneArgBlock with the value associated with the key. Otherwise > + add the value of absentBlock under the key, and answer that value." > + > + | index value | > + index := self scanFor: key. > + (array at: index) ifNotNil: > + [:element| > + ^oneArgBlock value: element value]. > + value := absentBlock value. > + self atNewIndex: index put: (Association key: key value: value). > + ^value! > > Item was removed: > - ----- Method: Dictionary>>fasterKeys (in category 'accessing') ----- > - fasterKeys > - "Contrary to old version of #keys, this method returned an Array rather than a Set. > - This was faster because no lookup: was performed. > - But now, #keys also return an Array, so don't use #fasterKeys anymore." > - > - self deprecated: 'use #keys'. > - > - ^self keys. > - ! > > Item was removed: > - ----- Method: Dictionary>>keyForIdentity: (in category 'accessing') ----- > - keyForIdentity: anObject > - "If anObject is one of the values of the receive, return its key, else return nil. Contrast #keyAtValue: in which there is only an equality check, here there is an identity check" > - > - self deprecated: 'Use #keyAtIdentityValue:ifAbsent:'. > - ^self keyAtIdentityValue: anObject ifAbsent: nil! > > > From eliot.miranda at gmail.com Sat Sep 26 18:30:50 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Sep 26 18:30:56 2015 Subject: [squeak-dev] The Trunk: Collections-eem.656.mcz In-Reply-To: References: Message-ID: <23324AC9-8D7E-4AF2-9CB5-41CE32345FE1@gmail.com> Hi Levente, > On Sep 26, 2015, at 11:03 AM, Levente Uzonyi wrote: > > Implementing #at:ifPresent:ifAbsentPut: without reusing #at:ifAbsent: and #at:ifAbsentPut: implies that it must be defined in some of its subclasses too to make it work. > This is the reason why #at:ifAbsentPut: and #at:ifPresent:ifAbsent: reuse the low-level methods, sacrificing performance. I understand. But a) using a single scanFor: saves half the search work in the ifAbsentPut: case and b) no extra effort is required if the subclass overrides scanFor: which is the real low level method. So I'm happy with my decision. > Levente _,,,^..^,,,_ (phone) > >> On Fri, 25 Sep 2015, commits@source.squeak.org wrote: >> >> Eliot Miranda uploaded a new version of Collections to project The Trunk: >> http://source.squeak.org/trunk/Collections-eem.656.mcz >> >> ==================== Summary ==================== >> >> Name: Collections-eem.656 >> Author: eem >> Time: 25 September 2015, 11:36:48.911 am >> UUID: 50ec1b3e-c058-4167-889e-836e994b500b >> Ancestors: Collections-ul.655 >> >> Add Dictionary>>at:ifPresent:ifAbsentPut:. >> Move Dictionary>>fasterKeys & keyForIdentity: to 50Deprecated >> >> =============== Diff against Collections-ul.655 =============== >> >> Item was added: >> + ----- Method: Dictionary>>at:ifPresent:ifAbsentPut: (in category 'accessing') ----- >> + at: key ifPresent: oneArgBlock ifAbsentPut: absentBlock >> + "Lookup the given key in the receiver. If it is present, answer the value of >> + evaluating oneArgBlock with the value associated with the key. Otherwise >> + add the value of absentBlock under the key, and answer that value." >> + >> + | index value | >> + index := self scanFor: key. >> + (array at: index) ifNotNil: >> + [:element| >> + ^oneArgBlock value: element value]. >> + value := absentBlock value. >> + self atNewIndex: index put: (Association key: key value: value). >> + ^value! >> >> Item was removed: >> - ----- Method: Dictionary>>fasterKeys (in category 'accessing') ----- >> - fasterKeys >> - "Contrary to old version of #keys, this method returned an Array rather than a Set. >> - This was faster because no lookup: was performed. >> - But now, #keys also return an Array, so don't use #fasterKeys anymore." >> - >> - self deprecated: 'use #keys'. >> - >> - ^self keys. >> - ! >> >> Item was removed: >> - ----- Method: Dictionary>>keyForIdentity: (in category 'accessing') ----- >> - keyForIdentity: anObject >> - "If anObject is one of the values of the receive, return its key, else return nil. Contrast #keyAtValue: in which there is only an equality check, here there is an identity check" >> - >> - self deprecated: 'Use #keyAtIdentityValue:ifAbsent:'. >> - ^self keyAtIdentityValue: anObject ifAbsent: nil! > From lecteur at zogotounga.net Sat Sep 26 18:31:00 2015 From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=) Date: Sat Sep 26 18:31:00 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: References: <5606C986.7080401@zogotounga.net> Message-ID: <5606E464.9040304@zogotounga.net> > MIDIPlugin doesn't seem to be included in 5.0 all-in-one. It does appear in Smalltalk listBuiltinModules though... Stef From eliot.miranda at gmail.com Sat Sep 26 18:32:07 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat Sep 26 18:32:13 2015 Subject: [squeak-dev] The Trunk: Collections-eem.656.mcz In-Reply-To: <23324AC9-8D7E-4AF2-9CB5-41CE32345FE1@gmail.com> References: <23324AC9-8D7E-4AF2-9CB5-41CE32345FE1@gmail.com> Message-ID: <15118612-5AC3-45DB-8107-3FAF06C37994@gmail.com> > On Sep 26, 2015, at 11:30 AM, Eliot Miranda wrote: > > Hi Levente, > >> On Sep 26, 2015, at 11:03 AM, Levente Uzonyi wrote: >> >> Implementing #at:ifPresent:ifAbsentPut: without reusing #at:ifAbsent: and #at:ifAbsentPut: implies that it must be defined in some of its subclasses too to make it work. >> This is the reason why #at:ifAbsentPut: and #at:ifPresent:ifAbsent: reuse the low-level methods, sacrificing performance. > > I understand. But a) using a single scanFor: saves half the search work in the ifAbsentPut: case and b) no extra effort is required if the subclass overrides scanFor: which is the real low level method. So I'm happy with my decision. And I'll take a look at subclasses soon. > >> Levente > > _,,,^..^,,,_ (phone) > >> >>> On Fri, 25 Sep 2015, commits@source.squeak.org wrote: >>> >>> Eliot Miranda uploaded a new version of Collections to project The Trunk: >>> http://source.squeak.org/trunk/Collections-eem.656.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Collections-eem.656 >>> Author: eem >>> Time: 25 September 2015, 11:36:48.911 am >>> UUID: 50ec1b3e-c058-4167-889e-836e994b500b >>> Ancestors: Collections-ul.655 >>> >>> Add Dictionary>>at:ifPresent:ifAbsentPut:. >>> Move Dictionary>>fasterKeys & keyForIdentity: to 50Deprecated >>> >>> =============== Diff against Collections-ul.655 =============== >>> >>> Item was added: >>> + ----- Method: Dictionary>>at:ifPresent:ifAbsentPut: (in category 'accessing') ----- >>> + at: key ifPresent: oneArgBlock ifAbsentPut: absentBlock >>> + "Lookup the given key in the receiver. If it is present, answer the value of >>> + evaluating oneArgBlock with the value associated with the key. Otherwise >>> + add the value of absentBlock under the key, and answer that value." >>> + >>> + | index value | >>> + index := self scanFor: key. >>> + (array at: index) ifNotNil: >>> + [:element| >>> + ^oneArgBlock value: element value]. >>> + value := absentBlock value. >>> + self atNewIndex: index put: (Association key: key value: value). >>> + ^value! >>> >>> Item was removed: >>> - ----- Method: Dictionary>>fasterKeys (in category 'accessing') ----- >>> - fasterKeys >>> - "Contrary to old version of #keys, this method returned an Array rather than a Set. >>> - This was faster because no lookup: was performed. >>> - But now, #keys also return an Array, so don't use #fasterKeys anymore." >>> - >>> - self deprecated: 'use #keys'. >>> - >>> - ^self keys. >>> - ! >>> >>> Item was removed: >>> - ----- Method: Dictionary>>keyForIdentity: (in category 'accessing') ----- >>> - keyForIdentity: anObject >>> - "If anObject is one of the values of the receive, return its key, else return nil. Contrast #keyAtValue: in which there is only an equality check, here there is an identity check" >>> - >>> - self deprecated: 'Use #keyAtIdentityValue:ifAbsent:'. >>> - ^self keyAtIdentityValue: anObject ifAbsent: nil! >> From leves at elte.hu Sat Sep 26 18:55:22 2015 From: leves at elte.hu (Levente Uzonyi) Date: Sat Sep 26 18:55:28 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: <5606E464.9040304@zogotounga.net> References: <5606C986.7080401@zogotounga.net> <5606E464.9040304@zogotounga.net> Message-ID: Does it appear as an internal plugin? Levente On Sat, 26 Sep 2015, St?phane Rollandin wrote: >> MIDIPlugin doesn't seem to be included in 5.0 all-in-one. > > It does appear in Smalltalk listBuiltinModules though... > > Stef > > > > From leves at elte.hu Sat Sep 26 19:05:36 2015 From: leves at elte.hu (Levente Uzonyi) Date: Sat Sep 26 19:05:40 2015 Subject: [squeak-dev] The Trunk: Collections-eem.656.mcz In-Reply-To: <15118612-5AC3-45DB-8107-3FAF06C37994@gmail.com> References: <23324AC9-8D7E-4AF2-9CB5-41CE32345FE1@gmail.com> <15118612-5AC3-45DB-8107-3FAF06C37994@gmail.com> Message-ID: On Sat, 26 Sep 2015, Eliot Miranda wrote: > >> On Sep 26, 2015, at 11:30 AM, Eliot Miranda wrote: >> >> Hi Levente, >> >>> On Sep 26, 2015, at 11:03 AM, Levente Uzonyi wrote: >>> >>> Implementing #at:ifPresent:ifAbsentPut: without reusing #at:ifAbsent: and #at:ifAbsentPut: implies that it must be defined in some of its subclasses too to make it work. >>> This is the reason why #at:ifAbsentPut: and #at:ifPresent:ifAbsent: reuse the low-level methods, sacrificing performance. >> >> I understand. But a) using a single scanFor: saves half the search work in the ifAbsentPut: case and b) no extra effort is required if the subclass overrides scanFor: which is the real low level method. So I'm happy with my decision. I understand. :) IIRC it was Bert who was against changing #at:ifAbsentPut: a few years ago, because EToys has some subclasses of Dictionary, which would have stopped working if the implementation had changed. I don't think it's reasonable to subclass Dictionary, I mean the subclasses of Dictionary I've seen in external packages turned out to be unnecessary, so maybe we should reconsider this for the other two selectors as well. Mainly because they are used more widely than your new method. Levente > > > And I'll take a look at subclasses soon. > >> >>> Levente >> >> _,,,^..^,,,_ (phone) >> >>> >>>> On Fri, 25 Sep 2015, commits@source.squeak.org wrote: >>>> >>>> Eliot Miranda uploaded a new version of Collections to project The Trunk: >>>> http://source.squeak.org/trunk/Collections-eem.656.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: Collections-eem.656 >>>> Author: eem >>>> Time: 25 September 2015, 11:36:48.911 am >>>> UUID: 50ec1b3e-c058-4167-889e-836e994b500b >>>> Ancestors: Collections-ul.655 >>>> >>>> Add Dictionary>>at:ifPresent:ifAbsentPut:. >>>> Move Dictionary>>fasterKeys & keyForIdentity: to 50Deprecated >>>> >>>> =============== Diff against Collections-ul.655 =============== >>>> >>>> Item was added: >>>> + ----- Method: Dictionary>>at:ifPresent:ifAbsentPut: (in category 'accessing') ----- >>>> + at: key ifPresent: oneArgBlock ifAbsentPut: absentBlock >>>> + "Lookup the given key in the receiver. If it is present, answer the value of >>>> + evaluating oneArgBlock with the value associated with the key. Otherwise >>>> + add the value of absentBlock under the key, and answer that value." >>>> + >>>> + | index value | >>>> + index := self scanFor: key. >>>> + (array at: index) ifNotNil: >>>> + [:element| >>>> + ^oneArgBlock value: element value]. >>>> + value := absentBlock value. >>>> + self atNewIndex: index put: (Association key: key value: value). >>>> + ^value! >>>> >>>> Item was removed: >>>> - ----- Method: Dictionary>>fasterKeys (in category 'accessing') ----- >>>> - fasterKeys >>>> - "Contrary to old version of #keys, this method returned an Array rather than a Set. >>>> - This was faster because no lookup: was performed. >>>> - But now, #keys also return an Array, so don't use #fasterKeys anymore." >>>> - >>>> - self deprecated: 'use #keys'. >>>> - >>>> - ^self keys. >>>> - ! >>>> >>>> Item was removed: >>>> - ----- Method: Dictionary>>keyForIdentity: (in category 'accessing') ----- >>>> - keyForIdentity: anObject >>>> - "If anObject is one of the values of the receive, return its key, else return nil. Contrast #keyAtValue: in which there is only an equality check, here there is an identity check" >>>> - >>>> - self deprecated: 'Use #keyAtIdentityValue:ifAbsent:'. >>>> - ^self keyAtIdentityValue: anObject ifAbsent: nil! >>> > > From lecteur at zogotounga.net Sat Sep 26 19:15:12 2015 From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=) Date: Sat Sep 26 19:15:13 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: References: <5606C986.7080401@zogotounga.net> <5606E464.9040304@zogotounga.net> Message-ID: <5606EEC0.7010308@zogotounga.net> > Does it appear as an internal plugin? How can I test this ? Stef From leves at elte.hu Sat Sep 26 20:13:31 2015 From: leves at elte.hu (Levente Uzonyi) Date: Sat Sep 26 20:13:33 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: <5606EEC0.7010308@zogotounga.net> References: <5606C986.7080401@zogotounga.net> <5606E464.9040304@zogotounga.net> <5606EEC0.7010308@zogotounga.net> Message-ID: In the list returned by [Smalltalk listLoadedModules], if the entry ends with (i), then it's internal, otherwise it's external. Levente On Sat, 26 Sep 2015, St?phane Rollandin wrote: >> Does it appear as an internal plugin? > > How can I test this ? > > Stef > > > From lecteur at zogotounga.net Sat Sep 26 20:15:15 2015 From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=) Date: Sat Sep 26 20:15:15 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: References: <5606C986.7080401@zogotounga.net> <5606E464.9040304@zogotounga.net> <5606EEC0.7010308@zogotounga.net> Message-ID: <5606FCD3.9080907@zogotounga.net> > In the list returned by [Smalltalk listLoadedModules], if the entry ends > with (i), then it's internal, otherwise it's external. Ah, ok. It's marked as internal then. Stef From bert at freudenbergs.de Sun Sep 27 14:34:33 2015 From: bert at freudenbergs.de (Bert Freudenberg) Date: Sun Sep 27 14:34:36 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: <5606C986.7080401@zogotounga.net> References: <5606C986.7080401@zogotounga.net> Message-ID: <0CBA6835-E1E3-401E-8208-C08B6BEE9B9D@freudenbergs.de> > On 26.09.2015, at 18:36, St?phane Rollandin wrote: > > Hello, > > Testing the 5.0 all-in-one from squeak.org in a Mint 17.2 running in VirtualBox (Windows 8.1 host), I see that > > SimpleMIDIPort midiIsSupported > > returns false with the linux VM, and true with the Windows VM (run though Wine). > > So it seems to me that the linux MIDIPlugin is broken (or am I missing something ?) This depends on which sound driver you?re running with. IIRC only Squeak?s ALSA module supports MIDI. - Bert - -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4115 bytes Desc: not available Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150927/5cf8d462/smime.bin From leves at elte.hu Sun Sep 27 16:05:57 2015 From: leves at elte.hu (Levente Uzonyi) Date: Sun Sep 27 16:06:02 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: <0CBA6835-E1E3-401E-8208-C08B6BEE9B9D@freudenbergs.de> References: <5606C986.7080401@zogotounga.net> <0CBA6835-E1E3-401E-8208-C08B6BEE9B9D@freudenbergs.de> Message-ID: On Sun, 27 Sep 2015, Bert Freudenberg wrote: > >> On 26.09.2015, at 18:36, St?phane Rollandin wrote: >> >> Hello, >> >> Testing the 5.0 all-in-one from squeak.org in a Mint 17.2 running in VirtualBox (Windows 8.1 host), I see that >> >> SimpleMIDIPort midiIsSupported >> >> returns false with the linux VM, and true with the Windows VM (run though Wine). >> >> So it seems to me that the linux MIDIPlugin is broken (or am I missing something ?) > > This depends on which sound driver you?re running with. IIRC only Squeak?s ALSA module supports MIDI. I guess Mint uses Pulseaudio over ALSA. And I know that programs, like Audacity, can grab ALSA for themselves when nothing is accessing Pulseaudio. So I guess that should work. Levente > > - Bert - > > > > From tim at rowledge.org Sun Sep 27 16:26:49 2015 From: tim at rowledge.org (tim Rowledge) Date: Sun Sep 27 16:26:53 2015 Subject: [squeak-dev] No MIDI ports found on Linux In-Reply-To: <0CBA6835-E1E3-401E-8208-C08B6BEE9B9D@freudenbergs.de> References: <5606C986.7080401@zogotounga.net> <0CBA6835-E1E3-401E-8208-C08B6BEE9B9D@freudenbergs.de> Message-ID: <061D7431-3373-41C3-8126-2822F516DE55@rowledge.org> > On 27-09-2015, at 7:34 AM, Bert Freudenberg wrote: > This depends on which sound driver you?re running with. IIRC only Squeak?s ALSA module supports MIDI. And we need to remember that ALSA needs fixing to deal with interrupts correctly; on Pi it is a major nuisance and I hope we finally got the fixed version into the new Raspbian release coming out in the next few days. Eliot can tell about the ?fun? they had sorting it out at Qwaq. We don?t seem to be able to get midi general instrument sounds either. The mess that *nix seems to have built around sound is amazing to me. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The enema of my enemy is my friend From Marcel.Taeumel at hpi.de Mon Sep 28 09:45:50 2015 From: Marcel.Taeumel at hpi.de (marcel.taeumel) Date: Mon Sep 28 09:54:41 2015 Subject: [squeak-dev] Re: The Trunk: 50Deprecated-eem.1.mcz In-Reply-To: References: <1443267892398-4852077.post@n4.nabble.com> <44C5E6AA-B286-4F05-A71D-DC3858B85915@gmail.com> Message-ID: <1443433550284-4852270.post@n4.nabble.com> Exactly. :) Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-50Deprecated-eem-1-mcz-tp4852032p4852270.html Sent from the Squeak - Dev mailing list archive at Nabble.com. From craig at netjam.org Mon Sep 28 14:33:03 2015 From: craig at netjam.org (Craig Latta) Date: Mon Sep 28 14:33:15 2015 Subject: [squeak-dev] any advice for debugging crashing Alien FFI callbacks? Message-ID: Hi-- I've got basic FFI connectivity going between Squeak 5 and a C library I want to use, via Alien. Callouts seem to work, and some callbacks. Other callbacks crash, though. I know which callback isn't successfully called, but I don't have the library source, so I'm not entirely sure what it's trying to do at that point. I'm on Mac OS 10.11. I attached lldb before the crash and am staring at the library's disassembled instructions. Does anyone have any advice for how to debug? thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) From eliot.miranda at gmail.com Mon Sep 28 15:07:38 2015 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Mon Sep 28 15:07:26 2015 Subject: [squeak-dev] any advice for debugging crashing Alien FFI callbacks? In-Reply-To: References: Message-ID: <63CF33AC-A733-4878-9D42-372EBCEAB3D3@gmail.com> Hi Craig, the four key questions I can think of are a) what is the signature of the callback? b) where does the crash occur (which instruction in which function) and why? c) what is the state of the stack and register arguments when the callback enters thunkEntry (which is where all callbacks come in) d) (if things get that far) what is the state of the system after the longjmp back into thunkEntry as the system attempts to return from the callback _,,,^..^,,,_ (phone) > On Sep 28, 2015, at 7:33 AM, Craig Latta wrote: > > > Hi-- > > I've got basic FFI connectivity going between Squeak 5 and a C > library I want to use, via Alien. Callouts seem to work, and some > callbacks. Other callbacks crash, though. I know which callback isn't > successfully called, but I don't have the library source, so I'm not > entirely sure what it's trying to do at that point. I'm on Mac OS 10.11. > I attached lldb before the crash and am staring at the library's > disassembled instructions. > > Does anyone have any advice for how to debug? > > > thanks, > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > From commits at source.squeak.org Wed Sep 30 12:09:59 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 30 12:10:02 2015 Subject: [squeak-dev] The Trunk: Morphic-mt.1007.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1007.mcz ==================== Summary ==================== Name: Morphic-mt.1007 Author: mt Time: 30 September 2015, 2:09:27.644 pm UUID: c0bc7335-d587-8f4a-b835-e6a3839fbf6a Ancestors: Morphic-mt.1006 Fixes redraw issues when changing font and/or label in pluggable button morphs. =============== Diff against Morphic-mt.1006 =============== Item was changed: ----- Method: PluggableButtonMorph>>font: (in category 'accessing') ----- font: aFont font = aFont ifTrue: [^ self]. font := aFont. + + self updateMinimumExtent. + self changed.! - self updateMinimumExtent.! Item was changed: ----- Method: PluggableButtonMorph>>label: (in category 'accessing') ----- label: aStringOrTextOrMorph label = aStringOrTextOrMorph ifTrue: [^ self]. label := aStringOrTextOrMorph isText ifTrue: [aStringOrTextOrMorph asMorph] ifFalse: [aStringOrTextOrMorph]. + self updateMinimumExtent. + self changed.! - self updateMinimumExtent.! From tim at rowledge.org Wed Sep 30 16:57:00 2015 From: tim at rowledge.org (tim Rowledge) Date: Wed Sep 30 16:57:03 2015 Subject: [squeak-dev] =?utf-8?q?The_Pi_Podcast_=234_=E2=80=93_Tim_Rowledge?= =?utf-8?b?IChTY3JhdGNoKSB8?= Message-ID: A bit of getting the word out - > http://thepipodcast.com/the-pi-podcast-4-tim-rowledge-scratch/ tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: AII: Add Insult to Injury From commits at source.squeak.org Wed Sep 30 21:55:02 2015 From: commits at source.squeak.org (commits@source.squeak.org) Date: Wed Sep 30 21:55:04 2015 Subject: [squeak-dev] Daily Commit Log Message-ID: <20150930215502.10832.qmail@box4.squeakfoundation.org> Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2015-September/008979.html Name: Morphic-mt.1007 Ancestors: Morphic-mt.1006 Fixes redraw issues when changing font and/or label in pluggable button morphs. =============================================