Squeak-dev April 2018

squeak-dev@lists.squeakfoundation.org

47 participants
159 discussions

The Trunk: MorphicExtras-kfr.229.mcz
by commits＠source.squeak.org 15 Apr '18

15 Apr '18

Karl Ramberg uploaded a new version of MorphicExtras to project The Trunk: http://source.squeak.org/trunk/MorphicExtras-kfr.229.mcz ==================== Summary ==================== Name: MorphicExtras-kfr.229 Author: kfr Time: 15 April 2018, 2:12:19.020131 pm UUID: 499ecdd9-d87e-dc46-9f0b-b262d237f5a2 Ancestors: MorphicExtras-kfr.228 Fix for bouncing atoms bounds, added menu item to make it bounce without infection, fix spelling in menu. =============== Diff against MorphicExtras-kfr.228 =============== Item was changed: ----- Method: BouncingAtomsMorph>>addCustomMenuItems:hand: (in category 'menu') ----- addCustomMenuItems: aCustomMenu hand: aHandMorph super addCustomMenuItems: aCustomMenu hand: aHandMorph. + aCustomMenu add: 'start bouncing' translated action: #startStepping. + aCustomMenu add: 'start infection' translated action: #startInfection. - aCustomMenu add: 'startInfection' translated action: #startInfection. aCustomMenu add: 'set atom count' translated action: #setAtomCount. aCustomMenu add: 'show infection history' translated action: #showInfectionHistory:. ! Item was added: + ----- Method: BouncingAtomsMorph>>justDroppedInto:event: (in category 'initialization') ----- + justDroppedInto: aWorld event: evt + + damageReported := false. + self changed + + !

1 0

The Trunk: MorphicExtras-kfr.228.mcz
by commits＠source.squeak.org 15 Apr '18

15 Apr '18

Karl Ramberg uploaded a new version of MorphicExtras to project The Trunk: http://source.squeak.org/trunk/MorphicExtras-kfr.228.mcz ==================== Summary ==================== Name: MorphicExtras-kfr.228 Author: kfr Time: 15 April 2018, 1:56:55.685131 pm UUID: c7fa3c36-9397-174f-b075-b4eaf3705abc Ancestors: MorphicExtras-kfr.227 Reverting MorphicExtras-kfr.227 =============== Diff against MorphicExtras-kfr.227 =============== Item was added: + ----- Method: BouncingAtomsMorph>>intoWorld: (in category 'initialization') ----- + intoWorld: newOwner + "Make sure report damage at least once" + damageReported := false. + super intoWorld: newOwner. + ! Item was removed: - ----- Method: BouncingAtomsMorph>>justDroppedInto:event: (in category 'initialization') ----- - justDroppedInto: newOwner event: evt - self startStepping - !

1 0

The Trunk: MorphicExtras-kfr.227.mcz
by commits＠source.squeak.org 15 Apr '18

15 Apr '18

Karl Ramberg uploaded a new version of MorphicExtras to project The Trunk: http://source.squeak.org/trunk/MorphicExtras-kfr.227.mcz ==================== Summary ==================== Name: MorphicExtras-kfr.227 Author: kfr Time: 15 April 2018, 12:47:19.317391 pm UUID: 9dd2eaf1-6002-4f42-99c4-65f00426c358 Ancestors: MorphicExtras-kfr.226 BouncingAtomsMorph was not updating drawing bounds once it stopped stepping and got moved =============== Diff against MorphicExtras-kfr.226 =============== Item was removed: - ----- Method: BouncingAtomsMorph>>intoWorld: (in category 'initialization') ----- - intoWorld: aWorld - "Make sure report damage at least once" - damageReported := false. - super intoWorld: aWorld.! Item was added: + ----- Method: BouncingAtomsMorph>>justDroppedInto:event: (in category 'initialization') ----- + justDroppedInto: newOwner event: evt + self startStepping + !

3 2

The Trunk: MorphicExtras-kfr.226.mcz
by commits＠source.squeak.org 14 Apr '18

14 Apr '18

Karl Ramberg uploaded a new version of MorphicExtras to project The Trunk: http://source.squeak.org/trunk/MorphicExtras-kfr.226.mcz ==================== Summary ==================== Name: MorphicExtras-kfr.226 Author: kfr Time: 14 April 2018, 3:54:05.537419 pm UUID: 013296dd-551b-154d-8583-5fa40bf21e36 Ancestors: MorphicExtras-kfr.225 Paint was missing from the Graphics category in Object tool =============== Diff against MorphicExtras-kfr.225 =============== Item was changed: ----- Method: PaintInvokingMorph class>>descriptionForPartsBin (in category 'parts bin') ----- descriptionForPartsBin ^ self partName: 'Paint' translatedNoop + categories: #('Graphics' translatedNoop) - categories: #() documentation: 'Drop this icon to start painting a new object.' translatedNoop!

