On 11/08/2016 02:11 PM, Antonio Corbi wrote:
>
> Maybe this one is useful for you:
>
> http://eagain.net/articles/git-for-computer-scientists/
On 11/08/2016 03:01 PM, H. S. Teoh via Digitalmars-d wrote:
> Nothing immediately comes to mind, but thanks to Dr. Google, I found
> this page that's sorta helpful:
>
> 	http://ericsink.com/vcbe/html/directed_acyclic_graphs.html
>
> And perhaps these:
>
> 	http://eagain.net/articles/git-for-computer-scientists/
> 	http://marklodato.github.io/visual-git-guide/index-en.html
>

Ok, so it looks like each node in the DAG is a commit. I'll definitely have to read further. Thanks, both.

Although I have my doubts it would explain all the issues I've hit upon with git's CLI. For example: I don't see why annotated tags aren't the default. Or why non-annotated ones even exist at all. When I made <https://github.com/Abscissa/gen-package-version>, I noticed that it'll *only* work if the version tags are "annotated" tags. Because otherwise "git describe" doesn't retrieve the tag. Doesn't even matter one bit *what* the tag's message is, just that it exists. Why? Who knows! It's git!

So it means that unlike hg users, who can just make their tags with "hg tag v1.2.0" and everything's fine, git users can't just say "git tag v1.2.0". In git, making a tag like that will work for SOME use-cases but not all. Instead, git users have to use the less-obvious "git tag -a v1.2.0 -m '...whatever...'" incantation or else "git describe" won't freaking work right, therefore gen-package-version won't be able to determine the working copy's current tag name.

So then why do the non-annotated tags even exist? Why not just have "annotated" tags with *optional* messages? Why even have the "-a" flag for "git tag" at all? Why not have "git tag tagname" make a tag with no message, and "git tag tagname -m '...'" to make a tag with a message, and ditch the whole "-a" nonsense? Because it wouldn't be stupid enough that way? I don't get it.

Its things like that. I'd be surprised if that has much to do with git's nature as a "dumb" DAG tool. It's just the general good-design principle of "The thing you *want to* or *should* do or *expect* 99% of the time should be the DEFAULT, not the obscure incantation".


> Or maybe I should write my own article about git being based on a DAG.
> :-P
>

You should! :)

I've given a lot of thought over the years to the concepts of learning and teaching. As I see it, the big key to both is taking seemingly complex things, finding a model that makes them simple, and then finding a way to communicate that model in a way that preserves its inherent simplicity.

The big key there is actually having a simple, well-understood mental model, and it sounds like you have that on this, so I'd love to read anything you'd have to write about it.

On 11/08/2016 11:40 PM, Chris Wright wrote:
> On Tue, 08 Nov 2016 11:44:50 -0500, Nick Sabalausky wrote:
>> I really wish Google would take that to heart. They seem to make a habit
>> of ripping things out *before* having replacements in place.
>>
>> I think they just simply love deleting code.
>
> I've seen this more internally than externally. The joke was that there
> are two versions of everything: the deprecated one, and the one that
> doesn't work yet.
>

It's REALLY poor project management.

On Thursday, 10 November 2016 at 04:22:10 UTC, Nick Sabalausky wrote:
> On 11/08/2016 11:40 PM, Chris Wright wrote:
>> On Tue, 08 Nov 2016 11:44:50 -0500, Nick Sabalausky wrote:
>>> I really wish Google would take that to heart. They seem to make a habit
>>> of ripping things out *before* having replacements in place.
>>>
>>> I think they just simply love deleting code.
>>
>> I've seen this more internally than externally. The joke was that there
>> are two versions of everything: the deprecated one, and the one that
>> doesn't work yet.
>>
>
> It's REALLY poor project management.

Please cut down on the OT guys.

This thread serves as my development log :)
As well as providing a place for discussion of the new engine.

Though that discussion seems to be very quiet at the moment.

On 11/09/2016 11:27 PM, Stefan Koch wrote:
> Please cut down on the OT guys.
>
> This thread serves as my development log :)
> As well as providing a place for discussion of the new engine.
>
> Though that discussion seems to be very quiet at the moment.

Although the default web-based front-end for this newsgroup suggests otherwise, this *is* a tree-based message system. Uninteresting sub-trees can simply be ignored without resorting to content policing.

On 11/10/2016 06:07 AM, Nick Sabalausky wrote:
> On 11/08/2016 02:11 PM, Antonio Corbi wrote:
>>
>> Maybe this one is useful for you:
>>
>> http://eagain.net/articles/git-for-computer-scientists/
> On 11/08/2016 03:01 PM, H. S. Teoh via Digitalmars-d wrote:
>> Nothing immediately comes to mind, but thanks to Dr. Google, I found this page that's sorta helpful:
>>
>>     http://ericsink.com/vcbe/html/directed_acyclic_graphs.html
>>
>> And perhaps these:
>>
>>     http://eagain.net/articles/git-for-computer-scientists/
>>     http://marklodato.github.io/visual-git-guide/index-en.html
>>
> 
> Ok, so it looks like each node in the DAG is a commit. I'll definitely have to read further. Thanks, both.
> 
> Although I have my doubts it would explain all the issues I've hit upon with git's CLI. For example: I don't see why annotated tags aren't the default. Or why non-annotated ones even exist at all. When I made <https://github.com/Abscissa/gen-package-version>, I noticed that it'll *only* work if the version tags are "annotated" tags. Because otherwise "git describe" doesn't retrieve the tag. Doesn't even matter one bit *what* the tag's message is, just that it exists. Why? Who knows! It's git!

