- Pharo-dev - lists.pharo.org

[update 6.0] #60522
by Marcus Denker Nov. 29, 2017

Nov. 29, 2017

60522 ----- 20339 Pharo6 test runs for CI fail with strange error in ClassRenameFixTest>>#testRenameClassUsingClass https://pharo.fogbugz.com/f/cases/20339 20279 AST-Core ASTCache not cleaned https://pharo.fogbugz.com/f/cases/20279

1 0

[Pharo 7.0-dev] Build #349: -20785/Fix-the-names-of-uploaded-bootstrap-zip-files
by ci-pharo-ci-jenkins2＠inria.fr Nov. 29, 2017

Nov. 29, 2017

There is a new Pharo build available! The status of the build #349 was: SUCCESS. The Pull Request #563 was integrated: "-20785/Fix-the-names-of-uploaded-bootstrap-zip-files" Pull request url: https://github.com/pharo-project/pharo/pull/563 Issue Url: https://pharo.fogbugz.com/f/cases/20785 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #348: 20783-upload-temporary-building-files-into-a-separate-repository
by ci-pharo-ci-jenkins2＠inria.fr Nov. 29, 2017

Nov. 29, 2017

There is a new Pharo build available! The status of the build #348 was: SUCCESS. The Pull Request #562 was integrated: "20783-upload-temporary-building-files-into-a-separate-repository" Pull request url: https://github.com/pharo-project/pharo/pull/562 Issue Url: https://pharo.fogbugz.com/f/cases/20783 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #347: 20777-Fix-instVarAt-instVarAt-put-comment
by ci-pharo-ci-jenkins2＠inria.fr Nov. 29, 2017

Nov. 29, 2017

There is a new Pharo build available! The status of the build #347 was: SUCCESS. The Pull Request #559 was integrated: "20777-Fix-instVarAt-instVarAt-put-comment" Pull request url: https://github.com/pharo-project/pharo/pull/559 Issue Url: https://pharo.fogbugz.com/f/cases/20777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

VoxelSpace
by Pavel Krivanek Nov. 29, 2017

Nov. 29, 2017

Hi, I tried to port and optimize the extremely simple VoxelSpace engine into Pharo. https://github.com/pavel-krivanek/VoxelSpace How to load Metacello new baseline: 'VoxelSpace'; repository: 'github://pavel-krivanek/VoxelSpace/src'; load. How to run Copy maps into the image directory and then evaluate: VoxelSpaceMorph new openInWindow. [image: VloÅ¾enÃ½ obrÃ¡zek 2] No external library is required. If you have some next ideas how to improve the rendering performace with the same image quality, please let me know. Cheers, -- Pavel

3 4

(no subject)
by Ben Coman Nov. 29, 2017

Nov. 29, 2017

A minor thing, but a fix is probably easy... I have... FFIExternalStructure subclass: #CXSourceLocation instanceVariableNames: '' classVariableNames: 'VoidPointer2' package: 'Libclang' initialize "self initialize" VoidPointer2 := FFITypeArray ofType: 'void*' size: 2. fieldsDesc "self rebuildFieldAccessors" ^#( VoidPointer2 ptr_data; uint int_data; ) Now when I debug into "self rebuildFieldAccessors" into #compileFields:withAccessors: through "fieldSpec fieldsAndTypesDo: [ :fieldName :type | " the [Variables] tab shows... type "FFITypeArrayType(a subclass of FFITypeArray)" and my perception is that this is wrong since FFITypeArrayType is not a subclass FFITypeArray. Intuitively I'm reading the text in the round brackets as a commentary on FFITypeArrayType. But debugging into "type printString" bring me to FFITypeArrayType(FFIExternalReferenceType) >> printOn: aStream aStream << self className << '(' << objectClass name << ')' where objectClass is an instance variable, so the commentary is about composition rather than inheritance. Now I properly understand the truth, I still have trouble with perceiving the printString the wrong way, so I'd like to add a visual cue that this is composition. Do we have such a standard convention? Options... 1. Square brackets a. FFITypeArrayType[a subclass of FFITypeArray] b. FFITypeArrayType([a subclass of FFITypeArray]) 2. Curly brackets a. FFITypeArrayType{a subclass of FFITypeArray} b. FFITypeArrayType({a subclass of FFITypeArray}) 3. Array-ish a. FFITypeArrayType#(a subclass of FFITypeArray) b. FFITypeArrayType(#(a subclass of FFITypeArray)) 4. Text a. FFITypeArrayType(holding a subclass of FFITypeArray) I'm tending towards [2a] or [2b] since two brackets together seem more distinct. It may be easy to overlook a difference in a single bracket, and also it feels more like holding something inside the object. cheers -ben P.S. Regarding the existing Libclang bindings. I'm not trying to compete but more along the line... "its worthwhile reinventing the wheel when you want to learn more about how a wheel works." I'll switch over to existing bindings in a while.

