If the app GUI is fairly simple, do the back end in a c++ library, and do the front end in Cocoa.
But if you have a complex GUI,
do take a look at QT/Mac from trolltech. It isn't FREE but it is quite good and allows your program to be portable between Mac/Linux/Windows.
TI 6701 DSP, custom embedded hardware, eprom for first and second boot stage, third boot stage is on flash.
The second boot stage had to be compressed to fit in the eprom. The first boot stage was limited in what it could do. The second boot stage in eprom was a subset of the flash code.
We would be fixing bugs and adding features in the firmware, but once in a while we would add a line of code and the firmware would crash in an entirely different spot, sometimes even on boot up.
Add one line of code elsewhere and the problem goes away. After a while we realized it did not matter what the line of code was that we added! it mattered where, though. We quadruple checked our cinit linker section and almost everything concievable including lost pointers and trashed code segments. The in-circuit-emulator proved almost useless with major crashes and special case things. So no debugger access.
What happened?
There are write-only latches that the boot loader needs to write to in order to control the front panel. At some point, the flash code was updated so that the last written pattern to the latches would be stored so you could query the value. When an eprom was made based on this code, the problem occured.
After the flash code was read from flash, and relocated to the appropriate spot by code safely residing in internal SRAM of the DSP, the internal code blinked a front panel LED. The latch buffer was still residing in DRAM, in the same area that the new code was loaded into!
So if one specific bit in the flash code was supposed to be a 1, the bootloader would change it to a zero and we would get a spurious crash.
If the bit was supposed to be zero, there would be no problems!!!!
And the new economy is defective because I did not read any of the ads on the site and can't remember anything other than the article! I wouldn't advertise there!
Imagine, tivo can obliterate their competition just by telling them that EVERYONE is performing hacks and copyright violations! ReplayTV will have to shut down all of their own customers! A great Denial Of Service attack!
It is not just the 'act of observation making something uncertain'. Energy is proportional to planck's constant times frequency. Since frequency is 1/time, this means that energy depends on time. The point is that the unobserved electron frozen in a 'snapshot' in time has no energy.
It depends on what your definition of Pi is. Is it the idealized circle? Or is it the measured circle? If Pi is defined and calculated by first principles assuming a non-changing flat euclidian plane, then Pi is a constant and calculatable.
If however you want to make Pi a measurement ratio, then you can never calculate it to arbitrary precision - you can only measure it. And general relativity already tells you that in our universe even if you had perfect measurement tools, you will measure a different value for Pi because of space being bent by mass.
Does that mean the value of Pi for the idealized circle is wrong? No.
Yes, I agree with your points. I think a key thing is to think about 'class string' as part of a library.... and this library is in itself a project all on its own. It has its own specifications and requirements and tests, and one of the requirements is for it to be reusable.
So in my opinion, it is totally feasible to split a large project up into smaller sub-projects. Some of which may have 'reuse' as a specification. But there is a fine line between what should be reusable and what should be not reusable... it comes down to a judgement call, and my point is that quite often those judgement calls come down on the side of too much abstraction and the 'illusion' of reusability.
"Damn, all this code we wrote with reusability in mind just does not fit well with this new application we want to make. Now we have to change the library and all the projects which depend on it!"
or worse: "Damn, this code we wrote with reusability in mind does not fit well.. let us make a bunch of adaptor classes to adapt them for use with our new project... it won't be as efficient as it could be but we gotta get this shipped and we don't have time to fix the library and all the projects that depend on it"
I have seen a number of cases where a 'bug fix' in one reusable component caused adverse effects in another project that used it! This is what I meant about the concept of two bugs cancelling each other out. Once a reusable component is changed for any reason - even just a bug fix - you must put all of your dependant projects through extensive testing again! It is not often clear what the ramifications of a bug fix may be!
One of the side effects of making your code 'reusable' is that you are less likely to hack it together into a mess. But proper design an coding should not depend on the reusability of the code... there should be good code everywhere.
--jeff++
P.S. unfortunately, under many c++ libraries you cannot reuse JUST the 'string' class. The string class usually implicitely pulls in all sorts of apparently unrelated things as well which may have their own issues. So for instance you want to 'reuse' the MFC CString class, now you are limited in your potential to port your code to another platform. So reusing code is not always a win as along with that reuse will come the 'reuse' of the original code's restrictions.
Another problem I have seen was where TWO different bugs mostly functionally cancelled each other out causing new intermittent problems.
I made a realization regarding strict-type checking languages versus dynamic typed languages.
Typically, people who are used to java and c++ complain about languages like python - saying that the compiler should catch static type problems at compile time and that languages that do not do this are inherently unsafe.
Then I realized that ALL of these people must not be running any real tests on their code! If they were running real tests on all your code (every line must be executed in your tests), then these dynamic typing errors would be easily caught ! those would be the easiest bugs to find.
Too often I have seen C and C++ coders compile their project.... No errors! Ship it!:-)
Another issue I have been thinking about is the relationship between code reuse and unexpected behaviours. Code reuse (and object class reuse) is fine as long as all of the functionality and limitations of the object/code are known.
However for more complex class hierarchies I have seen people say '"I'll just inherit from this class publicly and change the public interface to match what I need for this project." - And then they are surprised when other pre-written code interacts funny with it. I'm not saying object-oriented is bad - I'm saying it is so common for programmers to break the basic concepts of OOP.
I had one manager who was adamant that for any medium sized project there ought to be NO time spent on making the code re-usable. Every line of code should be directly related to specific aspects of the customer's requirements/specification document. At first I thought he was crazy.
But after I saw some projects expand into massive class hierarchies just for the sake of the illusion of increasing the reusability of the code in other projects, I am starting to side with him a bit more.
Extreme Programming has at least some very good points about it. ie: don't add features until you know you need them. Otherwise they probably won't be tested properly and won't be a good match for the new use. You can't predict every environment that the code may be reused in. It is harder to do than it sounds.
So for high reliability systems I think one should have simple non abstracted code that can be measured, prodded, and always predictable. Then you can fashion your unit tests accordingly.
--jeff++
P.S.: scary thought/rant for today: How much C++ code do you see that is striving to be exception safe so that memory full errors will be caught properly? How many C++ coders understand that the default linux kernels and libraries will almost NEVER cause malloc() to return 0 and will almost NEVER cause operator new() to throw? Only virtual memory space is allocated. Real memory pages are only allocated as they are being used. Once all physical and swap pages are used, blammo goes your app (and possibly other apps on your system). In semi-critical systems, this is a real problem that is often overlooked.
Where is the real problem in this case? Part of the problem is that the c++ environment running on the default linux kernel does not conform to the standard.
The other part of the problem is that it is little known. If it were commonly known, people would be able to design around it (or change the kernel options). So people rely on what the documentation says, instead of properly testing the software limits.
good points - Do you remember how many humans died in Episode 1? were there any at all? The robot attack force was a cop out on the potential violence rating had they been stormtroopers I think.
Who would have thought that Richard Stallman was correct all these years regarding free-as-in-speech software? How many of you just thought he was a paranoid lunatic?
Dan would later learn that there was a time when anyone could have debugging tools. There were even free debugging tools available on CD or downloadable over the net. But ordinary users started using them to bypass copyright monitors, and eventually a judge ruled that this had become their principal use in actual practice. This meant they were illegal; the debuggers' developers were sent to prison.
... In 2047, Frank was in prison, not for pirate reading, but for possessing a debugger.
Set up a EULA with LEGAL terms, verify it with a lawyer so that it does not constitute an illegal contract - Yet make it Absurd. THEN, get your friend to sue you over the absurdity of the EULA and let your friend win.
Would this then constitue a legal precedent against EULA's?
Maildir DOES work great, and I use it myself for non archived emails.
They work great until you have lots of messages.
My postgresql email database contains 54,244 email messages. Current filesystems do not like having that many files in one directory. A filesystem is NOT a database - it only has one field (filename) that you can do queries on.
The database allows me to properly index the fields such as 'date', 'subject', and 'from' - for instance:
select count(*) from msgs where msg_from = '<myemailaddress@domain>';
returns a result in a fraction of a second because it does not have to iterate through all my messages. Whereas a Maildir directory with 5000 files in it can not be groked with wildcards. Try it!:
$ ls * bash:/bin/ls: Argument list too long
A big problem with the concept of putting only metadata in the database and the content in the filesystem is that you end up making the system even more complex as you need two different ways of accessing the data and the data is split between two sources.
The two different ways of accessing the data is a problem when you want to access the emails from another computer. For me it is simple - my Mac OS X machine can make a postgresql connection to my linux server and do queries including message content easy and quick.
SQL databases nowadays handle large text fields and blobs just fine and make it dead simple to back up, process, or query all the data.
'Folders' can be just SQL VIEWs and are way more flexible than seperate Maildirs for each folder.
By the way, I would LOVE to see an imap server and email client program handle 54,244 messages in one folder that I can view and search different ways without it bogging down or trying to cache 600 megs of data locally or trying to make a single list box with 54,244 items in it (and usually crashing in the process)
Please show me one so I can use it instead of writing my own smtp to postgresql gateway.
DBMAIL looks cool, once it supports postgresql it would be awesome.
I have been dissapointed in general with most SMTP, IMAP and POP servers. A real database is the proper way to do things. Email is my #1 app and I want to do complex queries on my archives.
So last year I bit the bullet and wrote a 50 line python program which imported all my mbox and Maildir format archives into a simple postgresql database. 600 megs worth over the last 4 years.
And another simple 50 line php program gives me a web database query interface. It suits my needs now and is much faster than searching through a big (but much much smaller) imap folder with almost every mail program I've tried. With some good design it really shouldn't be too hard to make an industrial strength email database system and I am surprised that it hasn't happened sooner in the open source world.
I think that direct SQL access to the mail database is preferred over IMAP. SQL gives you more capabilities and I find it less problematic than all the various combinations of IMAP servers and mail programs.
Slashdot Mirror
Yes.
--jeff++
But if you have a complex GUI, do take a look at QT/Mac from trolltech. It isn't FREE but it is quite good and allows your program to be portable between Mac/Linux/Windows.
--jeff++
Yes! And as I mentioned way above, maybe this court action would form a legal precedent, effectively weakening EULA's in general!
--jeff++
This EULA can be fairly easily attacked in court, and maybe doing this, the precedent would help weaken EULA's everywhere. Maybe?
--jeff++
My trickiest bug fix was very confusing.
TI 6701 DSP, custom embedded hardware, eprom for first and second boot stage, third boot stage is on flash.
The second boot stage had to be compressed to fit in the eprom. The first boot stage was limited in what it could do. The second boot stage in eprom was a subset of the flash code.
We would be fixing bugs and adding features in the firmware, but once in a while we would add a line of code and the firmware would crash in an entirely different spot, sometimes even on boot up.
Add one line of code elsewhere and the problem goes away. After a while we realized it did not matter what the line of code was that we added! it mattered where, though. We quadruple checked our cinit linker section and almost everything concievable including lost pointers and trashed code segments. The in-circuit-emulator proved almost useless with major crashes and special case things. So no debugger access.
What happened?
There are write-only latches that the boot loader needs to write to in order to control the front panel. At some point, the flash code was updated so that the last written pattern to the latches would be stored so you could query the value. When an eprom was made based on this code, the problem occured.
After the flash code was read from flash, and relocated to the appropriate spot by code safely residing in internal SRAM of the DSP, the internal code blinked a front panel LED. The latch buffer was still residing in DRAM, in the same area that the new code was loaded into!
So if one specific bit in the flash code was supposed to be a 1, the bootloader would change it to a zero and we would get a spurious crash.
If the bit was supposed to be zero, there would be no problems!!!!
--jeff++
And the new economy is defective because I did not read any of the ads on the site and can't remember anything other than the article! I wouldn't advertise there!
--jeff++
Imagine, tivo can obliterate their competition just by telling them that EVERYONE is performing hacks and copyright violations! ReplayTV will have to shut down all of their own customers! A great Denial Of Service attack!
--jeff++
It is not just the 'act of observation making something uncertain'. Energy is proportional to planck's constant times frequency. Since frequency is 1/time, this means that energy depends on time. The point is that the unobserved electron frozen in a 'snapshot' in time has no energy.
--jeff++
Hence the reason to use either open source software or open, standard file formats for mission critical data.
--jeff++
It depends on what your definition of Pi is. Is it the idealized circle? Or is it the measured circle? If Pi is defined and calculated by first principles assuming a non-changing flat euclidian plane, then Pi is a constant and calculatable.
If however you want to make Pi a measurement ratio, then you can never calculate it to arbitrary precision - you can only measure it. And general relativity already tells you that in our universe even if you had perfect measurement tools, you will measure a different value for Pi because of space being bent by mass.
Does that mean the value of Pi for the idealized circle is wrong? No.
--jeff++
Wow! $1,000 !!! that will teach them! it probably took them AGES to page the fine!
--jeff++
Doesn't the typical microsoft eula specify that the software is not to be used in life critical systems anyways?
--jeff++
Are you saying that the ancient mayans and the ancient chinese and the ancient hindus were friends?
--jeff++
Yes, I agree with your points. I think a key thing is to think about 'class string' as part of a library.... and this library is in itself a project all on its own. It has its own specifications and requirements and tests, and one of the requirements is for it to be reusable.
So in my opinion, it is totally feasible to split a large project up into smaller sub-projects. Some of which may have 'reuse' as a specification. But there is a fine line between what should be reusable and what should be not reusable... it comes down to a judgement call, and my point is that quite often those judgement calls come down on the side of too much abstraction and the 'illusion' of reusability.
"Damn, all this code we wrote with reusability in mind just does not fit well with this new application we want to make. Now we have to change the library and all the projects which depend on it!"
or worse: "Damn, this code we wrote with reusability in mind does not fit well.. let us make a bunch of adaptor classes to adapt them for use with our new project... it won't be as efficient as it could be but we gotta get this shipped and we don't have time to fix the library and all the projects that depend on it"
I have seen a number of cases where a 'bug fix' in one reusable component caused adverse effects in another project that used it! This is what I meant about the concept of two bugs cancelling each other out. Once a reusable component is changed for any reason - even just a bug fix - you must put all of your dependant projects through extensive testing again! It is not often clear what the ramifications of a bug fix may be!
One of the side effects of making your code 'reusable' is that you are less likely to hack it together into a mess. But proper design an coding should not depend on the reusability of the code... there should be good code everywhere.
--jeff++
P.S. unfortunately, under many c++ libraries you cannot reuse JUST the 'string' class. The string class usually implicitely pulls in all sorts of apparently unrelated things as well which may have their own issues. So for instance you want to 'reuse' the MFC CString class, now you are limited in your potential to port your code to another platform. So reusing code is not always a win as along with that reuse will come the 'reuse' of the original code's restrictions.
Those are all good points.
:-)
Another problem I have seen was where TWO different bugs mostly functionally cancelled each other out causing new intermittent problems.
I made a realization regarding strict-type checking languages versus dynamic typed languages.
Typically, people who are used to java and c++ complain about languages like python - saying that the compiler should catch static type problems at compile time and that languages that do not do this are inherently unsafe.
Then I realized that ALL of these people must not be running any real tests on their code! If they were running real tests on all your code (every line must be executed in your tests), then these dynamic typing errors would be easily caught ! those would be the easiest bugs to find.
Too often I have seen C and C++ coders compile their project.... No errors! Ship it!
Another issue I have been thinking about is the relationship between code reuse and unexpected behaviours. Code reuse (and object class reuse) is fine as long as all of the functionality and limitations of the object/code are known.
However for more complex class hierarchies I have seen people say '"I'll just inherit from this class publicly and change the public interface to match what I need for this project." - And then they are surprised when other pre-written code interacts funny with it. I'm not saying object-oriented is bad - I'm saying it is so common for programmers to break the basic concepts of OOP.
I had one manager who was adamant that for any medium sized project there ought to be NO time spent on making the code re-usable. Every line of code should be directly related to specific aspects of the customer's requirements/specification document. At first I thought he was crazy.
But after I saw some projects expand into massive class hierarchies just for the sake of the illusion of increasing the reusability of the code in other projects, I am starting to side with him a bit more.
Extreme Programming has at least some very good points about it. ie: don't add features until you know you need them. Otherwise they probably won't be tested properly and won't be a good match for the new use. You can't predict every environment that the code may be reused in. It is harder to do than it sounds.
So for high reliability systems I think one should have simple non abstracted code that can be measured, prodded, and always predictable. Then you can fashion your unit tests accordingly.
--jeff++
P.S.: scary thought/rant for today: How much C++ code do you see that is striving to be exception safe so that memory full errors will be caught properly? How many C++ coders understand that the default linux kernels and libraries will almost NEVER cause malloc() to return 0 and will almost NEVER cause operator new() to throw? Only virtual memory space is allocated. Real memory pages are only allocated as they are being used. Once all physical and swap pages are used, blammo goes your app (and possibly other apps on your system). In semi-critical systems, this is a real problem that is often overlooked.
Where is the real problem in this case? Part of the problem is that the c++ environment running on the default linux kernel does not conform to the standard.
The other part of the problem is that it is little known. If it were commonly known, people would be able to design around it (or change the kernel options). So people rely on what the documentation says, instead of properly testing the software limits.
I remember that. Is the guy with the glasses still alive now?
--jeff++
good points - Do you remember how many humans died in Episode 1? were there any at all? The robot attack force was a cop out on the potential violence rating had they been stormtroopers I think.
jeff
Who would have thought that Richard Stallman was correct all these years regarding free-as-in-speech software? How many of you just thought he was a paranoid lunatic?
From The Right To Read:
- Dan would later learn that there was a time when anyone could have debugging tools. There were even free debugging tools available on CD or downloadable over the net. But ordinary users started using them to bypass copyright monitors, and eventually a judge ruled that this had become their principal use in actual practice. This meant they were illegal; the debuggers' developers were sent to prison.
--Jeff++... In 2047, Frank was in prison, not for pirate reading, but for possessing a debugger.
Absolutely.
In my opinion there will NEVER be a 'standard' internet video stream format until there is a free-as-in-speech codec available for all platforms.
Until then, the potential capabilities of streaming internet video will continue to be unrealized.
MS and QT are too closed, and the Real server is way too expensive.
It is not rocket science anymore.
--Jeff++
This may be a great idea, actually!
Set up a EULA with LEGAL terms, verify it with a lawyer so that it does not constitute an illegal contract - Yet make it Absurd. THEN, get your friend to sue you over the absurdity of the EULA and let your friend win.
Would this then constitue a legal precedent against EULA's?
--Jeff
And this is just further proof, right??
jeff
Looks great so far! However I guess I have to manually create the postgresql database tables....
jeff
Maildir DOES work great, and I use it myself for non archived emails.
/bin/ls: Argument list too long
They work great until you have lots of messages.
My postgresql email database contains 54,244 email messages. Current filesystems do not like having that many files in one directory. A filesystem is NOT a database - it only has one field (filename) that you can do queries on.
The database allows me to properly index the fields such as 'date', 'subject', and 'from' - for instance:
select count(*) from msgs where msg_from = '<myemailaddress@domain>';
returns a result in a fraction of a second because it does not have to iterate through all my messages. Whereas a Maildir directory with 5000 files in it can not be groked with wildcards. Try it!:
$ ls *
bash:
A big problem with the concept of putting only metadata in the database and the content in the filesystem is that you end up making the system even more complex as you need two different ways of accessing the data and the data is split between two sources.
The two different ways of accessing the data is a problem when you want to access the emails from another computer. For me it is simple - my Mac OS X machine can make a postgresql connection to my linux server and do queries including message content easy and quick.
SQL databases nowadays handle large text fields and blobs just fine and make it dead simple to back up, process, or query all the data.
'Folders' can be just SQL VIEWs and are way more flexible than seperate Maildirs for each folder.
By the way, I would LOVE to see an imap server and email client program handle 54,244 messages in one folder that I can view and search different ways without it bogging down or trying to cache 600 megs of data locally or trying to make a single list box with 54,244 items in it (and usually crashing in the process)
Please show me one so I can use it instead of writing my own smtp to postgresql gateway.
--Jeff
DBMAIL looks cool, once it supports postgresql it would be awesome.
I have been dissapointed in general with most SMTP, IMAP and POP servers. A real database is the proper way to do things. Email is my #1 app and I want to do complex queries on my archives.
So last year I bit the bullet and wrote a 50 line python program which imported all my mbox and Maildir format archives into a simple postgresql database. 600 megs worth over the last 4 years.
And another simple 50 line php program gives me a web database query interface. It suits my needs now and is much faster than searching through a big (but much much smaller) imap folder with almost every mail program I've tried. With some good design it really shouldn't be too hard to make an industrial strength email database system and I am surprised that it hasn't happened sooner in the open source world.
I think that direct SQL access to the mail database is preferred over IMAP. SQL gives you more capabilities and I find it less problematic than all the various combinations of IMAP servers and mail programs.
Jeff
Your guesses are correct.
Each altivec register is 128 bits.
You can use them as 4 32 bit integers, 4 32 bit floats, 8 16 bit integers, or 16 8 bit integers.
There is a lot of information on altivec.org
Jeff