GSoC idea: Frescobaldi extension (issue 571690043 by m...@ursliska.de)

2020-02-19 Thread mail 
Reviewers: ,

Message:
This is not as uncontroversial as removing an entire
section. However, assuming the tests pass I may consider
not waiting for the whole countdown process, if GNU
should be selected for the GSoC program.
(In that case I'd assume people will mainly look at
the GSoC page at the beginning of the phase).

Description:
GSoC idea: Frescobaldi extension

Please review this at https://codereview.appspot.com/571690043/

Affected files (+30, -0 lines):
  M Documentation/included/gsoc.itexi


Index: Documentation/included/gsoc.itexi
diff --git a/Documentation/included/gsoc.itexi 
b/Documentation/included/gsoc.itexi
index 
40a4b59354caaafd43141e4e56c7ad321cf4872e..906b4b3a273b96267f6449c9d81964ab607c5836
 100644
--- a/Documentation/included/gsoc.itexi
+++ b/Documentation/included/gsoc.itexi
@@ -181,6 +181,36 @@ of timing issues
 @emph{Mentors:} Urs Liska, Carl Sorensen
 
 
+@subsubheading Frescobaldi Extensions
+
+Starting with the current release 3.1
+@uref{http://frescobaldi.org, Frescobaldi} has an extension API that
+allows the easy integration of arbitrary functionality in the editing
+environment.  These could range from, say, document statistics and
+accounting functionality to fancy features like a built-in video chat
+client or a stock market ticker.
+
+We would welcome project suggestions about arbitrary Frescobaldi
+extensions of appropriate complexity that add substantial functionality
+for working with LilyPond scores which might not be suitable to be
+included into Frescobaldi itself.
+
+As @emph{suggestions} and examples may serve: a project management
+extension that can manage repetoire of arbitrary complexity, handle
+the generation of template files and the compilation process. Or an
+extension to manage the @uref{https://openlilylib.org, openLilyLib}
+infrastructure.
+
+@emph{Difficulty:} easy/medium
+
+@emph{Requirements:} Python, (PyQt)
+
+@emph{Optional:} GUILE Scheme (if functionality involves LilyPond
+internals)
+
+@emph{Mentor:} @emph{Urs Liska}
+
+
 @subsubheading Support for Style Sheets
 
 LilyPond's engraving output can be tweaked to the least detail, and one

Remove LO extension from GSoC ideas list (issue 569380043 by m...@ursliska.de)

2020-02-19 Thread mail 
Reviewers: ,

Message:
Removing this suggestion from the GSoC page
is uncontroversial, I will push after successful tests.

Description:
Remove LO extension from GSoC ideas list

Please review this at https://codereview.appspot.com/569380043/

Affected files (+0, -27 lines):
  M Documentation/included/gsoc.itexi


Index: Documentation/included/gsoc.itexi
diff --git a/Documentation/included/gsoc.itexi 
b/Documentation/included/gsoc.itexi
index 
40a4b59354caaafd43141e4e56c7ad321cf4872e..e8ab60136d9096b867175d015062320eb196d80a
 100644
--- a/Documentation/included/gsoc.itexi
+++ b/Documentation/included/gsoc.itexi
@@ -127,33 +127,6 @@ Working in this project will mainly be done in the
 @emph{Mentor}: Peter Bjuhr
 
 
-@subsubheading Rewrite LibreOffice LilyPond Extension with Python
-
-The @uref{http://ooolilypond.sourceforge.net/, OOoLilyPond} extension
-made it possible to conveniently include LilyPond score snippets in
-OpenOffice.org/LibreOffice Writer, Draw and Impress documents while
-keeping source and image together.  After many years without development
-an initial effort has started to make the extension compatible again
-with current versions of LibreOffice and LilyPond.
-
-However, as the LibreOffice ecosystem has changed substantially it is
-now possible to rewrite the extension with Python and PyQt.  This will
-not only be more powerful in general but will allow the integration of
-functionality from @uref{http://frescobaldi.org, Frescobaldi}, such as
-for example syntax highlighting, entry helpers, score wizards or musical
-transformations.
-
-@emph{Difficulty:} easy/medium
-
-@emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice
-extension basics
-
-@emph{Recommended knowledge:} Familiarity with Frescobaldi code based
-or willingness to learn during bonding period
-
-@emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
-
-
 @subsubheading Fix Beaming Patterns/Beam Subdivisions and Tuplets
 
 Subdivision is an important way to improve the readability of beamed

Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)

2020-01-29 Thread mail 
Reviewers: ,

Message:
Unfortunately I haven't set up a build system on my new computer yet, so
this patch is not tested locally at all, so I'm humbly waiting for the
automated tests to succeed or fail ...

Description:
Move Guile-style modules from scm to scm-modules

As an initial step towards a package mechanism this patch
separates .scm files in /scm that are directly loaded with
ly:load from those that are explicitly loaded with
(use-modules (scm ...

The latter are moved to a new directory /scm-modules, and
the (use-modules clauses adjusted accordingly.





Load Scheme modules through scm-modules


Move Scheme modules to scm-modules

Please review this at https://codereview.appspot.com/567140045/

Affected files (+83, -7862 lines):
  M Documentation/snippets/accordion-register-symbols.ly
  M input/regression/display-lily-tests.ly
  M input/regression/scheme-book-scores.ly
  M input/regression/to-xml.ly
  M ly/articulate.ly
  M ly/festival.ly
  M ly/graphviz-init.ly
  M ly/guile-debugger.ly
  M ly/init.ly
  A + scm-modules/accreg.scm
  A + scm-modules/clip-region.scm
  A + scm-modules/coverage.scm
  A + scm-modules/display-lily.scm
  A + scm-modules/editor.scm
  A + scm-modules/framework-eps.scm
  A + scm-modules/framework-null.scm
  A + scm-modules/framework-ps.scm
  A + scm-modules/framework-scm.scm
  A + scm-modules/framework-svg.scm
  A + scm-modules/graphviz.scm
  A + scm-modules/guile-debugger.scm
  A + scm-modules/lily.scm
  A + scm-modules/ly-syntax-constructors.scm
  A + scm-modules/memory-trace.scm
  A + scm-modules/output-ps.scm
  A + scm-modules/output-socket.scm
  A + scm-modules/output-svg.scm
  A + scm-modules/page.scm
  A + scm-modules/paper-system.scm
  A + scm-modules/ps-to-png.scm
  A + scm-modules/safe-utility-defs.scm
  A + scm-modules/song.scm
  A + scm-modules/song-util.scm
  A + scm-modules/to-xml.scm
  D scm/accreg.scm
  M scm/backend-library.scm
  M scm/chord-entry.scm
  D scm/clip-region.scm
  D scm/coverage.scm
  M scm/define-music-display-methods.scm
  M scm/define-music-types.scm
  M scm/define-note-names.scm
  D scm/display-lily.scm
  M scm/document-markup.scm
  M scm/documentation-generate.scm
  D scm/editor.scm
  D scm/framework-eps.scm
  D scm/framework-null.scm
  D scm/framework-ps.scm
  D scm/framework-scm.scm
  M scm/framework-socket.scm
  D scm/framework-svg.scm
  D scm/graphviz.scm
  D scm/guile-debugger.scm
  D scm/lily.scm
  M scm/lily-library.scm
  D scm/ly-syntax-constructors.scm
  D scm/memory-trace.scm
  M scm/music-functions.scm
  D scm/output-ps.scm
  D scm/output-socket.scm
  D scm/output-svg.scm
  D scm/page.scm
  M scm/paper.scm
  D scm/paper-system.scm
  D scm/ps-to-png.scm
  D scm/safe-utility-defs.scm
  D scm/song.scm
  D scm/song-util.scm
  M scm/stencil.scm
  D scm/to-xml.scm
  M scripts/lilypond-invoke-editor.scm

Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)

2012-01-20 Thread md5i . mail 


http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy#newcode432
lily/parser.yy:432: %type  list_music
I must *strongly* recommend that the name of either music_list or
list_music be changed.  Even if the names make distinct sense, it is far
to easy to transpose identifiers like this when reading or writing code.
 (I have made this mistake in my own code many times in the past.)
Given the existence of other _list types, I suggest that the name of
list_music be changed.  Maybe "wrapped_music" or "music_chord"...

http://codereview.appspot.com/5440084/

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

Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-20 Thread md5i . mail 

http://codereview.appspot.com/5489092/

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

Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-20 Thread md5i . mail 

On 2011/12/20 16:27:08, Graham Percival wrote:

On Tue, Dec 20, 2011 at 02:52:34AM +, mailto:md5i.m...@gmail.com

wrote:

>
> In point of fact, I found no additional errors when running make

check.

> Please understand, though, that I have a 32-bit machine.  Other

warnings

> may pup up with a 64-bit compile.



hmm, was this with
   -Wextra -Wconversion -Werror
?


Nope.  Just with -Wconversion -Werror -Wall -W -Wno-pmf-conversions
-Woverloaded-virtual

If I get time, I'll try with -Wextra and see what I get

http://codereview.appspot.com/5489092/

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

Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-20 Thread md5i . mail 

On 2011/12/20 14:02:50, Reinhold wrote:

Is anyone here using a 64-bit OS? There are ~150 compiler warnings

when

compiling lilypond currently (see bug 1890), so -Werror can't be

enabled on

64-bit systems.


Yes, this does not surprise me.  I wish I had a 64-bit system, but I'm
not due for an upgrade for another year or so.  My patch is a small
maintenance patch, only aimed at solving the problems I can see.


http://codereview.appspot.com/5489092/

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

Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-20 Thread md5i . mail 


http://codereview.appspot.com/5489092/diff/1/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/5489092/diff/1/lily/parser.yy#newcode36
lily/parser.yy:36: /* Define to get rid of conversion warning, int ->
int16_t.  This has
On 2011/12/20 08:32:27, dak wrote:

I think the side effect of significantly increasing the parse table

size here is

disproportionate.



We should look for other remedies.


I'd love to see another solution, but this was the only good one I was
able to find.  The problem is the part of the resulting parser.cc that
reads:

  yysetstate:
*yyssp = yystate;

yyssp is a yytype_int16*, and yystate is int.  yytype_int16 can be
changed via the YYTYPE_INT16 macro, but the int cannot be.  Why is it an
int?  I don't know.  From how it is used in the code I see no reason it
should not be a yytype_int16 as well.  Unfortunately, I could not figure
out to make this happen, short of postprocessing the resulting parser.cc
file.

Otherwise, the only solution I can think of for this is to exempt
parser.cc from -Werror.

http://codereview.appspot.com/5489092/

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

Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-20 Thread md5i . mail 

Reviewers: ,

Message:
A set of changes to allow lilypond to be built with -Werror using gcc
4.6.2 on i386.  I don't know if these changes are desirable, but I am
submitting them in the hopes that they may be useful.

Description:
Changes to allow compiling with -Werror using gcc 4.6.2 on i386.

Please review this at http://codereview.appspot.com/5489092/

Affected files:
  M lily/beaming-pattern.cc
  M lily/include/moment.hh
  M lily/moment.cc
  M lily/parser.yy


Index: lily/beaming-pattern.cc
diff --git a/lily/beaming-pattern.cc b/lily/beaming-pattern.cc
index  
916ec145af96d0e438fe33db217439bc2d68660c..51f7ade5ed5dfe03977c85e0a2ffcf537c541992  
100644

--- a/lily/beaming-pattern.cc
+++ b/lily/beaming-pattern.cc
@@ -184,7 +184,7 @@ find_location (SCM grouping, Moment base_moment, Moment  
start_moment,


   while (*next_group_pos < *next_beat_pos)
 {
-  int count = 1;  //default -- 1 base moments in a beam
+  I64 count = 1;  //default -- 1 base moments in a beam
   if (scm_is_pair (grouping))
 {
   count = scm_to_int (scm_car (grouping));
@@ -193,13 +193,13 @@ find_location (SCM grouping, Moment base_moment,  
Moment start_moment,


   // If we have a tuplet, the count should be determined from
   // the maximum tuplet size for beamed tuplets.
-  int tuplet_count = factor.num ();
+  I64 tuplet_count = factor.num ();
   if (tuplet_count > 1)
 {
   // We use 1/8 as the base moment for the tuplet because it's
   // the largest beamed value.  If the tuplet is shorter, it's
   // OK, the code still works
-  int test_count = (tuplet_count * Moment (Rational (1, 8)) /  
base_moment).num ();
+  I64 test_count = (tuplet_count * Moment (Rational (1, 8)) /  
base_moment).num ();

   if (test_count > count) count = test_count;
 }
   *group_pos = *next_group_pos;
@@ -213,7 +213,7 @@ Beaming_pattern::find_rhythmic_importance  
(Beaming_options const &options)

   Moment group_pos (0);  // 0 is the start of the first group
   Moment next_group_pos (0);
   Moment next_beat_pos (options.base_moment_);
-  int tuplet_count = 1;
+  I64 tuplet_count = 1;

   SCM grouping = options.grouping_;
   vsize i = 0;
Index: lily/include/moment.hh
diff --git a/lily/include/moment.hh b/lily/include/moment.hh
index  
5671d6b2342b7cbf915b017faa84e8d22fc23532..7c0618c6c803cb123ebd9f9de2a9e93a8e9ab685  
100644

--- a/lily/include/moment.hh
+++ b/lily/include/moment.hh
@@ -32,7 +32,7 @@ class Moment
   DECLARE_SIMPLE_SMOBS (Moment);
 public:
   Moment ();
-  Moment (int m);
+  Moment (I64 m);

   Moment (Rational, Rational);
   Moment (Rational m);
Index: lily/moment.cc
diff --git a/lily/moment.cc b/lily/moment.cc
index  
94d67a7b10596ebaf72800cae4d1eb54ad6cd356..7a2095b7c030b157d057e166dfcb5e1dc3ef7d18  
100644

--- a/lily/moment.cc
+++ b/lily/moment.cc
@@ -25,7 +25,7 @@ Moment::Moment ()
 {
 }

-Moment::Moment (int m)
+Moment::Moment (I64 m)
 {
   main_part_ = Rational (m);
   grace_part_ = Rational (0);
Index: lily/parser.yy
diff --git a/lily/parser.yy b/lily/parser.yy
index  
86973f3ae1971137259473873da25d79196ea2c7..02d84dd8543271aa7ffcf8349dfa75214c806861  
100644

--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -33,6 +33,9 @@
 #define YYLLOC_DEFAULT(Current,Rhs,N) \
((Current).set_location ((Rhs)[1], (Rhs)[N]))

+/* Define to get rid of conversion warning, int -> int16_t.  This has
+   the side-effect of making the parse stack wider. */
+#define YYTYPE_INT16 int

 %}

@@ -2925,10 +2928,10 @@ number_factor:
 bare_number:
bare_number_closed
| UNSIGNED NUMBER_IDENTIFIER{
-   $$ = scm_product ($1, $2)
+   $$ = scm_product ($1, $2);
}
| REAL NUMBER_IDENTIFIER{
-   $$ = scm_product ($1, $2)
+   $$ = scm_product ($1, $2);
}
;




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

Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-19 Thread md5i . mail 

http://codereview.appspot.com/5489092/

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

Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-19 Thread md5i . mail 

On 2011/12/20 01:54:29, Graham Percival wrote:


You'll probably find a ton of more errors when running 'make check' --
apparently that compiles some stuff in flower/ that isn't compiled

during a

normal make.


In point of fact, I found no additional errors when running make check.
Please understand, though, that I have a 32-bit machine.  Other warnings
may pup up with a 64-bit compile.

http://codereview.appspot.com/5489092/

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

Re: Changes to allow compiling with -Werror using gcc 4.6.2 on i386. (issue 5489092)

2011-12-19 Thread md5i . mail 


http://codereview.appspot.com/5489092/diff/1/lily/beaming-pattern.cc
File lily/beaming-pattern.cc (right):

http://codereview.appspot.com/5489092/diff/1/lily/beaming-pattern.cc#newcode187
lily/beaming-pattern.cc:187: I64 count = 1;  //default -- 1 base moments
in a beam
On 2011/12/20 01:54:29, Graham Percival wrote:

huh, I've never encountered I64 before... why does this particular int

need to

be explicitly 64 bits?  If we really can't fit that data into 32 bits,

it would

be nice to add a comment explaining why.

The variable count has to be I64, because it may be set to the result of
test_count, which is I64.  test_count is I64 because tuplet_count is
I64, and tuplet_count is I64 because factor.num() is I64.  In each case,
to use a smaller width could, in theory as far as the compiler is
concerned, truncate a value.  In practice, this almost certainly never
happens.  The alternative is to explicitly cast I64 values to int.  That
may be a better approach, but I prefer to take a conservative approach,
and avoid casts whenever possible.

http://codereview.appspot.com/5489092/

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

Re: grob.cc: rewrite O(n^2) algorithm in Grob::common_refpoint algorithm to O(n) (issue 5371050)

2011-11-10 Thread md5i . mail 


http://codereview.appspot.com/5371050/diff/1/lily/grob.cc
File lily/grob.cc (right):

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode536
lily/grob.cc:536: c = c->dim_cache_[a].parent_;
On 2011/11/10 16:41:54, joeneeman wrote:

After this loop, balance will be 0, right? So the next loop won't do

anything...
It seems to me that this is true ... unless balance was negative before
the loop.  That's what the next loop is handling, I believe.

http://codereview.appspot.com/5371050/diff/1/lily/grob.cc#newcode542
lily/grob.cc:542: while (c != d) {
On 2011/11/10 16:41:54, joeneeman wrote:

The old version would return 0 if there was no common refpoint (which

is

possible if the grob hierarchy hasn't been fully built yet). I'd

suggest a

"while (c && c != d)" to keep the old behavior.

The balancing code above ensures that the d and c chains are the same
length.  Therefore if there is no common refpoint, the loop will exit
when c and d are both 0, which will maintain the old behavior.

http://codereview.appspot.com/5371050/

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

Re: MIDI: intelligently combine overlapping notes. (issue4520050)

2011-05-11 Thread md5i . mail 

On 2011/05/11 23:12:08, Keith wrote:

http://codereview.appspot.com/4520050/diff/9001/flower/include/pqueue.hh#newcode110

flower/include/pqueue.hh:110: void del (vsize i)
Rather than change the 'flower' library to support deletion from the

heap, I

suggest we continue to use the ignore_ flag on items we would delete.



The formerly-used "lazy deletion" technique seems appropriate for the

note-of

queue, because deletions are rare.


Makes sense to me. I don't recall if "_ignore" existed when I originally
wrote the patch, several years ago now.


http://codereview.appspot.com/4520050/diff/9001/lily/midi-walker.cc
File lily/midi-walker.cc (right):



http://codereview.appspot.com/4520050/diff/9001/lily/midi-walker.cc#newcode94

lily/midi-walker.cc:94: if (now_ticks == stop_note_queue[i].val.first
The use of the .first field to cache the note-on-time was difficult

for me to

understand.



I suggest following pointers as was done to find now_ticks:
int queued_ticks =
  stop_note_queue[i].val.second->audio_->audio_column_->ticks ()


Good call, in my opinion.  I was never happy with the Pair.


http://codereview.appspot.com/4520050/

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

MIDI: intelligently combine overlapping notes. (issue4520050)

2011-05-11 Thread md5i . mail 

Small variable nit upon rereading this patch.  No change in semantics.


http://codereview.appspot.com/4520050/diff/1/flower/include/pqueue.hh
File flower/include/pqueue.hh (right):

http://codereview.appspot.com/4520050/diff/1/flower/include/pqueue.hh#newcode121
flower/include/pqueue.hh:121: vsize next = i / 2;
This should really be tgt / 2, for consistency.

http://codereview.appspot.com/4520050/

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