Version 0.8 - status or lack thereof

[Magnus Rundberget]

Hi !

I might be the impatient type, but i'm really starting to worry about the future of Light Table.
There is very little communication from the Lt-core committers about what is going on.
The activity on github is certainly decreasing, this discussion forum is growing ever more silent and irc is almost dead. The number of new plugins and plugin updates are also in steady decline.

I know it's open source and people are busy with real jobs etc, but I still believe the community should sooner rather than later be informed a little more on what is going on and what the future looks like for Light Table.

Is there anything the community can help out with specifically to get the atom-shell version releasable ?
When can we expect to have a discussion on how Light Table should be evolved going forward ? what is the capacity of the current core commiters team ? Do we need more active commiters ?

I believe the longer we postpone taking action, the more difficult it will become to turn the ship around, so I'm hoping this post triggers some reaction.

I'm certainly prepared to do my part, but I guess i feel a need to be reassured that there is a brighter future for LT.

-magnus

[Martin Zapata]

Hey Magnus,

I use LT frequently and try to help out however I can (mainly filling bug reports or helping others where I can on the mailing list) and would also like to have some more comms. Thanks for starting the discussion.

I don't really have anything productive to add, but that I'm also hearing you out.

Cheers, 

Martin  

[Erik Griffin]

I remember seeing Chris posting some replies here quite recently. I think all is well atm and there's no indication you should be worried.

[Zubair Quraishi]

Yes, Chris posted in here:

https://groups.google.com/forum/#!topic/light-table-discussion/PfQ6kCKrj84

[Chris Granger]

Ugh, somehow I managed to get gmail to paste that in there twice. Here it is correctly:

> "There is very little communication from the Lt-core committers about what is going on."

In all honesty that's because not much has been going on. We're not secretly plotting off somewhere. :) Everyone's just busy.

I think 0.8 is basically ready to go, I fixed the last thing I knew about and have been using the browser tab eval and all to work on Eve without any recent issues.

>  what is the capacity of the current core commiters team ? Do we need more active commiters ?

It seems pretty low. In my particular case I'm basically working all but a couple of my waking hours, weekends and all - so relying on me won't work, though I'm here to help answer questions and point people in the right direction as much as I can. If something really nasty comes up I can probably find a little time to help out with that as well. More committers might help, but unfortunately I'm not sure where we'd fine them. :(

In terms of the larger discussion about how to proceed forward, I think it's time for an honest look at where things are. Even with a principled approach, I think I managed to build a system that only I can really get around in. BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins.

Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. Instead of a clear and obvious flow of data you have to hunt around to try and piece together the graph of possible events. My hope was that pushing as much of that into data as I could think to at the time would make it observable, but realistically a graph with more than about 20 edges is very hard to make much sense of and an IDE certainly has more than 20 edges. So while you can build a pretty incredible amount of functionality in less than a hundred lines in LT, doing so requires you to pretty much understand the whole system. This is a failing on my part. I optimized for keeping the codebase small enough that one person could work on it and along the way I ended up making decisions that ultimately made it more difficult for others to contribute.

The industry has also changed pretty drastically since I started LT. During its creation CPS gained traction, React was created, the Clojure ecosystem basically rewrote itself... When I first started I was more or less the first person to use node-webkit, CodeMirror didn't even have a separable text model (we actually contracted Marijn to add it), and there was quite literally no tooling for ClojureScript. A whole lot has changed, and I would certainly do things differently if I were starting from scratch today. For one, I probably wouldn't have chosen to do it in CLJS. It's just too much of a moving target and architecture ends up being far more important than the specific language used. Using Clojure(Script) also reduced the pool of possible contributors. Starting over, I'd build the UI in an immediate mode fashion, though I probably wouldn't choose to use React directly. I'd scrap BOT for something that is a little less powerful, but far easier to reason about (if people are interesting pursuing such a thing, happy to share my thoughts).

Despite all of this though, I was surprised to see that LT usage is actually still growing and a little over 17,000 people have used it in the past month. Clearly even in its current state people find it useful and an interesting entry into the space. I'm seeing more and more of LT find its way into other things as well: the chrome dev tools now has something like watches, there's the swift playground, intellij now shows debugger values inline, and so on, which is all wonderful to see. 

I wish I had more time to work on it, but that's unlikely to change any time soon. We'll always welcome more committers, more stewards, more anything, and we'll help in any way we can. But what that ultimately means for LT is up to the community.

Cheers,

Chris.

On Tue, Apr 7, 2015 at 8:57 PM Chris Granger <ibd...@gmail.com> wrote:

> "There is very little communication from the Lt-core committers about what is going on."

In all honesty that's because not much has been going on. We're not secretly plotting off somewhere. :) Everyone's just busy.

I think 0.8 is basically ready to go, I fixed the last thing I knew about and have been using the browser tab eval and all to work on Eve without any recent issues.

>  what is the capacity of the current core commiters team ? Do we need more active commiters ?

It seems pretty low. In my particular case I'm basically working all but a couple of my waking hours, weekends and all - so relying on me won't work, though I'm here to help answer questions and point people in the right direction as much as I can. If something really nasty comes up I can probably find a little time to help out with that as well. More committers might help, but unfortunately I'm not sure where we'd fine them. :(

In terms of the larger discussion about how to proceed forward, I think it's time for an honest look at where things are. Even with a principled approach, I think I managed to build a system that only I can really get around in. BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins.

Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. Instead of a clear and obvious flow of data you have to hunt around to try and piece together the graph of possible events. My hope was that pushing as much of that into data as I could think to at the time would make it observable, but realistically a graph with more than about 20 edges is very hard to make much sense of and an IDE certainly has more than 20 edges. So while you can build a pretty incredible amount of functionality in less than a hundred lines in LT, doing so requires you to pretty much understand the whole system. This is a failing on my part. I optimized for keeping the codebase small enough that one person could work on it and along the way I ended up making decisions that ultimately made it more difficult for others to contribute.

The industry has also changed pretty drastically since I started LT. During its creation CPS gained traction, React was created, the Clojure ecosystem basically rewrote itself... When I first started I was more or less the first person to use node-webkit, CodeMirror didn't even have a separable text model (we actually contracted Marijn to add it), and there was quite literally no tooling for ClojureScript. A whole lot has changed, and I would certainly do things differently if I were starting from scratch today. For one, I probably wouldn't have chosen to do it in CLJS. It's just too much of a moving target and architecture ends up being far more important than the specific language used. Using Clojure(Script) also reduced the pool of possible contributors. Starting over, I'd build the UI in an immediate mode fashion, though I probably wouldn't choose to use React directly. I'd scrap BOT for something that is a little less powerful, but far easier to reason about.

