Arc Forumnew | comments | leaders | submit | i4cu's commentslogin
2 points by i4cu 158 days ago | link | parent | on: Beunto an experimental app builder

Hmm, haven't seen that one. I've done a search on my entire code base tree and 'randid' is nowhere in my code (of course that may not matter when it's a compiled jar file that's running).

Can you tell me your OS? I've only been using OSX so it's possible it's chrome on Windows? Versions would be great too, if you can :)

And is that a js error or a server error? I'm hazarding a guess it's a js error given I'm not seeing any errors on the server.

Thanks!

-----

2 points by i4cu 158 days ago | link | parent | on: Beunto an experimental app builder

Hey thought I'd post this over here (even though it's not really arc related!).

note this is in the very experimental stages. I wouldn't try it on mobile or IE yet.

Posted it on HN too,

https://news.ycombinator.com/item?id=19902880

but I think maybe it's a little too Alpha for a general audience.

-----


The 'Datafy' and 'Nav' protocol interfaces look really interesting.

From what I gather using those along with Clojure 'Spec' allow you to create ad hoc, generalized interfaces as an abstraction layer accessing an infinitely large lazy tree of 'things' (provided these 'things' are data or can hold meta data).

Unfortunately I have yet to see anyone really use it in the way I imagine it can be. I'd like to see a web 'req' var with the ability to drill down through the server-code<->js-code barrier (via the session and connection protocol) all the way down into the dom and the js application state. That would be really, really cool.

Also, I've been building a general purpose app builder (for web apps). This app building process is currently working, but in the future I'll need build a more advanced inspector and a designer. Since my stack is Clojure from server to js I'm wondering if it makes sense to build the inspector on top of that trio of technologies then attach the designer to it.

Someday I'll get to do that! ... I just know it. :)

Edit: for those who wonder what this has to do with REBL... these are the core technologies that REBL is built upon.

https://clojure.github.io/clojure//clojure.datafy-api.html

-----

3 points by i4cu 177 days ago | link | parent | on: Ask Arc: Arc forum RSS

Are you just looking for this?:

http://arclanguage.org/rss

-----

2 points by shader 177 days ago | link

That looks good enough for now, thanks!

At some point it would be nice to have a feed of full-text items as they get posted (including comments), but I can work on that separately.

-----


> Robert Tappan wrote the server code of the small company in Common Lisp.

Probably should reference Robert with his last name Morris? I imagine not that many people would know his middle name. I know I didn't.

-----


As a side question. Does anyone understand why they have both an arc news app and a discord forum? Seems to me like that would just separate the community.

I don't 'discord' so maybe someone else has insight?

I do wonder how much activity occurs in one vs. the other as it could be a good measure to determine which one is more appealing to a general audience.

-----

2 points by i4cu 239 days ago | link | parent | on: Using Arc in Production

> How useful would Arc be in a production system?

I've used it in production at multi-national organizations.

In fact that's how I learned to code. 10 years ago I was a business analyst who couldn't get the dev group to work on my projects in a timely fashion. The ability to use arc was in reach for me, even though I had no programming experience at all.

I actually wrote and released 2 internal apps and 1 external app that had good use (a few hundred users using it daily/weekly to get their jobs done). This was in production for a few years until I left in 2012. I'm pretty sure they're not using these apps anymore.

> What sorts of systems would it excel in and what sorts would it be unsuitable for?

I think its primary strength is the short learning curve. I also I think it's unsuitable for anything which needs to use existing db connections. Even though I did hacks to make that work it's the primary reason my apps could not be adopted by the dev group.

> What could be done to alleviate for Arc’s lack of features?

  * better db integration
Or if there's no interest in db integration then make it focused on compiling to js for mobile devices where db integration is less of an issue.

edit:

> In fact that's how I learned to code. 10 years ago...

lol, my first post on arc from 10 years ago:

http://arclanguage.org/item?id=8658

It's kind of ironic my first post was about a most recent topic[1]:

  "After playing for a bit I noticed my "set x" functions were 
  clobbering each other...so I started converting all my function to use 
  "let" statements."

 "why wouldn't the ARChitects of LISP or ARC make a set like 
  function that is global within a function ?
1. http://arclanguage.org/item?id=21187

Also, It's really embarrassing reading my old noobish questions/comments. I think we need to take this forum down and start a new one to preserve any sense of pride I could possibly have. :)

-----

3 points by jsgrahamus 239 days ago | link

Thanks for this, "Thaddeus".

