SleepyHead: Updated Version 0.7-4229 Alpha

[Breathe Jimbo]

One step closer to a Mac solution. ResMed data to follow soon (now I'm on the hook for sure).

Yee-hah!

[jedimark]

Mmmmmmm. Sexy Mac build... Soo shiny..

Ahem.. I digress.

The Bug & Feature Request system on sourceforge should now be ready to go. Anyone is welcome to use this, although you'll probably need to sign up for a SourceForge ID if you don't have one.
Please report your build number (in the titlebar) when filing a bug (and please be descriptive, tell us what you were doing when it broke/whatever, and check first someone else hasn't already reported it)

Also in the process of setting up a Help forum on Sourceforge. Though CPAPTalk will always be a great (the best?) place to ask for help.. Just put "SleepyHead" for now in your posts title so we can see it

We now have a functioning developer mailing list for those who are interested in following development.
Note: This developer mailing list is not meant for compiler/wxWidgets set-up assistance, or even asking about how to actually use the program.
It's primary purpose is for discussing development issues, wrangling out bugs, and sorting out build problems with officially supported platforms.
Troy and myself reserve the right to ignore, flame and generally not be super nice to those who ignore this warning and post off-topic to it.

If you consider yourself reasonably experienced at testing software and are using the windows binary builds, or your building your own copy from source, you are very welcome to join this list.
(You will get notified of and sometimes asked to test extra buggy development versions.)

Can find all this stuff under
https://sourceforge.net/projects/sleepyhead/

We will keep you up to date with major developments, and post notices about hopefully slightly more polished updates in this thread from now on..

[Breathe Jimbo]

If you consider yourself reasonably experienced at testing software and are using the windows binary builds, or your building your own copy from source, you are very welcome to join this list.
(You will get notified of and sometimes asked to test extra buggy development versions.)

What is the difference between watching the list and monitoring it?

P.S. Never mind; I see that subscribing is different.

[jedimark]

If you consider yourself reasonably experienced at testing software and are using the windows binary builds, or your building your own copy from source, you are very welcome to join this list.
(You will get notified of and sometimes asked to test extra buggy development versions.)

What is the difference between watching the list and monitoring it?

If you monitor it by subscribing, it will go to your email address.. if you just read the digests via sourceforge, well, you'll have to keep coming back for updates.

Anyone who's genuinely interested in the nerdy developer chatter can subscribe and join in (as long as it's relevant to development, bug-fixing, etc).

I just don't want the developer mailing list getting flooded with so many Help Me requests, it drowns out the important stuff. There's are just better places to ask for help and stuff (Like here)

If all you want is updates and a little inside scoop, this thread right here will probably suffice.

[Breathe Jimbo]

BTW, "SleepyHead" is a great name!

[jedimark]

BTW, "SleepyHead" is a great name!

It's more a project code name at the moment.

It was the name of my first Python & early C++ project. Since I joined forces with Troy it's only fair we get a shot at a new name.

It's our intention to have a poll, and you guys get to vote on the final name.

[Breathe Jimbo]

I just heard back from the maintainer of the wxwidgets available through MacPorts.

This was my question:

Although wxWidgets is available through MacPorts, there is some confusion as to whether their project will require something DIFFERENT called wxMac. See, e.g., http://www.wxwidgets.org/docs/faqmac.htm It would be greatly appreciated if you would clarify whether the wxWidgets available through MacPorts is the same as, or different from, "wxMac."

This is his answer:

Hi,
the current port is the same, it is configured with Carbon (argument "--with-mac"). The future versions, though, are able to use Cocoa (from 2.9.1 on). The problem with the 2.8.12 version (and port) is that it doesn't support 64-bit operations (due to Carbon).

[Breathe Jimbo]

here is a teaser - the application built and running on the Mac

Any chance I could try starting your binary on my Mac, to see whether it runs with wxwidgets built and installed via MacPorts? I don't expect to do anything with it at this point. Just curious whether my use of MacPorts makes any difference.

[tschultz]

here is a teaser - the application built and running on the Mac

Any chance I could try starting your binary on my Mac, to see whether it runs with wxwidgets built and installed via MacPorts? I don't expect to do anything with it at this point. Just curious whether my use of MacPorts makes any difference.

I have both 2.8.12 and 2.9.1 on my Mac.

I've been working on the Mac stuff and there are some more changes needed to handle some of the OSX specific differences which I am working my way through. This is one of those cases where a successful compile does not give a fully working application. For now I am concentrating on a 32 bit build using wxWidgets 2.8.12 as the 2.9.2 version is not yet complete and I had ran into other problems a few weeks back when I tried it.

I have updated the GIT Repo with a project, using the CodeLite IDE instead of CodeBlocks, which will build and create an OSX compatible application bundle than can be ran. At present data does not load yet however so there is not much you can do with it. I will update the Repo as I make progress cleaning up things I find.

[Breathe Jimbo]

The standard git command to pull the source code from the repository (used in a Terminal)

Code: Select all

git clone git://sleepyhead.git.sourceforge.net/gitroot/sleepyhead/sleepyhead

Assuming this is still accurate, I got the source and built it in CodeLite. Although the result gave me an error message when I first started it, I was able to ignore further warnings and run the program. Just a basic, empty program window, as you showed.

Here is a screen capture: https://files.me.com/louiexiv/uyznsh

I see that the information bar at the bottom of the SleepyHead window says "wxWidgets 2.8.8-Mac-Unicode build." However, I have 2.8.12 installed. Is 2.8.8 an outdated reference in one of the source files?

P.S. 2.8.8 is the version that OS X installed on my system as the default.

[jedimark]

Jimbo: Nope. You will have 2.8.8 installed somewhere on your system. you probably have two installations in separate directories, and the wrong wx-config is being called.

You will need to hunt and purge all traces of wx on your system, and reinstall.

Building from source on just mac isn't ready yet.. it compiles, but needs some mac customisations written for it. Trying at this stage to compile will not make it magically work for you.

Theres nothing wrong with sorting your buildsystem out in the meantime. It will come in handy for you later.

In the meantime, Try Winebottler (an intel mac build of wine), as sleepyhead runs fine in wine..

It's free, and doesn't require any virtualization or windows software/licenses, and doesn't "emulate", so runs very efficiently..

http://winebottler.kronenberg.org/

[tschultz]

I have been able to load PRS1 data into the app on the Mac using the application bundle I built.

I have uploaded a zipped copy of the application to http://sourceforge.net/projects/sleepyh ... p/download if you want to try it.
Please beware however that this has not been extensively tested and hopefully should not destroy the planet when you run it, so feel free to try it and let us know if it works. It was built, and ran, using SnowLeopard 10.6.7 and wxWidgets 2.8.12.

The GIT Repo does contain my lastest code with a project using the CodeLite IDE that will build things assuming your development environment is setup correctly for a wxWidgets application build. Once things settle down for me a bit I'll try and detail what steps are needed to ensure a working development environment.

[jedimark]

An awesome day for the project!

On top of Troy's excellent Mac successes... git source code is now synced between us.

Now we can start doing cool stuff like writing new importers, and plenty of other stuff on our todo lists..

I might push one more windows preview build before we get onto this, showing off the new Events tab in the Daily view. (You Mac testers already get to see this with Troy's work above..)

Now our code runs on Windows, Linux & Mac.. the big 3..

[Breathe Jimbo]

You will need to hunt and purge all traces of wx on your system, and reinstall.

I uninstalled 2.8.12 and 2.9.1 and poked around for 2.8.8. I believe I found it set up as follows:

/usr/include/wx-2.8/wx/ . The files in this directory are almost all .h files, plus very few .cpp files.

/usr/lib/wx/config/mac-unicode-debug-2.8 (executable)

/usr/lib/wx/include/mac-unicode-debug-2.8/wx/setup.h

and a bunch of libwx_macud...dylib files in /usr/lib/ .

I am reluctant to delete everything for fear of breaking programs that may need the dylib files to function properly.

I brought up MacPorts because I was concerned about precisely this kind of conflict.

[jedimark]

Jimbo:

This project is in the alpha stage. I'm kind of hoping people understand the difference between alpha & beta software testing. We're a little bit unconventional with this project, because we have provided a few binary alpha builds, as I feel it's relatively solid enough to do so.

We simply don't have time for developing this software, as well as coaching others to sort their build systems out.. Your certainly welcome to try (this is open source after all,) but we are unable to provide a lot of support for this.
My best advice to you is document what you do, and do a lot of reading.. You'll be up and hacking in no time. If you succeed please put what you did on line.
Troy said he might post a summary of setting up his build system later.. I'm sure he'd much rather get some coding done first though..

At the moment, the Linux platform is much easier to set up a build environment on. Windows and Mac, not so much, so we provide binaries for testers. Please use these in the meantime if your not a build guru yet..