Despite all of this though, I was surprised to see that LT usage is actually still growing and a little over 17,000 people have used it in the past month. Even in its current state people find it useful and an interesting entry into the space and I sincerely do hope it can continue on.> "There is very little communication from the Lt-core committers about what is going on."

In all honesty that's because not much has been going on. We're not secretly plotting off somewhere. :) Everyone's just busy.

I think 0.8 is basically ready to go, I fixed the last thing I knew about and have been using the browser tab eval and all to work on Eve without any recent issues.

>  what is the capacity of the current core commiters team ? Do we need more active commiters ?

It seems pretty low. In my particular case I'm basically working all but a couple of my waking hours, weekends and all - so relying on me won't work, though I'm here to help answer questions and point people in the right direction as much as I can. If something really nasty comes up I can probably find a little time to help out with that as well. More committers might help, but unfortunately I'm not sure where we'd fine them. :(

In terms of the larger discussion about how to proceed forward, I think it's time for an honest look at where things are. Even with a principled approach, I think I managed to build a system that only I can really get around in. BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins.

Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. Instead of a clear and obvious flow of data you have to hunt around to try and piece together the graph of possible events. My hope was that pushing as much of that into data as I could think to at the time would make it observable, but realistically a graph with more than about 20 edges is very hard to make much sense of and an IDE certainly has more than 20 edges. So while you can build a pretty incredible amount of functionality in less than a hundred lines in LT, doing so requires you to pretty much understand the whole system. This is a failing on my part. I optimized for keeping the codebase small enough that one person could work on it and along the way I ended up making decisions that ultimately made it more difficult for others to contribute.

The industry has also changed pretty drastically since I started LT. During its creation CPS gained traction, React was created, the Clojure ecosystem basically rewrote itself... When I first started I was more or less the first person to use node-webkit, CodeMirror didn't even have a separable text model (we actually contracted Marijn to add it), and there was quite literally no tooling for ClojureScript. A whole lot has changed, and I would certainly do things differently if I were starting from scratch today. For one, I probably wouldn't have chosen to do it CLJS. It's just too much of a moving target and architecture ends up being far more important than the specific language used. Using Clojure(Script) also reduced the pool of possible contributors. Starting over, I'd build the UI in an immediate mode fashion, though I probably wouldn't choose to use React directly and I'd scrap BOT for something that is a little less powerful, but far easier to reason about (if people are interesting pursuing such a thing, happy to share my thoughts).

Despite all of this though, I was surprised to see that LT usage is actually still growing and a little over 17,000 people have used it in the past month. Clearly even in its current state people find it useful and an interesting entry into the space. I'm seeing more and more of LT find its way into other things as well: the chrome dev tools now has something like watches, there's the swift playground, intellij now shows debugger values inline, and so on, which is all wonderful to see. 

I wish I had more time to work on it, but that's unlikely to change any time soon. We'll always welcome more committers, more stewards, more anything, and we'll help in any way we can. But what that ultimately means for LT is up to the community.

Cheers,

Chris.

--
You received this message because you are subscribed to the Google Groups "Light Table Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discussion+unsubscri...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zubair Quraishi]

Hi Chris,

 Thanks for the very honest response, and for explaining why some things are difficult to update. What about the  Josh Cole, Gabriel Horner, and Mike Innes? I remember reading that they are the largest commiters outside the core team for light table.Is there a chance that they may be able to make the changes necessary, or maybe take light table in a new direction?

http://lighttable.com/2014/11/19/light-table-070/

Zubair

[Lionel Zuber (Armaklan)]

I think too that ClojureScript and BOT make it difficult to build new plugin for less experienced developers. Personally I had no knowledge of Clojure, and I had a hard time developing "small" plug-ins. I have not achieved the results i expected (especially the grunt integration).

But I think the API benefit from further documented (and yes I know, we wan do PR in this sense ^^).

[Magnus Rundberget]

Tx Chris for the honest and thorough response !

I'm hoping that Gabriel, Mike and Josh also chip in with their thoughts too.

I thought I'd share some initial thoughts after digesting your response:

1. Contributing
I'm prepared to help out in anyway I can within the limits of my available time. I have already been granted commit rights to the LT repositories which is great. However I don't feel that I'm sufficiently qualified (in Clojure/Clojurescript/Node/JS and the LT source) to make changes directly on master. I should however be able to start making more and more pull requests for bug fixes, enhancements and additional features.
That obviously implies that there needs to be someone else available with capacity for handling/reviewing/testing the pull requests.

Other areas I should be able to contribute directly, like improving documentation, reviewing issues on github, verifying/publishing plugins etc.

2. Stewardship
I guess this is now the most critical area to address for Light Table. It needs one or more people with the drive and sufficient capacity to plot out a course for the future of Light Table, both in the short and longer term. I think Gabriel, Josh and Mike did a heroic effort, when they stepped up in October of last year.
So the question is are anyone of the aforementioned interested/able to carry on with such a role and/or are there others willing to step up and try to take on such a task? 
I would gladly try to support one or more stewards with whatever time I can spare and maybe eventually become part of stewarding Light Table myself if/when I'm qualified for the task


3. BOT/Architecture etc
I've found the BOT architecture to be incredibly flexible and extensible, but as you say It can become very hard to reason about. (The autocompleter springs to mind as one plugin I've found really hard to get properly to grips with). The flow of events is one thing that is certainly anything but trivial, but the use of atoms (shared global state) that can be modified by anyone from anywhere makes it even more difficult to reason about. Who knows how many plugins and functions meddle with the state of editor objects ? If state is modified all over the place, then obviously the system gets even harder to reason about. My tiny experience with clojure web apps has taught me that minimizing global state certainly makes it easier to reason about the system (and enable cool things like the reloaded workflow:  https://github.com/stuartsierra/reloaded). 

Maybe a transition away from the BOT to something simpler, but less powerful would be the right thing to do. It would be a pretty substantial undertaking though and maybe not the first thing to address in terms of a roadmap forward. To make it easier for people to create plugins (and contribute to LT core) I think documentation, how-to's, examples etc would get us a long way. People have already managed to make some really cool plugins, so I think it a lot can be achieved by lowering the bar for getting started and finding information.

I've been dabbling with React and ClojureScript and have firsthand experience with the benefits of an immediate mode approach to UI's. Moving towards something along those lines for LT makes total sense to me. Maybe react as is doesn't provide the best abstraction for an editor (btw didn't atom move away from react ?), but some of the principles it promotes certainly could.


4. ClojureScript
My entry to the Clojure world was through Light Table. So I guess I'm biased here, but to me, writing plugins using ClojureScript had a great appeal in itself (as opposed to Coffescript in Atom or JavaScript in Brackets). It has certainly been a moving target and lots of churn, but I think it's maturing everyday and we are using it with great success in my current project.
I'd vote for not focusing on moving away from ClojureScript, but rather try to find ways to upgrade the ClojureScript support to take advantage of the great developments here. Obviously we'd need to figure out a path forward to enable upgrades in the future as well.