Regarding db integration, I recently read a bit on Jarc (arc on Java - http://jarc.sourceforge.net/), and the author specifically added in that ability.

-----

4 points by akkartik 239 days ago | link

Wait, you're thaddeus?!

-----

3 points by i4cu 239 days ago | link

Yep... I thought you knew..

http://arclanguage.org/item?id=20276

-----

2 points by akkartik 239 days ago | link

Ah! Sorry, my memory's not so great these days.

-----

3 points by rocketnia 239 days ago | link

I totally forgot this too. XD

-----

3 points by i4cu 240 days ago | link | parent | on: Variables & scoping complaint

This definitely not great, but having to use 'with' is not the real issue for me. In fact if you read through the code you'll notice that this style is often used deliberately (i.e. some people might argue that it's a feature).

I think the bigger issue is that global vars can be used without any errors or conflict warnings. So someone else can create code which sets globals which then gets loaded via libs and will pollute your program. So you could have lib#1 set var 'x' only for it to get clobbered by lib#2's version of var 'x' and arc just ignores this. That's bad. Really bad.

-----

2 points by krapp 240 days ago | link

>So you could have lib#1 set var 'x' only for it to get clobbered by lib#2's version of var 'x' and arc just ignores this. That's bad. Really bad.

And how often is it intended behavior? How often does one want to have a macro parameter or apparently "local" variable overwrite an existing symbol globally and arbitrarily?

I can see it being useful in the case of "hot patching" code to just redefine a function, but that's still kind of crazy, since now the source code and running code are no longer the same. Might as well just edit the file and reload it, and have one source of truth.

It seems like an anti-feature. Something that seemed like a good idea in theory, but which in practice does more harm than good.

-----

2 points by akkartik 240 days ago | link

I'm not following the two of you on precisely what this anti-feature is. Assigning to local variables using '=' does not create new global variables. Can you share a code sample showing what you're talking about?

-----

1 point by i4cu 239 days ago | link

> Assigning to local variables using '=' does not create new global variables.

