I haven't had the chance to check recently (and am not sure when I will be able to), but when wrapping libav/ffmpeg, I found that passing mutable objects (of types) to C-code produced a segmentation fault, but that passing immutables worked (with no other changes). I believe that was after Jameson's changes, and had just assumed that the layout wasn't compatible still.
Anyway, when I get the chance, I'll try again, and create an issue if it still has problems. Kevin On Mon, Feb 9, 2015 at 10:53 AM, Tobias Knopp <[email protected]> wrote: > No I think its still only pointers to the type objects that are stored in > the array. But note that what Jameson wrote still holds. In ccall you can > assume that the type has C struct layout. No need to go for an immutable > there. > > Tobi > > Am Montag, 9. Februar 2015 19:00:15 UTC+1 schrieb Simon Danisch: > >> But arrays of* type* are still not densely packed, right? >> I tried it with the newest master and it doesn't look like it. >> >> >> Am Sonntag, 8. Februar 2015 21:35:20 UTC+1 schrieb [email protected]: >>> >>> I would like to request the following language feature: a function or >>> macro to modify a field of an immutable inside a container. Consider: >>> >>> immutable T >>> fielda::Int >>> fieldb::Int >>> fieldc::Int >>> end >>> >>> function modify_fieldc!(x::Array{T,1}, sub::Int, newc::Int) >>> x[sub] = T(x[sub].fielda, x[sub].fieldb, newc) >>> end >>> >>> This function modifies one field of an immutable object that sits inside >>> a container. The above construct, namely: >>> x[sub] = T(x[sub].field1, x[sub].field2, ... , newval, ... >>> x[sub].fieldn) >>> occurs rather frequently in my code. It is not very readable and is >>> also fragile in the case that I modify my code and put more fields in T >>> later. It would be much nicer if there were a universal function like this: >>> modifyField!(x, sub, fieldc, newc) >>> >>> Note that I declared T to be 'immutable' rather than 'type' for >>> performance reasons-- I prefer the data in the array x to be packed in >>> memory rather than accessed with pointers. If T were a 'type' then >>> obviously the problem would go away. >>> >>> Maybe it is already possible to write a function or macro for this >>> purpose in the existing language? >>> >>> Thanks, >>> Steve Vavasis >>> >>>