In terms of handling asynchronicity I have a hunch that core.async might prove very helpful and powerful. 

Choosing JavaScript rather than ClojureScript would certainly have dramatically have increased the pool of potential contributors. Maybe it would be possible to support writing plugins in both ClojureScript and JavaScript ? Not sure how though. It could be that it's to late for that now.


5. Plugin beginners note
My first plugin for Light Table was a language plugin (the groovy plugin). It was a daunting task indeed, but if there is a will there is a way. Very little documentation, but hey the source was there and mostly quite clear and understandable. There were also several other plugins to look at and questions I had was answered on the discussion forum. I can't say that it was ClojureScript that held me back, it was rather the lack of documentation and missing high-level picture of what parts a language plugin needed to consist of. A how-to guide here would have been a great boost. 
 

To summarize my thoughts at the moment:
I hope others chip in on this discussion and that one or more stewards are prepared to try and carry on with bringing Light Table forward. Let it be known that I'm atleast here to try and help of it that happens.
In the meantime I'll be
- eagerly awaiting the Atom Shell version,
- plug along with trying to make the Clojure Support in Light Table even better with my upcoming clj-light-refactor plugin
- address issues on github and submit pull-requests when I'm able

If it becomes evident that no-one else feels they can make the necessary commitments to breathe serious life into Light Table, I'd obviously need to evaluate my options.
Changing editor being the obvious one, forking Light Table and purging anything I don't care about would be another. Neither of which are very appealing options.

cheers
Magnus

On Wednesday, 8 April 2015 05:58:46 UTC+2, Chris Granger wrote:

[Zubair Quraishi]

Thanks for the very thorough explanation Magnus! Just thinking from the top of my head how I use lighttable myself. I use 0 plugins, and only use it for evaluating clojure and clojurescript (which is broken with the latest version of clojurescript) and the the built in browser . What if EVERYTHING was stripped out related to plugins and just a Lighttable for clojure/clojurescript and javascript were used, whichwas not extensible. Would that make sense?

[Gary Schiltz]

I've also been wondering what's going on with LightTable, and greatly appreciate Chris's response. I also like the idea of a stripped-down version just for Clojure, or maybe also including ClojureScript. There are already great IDEs for Python, etc. I've appreciated that LT is open source, so I can at least grub around in there to see how it was done, and learn from that. At the same time, I'm always pondering how sustainable open source development can be. There must be a reason that the uber-smart folks at Cognitect decided, at least so far, to keep Datomic closed source.

[Kyle Cordes]

On April 9, 2015 at 11:03:52 AM, Gary Schiltz (gary.s...@gmail.com) wrote:

same time, I'm always pondering how sustainable open source development can be. There must be a reason that the uber-smart folks at Cognitect decided, at least so far, to keep Datomic closed source.

If I recall right, at one of the early Conjes one of the key Cognitect folks quipped something about needing money to pay for their kids’ college education. :-)

-- 
Kyle Cordes

http://kylecordes.com

[Frank Castellucci]

I opted for LightTable for Clojure development (at this point in time, also eyeballing for the CLJS, F# , ad nauseam) because:

1. Light weight - loads fast, performs as an editor
2. Conducive to productivity - it doesn't get in the way but rather enhances the way
3. Extensible - my meager needs have all been resolved through plugins. 
4. Interest - Have ideas to extend (and here-in lies the rub)
5. See #1

Further bumbling humbly: Having at least a current state high level architecture/design set of diagrams with a smattering of narrative would help in numerous ways. 

[Zubair Quraishi]

@Frank Hmmm. interesting point about the architectures diagrams. So does it make sense before anything is decided to get all documentation/ideas for the Core of LightTable (apart from the source code which is in github) into one place first. Then we can all assess the state of it and discuss what may need to be done to fix it?

Just so you know my interest in fixing this Frank is that I have made my own apps in Clojurescript using the latest version of Clojurescript, but they cannot be evaled from within LightTable as something broke with LightTable and the latest clojurescript version. I would also consider switching to another IDE for clojuescriupt if there was one which worked out of the box well with clojurescript and allowed me to dynamically change the source like lighttabel does

[Frank Castellucci]

That is correct. Makes it more approachable and would help reduce the learning curves.

@Zubair: We all have our demons <grin>. I look at the potential values others can have and/or derive from what motivates us individually.

[Zubair Quraishi]

I see this readme:

https://github.com/LightTable/LightTable/blob/master/doc/developer-install.md

: I'll start with this and see if it can make any sense to me. If we could find all the relavant documentation then we could start by adding it  to the Light Table website. If I wanted to add my own documentation to the LightTable website what is the procedure?

[Frank Castellucci]

I'd be happy to contribute something.

I'd like to start a graphical representation and will spend the time trying to reverse engineer one out of the docs and (gulp) source. 

Is the website the go-to place to submit/collaborate/refine? A github project unto itself? I have no problem with anything approach.

Frank

--
You received this message because you are subscribed to a topic in the Google Groups "Light Table Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/light-table-discussion/2csnnNA1pfo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to light-table-discu...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Problems cannot be solved by the level of awareness that created them. -- Einstein

[Magnus Rundberget]

I'd suggest to add any documentaton efforts to the wiki for now.
https://github.com/LightTable/LightTable/wiki

(probably under this subsection : https://github.com/LightTable/LightTable/wiki/For-Developers)

We could also breathe some life into the irc and use that for collaborative communication :)

cheers
Magnus

To unsubscribe from this group and all its topics, send an email to light-table-discussion+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Zubair Quraishi]

Before we do anything, we should probably consult the people who have offically taken over, who are JoshCole , Gabriel Horner, and Mike Innes. It will be a shame if we start to make documentation and changes if it is not in the grand plan they have for Light Table

[Frank Castellucci]

Zubair

Makes sense, I will still etch my way through the current state diagramming. Worst case, it will help me to wrap my head around it.

To unsubscribe from this group and all its topics, send an email to light-table-discu...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alan Moore]

On Thursday, April 9, 2015 at 9:03:51 AM UTC-7, Gary Schiltz wrote:

I've also been wondering what's going on with LightTable, and greatly appreciate Chris's response. I also like the idea of a stripped-down version just for Clojure, or maybe also including ClojureScript. There are already great IDEs for Python, etc. I've appreciated that LT is open source, so I can at least grub around in there to see how it was done, and learn from that. At the same time, I'm always pondering how sustainable open source development can be. There must be a reason that the uber-smart folks at Cognitect decided, at least so far, to keep Datomic closed source.

