Re: C++ question on wrapper API for setting Guile fluids

On Apr 22, 2022, at 05:39, Jean Abou Samra wrote: > > You both made a good point. My conclusion is that I should stick to > > { > Local_assumption la (Lily::prebreak_estimate, SCM_BOOL_T); > ... > } > > where the constructor does everything, included scm_dynwind_begin () > and

Re: C++ question on wrapper API for setting Guile fluids

Jean Abou Samra writes: > Re call/cc: I would actually like to use > static_cast (0) > and not SCM_F_WIND_EXPLICITLY. I have no idea whether the stuff I write > is going to interact gracefully with rewinding the stack via continuations, > and I honestly don't want to wonder.We're using C++ (on

Re: C++ question on wrapper API for setting Guile fluids

Le 22/04/2022 à 09:52, Luca Fascione a écrit : [snipped] Where the problem is that dwc.free(p) is actually effectively acting as if it was dwc2.free(p); because the API doesn't pass around the context like the C++ wrappers appear to do, rather it statefully "just goes for it". This is a

Re: C++ question on wrapper API for setting Guile fluids

On Thu, Apr 21, 2022 at 11:46 PM Jean Abou Samra wrote: > Well, the C++ and Scheme interfaces can feel different and idiomatic > in their respective languages as long as they share the same > underlying implementation. > I think this is a super important goal. In fact, I'd upgrade 'can' to

Re: C++ question on wrapper API for setting Guile fluids

Le 21/04/2022 à 23:35, David Kastrup a écrit : Properties will be coded a lot in Scheme. So the interface needs to map naturally to Scheme programming. Well, the C++ and Scheme interfaces can feel different and idiomatic in their respective languages as long as they share the same underlying

Re: C++ question on wrapper API for setting Guile fluids

Jean Abou Samra writes: > Le 21/04/2022 à 13:10, Dan Eble a écrit : >> That is probably mostly due to your early remark that your >> control-flow options are limited in the case of a with_fluid wrapper >> taking a lambda. (It definitely steered my answer.) > > > Well, I find it better if it

Re: C++ question on wrapper API for setting Guile fluids

Le 21/04/2022 à 13:10, Dan Eble a écrit : That is probably mostly due to your early remark that your control-flow options are limited in the case of a with_fluid wrapper taking a lambda. (It definitely steered my answer.) Well, I find it better if it doesn't require reworking the control

Re: C++ question on wrapper API for setting Guile fluids

Le 21/04/2022 à 12:58, David Kastrup a écrit : My personal take on this would move the magic out of the normal reach of users. You get (*start-column*) and (*end-column*) which you can use for accessing the respective fluids but the function *start-column* does not merely access %start-column

Re: C++ question on wrapper API for setting Guile fluids

Le 21/04/2022 à 11:18, Han-Wen Nienhuys a écrit : OK. I'm curious to see how that turns out. I am too :-) I've been intermittently working on this project for more than 6 months now. When I do an experimental refactoring, I make a new branch from the current one to avoid losing the previous

Re: C++ question on wrapper API for setting Guile fluids

On Apr 21, 2022, at 06:54, Jean Abou Samra wrote: > > Le 21/04/2022 à 12:47, David Kastrup a écrit : >> So what one would want is a C++ wrapper working with functionals? ... > So this needs an interface that is easier to use, whether it uses > RAII or functionals or something else. Current

Re: C++ question on wrapper API for setting Guile fluids

Jean Abou Samra writes: > Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit : >> On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote: >>> I am working on code that pervasively utilizes Guile fluids. They should >>> be set in dynamic scopes. >> That sounds scary. Care to tell more? > > What is

Re: C++ question on wrapper API for setting Guile fluids

Le 21/04/2022 à 12:47, David Kastrup a écrit : So what one would want is a C++ wrapper working with functionals? My criterion is rather convenience. scm_c_with_fluid could be convenient if I could use it with a lambda. However, I cannot, I'd need to define a separate function every time,

Re: C++ question on wrapper API for setting Guile fluids

I wonder if you can 'chain' them: Dynwind_context dwc2(dwc); (you can at a minimum 'pause' dwc so to emit a runtime message that the "wrong" thing is happening, but I guess you could hand yourself to your parent and do more sophisticated shenanigans too... I must say I loathe this stateful stuff

Re: C++ question on wrapper API for setting Guile fluids

Jean Abou Samra writes: >> Le 21/04/2022 11:05, David Kastrup a écrit : >> Just for the record, your usage would not fit with the existing >> lily/include/fluid.hh , > > > The existing code in fluid.hh is concerned with retrieving > fluids. I'm asking about setting them. Whether the new code >

Re: C++ question on wrapper API for setting Guile fluids

On Apr 21, 2022, at 02:55, Luca Fascione wrote: > > I'd think you can up this by one, and get a cleaner looking piece of code > if you implement scm_dynwind_fluid() as a forwarded method on your context: ... > dwc.fluid (fluid2, value2); Here's something that does bother me. That reads as if

Re: C++ question on wrapper API for setting Guile fluids

Not sure why my message got mangled? Resending, properly formatted. Le 21/04/2022 à 10:51, Jean Abou Samra a écrit : Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit : On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote: I am working on code that pervasively utilizes Guile fluids. They

Re: C++ question on wrapper API for setting Guile fluids

On Thu, Apr 21, 2022 at 10:53 AM Jean Abou Samra wrote: > >> On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra > >> wrote: > >>> I am working on code that pervasively utilizes Guile fluids. They > >>> should > >>> be set in dynamic scopes. > >> That sounds scary. Care to tell more? > > > > What

Re: C++ question on wrapper API for setting Guile fluids

> Le 21/04/2022 11:05, David Kastrup a écrit : > Just for the record, your usage would not fit with the existing > lily/include/fluid.hh , The existing code in fluid.hh is concerned with retrieving fluids. I'm asking about setting them. Whether the new code can go in fluid.hh is a question, but

Re: C++ question on wrapper API for setting Guile fluids

Jean Abou Samra writes: > Hi, > > It's me again ... > > I am working on code that pervasively utilizes Guile fluids. They should > be set in dynamic scopes. In C++, usage of the Guile API looks like this: > >   scm_dynwind_begin (); >   scm_dynwind_fluid (fluid, value); >   ... >  

Re: C++ question on wrapper API for setting Guile fluids

Hi Luca, Thanks for your insights! Much appreciated. Le 21/04/2022 à 08:55, Luca Fascione a écrit : I'd think you can up this by one, and get a cleaner looking piece of code if you implement scm_dynwind_fluid() as a forwarded method on your context: {   Dynwind_context dwc; // overloaded

Re: C++ question on wrapper API for setting Guile fluids

Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit : On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote: I am working on code that pervasively utilizes Guile fluids. They should be set in dynamic scopes. That sounds scary. Care to tell more? What is scary about it exactly? I am trying to

Re: C++ question on wrapper API for setting Guile fluids

On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote: > I am working on code that pervasively utilizes Guile fluids. They should > be set in dynamic scopes. That sounds scary. Care to tell more? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: C++ question on wrapper API for setting Guile fluids

On Thu, Apr 21, 2022 at 8:12 AM Jean Abou Samra wrote: > Le 21/04/2022 à 04:57, Dan Eble a écrit : > > { > >// dwc constructor calls scm_dynwind_begin () > >Dynwind_context dwc; > >scm_dynwind_fluid (fluid1, value1); > >scm_dynwind_fluid (fluid2, value2); > >

Re: C++ question on wrapper API for setting Guile fluids

Le 21/04/2022 à 04:57, Dan Eble a écrit : On Apr 20, 2022, at 18:04, Jean Abou Samra wrote: Calls to scm_dynwind_begin () and scm_dynwind_end () must be paired correctly. Obviously, if '...' contains statements causing non-local control flow like return, break, continue, and such, it is easy

Re: C++ question on wrapper API for setting Guile fluids

On Apr 20, 2022, at 18:04, Jean Abou Samra wrote: > > Calls to scm_dynwind_begin () and scm_dynwind_end () must be > paired correctly. Obviously, if '...' contains statements > causing non-local control flow like return, break, continue, > and such, it is easy to miss a scm_dynwind_end (). I

C++ question on wrapper API for setting Guile fluids

Hi, It's me again ... I am working on code that pervasively utilizes Guile fluids. They should be set in dynamic scopes. In C++, usage of the Guile API looks like this:   scm_dynwind_begin ();   scm_dynwind_fluid (fluid, value);   ...   scm_dynwind_end (); Docs:

Re: C++ question:

Knut Petersen writes: >> // A markup property whiteout-markup-wzd is implemented. >> // The following definition is used for that property: >> // \markup { \with-dimensions #'(0 . 0) #'(0 . 0) { >> // \filled-box #'(0.0

Re: C++ question:

// A markup property whiteout-markup-wzd is implemented. // The following definition is used for that property: // \markup { \with-dimensions #'(0 . 0) #'(0 . 0) { // \filled-box #'(0.0 . 1.0) #'(-0.5 . 0.5) #0.0 } } SCM properties =

Re: C++ question:

Hi David! Sigh. Why do you use set_empty _after_ translation? That makes the remaining point stick out from the actual glyph. And of course, it totally moots any effect of set_empty before translation. It does not matter where set_empty is used, it does not have the desired effect. I tried

Re: C++ question:

Knut Petersen writes: >> Uh, you set the dimensions to 0,0 _after_ moving the thing to its place. >> That would make the remaining point stick out seriously wide of the >> actual glyph. Maybe move the set_empty before the translate_axis? > > Not even the following

Re: C++ question:

Am 20.01.2017 um 13:35 schrieb David Kastrup: Knut Petersen writes: Hi David! Uh what? If you want to change the dimensions of a stencil copy, you can just do Stencil wd0 = orig; wd0.set_empty (false); I use the following code to emit hyphens (stencil ds) and

Re: C++ question:

Knut Petersen writes: > Hi David! >> Uh what? >> >> If you want to change the dimensions of a stencil copy, you can just do >> >> Stencil wd0 = orig; >> wd0.set_empty (false); > > I use the following code to emit hyphens (stencil ds) and whiteout boxes > (stencil ws)

Re: C++ question:

Hi David! Uh what? If you want to change the dimensions of a stencil copy, you can just do Stencil wd0 = orig; wd0.set_empty (false); I use the following code to emit hyphens (stencil ds) and whiteout boxes (stencil ws) in lyric-hyphen.cc: Stencil total; for (int i = 0; i < hyphens;

Re: C++ question:

Knut Petersen writes: > Hi everybody! > > > Is there an equivalent of \with-dimensions #'(0 . 0) #'(0 . 0) that can be > used on a stencil within the C++ part of lilypond? > > If not: I thought I could work around that problem by constructing and using > a markup:

C++ question:

Hi everybody! Is there an equivalent of \with-dimensions #'(0 . 0) #'(0 . 0) that can be used on a stencil within the C++ part of lilypond? If not: I thought I could work around that problem by constructing and using a markup: SCM properties =

C++ question

Hey all, If I have a header file with stuff like: class MyClass { typedef int (*happy)(int a, int b, int c); happy foo happy bar; happy baz; } Is there a way to define foo, bar, and baz with the same typedef in the c++ file or do I have to enumerate all the arguments for the function

Re: C++ question

m...@mikesolomon.org m...@mikesolomon.org writes: Hey all, If I have a header file with stuff like: class MyClass { typedef int (*happy)(int a, int b, int c); happy foo happy bar; happy baz; } Is there a way to define foo, bar, and baz with the same typedef in the c++ file No. The

Re: C++ question

hi Mike, class MyClass { typedef int (*happy)(int a, int b, int c); happy foo happy bar; happy baz; } Is there a way to define foo, bar, and baz with the same typedef in the c++ file or do I have to enumerate all the arguments for the function definition à la int baz (int a, int b,