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 scm_d
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 co
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 design
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
'shou
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
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 doesn
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
flow
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 bu
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 w
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 talks
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 s
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, takin
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
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
> c
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 d
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
sho
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 is
> 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
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);
> ...
> scm_dynwind_en
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 s
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 r
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
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);
> >
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 to
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 read
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: https://www.gnu.org/software/gu
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 . 1.0) #'(-0.5 . 0.5) #0.0
// 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 = Fo
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 a
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 code shows any improvement:
>
>
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 whiteout boxes
(stencil ws)
i
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)
> in lyric-hyphen.cc:
>
>
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; i++
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:
>
> SCM properties
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 = Font_interface::text_font_alist_chai
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 (i
"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 para
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 definitio
38 matches
Mail list logo