OSS is sustainable only to the extent that people have time to work on it. Most people need day jobs in order to contribute their "free" time. It is a great system if you can tolerate a somewhat chaotic environment. Most large scale OSS project require a corporate overlord or two in order to pay for people to hack on OSS (great gig if you can land it) but this doesn't always end well as sooner or later the money/patience dries up and the project has to go shopping for another sponsor. 

Donations don't work very well either - I'm as guilty as the next dev in not pushing that damned donate button. Not sure why... I have given $ to the organizers of <unnamed-conference> in support of diversity in the <my-favorite> community but that is as far as I have gone. Planning to do more of that but I think human nature requires people to pony up cash *before* the near-instant gratification. Otherwise, we get the gratification and then... somehow... forget to tip those who work so hard on OSS.

I think a membership basis for OSS would go a long way to solving this problem. Time == Money and it all comes down to time in the end. This is one of the problems we are trying to solve with Co-op Source, the free-rider problem.

The typical startup route, which involves VCs/debt that ends up diverting focus away from core project concerns. This is exactly what happened to LT and it's founders. They have to pay the bills somehow so they had to pivot - no blame, just making an observation. The VC startup model may help get projects going initially but when they succeed (e.g. FB, Uber, etc.) most of the profits go to disinterested investors or a few founders.

There is room for an alternative approach to OSS and/or VC startups that is sustainable and keeps money in the software development ecosystem. Imagine if we could be our own democratic version of VCs/Kickstarter and when we are able to build a successful project most of the money can then be channeled back into other projects. Cooperatives are one of the most stable forms of enterprise and a good vehicle for this approach:

http://en.wikipedia.org/wiki/Cooperative#Economic_stability

Alan

[Alan Moore]

It might be worth trying to walk the BOT tree/graph with code and generate visualizations (D3? other?) This might aid in understanding. You could filter nodes to get different views if the the "all view" is too detailed.

Or similarly, use tracing to elucidate data from some of the key behaviors and visualize that...

Alan

[Alan Moore]

Also, on the question of react being removed from Atom, here is a link to a relevant pull request:

https://github.com/atom/atom/pull/5624

I am using react in my UIs but in my case ease of development is more of a priority than hand tuning for performance. Also, they have removed it from the text editor component itself but maybe not from the entire UI... TBD.

Maybe this use case (typing a character in the editor) is a worst case for react - maybe every character or keyword in the editor is a component (without :key to help w/ ordering?), etc.

Alan

[Aleš Roubíček]

React was key step on transition to current design of atom text editor. It improved the performance a lot. Then they realized they can do even better.

[Chris Granger]

Yeah, React is very slow - that slowness is just hidden behind pruning the tree with shouldComponentUpdate. A few days ago we got fed up with it for the Eve editor and I wrote my own much simpler version that performs significantly faster. Drawing the same thing went from 150ms to < 3ms. That's why I said I probably wouldn't use react itself - just the idea of using diffing to provide an immediate mode abstraction.

--

You received this message because you are subscribed to the Google Groups "Light Table Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discu...@googlegroups.com.

[Alan Moore]

Agreed, fundamentally we shouldn't need to diff explicitly. Changes in our data should directly (as possible) trigger the specific update required. Using something like Om or  other React wrapper could mitigate the shouldComponentUpdate issue due to immutable data and identity/value guarantees. However, React is still sub-optimal because it is "polling" the data for changes and reconciling the DOM. This is the wrong way around.

We need "reactive" data structures (e.g. things like atoms/watches) to drive the DOM updates. This gets unwieldy fast as you have to manually manage your data dependencies (atoms watching atoms) and more importantly, relationships in the data, in order to guarantee everything updates at most once and only if needed.

In particular, I think the Rete algorithm/graph is a possible candidate for solving this problem for creating FRP based UIs. I'm currently prototyping an integration of the Clara rule engine with the DOM to see what kind of performance (and simplicity) it can achieve. I think rule engines have a lot to offer for managing app state/data/behavior in areas like FRP, in a similar way that BOT designs help in building games.

I'm still working out what the right data and rule representations work best with this design. I hope to externalize all the UI update concerns and server interactions so that all you need to do is define your data, app state, your views and the core domain logic and behaviors. Clara sessions are just values so they should be able to be persisted or transported into other contexts, stored locally or on a server, etc.

I'll let you know what I find out. I'm working on a blog entry that describes this in more detail with example rules, views, etc.

Alan

--
You received this message because you are subscribed to a topic in the Google Groups "Light Table Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/light-table-discussion/2csnnNA1pfo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to light-table-discu...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-- 
"Whatever you can do, or dream you can do, begin it. Boldness has genius, power, and magic in it. Begin it now." - Goethe

[TP]

On Sun, Apr 12, 2015 at 2:21 PM, Alan Moore <kahun...@coopsource.org> wrote:
> We need "reactive" data structures (e.g. things like atoms/watches) to drive
> the DOM updates. This gets unwieldy fast as you have to manually manage your
> data dependencies (atoms watching atoms) and more importantly, relationships
> in the data, in order to guarantee everything updates at most once and only
> if needed.

This sounds like how Assisticant [1] (formerly Update Controls [2]
which has more detailed docs) helps do INotifyPropertyChanged
management automatically for WPF?

[1] http://assisticant.net/

[2] http://updatecontrols.net/

[Ben Drumain]

About the lack of contributions: a personal opinion from toying with this idea for the better part of a year.
As someone looking to start contributing back to Lighttable as my first real OSS project, I'm having little trouble fitting the abstract model in my head, but rather trying to figure out where to start meaningfully interacting with the system.

I think it would be  beyond helpful if there were an easy to find SPEC-file (à-là Ring) specifying the essential points of the generic components of the system and their interactions. From there, referring the user to a commented & verbose version of the entry points' code would carry the docs the rest of the way.
This could tie in nicely with @Frank's proposition for a graphical high level overview and @Zubair's point about simplifying the system: after the IDE as a value, the IDE as a spec file seems to me a good way to get people interested in their tools and keeping them so.

I'd very much like to help out, however being goodwilled but ignorant it's hard to start alone!

While I'm here, thank you and congratulations to all contributors for Light Table. Using and learning about it is mind blowing at times.

Ben

[Gary Schiltz]

LightTable seems to me to be one of Clojure and ClojureScript's most visible successes on the client side, since it is written for the most part in those two languages. I really like the clj/cljs ecosystem, so I find this to be exciting, motivating, and *freaking awesome*, like LightTable itself. I suspect that I am far from alone with this opinion. I also see it as an very compelling alternative to the other offerings (lighter weight than CCW and Cursive, more approachable for folks that haven't yet wrapped their heads around the Emacs ecosystem).

But, like so many open source projects, it faces a very real danger of stagnation. As Chris has pointed out, there are some architectural weaknesses that he would change if he had it to do over again, and this makes the code hard to modify without really understanding the whole system. So, I want to add my support to the proposition that one of the first things that needs to be done is to more fully document the architecture, both through diagrams and just plain old written documentation.