1 0

The Trunk: MorphicExtras-kfr.226.mcz
by commits＠source.squeak.org 14 Apr '18

14 Apr '18

1 0

The Trunk: Collections-cmm.785.mcz
by commits＠source.squeak.org 14 Apr '18

14 Apr '18

Chris Muller uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-cmm.785.mcz ==================== Summary ==================== Name: Collections-cmm.785 Author: cmm Time: 30 March 2018, 5:57:37.727038 pm UUID: 37e9870a-5379-4185-8538-fada710dad5d Ancestors: Collections-eem.784 Add #at:ifPresent:ifAbsent: for API compatibility with other kinds of directly-accessible Collections. =============== Diff against Collections-eem.784 =============== Item was added: + ----- Method: SequenceableCollection>>at:ifPresent:ifAbsent: (in category 'accessing') ----- + at: index ifPresent: elementBlock ifAbsent: exceptionBlock + "Answer the value of elementBlock on the element at position index. If I do not contain an element at index, answer the result of evaluating exceptionBlock." + ^ elementBlock value: + (self + at: index + ifAbsent: [ ^ exceptionBlock value ])!

3 5

Alignment of FFI ExternalStructure fields
by Nicolas Cellier 13 Apr '18

13 Apr '18

So the current algorithm in #defineFields: and compileFields: is producing compact structures layout with all fields aligned on 1 byte. It does not correspond to any platform behavior except when using special pragmas or compiler options. The current workaround is to force a length in 3rd column of spec. https://stackoverflow.com/questions/49782651/how-one-aligns-structure-field… But it's brainfuck: - it depends both on the fields preceding and the fields following - it becomes very hard to support both 32+64 bits #( (x 'char' 2) (y 'short') ) #( (x 'char' 4) "depends on the field following" (y 'long') ) #( (w 'char' 1) (x 'char' 3) "but also on the field preceding" (y 'long') ) I'd like to make our default behavior match that of the current platform - atomic fields of size 1,2,4,8 bytes have alignment = size - pointers also have alignment = pointer size (4 or 8). - nested structures have alignment = max of alignment of their fields Then we can support exotic alignment with a 4th column in spec: #( (x 'char' -1 1) (y 'short' -1 1) ) "compact" The 3rd column -1 or nil would mean "use the default size rather than force a user defined one" Other suggestions?

2 2

Re: [squeak-dev] [Vm-dev] Usability of Squeak FFI for anything serious...
by Eliot Miranda 13 Apr '18

13 Apr '18

