On 11.10.2015 10:12, Noel Grandin wrote:
> On 10 October 2015 at 15:41, Bjoern Michaelsen
> wrote:
>> And if something like boost::signal2 is awesome beyond believe (which is --
>> given Michaels hint about LOCs added at least open to debate), we should
>> first
>> make our least broken implement
On 10 October 2015 at 15:41, Bjoern Michaelsen
wrote:
> And if something like boost::signal2 is awesome beyond believe (which is --
> given Michaels hint about LOCs added at least open to debate), we should first
> make our least broken implementation wrap or subclass that as a migration
> path.
On Thu, Oct 08, 2015 at 01:03:15PM +0200, Michael Stahl wrote:
> uhm... did you just use "boost::signal2" and "trivial" in the same
> sentence? are you aware that a single #include
> adds a ludicrous 33 KLOC of included headers?
FWIW, from the top of my head, we have at least:
- SwClient/SwNot
On Thu, 2015-10-08 at 14:26 +0200, Stephan Bergmann wrote:
> On 10/08/2015 11:20 AM, Michael Meeks wrote:
> > But then - the way that calc re-calculates is neither trivial, nor
> > extremely susceptible to - "split the loop invariant out" - there is
> > some deeply nested recursive goodness ca
On 10/08/2015 11:20 AM, Michael Meeks wrote:
But then - the way that calc re-calculates is neither trivial, nor
extremely susceptible to - "split the loop invariant out" - there is
some deeply nested recursive goodness called from several places going
on =) So - hopefully this listener pr
On 07.10.2015 19:22, Michael Meeks wrote:
>
> I'm fairly convinced that I'd much prefer to have a really simple,
> native C++ binding that is usable; some boost::signals2 or somesuch
> where we can connect a trivial (and type safe via the generated
uhm... did you just use "boost::signal2" a
On Thu, 2015-10-08 at 09:12 +0200, Stephan Bergmann wrote:
> On 10/07/2015 07:22 PM, Michael Meeks wrote:
> > https://gerrit.libreoffice.org/19234
> >
> > Which I want to use in Calc to hide the hideous costs there. Input
> > appreciated.
>
> What are those "hideous costs" exactly ?
Crazy idea time.
I wonder, as the set of configuration parameters from the source tree in a
specific build is fixed, would it be possible to simply generate a large
(C++) struct containing all of them, populate one global such struct
variable on startup (or even at build time with the default valu
On 10/07/2015 07:22 PM, Michael Meeks wrote:
Just pushed:
https://gerrit.libreoffice.org/19234
Which I want to use in Calc to hide the hideous costs there. Input
appreciated.
What are those "hideous costs" exactly? Do you have a pointer to a
patch that makes use of t
Hi there,
Just pushed:
https://gerrit.libreoffice.org/19234
Which I want to use in Calc to hide the hideous costs there. Input
appreciated.
I'm fairly convinced that I'd much prefer to have a really simple,
native C++ binding that is usable; some boost::signals2
10 matches
Mail list logo