We're referring to the original posts problem where using = inside a function can redefine global variables:

  arc> (= data* '(green red)) 

  arc> (def my-fn () (= data* nil))
  #<procedure: my-fn>
  arc> (my-fn)
  nil
  arc> data*
  nil
Now my comment was referring a bigger problem that falls out of this 'feature' or 'anti-feature' (depending on your point of view).

assume you place this in html.arc

  (= data* '(blue red))

  ; (add-color 'purple)
  (def add-color (color)
    (push color data*))
    
Then I create apple tracker library 'lib/apples.arc' with:

  (= data* '(green red))

  ; (add-apple 'golden)
  (def add-apple (color)
    (push color data*))
Now at the top level of my progam:

  (load "lib/apples.arc")
  (load "lib/html.arc")
; now say the first apple in storage has gone brown:

  > (string (car data*) " has gone brown")

  "blue has gone brown"
say what? my blue apple has gone brown?

why is there no warning or error on loading my lib? That's pretty bad IMO.

-----


It's cool, but it's doing a new page request per interaction and the page load takes at least a second. It also has a looong painting operation. :(

This is where js would be handy - right? Personally I would just update the dom element and send a http post in the background.

I get that it's just a toy, but still it shows that languages* should have a good client side story too. Maybe some Lumen integration?

* that are for the web.

edit: reminds me of the million dollar homepage http://www.milliondollarhomepage.com/

-----

3 points by krapp 251 days ago | link

>This is where js would be handy - right? Personally I would just update the dom element and send a http post in the background.

If it's to be done in JS, might as well implement a drawing tool in an actual canvas element.

I've seen tutorials that are reasonably simple. The complicated part would be actually saving it. It is possible to export a canvas as a png and upload it with an AJAX request but I don't know how cross-browser compatible that is.

-----

2 points by shawn 251 days ago | link

We tried. It was almost a disaster.

We started out by making an EventSource endpoint and using JS EventSource object to get updates. Seemed to work great.

Pushed it live.

To everyone on the site. Not just to the people on /l/place. Oops. Mistake #1.

Mistake #2: I was aware that Arc kills threads that take longer than 30 seconds, but I was unaware that EventSource automatically tries to reconnect. Welcome to the DoS party.

With no way to tell the clients to stop. Mistake #3.

It was only live for about 10 minutes, but it took around two hours before the last few clients finally refreshed their browser and stopped DoSing the endpoint. The server absorbed the extra traffic like a champ, but the server logs were ridiculous for about an hour. Lots of "client took too long" error messages spit out by Arc every second.

Sooo yeah, submitting changes via JS is easy. Getting updates is the hard part.

Could poll. But then that's still hammering the server. Moreso than it already is.

It's probably a feature that it's painful to use. Only the determined will use it for art.

That said, if anyone has ideas for how to tweak arc for performance for this scenario – and remember to calculate how much memory is used by how many simultaneous sockets are open – I'd be willing to try again.

-----

3 points by i4cu 250 days ago | link

Reads like a really good horror story :)

> I was aware that Arc kills threads that take longer than 30 seconds...

> Sooo yeah, submitting changes via JS is easy. Getting updates is the hard part.

That's why I suggested a post request...

Just deliver the page and create an api end point, on the server, that gives you the last x changes from the change log.

With that ajax request, you could return these net updates for the client and use client side js to apply them to the dom. You could even create a trivial js debounce[1] algo to throttle requests if you wanted to go even further.

1. 'debounce' for those who don't know -> https://davidwalsh.name/javascript-debounce-function Only I'm suggesting it as a way to throttle ajax reqs.

-----

3 points by shawn 249 days ago | link

Yeah, it was worth the effort to make the drawing code client side. Someone showed up and made a software rasterizer.

Timelapse: https://www.youtube.com/watch?v=G0sG08jKCTI

-----

2 points by krapp 247 days ago | link

why not go all the way and render client-side in a canvas as well?

As it is, the more "pixels" you have, the slower the page loads. You could probably have just a single canvas and a single event handler.

You could preserve functionality for non-js users by using an imagemap (assuming browsers still even support those) or sticking the existing code in noscript tags.

-----

2 points by krapp 246 days ago | link

OK... I don't know where I got "single event handler from," that obviously wouldn't be true, but it would still be simpler than having each pixel be a separate HTML form....

-----

1 point by shawn 245 days ago | link

Wanna hop into discord and we can chat about the design? https://discord.gg/qaqkc9z

The repo's open, and I could help get you set up with it if you wanted to work on some of this. https://github.com/laarc/laarc

It should be a matter of:

  git clone https://github.com/laarc/laarc
  cd laarc
  make
  rlwrap bin/arc
  ((load "news.arc"))
and then http://localhost:8080/place

-----

2 points by krapp 245 days ago | link

Let me actually see if I can come up with a POC first, at least for the canvas and javascript. Realistically, since it's just GET requests that don't need authentication, I shouldn't even need laarc running, I can just send the same requests by AJAX.

-----

2 points by shawn 245 days ago | link

https://www.laarc.io/place.json is the API, by the way! I should probably mention that somewhere.

-----

2 points by shawn 250 days ago | link

Kay, it's all client side now. Have fun!

-----

3 points by i4cu 250 days ago | link

Much better.

I will say; I did a page reload and noticed the color pick was still in place and had to go hunt for the x. I expected it to reset, but I'm not sure if you see that as a bug or a feature :)

also, it looks like the client side is pure js... Is Lumen not up to that task? just curious if you tried that as it might be nice if, someday, we could get to the point where this kind of stuff could be done in arc.

-----

3 points by shawn 249 days ago | link

Thanks for mentioning that. It's a bug.

The trick to clear the x is to scroll up and click on the color palette.

Here's a timelapse for the curious. https://www.youtube.com/watch?v=G0sG08jKCTI

-----

2 points by i4cu 252 days ago | link | parent | on: Show Arc: seamless interop with racket

This is awesome. :)

> If you want to switch back to arc, you can use (%do ...)

Personally I would prefer '.arc' or '%arc':

  arc> (begin (require racket) (.arc (+ "foo" 42)))

  "foo42"
Yeah it's one more char, but I think it makes the code more explicit, understandable and also extendable (i.e. '.racket' also becomes an option too - not that it's needed).

-----

2 points by krapp 252 days ago | link

>(i.e. '.racket' also becomes an option too - not that it's needed).

.arc / .racket (or .rkt) seems more intuitive than .arc / $

We could also keep the dollar sign in both cases, which I prefer aesthetically, because being familiar with javascript and C type languages, seeing a dot alone like that just seems weird.

-----

3 points by i4cu 252 days ago | link

yeah but the dot reads to me like a file extension so I immediately get it.

$arc would be ok too. I can get behind that :)

-----

2 points by shawn 252 days ago | link

Good point! (%arc ...) and (%rkt ...) already work, actually. (I couldn't decide between %arc vs %do and %rkt vs %scm)

-----

More