[haiku] Re: Willing to work for your project.(George)

  • From: George zhao <raimann.zhao@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Fri, 25 Mar 2011 10:47:26 -0400

Hi Stephen,

Thanks for your reply, seems these two ways both work on me at some point.

> Depending on what you are doing, different models of development have better
> turn around times.
> When developing a GUI app, or even a driver that can be dynamically reloaded
> for each test run, developing directly in Haiku can give the quickest turn
> around times. The development tools in Haiku are the Pe editor, the command
> line, GDB, Kernel Debugging Land and printf or syslog debug output. The PPP
> module might be such a situation, but Philippe would know best from working
> on it recently.

Thanks for talking about the PPP debugging model. Since I saw the
docs, there is sshd and ftpd supporting in the current release, I hope
I can setup a remote access to another device in my lab. Since I am
using a Mac, and I haven't figure out the way to dual-boot Snow
Leopard and Haiku. I believe bootcamp doesn't support it.

By ssh to a remote one and ftp file to it will solve the most problem,
after all, what I need is just a command line environment. These
combination will be good enough. For the GDB+Kernel Debugging land
part, is there any Haiku docs online, which is wrote for this issue
now? Maybe I can learn it from that. Thanks.

> Another possibility is to run Haiku in a VM. The build system supports the
> "update" feature. It can be configured quite extensively. Suppose you have a
> jam target "ppp", then you can update the Haiku image with "jam
> @your_vm_profile update ppp". This will be very quick. "ppp" can be a pseudo
> target and update multiple files on the image. Then you just have to live
> with the time it takes to reboot Haiku in the VM.
> In any case, going back to the first scenario, when you develop a driver in
> Haiku, and you exchange the binary of the driver at its install location,
> the kernel will know it has updated. When your test application (re)opens
> the driver, it will use the new version.

If the remote access way doesn't work out, I think this way will be
definitely applicable, which I guess is supported by most platform
development. Since I just tried the ISO setup in VM, that takes almost
no time to reboot. So that couldn't be a problem. The thing is just
come to the test part, I think we need to reconfigure the system in
some testing scenario. Don't have time to try to load the image file
in VB, I will do it later today or tomorrow, to quickly go through a
whole process with this ASAP.

> If any of this was confusing, don't hesitate to ask for more details... :-)
> Best regards,
> -Stephan

Thanks again for replying my msg, and have a good one!

Other related posts: