@Szabolcs also here in the chat room

Thank you

Has anyone tried it already?

@MichaelE2 MUnit used to work fine when it was part of the Workbench. But when they updated it and included it in M10.0, it got completely broken. I kept getting random incorrect failures. It was such an awful experience that it scared me away from the official testing framework for good.

A few times I considered trying it again, but these stories keep me away ...

Better just roll your own testing tool

@MichaelE2 I figured out a workflow where I put VerificationTest(s) in a package and call TestReport["packageWithTests.wl"]from notebook or another script (from command line). See this answer for details. This workflow works reliably for me, I use it for more than a year on multiple projects.

@MichaelE2 fyi, I don't use Testing Notebooks because of this an other issues. Regular .m files with VerificationTest and TestReport are fine.

So exactly like @Pinti

p.s. check the VerificationTest template: mathematica.stackexchange.com/a/164654/5478

@b3m2a1 any idea how to call "SelectionConvert"->InputForm token on given boxes as opposed to selection?

Too bad testing notebooks are so slow, the layout is nice

Has anyone here tried using MathCompile?

@Szabolcs @Pinti @Kuba Thanks for your advice. I'll try something like Pinti/Kuba.

@Szabolcs I haven't used it, but it's very interesting. Have you looked at the WLL Interface repo by the same user? Again, very interesting but I haven't used it

@JasonB. No, thanks for pointing it out! I'm going to take a close look. It seems very complete, even having sparse array support. It is really a lot of work to make something like this.

There were similar things in the past, but this is properly templates and avoids overhead

I'd love to have a discussion with the developer. It's a pity he didn't talk to me before starting this. I could have pointed out to him the mistakes I made in LTemplate (which are now too late to fix without a complete rewrite)

Do you know if he is active on this site and what his username is?

@JasonB. I think one of the biggest mistakes I made with LTemplate was trying to keep things simple for everyone and trying to have my MTensor wrappers act similarly to a C++ reference rather than a pointer (thinking that pointers are too hard and allowing null pointers is too dangerous).

This library seems to embrace modern C++ without hesitation. That's probably better, but I still suspect that it's harder to get started with for people who are mainly used to plain C

But then: basically no one uses LTemplate seriously (except me), so what's the point of making it friendly at the cost of flexibility?

And if someone does use it, they're very likely already comfortable enough with C++.

One difference in scope between this and LTemplate seems to be that this one does not explicitly support managed library expressions (or did I just miss it?) while LTemplate was built around the concept of managed library expressions

Hi there.

@Szabolcs I just informed the author @njpipeorgan :)

@njpipeorgan Hi! What an unexpected surprise

But I'd love to talk about your package soon

If you are around

@njpipeorgan Still, before I go, a few questions:

I was wondering if you're familiar with my LTemplate package. It's similar, but doesn't have such elegant C++ parts

@Szabolcs Sure, I'll ab around.

Originally it was meant to make using managed library expressions easy to use. Have you used them, and does you package have any explicit support? Or have y ou considered adding them?

The most interesting feature I always wanted for LTemplate, but never got around to it (it's not easy) was to connect to "templated" C++ functions

This would be particularly useful for images

Images come with multiple element types: 8-bit, 16-bit, real 32-bit, real 64-bit. Sometimes one can use the very same algorith for all of them. Some image processing libraries, like ITK use templates in C++

It would be really nice if one could write a templated image processing function once in C++, automatically instantiate the template for the relevant types, and have the correct function be called depending on the type of Image that is being passed to the library

That's an idea, but making is work and be useful in practice is not so easy ...

@Szabolcs I'm not very familiar with LTemplate, but I do know the managed expression part of it.

This would make a lot more sense if I could show examples ...

Unfortunately I really have to go

But I'll leave this here, there's a partial tutorial notebook and several examples

github.com/szhorvat/LTemplate

Thanks, see you.

It generates the glue code with Mathematica, not in C++ (in hindsight, doing it in C++, like you do, may not be a bad idea!)

See you!

@njpipeorgan Maybe you could send me an email. I have not yet had the time to try your package, but it looks very interesting, and I am looking forward to exploring it. It must have been a lot of work to make it!

Keep me in the loop for this discussion. I use a modified version of LTemplate for all my library work. I've been wanting to show you, @Szabolcs, what changes I made for my use case.

Maybe we should make a separate chat room here for it?

@Szabolcs My mail address: Uncompress["1:eJxTTMoPChZmYGAoyTGyMDVxSM7PKc1NykzUS00pBQBqXwhW"]

@njpipeorgan I edited your mail message to scramble your plain mail address. This room is publicly visible and not everyone in the world is a saint..

@halirutan Thanks!

@Kuba Unfortunately I don't. There doesn't seem to be anything in the FE contexts that seems explicitly to manage that and since the token is just a token I've got no good way beyond making an invisible notebook, writing the boxes, converting that selection, then reading the boxes again and closing the notebook. Obviously that'll mess with the FE experience though.

@Kuba @b3m2a1 It's not exactly the same, but there is FrontEndExecute[FrontEnd`ExportPacket[boxes, "InputText"]]. I didn't look for differences too carefully though... (the whitespaces at least seem to be different)

Vector-valued event actions:

NDSolve[{x'[t] == -y[t], y'[t] == x[t], x[0] == 1, y[0] == 0,
   WhenEvent[y[t] == 0,
    Thread[{x[t], y[t]} -> {x[t], y[t]} + RandomReal[{-1, 1} 0.1, 2],
     NDSolve`SetState]]},
  {x, y}, {t, 0, 20}] // First
ParametricPlot[{x[t], y[t]} /. %, {t, 0, 20}]

Probably a useless hack....and unreliable.

D'oh. It works without the Thread. Just too clever to keep my mouth shut. :)

@LukasLang Yeah I use that a lot, but it's not gonna give quite the same behaviour. You can use like FrontEndExecute[FrontEnd`ReparseBoxStructurePacket@First@FrontEndExecute@FrontEnd`ExportPacket[boxes, "InputText"]] or something if you go through the text route.

There is also actually a somewhat better version of "InputText" called something like "Package" (I learned about this from JF--think I put it in my answer detailing FE packets) which respects the cell type as well for Cell expressions and which makes the output text not word wrap and doesn't insert weird spaces all over the place

^wait it's called "DefaultText"

as Entity["Country", "France"] without changing the cell.

PlainText gives "Country France" and InputText gives string representation of boxes behind Entities'.

I'm tempted to call the latter case a bug.

@Kuba in this case aren't you really trying to apply ToExpression to the box expression then? There the real issue is that NamespaceBox can't be interpreted by ToExpression...

@b3m2a1 I don't want to lose formatting and I am not willing to pick those boxes and ToExpression them 'locally' yet.

@Kuba It looks like that might be an annoying special case, since the standard way you get rid of one of those things is by using that little check mark, but that calls into a ButtonFunction that looks like:

MathLink`CallFrontEnd[
    FrontEnd`BoxReferenceReplace[
     FE`BoxReference[
      MathLink`CallFrontEnd[
       FrontEnd`Value[
        FEPrivate`Self[]]], {
       FE`Parent["LinguisticAssistant"]}], $CellContext`a, AutoScroll -> True]]

So it's using the BoxReference mechanism to find the parent "LinguisticAssistant" box and replace it with a set of boxes that the NamespaceBox has cooked into it

(which is the first TemplateBox argument in the expression)

Right, I didn't notice it is not 'final' entity yet. I don't work with them at all. This was the first time I pressed that check mark. They should be 'accepted' once you evaluate that cell, shouldn't they?

Yep

But they are not in the input

Clearly some magic happens that isn't ToExpression or ToBoxes to get it out

yep

The boxes are in it here:

Ok, I have to go now, thanks for help

DynamicModuleBox[{Typeset`query$$ = "France",
  Typeset`boxes$$ =
   TemplateBox[{"\"France\"",
     RowBox[{"Entity", "[", RowBox[{"\"Country\"", ",", "\"France\""}], "]"}],
      "\"Entity[\\\"Country\\\", \\\"France\\\"]\"", "\"country\""}, "Entity"]

That TemplateBox is what you want

Yep, I probably can parse it, I just don't want to.

But I guess I will.

@Kuba Here's my implementation of what it seems WRI does already:

getTheBox // Clear
getTheBox[cell : _CellObject | _BoxObject, maxRec_: 3] :=
  Block[
   {
    $wasInGetTheBox = TrueQ[$inGetTheBox],
    $inGetTheBox = True,
    boxes
    },
   If[Not[$wasInGetTheBox],
     Function[Null, Catch[#, "GotABox"],  HoldFirst],
     Identity
     ]@
    With[{kids = FrontEnd`ObjectChildren[cell]},
     Replace[
      SelectFirst[
       boxes = FrontEndExecute@FrontEnd`ObjectChildren[cell],
       Head[NotebookRead[#]] === NamespaceBox &,
       If[maxRec > 0,
        Map[getTheBox[#, maxRec - 1] &, boxes]

Which you can call like tryTheThing@getTheBox[PreviousCell[]]

The hard part is getting the NamespaceBox, but if you are writing the expression for it already you might be able to get that more precisely, especially if you know the Cell into which you are writing

The button has a distinct advantage in that it knows where it is already