I guess my overall suggestion is that before diving in and changing a lot of code, there needs to be a lot more effort put into the aforementioned grunt work, i.e. architecture documentation for the system just as it is now, perhaps annotated with discussion of opportunities for change. Like others, I wish I could devote a lot of time to it (which I really can't at this moment), but I will promise to start looking at the code and participating in discussions in this group. One meta question: is this the right group to be discussing development issues? I suspect it is, since it's pretty low traffic anyway.

[Zubair Quraishi]

I guess this is the right place to discuss development issues, unless there is another place we should be talking. I am ll for documenting the current system, no matter how complex it is as that is the first step to deciding what to do. However I have  noticed that none of the main contributors have weighed in yet with their opinions, so I am still waiting to hear from Josh, Gabriel, or Mike Innes, as they are supposed to be spearheading the future direction of Light Table more than anyone else. 

[Irakli Gozalishvili]

I would be very interested in blog post describing an issue with React and a solution you came to Chris, if you'll find some time to that that would be very appreciated!

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discussion+unsub...@googlegroups.com.

[Roman Plášil]

I was following LT a bit because the ideas seemed very interesting. Sad it hasn't come to fruition.

However, I'm very interested in the BOT system and the lessons that can be learned from it. When I first read about it, I found it pretty cool. If someone could write up a blog post (or just reply here) on why is it so difficult to debug, it could be a useful lesson. I'm imagining that since the code is highly data-driven, you would really need to have a way to visualize and explore this data in order to debug anything. Do you think that BOT would be usable if such a visualization was available?

And if you really want to have such extensibility but this dynamic system is unmaintainable, what else can you do? Instead of dynamically, you can just hardcode the extension calls in the source code but is it really that much simpler then? Or do you simply need to sacrifice some parts of extensibility and only have a small interface for extensions?

I noticed a comment above about a lot of global state modified from random places, perhaps that's the main problem why the whole thing is so hard to maintain?

[Gabriel Horner]

On Thu, Apr 9, 2015 at 8:07 AM, Magnus Rundberget <mru...@gmail.com> wrote:

Tx Chris for the honest and thorough response !

I'm hoping that Gabriel, Mike and Josh also chip in with their thoughts too.

Happy to give my two cents having done a fair amount of the maintenance since October. For the past months, I haven't had any personal time and just a few Fridays to work on LightTable. I hope to get some personal time to help by mid summer but that is up in the air but until then I will just have some Fridays. So capacity is fairly low. LT could always use more contributions but just as important are answering issues. A significant part of my time has been eaten up in getting issues to a point that they are reproducible. This leaves me with less time than I would like to fix bigger issues with LT.

I thought I'd share some initial thoughts after digesting your response:

1. Contributing
I'm prepared to help out in anyway I can within the limits of my available time. I have already been granted commit rights to the LT repositories which is great. However I don't feel that I'm sufficiently qualified (in Clojure/Clojurescript/Node/JS and the LT source) to make changes directly on master. I should however be able to start making more and more pull requests for bug fixes, enhancements and additional features.

That obviously implies that there needs to be someone else available with capacity for handling/reviewing/testing the pull requests.

Regardless of how qualified anyone is contributions should go through pull requests. I can review work on Fridays I'm available.

Other areas I should be able to contribute directly, like improving documentation, reviewing issues on github, verifying/publishing plugins etc.

2. Stewardship
I guess this is now the most critical area to address for Light Table. It needs one or more people with the drive and sufficient capacity to plot out a course for the future of Light Table, both in the short and longer term. I think Gabriel, Josh and Mike did a heroic effort, when they stepped up in October of last year.
So the question is are anyone of the aforementioned interested/able to carry on with such a role and/or are there others willing to step up and try to take on such a task? 

I can help with such a role in the capacity I mentioned above.

 

I would gladly try to support one or more stewards with whatever time I can spare and maybe eventually become part of stewarding Light Table myself if/when I'm qualified for the task


3. BOT/Architecture etc
I've found the BOT architecture to be incredibly flexible and extensible, but as you say It can become very hard to reason about. (The autocompleter springs to mind as one plugin I've found really hard to get properly to grips with). The flow of events is one thing that is certainly anything but trivial, but the use of atoms (shared global state) that can be modified by anyone from anywhere makes it even more difficult to reason about. Who knows how many plugins and functions meddle with the state of editor objects ? If state is modified all over the place, then obviously the system gets even harder to reason about. My tiny experience with clojure web apps has taught me that minimizing global state certainly makes it easier to reason about the system (and enable cool things like the reloaded workflow:  https://github.com/stuartsierra/reloaded). 

Maybe a transition away from the BOT to something simpler, but less powerful would be the right thing to do. It would be a pretty substantial undertaking though and maybe not the first thing to address in terms of a roadmap forward. To make it easier for people to create plugins (and contribute to LT core) I think documentation, how-to's, examples etc would get us a long way. People have already managed to make some really cool plugins, so I think it a lot can be achieved by lowering the bar for getting started and finding information.

I've been dabbling with React and ClojureScript and have firsthand experience with the benefits of an immediate mode approach to UI's. Moving towards something along those lines for LT makes total sense to me. Maybe react as is doesn't provide the best abstraction for an editor (btw didn't atom move away from react ?), but some of the principles it promotes certainly could.


4. ClojureScript
My entry to the Clojure world was through Light Table. So I guess I'm biased here, but to me, writing plugins using ClojureScript had a great appeal in itself (as opposed to Coffescript in Atom or JavaScript in Brackets). It has certainly been a moving target and lots of churn, but I think it's maturing everyday and we are using it with great success in my current project.
I'd vote for not focusing on moving away from ClojureScript, but rather try to find ways to upgrade the ClojureScript support to take advantage of the great developments here. Obviously we'd need to figure out a path forward to enable upgrades in the future as well.

In terms of handling asynchronicity I have a hunch that core.async might prove very helpful and powerful. 

Choosing JavaScript rather than ClojureScript would certainly have dramatically have increased the pool of potential contributors. Maybe it would be possible to support writing plugins in both ClojureScript and JavaScript ? Not sure how though. It could be that it's to late for that now.


5. Plugin beginners note
My first plugin for Light Table was a language plugin (the groovy plugin). It was a daunting task indeed, but if there is a will there is a way. Very little documentation, but hey the source was there and mostly quite clear and understandable. There were also several other plugins to look at and questions I had was answered on the discussion forum. I can't say that it was ClojureScript that held me back, it was rather the lack of documentation and missing high-level picture of what parts a language plugin needed to consist of. A how-to guide here would have been a great boost. 
 

