64-bit blues

new topic     » topic index » view thread      » older message » newer message
  • Posted by irv May 24, 2012
  • 1190 views

I've run into a couple of problems converting to 64-bit Euphoria: The first, I've solved myself; the second is beyond my skill level.

Stats: Euphoria Interpreter v4.1.0 development 64-bit Linux, Using System Memory Revision Date: 2011-06-30 16:06:49, Id: 5038:3739d931e005

GTK version 3.4.1 EuGTK version 4.5.9 Platform Linux 3.2.0-23-generic #36-Ubuntu SMP ... x86_64 GNU/Linux 2x AMD Athlon II X2 220 Processor 3791MB Linux Mint Maya

To get string arrays to work in 64bits, I modified the marked lines in std/machine.e: 

public function allocate_pointer_array(sequence pointers, types:boolean cleanup = 0) 
    atom pList 
	integer len = length(pointers)  * ADDRESS_LENGTH  
 
    pList = allocate( (len + ADDRESS_LENGTH ) ) 
    poke8(pList, pointers) --IGM these were poke4, will have to be wrapped in an 
    poke8(pList + len, 0)  --IGM ifdef to work on both platforms, I guess. 
	if cleanup then 
		return delete_routine( pList, FREE_ARRAY_RID ) 
	end if 
    return pList 
end function

Do we already have a CPU_64 defined somewhere, otherwise, how best to determine this?

Problem passing pointers via c_func/c_proc? 

SET: GtkWindow property: 'position'  
     Expects: Ptr Int  
     Returns: Nul  
     Vector: 107 
     ARGS: {32874896,1} 
 
SET: GtkWindow property: 'border_width'  
     Expects: Ptr Int  
     Returns: Nul  
     Vector: 108 
     ARGS: {32874896,1} 
 
SET: Cairo_t property: 'fill_rule'  
     Expects: Ptr Int  
     Returns: Nul  
     Vector: 114 
     ARGS: {2604572528,0} -- first arg is the handle 
 
/home/irv/demos/GtkEngine.e:494 in function set()  
A machine-level exception occurred during execution of this statement (signal 11)
The call at line 494 is: c_proc(method[VECTOR],args)

The same programs work perfectly when running 32-bit Eu, but there the handles never exceed 9 digits.

Further testing shows that both c_proc and c_func cause an exception whenever the handle passed to them looks too large; greater than 1_000_000_000 apparently.

This happens 100% of the time with test60.ex or any program which creates a Cairo object, and unreliably at random times with other controls.

What to do?

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu