Development mailing list

2013/4/22 John Scipione jscipione@xxxxxxxxx I've noticed that sometimes emails to haiku-commits will come looking like replies to the previous push instead of as a new email thread. I've discovered that this is because the new email affects identical components as the previous email which means that it also has an identical subject. For example this just happened with Ingo's few recent pushes concerning package management. ...

I've noticed that sometimes emails to haiku-commits will come looking like replies to the previous push instead of as a new email thread. I've discovered that this is because the new email affects identical components as the previous email which means that it also has an identical subject. For example this just happened with Ingo's few recent pushes concerning package management. Would it be possible to add some sort of unique identifier such as the short hash of the last commit to the email subject so that each email will be treated as a new thread? It's a small detail I know, but, it ...

Στις 22/4/2013 7:12 μμ, ο/η John Scipione έγραψε: On Mon, Apr 22, 2013 at 11:57 AM, Jérôme Duval korli@xxxxxxxxxxxxxxxx wrote: 2013/4/22 ΧΡΗΣΤΟΣ ΜΑΡΕΤΣΙΚΟΣ chrisgrelec@xxxxxx and then I open the text file mydumpfile with the program StyleEdit, I see for the dead key Rough breathing (Dasia)that it has 16 entries instead of 18. ...

On Mon, Apr 22, 2013 at 11:57 AM, Jérôme Duval korli@xxxxxxxxxxxxxxxx wrote: 2013/4/22 ΧΡΗΣΤΟΣ ΜΑΡΕΤΣΙΚΟΣ chrisgrelec@xxxxxx and then I open the text file mydumpfile with the program StyleEdit, I see for the dead key Rough breathing (Dasia)that it has 16 entries instead of 18. I don’t know who is the counter (or counters) in order to increase price from 16 to 18 entries when I make dump keymap. Not sure I understand what you mean. Would you mean 16 lines dumped instead ...

Hi, 2013/4/22 ΧΡΗΣΤΟΣ ΜΑΡΕΤΣΙΚΟΣ chrisgrelec@xxxxxx and then I open the text file mydumpfile with the program StyleEdit, I see for the dead key Rough breathing (Dasia)that it has 16 entries instead of ...

Greek Extended Keymap - Greek Polytonic Hello! I need help. Before time I began my own project for Haiku in order to supports Greek Polytonic keyboard. The project is finished, and soon I’ll upload the source code, also I prepare a video for youtube. ...

Dear Colleagues, during trying to resolve a Trac issue #6227, related to support of Chinese GB18030 encoding I have found some code that is looking like dead or semi-functional. I'm speaking about support of so known designation of 96/94 multi-byte characters sets, mentioned in in Ecma-35 as GZDM4, G1ZDM4, G2ZDM4, G2ZDM4 and G1ZDM6, G2ZDM6, G2ZDM6 commands. Looks like original MuTerm 2.3 from which we have started our Terminal development had some rudimentary support of such functionality for ...

On Mon, Apr 15, 2013 at 6:21 AM, Axel Dörfler axeld@xxxxxxxxxxxxxxxx wrote: Given how that object's being used, I'm somewhat unclear on why it's a BReferenceable subclass at all, since that seems a bit unsafe for a statically allocated object. The BReferenceable is in fact not used there to destroy the object, but only to keep the module loaded in the first place as long as it is in use. ...

On April 15, 2013 at 2:45 AM Rene Gollent anevilyak@xxxxxxxxx wrote: Found and corrected that problem. This gets the boot to the point of starting net_server, which then also panics the BReferenceable code by virtue of this: Given how that object's being used, I'm somewhat unclear on why it's a BReferenceable subclass at all, since that seems a bit unsafe for a statically allocated object. ...

On 4/14/13, Ingo Weinhold ingo_weinhold@xxxxxx wrote: to skip the debugger call when get_thread_info() fails. OTOH it is worth checking why the heuristic doesn't work in this case, since neither resume_thread() nor the Signal destructor seem to use a lot of stack. Found and corrected that problem. This gets the boot to the point of starting net_server, which then also panics the BReferenceable code by virtue of this: ...

On Sun, Apr 14, 2013 at 6:10 PM, Ingo Weinhold ingo_weinhold@xxxxxx wrote: Since get_thread_info() for the current thread normally cannot fail, if a pointer to valid storage for the thread info is provided, the easiest solution is probably to change the code in the BReferenceable destructor to skip the debugger call when get_thread_info() fails. OTOH it is worth Will do that, was afraid of potentially allowing valid failures to pass through by doing so but that shouldn't be an issue if that's correct. ...

On 04/14/2013 10:58 PM, Rene Gollent wrote: On 4/14/13, Matt Madia mattmadia@xxxxxxxxx wrote: Deleted referenceable object with non-zero ref count. After some further debugging with Matt, the problem is as follows: ...

On 4/14/13, Matt Madia mattmadia@xxxxxxxxx wrote: Deleted referenceable object with non-zero ref count. After some further debugging with Matt, the problem is as follows: The check for a ref count of 1 + object on the stack fails to correctly detect that the object is in fact a stack object, because we're either unable to get thread_info, or the info object returned has stack_base and stack_end set to 0, which of course causes us to be unable to determine that the object is in the thread's stack range. ...

On 4/14/13, Ingo Weinhold ingo_weinhold@xxxxxx wrote: On 04/14/2013 06:08 PM, Matt Madia wrote: Any suggestions on what to try next? Enter sc. ;-) *cough* I've gotten too used to kdebug automatically running a default command. :-) ...

On 04/14/2013 06:08 PM, Matt Madia wrote: On 2/6/12, Ingo Weinhold ingo_weinhold@xxxxxx wrote: On 2012-02-06 at 02:52:02 [+0100], Matt Madia mattmadia@xxxxxxxxx wrote: Today, I tried booting a DEBUG=1 image. It failed miserably. To the point where it won't even allow me to enter the boot menu options screen or output any serial debug information. ...

On 2/6/12, Ingo Weinhold ingo_weinhold@xxxxxx wrote: On 2012-02-06 at 02:52:02 [+0100], Matt Madia mattmadia@xxxxxxxxx wrote: Today, I tried booting a DEBUG=1 image. It failed miserably. To the point where it won't even allow me to enter the boot menu options screen or output any serial debug information. This sounds like an issue very early in the boot process. Maybe even in the stage 1 boot loader. IIRC since I wrote it a few people changed the code also with respect to debugging. I don't know its current state. It may not even ...

Hello! I think You should also put this information on the haiku-os.org forum. Not everyone subscribes the mailing list. Haiku General Mailing List is probably the better place for this type of information Unfortunately, I know poorly English language and now I write for haiku- os.pl. ...

Good morning. I am the Assistant Systems Admin, Assistant Editor and Staff Writer for Unixmen.com. We are a computer and technical based website which publishes Unix and Linux related content. We have increased our web presence over the past 12 months to a point where we and are currently seeking the assistance of new freelance technical writers. We are seeking specifically someone who has the time to contribute to the website and write about Haiku. It would be a chance for the writer to freely express their views and opinions on Haiku and also increase media exposure for the Haiku project. ...

Am 09/04/2013 16:03, schrieb Philippe Houdoin: Does our stage2 boot_loader needs to know anything about GPT to locate Haiku and the kernel image? I'm not entirely sure about it, but I think it does. Luckily, it should already have that support build in. ...

2013/4/9 Philippe Houdoin philippe.houdoin@xxxxxxxxx: Regarding EFI boot mode, I'm following your branch, Fredrik, but I understand that it's not ready and, there, needs to add boot_loader EFI platform support, which will interface with the EFI system. I've investigated what needs to be done and experimented a bit with the linking, but so far I havn't had time to sit down and code on anything more (and atm it's only second on my todo list). ...