Gosh darn, I want hg push messages

Gosh darn I want hg push messages.

I want to be able to push, and say something like "Everything in this changegroup is on a branch.  Don't panic.  It is being cleaned up before it gets merged into the default trunk."

Exceptions that pop the stack versus occurring WITHIN the stack frame

In a high reliability situation where you might want to throw typed errors that are easily parsed so that you can mitigate the problem ... in such a situation, would you not at least like to throw the error WITHIN the context so that you can return to the erroring instructions?  E.g. open a file if necessary, fix a permission problem by asking the user, etc.

I.e. exceptions that can fix up, and return, as if the exception never occurred.

The other sort of exception, the C++ style exception, pops/unwinds the stack.  And can't return.   The only way that you can handle such errors is to have the calling functions loop:

Hmm..  might call this PSH versus POP exception handling.

             outer() {
                             do {
                                    bool failed = 0;
                                    try {
                                           inner();
                                     }
                                     catch(...) {
                                            // attempt fixup and repeat
                                            failed = 1;
                                      }
                              } while( failed );
               }

Imagine if you had to handle page faults in this manner?    Actually, you don't need to imagine - just look at how stack probes in old UNIX shells used to work.

This seems to be the criterion:

* if exception handling can be transparent to the calling code, you want WITHIN handling

* if exception handling requires the cooperation of the calling code, you want POP handling.

Examples of possibly transparent handling:
* page faults, where VM system can bring in
* removable disk or tape not mounted
* OS asking the user "are you sure?" before doing something that might be a security issue
* emulating unimplemented operations or instructions

Examples of non-transparent:
* stack overflow - you can't PUSH onto the present context, because there is no room left

There's a case for both.   And, certainly, if PUSH is provided, there must be a way so that it can POP.


--

Older OSes like DEC VMS(?) reportedly provided both.

Obviously OSes provided PUSH exception handling for stuff like virtual memory.

But modern languages like C++ have definitely tended towards POP or UNWIND exception handling.   If you can call C++ modern.     (Q: Java? Javascript?)

--

It almost seems that PUSH is associated with change of privilege, while POP is not.  Perhaps.  But, I would like to be able to provide things like user mode page fault handlers, or user mode integer overflow handlers.   That is only change of privilege is you have fine grain privileges, more fine than modern OSes provide.

Garbage collection makes it more practical to return good error messages

Elsewhere I have discussed how I buy into Andrei Alexandresciu and D's contention that throwing C++ style exceptions is the best way to signal errors, since a programmer cannot accidentally or deliberately forget to handle an error.  My preference is to throw generic string error messages, unless I am in a high reliability situation where errors will be parsed and try to be cured, since you can then at least provide a context,. or stack, of error messages.

But... languages with garbage collection do remove one objection to signalling errors by a return code.  One problem with return codes is that they are so cryptic.  Integers.  Ugh.   But if you can construct a meaningful string and return that, then the user at least has the option of printing a meaningful message.

     e.g.

             FUNCTION foo(int bar, char* file) RETURNS char* error_msg;

             if( char* error_msg = foo(42,"bazz") ) {
                     std::cerr << "call to foo got error message: " << error_msg << "\n";
             }

      versus

             foo(42,"bazz");    /// error code is ignored

At least with GC this pattern does not cause a memory leak.

---

I still prefer throwing C++ style exceptions, though.

Notifications not just for beginning but also for end of event

My daughter has an activity that my wife drops her off at, and from which I pick her up at the end.

Most calendar programs provide notifications and alarms only for the start of meetings and activities.

Now, one could (and historically I have) create separate events for the beginning and end.  But this leads to inconsistencies, e.g. when the activity time is changed, but the pickup event is not changed.

Idea: provide multiple alarms or notifications for events, not just at start, but also at end.

Actually, more like a compound calendar item:

1) the activity or duration

2) the event items for my wife to take our daughter to the activity

3) the event item for me to leave wherever I am leaving from (work, home - lead time depends on were I am, and that should also be automated) and pick Sophie up.
    Scheduled relative to the END of the event.

etc.

Cancelling such a compound event removes all.

Moving, changing the time - may want to query.  If rescheduled, I may end up dropping off, and my wife may end up picking up.

---

May also want internal times, not just beginning and end.

E.g. for an all day event, e.g. my wife and daughter at one day of a multi day folk music festival, I may be able to attend only one lunch hour.

===

This general insight - that it is almost as important to schedule and remind yourself of when an activity should end as begin - is, I regret, somewhat new to me.  It is implicit is stuff like Pomodoro scheduling.  But I am only just now beginning to think of it explicitly.

Simple thing: I am trying to schedule an alarm on my Android device for the next time I should look up.

Now, which of the umnpteen alarm programs should I use...?

A better solution than to_string(T) versus operator<<( stream,T)