To summarize my thoughts at the moment:
I hope others chip in on this discussion and that one or more stewards are prepared to try and carry on with bringing Light Table forward. Let it be known that I'm atleast here to try and help of it that happens.
In the meantime I'll be
- eagerly awaiting the Atom Shell version,
- plug along with trying to make the Clojure Support in Light Table even better with my upcoming clj-light-refactor plugin

Keep up the great work with this plugin.

Cheers,

Gabriel

 

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discu...@googlegroups.com.

[Gabriel Horner]

I do share Magnus' concern that there hasn't been a release of LT in a while. I do think releasing infrequently hurts the project. With some integration tests we could eventually have a quicker release cycle.

Fwiw, the only person who can release LT currently is Chris. Since OSX requires a developer id to officially release the app, I don't believe there's a way for others on the core team to release without paying for a yearly org license. It would be great if myself and other core contributors could eventually release LT without having to pay for the right. Any ideas there welcome.

On Tue, Apr 7, 2015 at 11:58 PM, Chris Granger <ibd...@gmail.com> wrote:

Ugh, somehow I managed to get gmail to paste that in there twice. Here it is correctly:

> "There is very little communication from the Lt-core committers about what is going on."

In all honesty that's because not much has been going on. We're not secretly plotting off somewhere. :) Everyone's just busy.

I think 0.8 is basically ready to go, I fixed the last thing I knew about and have been using the browser tab eval and all to work on Eve without any recent issues.

Ok. Let me know if there's something else I can do besides user testing across windows, linux, osx in preparation for a release. Otherwise, I'll be eagerly awaiting a release

Cheers,

Gabriel

[Chris Granger]

At one point, we talked about not code signing releases anymore, so I thought that's what we're doing. I didn't realize we were waiting on me to try and sign the thing.

[Chris Granger]

I just re-upped our apple license. As soon as that goes through, I'll add Gabriel to it. Magnus do you want release privileges as well?

[Sean Corfield]

On Apr 15, 2015, at 4:50 PM, Gabriel Horner <gabriel...@gmail.com> wrote:

I do share Magnus' concern that there hasn't been a release of LT in a while. I do think releasing infrequently hurts the project. With some integration tests we could eventually have a quicker release cycle.

I think having an official 0.8 release based on the atom-shell branch would really help, since then plugin authors could get their plugins working again on the new code base (Recall is the one that I most want to see working properly again — hint, hint!).

Then trying to find ways to easy the process for more contributors going forward would be a welcome move, whatever form that takes.

I’ve tried to enhance the global file search (to search only specific file types, by extension) but never quite got it working because I couldn’t quite navigate my way through the code base. Any documentation that helps folks navigate the code / architecture would be a big step forward.

At this point I’m running the atom-shell branch as my day-to-day editor for all my development, built from source and run via this command:

./builds/lighttable-0.8.0-mac/light

I’d certainly contribute PRs if it was a little easier to figure out how to add enhancements :)

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Chris Granger]

I invited you Gabriel :) So now there's at least two of us who can do a mac release.

[Chris Granger]

Given limited time, are there specific bits people would really like to see comments and such for?

[Stefan Sigurdsson]

Hi all,

By way of introduction, I am a long time Light Table lurker, going back to the Kickstarter effort, maybe Python, etc. I've really enjoyed watching this project, and I've spent some time digging through the source code for fun. I've not implemented a plugin though.

I wanted to add three thoughts to this discussion. First, that, yeah, there is a bit of a lack of documentation :) But the overall model is very cool and easy to grok. My #1 documentation suggestion would be to pick out a simple plugin and a not-quite-simple plugin and write up how those work, nice and tightly focused. When I first started looking at the sources I decided to see if I could figure out the workspace view and I found that quite rewarding. I think it doesn't matter which plugins would be illustrated as long as the implementation is nice and idiomatic BOT.

Then, second, I'd perhaps respectfully disagree with the comments about BOT, mixins and complexity, and really strongly agree with the integration test comment someone made. Ya, I know I don't have any street cred to disagree with anything here, given that I've never posted :) But the BOT model is beautiful. Sure, global state can become convoluted to think about but there are remedies - arranging as much computation as possible to be referentially transparent, eg. pure functional, and then collecting the side effects into documebted blocks, might be one way to control the complexity?

Third and last, a roadmap to 0.8, 0.9 and 1.0, together with a place to put the more far-out ideas, would be very nice. Sorry if this exists here somewhere, I might have missed it - I know this was mentioned around the 0.7 discussion last year.

Cheers,

Stefan

[Magnus Rundberget]

The namespaces I find my self using all the time is (in priority order):
[lt.object :as object]
[lt.objs.editor :as editor]
[lt.objs.command :as cmd]
[lt.objs.editor.pool :as pool]
[lt.objs.files :as files]
[lt.objs.notifos :as notifos]
[lt.objs.console :as console]

After that a tiny description for each namespace about their purpose would probably be worthwhile as well.

I'd be happy to try and help out with this. maybe use granular github issues (possibly with a label indicating whether it's possible for an beginner, intermediate or advanced LT user to contribute) ?

cheers
Magnus

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discussion+unsub...@googlegroups.com.

[Zubair Quraishi]

If it is helpful I could make some video interviews where we walk through the code and plugins on my clojurescript youtube channel? We could just record the person I am interviewing's screen and then they could walk me through the code, as I ask questions?

https://www.youtube.com/user/zubairq

[Zubair Quraishi]

Hi Stefan,

 Are you in the Copenhagen area? If so we could meet? Connect to me on LinkedIn if so.

Zubair

[Mike Innes]

Happy to also weigh in as one of the committers. Unfortunately, I also won't have much personal time to devote to LT in the short term. Real life beckons and I'm having to seriously cut back on my OS work (tempting though it is) over the coming months. That said, it would be great to see a community effort to reboot things – I think making an LT-style plugin for Atom is a particularly attractive option, although I'm not sure how extensible Atom's editor is compared to CodeMirror.

I think I'm actually a bit less pessimistic about LT's architecture than Chris is. Maybe I'm biased, because for me flexibility was always LT's big selling point – it made a wonderful test bed for building IDE features and extensions. I definitely agree that it doesn't mesh that well with ClojureScript's model – bearing in mind that this is a language which was basically invented as a middle finger to stateful object oriented programming – and that some of the concepts could do with cleaning up. But those are basically aesthetic concerns, so it's not a huge criticism.

Any powerful system is going to need best practices and guidelines for getting the most out of it, as well as a bit of trial and error to figure out those approaches. That and some careful design to make the system feel simple. If LT/BOT is in the middle of that process it's not fatally bad, and it would be a shame to take the shortcut of cutting down its power when there's so much potential to be had.

[Stefan Sigurdsson]

