Re: guile-2.0 and debian

2016-12-06 Thread Urs Liska


Am 07.11.2016 um 17:08 schrieb Federico Bruni:
> In case you don't know already, last news about guile2 and debian:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#216

Just for the record (although it's probably evident):
This doesn't only mean one can't install "lilypond" from Debian testing
but it's also not possible to do

# apt-get build-dep lilypond

So is there a way to get LilyPond's build-dependencies on that distro
(either a list of dependencies to install manually or by pinning it to
an older release?

Urs

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

2016-12-06 Thread Graham Percival
On Mon, Dec 05, 2016 at 06:03:28PM +, Carl Sorensen wrote:
> 
> On 12/5/16 10:28 AM, "lilypond-devel on behalf of Graham Percival"
>  gra...@percival-music.ca> wrote:
> 
> >The website *is* tied to the documentation.  That decision was
> >made in 2009, and the reasons are just as valid today.
> 
> I believe you when you say this.  But I am having a hard time finding a
> record of the decision.  I expected to find it in the CG under
> Administrative Policies or under Website work.  I couldn't find it either
> place.  Can you help me find a pointer to the discussion and/or the
> decision rationale?

Good question, and I still don't have a good answer.  This was
before we started keeping records of any decisions.  The earliest
I found was this:
http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00574.html
which didn't spark a whole lot of discussion.  The current website
didn't start to become visible until late 2009.

I had a vague memory of a much more in-depth discussion, but
perhaps that was sometime in 2010 or 2011.  I'll continue to trawl
through the archives to see if there's more info.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Guile v2 and GC

2016-12-06 Thread David Kastrup
Han-Wen Nienhuys  writes:

> On Tue, Dec 6, 2016 at 6:54 PM, David Kastrup  wrote:
>> Han-Wen Nienhuys  writes:
>>
>>> Hello David,
>>>
>>> I saw that you made (some) changes for dealing with the Guile v2
>>> garbage collector. what is the overall status of this?
>>
>> The known problems are patched up.
>
> so we have unknown problems? Or is it just working?

Not enough data.

>>> Have you considered defining an operator new() for the smob types? It
>>> would call scm_gc_malloc. Wouldnt that take care of the whole messy
>>> derived_mark business?
>>
>> The whole messy derived_mark business is there for a reason.  LilyPond's
>> data structures are large and LilyPond fills almost all the available
>> address space on 32bit systems.
>
> It is there because GUILE 1.6 did not support anything else.
>
>> In spite of our targeted mark passes, we still had the occasional
>> "Object should be dead" message, just from conservatively marking the
>> stack (and explicitly garbage collecting at a known low tide point).
>
> Conservative garbage collection when the heap size is close to address
> space is always a losing proposition, so we should not aim for it;
> People that want to use a lot of RAM should buy a 64-bit system.
>
>> And you are not going to win this by scm_gc_alloc-ing the memory of the
>> smob types anyway: you need custom alloc overrides for all of the STL
>> class arrays containing SCM values of some kind as well.
>
> AFAICT There are actually very few of them.
>
>> And of course you know that _lot_ of SCM values are not even stored
>> explicitly but as structure pointers that still need ->self () calls to
>> actually get a recognizable SCM value out.
>
> well, they could be stored as SCM with conversion function.

Feel free to go for it.  I consider it a heap of new trouble, but then I
am not the one who'll have to deal with the fallout any more.

And you have to be aware that there are very few people who will be able
to deal with the kind of trouble low-level memory allocation can cause.
Basically you'll be out on your own.

And Guile-2.x is good for a number of surprises of its own.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Guile v2 and GC

2016-12-06 Thread Han-Wen Nienhuys
On Tue, Dec 6, 2016 at 6:54 PM, David Kastrup  wrote:
> Han-Wen Nienhuys  writes:
>
>> Hello David,
>>
>> I saw that you made (some) changes for dealing with the Guile v2
>> garbage collector. what is the overall status of this?
>
> The known problems are patched up.

so we have unknown problems? Or is it just working?

>> Have you considered defining an operator new() for the smob types? It
>> would call scm_gc_malloc. Wouldnt that take care of the whole messy
>> derived_mark business?
>
> The whole messy derived_mark business is there for a reason.  LilyPond's
> data structures are large and LilyPond fills almost all the available
> address space on 32bit systems.

It is there because GUILE 1.6 did not support anything else.

> In spite of our targeted mark passes, we still had the occasional
> "Object should be dead" message, just from conservatively marking the
> stack (and explicitly garbage collecting at a known low tide point).

Conservative garbage collection when the heap size is close to address
space is always a losing proposition, so we should not aim for it;
People that want to use a lot of RAM should buy a 64-bit system.

> And you are not going to win this by scm_gc_alloc-ing the memory of the
> smob types anyway: you need custom alloc overrides for all of the STL
> class arrays containing SCM values of some kind as well.

AFAICT There are actually very few of them.

> And of course you know that _lot_ of SCM values are not even stored
> explicitly but as structure pointers that still need ->self () calls to
> actually get a recognizable SCM value out.

well, they could be stored as SCM with conversion function.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwe

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Guile v2 and GC

2016-12-06 Thread David Kastrup
Han-Wen Nienhuys  writes:

> Hello David,
>
> I saw that you made (some) changes for dealing with the Guile v2
> garbage collector. what is the overall status of this?

The known problems are patched up.

> Have you considered defining an operator new() for the smob types? It
> would call scm_gc_malloc. Wouldnt that take care of the whole messy
> derived_mark business?

The whole messy derived_mark business is there for a reason.  LilyPond's
data structures are large and LilyPond fills almost all the available
address space on 32bit systems.

In spite of our targeted mark passes, we still had the occasional
"Object should be dead" message, just from conservatively marking the
stack (and explicitly garbage collecting at a known low tide point).

And you are not going to win this by scm_gc_alloc-ing the memory of the
smob types anyway: you need custom alloc overrides for all of the STL
class arrays containing SCM values of some kind as well.

And of course you know that _lot_ of SCM values are not even stored
explicitly but as structure pointers that still need ->self () calls to
actually get a recognizable SCM value out.

Until all of your derived_mark calls look like

   scm_gc_mark (field1_);
   scm_gc_mark (field2_);
   scm_gc_mark (field3_);
   for (i=0; ihttps://lists.gnu.org/mailman/listinfo/lilypond-devel


MacUpdate - your app listing has been updated

2016-12-06 Thread MacUpdate



   [1][macupdate-logo.png]
   top background


App Listing Updated

   Hi lilypond.org, We have updated your application listing for LilyPond
   2.19.52-1 on [2]MacUpdate.com. Please take a moment to review your
   application's information to make sure that everything is correct.

   [3]View your updated app listing view your updated app
You can [4]login to your Developer Account to reply to comments and
   view stats, or [5]submit new updates and changes to your app listing.


 [6]MacUpdate Desktop install compatibility

   Desktop Install Compatibility

   MacUpdate Desktop 6 is helping developers make it easier for users to
   fully install and use their apps. Download Desktop 6 and to ensure your
   app works with the “Install” link on our download pages.

   Advertise With MacUpdate

  The best Mac devs advertise their apps on MacUpdate.com because it’s
  the most targeted, highly performing Mac app advertising you can find
  on the web. Contact a...@macupdate.com to guarantee your annual ad
  campaigns get booked and expand your app’s audience.

   Learn more view your updated app

   MacUpdate Desktop install compatibility Questions? Contact our Content
   Update Team [7]upda...@macupdate.com.
  bottom background

   You are receiving this offer because you have an app listed on
   MacUpdate.com. Add us to your address book or white list to ensure
   reliable delivery.

   © 2014 MacUpdate LLC - All Rights Reserved
   526 W. 14th St. #100 • Traverse City, MI 49684

   [devemail-lilypond]

References

   Visible links
   1. 
https://www.macupdate.com/?utm_source=macupdate_medium=email_term=LilyPond_content=appupdate_campaign=dev_emails
   2. 
https://www.macupdate.com/?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   3. 
https://www.macupdate.com/app/mac/19024/lilypond?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   4. 
https://www.macupdate.com/member/login?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   5. 
https://www.macupdate.com/developers/update/?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   6. 
https://www.macupdate.com/desktop?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   7. mailto:upda...@macupdate.com

   Hidden links:
   8. 
https://www.macupdate.com/advertise?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: guile2: string-delete and string-filter

2016-12-06 Thread Thomas Morley
2016-11-29 19:57 GMT+01:00 Antonio Ospite :

> Have you decided how to handle the updates to the dev/guile-2-work
> branch?

I'd like to keep dev/guile-2-work on top of current master or at least
on top of the releases.
But that's only me. Objections?

Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: guile-2.0 and debian

2016-12-06 Thread Thomas Morley
2016-12-06 11:14 GMT+01:00 Antonio Ospite :
> On Tue, 6 Dec 2016 00:24:26 +0100
> Thomas Morley  wrote:
>
>> 2016-11-29 19:34 GMT+01:00 Antonio Ospite :
>> > On Mon, 28 Nov 2016 10:11:35 +0100
>> > Thomas Morley  wrote:
>> >
>> >> 2016-11-25 23:19 GMT+01:00 Antonio Ospite :
>> >>
>> >> > In the mean time I started to write a TODO list of the missing pieces:
>> > [...]
>> Another one for the TODO-list
>>
>> This fails:
>>
>> m字 = { c'1 }
>> m² = { c'1 }
>> \new Staff \m字
>> \new Staff \m²
>>
>> error: unknown escaped string: `\m字'
>> \new Staff
>>\m字
>> error: unknown escaped string: `\m²'
>> \new Staff
>>\m²
>>
>
> Hi Thomas,
>
> the examples from above seem to work here, not sure what is going on.
> I double checked by building again from dev/guile-v2-work with no other
> changes, and I cannot reproduce the problem.
>
> Ciao,
>Antonio



Hi Antonio,

today it works fine. No idea what caused it yesterday.

Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: guile-2.0 and debian

2016-12-06 Thread Antonio Ospite
On Tue, 6 Dec 2016 00:24:26 +0100
Thomas Morley  wrote:

> 2016-11-29 19:34 GMT+01:00 Antonio Ospite :
> > On Mon, 28 Nov 2016 10:11:35 +0100
> > Thomas Morley  wrote:
> >
> >> 2016-11-25 23:19 GMT+01:00 Antonio Ospite :
> >>
> >> > In the mean time I started to write a TODO list of the missing pieces:
> > [...]
> Another one for the TODO-list
> 
> This fails:
> 
> m字 = { c'1 }
> m² = { c'1 }
> \new Staff \m字
> \new Staff \m²
> 
> error: unknown escaped string: `\m字'
> \new Staff
>\m字
> error: unknown escaped string: `\m²'
> \new Staff
>\m²
>

Hi Thomas,

the examples from above seem to work here, not sure what is going on.
I double checked by building again from dev/guile-v2-work with no other
changes, and I cannot reproduce the problem.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Guile v2 and GC

2016-12-06 Thread Han-Wen Nienhuys
Hello David,

I saw that you made (some) changes for dealing with the Guile v2
garbage collector. what is the overall status of this?

Have you considered defining an operator new() for the smob types? It
would call scm_gc_malloc. Wouldnt that take care of the whole messy
derived_mark business?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel