There are/have been some implementations of the ideas mentioned in the
original post:
1. Smalltalk - I used the Squeak implementation in college and found it
terribly frustrating when the image would crash.
2. IBM VisualAge for Java - I used this about 15 years ago. It still used
files for each
On 20/07/12 2:45 AM, Mark wrote:
That's what I was thinking. Is Envy still around? The Google didn't
give me much after a quick search.
Not sure about Envy - but "Store" is what Cincom Smalltalk now uses:
- public repository -
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/PostgreSQL+
>>
>> Hi All,
>>
>> One of my first posts to Clojure mailing list. I had an idea around SCMs
>> and Clojure. I'd basically like to put the idea out there and get some
>> feedback. I hope I'm not breaking any etiquette linking to my blog post but
>&g
a cheaper and horrible dirty hack might be to just store it in a
canonical indentation format, and then each person can register their
own output filter so that when they check out they get their own look
and feel.
of course diffs would suck.
the hack upon the hack for that would be to convert a
> It would be more interesting to see a version control system based on
> storing an abstract syntax tree
hmm, interesting idea... such a SCM would need to have the code
compiled at every commit/checkout, right? How would that work for
large projects? And what about let's say "rebase -i master top
On Tue, Jul 17, 2012 at 7:04 AM, Steve Tickle wrote:
> It would be more interesting to see a version control system based on
> storing an abstract syntax tree and then using a pretty printer when the
> files are checked out.
yes! i've been whining about that for all programming languages over
bee
, 2012 at 11:27 AM, N8Dawgrr wrote:
> Hi All,
>
> One of my first posts to Clojure mailing list. I had an idea around SCMs
> and Clojure. I'd basically like to put the idea out there and get some
> feedback. I hope I'm not breaking any etiquette linking to my blog post but
, 17 July 2012 11:27:41 UTC+1, N8Dawgrr wrote:
>
> Hi All,
>
> One of my first posts to Clojure mailing list. I had an idea around SCMs
> and Clojure. I'd basically like to put the idea out there and get some
> feedback. I hope I'm not breaking any etiquette linking
That's what I was thinking. Is Envy still around? The Google didn't give
me much after a quick search.
On Wednesday, July 18, 2012 1:19:01 AM UTC-7, Mark Derricutt wrote:
>
> On 17/07/12 10:27 PM, N8Dawgrr wrote:
>
>
> In a nutshell its about why use files for source in Clojure, can we do
I come from a world were we would write assembler code directly in
hexadecimal using the debugger and decipher the memory dump
to write back the source code.
You learned to be very fluent in hexadecimal :)))
Luc P.
> > I don't think so. After some practice you can read patches as if they
> >
I really hope that refactoring-aware diffs are on their way. They'll allow
for a whole class of merge conflicts to be resolved automatically.
Chris
On 18 July 2012 14:19, Leonardo Borges wrote:
> I haven't been following this discussion that closely so far but I'd
> like to comment on this bit:
I haven't been following this discussion that closely so far but I'd
like to comment on this bit:
> One of my frustrations with source control systems is the way you end up
> repeating information, e.g. Modified function X, Refactored function Y. >
> Added defmethod etc… This information is alre
Hi Nahuel,
I think from a technical perspective something like Datomic would be a good
fit, I think it has the right ingredients. If Git allows access to the lower
layers, that may also be a good fit. One of my frustrations with source control
systems is the way you end up repeating information
What about storing the vars definitions in Datomic? Maybe augmented
with semantic information ("added defmethod", "redefined function",
etc).
Saludos,
Nahuel Greco.
On Wed, Jul 18, 2012 at 5:19 AM, Mark Derricutt wrote:
> On 17/07/12 10:27 PM, N8Dawgrr wrote:
>
>
> In a nutshell its about why u
On 17/07/12 10:27 PM, N8Dawgrr wrote:
In a nutshell its about why use files for source in Clojure, can we do
better?
Almost sounds like you're wanting the Smalltalk "image" along with
something like Monticello - the smalltalk distributed version control
system ( versioning at the function l
> I don't think so. After some practice you can read patches as if they
> were finest prose. ;-)
Yea, for prose they work. I believe that. But I'm paid for writing code :)
> There are already special-purpose, format-dependent diff/patch tools,
> e.g., XMLdiff, various binary diff/patch tools, an
Rostislav Svoboda writes:
Hi Rostislav,
>> You want do diffs
>
> I think you need to concentrate on a way how a diff is made and
> defined if you want to improve the way how a VCS works. I.e. current
> VCSs use something like this:
>
> @ some line numbers @
> - replacing that old line...
> + ...
> You want do diffs
I think you need to concentrate on a way how a diff is made and
defined if you want to improve the way how a VCS works. I.e. current
VCSs use something like this:
@ some line numbers @
- replacing that old line...
+ ... with this new line
which works well for a machine, but i
Hi Tassilo,
Thanks for your reply. I agree that you need a persistence layer and a VCS
provides additional useful capabilities other than persistence. My
suggestion isn't to dispense with a persistence or VCS layer. Its more that
the REPL connects directly to the VCS layer (which may be remote
N8Dawgrr writes:
> http://clojurian.blogspot.co.uk/
>
> In a nutshell its about why use files for source in Clojure, can we do
> better?
Interesting thoughts. With a dynamic, interactive language like Clojure
it would certainly be possible to omit files at all and instead hack
everything toget
Hi All,
One of my first posts to Clojure mailing list. I had an idea around SCMs
and Clojure. I'd basically like to put the idea out there and get some
feedback. I hope I'm not breaking any etiquette linking to my blog post but
I've outlined the idea here:
http://clojurian
21 matches
Mail list logo
