Arc Forumnew | comments | leaders | submitlogin
Anarki Stable
24 points by nex3 6145 days ago | 28 comments
Anarki's great for a bunch of things: collecting Arc libraries, allowing experimentation with the language, collecting bug fixes, and so forth.

However, sometimes you don't want all of these, for whatever reason. You don't want all those libs cluttering up your arc/ directory. You want to maintain maximal compatibility with the official release. Whatever.

For those reasons, I've added a stable branch to Anarki. It's just arc2 with as many bug fixes as are available and a very spare set of features added to make those fixes possible. It includes:

* Cross-platform "date" and "ensure-dir" * Compatibility with MzScheme 372 * Proper handling for Control-D in the REPL * A more efficient "whiler" * A fixed "codelines" (http://www.arclanguage.org/item?id=3753) * A fixed "minutes-since" (http://arclanguage.org/item?id=3726)

There are only two real non-bugfix differences between it and arc2. I added arc.sh because it's so handy, and I added the escape-to-Scheme $ macro, to make it easier to write cross-platform code. The latter could also be accomplished by adding more xdefs to ac.scm.

You can check out the stable branch as follows:

  $ git clone git://nex-3.com/arc-wiki.git # Check out the repo
  $ cd arc-wiki
  $ git branch stable origin/stable        # Create a local branch to track the remote stable branch
  $ git checkout stable                    # Switch to your shiny new branch
That's it. If you want to commit a bugfix to Anarki that also applies to the official arcn, commit it to this branch and then merge it into master as follows:

  $ git checkout stable     # Get the stable branch
  $ emacs                   # Make your edits
  $ git commit -a           # Commit all changes
  Created commit 8668ce2: My informative commit title.
  $ git checkout master     # Switch to master branch
  $ git merge stable        # Merge in your change(s) to stable
  $ git push                # Push your changes to the remote repository
Note that there may be a merge conflict when you run "git merge stable." In this case, just open up the files Git tells you have conflicts, search for "<<<<<<" which denotes a merge conflict, and resolve it. Then "git add" the file, "git commit", and continue on your merry way.

I hope this is helpful for everyone.



4 points by CatDancer 6145 days ago | link

In the stable def for mkdir:

  ; If we're running Unix, MzScheme <371 has a bug
  ; where make-directory* sets the sticky bit.
  ; Thus, we want to use system instead.
Actually, in MzScheme 352, make-directory also sets the sticky bit, so the version currently in stable is buggy for that version of MzScheme:

  arc> (mkdir "foo")
  nil
  arc> ^D
  $ ls -l
  total 0
  drwxr-xr-t 2 cat cat 48 Feb 29 09:49 foo

-----

1 point by CatDancer 6145 days ago | link

Also the check in ensure-dir to see if the directory already exists has been taken out going from arc2 -> stable, which means that if the os is unix or macos, you're going to be firing up the shell on every single call to ensure-dir.

-----

2 points by CatDancer 6145 days ago | link

Ah, look, an email address for the committer to complain to... very cool! ^_^

-----

1 point by nex3 6144 days ago | link

Fixed and fixed. Thanks :-).

-----

1 point by CatDancer 6144 days ago | link

  arc> (mkdir "foo")
  Error: "Function call on inappropriate object nil (\"foo\")"

-----

1 point by almkglor 6144 days ago | link

Fixed on master branch. Sorry nex-3, I don't develop on stable branch at all, and I'm pretty much just using git as a glorified CVS ^^

-----

1 point by nex3 6144 days ago | link

Would you be willing to try using stable? It's really not that hard, and it keeps the history so neat.

-----

1 point by almkglor 6144 days ago | link

Will try later, anyhow how to do changes on both stable and master?

-----

1 point by nex3 6144 days ago | link

It's probably not worth worrying about for this patch, because mkdir is in a different place in stable... I'll worry about that. But for future reference, the original post has a good procedure.

-----

4 points by jbert 6145 days ago | link

I'm not 100% sure, but perhaps bugfix commits should go straight into the stable branch?

And then you can ensure you have all bugfixes in the master branch by doing this.

    git checkout master
    git-merge stable
Ideally, this would be done by the person committing the bugfix, but if they forget, then this will merge all not-already-merged bugfixes.

That way you don't have a human-error issue of some bugfixes going into one branch and not the other.

Git will handle the repeated merges, and the history (viewable with gitk) will make more sense, imho.

-----

1 point by nex3 6145 days ago | link

Really, I don't forsee much of a synchronization problem. People can commit to whichever branch they prefer; I'll keep an eye on the RSS feed, as might others, and if a bugfix gets pushed in one branch but not cherry-picked, we'll do it. There aren't too many commits that human error is going to matter all that much.

As for merging, there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.

