| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
One more place we were missing expanding type abbreviations: inside
container definitions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Standardize quotes around reagents in error messages.
I'm still sure there's issues. For example, the messages when
type-checking 'copy'. I'm not putting quotes around them because in
layer 60 I end up creating dilated reagents, and then it's a bit much to
have quotes and (two kinds of) brackets. But I'm sure I'm doing that
somewhere..
|
| |
|
|
| |
This should eradicate the issue of 2771.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'm dropping all mention of 'recipe' terminology from the Readme. That
way I hope to avoid further bike-shedding discussions while I very
slowly decide on the right terminology with my students.
I could be smarter in my error messages and use 'recipe' when code uses
it and 'function' otherwise. But what about other words like ingredient?
It would all add complexity that I'm not yet sure is worthwhile. But I
do want separate experiences for veteran programmers reading about Mu on
github and for people learning programming using Mu.
|
| | |
|
| | |
|
| |
|
|
| |
Delete all the [] that has crept in since 2377 in November.
|
| |
|
|
|
| |
Some more structure to transforms, and flattening of dependencies
between them.
|
| |
|
|
|
|
|
| |
In general you only want to specify one transform in terms of
(before/after) another if the other direction wouldn't work. Otherwise
try to make it work by just pushing transforms at the start/end of the
list.
|
| |
|
|
|
|
|
|
|
| |
I was failing to specialize calls containing literals. And then I had to
deal with whether literals should map to numbers or characters. (Answer:
both.)
One of the issues that still rema"><stdlib.h>
#include <string.h>
#include <stabber.h>
#include <expect.h>
#include "proftest.h"
void
does_not_send_receipt_request_to_barejid(void **state)
{
prof_input("/receipts request on");
prof_connect();
prof_input("/msg somejid@someserver.com Hi there");
assert_true(stbbr_received(
"<message id='*' type='chat' to='somejid@someserver.com'>"
"<body>Hi there</body>"
"</message>"
));
}
void
send_receipt_request(void **state)
{
prof_input("/receipts request on");
prof_connect();
stbbr_for_id("prof_caps_4",
"<iq from='buddy1@localhost/laptop' to='stabber@localhost' id='prof_caps_4' type='result'>"
"<query xmlns='http://jabber.org/protocol/disco#info' node='http://profanity-im.github.io#hAkb1xZdJV9BQpgGNw8zG5Xsals='>"
"<identity category='client' name='Profanity 0.5.0' type='console'/>"
"<feature var='urn:xmpp:receipts'/>"
"</query>"
"</iq>"
);
stbbr_send(
"<presence to='stabber@localhost' from='buddy1@localhost/laptop'>"
"<priority>15</priority>"
"<status>My status</status>"
"<c hash='sha-256' xmlns='http://jabber.org/protocol/caps' node='http://profanity-im.github.io' ver='hAkb1xZdJV9BQpgGNw8zG5Xsals='/>"
"</presence>"
);
prof_output_exact("Buddy1 is online, \"My status\"");
prof_input("/msg Buddy1");
prof_input("/resource set laptop");
prof_input("Hi there, where is my receipt?");
assert_true(stbbr_received(
"<message id='*' type='chat' to='buddy1@localhost/laptop'>"
"<body>Hi there, where is my receipt?</body>"
"<request xmlns='urn:xmpp:receipts'/>"
"</message>"
));
}
void
send_receipt_on_request(void **state)
{
prof_input("/receipts send on");
prof_connect();
stbbr_send(
"<message id='msg12213' type='chat' to='stabber@localhost/profanity' from='someuser@server.org/profanity'>"
"<body>Wants a receipt</body>"
"<request xmlns='urn:xmpp:receipts'/>"
"</message>"
);
assert_true(stbbr_received(
"<message id='*' to='someuser@server.org/profanity'>"
"<received id='msg12213' xmlns='urn:xmpp:receipts'/>"
"</message>"
));
}
/mu/commit/041jump_target.cc?h=hlt&id=4814bf94e75ffdcbd2a4093eb1ab67851980a37a'>2226 - standardize warning format | Kartik K. Agaram | 2015-10-01 | 1 | -4/+4 |
| |
|
|
|
|
|
|
| |
Always show recipe name where error occurred. But don't show internal
'interactive' name for sandboxes, that's just confusing.
What started out as warnings are now ossifying into errors that halt all
execution. Is this how things went with C and Unix as well?
|
|
|
This seemingly simple goal uncovered a little nest of bugs: it turns out
I've been awash in ambiguous labels until now. My baseline recipes in
edit.mu were clean, but they introduced duplicate <waypoints> -- and
*those* waypoints contained +jump-targets. Result: duplicate jump
targets, so that I wasn't jumping where I thought I was jumping. Somehow
I happened to be picking one of the alternatives that magically kept
these issues quiescent.
My first plan to fix this was to mangle names of all labels inside
before/after fragments, keep the jump targets private to their fragment.
But the labels also include more waypoints! Mangle those, and I can't
tangle to them anymore.
Solution: harden the convention that jump targets begin with '+' and
waypoints are surrounded by '<>'. Mangle jump targets occurring inside
before/after fragments to keep them private to their lexical fragment,
but *don't* mangle waypoints, which must remain globally accessible.
|