I like what Mike said, flexibility & best practices. Chris also said something about optimizing the code base to fit it in his head, that's a big plus for me. Eclipse gets used as a basis for domain-specific UIs, but Light Table looks a lot better - it's just, prettier, more elegant - and the code base is *so much smaller*, it should be more tractable, not less? Intuitively speaking? With some helpful documents for getting started? 

Perhaps domain-specific UIs are a direction Light Table could evolve towards? The lack of debugger integration is fatal for some of us when it comes to development. (Why choose or even debate breakpoints vs. console printing when you can have both...) 

Just for fun: Light Table was to some extent conceived as a tool to better understand code, right? So, what can be done with it to help understanding its own codebase? 

I found this article hugely useful when digging through JBoss not too long ago; if I write something like this about Light Table, would some of you guys chip in by reviewing and helping make presentable?

https://developer.jboss.org/wiki/AS7InternalArchitectureOverview

On Friday, April 17, 2015 at 4:11:01 AM UTC-7, Mike Innes wrote:

Happy to also weigh in as one of the committers. Unfortunately, I also won't have much personal time to devote to LT in the short term. Real life beckons and I'm having to seriously cut back on my OS work (tempting though it is) over the coming months. That said, it would be great to see a community effort to reboot things – I think making an LT-style plugin for Atom is a particularly attractive option, although I'm not sure how extensible Atom's editor is compared to CodeMirror.

I think I'm actually a bit less pessimistic about LT's architecture than Chris is. Maybe I'm biased, because for me flexibility was always LT's big selling point – it made a wonderful test bed for building IDE features and extensions. I definitely agree that it doesn't mesh that well with ClojureScript's model – bearing in mind that this is a language which was basically invented as a middle finger to stateful object oriented programming – and that some of the concepts could do with cleaning up. But those are basically aesthetic concerns, so it's not a huge criticism.

Any powerful system is going to need best practices and guidelines for getting the most out of it, as well as a bit of trial and error to figure out those approaches. That and some careful design to make the system feel simple. If LT/BOT is in the middle of that process it's not fatally bad, and it would be a shame to take the shortcut of cutting down its power when there's so much potential to be had.

On 16 April 2015 at 01:49, Chris Granger <ibd...@gmail.com> wrote:

I invited you Gabriel :) So now there's at least two of us who can do a mac release.

On Wed, Apr 15, 2015 at 5:20 PM Sean Corfield <se...@corfield.org> wrote:

On Apr 15, 2015, at 4:50 PM, Gabriel Horner <gabriel...@gmail.com> wrote:

I do share Magnus' concern that there hasn't been a release of LT in a while. I do think releasing infrequently hurts the project. With some integration tests we could eventually have a quicker release cycle.

I think having an official 0.8 release based on the atom-shell branch would really help, since then plugin authors could get their plugins working again on the new code base (Recall is the one that I most want to see working properly again — hint, hint!).

Then trying to find ways to easy the process for more contributors going forward would be a welcome move, whatever form that takes.

I’ve tried to enhance the global file search (to search only specific file types, by extension) but never quite got it working because I couldn’t quite navigate my way through the code base. Any documentation that helps folks navigate the code / architecture would be a big step forward.

At this point I’m running the atom-shell branch as my day-to-day editor for all my development, built from source and run via this command:

./builds/lighttable-0.8.0-mac/light

I’d certainly contribute PRs if it was a little easier to figure out how to add enhancements :)

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

--
You received this message because you are subscribed to the Google Groups "Light Table Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discussion+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Light Table Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discussion+unsub...@googlegroups.com.

[Magnus Rundberget]

In an effort to document (in a slightly self-promoting fashion perhaps :) ), i've blogged about plugin development in LightTable.

http://rundis.github.io/blog/2015/lt_react.html
(Implementing a Clojure ns-browser in Light Table with React).

I'm hoping that some of my LT related blogposts can be refined into "official" tutorials/how-tos soonish. Qa assistanse when I get to that would be great !

Btw the BOT architecture is growing on me the more I use it. With good documentation, best practices for usage etc, i think the BOT is way to powerful to give up.

Now I'm just eagerly awaiting the 0.8 release, before I start submitting pull requests :)

Cheers
Magnus

[Martin Zapata]

Nice post Magnus! Saw it on the front page of HN too, congrats :)

Cheers, 

Martin

[Magnus Rundberget]

Cheers !

Buzzword compliant or fortunate timing I guess :)

-magnus

[Chris Granger]

It's a great post Magnus :)

--

You received this message because you are subscribed to the Google Groups "Light Table Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discu...@googlegroups.com.

[Martin Zapata]

Hey All, 

Just to bring the conversation back to what Magnus originally was posting about 

Is there anything the community can help out with specifically to get the atom-shell version releasable ? 

Going through older discussions, it seems that theres 

