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.

Emacs functions to manipulate multiple frames on multiple displays

;; Convenient functions to manipulate multiple frames on multiple displays

;; e.g. I often run emacs with 4 frames on 4 different VNC sessions

;; and often need to delete all but the current frame.

(progn ; test idiom: defun some stuff, and then test at end of progn. can eval to test interactively
  (defun print-frame-list ()
    (interactive)
    (reduce 'concat
      (mapcar
(lambda (frame) "print frame"
 (reduce 'concat
   (mapcar (lambda (s) (format "%s" s))
     (list
"TITLE=" (frame-parameter frame 'title) "\n"
"   NAME=" (frame-parameter frame 'name) "\n"
"   explicit-name=" (frame-parameter frame 'explicit-name) "\n"
"   display=" (frame-parameter frame 'display) "\n"
"   frame-height X frame-width=" (frame-height frame) "x" (frame-width frame) "\n"
"   frame-pixel-height X frame-pixel-width=" (frame-pixel-height frame) "x" (frame-pixel-width frame) "\n"
"   visibility=" (frame-parameter frame 'visibility) "\n"
)
     )
   )
 )
(frame-list)
)
      )
    )
  (defun delete-frames-except (frame-list-to-be-deleted)
    (mapcar 'delete-frame frame-list-to-be-deleted))
  (defun non-selected-frames ()
    (remove-if 'null (mapcar (lambda (f) (if (eq (selected-frame) f) nil f)) (frame-list))))
  (defun delete-frames-except-selected ()
    "delete all frames except for the currently selected frame
useful in cleaning up frames scattered over multiple displays, e.g. multip.le VNC sessions"
    (interactive)
    (delete-frames-except (non-selected-frames))
    )
  (defun ag-mips-usual-emacs-frames ()
    "open my usual emacs frames"
    (interactive)
    (make-frame-on-display "ubuntu-uarch:1.0")
    (make-frame-on-display "ubuntu-uarch:2.0")
    ;(make-frame-on-display "ubuntu-uarch:3.0")
    (make-frame-on-display "ubuntu-uarch:4.0")
    )
  ;; test (manual, hand-checked)
  (delete-frames-except-selected)
  (ag-mips-usual-emacs-frames)
  (print-frame-list)
  )


(progn
  ;; Creating a new menu pane in the menu bar to the right of Tools menu
  (define-key-after
    global-map
    [menu-bar ag-frame-menu]
    (cons "Frames" (make-sparse-keymap "hoot hoot"))
    'tools )

  ;; Creating a menu item, under the menu by the id [menu-bar mymenu]
  (define-key
    global-map
    [menu-bar ag-frame-menu dff]
    '("delete-frames-except-selected" . delete-frames-except-selected))

  ;; creating another menu item
  (define-key
    global-map
    [menu-bar ag-frame-menu df.]
    '("delete-frame" . delete-frame))


  ;; creating another menu item
  (define-key
    global-map
    [menu-bar ag-frame-menu uf]
    '("usual frames" . ag-mips-usual-emacs-frames))
  )

voice

want speech to text for blog !!