1 0

[Pharo 7.0-dev] Build #346: 20777-Fix-instVarAt-instVarAt-put-comment
by ci-pharo-ci-jenkins2＠inria.fr Nov. 28, 2017

Nov. 28, 2017

There is a new Pharo build available! The status of the build #346 was: FAILURE. The Pull Request #559 was integrated: "20777-Fix-instVarAt-instVarAt-put-comment" Pull request url: https://github.com/pharo-project/pharo/pull/559 Issue Url: https://pharo.fogbugz.com/f/cases/20777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

FFIIntegerTypes inheritance hierarchy
by Ben Coman Nov. 28, 2017

Nov. 28, 2017

I'm looking through the keyhole at something new to me, so maybe this is off base, but looking at the inheritance hierarchy... FFIIntegerType FFIUint16 FFIUint16 FFIUInt32 FFIInt32 FFIUint64 FFIInt64 FFIUint8 FFIInt8 I'm curious... why the all the Ints inherit from the UInts? Each of those classes has the same two methods #basicHandle:at: and #basicHandle:at:put. So the Int subclasses fully override the superclass methods. So there in no inherited behaviour on the instance side. On the class side, I see #externalTypeSize is inherited by the Ints, but evaluating... FFIIntegerType allSubclasses collect: [ :class | class externalType byteSize -> class externalTypeSize ] produces... 4->4 2->2 4->4 8->8 1->1 2->2 4->4 8->8 1->1 So naively the extra inheritance level seems unnecessary and perhaps having... FFIIntegerType class >> externalTypeSize ^ self externalType byteSize would allow the hierarchy to be flattened. Maybe not a great benefit, except to avoid the next person wondering the same thing :P Also, it is surprising that that FFUInt64 uses #signedLongLongAt: rather than #unsignedLongLongAt: . This seems on-purpose rather than accidental since its inherited by FFIInt64, so it seems there is something interesting to learn here that would benefit a method comment. cheers -ben

2 2

Would it be possible to also launch templates in PharoLauncher?
by Mariano Martinez Peck Nov. 28, 2017

Nov. 28, 2017

Hi guys, Thank you Christophe for continue pushing this useful tool! One small request which might be easy to do... Quite frequently I want to do something and re-save an image I have previosuly saved as a custom template (under Local root tree). Right now what I have to do so: 1) Make a new image from that template 2) remove template 2) do the thing and save the opened image. 3) go back to laucher and save that image as a new template (with the same name of the one I deleted) 4) delete the created image All that would be simplified if I could also launch my local templates. Is there any reason why is that not allowed? (at least for Local tree). Thanks in advance, -- Mariano http://marianopeck.wordpress.com

3 4

[Pharo 7.0-dev] Build #345: 20777-Fix-instVarAt-instVarAt-put-comment
by ci-pharo-ci-jenkins2＠inria.fr Nov. 28, 2017

Nov. 28, 2017

There is a new Pharo build available! The status of the build #345 was: FAILURE. The Pull Request #559 was integrated: "20777-Fix-instVarAt-instVarAt-put-comment" Pull request url: https://github.com/pharo-project/pharo/pull/559 Issue Url: https://pharo.fogbugz.com/f/cases/20777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0