(def buttons(user sname doc)
(tag (div class "buttons")
(do (button user sname doc 1 "skip" "not interesting")
(button user sname doc 2 "next" "more like this")
(button user sname doc 4 "love" "more from this site")
(clear))))
Lol. I found it useful, because it got me thinking about the fact that all the tags in the code are really pr's under the hood. I wonder if the code gets evaluated in the wrong order. With most code bugs in evaluation order wouldn't matter as long as outer functions picked up the right objects for their arguments. But here the entire tree shares a single channel.
HN: Too crowded, too fast. I can't remember users from one day to the next. Getting down-voted for slightly different etiquette that breaks 'secret rules' sux.
-Note however, that if you think you could actually go out and start a successful social news site of any sort, programming or non-programming, you might consider applying to Y Combinator.
I've been working something, different, for about 6 months, hackin on weekends evenings. I don't want to quit my job - I like my job. I get paid quite well so funding isn't something I think about. I'm happy tinkering along until I get my vision down pat. 50%-60% complete, but the remainder will take about 6 months for me (dependant upon how much I golf this year). Golf is more important than you might think! :)
-Starting a new social news site is really hard though. It's much more of a marketing challenge than anything else.
hmmm.... idealistically I had hoped that doing this might grow the arc community, provide more things for the same community to engage in.
are there other communities you will also attract some seed population from
I think so, if I re-tool the forum well enough that conceptual domains are not all over the place, that could happen.
Do you want to give an example of the kinds of topics you have in mind?
yup.
* Right now I proxy from apache to my arc server. I was
reading about the Nginx webserver and wanted to know if
anyone had proxied from Nginx to Arc and could 'dicuss'
the worth-it/not-worth-it setup&configs of it. Nginx docs
are bad and most blogs only discuss integration with
mainstream technologies. Really this is a side topic not
truly arc related.
* I was reading about 'coffee script' and want to know
if anyone has used it. I was thinking of writing a
arc->coffe-script tool, but I would like to post
questions on it first.
I think that running Nginx as a frontend to Arc is relevant since there may be issues related specifically with the interaction between the two. Of course there might not be, but how would you know until you got into it? For example I'm running Perlbal as a frontend to Arc, and it gets messed up when Arc send a response without carriage returns in the headers but has a carriage returns in the beginning of the body. That's something that it's unlikely that anyone else is going to run into.
And if you're thinking of a Arc -> coffee-script tool, who knows, there might be some things that even if coffee-script is cool in general, might be unusual or problematic in the context of Arc.
I suppose "talk about anything as long as you include an obligatory Arc reference" might be going too far :-) but I suspect the line is further out than you've drawn it ^_^
I'd go farther - it doesn't even have to include an obligatory arc reference. The number of users here is small enough that the usual rules are less important. Especially if it's occasional (the front page is still mostly arc) and from someone we recognize, I think the handful of people here prob won't mind (or they'll respond to this if they do ;)
I'm finding out that creating a new destination site is crazy hard to do. The internet is mature; all of us have our habits, and it takes a lot to change. Just go where your audience is. If they don't like what you say they'll let you know, and you can then iterate.
hmmm. Good point. I suppose if no one replies to my 'other' items here, then a side forum probably would not work anyhow. And if I don't get replies to most of them - I'll probably get the hint (at least one would hope)... :)
At this point, I think that more posts is probably a good thing, even if they're only slightly related to arc.
A lot of people like me probably don't check all that often because there isn't much going on. If we can increase the number of comments/submissions to a slightly higher level, it will probably encourage more return visits, and better community interaction. Sure, the quality should be kept high and this is the arc forum. But by all means, submit "other" posts, if only so that there's a reason to check more frequently. That would give the arc community a greater appearance of life, and allow the posts and questions that "really matter" to get more attention as well.
My my own personal market scanner I developed using Arc, jQuery & jqGrid.
Using every stock symbol on the TSX & TSXV the app goes out and web scrapes the last 200 days of history
from well known sites on the internet. It parses the files, loads into memory, creates a few data factors, and stores only the data of interest.
The interface code is jqGrid ( http://www.trirand.com/blog/ ) Have a look, I've been pretty impressed as the plugin has so many options, configurations
and integration points. One nice thing about it is that it already handles JSON for data feeds and callbacks. Arc, as you may know, has a few handy json parser/combinators for use: (see http://awwx.ws/). One thing about jqGrid is that it can be brutally slow on IE6.
Anyone find any grids that work well on IE6? Any insight here?
I've limited the data set to OG (Oil & Gas) just so I limit the page load and I will only leave up until Monday (by then I have to use to find my stocks again).
Check out the buttons on the bottom, there are some hidden fields to filter on. I chose the factors based upon Stan Weinstein's book:
( http://books.google.ca/books?id=k7dJZbOOkLEC&printsec=fr... )
I am posting the example for discussion sake. I don't plan to release the code since it's too heavily
integrated into a larger body of code. There's client side code for jqGrid that's exposed in the app if you're interested and I am more than willing to answer questions.
Ah, here's a technical question: are you using arc for html parsing? I couldn't see how to, so I just built my crawler with python and beautifulsoup writing json.
I just find the subset lines by finding start & end indicator points then write a custom parser for the subset section. I might be wrong, but for my needs a full-blown html parser would be much slower and I'm hitting the same file structure every time (for each stock).
All data is limited to the last 200 days so yes, but I don't store lowest, just highest and last and price prior to last. I plan to add more stuff, but I just got the basic stuff I need.
The Volume & Price Factors are the % of the last relative to the highest. I.E. Volume Factor 300 means the last volume is 300% greater than the highest (in 200 days), 100% means they are equal.
Price Pop is the percent the last is relative to the prior.
You can drill down by creating a query using the magnifying glass at the bottom.
You can move column order by using drag/drop within the column dialog.
Good questions- I was expecting technology questions. lol. :)
They are the highest 'close' attributes in the last 200 days. The volume would be the total volume for a day. The price would be the close price for a day.
The highest excludes the last close.
Header descriptions could be much better as you point out... I wasn't too worried as I had no plans for a product.
Much better. When I revisited I went much further and clicked through those option buttons. Since then I noticed one more thing: The space on the left side showing the history fluctuates in size quite a bit and only takes advantage of a third of the vertical space my screen has available. The fluctuating size forces me to chase the <older and newer> links as they move around the screen. Might I suggest moving the older/newer nav links to the top area so they remain in a fixed position, then allow the history to fill to the bottom of the webpage. My 2 cents :).
[Edit: or even have the links both atop and bottom]
I added pagination links to the top, and made it 25 links per page. Since there's links at the top I'm less concerned about requiring scrolling to paginate :) Thanks for the suggestion.
I think there's a bug. I ran finance from home yesterday ->
http://readwarp.com/station?seed=finance# and stepped through the history section. On my lunch hour today I gave the same input... and the same history is still there. Given I don't have a user account and I am at a different IP, I think everyone get a shared history.
Earlier you posted...
"so if somebody else makes a request while you're browsing, you see the history for their station when you hit older or newer.."
I don't think anyone one else made this request while I was browsing and these are the links from yesterday.
That quote was a bug report, and it was already fixed at the time of writing :)
The way it works right now: stations are distinct, and have their own history, but are shared across users. The fact that the same history is still there just means that nobody else used the finance station in the meantime. Am I misunderstanding something?
Why don't we take this offline? My email is in my profile. If you send me email I can set you up with a user account. It's extremely unpolished, but you'll be able to import your own feeds and so on.
This goes for anyone else reading this, btw. Send me email and I'll set you up with your own private feedreader on readwarp.
Thanks for posting the app. I wish more arc apps would pop up like this.
Some things I noticed beyond the obvious buttons being buttons:
It would be nice to have some default or optional filters so porn feeds and such can be filtered.
I am still trying to figure out if it works as it supposed to or not. The site says to input your favorite
site or blogger, so I put in the following sites/cases and here are the results:
http://arclanguage.org -> Hmm, this may suck....
http://arclanguage.org/forum -> Hmm, this may suck....
http://arclanguage.org/rss -> Hmm, this may suck....
arclanguage -> Hmm, this may suck....
arclanguage.org -> Hmm, this may suck....
arc language -> found article on arcfn which only talks about arduino
peace -> Aero Snap makes Australian Open TV cameo
http://www.google.com/finance -> TurboTax 2009 Discounts For Early Birds
My Money Blog (nothing to do with google)
So is this expected? If so why?
Also... A few times I tried the page stopped responding or took a really long time.
Yes I noticed the timeouts in the logs. I'm going to look into that.
Arc language forum wasn't in the feeds I crawled (I should have checked this one term, d'uh!), so the program doesn't know anything about, hence the 'this may suck' message.
Peace: I'm trying to be smarter than just matching on keywords. That didn't pay off here.
with google.com/finance, it tried to find finance news. It's smart enough to know that that URL isn't about google.. will you try that station again, vote on a few stories, tell me what you thought?
Will you try out a few more blog/site titles? I'd love to get the coverage of my crawler stress-tested like this :) Thanks for trying it out like this.
Re the porn feeds: I'm just not going there. I noticed one feed that had slipped through in the logs this morning, and I've deleted it, so it shouldn't show up again.
thx - that's what I had in mind -> to filter them out. I should have chosen my words more carefully. :) I was kinda shocked to see the link pass by in the ticker bar. Though I must admit I did click the link just to make sure it was what I thought it was.... consider it testing. :) lol.
Autor here. The implementation on github is for arc 2 and is really outdated. I've got a lot of improvements, including support for arc3 and a self hosting compiler that I haven't released yet. I've stopped working on it after seeing how slow Parrot is at the moment (or at least how slow it was a few months ago). The implementation is quite complete and can load a slightly modified version of arc.arc (mostly to avoid overriding internal functions) but could be easily modified to load the official arc.arc. To give an idea of how slow it currently is, just loading arc.arc takes a few minutes (but it can be pre-compiled, so startup is fast). On my computer it took something like 9 minutes, after an optimization to my code generator I brought it down to 4 minutes, and after a new release of Parrot it went back to 9 minutes (without changing my code, it was the VM's fault). After that, I stopped the development. Another show stopper is that just spawning a new thread makes the VM segfault, thus preventing me to run a slow version of news.arc.
If someone is interested, I can push this new code to the github repo. It probably needs some modifications (not too many hopefully) to work in the latest Parrot, since they've been changing a lot of stuff in the last months. Keeping up with these continuous changes is also among the reasons why I stopped the development. Every month, after a new Parrot release, something broke because the API, or the build system, changed.
I believed that after the version 1 there should be any modification in the API. You have the same problem with Parrot than the rest of the developers. I think the only proyects that are still update are Partcl and Rakudo.
I follow Partcl becouse I am a Tcl user. It is being rewriting in NQP. The Pir version could pass 4089/7397 test from the official test suit. It a lot slower that the official version.
Can you explain how is possible(theorically) to use libraries from various languages with another language in Parrot? The library have to be compiled to Pir?
They're still deprecating stuff after every release, and the following month deprecated stuff is removed.
All languages on Parrot compile down to a common denominator, Parrot's assembly language (PIR), either dynamically at run time or before execution. It has an object system and common function call conventions, this means that as long as a language supports calling functions and a compatible object system (or some wrappers around it) it can call any function and use any object as other languages running on the VM. Arc doesn't have an object system, so some wrapper would be needed. To get seamless interoperability the language implementation should define a mapping between the language's primitive types and the corresponding Parrot's types. Primitivearc currently lacks the wrappers around the object system to interoperate with object oriented libraries (adding them wouldn't be a huge task I think), but it can already call any function loaded into the VM. To call a Perl 6 function (this doesn't work because 'load assumes an Arc file but it could be easily modified to call the correct compiler, since the mechanism is already present in Parrot):
I haven't done any testing along these lines, so I don't know what the actual answer is, but I don't think adding more Arc instances than you have CPU's would do anything except use up more memory...
edit: though I suppose it's possible that garbage collection times might not scale linearly... if it takes more than twice as long for the garbage collector to run on twice as much data, then a larger number of smaller processes might give you some kind of performance benefit.
