When trying to highlight text to copy/paste the highlighted text begins overlapping.
Example: Go to the following URL and attempt to highlight "Matrox G450 ATX Dual VGA"
attached screenshot showing issue
I have an Lenovo Z580 (http://shop.lenovo.com/us/en/laptops/ideapad/z-series/z580/)
Haiku used to boot on this laptop from CD just fine. I have not downloaded and tried Haiku in a while so I can't tell you exactly when the last time worked was. I have tried various nightlies over the last month or so and non have booted. I get a KDL at the drive icon reporting now boot partition found, but I am booting from the CD, it is the boot partition. The best I could get you is a photo of the screen.
device Network controller (Ethernet controller) [2|0|0] vendor 1022: Advanced Micro Devices, Inc. [AMD] device 2001: 79c978 [HomePNA]
This device is recognized and acquires the correct DHCP address in BeOS.
More and more people on IRC mention that they are unable to register at Trac, because they are rejected as possible spam. This is very bad, as it deterres bug reports and patches and ultimately possibly new developers.
I have no idea what's the problem, let alone the solution. I'll post a short discussion by PulkoMandy and Barrett, with Adrien's take on it:
[18:23] <Barrett> <gbl08ma> Barrett: I tried registering with two email addresses, first a Gmail one and after that didn't work, a @tny.im one (personal domain) [18:23] <Barrett> <gbl08ma> both times I got an error message "Submission rejected as potential spam" because of failed captcha attempts and high spambayes probability [18:34] <PulkoMandy> Barrett: not much can be done, users can be added manually but that won't fix things long-term [18:35] <PulkoMandy> basically the "register" page submit feeds an empty string to the spam filter logic no matter what [18:35] <PulkoMandy> and people keep marking things as "spam" for our bayesian filter in trac administration, so now everything empty is "spam" [18:35] <PulkoMandy> and it's not possible to register anymore [18:36] <PulkoMandy> the captcha would save it, but I think it's broken [18:37] <Barrett> in past I suggested to use reCaptcha, but forgot how it ended BTW [18:39] <PulkoMandy> that's what we use [18:40] <PulkoMandy> possibly our API key is broken however, no idea how to test that
This is hrev50505.
Starting "WebPositive http://dir.xiph.org/" from Terminal, I get over and over:
[libmodplug @ 0x197c39c0] Format libmodplug detected only with low score of 24, misdetection possible!
All the while I receive data full-speed before eventually WebPositive crashes in several BUrlProtocol.HTTP threads (full debug report attached):
thread 16965: BUrlProtocol.HTTP state: Exception (Segment violation) Frame IP Function Name ----------------------------------------------- 0x70ff34e8 0x13423b5 /boot/system/lib/x86/libroot.so + 0xa83b5 Unable to retrieve disassembly for IP 0x13423b5: No such file or directory Frame memory: [0x70ff34d0] .5w.8..S85.pl_7. ac 35 77 18 38 ad 06 53 38 35 ff 70 6c 5f 37 01 [0x70ff34e0] . ... w. 00 20 00 00 00 20 77 18 0x70ff3528 0x13426dc /boot/system/lib/x86/libroot.so + 0xa86dc 0x70ff3578 0x134326b /boot/system/lib/x86/libroot.so + 0xa926b 0x70ff3598 0x134349e /boot/system/lib/x86/libroot.so + 0xa949e 0x70ff35e0 0xa9d2e0 BMessage::operator=(BMessage const&) + 0x32 0x70ff3600 0xa9d4ae BMessage::BMessage(BMessage const&) + 0x30 0x70ff3690 0xa9d530 BMessage::_SendMessage(long, long, long, long long, bool, BMessenger&) const + 0x72 0x70ff36c0 0xaa31fe BMessenger::SendMessage(BMessage*, BMessenger, long long) const + 0x32 0x70ff3740 0xaa353e BMessenger::SendMessage(BMessage*, BHandler*, long long) const + 0x9e 0x70ff3790 0xa9630b BLooper::_PostMessage(BMessage*, BHandler*, BHandler*) + 0x41 0x70ff3800 0xa978c4 BLooper::PostMessage(unsigned long, BHandler*, BHandler*) + 0x2c 0x70ff3848 0x349e5b4 WebCore::MediaPlayerPrivate::DownloadProgress(BUrlRequest*, long, long) + 0xd4 0x70ff4900 0xe94ea1 BHttpRequest::_MakeRequest() + 0xa69 0x70ff49c0 0xe953e0 BHttpRequest::_ProtocolLoop() + 0x1bc 0x70ff49e0 0xe9bb34 BUrlRequest::_ThreadEntry(void*) + 0x1c 0x70ff49f8 0x12c6c87 /boot/system/lib/x86/libroot.so + 0x2cc87 00000000 0x60ac3250 commpage_thread_exit + 0
In the process of fixing #10928, I noticed that the screenshot tool doesn't show any errors when saving the image fails (because of insufficient permissions, or if the destination for some reason is not a directory, or any other storage error).
On error, the window just stayed open, instead of closing. This can be very confusing for the users who might not remember that the normal behavior is to close on save, and thus may think the file saved sucessfully when it didn't.
This patch fixes the problem by adding error alerts to the saving function.
Applied in hrev50530, thanks!
Feel free to continue with the improved error handling and user alerts, or something else as you wish :)
Should be fixed in hrev50529.
I built grep-2.24 and make-4.1 with porter, installed both locally with sources.
Debugger grep lets me locate the grep.c source file successfully, while Debugger make lets me locate the main.c source file but fails to load it.