Hi Nicolas, On Fri, Apr 13, 2018 at 12:40 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2018-04-13 21:28 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> On Fri, Apr 13, 2018 at 10:59 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> >>> 2018-04-13 17:08 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> Hi Nicolas, >>>> >>>> On Apr 13, 2018, at 7:01 AM, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> So I started to improve the Squeak FFI: >>>> -1) I corrected pointer arithmetic on 64 bits >>>> http://source.squeak.org/FFI/FFI-Kernel-nice.48.diff >>>> -2) I prepared the possibility of having automated layout spec updates >>>> http://source.squeak.org/FFI/FFI-Kernel-nice.49.diff >>>> >>>> Note that the FFI plugin by itself did not change. >>>> The next steps should be to provide support for native platform >>>> alignment of fields and unions. >>>> I'll focus on these when i can. >>>> >>>> I shall join you as soon as I am able. Right now I have a pressing >>>> task, but within a few weeks I should be able to help. >>>> >>> >>> Hi Eliot, >>> thanks. >>> I think that I can manage the easiest image side issues, but as soon as >>> a feature will require an evolution of the plugin, your review is >>> mandatory, as well as coordination with Pharo team, Backward compatibility >>> counts and Esteban spent enough time on UFFI, so this will mean either >>> unifying our forces or forking a plugin! >>> >> >> Sounds good. A fork is to be avoided at all costs. I don't see any >> pressure for a fork though because the plugin is essentially defined by the >> platform's ABI and Andreas' design for the type specification language is >> sufficiently general. Am I missing something? (Esteban are you reading?) >> > > With my current understanding, two essential features are missing in the > type compiledSpec: > - multiple indirection pointers (I've got an example of these in HDF5) > What do you mean, 64 vs 32 bit pointers or? > - fixed size arrays in struct members (I've got an example in HDF5 too!) > > For now, we can workaround with > - void * declaration and human crafted pointer handling > - unrolled array members (1 member per array slot!) > I think unrolling might be a good solution. There are relatively few types in a typical FFI interface and even fewer that have fixed size arrays in structs, so adding this would indeed create a few large specs, but in practice not many, whereas introducing support for arrays of types in the specs would add recursion into the marshaling in the plugin, and that could be error prone and slow. Unrolling in the type to spec compiler (and re-rolling in printTypedefOn:) is probably simpler and I suspect would be far more robust. A modification of FFI would be necessary only for enforcing type checking. > I'm not sure where this comes in if we unroll. At least on callout the plugin merely checks that a structure is of the right size, and if specified the right subclass of ExternalStructure. That's still sufficient if we realign instances of ExternalStructure on startup right? > I don't plan anything right now, and I agree that doing so with backward > compatibility is by far preferred. > +1000. > 2018-04-12 23:27 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>>> Hi >>>>> >>>>> There is project TalkFFI <https://github.com/estebanlm/TalkFFI> from >>>>> Ciprian Teodorov. >>>>> >>>>> 2018-04-12 22:50 GMT+02:00 Bert Freudenberg <bert(a)freudenbergs.de>: >>>>> >>>>>> On 12 April 2018 at 22:34, Nicolas Cellier < >>>>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> There are at least two problems: >>>>>>> - documentation (lack of) >>>>>>> - limitations (unions, pointer on pointer on ...) >>>>>>> - automation (I said at least two, not at most) >>>>>>> >>>>>>> For the first problem, I opened the SO issues. Not ideal, but it's a >>>>>>> start. >>>>>>> For the second, I'll see if I can do something... >>>>>>> For the third, I did import some .h header with VW DLLCC, and I'm in >>>>>>> the process of translating to other dialects. >>>>>>> It's easier because Smalltalk syntax is order of magnitudes smaller >>>>>>> than C syntax. >>>>>>> >>>>>> >>>>>> I always thought it should be fairly straightforward to make a FFI >>>>>> bindings generator using SWIG (http://www.swig.org/). >>>>>> >>>>>> SWIG parses C headers and outputs XML. Starting from that XML should >>>>>> be way easier than trying to parse C ourselves. >>>>>> >>>>>> - Bert - >>>>>> >>>>> -- >> _,,,^..^,,,_ >> best, Eliot >> > _,,,^..^,,,_ best, Eliot

1 0

Usability of Squeak FFI for anything serious...
by Nicolas Cellier 13 Apr '18

13 Apr '18

I'm trying to see how hard it is to port my HDF5 work from VW to Squeak. It was not a pleasure in VW, because that already raised some questions despite that there is a somehow detailed DLLCC manual: https://stackoverflow.com/questions/49544642/why-cant-i-pass-an-uninterpret… https://stackoverflow.com/questions/49564024/isnt-pointer-type-checking-dis… But in Squeak, it sounds like hard++: https://stackoverflow.com/questions/49782651/how-one-aligns-structure-field… https://stackoverflow.com/questions/49783126/how-one-defines-a-union-type-i… https://stackoverflow.com/questions/49783443/how-one-defines-a-fixed-size-a… https://stackoverflow.com/questions/49783882/how-one-deals-with-typedefs-in… https://stackoverflow.com/questions/49784253/how-one-deals-with-multiple-po… https://stackoverflow.com/questions/49784522/how-one-supports-both-32-and-6… Either I'm blind, or the very light documentation that I found lacks those details http://wiki.squeak.org/squeak/2426 I think that I could throw a few more questions (dealing with enums...) but I don't want to excede some unknown quota and start irritating a touchy SO moderator ;) I'm afraid that there is no answer but "you're on your own"... I'm open to studying Alien or UnifiedFFI of Pharo. Or I can try and improve FFI. At this stage, my trajectory has already been quite perturbed, and despite my knowledge of rocket science, I can see that I'm not going to put HDF5 on the intended orbit :( Thoughts?

6 12

ExternalPipe atEnd test
by K K Subbu 13 Apr '18

13 Apr '18

Hi, I stumbled upon the following method in OSProcess-Base package: ExternalPipe#atEnd ^writer closed and: [self peek == nil] Shouldn't the test be reversed? In a pipe, the reader's peek buffer could be holding an object while the writer has closed its end. Regards .. Subbu

3 2

← Newer
1
...
8
9
10
11
12
13
14
15
16
Older →

Jump to page: