Re: [julia-users] Really need to change immutables

[J Luis]

and will I not fall in the same case as the *TS* above? That is, when I do 
the unsafe_store will that memory be owned by the C lib (and therefore safe 
to be free by it)?

segunda-feira, 10 de Agosto de 2015 às 21:13:39 UTC+1, Jameson escreveu:
>
> right, you can't mutate it directly, but you can make a new copy with the 
> intended changes, then use unsafe_store to write those changes back into 
> the struct.
>
> On Mon, Aug 10, 2015 at 3:56 PM J Luis > 
> wrote:
>
>> ... amd I am using unsafe_load() 
>>
>>
>> S0 = unsafe_load(unsafe_load(TTABLE.segment,1),1)# 
>> ::GMT.GMT_TEXTSEGMENT  
>> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L860
>>
>> but if I add this line after 
>>
>>  S0.n_rows = 2
>>
>> ERROR: type GMT_TEXTSEGMENT is immutable
>> in GMTJL_Text_init at C:\progs_cygw\GMTdev\GMT.jl\src\gmt_main.jl:861
>>
>>
>>
>> segunda-feira, 10 de Agosto de 2015 às 20:47:27 UTC+1, J Luis escreveu:
>>>
>>>
>>>
>>> segunda-feira, 10 de Agosto de 2015 às 20:15:57 UTC+1, Jameson escreveu:

 My suggestion would be to mirror only the parts of those structs that 
 are part of the public API. Then use unsafe_load / unsafe_store to read / 
 modify / write the intended changes. The API authors were nice to put the 
 public fields at the top so that you can do this (many libraries don't / 
 can't do this). Then the "real" object will always be the Ptr to the one 
 allocated by GMT, and you only have temporary copies of them alive at any 
 time inside Julia.

>>>
>>> But GMT_TEXTSEGMENT is part of the GMT API (hm, have to check why it 
>>> doesn't show up in http://gmt.soest.hawaii.edu/doc/latest/GMT_API.html)
>>>
>>> Sorry, to be concrete, and repeating myself. I need to change n_rows of
>>>
>>> 
>>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
>>>  
>>> Can I do it?
>>>
>>> BTW, I'm a developer of GMT (that's why I could create that backdoor 
>>> function that temporarily saved me on this), although the API was all 
>>> created by P. Wessel.
>>>
>>>  
>>>


 On Mon, Aug 10, 2015 at 2:53 PM J Luis  wrote:

>
>
>> usually, there's is one big toplevel distinction driven by who will 
>> free the memory: if C will be freeing the memory, then you must always 
>> have 
>> the C code also allocating the memory (hopefully the library author 
>> provide 
>> some sort of new / alloc / create function, although sometimes they rely 
>> on 
>> the user calling malloc).
>>
>
> Yes, the GMT_Create_Data (that ccals a C function with the same name) 
> does that.
>
> 
> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L852
>   
> 
>
>>
>> > Is that really impossible and I'm doomed to the path 
>> exemplified with that C GMT_blind_change_struct() function?
>>
>> ideally, C libraries that expect to manage a struct's memory also 
>> provide accessor methods to read any of the structs important fields so 
>> that you can always declare its type as Ptr{Void} in Julia. However, I 
>> realize this is true of many C libraries.
>>
>
>
> The pointers are ok, my real problem are those 'scalars' like the 
> n_rows in
>
> 
> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
>
> I only know the number of rows after having read the data and than the 
> immut is already created
>  
>
>>
>>
>> On Mon, Aug 10, 2015 at 9:58 AM J Luis  wrote:
>>
>>>
>>>
>>> segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah 
>>> escreveu:

 https://github.com/JuliaLang/julia/pull/12113

>>>
>>> So there is hope. Thanks
>>>
>>>  
>>>


 On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:

> Hi,
>
> Let me try to explain my need to fight with immutables. I made 
> another round to my GMT wrapper (which is hopefully almost ready) and 
> struggled again with the immutables. The point is that GMT API 
> structs are 
> deeply nested and need to be mirrored with immutables (otherwise 
> Julia 
> crashes). Namely this one 
>
> 
> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445
>
> so I first went with the advised solution of creating and filling 
> the type is julia and replace the pointees of the immutable type, 
> which I 
> did here (see the commented code):
>
> 
> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874
>
> but the problem now is that *TS* is a memory owned by Julia and 
> tha

Re: [julia-users] Really need to change immutables

[Jameson Nash]

right, you can't mutate it directly, but you can make a new copy with the
intended changes, then use unsafe_store to write those changes back into
the struct.

On Mon, Aug 10, 2015 at 3:56 PM J Luis  wrote:

> ... amd I am using unsafe_load()
>
>
> S0 = unsafe_load(unsafe_load(TTABLE.segment,1),1)#
> ::GMT.GMT_TEXTSEGMENT
> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L860
>
> but if I add this line after
>
>  S0.n_rows = 2
>
> ERROR: type GMT_TEXTSEGMENT is immutable
> in GMTJL_Text_init at C:\progs_cygw\GMTdev\GMT.jl\src\gmt_main.jl:861
>
>
>
> segunda-feira, 10 de Agosto de 2015 às 20:47:27 UTC+1, J Luis escreveu:
>>
>>
>>
>> segunda-feira, 10 de Agosto de 2015 às 20:15:57 UTC+1, Jameson escreveu:
>>>
>>> My suggestion would be to mirror only the parts of those structs that
>>> are part of the public API. Then use unsafe_load / unsafe_store to read /
>>> modify / write the intended changes. The API authors were nice to put the
>>> public fields at the top so that you can do this (many libraries don't /
>>> can't do this). Then the "real" object will always be the Ptr to the one
>>> allocated by GMT, and you only have temporary copies of them alive at any
>>> time inside Julia.
>>>
>>
>> But GMT_TEXTSEGMENT is part of the GMT API (hm, have to check why it
>> doesn't show up in http://gmt.soest.hawaii.edu/doc/latest/GMT_API.html)
>>
>> Sorry, to be concrete, and repeating myself. I need to change n_rows of
>>
>>
>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
>>
>> Can I do it?
>>
>> BTW, I'm a developer of GMT (that's why I could create that backdoor
>> function that temporarily saved me on this), although the API was all
>> created by P. Wessel.
>>
>>
>>
>>>
>>>
>>> On Mon, Aug 10, 2015 at 2:53 PM J Luis  wrote:
>>>


> usually, there's is one big toplevel distinction driven by who will
> free the memory: if C will be freeing the memory, then you must always 
> have
> the C code also allocating the memory (hopefully the library author 
> provide
> some sort of new / alloc / create function, although sometimes they rely 
> on
> the user calling malloc).
>

 Yes, the GMT_Create_Data (that ccals a C function with the same name)
 does that.

 https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L852
   

>
> > Is that really impossible and I'm doomed to the path exemplified
> with that C GMT_blind_change_struct() function?
>
> ideally, C libraries that expect to manage a struct's memory also
> provide accessor methods to read any of the structs important fields so
> that you can always declare its type as Ptr{Void} in Julia. However, I
> realize this is true of many C libraries.
>


 The pointers are ok, my real problem are those 'scalars' like the
 n_rows in


 http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517

 I only know the number of rows after having read the data and than the
 immut is already created


>
>
> On Mon, Aug 10, 2015 at 9:58 AM J Luis  wrote:
>
>>
>>
>> segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah
>> escreveu:
>>>
>>> https://github.com/JuliaLang/julia/pull/12113
>>>
>>
>> So there is hope. Thanks
>>
>>
>>
>>>
>>>
>>> On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:
>>>
 Hi,

 Let me try to explain my need to fight with immutables. I made
 another round to my GMT wrapper (which is hopefully almost ready) and
 struggled again with the immutables. The point is that GMT API structs 
 are
 deeply nested and need to be mirrored with immutables (otherwise Julia
 crashes). Namely this one


 https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445

 so I first went with the advised solution of creating and filling
 the type is julia and replace the pointees of the immutable type, 
 which I
 did here (see the commented code):


 https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874

 but the problem now is that *TS* is a memory owned by Julia and
 that will be fatal when GMT's own memory cleaning functions try to 
 free it
 and  -> Julia crashes.
 So if use a pure Julia solution I've no choice but to let memory
 leeks and other house keeping to be done. Not good at all.

 For the time being I ended up with this ugly C  trick of sending to
 C the job of changing some members (non-pointers) that need absolutely 
 to
 changed after the type has been created
>>>

Re: [julia-users] Really need to change immutables

[J Luis]

... amd I am using unsafe_load() 


S0 = unsafe_load(unsafe_load(TTABLE.segment,1),1)# 
::GMT.GMT_TEXTSEGMENT  
https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L860

but if I add this line after 
   
 S0.n_rows = 2

ERROR: type GMT_TEXTSEGMENT is immutable
in GMTJL_Text_init at C:\progs_cygw\GMTdev\GMT.jl\src\gmt_main.jl:861


segunda-feira, 10 de Agosto de 2015 às 20:47:27 UTC+1, J Luis escreveu:
>
>
>
> segunda-feira, 10 de Agosto de 2015 às 20:15:57 UTC+1, Jameson escreveu:
>>
>> My suggestion would be to mirror only the parts of those structs that are 
>> part of the public API. Then use unsafe_load / unsafe_store to read / 
>> modify / write the intended changes. The API authors were nice to put the 
>> public fields at the top so that you can do this (many libraries don't / 
>> can't do this). Then the "real" object will always be the Ptr to the one 
>> allocated by GMT, and you only have temporary copies of them alive at any 
>> time inside Julia.
>>
>
> But GMT_TEXTSEGMENT is part of the GMT API (hm, have to check why it 
> doesn't show up in http://gmt.soest.hawaii.edu/doc/latest/GMT_API.html)
>
> Sorry, to be concrete, and repeating myself. I need to change n_rows of
>
> 
> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
>  
> Can I do it?
>
> BTW, I'm a developer of GMT (that's why I could create that backdoor 
> function that temporarily saved me on this), although the API was all 
> created by P. Wessel.
>
>  
>
>>
>>
>> On Mon, Aug 10, 2015 at 2:53 PM J Luis  wrote:
>>
>>>
>>>
 usually, there's is one big toplevel distinction driven by who will 
 free the memory: if C will be freeing the memory, then you must always 
 have 
 the C code also allocating the memory (hopefully the library author 
 provide 
 some sort of new / alloc / create function, although sometimes they rely 
 on 
 the user calling malloc).

>>>
>>> Yes, the GMT_Create_Data (that ccals a C function with the same name) 
>>> does that.
>>>
>>> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L852
>>>   
>>>

 > Is that really impossible and I'm doomed to the path exemplified 
 with that C GMT_blind_change_struct() function?

 ideally, C libraries that expect to manage a struct's memory also 
 provide accessor methods to read any of the structs important fields so 
 that you can always declare its type as Ptr{Void} in Julia. However, I 
 realize this is true of many C libraries.

>>>
>>>
>>> The pointers are ok, my real problem are those 'scalars' like the n_rows 
>>> in
>>>
>>> 
>>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
>>>
>>> I only know the number of rows after having read the data and than the 
>>> immut is already created
>>>  
>>>


 On Mon, Aug 10, 2015 at 9:58 AM J Luis  wrote:

>
>
> segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah escreveu:
>>
>> https://github.com/JuliaLang/julia/pull/12113
>>
>
> So there is hope. Thanks
>
>  
>
>>
>>
>> On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:
>>
>>> Hi,
>>>
>>> Let me try to explain my need to fight with immutables. I made 
>>> another round to my GMT wrapper (which is hopefully almost ready) and 
>>> struggled again with the immutables. The point is that GMT API structs 
>>> are 
>>> deeply nested and need to be mirrored with immutables (otherwise Julia 
>>> crashes). Namely this one 
>>>
>>> 
>>> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445
>>>
>>> so I first went with the advised solution of creating and filling 
>>> the type is julia and replace the pointees of the immutable type, which 
>>> I 
>>> did here (see the commented code):
>>>
>>> 
>>> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874
>>>
>>> but the problem now is that *TS* is a memory owned by Julia and that 
>>> will be fatal when GMT's own memory cleaning functions try to free it 
>>> and  
>>> -> Julia crashes.
>>> So if use a pure Julia solution I've no choice but to let memory 
>>> leeks and other house keeping to be done. Not good at all.
>>>
>>> For the time being I ended up with this ugly C  trick of sending to 
>>> C the job of changing some members (non-pointers) that need absolutely 
>>> to 
>>> changed after the type has been created
>>>
>>> 
>>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376
>>>
>>> but besides being ugly I've no guarantee that I can convince my 
>>> partners to let that backdoor go into the GMT lib. I much lovelier 
>>> trick 
>>

Re: [julia-users] Really need to change immutables

[J Luis]

segunda-feira, 10 de Agosto de 2015 às 20:15:57 UTC+1, Jameson escreveu:
>
> My suggestion would be to mirror only the parts of those structs that are 
> part of the public API. Then use unsafe_load / unsafe_store to read / 
> modify / write the intended changes. The API authors were nice to put the 
> public fields at the top so that you can do this (many libraries don't / 
> can't do this). Then the "real" object will always be the Ptr to the one 
> allocated by GMT, and you only have temporary copies of them alive at any 
> time inside Julia.
>

But GMT_TEXTSEGMENT is part of the GMT API (hm, have to check why it 
doesn't show up in http://gmt.soest.hawaii.edu/doc/latest/GMT_API.html)

Sorry, to be concrete, and repeating myself. I need to change n_rows of


http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
 
Can I do it?

BTW, I'm a developer of GMT (that's why I could create that backdoor 
function that temporarily saved me on this), although the API was all 
created by P. Wessel.

 

>
>
> On Mon, Aug 10, 2015 at 2:53 PM J Luis > 
> wrote:
>
>>
>>
>>> usually, there's is one big toplevel distinction driven by who will free 
>>> the memory: if C will be freeing the memory, then you must always have the 
>>> C code also allocating the memory (hopefully the library author provide 
>>> some sort of new / alloc / create function, although sometimes they rely on 
>>> the user calling malloc).
>>>
>>
>> Yes, the GMT_Create_Data (that ccals a C function with the same name) 
>> does that.
>>
>> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L852
>>   
>>
>>>
>>> > Is that really impossible and I'm doomed to the path exemplified 
>>> with that C GMT_blind_change_struct() function?
>>>
>>> ideally, C libraries that expect to manage a struct's memory also 
>>> provide accessor methods to read any of the structs important fields so 
>>> that you can always declare its type as Ptr{Void} in Julia. However, I 
>>> realize this is true of many C libraries.
>>>
>>
>>
>> The pointers are ok, my real problem are those 'scalars' like the n_rows 
>> in
>>
>> 
>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
>>
>> I only know the number of rows after having read the data and than the 
>> immut is already created
>>  
>>
>>>
>>>
>>> On Mon, Aug 10, 2015 at 9:58 AM J Luis  wrote:
>>>


 segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah escreveu:
>
> https://github.com/JuliaLang/julia/pull/12113
>

 So there is hope. Thanks

  

>
>
> On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:
>
>> Hi,
>>
>> Let me try to explain my need to fight with immutables. I made 
>> another round to my GMT wrapper (which is hopefully almost ready) and 
>> struggled again with the immutables. The point is that GMT API structs 
>> are 
>> deeply nested and need to be mirrored with immutables (otherwise Julia 
>> crashes). Namely this one 
>>
>> 
>> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445
>>
>> so I first went with the advised solution of creating and filling the 
>> type is julia and replace the pointees of the immutable type, which I 
>> did 
>> here (see the commented code):
>>
>> 
>> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874
>>
>> but the problem now is that *TS* is a memory owned by Julia and that 
>> will be fatal when GMT's own memory cleaning functions try to free it 
>> and  
>> -> Julia crashes.
>> So if use a pure Julia solution I've no choice but to let memory 
>> leeks and other house keeping to be done. Not good at all.
>>
>> For the time being I ended up with this ugly C  trick of sending to C 
>> the job of changing some members (non-pointers) that need absolutely to 
>> changed after the type has been created
>>
>> 
>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376
>>
>> but besides being ugly I've no guarantee that I can convince my 
>> partners to let that backdoor go into the GMT lib. I much lovelier trick 
>> would be if this chunk only of that backdoor function would work.
>>
>> else if (!strncmp (keyword, "API_POINTER_", 12U)) {/* 
>> Blindly change a pointer to a scalar. Irritatingly Julia ignores this */
>> if (!strcmp(&keyword[12], "UINT64"))
>> *(uint64_t *)ptr = *(uint64_t *)what;
>> }
>>  
>> but the problem is that I am not able to get from Julia the pointers 
>> address that would make that work. I tried with
>>
>> pointer(S0.n_rows)
>>
>> and
>>
>> pointer_from_objref(S0.n_rows)
>>

Re: [julia-users] Really need to change immutables

[Jameson Nash]

My suggestion would be to mirror only the parts of those structs that are
part of the public API. Then use unsafe_load / unsafe_store to read /
modify / write the intended changes. The API authors were nice to put the
public fields at the top so that you can do this (many libraries don't /
can't do this). Then the "real" object will always be the Ptr to the one
allocated by GMT, and you only have temporary copies of them alive at any
time inside Julia.


On Mon, Aug 10, 2015 at 2:53 PM J Luis  wrote:

>
>
>> usually, there's is one big toplevel distinction driven by who will free
>> the memory: if C will be freeing the memory, then you must always have the
>> C code also allocating the memory (hopefully the library author provide
>> some sort of new / alloc / create function, although sometimes they rely on
>> the user calling malloc).
>>
>
> Yes, the GMT_Create_Data (that ccals a C function with the same name) does
> that.
>
> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L852
>   
>
>>
>> > Is that really impossible and I'm doomed to the path exemplified
>> with that C GMT_blind_change_struct() function?
>>
>> ideally, C libraries that expect to manage a struct's memory also provide
>> accessor methods to read any of the structs important fields so that you
>> can always declare its type as Ptr{Void} in Julia. However, I realize this
>> is true of many C libraries.
>>
>
>
> The pointers are ok, my real problem are those 'scalars' like the n_rows in
>
>
> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517
>
> I only know the number of rows after having read the data and than the
> immut is already created
>
>
>>
>>
>> On Mon, Aug 10, 2015 at 9:58 AM J Luis  wrote:
>>
>>>
>>>
>>> segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah escreveu:

 https://github.com/JuliaLang/julia/pull/12113

>>>
>>> So there is hope. Thanks
>>>
>>>
>>>


 On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:

> Hi,
>
> Let me try to explain my need to fight with immutables. I made another
> round to my GMT wrapper (which is hopefully almost ready) and struggled
> again with the immutables. The point is that GMT API structs are deeply
> nested and need to be mirrored with immutables (otherwise Julia crashes).
> Namely this one
>
>
> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445
>
> so I first went with the advised solution of creating and filling the
> type is julia and replace the pointees of the immutable type, which I did
> here (see the commented code):
>
>
> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874
>
> but the problem now is that *TS* is a memory owned by Julia and that
> will be fatal when GMT's own memory cleaning functions try to free it and
> -> Julia crashes.
> So if use a pure Julia solution I've no choice but to let memory leeks
> and other house keeping to be done. Not good at all.
>
> For the time being I ended up with this ugly C  trick of sending to C
> the job of changing some members (non-pointers) that need absolutely to
> changed after the type has been created
>
>
> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376
>
> but besides being ugly I've no guarantee that I can convince my
> partners to let that backdoor go into the GMT lib. I much lovelier trick
> would be if this chunk only of that backdoor function would work.
>
> else if (!strncmp (keyword, "API_POINTER_", 12U)) {/*
> Blindly change a pointer to a scalar. Irritatingly Julia ignores this */
> if (!strcmp(&keyword[12], "UINT64"))
> *(uint64_t *)ptr = *(uint64_t *)what;
> }
>
> but the problem is that I am not able to get from Julia the pointers
> address that would make that work. I tried with
>
> pointer(S0.n_rows)
>
> and
>
> pointer_from_objref(S0.n_rows)
>
> and others, but nothing. It seams to work in the C side (I can see it
> with the debugger when I set in that piece of code) but than nothing
> changes. The C struct doesn't change.
> Is there a way to get the C pointer address from Julia?
>
> So, I guess my question is:
>
> How do we do to change immutable members that are not pointers?
> Is that really impossible and I'm doomed to the path exemplified
> with that C GMT_blind_change_struct() function?
>
>
>
>
>

Re: [julia-users] Really need to change immutables

[J Luis]

>
> usually, there's is one big toplevel distinction driven by who will free 
> the memory: if C will be freeing the memory, then you must always have the 
> C code also allocating the memory (hopefully the library author provide 
> some sort of new / alloc / create function, although sometimes they rely on 
> the user calling malloc).
>

Yes, the GMT_Create_Data (that ccals a C function with the same name) does 
that.

https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L852
  

>
> > Is that really impossible and I'm doomed to the path exemplified 
> with that C GMT_blind_change_struct() function?
>
> ideally, C libraries that expect to manage a struct's memory also provide 
> accessor methods to read any of the structs important fields so that you 
> can always declare its type as Ptr{Void} in Julia. However, I realize this 
> is true of many C libraries.
>


The pointers are ok, my real problem are those 'scalars' like the n_rows in


http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_resources.h#L517

I only know the number of rows after having read the data and than the 
immut is already created
 

>
>
> On Mon, Aug 10, 2015 at 9:58 AM J Luis > 
> wrote:
>
>>
>>
>> segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah escreveu:
>>>
>>> https://github.com/JuliaLang/julia/pull/12113
>>>
>>
>> So there is hope. Thanks
>>
>>  
>>
>>>
>>>
>>> On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:
>>>
 Hi,

 Let me try to explain my need to fight with immutables. I made another 
 round to my GMT wrapper (which is hopefully almost ready) and struggled 
 again with the immutables. The point is that GMT API structs are deeply 
 nested and need to be mirrored with immutables (otherwise Julia crashes). 
 Namely this one 

 
 https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445

 so I first went with the advised solution of creating and filling the 
 type is julia and replace the pointees of the immutable type, which I did 
 here (see the commented code):

 https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874

 but the problem now is that *TS* is a memory owned by Julia and that 
 will be fatal when GMT's own memory cleaning functions try to free it and  
 -> Julia crashes.
 So if use a pure Julia solution I've no choice but to let memory leeks 
 and other house keeping to be done. Not good at all.

 For the time being I ended up with this ugly C  trick of sending to C 
 the job of changing some members (non-pointers) that need absolutely to 
 changed after the type has been created

 
 http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376

 but besides being ugly I've no guarantee that I can convince my 
 partners to let that backdoor go into the GMT lib. I much lovelier trick 
 would be if this chunk only of that backdoor function would work.

 else if (!strncmp (keyword, "API_POINTER_", 12U)) {/* 
 Blindly change a pointer to a scalar. Irritatingly Julia ignores this */
 if (!strcmp(&keyword[12], "UINT64"))
 *(uint64_t *)ptr = *(uint64_t *)what;
 }
  
 but the problem is that I am not able to get from Julia the pointers 
 address that would make that work. I tried with

 pointer(S0.n_rows)

 and

 pointer_from_objref(S0.n_rows)

 and others, but nothing. It seams to work in the C side (I can see it 
 with the debugger when I set in that piece of code) but than nothing 
 changes. The C struct doesn't change.
 Is there a way to get the C pointer address from Julia?

 So, I guess my question is: 

 How do we do to change immutable members that are not pointers?
 Is that really impossible and I'm doomed to the path exemplified 
 with that C GMT_blind_change_struct() function?





>>>

Re: [julia-users] Really need to change immutables

[Jameson Nash]

> but the problem now is that *TS* is a memory owned by Julia and that will
be fatal when GMT's own memory cleaning functions try to free it and  ->
Julia crashes.

getting memory ownership right is absolutely critical when writing C
interop code. It is also a place where Julia gives you a large number of
tools (struct-compatible type layout, Ref, &, Ptr, c_malloc, unsafe_load),
because there is no feasible way to detect the intent of the C code
automatically.

usually, there's is one big toplevel distinction driven by who will free
the memory: if C will be freeing the memory, then you must always have the
C code also allocating the memory (hopefully the library author provide
some sort of new / alloc / create function, although sometimes they rely on
the user calling malloc).

> How do we do to change immutable members that are not pointers?

ccall goes to great lengths to make sure you don't accidentally do this,
because you semantically can't change a value, and Julia uses this to
implement many optimizations. And even if you managed to change one of the
instances of the value, Julia is free to delete / reuse the memory
containing that modification (or share it with something else that had the
same value) even before the call to `pointer_from_objref` returns.

> Is that really impossible and I'm doomed to the path exemplified with
that C GMT_blind_change_struct() function?

ideally, C libraries that expect to manage a struct's memory also provide
accessor methods to read any of the structs important fields so that you
can always declare its type as Ptr{Void} in Julia. However, I realize this
is true of many C libraries.


On Mon, Aug 10, 2015 at 9:58 AM J Luis  wrote:

>
>
> segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah escreveu:
>>
>> https://github.com/JuliaLang/julia/pull/12113
>>
>
> So there is hope. Thanks
>
>
>
>>
>>
>> On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:
>>
>>> Hi,
>>>
>>> Let me try to explain my need to fight with immutables. I made another
>>> round to my GMT wrapper (which is hopefully almost ready) and struggled
>>> again with the immutables. The point is that GMT API structs are deeply
>>> nested and need to be mirrored with immutables (otherwise Julia crashes).
>>> Namely this one
>>>
>>> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445
>>>
>>> so I first went with the advised solution of creating and filling the
>>> type is julia and replace the pointees of the immutable type, which I did
>>> here (see the commented code):
>>>
>>> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874
>>>
>>> but the problem now is that *TS* is a memory owned by Julia and that
>>> will be fatal when GMT's own memory cleaning functions try to free it and
>>> -> Julia crashes.
>>> So if use a pure Julia solution I've no choice but to let memory leeks
>>> and other house keeping to be done. Not good at all.
>>>
>>> For the time being I ended up with this ugly C  trick of sending to C
>>> the job of changing some members (non-pointers) that need absolutely to
>>> changed after the type has been created
>>>
>>>
>>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376
>>>
>>> but besides being ugly I've no guarantee that I can convince my partners
>>> to let that backdoor go into the GMT lib. I much lovelier trick would be if
>>> this chunk only of that backdoor function would work.
>>>
>>> else if (!strncmp (keyword, "API_POINTER_", 12U)) {/*
>>> Blindly change a pointer to a scalar. Irritatingly Julia ignores this */
>>> if (!strcmp(&keyword[12], "UINT64"))
>>> *(uint64_t *)ptr = *(uint64_t *)what;
>>> }
>>>
>>> but the problem is that I am not able to get from Julia the pointers
>>> address that would make that work. I tried with
>>>
>>> pointer(S0.n_rows)
>>>
>>> and
>>>
>>> pointer_from_objref(S0.n_rows)
>>>
>>> and others, but nothing. It seams to work in the C side (I can see it
>>> with the debugger when I set in that piece of code) but than nothing
>>> changes. The C struct doesn't change.
>>> Is there a way to get the C pointer address from Julia?
>>>
>>> So, I guess my question is:
>>>
>>> How do we do to change immutable members that are not pointers?
>>> Is that really impossible and I'm doomed to the path exemplified
>>> with that C GMT_blind_change_struct() function?
>>>
>>>
>>>
>>>
>>>
>>

Re: [julia-users] Really need to change immutables

[J Luis]

segunda-feira, 10 de Agosto de 2015 às 14:15:15 UTC+1, Isaiah escreveu:
>
> https://github.com/JuliaLang/julia/pull/12113
>

So there is hope. Thanks

 

>
>
> On Mon, Aug 10, 2015 at 8:11 AM, J Luis > 
> wrote:
>
>> Hi,
>>
>> Let me try to explain my need to fight with immutables. I made another 
>> round to my GMT wrapper (which is hopefully almost ready) and struggled 
>> again with the immutables. The point is that GMT API structs are deeply 
>> nested and need to be mirrored with immutables (otherwise Julia crashes). 
>> Namely this one 
>>
>> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445
>>
>> so I first went with the advised solution of creating and filling the 
>> type is julia and replace the pointees of the immutable type, which I did 
>> here (see the commented code):
>>
>> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874
>>
>> but the problem now is that *TS* is a memory owned by Julia and that will 
>> be fatal when GMT's own memory cleaning functions try to free it and  -> 
>> Julia crashes.
>> So if use a pure Julia solution I've no choice but to let memory leeks 
>> and other house keeping to be done. Not good at all.
>>
>> For the time being I ended up with this ugly C  trick of sending to C the 
>> job of changing some members (non-pointers) that need absolutely to changed 
>> after the type has been created
>>
>> 
>> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376
>>
>> but besides being ugly I've no guarantee that I can convince my partners 
>> to let that backdoor go into the GMT lib. I much lovelier trick would be if 
>> this chunk only of that backdoor function would work.
>>
>> else if (!strncmp (keyword, "API_POINTER_", 12U)) {/* Blindly 
>> change a pointer to a scalar. Irritatingly Julia ignores this */
>> if (!strcmp(&keyword[12], "UINT64"))
>> *(uint64_t *)ptr = *(uint64_t *)what;
>> }
>>  
>> but the problem is that I am not able to get from Julia the pointers 
>> address that would make that work. I tried with
>>
>> pointer(S0.n_rows)
>>
>> and
>>
>> pointer_from_objref(S0.n_rows)
>>
>> and others, but nothing. It seams to work in the C side (I can see it 
>> with the debugger when I set in that piece of code) but than nothing 
>> changes. The C struct doesn't change.
>> Is there a way to get the C pointer address from Julia?
>>
>> So, I guess my question is: 
>>
>> How do we do to change immutable members that are not pointers?
>> Is that really impossible and I'm doomed to the path exemplified with 
>> that C GMT_blind_change_struct() function?
>>
>>
>>
>>
>>
>

Re: [julia-users] Really need to change immutables

[Isaiah Norton]

https://github.com/JuliaLang/julia/pull/12113

On Mon, Aug 10, 2015 at 8:11 AM, J Luis  wrote:

> Hi,
>
> Let me try to explain my need to fight with immutables. I made another
> round to my GMT wrapper (which is hopefully almost ready) and struggled
> again with the immutables. The point is that GMT API structs are deeply
> nested and need to be mirrored with immutables (otherwise Julia crashes).
> Namely this one
>
> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445
>
> so I first went with the advised solution of creating and filling the type
> is julia and replace the pointees of the immutable type, which I did here
> (see the commented code):
>
> https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874
>
> but the problem now is that *TS* is a memory owned by Julia and that will
> be fatal when GMT's own memory cleaning functions try to free it and  ->
> Julia crashes.
> So if use a pure Julia solution I've no choice but to let memory leeks and
> other house keeping to be done. Not good at all.
>
> For the time being I ended up with this ugly C  trick of sending to C the
> job of changing some members (non-pointers) that need absolutely to changed
> after the type has been created
>
>
> http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376
>
> but besides being ugly I've no guarantee that I can convince my partners
> to let that backdoor go into the GMT lib. I much lovelier trick would be if
> this chunk only of that backdoor function would work.
>
> else if (!strncmp (keyword, "API_POINTER_", 12U)) {/* Blindly
> change a pointer to a scalar. Irritatingly Julia ignores this */
> if (!strcmp(&keyword[12], "UINT64"))
> *(uint64_t *)ptr = *(uint64_t *)what;
> }
>
> but the problem is that I am not able to get from Julia the pointers
> address that would make that work. I tried with
>
> pointer(S0.n_rows)
>
> and
>
> pointer_from_objref(S0.n_rows)
>
> and others, but nothing. It seams to work in the C side (I can see it with
> the debugger when I set in that piece of code) but than nothing changes.
> The C struct doesn't change.
> Is there a way to get the C pointer address from Julia?
>
> So, I guess my question is:
>
> How do we do to change immutable members that are not pointers?
> Is that really impossible and I'm doomed to the path exemplified with
> that C GMT_blind_change_struct() function?
>
>
>
>
>

[julia-users] Really need to change immutables

[J Luis]

Hi,

Let me try to explain my need to fight with immutables. I made another 
round to my GMT wrapper (which is hopefully almost ready) and struggled 
again with the immutables. The point is that GMT API structs are deeply 
nested and need to be mirrored with immutables (otherwise Julia crashes). 
Namely this one 

https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1445

so I first went with the advised solution of creating and filling the type 
is julia and replace the pointees of the immutable type, which I did here 
(see the commented code):

https://github.com/joa-quim/GMT.jl/blob/master/src/gmt_main.jl#L874

but the problem now is that *TS* is a memory owned by Julia and that will 
be fatal when GMT's own memory cleaning functions try to free it and  -> 
Julia crashes.
So if use a pure Julia solution I've no choice but to let memory leeks and 
other house keeping to be done. Not good at all.

For the time being I ended up with this ugly C  trick of sending to C the 
job of changing some members (non-pointers) that need absolutely to changed 
after the type has been created


http://gmt.soest.hawaii.edu/projects/gmt/repository/entry/branches/5.2.0/src/gmt_api.c#L7376

but besides being ugly I've no guarantee that I can convince my partners to 
let that backdoor go into the GMT lib. I much lovelier trick would be if 
this chunk only of that backdoor function would work.

else if (!strncmp (keyword, "API_POINTER_", 12U)) {/* Blindly 
change a pointer to a scalar. Irritatingly Julia ignores this */
if (!strcmp(&keyword[12], "UINT64"))
*(uint64_t *)ptr = *(uint64_t *)what;
}
 
but the problem is that I am not able to get from Julia the pointers 
address that would make that work. I tried with

pointer(S0.n_rows)

and

pointer_from_objref(S0.n_rows)

and others, but nothing. It seams to work in the C side (I can see it with 
the debugger when I set in that piece of code) but than nothing changes. 
The C struct doesn't change.
Is there a way to get the C pointer address from Julia?

So, I guess my question is: 

How do we do to change immutable members that are not pointers?
Is that really impossible and I'm doomed to the path exemplified with 
that C GMT_blind_change_struct() function?