New visual debugger added to Coils Om framework

[Zubair Quraishi]

I add a new feature so that the current Om component being debugged in the "render" phase now shows in the debugger. So when you click on "Debug" and then see the debug items on the right you will see GUI fragments of the current Om component, its code (in coils form) and the state passed into that component:

http://connecttous.co/connecttous/connecttous.html?livedebug=true

[Harsha]

On Thursday, August 7, 2014 11:06:12 PM UTC+5:30, Zubair Quraishi wrote:
> I add a new feature so that the current Om component being debugged in the "render" phase now shows in the debugger. So when you click on "Debug" and then see the debug items on the right you will see GUI fragments of the current Om component, its code (in coils form) and the state passed into that component:
>
> http://connecttous.co/connecttous/connecttous.html?livedebug=true

This is neat.
I have done something very similar with my framework, harsha-mudi/rdp.

It's an important advantage you get because of modelling everything
on top of events and messaging.

From an implementation perspective, I think the right way to approach this
would be mixins. I am not sure how mixins are done in clojurescript.

For example, from the ui you could take a component's name and
apply debugging methods to that component with a mixin. This like
applying a breakpoint.

I believe you have applied debugging at a channel level ?

[Zubair Quraishi]

Hi Harsha,
I took a look at your framework, but I could not get the debugger to work. Is this the correct URL?

https://github.com/harsha-mudi/esti

Zubair

PS: It uses macros, core.async go blocks and observers over shared atoms to get the debug information. Not so much channels though. Feel free to dig into the code and see if you like

[Zubair Quraishi]

Hi Harsha,
I watched the videos in the eat. Seems like you have realtime sync in place like meteor, cool! :)
Zubair

On Friday, August 8, 2014 10:12:14 AM UTC+2, Harsha wrote:

[Sreeharsha Mudivarti]

Hi,

https://github.com/harsha-mudi/esti -- that's the app

That's the debugger as a mixin,
https://github.com/harsha-mudi/rdp/blob/master/lib/debugger.js
The ui of the debugger is in the esti app again.

Debugging and Syncing are just a side-effect of designing the
application around reactive components.

To put it in om's terms, every component ( I use the word System ) in
my framework comes with at-least 5 channels.

"sysin", "sysout", "syserr", "feedback", "debug"

( that's a simplistic explanation because I got inspired by low level
electronics
for the most part )

Since all communication to the component happens trough these channels,
a debugger is just something that sits in-between.

I really wanted to make a phonegap app, but I lost my phone.
nodewebkit seemed like the next best thing given that LightTable uses it.

I am working on runtime debugging.
Currently the debugger is enabled by the build step.

`npm bin`/squareboy esti.tasklist.coffee --stepper --sys "clicks" --tracer

I have added a macosx binary -- https://github.com/harsha-mudi/esti/releases
and clarified the Readme a bit.

I have compiled it using --stepper --sys "clicks" and --tracer, so you
should see the step button. Try adding a task. You should get some
kinda display.

In nodewebkit, the developer tools is located on the top right corner.
My favourite part is actually the tons and tons of tracing.

On Fri, Aug 8, 2014 at 7:25 PM, Zubair Quraishi <zub...@gmail.com> wrote:
> It uses macros, core.async go blocks and observers over shared atoms to get the debug information

Yes, that's a very interesting place to put a debugger. Om components
change when the atoms change so you can easily put it there.

[Zubair Quraishi]

I took a more detailed look. I especially like that you took the inspiration from electronics. Let me know if you blog about this

[Sreeharsha Mudivarti]

Documentation is definitely a weak point.
Trying to do some literate programming style documentation :)

I call this model, Reactive Data Processing (RDP).

Design Influences are listed at -- http://lexical.foobar.systems/rdp.html
Feel free to go through the repo -- https://github.com/harsha-mudi/rdp

The only interesting thing I did was to make an abstraction called System.
Everything follows from there.

This model is build on OOPy ideas so it should be compatible with most
langs out there. I actually use React.js in my app so om should not be
that difficult to adapt to.

Currently om doesn't have best practices wrt the number of core.async
channels to have, or how to design components. That's a place where
RDP like ideas can help. I suspect the clojurescript port of RDP would
be like 5 protocols. I am waiting for the js to be stable before I go
for that.

High level approaches talk about composability, higher order algebra
and <insert-smug-word> and I talk about systems and wires :)

---
www.foobar.systems

> --
> Note that posts from new members are moderated - please be patient with your first post.
> ---
> You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/VugJcgzFNDk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.
> To post to this group, send email to clojur...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

[Zubair Quraishi]

I couldn't get the :

http://lexical.foobar.systems/rdp.html

:link to work

[Sreeharsha Mudivarti]

That's weird. I clicked and it worked.
I use github pages

no 25 on --- http://lexical.foobar.systems/

It could be that the router is rejecting the domain name.

[Zubair Quraishi]

http://lexical.foobar.systems/ seems to work, http://lexical.foobar.systems/rdp.html had some weird redirect stuff going on but even that seems to work now.

Thanks I'll read through them