to_string() versus stream operator<< ?  A commonly occurring quandary for C++ programmers.

For large objects it is often just plain more efficient to write directly to a stream, e.g. output, or write to disk, than it is to write first to a string and then print it.

But it is often nice to be able to take the string representation, and then manipulate it.

I.e. sometimes you want to write to a stream.  Sometimes to a string.  And, yes, I know about ostringstream.   Also ostrstream.  (The ostringstream/ostrstream thrashing in the C++ standard s one reason why this issue was not resolved long ago.)

Also...  sometimes the streams << notation is easier to use than the string concatenation operarir +.  Especially since << often has implicit operators to convert to numerucs etc. to string and then print, whereas you usually don't want to overload operator+(string,T) because that can cause bugs.

---

All of that boils down to: should you provide:

string& to_string(const T& val);

or

std::ostream& operator(ostream& ostr, const T& val);

With the additional caveat that one is often misled by


string& T::to_string() const;

whereas

class T {
public: friend std::ostream& operator<<(ostream& ostr,const T& val);

}

is less misleading.

---

Here's a better way that accomplishes both ends:

class T {

public:

     class Formatter {

           const T& m_val;

           XXX m_extra_stuff; // ...extra paramters, like format directives

      public:

           friend::ostream& operator<<(std::stream&, Formatter);

           Formatter(const T& arg_val, XXX arg_extra_stuff = default) 

               : m_val(arg_val), m_extra_stuff(arg_extra_stuf) 

         {}

};

Used 

std::cout << Formatter(t_object) << "\n";

Or the like.

It's a little bit clunkier to get a string, not quite as elegant as

std::string s = t_object->to_string();

Something like:

std::string s;

std::ostringstream(s) << Formatter(t_object) << "\n";

But perhaps some creative overloading will allow

std::string s = Formatter(t_object) << "\n";

or similar.

---

Q: who do I give credit to?

---

For older C-style programming: print to stream, versus to string?  Same issue, but the C++ streams syntax makes it more pleasant.

To String

class Foo {

public:

  unsigned bazz;

public:

  class Formatter {

  private:

    const Foo& m_objref;

  public:

    Formatter(const Foo& arg_objref) : m_objref(arg_objref) {}

    friend std::ostream& operator<<(std::ostream& ostr, const Formatter f) {

      ostr << std::hex;

      ostr << f.m_objref.bazz;

      ostr << std::dec;

      return ostr;

    }

    operator std::string() const {

      std::ostringstream os;

      os << *this;

      return os.str();

    }

    friend std::string operator+(const std::string& s, const Formatter f)

    {

      return s + (std::string)f;

    }

    friend std::string operator+(const Formatter f, const std::string& s)

    {

      return (std::string)f + s;

    }

    friend std::string operator+(const Formatter f1, const Formatter f2)

    {

      return (std::string)f1 + (std::string)f2;

    }

  };

};

int main()
{
  Foo a, b;
  a.bazz = 0xAAA;
  b.bazz = 0xBBB;

  std::cout << "stream: " << Foo::Formatter(a) << Foo::Formatter(b) << "\n";

  {
    std::string s;
    std::ostringstream sostr(s);
    sostr << "ostringstream: " << Foo::Formatter(a) << Foo::Formatter(b) << "\n";
    std::cout << sostr.str();
  }

  {
    std::string s = Foo::Formatter(a);
    std::cout << "string = f: " << s << std::endl;
  }

#if 1
  {
    std::ostringstream s;
    s << Foo::Formatter(a);
    s << Foo::Formatter(b);
    std::cout << "string; <<; <<: p="p" s="s" std::endl="std::endl">  }
  {
    std::string s = Foo::Formatter(a) + Foo::Formatter(b);
    std::cout << "string = f + f: " << s << std::endl;
  }
#endif

  {
    std::string s = Foo::Formatter(a) + Foo::Formatter(b);
    std::cout << "string = f + f: " << s << std::endl;
  }
  {
    std::string s = "string = s + f: " + Foo::Formatter(b);
    std::cout << s << std::endl;
  }
  {
    std::string s =  Foo::Formatter(b) + ": string = f + s";
    std::cout << s << std::endl;
  }
}

This is painful enough that I would like top make it a mixin.

#define FOO() do { ... } while(0)

Encountered this construct in a C/C+ macro.

This insists in FOO(); having a semicolon,

whereas if did #define FOO() { ... }
the semicolon is not required.

Hack.

Good hack for C.

But shows that C/C++ are stupid languages.

delete-trailing-whitespace

annoyed by emacs' delete-trailing-whitespace deleting trailing newlines at rend of file.

Or, as a friend says:  I want to have a command/mode/whatever that prevents ME from adding extraneous whitespace, but leaves whatever was already there, there.