Arc Forumnew | comments | leaders | submit | pg's commentslogin
3 points by pg 3354 days ago | link | parent | on: It's been a while since pg's appeared here?

Kind of correct. It depends on the degree to which you count news.arc as part of the language. I work quite actively on that.

-----

2 points by bhoung 3353 days ago | link

Thanks for the replies.

-----

7 points by pg 3354 days ago | link | parent | on: It's been a while since pg's appeared here?

While I still hack in Arc constantly because I'm always tweaking HN, I haven't made dramatic changes to the language itself lately. I only seem to be able to work on 2 things at once, not 3. Since YC is a given, that means I have to choose between hacking and writing. Lately I've mostly chosen writing.

I should release a new version though. News.arc is greatly improved since the last release.

-----

2 points by garply 3354 days ago | link

That would be great. Seeing others share code - even tools that I don't currently use - makes me want to push code as well. When I push code and no one else does, I feel a bit like my work is unappreciated and want to stop sharing. I suspect there is type of momentum at work in the formation of vibrant programming communities. Seeing Arc 3.2 would be motivational.

-----

3 points by akkartik 3353 days ago | link

Yeah. I have this hazy sense that people submit lots of bug reports on this forum, but no idea if any of them are ever integrated.

-----

2 points by aw 3352 days ago | link

iirc all reported bugs fixes were incorporated by the arc3.1 release. (Releases haven't always incorporated all fixes reported up to that point, the atomic-invoke fix was particularly alarming and took several releases to make it in).

The only bug I'm currently aware of off the top of my head in arc.arc is readline, which was reported after the arc3.1 release.

There are a couple of known issues with the Arc runtime (i.e. the queue bug you found which seems likely caused by unsafe mutation of immutable cells, nested quasiquotation) which have prospective fixes, but neither tested throughly enough that I'd personally say, "oh, why yes, you should go ahead and switch HN over today".

-----

1 point by hasenj 3351 days ago | link

> I should release a new version though. News.arc is greatly improved since the last release.

Just curios, do you have a public git repo, or anything like that?

-----

1 point by pg 3504 days ago | link | parent | on: What does 'nil buy us?

I like using the symbol nil for the empty list.

-----

2 points by akkartik 3504 days ago | link

Any code that interacts with scheme code ends up having to jump through hoops like the JSON parser did: http://arclanguage.org/item?id=10799

I suppose the answer is to just make (is nil '()) true.

-----

2 points by pg 3661 days ago | link | parent | on: Bug: (downcase nil) should return nil

Oops, yes. That solution will work.

There's a corresponding bug in upcase, which I dealt with thus:

         sym    (if x (sym (map upc (coerce x 'string))) 'NIL)
Note that NIL isn't false.

-----

1 point by akkartik 3660 days ago | link

I've been treating (upcase nil) as nil, since (coerce nil 'string) isn't "nil". Haven't had occasion to need this so far, though.

-----

1 point by pg 3704 days ago | link | parent | on: Changing account to "aw"

I ported your karma, if you care about that.

-----

1 point by aw 3703 days ago | link

Thanks!

-----


I broke lines that would have been more than 80 characters.

-----


A better solution might be to supply an explicit 80 as an argument to asv. I.e. change bsv to:

    (def bsv ()
      (ensure-dir postdir*)
      (load-posts)
      (asv 80))

-----

2 points by revorad 3721 days ago | link

I tried that but it still doesn't solve the problem that my ISP blocks port 80 by default.

-----

2 points by pg 3741 days ago | link | parent | on: Bug using 'thread in 'for (w/eventual-patch)

Thanks for catching this. I fixed both for and down.

-----

3 points by pg 3739 days ago | link

Oops, spoke too soon. This new version would mean you can't modify the variable within the loop, which is something I meant to be possible, and in fact use in e.g. urldecode.

I believe the strange behavior palsecam discovered is actually correct. But if anyone wants to make the case that it shouldn't be, I'm open to being convinced.

-----

3 points by conanite 3738 days ago | link

I believe the strange behavior palsecam discovered is actually correct.

I believe the behaviour isn't even strange. Inside your for loop, (thread ...) creates a closure which references i, and when the closure is invoked, it looks up the current value of i, which has in the meantime changed.

  (def test-strange-behaviour ()
    (let fns (accum x
      (for i 0 10 (x (fn () (prn i)))))
    (each f fns (f))))

  (test-strange-behaviour) ; displays "11" 10 times
javascript has the same behaviour:

  <script type="text/javascript">
  var fns = [];

  function strange() {
    for (var i=0; i<3; i++) {
      fns[i] = function () { alert(i); }
    }

    for (var j = 0; j < 3; j++) {
      fns[j]();
    }
  }

  strange(); // alerts "3" 3 times
  </script>
The workaround is to outsource the closure-creation to another function:

  (def loop-work (i)
    (fn () (prn i)))

  (def no-strange-behaviour ()
    (let fns (accum x
      (for i 0 10 (x (loop-work i))))
    (each f fns (f))))

  (no-strange-behaviour) ; displays 0 up to 10
This works because now the closure references the i that belongs to the invocation of loop-work that created the closure; nothing modifies that i. The strangeness has nothing to do with threads; it's only about closures.

-----

1 point by palsecam 3738 days ago | link

Warning: quick (& dirty) reflexion and patch.

> you can't modify the variable within the loop, which is something I meant to be possible

Yes useful feature, so maybe:

  (mac for (v init max . body)
    (w/uniq (gv gi gm)
      `(with (,gv nil ,gi ,init ,gm (+ ,max 1))
         (loop (assign ,gv ,gi) (< ,gv ,gm) (assign ,gv (+ ,gv 1))
           ((fn (,v) ,@body (= ,gv ,v)) ,gv)))))
?

Very lightly tested, only in the online repl, but seems OK although a bit ugly.

   arc> (for i 0 10 (pr i " ") (++ i))
   0 2 4 6 8 10 nil
   arc> (do (for i 0 10 (thread:pr i " ")) (sleep 1))
   0 10 8 6 4 2 9 5 1 7 3 nil
   arc>	(urldecode "80%25%20-+20%25")
   "80% - 20%"
   
Anyway, it'd make the def of 'for more complex, less clean, and the perf a little bit worse.

> I believe the strange behavior palsecam discovered is actually correct. But if anyone wants to make the case that it shouldn't be, I'm open to being convinced.

I don't really care but I like to play the devil's advocate :-)

It's a bug for my brain. I'd sleep better at night if I knew I could use 'for in any situation, even w/ threads. 1: Simpler. The less stuff I have to keep in mind (e.g: "oh right, and remember 'for is not thread-safe"), the better. 2: More robust. I like to know I can "stand on the shoulders of giants" and that edge cases are handled correctly.

It's a bug because you call it "strange" and considered it as a bug (and so do I). Maybe we're wrong and we can't see the real problem(s) behing using threads in a loop construct, or maybe this behaviour is just a free overhead that shouldn't exist, and we're right.

-----


thanks, fixed

-----

2 points by pg 3742 days ago | link | parent | on: IP Source Domain Bug

oops, fixed

-----

More