Re: python, then C++, or C++ from the start?
martin f krafft [EMAIL PROTECTED] writes: Dear colleagues, I am starting to write netconf [0], finally. Or rather, I would if I could settle on a language. If netconf is ever going to replace ifupdown, it would need to have a low footprint and few dependencies. This clearly suggests C/C++ as the language of choice. 0. http://netconf.alioth.debian.org However, C/C++ make extreme programming rather difficult as it's hard to make large-scale changes due to the strict typing and stuff like lack of garbage collection or seamless exception handling. I am not here to bash C/C++, but you might agree that high-level languages such as Python are much better suited for mockup implementations, when the overall structure and logic of a programme is not yet set in stone. Since I want netconf released early and often, and I'll be reusing a lot of shell script logic at first, throwing stuff around until the logical structure and type definitions are adequate, I am considering starting first in Python and later, when it's All Done(tm), port the application to C++. I am a well-versed C++ coder and I know which things are possible in Python but not in C++, so if I avoid those, this seems like a possible approach. But I am asking you still: can you think of anything to say against such an approach? Please don't flame languages or anything of that sort. The question is just: is it viable for a C++ coder with a Python proficiency to mockup a new application in Python first? I think that approach makes sense. This isn't what you asked for, but you might be interested in Vala[0], which compiles to C and has high-level features such as lambda expressions. [0] http://live.gnome.org/Vala Cheers, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://rotty.uttx.net| GnuPG Key: http://rotty.uttx.net/gpg.asc Fingerprint | C38A 39C5 16D7 B69F 33A3 6993 22C8 27F7 35A9 92E7 v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com Always be wary of the Software Engineer who carries a screwdriver. -- Robert Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python, then C++, or C++ from the start?
On 2007-05-31 08:13, Oleg Verych wrote: I like shell PITAs. At least it will start to run everywhere by `/bin/sh' (dash, busybox, bash, zsh, whatever :) How do you implement control sockets or listen on the netlink socket with shell? Do you want to tail 'ip monitor'? Even if, how do you do control sockets which don't block? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems convictions are more dangerous enemies of truth than lies. - friedrich nietzsche signature.asc Description: Digital signature (GPG/PGP)
Re: python, then C++, or C++ from the start?
On 2007-05-31 08:13, Oleg Verych wrote: I like shell PITAs. At least it will start to run everywhere by `/bin/sh' (dash, busybox, bash, zsh, whatever :) How do you implement control sockets or listen on the netlink socket with shell? Do you want to tail 'ip monitor'? Even if, how do you do control sockets which don't block? I'm not one, who wrote http server in bash or Postscript anyway ;) Seriously. With meaningful wrappers netlink sockets can be handled. I'm not sure what control sockets are, any why non blocking is a problem if I/O is line-oriented (mainly). Moreover, i didn't know `ip' was upgraded to `monitor' functionality! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python, then C++, or C++ from the start?
also sprach Oleg Verych [EMAIL PROTECTED] [2007.05.31.0011 +0200]: Configuration of interfaces (hardware or software) is part of OS setup and proper operation. And this task must be solved on the principle basis, rather than jet-another-lang-flame. Once you have all kernel/network-interfaces (ioctl, sysctl, dhcp clients, etc.) realizations, why not just to start glue them? It's C/shell (or even C/SLang) ifs-glue thing, as you've wrote in the wiki page and not C++/python. IMHO it's far too away from ordinary application programming. While I fundamentally agree with you, shell is also a major PITA and there are even more pitfalls than with C. Add to that a lack of proper debugging tools and you'll understand my tendency for a real language. I should clarify that I am looking only at the core daemon right now, and maybe the configuration/policy parser. The methods, which are the actual workers doing the configuring will most certainly be implemented in shell. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems after you install windows xp, you have the option to create user accounts. if you create user accounts, by default, they will have an account type of administrator with no password. way to go! signature.asc Description: Digital signature (GPG/PGP)
Re: python, then C++, or C++ from the start?
also sprach Robert Collins [EMAIL PROTECTED] [2007.05.31.0021 +0200]: I think its entirely viable. boost::python is rather nice and should allow incremental migration. You could if you care start with a C++ wrapper using boost:python where all the guts are in python, and then its just a question of how much is pure c++ :). I know of at least one person who'd kill me if I used boost for netconf. But as a migrational strategy, this isn't bad, although my experience has been that you don't use boost, it uses you. Or rather, you need to cater your application for boost, despite all the generic programming it does. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems Most Intelligent Customers Realise Our Software Only Fools Them. signature.asc Description: Digital signature (GPG/PGP)
Re: python, then C++, or C++ from the start?
On Thu, May 31, 2007 at 08:50:11AM +0200, martin f krafft wrote: [] The methods, which are the actual workers doing the configuring will most certainly be implemented in shell. Then call me ! I like shell PITAs. At least it will start to run everywhere by `/bin/sh' (dash, busybox, bash, zsh, whatever :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python, then C++, or C++ from the start?
also sprach Oleg Verych [EMAIL PROTECTED] [2007.05.31.1013 +0200]: Then call me ! Do you have a POSIX-compatible solution to the problem of setting variables inside while loops? See http://blog.madduck.net/geek/2006.05.29-shell-sucks -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems i'd rather be riding a high speed tractor with a beer on my lap, and a six pack of girls next to me. signature.asc Description: Digital signature (GPG/PGP)
Re: python, then C++, or C++ from the start?
On Wed, May 30, 2007 at 05:34:10PM +0200, martin f krafft wrote: But I am asking you still: can you think of anything to say against such an approach? Please don't flame languages or anything of that sort. The question is just: is it viable for a C++ coder with a Python proficiency to mockup a new application in Python first? I would choose plain C instead of C++ to avoid possible ABI breakages during main upgrades. But for that, there are more tiny languages available to be embedded into a C/C++ framework, but probably I'm biased and old-fashioned ;-) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python, then C++, or C++ from the start?
* From: martin f krafft [EMAIL PROTECTED] * Date: Thu, 31 May 2007 10:37:54 +0200 * Organization: Debian GNU/Linux also sprach Oleg Verych [EMAIL PROTECTED] [2007.05.31.1013 +0200]: Then call me ! Do you have a POSIX-compatible solution to the problem of setting variables inside while loops? See http://blog.madduck.net/geek/2006.05.29-shell-sucks ,---[ blog entry, Mon, 29 May 2006 ]--- | |Shell sucks | | Shell programming must be the most depressive waste of time out there, | and if only because things sometimes just don't work the way you'd | expect from a scripting language. Yes... And main reason is, IMHO, shell is a kernel syscalls (open, read, write, pipe, fork, etc.) manipulation tool with some helper functionality, it's not a programming thing. | Take the following simple examples in bash (3): |for i in 1 2 3; do | echo $i | exit 1 |done | echo END | |== 1 | |echo -e 1\n2\n3 | while read i; do | echo $i | exit 1 |done |echo END | |== 1 |== END | | WTF? The result of the first -- the whole script exits entirely after | the first iteration -- is what I expect. After all, I did not call | break, but exit. The result of the second is totally unexpected. I | understand that for and while each execute their iterations in a | subshell, but why don't these behave in the same way? I'd say, the *fine* reason can be found after reading pipe(7), pipe(2). Pipe is so frequently mentioned and used in the UNIX environment by shells, but programmers with their applications use it fairly seldom. (in short: syscall pipe(2) can be used only by two processes, i.e fork) However as noted in some historical notes ever, it was a time, where all that wasn't that good. Shell implementations ran loops with redirected I/O (,) in subshells also, while this not require forking[0]. Now it's OK. [0] UNIX Power Tools http://www.unix.org.ua/orelly/unix/upt/ch45_23.htm | The fix here is a || exit $? following the done keyword. Urks! Obviously, it's an another process. Syntax is wired, but hey, it's the UNIX power! | | Here's another one: the task is simply to output the number of 1's in | the output (yeah, I realise grep -c can do this too): |cnt=0 |echo -e 2\n1\n3\n1 | while read i; do |case $i in | 1) cnt=$((cnt + 1));; |esac | done |echo $cnt | | == 0 | | The reason? The while subshell receives a copy of the caller | environment, so when it updates $cnt, it only updates a copy of the | actual variable, leaving the original untouched. Similarly, a variable | defined inside the subshell won't be available after the while loop is | done. Aha, you knew that! But it's a kind of confusion. Again, *subshell* is another process, another process is not necessarily a shell. See also 38.4 in the [0]. Thus same result must be with `` and $(). Funny thing to note is, that this script already bash specific, because of `echo -e'. Forget it, please, use `printf %b ...' instead. | | I cannot find a fix that's not bash specific. | | Of course, it works fine when I replace the while loop by a for loop: |cnt=0 | for i in 2 1 3 1; do |case $i in | 1) cnt=$((cnt + 1));; |esac | done |echo $cnt | |== 2 | | Great, isn't it? | | And I am not surprised that zsh gets it right. Why would anyone | actually want to use bash? Maybe zsh is a shell for programmers ;) ==[self, about programmers] I developed one simple way of being useful for any kind of Linux development, while i had wonderful academia time. Become a User (not user or luser) of your system first, before you start to develop and code anything. Unfortunately big and expensive UNIX setups were not so widely available, and many of use came back there only after M$ brainwashing, dot com bubbles, HTML, Javascript XML and such $(/dev/random dd bs=13 count=1) [note subshell! ;] ==[ish] | | Update: here's Joey's explanation for the behaviour, and Clint's | account for why zsh does it right. I still can't figure out how to | count the 1's. Joey is talking about lot of shell programming and POSIX, while using `echo -e` :D | | Update ^2: Axel Liljencrantz sent in this message. | ||grep ...|read foo bar baz || ||Which is very often useful. As you say in your blog, zsh fares quite a ||bit better since the last process in a pipeline is not run in a ||subshell, which at least takes care of the most common problems. But ||the fundamental idea of subshells is, in my opinion, broken. You ||simply can't do variable assignment or perform many other builtins ||with any reliability when using pipelines or command substitutions. || ||I've tried to write a shell (called fish) that never ever forks of a ||subshell... It's possible to do variable assigment `eval', `. file', [0]. [But programmer chooses to code more...] | | Update ^3: Alexander Sieck showed me that process substitution | ((command)) instead of the pipe does work (for both cases): |while read i; do | echo $i | exit 1 |done (echo -e
python, then C++, or C++ from the start?
Dear colleagues, I am starting to write netconf [0], finally. Or rather, I would if I could settle on a language. If netconf is ever going to replace ifupdown, it would need to have a low footprint and few dependencies. This clearly suggests C/C++ as the language of choice. 0. http://netconf.alioth.debian.org However, C/C++ make extreme programming rather difficult as it's hard to make large-scale changes due to the strict typing and stuff like lack of garbage collection or seamless exception handling. I am not here to bash C/C++, but you might agree that high-level languages such as Python are much better suited for mockup implementations, when the overall structure and logic of a programme is not yet set in stone. Since I want netconf released early and often, and I'll be reusing a lot of shell script logic at first, throwing stuff around until the logical structure and type definitions are adequate, I am considering starting first in Python and later, when it's All Done(tm), port the application to C++. I am a well-versed C++ coder and I know which things are possible in Python but not in C++, so if I avoid those, this seems like a possible approach. But I am asking you still: can you think of anything to say against such an approach? Please don't flame languages or anything of that sort. The question is just: is it viable for a C++ coder with a Python proficiency to mockup a new application in Python first? Thanks for comments, -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems micro$oft encrypts your windows nt password when stored on a windows ce device. but if you look carefully at their encryption algorithm, they simply xor the password with susageP, Pegasus spelled backwards. Pegasus is the code name of windows ce. this is so pathetic it's staggering. signature.asc Description: Digital signature (GPG/PGP)
Re: python, then C++, or C++ from the start?
On Wed, 30 May 2007 17:34:10 +0200 martin f krafft [EMAIL PROTECTED] wrote: But I am asking you still: can you think of anything to say against such an approach? Please don't flame languages or anything of that sort. The question is just: is it viable for a C++ coder with a Python proficiency to mockup a new application in Python first? Planning to write the application twice seems to me to presume more time and continued enthusiasm than is perhaps realistic, especially since your plans seem fairly ambitious---having to slog through the last 10% of the application not once but twice seems masochistic. Also, for the transition from the python to C/C++ versions to be smooth enough to not penalize early adopters, it seems to me that they would both have to have comprehensive test suites, otherwise you risk having small incompatibilities. Again, everyone's least favorite bits, done twice. It seems to me like your chances of real success would be greater if you wrote it once in Python---which will be much more productive than any C/C++---and then spent the time you would have spent rewriting it in C/C++ lobbying to get python in base, which would probably make a lot of other people very happy. For that matter, figure out what other perl dependencies there are in base, rewrite them all in python so that perl could be dropped from base (as a way to bolster your argument) and you'll still probably be done before you would writing the app twice. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python, then C++, or C++ from the start?
On Wednesday 30 May 2007 09:34, martin f krafft wrote: But I am asking you still: can you think of anything to say against such an approach? Please don't flame languages or anything of that sort. The question is just: is it viable for a C++ coder with a Python proficiency to mockup a new application in Python first? A similar approach seems to have worked pretty well for git. I think that some of the core functionality was C with a lot of scripts for functionality. Slowly, a lot of the scripts have become C code. It seems rational to allow the python and C/C++ code to work together so that you can transition from one to the other and aren't just strictly porting from one to the other at the end of the project. wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python, then C++, or C++ from the start?
also sprach Michael Alan Dorman [EMAIL PROTECTED] [2007.05.30.1816 +0200]: Planning to write the application twice seems to me to presume more time and continued enthusiasm than is perhaps realistic, especially since your plans seem fairly ambitious---having to slog through the last 10% of the application not once but twice seems masochistic. It does. I was hoping someone else would do the porting. :) Also, for the transition from the python to C/C++ versions to be smooth enough to not penalize early adopters, it seems to me that they would both have to have comprehensive test suites, otherwise you risk having small incompatibilities. Again, everyone's least favorite bits, done twice. Well, comprehensive test suites they should have anyway. It's absolutely not my least favourite bit after having read Kent Beck. http://en.wikipedia.org/wiki/Test-driven_development It seems to me like your chances of real success would be greater if you wrote it once in Python---which will be much more productive than any C/C++---and then spent the time you would have spent rewriting it in C/C++ lobbying to get python in base, which would probably make a lot of other people very happy. Well, depending on what Python I need, this may or may not be possible. Then again, I should really aim for python-minimal, just to make sure it *could* be ported to C++. For that matter, figure out what other perl dependencies there are in base, rewrite them all in python so that perl could be dropped from base (as a way to bolster your argument) and you'll still probably be done before you would writing the app twice. debconf? adduser? No thanks. :) -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems windoze is the one-night-stand of operating systems; you feel so cheap after having used it. signature.asc Description: Digital signature (GPG/PGP)
Re: python, then C++, or C++ from the start?
On Wed, 2007-05-30 at 17:34 +0200, martin f krafft wrote: Dear colleagues, ... But I am asking you still: can you think of anything to say against such an approach? Please don't flame languages or anything of that sort. The question is just: is it viable for a C++ coder with a Python proficiency to mockup a new application in Python first? I think its entirely viable. boost::python is rather nice and should allow incremental migration. You could if you care start with a C++ wrapper using boost:python where all the guts are in python, and then its just a question of how much is pure c++ :). Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: python, then C++, or C++ from the start?
But I am asking you still: can you think of anything to say against such an approach? Please don't flame languages or anything of that sort. The question is just: is it viable for a C++ coder with a Python proficiency to mockup a new application in Python first? Planning to write the application twice seems to me to presume more time and continued enthusiasm than is perhaps realistic, especially since your plans seem fairly ambitious---having to slog through the last 10% of the application not once but twice seems masochistic. Configuration of interfaces (hardware or software) is part of OS setup and proper operation. And this task must be solved on the principle basis, rather than jet-another-lang-flame. Once you have all kernel/network-interfaces (ioctl, sysctl, dhcp clients, etc.) realizations, why not just to start glue them? It's C/shell (or even C/SLang) ifs-glue thing, as you've wrote in the wiki page and not C++/python. IMHO it's far too away from ordinary application programming. [] For that matter, figure out what other perl dependencies there are in base, rewrite them all in python so that perl could be dropped from base (as a way to bolster your argument) and you'll still probably be done before you would writing the app twice. Somebody suggests to get rid of the bloated mammoth, debian so depends on, interesting. I want to rewrite some base, that is really needed on shell :) Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
