Jan passed away
Diego Mainou
Diego.Mainou at alumni.uts.edu.au
Sat Mar 30 18:38:39 PDT 2013
Dirk,
I heard on Facebook.
Both of us use the OSTC mk2 computer and the shearwater predator ccr
controller and dice a JJ-CCR.
We've never met in person but used to talk now and then on how to
contribute to the various projects (subsurface and OSTC)
D
On 31/03/2013 8:25 AM, <subsurface-request at hohndel.org> wrote:
> Send subsurface mailing list submissions to
> subsurface at hohndel.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
> or, via email, send a message with subject or body 'help' to
> subsurface-request at hohndel.org
>
> You can reach the person managing the list at
> subsurface-owner at hohndel.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of subsurface digest..."
>
>
> Today's Topics:
>
> 1. Re: Jan passed away (Dirk Hohndel)
> 2. Re: Thought about a Qt port (Lubomir I. Ivanov)
> 3. Re: Thought about a Qt port (Thiago Macieira)
> 4. Re: Move to Qt? (Alberto Mardegan)
> 5. Re: Thought about a Qt port (Lubomir I. Ivanov)
> 6. Re: Move to Qt? (Linus Torvalds)
> 7. Re: Thought about a Qt port (Alberto Mardegan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 30 Mar 2013 12:51:29 -0700
> From: Dirk Hohndel <dirk at hohndel.org>
> To: Henrik Brautaset Aronsen <subsurface at henrik.synth.no>,
> <Diego.Mainou at alumni.com.au>
> Cc: subsurface at hohndel.org
> Subject: Re: Jan passed away
> Message-ID:
> <13dbcdab870.2747.56b47ea4a24d1c5a000e92dcca3c60d5 at hohndel.org>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Heart breaking. I just can't believe it. Where did you hear it?
>
> /D
>
>
>
> On March 30, 2013 11:52:43 AM Henrik Brautaset Aronsen
> <subsurface at henrik.synth.no> wrote:
> > dmainou at gmail.com wrote:
> > >
> > > Don't have any details other than he's gone.
> > >
> > > RIP my friend.
> > >
> >
> > I assume you are talking about Jan Schubert? That is terrible terrible
> > news.
> >
> > Rest in peace, Jan.
> >
> > -Henrik
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.hohndel.org/pipermail/subsurface/attachments/20130330/e508ebb3/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 30 Mar 2013 22:03:54 +0200
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> To: Thiago Macieira <thiago at macieira.org>
> Cc: subsurface at hohndel.org
> Subject: Re: Thought about a Qt port
> Message-ID:
> <
> CAGDbWi90wsVZuXmjdXvwSRWFsjGoT78XywjAmq1Qsgd_Tuykug at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 30 March 2013 20:37, Thiago Macieira <thiago at macieira.org> wrote:
> > On s?bado, 30 de mar?o de 2013 10.40.50, Dirk Hohndel wrote:
> >> > For Windows, I'd recommend building yourself. The current binary
> downloads
> >> > are for hosted builds, plus the MinGW folks can't make up their minds
> >> > about what ABI to use.
> >>
> >> Bleh. Not having a stable MinGW build really hurts me. Maybe we can
> >> engage with them while we do this and help figure this out?
> >
> > Trust me, I have. I have knocked heads on this problem before and I've
> even
> > said anyone still using SJLJ exceptions should be taken out and shot
> (Linus
> > would've called them morons). And lo and behold! the Qt 5.0.1 MinGW
> binaries
> > we produced used SJLJ and within a week we got bug reports of extreme
> > performance regressions.
> >
> > I won't bother you with details. This is being taken care of and should
> much
> > improve with GCC 4.8 released.
> >
> > Moreover, it does not affect Subsurface. Whichever exception ABI is
> chosen, it
> > will work with Qt and the Windows installation will bring in all the
> necessary
> > libraries anyway.
> >
> > PS: I think the Fedora cross-mingw build uses SJLJ ? performance
> problems.
> >
>
> out of curiosity - are you shooting for a Mingw with SEH (if that even
> works yet in 4.8 with the TIBs and the handler linked lists and such)
> or DW2 to be distributed with the next (perhaps 5.1 minor) release?
> though, if DW2 is chosen i remember there were some issues with that
> and how the WINAPI works, but i could be wrong.
>
> also, there were some nice improvements in ABI compatibility with MSVC
> in 4.8 (or was it back in 4.7), but a combo of C++ virtual functions
> and some varargs (cdecl x86) really got the best out of it, so i gave
> up testing further at that point. i think it was early 2012...
>
> lubomir
> --
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 30 Mar 2013 13:07:37 -0700
> From: Thiago Macieira <thiago at macieira.org>
> To: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> Cc: subsurface at hohndel.org
> Subject: Re: Thought about a Qt port
> Message-ID: <1935714.6u4s31lTar at tjmaciei-mobl2>
> Content-Type: text/plain; charset="utf-8"
>
> On s?bado, 30 de mar?o de 2013 22.03.54, Lubomir I. Ivanov wrote:
> > > Moreover, it does not affect Subsurface. Whichever exception ABI is
> > > chosen, it will work with Qt and the Windows installation will bring in
> > > all the necessary libraries anyway.
> > >
> > > PS: I think the Fedora cross-mingw build uses SJLJ ? performance
> problems.
> >
> > out of curiosity - are you shooting for a Mingw with SEH (if that even
> > works yet in 4.8 with the TIBs and the handler linked lists and such)
> > or DW2 to be distributed with the next (perhaps 5.1 minor) release?
> > though, if DW2 is chosen i remember there were some issues with that
> > and how the WINAPI works, but i could be wrong.
>
> Anything as long as it's not SJLJ. I think it's stupid to try and throw
> exceptions through the Windows kernel C API, so that functionality is not
> required for Qt. Therefore, DW2 is a good solution for us. I'm told SEH
> will
> with with GCC 4.8, though.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> URL: <
> http://lists.hohndel.org/pipermail/subsurface/attachments/20130330/5b2d7ba1/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 4
> Date: Sat, 30 Mar 2013 22:43:39 +0200
> From: Alberto Mardegan <mardy at users.sourceforge.net>
> To: subsurface at hohndel.org
> Subject: Re: Move to Qt?
> Message-ID: <51574E7B.5040903 at users.sourceforge.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 03/30/2013 07:57 PM, Amit Chaudhuri wrote:
> > I think the guy on the link was trying to say he's had issues with
> > deployment of Qt apps when using dynamic libraries.
>
> If the link is this one:
>
> > Here's an interesting post that was pointed out to me. More food for
> > thought.
> >
> > http://blog.mardy.it/2012/05/from-g-to-q.html
>
> Than "that guy" (which is me :-)) can elaborate a bit. :-)
> I didn't have issues with shared libraries; I was just discouraging
> people from starting learning Qt by writing a wrapper to a GObject based
> library, because there isn't a 1-1 correspondence between QObject and
> GObject; sometimes you just have to do things in a very different way,
> and trying to map the paradigms from GObject to QObject can just get you
> frustrated.
>
> I don't think this applies to Subsurface; as far as I can see, there
> isn't even a single GObject subclass being defined in the code.
>
> Ciao,
> Alberto
>
> --
> http://blog.mardy.it <- geek in un lingua international!
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 30 Mar 2013 22:54:05 +0200
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
> To: Thiago Macieira <thiago at macieira.org>
> Cc: subsurface at hohndel.org
> Subject: Re: Thought about a Qt port
> Message-ID:
> <
> CAGDbWi9dfxW_dsQ4BuY03oA8sWOWJ2QnD-WpAfhRVnXKYDJ49A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 30 March 2013 18:38, Thiago Macieira <thiago at macieira.org> wrote:
> > On s?bado, 30 de mar?o de 2013 07.20.50, Dirk Hohndel wrote:
> >> We don't use autotools now, we won't move to them for a Qt build. Right
> >> now we have a hacked together Makefile that does a lot of fun things for
> >> us.
> >>
> >> I have never tried to use qmake but hear even less love for it than for
> >> autotools (and that is saying a lot). Maybe we can start with qmake for
> >> the initial exploration / prototype and as we move towards a first
> >> buildable version that maps out the UI and links it with the existing
> >> logic we can revisit this question as well?
> >
> > I took a look at it and I'd propose the following:
> > - hack the Makefile a little more and give it basic Qt support
> > - in parallel, if someone is interested, try porting to qmake
> >
> > Adding basic C++ and Qt support to the Makefile isn't difficult. Adding
> support
> > for Qt resource files is also trivial, if that feature is ever needed.
> Support
> > for moc and uic can be done, but without a good dependency scanner,
> subsurface
> > will have to obey some strict rules about where the #includes can be
> placed
> > for the generated files. Or manually adjust the Makefile to declare the
> > dependencies.
> >
> > qmake is easy to use and good at *building*, but not at *detecting*
> stuff. If
> > you have hard dependencies you just want to use, qmake can do it. To
> detect,
> > the code will be a great deal uglier. Even for installation, it might be
> ugly.
> >
> > In fact, maybe the ideal solution is hybrid: leave the current Makefile
> for
> > detecting and installing, but ask qmake to generate another Makefile for
> > building. Or if we can get the install rules working with qmake, create a
> > simple configure script.
> >
>
> my understanding of qmake is bit limited, but i think the hybrid
> solution sounds good.
> - we distribute some sort of a default .pro file.
> - we leave the compiler/linker stage to qmake and the Makefile it
> generates, but there is a default Makefile that handles dependencies
> and install
> - pulling the repo and calling `make` would call the default Makefile,
> which will gather what is available and (for example) SED into the
> .pro file the macros libs and lib headers if possible
> - qmake -o Makefile.qmake will then be called generating the
> compile/link makefile, and then Makefile.qmake can be called with
> `make -f` again from that main Makefile rule
>
> not sure how well will that work though...
>
> also i would like to point out that for the native Win32 build of
> Subsurface i'm not using POSIX shell commands and pkg-config at all,
> but a custom Makefile.win32 that has a bunch of paths hardcoded and
> works with `cmd.exe`. i find the use of pkg-config pointless on Win32
> given there are no real package managers except the one for cygwin
> (which is kind of good) and also for the fact a lot of libraries
> simply do not distribute .pc files for something like the MSYS shell,
> so one has to write his own. so checking if a -dev package is
> available on Win32 is a non-trivial in my experience.
>
> lubomir
> --
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 30 Mar 2013 14:04:39 -0700
> From: Linus Torvalds <torvalds at linux-foundation.org>
> To: Alberto Mardegan <mardy at users.sourceforge.net>
> Cc: Subsurface Mailing List <subsurface at hohndel.org>
> Subject: Re: Move to Qt?
> Message-ID:
> <CA+55aFyjt9Pg_dkyNFxRWgb_RNSvKJK=OL-S985gp=
> bNz8OUFg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Sat, Mar 30, 2013 at 1:43 PM, Alberto Mardegan
> <mardy at users.sourceforge.net> wrote:
> >
> > I don't think this applies to Subsurface; as far as I can see, there
> > isn't even a single GObject subclass being defined in the code.
>
> Yeah, we've tried to avoid unnecessary linkages with GLib. We use the
> GTK GUI parts, and we use a *very* small subset of the "pure GLib"
> stuff (ie some utf8 stuff and things like g_ascii_strtod and a
> filesystem accessor helper or two), but we don't really build around
> either.
>
> In fact, I spent some time removing as much GLib and GTK data
> structure use as possible. We had some GList use that just complicated
> things unnecessarily, and we had a fair amount of code that worked by
> traversing and modifying the GTK data structures (using the treeview
> stuff to track the dive trip <-> dive relationships etc), and almost
> all of that got rewritten. So now we just maintain our own simple data
> structures and then basically redraw everything from scratch when they
> change.
>
> Re-creating the whole divelist from scratch might not scale well with
> millions of dives, but happily, even if you're a dm in Hawaii it's
> fairly hard to do more than a thousand dives a year. A ten thousand
> dives over a lifetime is already considered quite a lot. And it's not
> like we need to do it for things like "scroll through the list and
> select a dive", only for "add/delete dives" or "move a dive from/to a
> divetrip" etc.
>
> We could probably re-organize some of our sources better, so that we'd
> have a clearer separation between the UI code and the code that just
> works on our our data structures. divelist.c in particular is a mix of
> "pure gtk stuff" and "completely non-gtk stuff" partly due to the
> history of doing the trip handling in particular using the treeview
> data structures. There's a smattering of that elsewhere too, but
> divelist.c is the worst offender.
>
> Linus
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 30 Mar 2013 23:25:35 +0200
> From: Alberto Mardegan <mardy at users.sourceforge.net>
> To: subsurface at hohndel.org
> Subject: Re: Thought about a Qt port
> Message-ID: <5157584F.1060509 at users.sourceforge.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 03/30/2013 07:40 PM, Dirk Hohndel wrote:
> > Someone else brought up this issue with respect to picking Qt5 over
> > Qt4...
> >
> > We want to be able to support at least the following distros:
> > Fedora (under support, currently 17/18)
> > openSUSE (under support, 12.1-12.3)
> > Ubuntu (12.04, 12.10, 13.04)
> > Debian (Squeeze, Wheezy - we actually dropped Squeeze support for a
> > while - so that's not quite as critical as Wheezy will be out before we
> > are ready).
> >
> > I don't think Qt5 is available for all those, is it?
>
> In Ubuntu 12.04 it's available under a PPA, in the others it should be
> already available.
> Anyway, I agree we can support Qt4 as well.
>
> Here's how I'd do it:
>
> https://github.com/mardy/subsurface/commit/407e8e831f6b75d4d27a54224b1429f72dcab586
>
> We require the developer to have the Qt bin/ directory in the path, and
> then we ask qmake about the Qt version; depending on that, we pick
> different pkg-config modules (it may be that more things will have to
> end up in that if/else switch, in the future).
>
> [...]
> >> Adding basic C++ and Qt support to the Makefile isn't difficult. Adding
> support
> >> for Qt resource files is also trivial, if that feature is ever needed.
> Support
> >> for moc and uic can be done, but without a good dependency scanner,
> subsurface
> >> will have to obey some strict rules about where the #includes can be
> placed
> >> for the generated files. Or manually adjust the Makefile to declare the
> >> dependencies.
>
> Thiago, I would simply go for declaring the dependencies in the
> Makefile. Something like:
>
> OBJS = main.o ... qt-class.o qt-class.moc.o
>
> and then have a rule
>
> %.moc.cpp: %.h
> @echo ' MOC' $<
> @$(MOC) $< -o $@
>
> (I didn't try this, but it should work)
>
>
>
> Changing topic: currently, there are three files which are used to
> implement the functions which read/write the application settings:
> linux.c (GConf)
> windows.c (registry)
> macos.c (CFPreferences)
> Do we want to keep them, or use the QSettings class [0]? QSettings uses
> the Windows Registry in win32 and the CFPreferences API in OSX, and I
> believe it should be possible to configure the paths in such a way to
> match the current ones. However, in Linux it uses plain .ini files (by
> default, stored under ~/.config/<company>/<application>.conf, IIRC, but
> it can be changed).
> Given that subsurface isn't sharing its data with other applications, I
> don't see a strong reason to prefer using GConf (or GSettings) to
> ~/.config/subsurface.conf; however, we'd need to address the problem of
> migrating the existing user's configuration there (*if* it is a problem;
> maybe we can just apologize and ask the Linux users to reconfigure the
> app?).
> This probably is a bit premature, but it can have an impact on how the
> UI stores the configuration (in any case the C API in pref.h would stay,
> if it's used by other C files).
>
> Ciao,
> Alberto
>
> [0] http://qt-project.org/doc/qt-4.8/qsettings.html
>
> --
> http://blog.mardy.it <- geek in un lingua international!
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
> ------------------------------
>
> End of subsurface Digest, Vol 16, Issue 152
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130331/32d47ec2/attachment-0001.html>
More information about the subsurface
mailing list