« first day (1730 days earlier)      last day (2050 days later) » 

12:11 AM
@pekr Or others connected with potentially pulling strings to get rebol.net back up... it's been down for a bit.
2 hours later…
2:12 AM
@MarkI you are a room owner so feel free to change the topic. The last one had been there for too long
@HostileFork I think the bot code is still authenticating, but posting a message is being rejected (probably due to a missing cookie or something). Half the pain is getting an environment up and running to compare what the browser is sending to what the code is sending. That was the main reason for rebuilding my laptop as linux as I was testing using the atronix linux build under a vm on my mac and trying to proxy it through Charles (and struggling with all the virtual interfaces)
I'm debating whether to start building ren-c and using that or to carry on with the atronix build. How is the https support under ren-c now?
2:29 AM
@johnk It should work the same as in Atronix build. If you choose to use Ren/C it will be bleeding edge, but helpful, as I poke through commits if you notice problems. But expect problems.
I wouldn't be building it daily if "getting work done" is priority #1.
I'll listen and be empathetic if I've broken something, as long as a "we're in this together" and "you aren't running a manned space mission" tone prevails. :-)
1 hour later…
3:32 AM
@HostileFork is @kealist's serial port pull on your todo list for Ren/C? Maybe I can start playing with Rebol robots in the future as well
@johnk It was in the Atronix build, and so is in Ren/C also. Would be nice if someone were putting it through some paces...
@HostileFork to play with it more I need to enhance this to support an arduino
Would be nice to see more projects and dialects and such... and especially more projects that aren't just one-person-shows...
2 hours later…
5:29 AM
@HostileFork One person shows? Don't we all have some degree of split personality?
2 hours later…
7:19 AM
posted on July 27, 2015 by fork

[Bug] For example, if you use a block with just one item in it, you will be able to Ctrl-C out of this forever loop: >> forever [1020] ;... then, hit Ctrl-C [escape]>> But if you do not put anything in the block you won't get a response to the interrupt request, it will just keep requesting... >> forever [] ;... then, hit Ctrl-C...Ctrl-C...Ctrl-C [escape][escape][escape] ;

7:48 AM
posted on July 27, 2015 by hostilefork

PROMPT REVIEW REQUESTED...a lot builds on this, and it's taking a very long time as it is to try and ramp the code up to where I'd like it to be. (Note QUIT now takes an INTEGER! value only, and has no /NOW refinement. A small step for now, but ideally EXIT will be shifted to act as QUIT/RETURN, and QUIT will be arity zero meaning EXIT 0) This is a major rewrite of the setjmp/longjmp-

posted on July 27, 2015 by hostilefork


@earl @ShixinZeng @MarkI and everyone else interested, please review --^ ... while I know it can't be perfect, the thing is I really need to get some of these baseline things in... so that I can get the rest of the stuff in. But Zzzz for now...
8:49 AM
I've spent the last two weeks "porting" all my production R2 code over to Atronix R3. In the hope this is of use to someone else, here's a list of the issues I've encountered so far:

- `hash!` not supported
- `find/any` not working/implemented
- `delete/any` not working/implemented
- `read` now defaults to `binary!`
- `read/lines/part` not returning correct units
- `read/string` not handling accented characters (workaround is to use [latin1-to-utf8](http://stackoverflow.com/questions/21716201/perform-file-encoding-conversion-with-rebol-3)
3 hours later…
12:18 PM
posted on July 27, 2015 by qtxie

FEAT: preliminary support for TEXT-LIST widget by qtxie

1 hour later…
1:30 PM
@HostileFork Re CC#2229 on Windows: (1) "[escape]" is not printed (2) Only ctrl-C does anything, not Esc (3) at top level, causes program exit, a regression from R2.
I do not know which of these should be added to CC#2229 or which should be new tickets.
I want R2 behaviour, Esc not ctrl-C in particular. Ctrl-C is the most illiterate thing Unix ever did, and that's saying a bunch.
@Ashley Awesome report, very useful, thank you muchly. These should be noted for the R3/Forward project.
// !!! Through this interface we have no way to distinguish an error
// returned as a value from one that was thrown.  Yet by contract
// we must return some sort of value--we try and patch over this
// by printing out the error and returning an UNSET!.  RenC has
// a stronger answer of offering the actual error catching interface
// to clients directly.
@HostileFork ^---- re your error handling review request: this comment makes me want to review before any code is written.
ATM you are the only one who has played in this area HF, I at least need some time to catch up (on?) before my review.
2:18 PM
posted on July 27, 2015 by Ladislav

https://github.com/saphirion/include - documentation update to describe how to revert the "Choose default program..." action effect

@MarkI I've made no secret of my disdain for the way the RL_Api was done, but something like it does have an advantage over Ren/C... because C does not have namespaces. A limited set of entry points (not these in particular, but something like them) may have value. In any case, I don't think many people have spent a lot of time on analyzing the basics and restructuring them to become sane, no.
@Ashley For more differences, see the list of SO questions in the Red Rebol3 port PR. If you wanted to post a well formed question-and-answer for institutional knowledge (for instance about your sort/skip/all workaround) that could be good.
1 hour later…
3:33 PM
Interesting paper on tracing jits and pypy for anyone who is interested...
1 hour later…
4:39 PM
@rgchris, @Brett, @rebolek or other Rebol-type programmers who might be interested: I was thinking it would be nice if there was an automated script for reconciling some form of the native function specs into the C code. As a very basic start, just putting the indices of the parameters and refinements into the comment. Like here on QUIT
It wouldn't be something run all the time, but could be run periodically as a tool. And just establish a general format for it. It may be that the comment blocks for natives and actions be automatically generated, and if anything additional needs to be said that it be said using comments inline in the function body itself.
Just a thought.
1 hour later…
6:11 PM
So the limiting factors on using Rebol3 for Red were: disagreement with indexing (DocKimbel uses foo/3 and foo/-2 etc rather frequently for performance reasons, and as he does this instead of using labeled structures deliberately FOR performance, he was not interested in glossing the difference with something like second-back. Though second-back as a native may even perform faster than the path evaluation.)
Another was lack of encap. There are now encapping parts on Windows and Linux, not for OS/X yet. The state of polish of the encap process relative to Rebol2 is not something I would know.
Another was no hash! support...again a performance-based desire.
The indexing is largely agreed on needing to go back, with questions remaining only in how to deal with a compromise so the zero-based-continuum users can have something they consider reasonable.
Regarding HASH!, I mentioned that I thought the way to do this was with some sort of "hinting", like creating indexes in a database...while still making something a block...if you needed it to be a block. Some of the cases would have been done better as a MAP!
We could do a "hash-hinted block!" sooner rather than later, probably. Just considering it since @Ashley brought it up.
6:57 PM
>> assert [10]
== true
Should assert be like a "noisy" variant of all...hence returning the last result, instead of flattening it?
That would make it more useful. I wrote a ticket about this: github.com/metaeducation/ren-c/issues/7
Question might be if "assert" is the right name for it, because if you see assert used in an expression-like context it might look weird. I propose "ensure" which also doesn't carry the baggage of people thinking assert "has no side effects in debug builds"
7:20 PM
I should probably ask on AltMe, but does anyone know of any efforts/decisions that were taken/made in Rebol regarding self-referential aggregates (aka any-blocks)?
I am of course particularly interested in reading them and printing them.
There's a mechanism in Common Lisp for this, but it is rather kludgy and does not extend well to Rebol aggregates because they are not binary trees.
I am asking because it is possible that a decision was made in Rebol that for efficiency's sake cycles in aggregates were assumed to never be needed on input, for example.
There is code in mold that checks for cycles, but it is limited and useless, and, more importantly, is not present in form.
Plus, cycles aren't the only thing that needs checking, the general concept is "sharing" and that needs to be fully checked IMO.
A Ladislav/BrianH question, really, but the rest of us can try, can't we? :)
7:42 PM
@hostillefork Well done Brian, your Ren/C definitely has a lot of work in it. To me it looks really the way forward for R3 development. I'm almost sorry that I can't spend enough time to study it thoroughly and contribute.
8:00 PM
@iArnold Thanks, well still much to do, and help is appreciated when people can find the time.
Is there by any chance another name CALL could use, or perhaps even turn it into a dialect... perhaps one named PIPE? Perhaps then it could lose all the refinements. pipe [input >> "process" arg1 arg2 arg3 >> [output error_output]]
Perhaps it could be like the shell in general, and default to INPUT coming from stdin, but by default give the output as a value unless you suppress with none.
So if you don't want to get an output, you would say pipe [{ls} >> none] for instance, but the default you'd just say foo: pipe {ls} and it would be in a variable.
I'm motivated by the fact that I want the word "call" for something else, but it's a reasonable idea I think...and also hints more at the power of the tool.
See also: "Isn't Rebol supposed to be about dialecting?"
(as oppposed to constantly confronting people with one of the most confusing mechanisms for adding optional arguments to a function ever invented)
8:21 PM
The one risk of it would be that if a command generated a large amount of output, and they typed pipe {command-with-lots-of-output}, that it would unnecessarily generate a large value vs. pipe [{command-with-lots-of-output} >> none]. So I guess defaulting to standard output would be a better choice so that people would at least remember to be conscious of that.
Though it means that as with call today, you'd have to name your variables to pipe into them.
foo: {}
pipe [{ls} >> foo]
Though it raises the question of what if you want to pipe literal input into something...
I think this is where the FILE! type can come in handy, because you could see {ls} and %ls differently.
8:59 PM
@HostileFork your commit "Use stack series instead of recursion for GC" breaks FFI stuffs. I've got FFI integrated into my make-cmake.r and it worked on Linux. However, I have to revert the aforementioned commit and make other little fixes
I am trying to see if I can fix the crash with your commit unreverted
@ShixinZeng Glad you're looking at it! I should mention that perhaps obviously, it has likelihood of not working, as I'm only getting it to "builds" point with that stub implementation. Hopefully the changes are intelligible enough to look at and see what might have gone wrong...
@ShixinZeng Regarding this‌​, that is intentional. WORD_INDEX_UNBOUND is only in debug builds; it is not the test of whether a word is bound, it's just to prevent accidentally using the index in cases where the word is unbound. If the series is non-null, that is supposed to mean the word is bound.
So if you're seeing a word that has a WORD_INDEX_UNBOUND but has a frame set, that is a bug in whoever made that word. It shouldn't have its frame set unless an index was also set.
Well, in some cases, REBWRS overlaps with REBWRD
which means, the typeset is set, and the type of the REBVAL is still WORD!
The test for that is supposed to be OPTS_UNWORD
and due to the overlapping of "typeset" and "frame", the "frame" would appear to be set
Right. But any REBWRS-class word should have OPTS_UNWORD set and not run this check due to this apparently badly indented line
There's a separate init for those now one can use: Init_Unword
9:12 PM
Oh, I missed that option
It's very badly named, and there's lots we could do in that area, but it's a flag that's supposed to be set if a word is one of those typeset words.
OK, I will try that
Yes, it worked. and that commit is now replaced by this one: github.com/zsx/r3/commit/…
@ShixinZeng Good. Is that the only change needed, or are there others you want to put in?
It's not done yet. I have yet to get it working with your commit unreverted
9:23 PM
This commit will probably also need to get in eventually: github.com/zsx/r3/commit/…
@ShixinZeng Hm...what does the comment mean about Make_Mem clearing initialized memory? It still does (Alloc_Mem)...
hmmm, you're right, the memory is still cleared by Alloc_Mem
I need to revisit this commit
hmm, I just noticed Make_Series_Data is not clear'ed if it's from memory pool
and clear'ed when it's from system pool
The inconsistency comes from: Make_Node doesn't clear memory, while Alloc_Mem does
@ShixinZeng Hmm. I don't know if I changed anything related to that.
I think I had a commit to make them consistently clear the memory
Let me find it out
In code I have locally, I consistently don't clear it.
But that code had no pooling at all, so will need to be revisited. Once I realized the pools had value, it seems your "always malloc" idea is a more strategic cut.
But the invariant to be planning for is "not cleared", I'd say.
9:35 PM
That's OK
Alright, I gotta go
L8r, thanks!
@HostileFork I'd love to, and I'll do so. I won't be able to make time before Thursday, unfortunately.
@earl Well, even without minutiae looking, a general skim to see if you see anything glaring helps...
Along the lines of "no, you're doing it all wrong". Which I better not be. :-/
400 lines net plus deserve some deeper look.
I fear review deserves at least a tiny percentage of the time it took to write :)
In any case, if I'll get to a "general skim" before that, I'll be sure to let you know.
Net plus lines are likely comments.
Likely less code. (Almost certainly)
9:42 PM
@Ashley Thanks, that's very helpful. Be sure to also have a look at Brett Handley's notes on Transitioning from Rebol 2 to Rebol 3.
@HostileFork Seems to be roughly 180 net plus w/o comments.
Anyway, I'll be very happy to look it over. Unlikely that I'll find time before Thursday.
@earl Well, let's be careful in framing out worldview by line counts. I seek vertical code more than the existing, I also throw in things like DEAD_END; to indicate to the compiler when there's not going to be a return value even when it sometimes might not be needed, trying to fit things in 80 columns etc. So when using our judging sense of the complexities of a commit, we don't want to get to the point where I feel pressure to put lots of things on one line if it's less clear.
I'm pretty sure it's less executable code, though I did manually inline a couple of macros to look at patterns for if there should be better macros. The idea of turning Trap() into a vararg function is something I'll probably do. It's just a phasing thing of what to do when.
10:30 PM
@HostileFork Am I right, that the error handling overhaul now also changes the default so that toplevel error cause the interpreter to QUIT instead of HALTing the console (CC#2215)? I.e. with the change, --on-error=quit is the default, whereas previously/currently it's --on-error=halt.
A comment seems to indicate that, and basic testing seems to confirm that.
@HostileFork I do not share the opinion that the complexity of reviewing 180 plus-lines is reduced significantly by knowing each line is going to be clear and simple. That is, or at the very least should be, a given. I would instead say that each plus-line requires a certain minimum amount of review time, I assert even if it is by the code-writer, and 180 of those amounts even without any further cognitive burden is considerable.
@earl If that's what the comment says, and that's what it does, likely so. (I've not tweaked this to react coherently to switches according to a proposal as of yet.)
@HostileFork Did you intend to change the default?
I appreciate it, in any case. I'd suggest adding a remark to the commit message to be clear about it.
At the time of establishing the code, I wasn't aware that anything being done was being done intentionally.
And as such, I leave it up to people to decide what they want. It's much easier to choose now.
Did you intentionally change the default?
10:33 PM
@HostileFork C'mon, HF, fess up!
The previous, intentional default was to HALT.
As I said, and as others have critiqued, the behavior as it was isn't something I knew to be intentional. I intentionally made it do what it did, and I intentionally put in a comment to the effect of "this is probably something that should be controlled with a switch".
Ok, so you intentionally changed it. Thanks for clarifying.
Please add a remark to the commit message to indicate as such.
I like the v: pipe [{command-with-lots-of-output}] idea. One way to mitigate the "what if there's a huge amount of output" is to have the default being the return code and /output (or whatever we cal it) returning the actual output. I often find I care about one or the other but rarely, if ever, both. Totally agree that the current call/output "blah" stdout: copy "" method is rather alien in the Rebol world.
@Ashley The dialect could also say v: pipe [... >> return]
10:39 PM
Or could return an object with a /return, /output, /error path?
@Ashley I like the idea of seeing how far dialects can be pushed without refinements, where refinements say something more about the process as a whole vs a step that could be done with a keyword in the right place.
PARSE for instance uses RETURN in that way.
And it might be that you want to specifically indicate, as when something pipes to a stdout and a stderr stream which to return
So whatever the mechanism is that you would use to put a variable into a place in the pipe dialect to say "put that output here", using RETURN for that would fit into the model.
@HostileFork Agree on refinements, but call is tricky in that you potentially care about 0-3 of the outputs. (BTW what's the reason for preceding messages with @name ... is it to maintain context, or something deeper?)
@Ashley You can reply to a specific message using the little "reply arrow" that shows up when you hover over someone else's message (lower right corner). It then precedes your message with a number (e.g. :24707692) which replies to that specific message, and when you hit enter it renders it as the author's name.
Then when you hover over any message with that reply arrow, you see what it is in reference to.
@HostileFork Doh! Thanks.
The chat is simple and hasn't been getting any new features, but it is reasonably serviceable.
11:44 PM
So, that's it, for reviewing tonight. (Managed about 20% in ~1.5-2.0hrs.) To be continued!
(Looking forward to it, actually. Looks very good, so far.)
@earl Good... all right, well there's lots more of these to do.
