I just meet haxe right now, so I'm doing some tests. However the first test I made didn't work. Why does Api.getSize() only returns 0 (regardless of type and its assigned value)?
import flash.sampler.Api;
class Test {
static function main() {
var a = 44;
trace(Api.getSize(a)); // prints 0
}
}
What version of your Flash Player?
In Adobe documentation said:
Returns the size in memory of a specified object when used with the
Flash Player 9.0.115.0 or later debugger version. If used with a Flash
Player that is not the debugger version, this method returns 0.
Related
I am trying to use the XKB extension to XCB to capture keyboard input. The particular implementation that I'm writing is in rust, however the erroneous part of the code is mostly just calls through FFI. My goal is to be able to process keyboard events, such as when a key is pressed, released, etc., and to be able to convert the keycodes into unicode. Currently I am trying to get this example from the libxkbcommon quick guide working.
Below is the code I tried:
let (conn, screen_num) = Connection::connect(None)?;
// Other code...
let raw_conn = conn.get_raw_conn() as *mut xkbcommon_sys::xcb_connection_t;
let context = unsafe { xkb_context_new(XKB_CONTEXT_NO_FLAGS) };
if context.is_null() {
return Err(Error::XkbContextInit);
}
let device_id = unsafe { xkb_x11_get_core_keyboard_device_id(raw_conn) };
// This branch is taken
if device_id == -1 {
unsafe { xkb_context_unref(context); }
return Err(Error::XkbGetCoreKbDev);
}
I expected to be able to get the device ID of the core keyboard, however instead the function returned -1, signaling an error.
After some experimenting and digging around, I found that the xkb_x11_get_core_keyboard_device_id function was specifically failing on this request, which used XCB_XKB_ID_USE_CORE_KBD as the value for the device spec. Since I don't get much error information from this function, I translated the request to the X server into rust, and got the following error:
// Output from debugging the returned error enum
Protocol(
X(
Access(
RequestError {
response_type: 0,
error_code: 10,
sequence: 3,
bad_value: 2003,
minor_opcode: 1,
major_opcode: 130,
pad: 1
}
)
)
)
I also tried some of the other values for the device spec listed here, but received the same error.
Unsure whether this was an issue with the X server, I tried it on my installation of Kali as well as an Ubuntu 20.04 VM, both of which yielded the same error (although with different values for the bad_value field). Furthermore, any time I use XCB_XKB_ID_USE_CORE_KBD where a device spec is required, I get this error. I'm not really sure what could be causing this issue. This seems to be specifically related to XKB since I am also using XCB to capture the screen, and I have not had any errors with that so far. Any help or guidance would be appreciated.
After searching around for a while, I found this post which linked to some documentation which made me realize that I was never setting up the XKB extension. Adding the following code fixed the issue:
let res = unsafe {
xkb_x11_setup_xkb_extension(
raw_conn,
MAJOR_VERSION as u16,
MINOR_VERSION as u16,
XKB_X11_SETUP_XKB_EXTENSION_NO_FLAGS,
ptr::null_mut(),
ptr::null_mut(),
ptr::null_mut(),
ptr::null_mut()
)
};
if res == 0 {
return Err(Error::XkbInit);
}
If you are using the xcb and xkbcommon crates, they have an example using the (currently) beta versions of the crates that do this using the API instead of unsafe functions:
let context = xkb::Context::new(xkb::CONTEXT_NO_FLAGS);
let device_id = xkb::x11::get_core_keyboard_device_id(&connection);
let keymap = xkb::x11::keymap_new_from_device(
&context,
&connection,
device_id,
xkb::KEYMAP_COMPILE_NO_FLAGS,
);
let state = xkb::x11::state_new_from_device(&keymap, &connection, device_id);
https://github.com/rust-x-bindings/toy_xcb/blob/master/src/keyboard.rs
I'm using SHGetFileInfo function for getting icons for folders and different file types. According to MSDN call of this function should be done from background thread and before call Component Object Model (COM) must be initialized with CoInitialize or OleInitialize.
My code looks like this:
public void SetHlinkImage(string path)
{
Shell32.OleInitialize(IntPtr.Zero);
Task task = Task.Factory.StartNew(() => { LoadIcons(path); });
}
private void LoadIcons(string path)
{
image = GetHlinkImage(path);
if (OwnerControl.InvokeRequired)
layout.ModuleControl.BeginInvoke((MethodInvoker)delegate ()
{
Shell32.OleUninitialize();
});
}
public Icon GetHlinkImage(string path)
{
uint flags = Shell32.SHGFI_ICON | Shell32.SHGFI_ATTRIBUTES | Shell32.SHGFI_SMALLICON;
Shell32.SHFILEINFO shfi = new Shell32.SHFILEINFO();
IntPtr result = Shell32.SHGetFileInfo(path,
Shell32.FILE_ATTRIBUTE_DIRECTORY,
ref shfi,
(uint)Marshal.SizeOf(shfi),
flags);
Icon icon = (Icon)Icon.FromHandle(shfi.hIcon).Clone();
WinApi.DestroyIcon(shfi.hIcon); // cleanup
return icon;
}
Mostly the problem appears after first call of the code and as result I get an exception when I tried to create Icon from icon handle:
System.ArgumentException: Win32 handle that was passed to Icon is not
valid or is the wrong type
And further calls of the code work without problems.
Actually behaviour also somehow depends on the test system. It is hardly possible to reproduce this issue on Windows10 systems but on Windows 7 it happens quite often.
Has anyone experienced this problem?
From comment of Hans Passant:
Calling OleInitialize() is pointless, the CLR already initializes COM before it starts a thread. And it failed, something you cannot see because you are not checking its return value. Not knowing that, it just spirals into undiagnosable misery from there. Yes, more of it on Win7. You must provide an STA thread, if this needs to run in the background then consider this solution.
I have an Android app which uses OpenSL ES for audio. It runs correctly in API17 through API 22. While developing the app, I read somewhere that although OpenSL supports up to 32 objects (platform dependent), Android supports only 11. And so, I designed the app accordingly.
For example I create multiple buffer objects in JNI
// buffer queue player interfaces
// FIRST BUFFER
static SLObjectItf buffer_obj_mainBeat_1 = NULL;
static SLPlayItf buffer_itf_mainBeat_1;
static SLAndroidSimpleBufferQueueItf buf_q_mainBeat_1;
// SECOND BUFFER
static SLObjectItf buffer_obj_mainBeat_2 = NULL;
static SLPlayItf buffer_itf_mainBeat_2;
static SLAndroidSimpleBufferQueueItf buf_q_mainBeat_2;
// THIRD BUFFER
static SLObjectItf buffer_obj_mainBeat_3 = NULL;
static SLPlayItf buffer_itf_mainBeat_3;
static SLAndroidSimpleBufferQueueItf buf_q_mainBeat_3;
Then, I also define the required player interfaces etc...
In the Java code I play each of the defined objects sequentially in loop:
public void playMainBeat {
switch (mainBeat_buf_counter) {
case 1:
setPlayStateMainBeat1(true); // play this sound
setPlayStateMainBeat2(false); // stop next bufQ if not done and rewind
mainBeat_buf_counter = 2;
break;
case 2:
setPlayStateMainBeat2(true);
setPlayStateMainBeat3(false);
mainBeat_buf_counter = 3;
break;
case 3:
setPlayStateMainBeat3(true);
setPlayStateMainBeat1(false);
mainBeat_buf_counter = 1;
break;
}
}
Each of the sound samples that I am playing are about 300 milliseconds. I don't want to stop one sound while playing the next as I loop through the sequence. Notice that I stop the 1st sound after starting the 3rd. Then the loop starts at the top again. The loop in the Java code looks something like the following code:
mainBeat_buf_counter = 1; // initialize counter
while (hasStarted){
playMainBeat();
try {
Thread.sleep(soundInterval);
} catch (InterruptedException e) {; }
}
This all works great until API23 (Marshmallow). Marshmallow will not play all the buffers. It simply fails to play. Sounds are absent in a regular pattern.
I cannot find any documentation regarding the number of objects supported by Android for OpenSL ES. But, if I reduce the number of objects to 7 it does not skip sounds. However, the reduced number of buffers is not adequate for my application. I suspect that the number of supported objects was reduced from 11 objects to 7 objects at API23.
Can anyone confirm the number of objects supported in Android? Or, maybe I am going about this all wrong and there is a better way?
Thanks,
var foo = 0, bar = 0
process.nextTick(function() {
debugger
})
Entering node REPL using node debug, and trying to print some variables, I found that foo and bar can not be accessed either: ReferenceError: foo is not defined
var foo = 0, bar = 0
process.nextTick(function() {
console.log(foo)
})
process.nextTick(function() {
debugger
})
But somehow I 'access' foo from another async callback function, it became visible, print bar still raises ReferenceError.
Is it about V8 JIT or Node implementing details?
There seems to be nothing wrong with the code, I am not sure how you used the debugger you could try the node-inspector for a better debugging experience.
You can always use the console.log to get the current scope value. Same example in browser environment.
var foo = 0, bar = 0
window.setTimeout(function() {
console.log(foo, bar);
}, 0);
Yes, this is about V8 "optimizing" the scope -- it leaves out variables that are not actually referenced by the code inside the function, even though they should be in scope.
If you want to see a variable during debug inside the function, you can add a do-nothing line of code that references the variable. That will force the V8 compiler to make the variable available in that scope.
I wonder whether there is another way?...Whether you can somehow tell V8 to keep more things in scope?
I am trying to write a listener using the CoreAudio API for when the default audio output is changed (e.g.: a headphone jack is plugged in). I found sample code, although a bit old and using deprecated functions (http://developer.apple.com/mac/library/samplecode/AudioDeviceNotify/Introduction/Intro.html, but it didn't work. Re-wrote the code in the 'correct' way using AudioHardwareAddPropertyListener method, but still it doesn't seem to work. When I plug in a headphone the function that I registered is not triggered. I'm a bit of a loss here... I suspect the problem may lay some where else, but I can't figure out where...
The Listener Registration Code:
OSStatus err = noErr;
AudioObjectPropertyAddress audioDevicesAddress = { kAudioHardwarePropertyDefaultOutputDevice, KAudioObjectPropertyScopeGlobal, KAudioObjectPropertyElementMaster };
err = AudioObjectAddPropertyListener ( KAudioObjectAudioSystemObject, &AudioDevicesAddress, coreaudio_property_listener, NULL);
if (err) trace ("error on AudioObjectAddPropertyListener");
After a search in sourceforge for projects that used the CoreAudio API, I found the rtaudio project, and more importantly these lines:
// This is a largely undocumented but absolutely necessary
// requirement starting with OS-X 10.6. If not called, queries and
// updates to various audio device properties are not handled
// correctly.
CFRunLoopRef theRunLoop = NULL;
AudioObjectPropertyAddress property = { kAudioHardwarePropertyRunLoop,
kAudioObjectPropertyScopeGlobal,
kAudioObjectPropertyElementMaster };
OSStatus result = AudioObjectSetPropertyData( kAudioObjectSystemObject, &property, 0, NULL, sizeof(CFRunLoopRef), &theRunLoop);
if ( result != noErr ) {
errorText_ = "RtApiCore::RtApiCore: error setting run loop property!";
error( RtError::WARNING );
}
After adding this code I didn't even need to register a listener myself.
Try CFRunLoopRun() - it has the same effect. i.e. making sure the event loop that is calling your listener is running.