Studying git object model in more details actually explains that. Annotated tag is a first class git object (like commit), while plain tag is simply a reference to existing object (like branch). From usability PoV difference can be negligible but impact on git internals is huge.

The fact that the default is non-annotated tag is still just plain bad decision though :)

> Its things like that. I'd be surprised if that has much to do with git's nature as a "dumb" DAG tool. It's just the general good-design principle of "The thing you *want to* or *should* do or *expect* 99% of the time should be the DEFAULT, not the obscure incantation".

I think it is related, but is not necessary consequence. My understanding is that for a long time command line design was given zero thoughts on its own - it was directly exposing whatever git does internally with no usability considerations. Which is why it is so awkward to use unless you really do know internal object model in great details.

On 11/10/2016 09:31 AM, Dicebot wrote:
> On 11/10/2016 06:07 AM, Nick Sabalausky wrote:
>> Its things like that. I'd be surprised if that has much to do with git's
>> nature as a "dumb" DAG tool. It's just the general good-design principle
>> of "The thing you *want to* or *should* do or *expect* 99% of the time
>> should be the DEFAULT, not the obscure incantation".
>
> I think it is related, but is not necessary consequence. My
> understanding is that for a long time command line design was given zero
> thoughts on its own - it was directly exposing whatever git does
> internally with no usability considerations. Which is why it is so
> awkward to use unless you really do know internal object model in great
> details.
>

Yea, see that's the stuff I mean when I say I dislike git's CLI, and would really like to fix with a front-end. A few years back, someone here compared it to driving a car by leaning under the hood pulling on various wires. I like that comparison. Git always did give off that kinda feel to me.

Somebody else pointed out gitless. At a quick glance, it looks like it has at least some potential. I'll have to take a closer look. Although I suspect I'll find a bunch of "oh, hmm, I'd have done that differently" just because...well, I tend to be like that ;)

On Thursday, 10 November 2016 at 01:17:48 UTC, Stefan Koch wrote:
> After the bad news now a bit of good news.
> I just finished the strCat algorithm;
>
> [...]

As expected this code is slightly wrong and will fail on the offset == 3 case.
It will need a little bit of tinkering until it's ready to go :)

On Thursday, November 10, 2016 18:40:03 Stefan Koch via Digitalmars-d wrote:
> On Thursday, 10 November 2016 at 01:17:48 UTC, Stefan Koch wrote:
> > After the bad news now a bit of good news.
> > I just finished the strCat algorithm;
> >
> > [...]
>
> As expected this code is slightly wrong and will fail on the
> offset == 3 case.
> It will need a little bit of tinkering until it's ready to go :)

And aren't you glad that you have all of these unit tests to verify that what you're working works properly? They don't necessarily catch everything, but it would be _way_ worse to completely replace something like this without them. :)

The way that D promotes unit testing is definitely one of its strong points.

- Jonathan M Davis

On Thursday, 10 November 2016 at 20:15:49 UTC, Jonathan M Davis wrote:
> On Thursday, November 10, 2016 18:40:03 Stefan Koch via Digitalmars-d wrote:
>> On Thursday, 10 November 2016 at 01:17:48 UTC, Stefan Koch wrote:
>> > After the bad news now a bit of good news.
>> > I just finished the strCat algorithm;
>> >
>> > [...]
>>
>> As expected this code is slightly wrong and will fail on the
>> offset == 3 case.
>> It will need a little bit of tinkering until it's ready to go :)
>
> And aren't you glad that you have all of these unit tests to verify that what you're working works properly? They don't necessarily catch everything, but it would be _way_ worse to completely replace something like this without them. :)
>
> The way that D promotes unit testing is definitely one of its strong points.
>
> - Jonathan M Davis


I love compile-time unitests.
Who does not like them ?

The interpret3.d test in the compiler acceptance testsuite is almost a work of art.
After you pass that one you can be pretty sure to have a complainant d compiler.

The current Status of stringCat can be found here :
https://gist.github.com/UplinkCoder/fed000f5ca41ad3d65d59a7a63d5ef6f

On Thursday, 10 November 2016 at 20:51:01 UTC, Stefan Koch wrote:
> On Thursday, 10 November 2016 at 20:15:49 UTC, Jonathan M Davis wrote:
>> On Thursday, November 10, 2016 18:40:03 Stefan Koch via Digitalmars-d wrote:
>>> On Thursday, 10 November 2016 at 01:17:48 UTC, Stefan Koch wrote:
>>> > After the bad news now a bit of good news.
>>> > I just finished the strCat algorithm;
>>> >
>>> > [...]
>>>
>>> As expected this code is slightly wrong and will fail on the
>>> offset == 3 case.
>>> It will need a little bit of tinkering until it's ready to go :)
>>
>> And aren't you glad that you have all of these unit tests to verify that what you're working works properly? They don't necessarily catch everything, but it would be _way_ worse to completely replace something like this without them. :)
>>
>> The way that D promotes unit testing is definitely one of its strong points.
>>
>> - Jonathan M Davis
>
>
> I love compile-time unitests.
> Who does not like them ?
>
> The interpret3.d test in the compiler acceptance testsuite is almost a work of art.
> After you pass that one you can be pretty sure to have a complainant d compiler.
>
> The current Status of stringCat can be found here :
> https://gist.github.com/UplinkCoder/fed000f5ca41ad3d65d59a7a63d5ef6f

StringConcat works and will be translated into bytecode soon.
I am going to get a few big things done during next week.
Namely support for dynamic arrays.
At least I hope so :) You never know what bugs might rain on your programming parade.