World: r4wp

Aha, thanks

Just found that https://help.github.com/articles/ignoring-fileshere

Cool. So --assume-unchanged helps :)

git update-index --assume-unchanged make/makefile

Oh good stuff -- the exclude list doesn't

Since already committed

Hopefully one remembers having marked a file with --assume-unchanged 
when actually _trying_ to stage changes from that file :)

$ git ls-files -v | grep "^[a-z]"
h make/makefile

aha, http://durdn.com/blog/2012/11/22/must-have-git-aliases-advanced-examples/

nice aliases

including unasumeall

This SO chat seems quite nice, perhaps I should sign up. The interleaving 
of CureCode and Github feeds works well.

That's pretty nice, yes :)

Incidentally, nice to (re)meet you.

(Pretty sure we chatted on here about 6 months ago.)

Quite possible :) Nice to (re)meet you to.

Andreas, I have an interesting Git problem related to R3 and the 
new version of VS2012. Git both in Github and now in VS are both 
detecting a couple files in the build directory you helped me make 
as having changed or being new. I thought that whole directory was 
ignored in .gitignore, so it seems weird.

build/ should be ignored, yes. (Let's move to "Git" or to private 
chat for that.)

For anyone following the browse stuff, I rebased as Andreas suggested 
-- while the above changesets/commits are still accessible, the new 
ones are listed in the pull request.

(Split in two)

In CC #1990 http://issue.cc/r3/1990
I think there a typo in the example :

	>> reword/escape "!bang;bang;" [bang "!"] ["!" ";"]
	== "!blah;"  ; One-pass, continues after the replacement

Thanks, I'll fix that. Originally it was HTML entities, but something 
about CC's update process converts those entities to their original 
characters, which corrupted the code examples. I started using blah 
before I switched to bang.

This is something that surprises me:

system/version ; == 2.100.111.3.1
for i 1 2 0 [prin "x"] ; == none (I am OK with this)

for i 2 1 0 [prin "x"] ; xxxx..... (this does not look compatible 
with the above)

Yeah, that looks like a bug. Write a ticket?

And a step of 0 makes it not run and return none, instead of triggering 
an error? Is that right?

Yes, but I do not object against that (no problem with me)

Does somebody have other preferences?

I'm OK with that, since the alternative is either an endless loop 
or conditional code to avoid error trapping. But it needs to make 
sense conceptually.

Oh, and please don't be bug-for-bug compatible in your R2 version. 
If you find bugs in R3's version, let's report and fix them, now's 
the time :)

Another test:

for i 1 1 0 [prin "x"] ; xxxx.....

If we define the FOR function with a special-case that a step of 
0 will definitely not make the loop run, and have the function return 
none, that makes for some simple tests to add to rebol-tests. Just 
have it break/return something other than none in the code block. 
Like this:
[none? for i 1 1 0 [break/return 1]]
[none? for i 1 2 0 [break/return 1]]
[none? for i 2 1 0 [break/return 1]]
... maybe.

Yes, I am OK with that

none? for i 1 1 0 [break]

looks sufficient as well

Good.

FOREACH triggers an error in that case, the case of the empty word 
block.

Should we be consistent?

I thoguht I did a FOR compatible wrapper for CFOR at one time, but 
I can't find it right now.

Is that along the lines of what you're thinking Ladislav?

Being at it, this looks OK:

for i [1 2] 1 1 [prin mold i] ; [1 2]

this looks OK as well:

for i [1 2] 2 1 [prin mold i] ; [1 2] [2]

this too:

for i [1 2] 3 1 [prin mold i] ; [1 2][2][]

however, this looks arguable:

for i [1 2] 4 1 [prin mold i] ; [1 2][2][]

Is that along the lines of what you're thinking Ladislav?
 - yes, more or less

(I did not intend to use CFOR, wanted to make it "standalone")

I think mine used it, but I agree that standalone is better, and 
won't be any harder in this case.

Do either of you (Brian or Ladislav) know if there's a good FOR test 
suite in the REBOL base?

There are some tests in the core-tests suite (28 in total), but as 
you can see, there are many properties that aren't tested yet.

Thanks, cloned and found them.

I gave the

    for i 1 2 0 [prin "x"]


a second thought, and the fact is that the "forever" functionality 
looks legitimate as well. Thus, it would be best if we made a user 
poll to find out what is preferred. Whether looping forever or not 
looping at all. So, please, let us know what do you prefer.

Alternatives are:


1) for i 1 2 [prin "x"] loops forever printing "infinite" string 
xxx....
2) for i 1 2 [prin "x"] does not loop at all yielding none

Consistently, we want to see the same behaviour when encountering

for i 2 1 0 [prin "x"]

or

for i 1 1 0 [prin "x"]

Pekr, I hope that you do express your preference as well.

shouldn't a for loop run at least once, and then on the next run 
check to see if limits are exceeded?

That is a matter of preferences as well (at least IMO). You can have 
such preference and express it, but another legitimate wish is for 
this case:

    for i 2 1 1 [prin "x"]

to not run at all yielding #[none] as it currently does in R3

So, Graham, I did not understand your question as an expression of 
your preferences. So, you still have an oportunity to express what 
your preferences are.