I'm still not all that familiar with Git, though, and I would love to have nice history. I'm all ears for suggestions.

-----

3 points by jbert 6145 days ago | link

> there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.

That would be a one-time headache with the first merge. After that, as long as bugfixes go into the stable branch, you won't have that problem. (Just had a quick look, it seems like it's currently a fairly trivial merge with only a few minor conflicts - I think git is doing the right thing for you here, but I don't know arc well enough to be sure).

> I would love to have nice history. I'm all ears for suggestions.

Basically, imho, splitting a tree is work and merging shouldn't be.

So by putting the commits in the right place to start with, you're avoiding work (and errors, and people checking with other people to see if that is supposed to be like that, etc).

You're essentially preserving more information as to the purpose of the fix (this is a bugfix) in a way that the tools can get hold of.

Anyway - I'm not a git expert, but that's the way I'd do it.

-----

1 point by nex3 6145 days ago | link

Good points. I've merged stable and updated the instructions.

-----

1 point by lojic 6145 days ago | link

Thanks for setting that up.

I'm still hoping we'll get a nice way to get bugfixes directly into the Arc codebase though. No feedback from pg yet on the other thread. I am curious if there's a reason why he's unwilling to include things such as the date fix into the codebase. I suppose it could be just lack of time at this point.

-----

2 points by CatDancer 6145 days ago | link

> lack of time

Yes.

Everyone has exactly the same amount of time: 24 hours in a day.

Every task that a person does means that there is something else that they are not doing.

To incorporate bug fixes sounds easy, but consider for example all the fixes floating around for "mkdir". Each one fixes mkdir for their operating system and their version of mzscheme, yet it's time consuming to ensure that a bugfix doesn't break someone else's installation.

When a bugfix has been tested and used by lots of people and there is a consensus that it is the right thing to do, then it would be easy for Paul to incorporate it into an arcn. When someone simply says "here's a fix!", then it takes a lot more time to figure out if it is the right fix and if it isn't going to make it worse for someone else.

-----

2 points by byronsalty 6144 days ago | link

This why the whole "network of trust" concept as it relates to massive distributed software projects is important. I'm sure if Arc will do well then PG will need to establish people whom he trusts to aggregate packages and give him only the good ones in order to cut down his personal time investment. Some guys on this forum are definitely knowledgeable enough and motivated.

-----

1 point by eds 6144 days ago | link

> Everyone has exactly the same amount of time: 24 hours in a day.

Except for Le Monte Young :)

-----

1 point by almkglor 6144 days ago | link

And Chuck Norris

-----

3 points by jbert 6145 days ago | link

I'd imagine this is a significant help to getting bugfixes into mainline arc.

It would be a lot easier for PG to go through the arc2->stable diff than the arc2->master diff.

-----

2 points by mst 6144 days ago | link

I think pg is hoping we'll solve that for him.

I'd rather have him thinking about language design anyway.

-----

1 point by lojic 6144 days ago | link

"I think pg is hoping we'll solve that for him."

That's fine, but if it's the case, it would be nice if he'd mention that he wants people to just deal with it via their own ad-hoc systems.

-----

2 points by jbert 6145 days ago | link

> Note that there may be a merge conflict when you run "git merge stable."

There is a git command, 'git mergetool'. This will go through all conflicting files and launch an external tool (you can configure which) to handle the merge. If you save your merged results, it will git add for you, just leaving you to commit at the end.

(From the manpage) It has support for: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff

Editing conflicted files by hand does work, but for complex conflicts I prefer the approach above.

-----

1 point by Jesin 5811 days ago | link

When I try to

  git clone git://nex-3.com/arc-wiki.git
I just get this message:

  Initialized empty Git repository in /home/jesin/arc-wiki/.git/
  nex-3.com[0: 70.87.222.25]: errno=Connection refused
  fatal: unable to connect a socket (Connection refused)
I'm new to git. Is there anything I can do about this, or is this a problem on the server side?

-----

1 point by CatDancer 5811 days ago | link

It was moved to github, see http://www.arclanguage.org/item?id=4951

-----

1 point by CatDancer 6145 days ago | link

Where should we keep track of bugs in arcn not yet fixed in stable?

And, er, perhaps bugs introduced by stable? (Though hopefully they won't be around for too long :)

-----

1 point by nex3 6144 days ago | link

The BUGS file in master? I know it's in master and all, but since master's sort of the main branch, it makes sense for it to have information that pertains to the whole repo. Plus we don't want to clutter up stable with extra files.

-----

1 point by CatDancer 6145 days ago | link

I pushed to stable a fix for the atomic-invoke bug.

First time I've ever used git... please let me know if I did everything correctly. Thanks!

-----

1 point by nex3 6144 days ago | link

Yep, looks great.

-----