Latest Bugs & Tasks
Implemented in hrev45627.
Haiku does not support Greek Polytonic for my greek language, but Windows, Linux and MacOS can. A long time ago I started my own project for Haiku in order to support Greek Polytonic keyboard. My source code increased the 5 dead-keys up to 32 dead-keys and also each dead key array can contain up to 19 pairs of dead key characters. Of course it does not break compatibility.
The project is finished and I have attached my patches.
If you accept my patches, please also close the other ticket:
Here is the video showing the possibilities.
2013-05-04 15:13:29,246 INFO No information found about language code 2013-05-04 15:13:29,323 INFO Running update_against_templates over /nb/haiku/ 2013-05-04 15:13:29,336 DEBUG cache miss for /nb/haiku/add-ons/disk_systems/bfs/nb.catkeys:get_mtime 2013-05-04 15:13:29,432 DEBUG cache miss for /nb/haiku/:getquickstats 2013-05-04 15:13:29,633 DEBUG Cache miss for /srv/pootle-production/catalogs/haiku/add-ons/disk_systems/bfs/en.catkeys 2013-05-04 15:13:29,636 DEBUG Cache miss for /srv/pootle-production/catalogs/haiku/add-ons/disk_systems/bfs/nb.catkeys 2013-05-04 15:13:29,642 DEBUG Updating /nb/haiku/add-ons/disk_systems/bfs/nb.catkeys 2013-05-04 15:13:29,665 ERROR Failed to run update_against_templates over /nb/haiku/: 'ascii' codec can't encode character u'\xe5' in position 4: ordinal not in range(128)
I use a hrev45516 nightly. When I add files to project in BeIDE show me a KDL
Last message repeated 8 times. PANIC: _mutex_unlock() failure: thread 2779 is trying to release mutex 0x801b6384 (current holder 2218) Welcome to Kernel Debugging Land... Thread 2779 "postgres" running on CPU 1 stack trace for thread 2779 "postgres" kernel stack: 0xccf44000 to 0xccf40000 user stack: 0x61b28000 to 0x62b28000 frame caller <image>:function + offset 0 ccf47d58 (+ 32) 80132aa2 <kernel_x86> arch_debug_stack_trace + 0x12 1 ccf47d78 (+ 16) 80092db3 <kernel_x86> stack_trace_trampoline(NULL) + 0x0b 2 ccf47d88 (+ 12) 8012553e <kernel_x86> arch_debug_call_with_fault_handler + 0x1b 3 ccf47d94 (+ 48) 80094856 <kernel_x86> debug_call_with_fault_handler + 0x5e 4 ccf47dc4 (+ 64) 80092fd3 <kernel_x86> kernel_debugger_loop(0x801718f7 "PANIC: ", 0x8016ebe0 "_mutex_unlock() failure: thread %ld is trying to release mutex %p (current holder %ld) ", 0xccf47e70 " ", int32: 1) + 0x21b 5 ccf47e04 (+ 48) 80093337 <kernel_x86> kernel_debugger_internal(0x801718f7 "PANIC: ", 0x8016ebe0 "_mutex_unlock() failure: thread %ld is trying to release mutex %p (current holder %ld) ", 0xccf47e70 " ", int32: 1) + 0x53 6 ccf47e34 (+ 48) 80094be2 <kernel_x86> panic + 0x36 7 ccf47e64 (+ 64) 800894cc <kernel_x86> _mutex_unlock + 0x74 8 ccf47ea4 (+ 160) 800f669f <kernel_x86> _user_xsi_semop + 0x8f3 9 ccf47f44 (+ 180) 801281e0 <kernel_x86> handle_syscall + 0xcd user iframe at 0xccf47fa8 (end = 0xccf48000) eax 0x1e ebx 0x23ba188 exc 0x62b27884 edx 0x610e8114 esi 0x17cd0fc edi 0x549b19b0 ebp 0x62b278b0 esp 0xccf47fdc eip 0x610e8114 eflags 0x3202 user esp 0x62b27884 vector: 0x63, error code: 0x0 10 ccf47fab (+ 0) 610e8114 <commpage> commpage_syscall + 0x04 11 62b278b0 (+ 64) 015162w9 <postgres> PGSemaphoreLock + 0x65 12 62b278f0 (+ 64) 0155d4be <postgres> LWLockAcquireOrWait + 0x14e 13 62b27930 (+ 80) 013a2e38 <postgres> XLogFlush + 0x80 14 62b27980 (+ 272) 01396092 <postgres> ForceSyncCommit (nearest) + 0x526 15 62b27a90 (+ 48) 01396aab <postgres> ForceSyncCommit (nearest) + 0xf3f 16 62b27ac0 (+ 48) 013974b5 <postgres> CommitTransactionCommand + 0x121 17 62b27af0 (+ 32) 0156a484 <postgres> check_log_duration (nearest) + 0x8e0 18 62b27b10 (+ 176) 015686a9 <postgres> pg_plan_queries (nearest) + 0x435 19 62b27bc0 (+ 144) 0156c409 <postgres> PostgresMain + 0x839 20 62b27c50 (+ 80) 01525fe3 <postgres> ClosePostmasterPorts (nearest) + 0x290b 21 62b27ca0 (+ 48) 015257d2 <postgres> ClosePostmasterPorts (nearest) + 0x20fa 22 62b27cd0 (+ 336) 015224f6 <postgres> PostmasterMain (nearest) + 0x19ee 23 62b27e20 (+ 272) 01521df6 <postgres> PostmasterMain + 0x12ee 24 62b27f30 (+ 64) 014b903c <postgres> main (nearest) + 0x208 25 62b27f70 (+ 48) 0134bd3b <postgres> _start + 0x5b 26 62b27fa0 (+ 48) 0117f586 </boot/system/runtime_loader@0x01170000> <unknown> + 0xf506 27 62b27fd0 (+ 0) 618e825e <commpage> commpage_thread_exit + 0x00
I don't know yet if it is reproducible as Haiku now gives another KDL when I try to start it.
I will have a look at the other KDL and reinstall Haiku again to see if I can reproduce this one.
There might be some typos in the KDL output as I made a photo of the KDL and typed it over. I still have the photo, so I can look back if the KDL above contains something odd.
When defining a user build profile that writes the image to a local partition, e.g. /dev/sda57, on Linux one needs to run sudo to do so.
However, running the entire build under sudo is inadvisable. I've created a patch that would allow a user build profile to specify HAIKU_REQUIRES_SUDO = 1 such that at the image writing stage, it will invoke the build_haiku_image script using sudo.
Implemented in hrev45612.
I use a single button 2008 Macbook Pro Trackpad and it'd be nice to be able to right click by using two fingers on the track pad while pressing the left mouse button. That's how the typical Macbook right clicks.
At the moment I can't right click at all unless I use a usb mouse.
Terminal exhibits a very long lag before returning to normal, when tab completition is used and accidentially the string cannot be completed, e.g. because there is no file with the given starting string.
Thanks a lot! Applied in hrev45610.
Sorry, didn't notice you assigned it to yourself already! In any case, it's fixed in hrev45609 - I just use B_RELATIVE_TIMEOUT in case the timeout is 0.
When a BMenu is large enough to require scrolling, the marked item may not be in view.
I've attached a patch that will scroll the marked item into view. The patch also behaves like a BMenuField, scrolling the item to be immediately under the cursor when the menu is opened if possible.
Currently, there are two mimetypes (mid & midi) whose descriptions are the same ("MIDI File").
In Tracker's Find Panel, as they both have the same label, the marked item doesn't necessarily get cleared correctly, leading to inconsistent UI state.
I have attached a patch to correct this, using similar logic to that used in the FileTypes preflet.
I was searching for "Microsoft PowerPoint Presentation Macro-enabled Document" and this file type name is truncated in the popup menu of "Find" window.
When trying to receive data from a nonblocking socket, I get an "Operation timed out" error, while I am expecting a EWOULDBLOCK error as there is no data to read. Changing the socket to blocking does block as expected.
I expanded my test case from #9678 and attached it to this ticket.
This happens with href45525.