Re: [gentoo-user] package.keywords syntax?
On Thu, Oct 30, 2008 at 9:12 PM, Jorge Peixoto de Morais Neto [EMAIL PROTECTED] wrote: It seems you did not get the point. To attribute a floating point number to an integer variable is perfectly valid, depending on the specific program. The compiler normally does not even warn about this, as this is perfectly valid (from my testing, the compiler only warns if you are using gcc 4.3, and specify -Wconversion, an option that is not included in -Wall and not even in -Wextra). Yes, you are right. I was doing what some people would like to call speaking out of my ass :) C++ compiled with gcc does give you a warning with -Wall. I just assumed that C did the same, its been some time since I coded pure C. Regards Dirk
Re: [gentoo-user] package.keywords syntax?
On Thu, Oct 30, 2008 at 9:11 PM, Albert Hopkins [EMAIL PROTECTED] wrote: I'm coming into this thread kinda late, so feel free to ignore... ... but Jorge is right. This is easily picked up by a lint tool... and good python programmers use them ;-). Some python-aware editors even have this functionality built in. Using the above example: $ pylint who_no.py ... C: 1: Missing docstring C: 5: Comma not followed by a space for i in range(1,1): ^^ E: 8: Undefined variable 'malformed' E: 8: Undefined variable 'beast' Thanks, that sounds like a utility i may use in the future. I don't like having to use a separate tool to make sure I didn't perhaps make a typo while typing some variables name, but I find python useful enough to oversee that. Regards Dirk
Re: [gentoo-user] package.keywords syntax?
On Wed, Oct 29, 2008 at 10:13 PM, Jorge Peixoto de Morais Neto [EMAIL PROTECTED] wrote: The real problem is when you type float real_number = 4e10; int integer = real_number; If your integer can only hold values up to 2^31 - 1 , the behavior of the above code is undefined. In a language like Python, everything either behaves as you intended, of throws an exception. This is why I say In C, you must completely understand the behavior of every statement or function, and you *must* handle the possibility of errors. The line: int integer = real_number; will produce a warning. (or an error if you are smart enough to compile with -Werror) But, if you know that the real number will be small enough and you don't mind getting the floor of the float, you may wish to ignore the error. Like mr McKinnon said, c will allow you to do wrong things. Depending on what you are doing, the babysitting of python, may or may not be a problem. One thing I would like to know (not knowing python that well), is when you make an error in python, when will the exception be thrown? At the start of run-time, or when the guilty code is encountered? And what if that code is in a codebranch that gets executed 0.0005% of the time? Regards Dirk
Re: [gentoo-user] package.keywords syntax?
To back myself up: file name=why_no.py #!/usr/bin/python import random for i in range(1,1): if random.random() 0.001: print rare if malformed beast: print kick me in the ... else: print whatever /file Regards Dirk
Re: [gentoo-user] package.keywords syntax?
To back myself up: file name=why_no.py #!/usr/bin/python import random for i in range(1,1): if random.random() 0.001: print rare if malformed beast: print kick me in the ... else: print whatever /file This kind of error is not a syntax error; this kind of error is indeed only discovered at runtime. However, syntax errors are discovered at byte-compile time. byte-compile happens automatically when you load a module, but you can perform it yourself easily, and this is recommended in certain situations. For this kind of error (try to reference an undefined variable), there are tools like pychecker. -- Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] package.keywords syntax?
On Thu, 2008-10-30 at 16:54 -0200, Jorge Peixoto de Morais Neto wrote: To back myself up: file name=why_no.py #!/usr/bin/python import random for i in range(1,1): if random.random() 0.001: print rare if malformed beast: print kick me in the ... else: print whatever /file This kind of error is not a syntax error; this kind of error is indeed only discovered at runtime. However, syntax errors are discovered at byte-compile time. byte-compile happens automatically when you load a module, but you can perform it yourself easily, and this is recommended in certain situations. For this kind of error (try to reference an undefined variable), there are tools like pychecker. I'm coming into this thread kinda late, so feel free to ignore... ... but Jorge is right. This is easily picked up by a lint tool... and good python programmers use them ;-). Some python-aware editors even have this functionality built in. Using the above example: $ pylint who_no.py ... C: 1: Missing docstring C: 5: Comma not followed by a space for i in range(1,1): ^^ E: 8: Undefined variable 'malformed' E: 8: Undefined variable 'beast'
Re: [gentoo-user] package.keywords syntax?
The real problem is when you type float real_number = 4e10; int integer = real_number; If your integer can only hold values up to 2^31 - 1 , the behavior of the above code is undefined. In a language like Python, everything either behaves as you intended, of throws an exception. This is why I say In C, you must completely understand the behavior of every statement or function, and you *must* handle the possibility of errors. The line: int integer = real_number; will produce a warning. (or an error if you are smart enough to compile with -Werror) It seems you did not get the point. To attribute a floating point number to an integer variable is perfectly valid, depending on the specific program. The compiler normally does not even warn about this, as this is perfectly valid (from my testing, the compiler only warns if you are using gcc 4.3, and specify -Wconversion, an option that is not included in -Wall and not even in -Wextra). So erase this *wrong idea* that attributing floating-point value to an integer variable is invalid or even just unwise. There is nothing generally wrong with it. The point is: in certain situations, the behavior is well-defined and unsurprising. What happens, though, if (for example) the value of the floating-point variable is too big for the int? In a forgiving language, you would either have a sensible behavior (such as the int receiving a INT_MAX value) or an error. In C the behavior is *undefined*. Got the point? In C, you *must* know what you are doing, and *must* handle the possibility of errors. If not, your program is not even garanteed to crash; it can, after an error, go on working (erratically), possibly damaging user data or yielding subtly wrong results without any warning. -- Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] package.keywords syntax?
On Wednesday 29 October 2008 00:55:42 Jorge Peixoto de Morais Neto wrote: I mean to really know C, that is, read a rigorous book such as C: A Reference Manual and be able to write portable programs with well-defined behavior. Speaking of well-defined behavior, do you know what happens when you cast a float to an int, and the float is too big to fit into the int? Did oyu try it yourself and see? The point is that the behavior in this situation is undefined. It might do anything. Programming in C is different than programming in Python. Most likely the compiler will try to treat the float as an int and use the first 4 bytes of the float, ignoring the rest. This is insane though. I cannot think of any reason why one would ever want to treat the first 32 bits of a float as an int. It's not like you are casting a long to an int which can make sense - just discard the high bits. I reckon the standard would say this is undefined. Most compiler would bomb out with a compile error but give you an obscure flag to proceed anyway. If you want to commit suicide, C is quite happy to pass you the pills as long s you ask nicely -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] package.keywords syntax?
On Wed, Oct 29, 2008 at 3:16 AM, Alan McKinnon [EMAIL PROTECTED] wrote:
On Wednesday 29 October 2008 00:55:42 Jorge Peixoto de Morais Neto wrote:
I mean to really know C,
that is, read a rigorous book such as C: A Reference Manual and be
able to write portable programs with well-defined behavior. Speaking
of well-defined behavior, do you know what happens when you cast a
float to an int, and the float is too big to fit into the int?
Did oyu try it yourself and see?
The point is that the behavior in this situation is undefined. It
might do anything. Programming in C is different than programming in
Python.
Most likely the compiler will try to treat the float as an int and use the
first 4 bytes of the float, ignoring the rest.
Float is 4 bytes; the questions should be reworded s/float/double/g
But somehow, SSE version or fisttp (or whatever) doesn't set CF/OF on
overflow, the returned int is simply (1 31) ^ (1 31 - 1)
This is insane though. I cannot think of any reason why one would ever want to
treat the first 32 bits of a float as an int. It's not like you are casting a
long to an int which can make sense - just discard the high bits.
I reckon the standard would say this is undefined. Most compiler would bomb
out with a compile error but give you an obscure flag to proceed anyway. If
you want to commit suicide, C is quite happy to pass you the pills as long s
you ask nicely
gcc does this without errors
Code [x86/64 only]:
#include stdio.h
#include math.h
#include stdint.h
int main() {
double f = 1.5e99;
int i = (int)f;
uint16_t z;
asm(pushf; popw %0; : =r(z));
printf(%d %d %d\n, i, (z (1 11)), (z 1) );
return 0;
}
In short, your mileage shall vary, so sayeth the standard.
--
--
Andrey Vul
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Re: [gentoo-user] package.keywords syntax?
I mean to really know C, that is, read a rigorous book such as C: A Reference Manual and be able to write portable programs with well-defined behavior. Speaking of well-defined behavior, do you know what happens when you cast a float to an int, and the float is too big to fit into the int? Did oyu try it yourself and see? The point is that the behavior in this situation is undefined. It might do anything. Programming in C is different than programming in Python. Most likely the compiler will try to treat the float as an int and use the first 4 bytes of the float, ignoring the rest. No, you misunderstood C. C, despite being lower level than (say) Java, does not view variables as typeless bit patterns. It views them as integers, real numbers, etc. So if you perform float real_number = 0.5; int integer = real_number; The value of integer will be 0; if C were to actually interpret the bit pattern of real_number as an integer, you would get 1056964608 (0x3f00) - at least on my machine. That is not what C does, though. The real problem is when you type float real_number = 4e10; int integer = real_number; If your integer can only hold values up to 2^31 - 1 , the behavior of the above code is undefined. In a language like Python, everything either behaves as you intended, of throws an exception. This is why I say In C, you must completely understand the behavior of every statement or function, and you *must* handle the possibility of errors. -- Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] package.keywords syntax?
On Tue, 28 Oct 2008 18:07:35 +0100 (CET), Helmut Jarausch wrote: Is it possible to revoke this for whole bunch of packages like kde-base/* I've tried the following line in /etc/portage/package.keywords kde-base/* -~amd64 If you are trying to prevent KDE4 installing, it is better to put kde-base/kde-meta:4.1 in /etc/portage/package.mask -- Neil Bothwick Modesty Becomes You. Try It More Often. signature.asc Description: PGP signature
Re: [gentoo-user] package.keywords syntax?
On Tue, Oct 28, 2008 at 1:07 PM, Helmut Jarausch [EMAIL PROTECTED] wrote: Hi, I have ACCEPT_KEYWORDS=~amd64 in /etc/make.conf and I want to keep it. Is it possible to revoke this for whole bunch of packages like kde-base/* I've tried the following line in /etc/portage/package.keywords kde-base/* -~amd64 but it doesn't help. That looks like it'll only work in paludis. You're going to have to use shell scripting and output a BFList to package.keywords . Try $eix -C kde-base --only-names | sed -r 's/$/ -~amd64/' | sudo tee -a /etc/portage/package.keywords -- Andrey Vul A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: [gentoo-user] package.keywords syntax?
Andrey Vul wrote: That looks like it'll only work in paludis. You're going to have to use shell scripting and output a BFList to package.keywords . Try $eix -C kde-base --only-names | sed -r 's/$/ -~amd64/' | sudo tee -a /etc/portage/package.keywords Don't you guys like (or maybe even know) autounmask? [15:34:56] [EMAIL PROTECTED] ~ $ eix autounmask * app-portage/autounmask Available versions: 0.15 0.21 Homepage:http://download.mpsna.de/opensource/autounmask/ Description: autounmask - Unmasking packages the easy way Best regards, Saffi -- Ricardo Saffi Marques http://www.las.ic.unicamp.br/~saffi/ == Laboratory of System Administration and Security - LAS Institute of Computing - IC P.O. Box: 6176 University of Campinas - UNICAMP 13083-852, Campinas, SP, Brazil ==
Re: [gentoo-user] package.keywords syntax?
On Tue, 28 Oct 2008 15:39:14 -0200, Ricardo Saffi Marques wrote: Don't you guys like (or maybe even know) autounmask? Yes, but it unmasks, not masks. -- Neil Bothwick Yoda of the Borg am I. Futile, resistance is. Be assimilated, you will. signature.asc Description: PGP signature
Re: [gentoo-user] package.keywords syntax?
On Tue, Oct 28, 2008 at 1:39 PM, Ricardo Saffi Marques [EMAIL PROTECTED] wrote: Andrey Vul wrote: That looks like it'll only work in paludis. You're going to have to use shell scripting and output a BFList to package.keywords . Try $eix -C kde-base --only-names | sed -r 's/$/ -~amd64/' | sudo tee -a /etc/portage/package.keywords Don't you guys like (or maybe even know) autounmask? You're giving the exact opposite of what was requested in the question. The relevant part of the question was Is it possible to *revoke* [the ~amd64 for kde] If it was *unmasking*, then yes, I would have mentioned autounmask. But the OP asked about revoking (unmasks), not unmasking. If you want to make an automask script that does the work for you, go ahead. -- Andrey Vul A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: [gentoo-user] package.keywords syntax?
On Tuesday 28 October 2008 22:29:39 Andrey Vul wrote: On Tue, Oct 28, 2008 at 1:39 PM, Ricardo Saffi Marques [EMAIL PROTECTED] wrote: Andrey Vul wrote: That looks like it'll only work in paludis. You're going to have to use shell scripting and output a BFList to package.keywords . Try $eix -C kde-base --only-names | sed -r 's/$/ -~amd64/' | sudo tee -a /etc/portage/package.keywords Don't you guys like (or maybe even know) autounmask? You're giving the exact opposite of what was requested in the question. The relevant part of the question was Is it possible to *revoke* [the ~amd64 for kde] If it was *unmasking*, then yes, I would have mentioned autounmask. But the OP asked about revoking (unmasks), not unmasking. If you want to make an automask script that does the work for you, go ahead. Run autounmask, it creates a new file in /etc/portage/package.unmask/ Run a quick awk on it to get it into shape Move file to /etc/portage/package.mask/ Problem solved in a neat elegant insightful way. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] package.keywords syntax?
Run autounmask, it creates a new file in /etc/portage/package.unmask/ Run a quick awk on it to get it into shape Move file to /etc/portage/package.mask/ Problem solved in a neat elegant insightful way. awk? I assumed it was an obsolete language included for compatibility. People should use Python, Perl, or sed's s command. Am I wrong? -- Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] package.keywords syntax?
On Tue, 28 Oct 2008 19:34:31 -0200 Jorge Peixoto de Morais Neto [EMAIL PROTECTED] wrote: Run autounmask, it creates a new file in /etc/portage/package.unmask/ Run a quick awk on it to get it into shape Move file to /etc/portage/package.mask/ Problem solved in a neat elegant insightful way. awk? I assumed it was an obsolete language included for compatibility. People should use Python, Perl, or sed's s command. Am I wrong? Yes. You are wrong. Awk is a useful tool, if you know it. It's just less people bother learning it these days. signature.asc Description: PGP signature
Re: [gentoo-user] package.keywords syntax?
On Tuesday 28 October 2008 23:34:31 Jorge Peixoto de Morais Neto wrote: Run autounmask, it creates a new file in /etc/portage/package.unmask/ Run a quick awk on it to get it into shape Move file to /etc/portage/package.mask/ Problem solved in a neat elegant insightful way. awk? I assumed it was an obsolete language included for compatibility. People should use Python, Perl, or sed's s command. Am I wrong? Yes. You are indeed wrong. Python and Perl are humungous interpreters that rival Java for size. Perl is in a class of it's own for syntax bloat. sed is neat but has nowhere near the functionality of awk. For example, I recently needed to scan a massive text file of 89000+ lines and count the number of character on each line and print it out with the line number. A bash script took 20 seconds to run. A C script took less than half a second. An awk script was marginally *quicker*. Granted, most of that time is spent writing to the console, but the text processing must then also be on par with C. awk is not obsolete, it's just been around for a while. It's no more obsoleted by perl, python and sed than ls is obsoleted by the existence of gui file managers -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] package.keywords syntax?
awk? I assumed it was an obsolete language included for compatibility. People should use Python, Perl, or sed's s command. Am I wrong? Yes. You are indeed wrong. Python and Perl are humungous interpreters that rival Java for size. Perl is in a class of it's own for syntax bloat. sed is neat but has nowhere near the functionality of awk. For example, I recently needed to scan a massive text file of 89000+ lines and count the number of character on each line and print it out with the line number. A bash script took 20 seconds to run. A C script took less than half a second. An awk script was marginally *quicker*. Granted, most of that time is spent writing to the console, but the text processing must then also be on par with C. awk is not obsolete, it's just been around for a while. It's no more obsoleted by perl, python and sed than ls is obsoleted by the existence of gui file managers Nice. I might learn it in the future (there are some urgent duties I must to before, and then I want to learn C* and Python**. Then I may study awk) * Before you ask what, you don't know C?, I mean to really know C, that is, read a rigorous book such as C: A Reference Manual and be able to write portable programs with well-defined behavior. Speaking of well-defined behavior, do you know what happens when you cast a float to an int, and the float is too big to fit into the int? ** I know basic Python, but I think Python is nice enough for a person to *really* know it. -- Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] package.keywords syntax?
On Wednesday 29 October 2008 00:17:50 Jorge Peixoto de Morais Neto wrote:
* Before you ask what, you don't know C?,
A sysadmin doesn't need to know C. It helps to be able to read it of course.
A sysadmin ought to know grep, sed and awk rather well and be quite fluent in
either perl or python, simply becuase those are tools they will use every day
I mean to really know C,
that is, read a rigorous book such as C: A Reference Manual and be
able to write portable programs with well-defined behavior. Speaking
of well-defined behavior, do you know what happens when you cast a
float to an int, and the float is too big to fit into the int?
Did oyu try it yourself and see?
** I know basic Python, but I think Python is nice enough for a person
to *really* know it.
Agreed. It's a very nice language and has some nice side effects on your
thinking. Like realising that the new keyword is an OOP language is always
completely redundant. Or how many brain cycles you use parsing { and }.
Many people like to bitch about Python's enforcement of coding style. But we
all agree that indentation is good. We disagree sometimes how exactly to do
it. Python assumes that you start using the style you like and simply
enforces that you carry on with it (which you were going to do anyway)
That appeals to me - cut to the chase, toss out the irrelevant crap and
concentrate on what's left - the important stuff
--
alan dot mckinnon at gmail dot com
Re: [gentoo-user] package.keywords syntax?
I mean to really know C, that is, read a rigorous book such as C: A Reference Manual and be able to write portable programs with well-defined behavior. Speaking of well-defined behavior, do you know what happens when you cast a float to an int, and the float is too big to fit into the int? Did oyu try it yourself and see? The point is that the behavior in this situation is undefined. It might do anything. Programming in C is different than programming in Python. In Python, you must know the basic behavior of a statement/functions. If an error occurs, it raises an exception. If you do not catch the exception, the program exits (and you can arrange for cleanup actions to be performed before the program exits). In C, you must know exactly what the statement/function does, and you *must* handle the possibility of errors. If an error occurs and you do not handle it, the program may crash, or it may go on and behave erratically (such as deleting user files, or giving results subtly wrong, or leaking memory, or...) -- Software is like sex: it is better when it is free - Linus Torvalds
