- can distribute a statically linked 2 meg executable - quick to install - typically only 2 megs of resident RAM used by running program - virtually zero startup time - much more responsive GUI - still runs well on hardware more than 4 years old
Why not Swing?
- don't want the 40 meg downloadable JRE footprint - don't want Java version hell for your users/customers - don't want the 40 Meg of resident RAM required by the smallest running Swing program - requires the latest hardware for decent speed.
1. Offer goose for code and post notice in town square. 2. Wait 30 days 3. If no one claims the code in that time you may keep the code and eat the goose.
The proposed new messaging layer sounds really interesting and powerful. A little like Mach or QNX, perhaps? Many kernel methods and system calls will use messaging instead of traditional brittle techniques that often lead to API problems down the road. Also, multithreaded kernel design should be simplified as result. My only question is how much will this slow down FreeBSD?
The C++ standards committee does not want to get involved with operating system issues, nor do they want to impose a standard object file linking convention for various vendors' C++ compilers. I don't agree with this. C++ is forever doomed to be a statically compiled language with poor compilation speed if they do not mandate standard object file and shared library formats and conventions. The C++ ABI standardization is a good start - but it does not go far enough. And no, a template repository is not a solution - it's a band-aid covering this underlying problem of brittle classes and the need to recompile everything under the sun everytime a fundamental class' structure is changed. The.o (or.obj) files ought to store much higher level information about templates, classes, dependencies and typedefs. I know a number of projects that have switched to Java solely due to the poor C++ compilation speed issue. It is not unusual for a complete rebuild of a C++ system to take several hours. Don't believe me? Build Qt on typical two-year old hardware. This is not acceptable. Even the largest Java projects typically take under 10 minutes to build from scratch. Say what you will about Java, but they got it right when it came to creating a standard object file format (the.class file). A third party Java analysis tools industry was born overnight to take advantage of this common object format. As far as I'm concerned, the more standardization between various C++ compilers on different platforms - the better it will be for all C++ programmers.
Amen, brother. Anything that reduces the amount of needless typing in C++ programs is welcome.
I'd only add C++ reflection to your wishlist since every library rolls their own scheme based on wacky macros or external pre-processor programs anyway. Language purists who are against reflection have never coded large systems in the real world.
C++ needs ACE like dogs need submarines. Can ACE possibly be any more complicated than it is? The ACE developers should really look at Qt/KDE to see how to design intuitive C++ APIs. Boost has the right idea, but I fear they are heading down the ACE path of needless complexity.
The original poster claimed that mass was a measure of intertia. Special Relativity refutes this. I brought this to your attention. You were wrong. You obviously agree with this or you would not have posted such a long-winded fact-less rant. This is pedantic perhaps, but this is Slashdot afterall. I never was making reference to mass and intertia with repect to the space shuttle. I was just making a point. You did not and can not refute this fact. So, please stop embarassing yourself further. You and your AC friend whom has professed his love for you should get a room.
Libxml2 is a bitch to use - memory ownership is not documented, and the examples are poor. GCC 3.3 produces excellent code. Libwww is not threadsafe. Never tried libxml++.
I was referring to the comparitive size of the interpreter projects. The results speak for themselves. DotGNU Portable.NET was done with roughly the same number of developers (mostly by Rhys Weatherley) - and they were not paid to write this code as were the Parrot developers. DotGNU has a CLR VM, runtime libraries, a C# compiler, an assembler and a disassembler.
Forgive Dan. He's been spending time thinking of how to implement them well, rather than just wasting his time coding randomly. Thinking before acting has its merits.
That's quite funny. And Parrot's design is not random?! I guess you haven't been following their development very closely. They've changed calling conventions at least a half dozen times in the past 2 years, just to give you an example of their lack of a true design. Look how far both DotGNU and Mono have come in the same timeframe - they're actually working!
As for Dan and his book, I won't be buying it. He's already made enough money with his $60K Perl Foundation grant to construct the most needlessly (hopelessly?) complicated interpreter design anyone has ever seen. And does anyone know why the Parrot/Perl 6 team is trying to run Ruby, Python, CLR and Java bytecodes anyway? How exactly does that advance the cause of Perl 6?
On a slightly different topic, perhaps you can tell me why on earth isn't Larry prototyping Perl 6 with Perl 5? Afterall, most Ada compilers are written in Ada, and Lisp compilers are usually written in Lisp. Writing a Perl 6 interpreter in Perl 5 would increase community interest in the language as well as debug its concepts and shake out bad features and most importantly, Perl 6 modules and tutorials could be written. Sure this prototype would be slow - but who cares - it would be throw-away code. The final interpreter could be rewritten in C after the language is conceptually stable. Just call me crazy.
I guess I would not be so critical if I did not see promise in Perl 6 - the language. Oh well, perhaps another language will incorporate these concepts.
1. Develop VM before knowing what Perl 6 language will look like or what it requirements will be. 2. Claim VM will support all interpreted languages known to man, yet the only language that runs on it is a crippled version of Basic. The other (non Perl) languages will require custom C code defeating the point of having a VM in the first place. 3. Piss away $200K in grant money and have nothing to show for it 3 years later. Gee, why isn't anyone contributing anymore? 4. Threads? We'll worry about it later. 5. Objects? Too tricky for now. 6. Function calling convention - we'll get it right one of these years.
Guys, time to put the horse in front of the cart and get back to the business of writing Perl 6 or Topaz or whatever it is called these days instead of trying to rule the world with Parrot.
for salesforce.com courtesy of BusinessWeek. Don't read into what BusinessWeek "predicts" too much. They are almost always wrong. As an example, they were cheering on Enron's business plan as being brilliant and unstoppable when they should have been questioning their numbers and trying to uncover their pyramid scheme. As I recall, BusinessWeek had pictures of the Enron execs jumping on trampolines and laughing in the article - business journalism at its finest! I think traditional software still has some legs yet.
RMS has always insisted on GCC authors handing over copyright assignments on paper to the FSF before contributing any non-trivial (over a few lines) patch to GCC. Many thought this was being overly paranoid but in light of SCO's irresposible corporate behavior history has proven Stallman right. Yes, this slows progress down tremendously, but with the litigious nature of US firms - what choice do you really have?
Jabber is more than "just" an instant messaging thing - it's a simple bidirectional socket-based generic DTD-less XML protocol that is computer-language agnostic. Unlike the request/response model of HTTP, Jabber messages are asynchronous (unsolicited messages allowed in both directions) and share a single socket connection until the session is complete. In each direction on the socket you have a single-rooted XML document. Each Jabber message is basically a sub-node of this document as parsed by your favorite SAX-style parser firing a callback when the message is received. There are some manditory tags for joining groups, broadcasting and requesting info among other things. For the most part you just support the message types that you care about and you can add your own application-specific messages with custom XML payloads. If a Jabber client or server is not familiar with a message type it is ignored. Nice. Simple. Effective.
Here's some of the issues I've run into with a lot of the free software libraries out there:
library uses wrong language
library has the wrong license
library pulls in too many external dependencies
library not threadsafe
But it's worth the search - occasionally you find a real gem.
Mozilla 1.2.1 mailboxes don't migrate?
on
Mozilla 1.4 RC1
·
· Score: 2, Interesting
I've tried and failed twice to migrate to versions of Mozilla above 1.2.1 without success. None of the new versions seem to like the older mailbox format. I never had trouble migrating the mozilla mailboxes prior to 1.2.1 - going from Mozilla 1.0.x to 1.1.x to 1.2.x went without a hitch. Anyone have any suggestions?
You would not be able to deduce much considering the template code and inline class members functions would simply become part of other unrelated functions or classes - or collapsed into constants or a word in memory. Consider C++ template metaprogramming where a killer 500K block of source code is crunched down into a single number or simple expression. vector::size() might be reduced to be the 8th byte from the beginning of a block of memory - there's no function. There's no way to retrieve the original due to the intense optimization.
Slashdot Mirror
Why a native C/C++ GUI toolkit?
- can distribute a statically linked 2 meg executable - quick to install
- typically only 2 megs of resident RAM used by running program
- virtually zero startup time
- much more responsive GUI
- still runs well on hardware more than 4 years old
Why not Swing?
- don't want the 40 meg downloadable JRE footprint
- don't want Java version hell for your users/customers
- don't want the 40 Meg of resident RAM required by the smallest running Swing program
- requires the latest hardware for decent speed.
1. Offer goose for code and post notice in town square.
2. Wait 30 days
3. If no one claims the code in that time you may keep the code and eat the goose.
The proposed new messaging layer sounds really interesting and powerful. A little like Mach or QNX, perhaps? Many kernel methods and system calls will use messaging instead of traditional brittle techniques that often lead to API problems down the road. Also, multithreaded kernel design should be simplified as result. My only question is how much will this slow down FreeBSD?
The C++ standards committee does not want to get involved with operating system issues, nor do they want to impose a standard object file linking convention for various vendors' C++ compilers. I don't agree with this. C++ is forever doomed to be a statically compiled language with poor compilation speed if they do not mandate standard object file and shared library formats and conventions. The C++ ABI standardization is a good start - but it does not go far enough. And no, a template repository is not a solution - it's a band-aid covering this underlying problem of brittle classes and the need to recompile everything under the sun everytime a fundamental class' structure is changed. The .o (or .obj) files ought to store much higher level information about templates, classes, dependencies and typedefs. I know a number of projects that have switched to Java solely due to the poor C++ compilation speed issue. It is not unusual for a complete rebuild of a C++ system to take several hours. Don't believe me? Build Qt on typical two-year old hardware. This is not acceptable. Even the largest Java projects typically take under 10 minutes to build from scratch. Say what you will about Java, but they got it right when it came to creating a standard object file format (the .class file). A third party Java analysis tools industry was born overnight to take advantage of this common object format. As far as I'm concerned, the more standardization between various C++ compilers on different platforms - the better it will be for all C++ programmers.
Amen, brother. Anything that reduces the amount of needless typing in C++ programs is welcome. I'd only add C++ reflection to your wishlist since every library rolls their own scheme based on wacky macros or external pre-processor programs anyway. Language purists who are against reflection have never coded large systems in the real world.
C++ needs ACE like dogs need submarines.
Can ACE possibly be any more complicated than it is?
The ACE developers should really look at Qt/KDE to see how to design intuitive C++ APIs.
Boost has the right idea, but I fear they are heading down the ACE path of needless complexity.
The original Perl 6 development schedule from 2000:
Forecast
Design finished (end of 2001)
Alpha released (Mayish 2002)
Beta release (Julyish 2002)
Perl 6.0.0 (Octoberish 2002)
What stage are we at now?
The original poster claimed that mass was a measure of intertia. Special Relativity refutes this. I brought this to your attention. You were wrong. You obviously agree with this or you would not have posted such a long-winded fact-less rant. This is pedantic perhaps, but this is Slashdot afterall. I never was making reference to mass and intertia with repect to the space shuttle. I was just making a point. You did not and can not refute this fact. So, please stop embarassing yourself further. You and your AC friend whom has professed his love for you should get a room.
So Webster.com says mass is a measure of inertia, does it? Oh boy! It must be right!
Not according to Special Relativity.
Where did you go to school? I'll be sure not to send my kids there.
Libxml2 is a bitch to use - memory ownership is not documented, and the examples are poor. GCC 3.3 produces excellent code. Libwww is not threadsafe. Never tried libxml++.
Web Economy Bullshit Generator
I was referring to the comparitive size of the interpreter projects. The results speak for themselves. DotGNU Portable.NET was done with roughly the same number of developers (mostly by Rhys Weatherley) - and they were not paid to write this code as were the Parrot developers. DotGNU has a CLR VM, runtime libraries, a C# compiler, an assembler and a disassembler.
Forgive Dan. He's been spending time thinking of how to implement them well, rather than just wasting his time coding randomly. Thinking before acting has its merits.
That's quite funny. And Parrot's design is not random?! I guess you haven't been following their development very closely. They've changed calling conventions at least a half dozen times in the past 2 years, just to give you an example of their lack of a true design. Look how far both DotGNU and Mono have come in the same timeframe - they're actually working!
As for Dan and his book, I won't be buying it. He's already made enough money with his $60K Perl Foundation grant to construct the most needlessly (hopelessly?) complicated interpreter design anyone has ever seen. And does anyone know why the Parrot/Perl 6 team is trying to run Ruby, Python, CLR and Java bytecodes anyway? How exactly does that advance the cause of Perl 6?
On a slightly different topic, perhaps you can tell me why on earth isn't Larry prototyping Perl 6 with Perl 5? Afterall, most Ada compilers are written in Ada, and Lisp compilers are usually written in Lisp. Writing a Perl 6 interpreter in Perl 5 would increase community interest in the language as well as debug its concepts and shake out bad features and most importantly, Perl 6 modules and tutorials could be written. Sure this prototype would be slow - but who cares - it would be throw-away code. The final interpreter could be rewritten in C after the language is conceptually stable. Just call me crazy.
I guess I would not be so critical if I did not see promise in Perl 6 - the language. Oh well, perhaps another language will incorporate these concepts.
Parrot (the Perl 6 VM) is a classic case of Second System Syndrome.
1. Develop VM before knowing what Perl 6 language will look like or what it requirements will be.
2. Claim VM will support all interpreted languages known to man, yet the only language that runs on it is a crippled version of Basic. The other (non Perl) languages will require custom C code defeating the point of having a VM in the first place.
3. Piss away $200K in grant money and have nothing to show for it 3 years later. Gee, why isn't anyone contributing anymore?
4. Threads? We'll worry about it later.
5. Objects? Too tricky for now.
6. Function calling convention - we'll get it right one of these years.
Guys, time to put the horse in front of the cart and get back to the business of writing Perl 6 or Topaz or whatever it is called these days instead of trying to rule the world with Parrot.
for salesforce.com courtesy of BusinessWeek.
Don't read into what BusinessWeek "predicts" too much. They are almost always wrong. As an example, they were cheering on Enron's business plan as being brilliant and unstoppable when they should have been questioning their numbers and trying to uncover their pyramid scheme. As I recall, BusinessWeek had pictures of the Enron execs jumping on trampolines and laughing in the article - business journalism at its finest!
I think traditional software still has some legs yet.
The bug in question (moz bug ID 208300) appears to be fixed for 1.4 RC2.
RMS has always insisted on GCC authors handing over copyright assignments on paper to the FSF before contributing any non-trivial (over a few lines) patch to GCC. Many thought this was being overly paranoid but in light of SCO's irresposible corporate behavior history has proven Stallman right. Yes, this slows progress down tremendously, but with the litigious nature of US firms - what choice do you really have?
I also thought the article poorly described Sun's new chip design initiative. Here's one article on the new asynchronous chip design. Here's another.
I guess it shows just how much the Java Community Process is worth when someone from Sun comes out and says "Java will not have X because we say so".
Nonsense - the JCP is a community - a community of obedient followers of Sun's doctrine. Sun always knows what's best.
Jabber is more than "just" an instant messaging thing - it's a simple bidirectional socket-based generic DTD-less XML protocol that is computer-language agnostic. Unlike the request/response model of HTTP, Jabber messages are asynchronous (unsolicited messages allowed in both directions) and share a single socket connection until the session is complete. In each direction on the socket you have a single-rooted XML document. Each Jabber message is basically a sub-node of this document as parsed by your favorite SAX-style parser firing a callback when the message is received. There are some manditory tags for joining groups, broadcasting and requesting info among other things. For the most part you just support the message types that you care about and you can add your own application-specific messages with custom XML payloads. If a Jabber client or server is not familiar with a message type it is ignored. Nice. Simple. Effective.
library uses wrong language
library has the wrong license
library pulls in too many external dependencies
library not threadsafe
But it's worth the search - occasionally you find a real gem.
I've tried and failed twice to migrate to versions of Mozilla above 1.2.1 without success. None of the new versions seem to like the older mailbox format. I never had trouble migrating the mozilla mailboxes prior to 1.2.1 - going from Mozilla 1.0.x to 1.1.x to 1.2.x went without a hitch. Anyone have any suggestions?
Press release from SCO this morning:
"SCO's lawsuit against IBM does not involve patents or copyrights."
So what the hell does it involve?
Where's the talk of IP infringement now?
It seems SCO's lawsuit and SCO itself are finished.
You would not be able to deduce much considering the template code and inline class members functions would simply become part of other unrelated functions or classes - or collapsed into constants or a word in memory. Consider C++ template metaprogramming where a killer 500K block of source code is crunched down into a single number or simple expression. vector::size() might be reduced to be the 8th byte from the beginning of a block of memory - there's no function. There's no way to retrieve the original due to the intense optimization.