- a problem with browser eval (https://groups.google.com/d/msg/light-table-discussion/PfQ6kCKrj84/ZRmdXqlTWl8J)

- moving to the latest CLJS (https://groups.google.com/d/msg/light-table-discussion/PfQ6kCKrj84/jifIi-1dYbkJ) which Chris has mentioned might not be the best thing to do right now

- Testing an issue with proxy support in atom-shell (as an aside, atom-shell is now known as electron, found that out the hard way trying to build LT)

- Updates to LT should be driven by main.js so that they can be guaranteed to only happen once (https://github.com/LightTable/LightTable/pull/1756)

- Testing and fixing plugins which seem to break with atom-shell (https://github.com/joshuafcole/recall/issues/19)

Since there's already far more experienced hands dealing with the first three, I can try and go through some plugins and see if they (hopefully!) work as expected. What I'm thinking is that if there are changes to be made, I'll fork the plugin repo and create an atom-shell branch on there too with the appropriate changes. That way once we push out 0.8, plugin authors can hopefully just accept pull requests to merge atom-shell branches and they should be good to go.

For those who are running the atom-shell version, they can then git a `git co atom-shell` in their plugin directories and hopefully and further test out the plugins they use. 

Does this sound like an okay plan?

(Please note I've only BRIEFLY looked into plugins, so it'll take me some time - but happy to put in some effort)

Back to the list for 0.8, is there other stuff to add in that list? Anything else we can add to #1756 

Cheers, 

Martin

To unsubscribe from this group and stop receiving emails from it, send an email to light-table-discussion+unsub...@googlegroups.com.

[Kenny Evitt]

Opening up releases is a great step. I'd also like to be able to perform a full build of Light Table, e.g. including the node-webkit or atom executables. That would improve my confidence trying to reproduce issues with the latest version of the code or contribute changes to feature branches.

Reviewing issues has been a struggle. The one I was most recently struggling with is Clojure Instarepl loops endlessly · Issue #1873. I was trying to follow the code – and I think I was able to mostly figure out what was the relevant code, but I couldn't think of how to remotely debug the issue. I was never able to reproduce it myself and the only thing I could think to do was provide instructions on inserting additional 'debug print' statements in what I figured was the relevant code so that more info could be gathered, hopefully. Luckily someone else discovered that the (or a possible) culprit was a Leiningen plugin.

In general, there are several classes of issues that seem very difficult to resolve, e.g. proxy problems. My instinct is to spend time adding 'debug info gathering' features so as many issues as possible can be resolved quickly. But I only have a limited understanding of how to change the Light Table code to do that, e.g. 'deploying' the Clojure plugin to be used by my local Light Table build. I suspect tho that none of this is really that hard; it's just currently confusing and difficult to understand given limited and fragmented blocks of time in which to do it.

[Lionel Zuber]

Hi,

Any news about this release ?

[Fred Eisele]

For a start there is Aleph
https://github.com/ndr-qef/light-aleph
I am experimenting with storing code in a graph data base for queries and to support visualization?
It is using doxygen to extract from c++ and loading Neo4j and visualizing with gephi.
Currently we are looking at function calls:  cohesion and coupling.
Would something like this help to understand BOT?

[Kenny Evitt]

Aleph looks like it could be very useful for understanding BOT configuration. Do you have any example visualizations?

[Fred Eisele]

I have a massive gephi graph for a project that I cannot share.

But you can get some sense of what it looks like here...

http://www.martingrandjean.ch/introduction-to-network-visualization-gephi/

The trick is to come up with a good layout and clustering approach,

some type of unsupervised learning.

As a first cut I would think getting the BOT information (Aleph) into

a graphical representation.

There are many to choose from, maybe http://sigmajs.org/ ?

[Kenny Evitt]

I got the "atom-shell" branch to build on a Windows computer finally. The build output looks good too.

I went ahead and merged two pull requests for that branch (for the rename of Atom Shell to Electron).

There are only two outstanding to-do items in the pull request for the branch. One for proxy support and the other for "Updates to LT should be driven by main.js so that they can be guaranteed to only happen once", which I guess covers runtime changes to Light Table. I've asked the core committers about both and whether they can be deferred to another release.

I still need help from the core committers to be able to package the build output and create a new release. But I actually think it would be good to do a beta release of the Atom Shell (Electron) version as it is.

That all said, it would be great for everyone to try the branch build themselves and report any problems. The document "doc/developer-install.md" in the source repo (in the "atom-shell" branch) has the relevant instructions.

On Thursday, April 2, 2015 at 8:58:45 PM UTC-4, Magnus Rundberget wrote:

Hi !

I might be the impatient type, but i'm really starting to worry about the future of Light Table.
There is very little communication from the Lt-core committers about what is going on.
The activity on github is certainly decreasing, this discussion forum is growing ever more silent and irc is almost dead. The number of new plugins and plugin updates are also in steady decline.

I know it's open source and people are busy with real jobs etc, but I still believe the community should sooner rather than later be informed a little more on what is going on and what the future looks like for Light Table.

Is there anything the community can help out with specifically to get the atom-shell version releasable ?

[James Abbott]

Hi,

I've found this thread when making a Google search about the future of LT. I've been a user of LT for about  year now (on and off, my main workflow these days is Ruby & friends in Sublime Text).

I was late to the LT Kickstarter campaign, but as soon as I found out about the project I became tremendously excited because this seemed like exactly the Clojure editor I was looking for. Not just an editor, but a learning tool.

It looks like LT is falling a little by the wayside (while its competitors are busy absorbing its innovative features), or as Chris wrote:

I'm seeing more and more of LT find its way into other things as well: the chrome dev tools now has something like watches, there's the swift playground, intellij now shows debugger values inline, and so on, which is all wonderful to see.

To me, this looks like a pretty sad state of affairs.

Here's my take on a solution. It's coming from an opinionated user who's really, really interested in LT's development & progress, and ultimate success. If you disagree, fine. If you agree, and would like to discuss, feel free to get in touch.

So it seems like the main bottleneck for making headway on LT is lack of time on the part of core commiters / developers. There are plenty of ideas on how to progress LT on the part of the core team and plenty of indicators from the user base on what they appreciate / would like to see. The thing lacking seems to be time resources.

To this end:

1) Make LT a commercial product. This will enable the team to focus on achieving one thing, and one thing only: making LT the best interactive programming environment, ever. Period.

2) Go from a company that makes an editor to a company that provides education in programming and computing. Make LT the hub of that strategy. Look at Mathematica for an example / inspiration.

3) Re-launch the crowdfunding campaign if necessary and involve outside funding if necessary (but NOT of the VC category).

There are other points to the strategy, but those are more confidential / competitive in nature so I won't be posting them here. If anyone wishes to engage in a conversation, feel free to write to me via:

http://www.jamesabbottdd.com/contact-me

or via abbottjam-at-gmail-com.

Cheers,

James.

PS. Lets do it guys. Life is too short for either Emacs or Cursive. I'm currently working as a dev in the educational sector and working on my own startup in the spare time, but would like to get involved with LT to the extent possible.

[Kenny Evitt]

As-of right now, only Magnus and I are active among the LT committers and we're not part of the core team. The core team are all engaged with another project – Eve. Josh was planning on dedicating some amount of time each week to LT, but he's been unable to do so because of commitments to Eve.

I'm not sure it's really possible to make LT a commercial product now. It's certainly possible to build a business around supporting Light Table, like other open source projects do.

I'm not currently interested in joining a startup. And the core team are already building another startup. But there's nothing stopping you or anyone else from building a startup around Light Table.

Personally, I think LT just needs more 'eyes' and 'hands'. The core team has migrated LT from node-webkit/NW.js to { Atom shell / Electron } and it seems to be mostly running great. Magnus and I have been – slowly, but steadily – figuring out what else we need to do before we release the next version. We could certainly use some help doing that.

But LT is a tool for programmers, so its audience are all potential contributors!

[Zubair Quraishi]

Hey James

Get in contact, I sent you a message on your contact form. Did you get it?

Zubair

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "Light Table Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/light-table-discussion/2csnnNA1pfo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to light-table-discu...@googlegroups.com.

[James Abbott]

Hi Kenny,

thanks for sharing your thoughts. The support business model does have potential, except maybe in cases where a product's core functionality is being augmented.

But LT is a tool for programmers, so its audience are all potential contributors!

Sure. Let's hope that potential becomes realized over the long haul. I'm not developing in the LT internal stack so cannot contribute with code, but will look for alternative ways to develop the project.

Cheers,
James

[James Abbott]

Hey Zubair,

yep — received it in my Spam originally, thanks for the ping, will be in touch.

/ James

To unsubscribe from this group and all its topics, send an email to light-table-discussion+unsub...@googlegroups.com.