* cleared my browser cache.
* flushed my airport cache and renewed the DCHP lease.
* I had my machine off last night.
Turned it on this morning and loaded the same process. and it's happening everytime. That kind of replication and consistency suggests it's not just myclient flaking out correct?.
I mean it could be, but why ? It's like my client is flaking out because of the code loaded into it ? Maybe bad javascript or meta tags or something the browser need to process so it flakes out?
Anyway I just don't believe it's not a real error. There's more to it than clients flaking out.
T.
You'll get an "tcp error writing" when in your browser you navigate away from a page before the browser has finished downloading everything.
Usually Arc sends the entire response and closes the connection. When the browser doesn't wait, it closes the connection. Arc is then complaining that the connection has been closed on it.
If you're absolutely sure that everything has been loaded in the page before you click on anything, that would be something to look into further.
I had thought of that originally, but the nature of the app is where a user would log in for 10-20 minutes per day (at least to start) and read the data. The maximum possible audience is limited to about 1000 people. Currently users pay $600 to 800 per user per month to the competition (data by email only).
I am thinking I should increase the cost a little to account for the freeloaders.
Are you able to offer all the data your competition does? $300/month would be half off ^__^
Also, is there some way to include the user's name in the downloaded data? No doubt they could edit the data to remove their name before passing it on to their colleagues, but that might be more trouble than it's worth to them.
no doubt they could edit the data to remove their name before passing it on...
I could as they do - watermark on PDF, but my model is to make the data more accessible/usable and in doing so I am making it easier to freeload, hence why I am trying to make it cheap enough that users would just sign up and pay the monthly fee and get the benefits of some customization, rather than freeload.
Also the real money isn't in the data it's in other things, but I need the audience so I'm going to offer it really cheap, get the audience, get them famliar with the software then sell modules (the real pot of gold). I could jut get it out there for free, but I need to learn this pricing/billing stuff.
That all sounds good, my only thought is if you are charging $5 for something your market is used to paying $600 for, you may appear to lack credibility... imagine going up to a guy who gets $100 haircuts and offering him a haircut for $3. Would he take the risk of getting a $3 haircut, even if it looks like it would be just as good as his usual $100 one? But, of course, if they're getting other stuff than just the data for the $600, offering just the data for $5 plus expensive modules might be perfect ^_^
From my cursory look, pg has fixed many if not most of the core issues that anarki resolved. (ie cut fn not handling -1, providing a static directory for files to be published, added some basic math functions - sin cos etc..).
I would suggest starting a new branch with arc3 and if the libraries from anarki are still relevant then people will incrementally add them. This way were not integrating a bunch of code just because it's there - even though it's no longer useful.
+ just because you make them work with core arc3 files doesn't mean there will not be conflicts - as example the int function in the anarki math.arc library conflicts with news.arc only (as pg added an int function).
Some of the things anarki adds that are not in arc3 are tremendously useful.
For example, help strings and the 'help macro to access them, and similarly, the ability to call up any function or macro's source with 'src.
I do think the idea of integrating anarki code incrementally is probably the right way to do it. To this end, I've forked anarki's "official" branch (http://github.com/rntz/arc), and I've been applying CatDancer's "minimum-distance-from-arc" patching philosophy (http://catdancer.github.com/sharing-hacks.html). We'll see how many things from anarki I end up converting this way.
When you're done with you're patching process (I wouldn't mind helping) we should probably merge it back into nex3's copy, as his has public commit access.
1. On desktop: right click -> new -> shortcut
2. Enter a target of: C:\MzScheme\MzScheme.exe -m -f as.scm (or where ever mzscheme is installed)
3. Name the shortcut Arc3
4. Find the shortcut on desktop; right click on it and select properties.
5. Add the path to the arc directory in the 'start-in' box. (example: C:\arc3)
Launch shortcut.
This will get you started with pg's release, but you will need to make changes to account for windows:
(and I might be wrong, but it would seem that since were now using scheme 372 we no longer need to account for the sticky bit problem that anarki accounted for - this was mentioned as a reply in the above post).
notes:
* ensure-dir is an existing function (so replace it),
mkdir is new so add it.
* in the new arc3 you need to take out the qoute on
make-directory:
