[svlug] qtparted-0.5.0 missing something still...
Michael C. Robinson
plug_1 at robinson-west.com
Sat Nov 28 11:01:45 PST 2015
On Sat, 2015-11-28 at 11:32 +0100, Ivan Sergio Borgonovo wrote:
> On 11/28/2015 04:54 AM, Michael C. Robinson wrote:
> > I am suspecting that there is something wrong with my parted
> > installation. If there is enough information in the attached
> > output to
> > make an educated guess, great. If not, how can I get the
> > information I
> > /home/michael/qtparted-0.5.0/src/qp_libparted.cpp: In member
> > function ‘void QP_LibParted::get_filesystem(QP_FileSystem*)’:
> > /home/michael/qtparted-0.5.0/src/qp_libparted.cpp:718:48: error:
> > ‘PedFileSystemOps’ has no member named ‘create’
> Yeah in fact there are. My suspicion is that qparted is too old or
> libparted is too new and PedFileSystemOps has changed signature as
> may guess from
> Last release of qtparted is 10 years old!!! Last commit to parted has
> > need??? I know adding software to a Linux from scratch system is
> > adding software the hard way, but really there are only 2-3 things
> > left
> > to add that I really want. For educational reasons, I'd like to
> > learn
> > what the problem is at least.
> The problem is you miss basic knowledge on how make and C/C++ works
> you don't know what to google.
> It really makes me wonder what made you believe you could write
> you're a
> C/C++ expert in your CV.
> I'm sorry but this is a reality check.
I studied C/C++ as part of my degree where we didn't go into make
very much. I can write simple make files, but understanding automake,
autoconf, and configure is way beyond what the undergraduate curriculum
covered. You don't have to know how to google from make errors for the
most part to compile packages that are in the book. Of course,
qtparted isn't in the book. I say there is a significant difference
between being able to work with configure, automake, C/C++, and
autoconf verses being able to just code in C/C++ and maybe write a
simple make file. I see nothing wrong with my CV considering that I
don't list autoconf, automake, and configure.
> If you want to improve your diagnostic skills for C/C++ I'd start to
> write simple programs in C/C++ that use libraries and *build*
> No matter how simple the library you may write could be, do it as an
> exercise to understand how linking works and how libraries and
> headers are found.
You can be a good C/C++ programmer and not know how to write libraries.
That is not in the undergraduate curriculum unfortunately.
> Then take some simple program written by someone else that uses
> libraries and examine carefully the source and the make file.
Assuming the make file isn't practically a program full of macros that
I can read, this is reasonable advice. In reality, shell expansion and
other things can happen to make files and they are often too cryptic
for a person to understand them without perhaps seeing a compiled
version of the make file without macros and shell expansions.
> Really write and read far more C/C++ code and try to understand
> what's going on by yourself and as last resort learn to google
> meaningful stuff.
> Rise and repeat.
> Learn how to read compilers errors! As Karen said there may be
> transition period when the support for some new features of a
> is still getting mature and some errors may be cryptic but generally
> these are not the errors you'd find spit out by mature software or by
> things you're writing on your own unless you're experimenting with a
> new standard.
> C and C++ errors are rarely ambiguous unless you're using a pretty
> bad/unfrequently used compiler.
> If you don't understand C and C errors you can't even google them.
> For educational reasons you shouldn't want to know what THIS specific
> problem is, for educational purpose you'd build up enough skills to
> deal with C/C++ and generally how to read and report errors to peer
> programmers, that also means to actually get at least a clue about
> what could be the relevant information related to an error and not
> 10Kb of logs!
Well, first I'm accused of not providing enough information and now too
much information. I don't think 10k of log is too much. If you
don't know what's relevant, you kinda have to include the whole log.
Seems worthwhile to me to learn how to determine if a package is being
maintained or not when working with the source code for it.
I've never seen a google manual. That I get anything out of google I'd
say is pretty decent considering.
> oh and if you think I'm a presumptuous disrespectful bastard that is
> just taking joke of you, that's your MAIN problem.
How does that last statement convince me that the rest is worth
reading? How does this convince me that anything you say is worth
reading if I can get it from someone else who is more professional in
how they address me? Okay, so I'm less than a novice when it comes to
make, writing libraries, system programming in general, automake,
autoconf, and configure. I never claimed on my CV to have any
understanding of automake, autoconf, writing libraries, system
programming, or configure. I only claimed to have C/C++ skill.
More information about the svlug