openlilylib-user — General openLilyLib discussion

Re: [oll-user] 'snippets' Github interface idea

[Janek W. <lem...@gm...>]

2013/9/13 Urs Liska <ul...@op...>

>  Am 13.09.2013 01:20, schrieb Janek Warchoł:
>
 In the basic version the generated file would contain
>> - A heading and a general short introductory text
>> - A generated image (the example output of the compilable file)
>>    -> one more incentive to include good examples
>> - The complete code listing
>>    (unfortunately it isn't possible to provide code highlighting like in
>> the blog posts)
>>
>
>  This could simply be a link to the snippet file, if we wanted to make
> things simple.
>
> I would prefer including the listing. This shouldn't be really
> complicated, and it would make the code readable in the context of the
> description. Opening .ly files in a browser usually isn't really exciting
> ...
>

+1

>  Actually, we may be able to provide syntax highligting: as far as i
> know, you can insert HTML into markdown, so we could use your html-export
> from Frescobaldi to produce html code and paste it into the .md file!
> ...for some reason this doesn't work as expected.  I've added a markdown
> file containing html code generated using your Frescobaldi export, and it
> isn't coloredd.  I think that Github isn't respecting some aspect of html
> formatting, maybe that's a bug.
>  See my attempt here:
>
> https://github.com/openlilylib/snippets/blob/markdown-test/notation-snippets/scaling-stencils.md
>
>
> As you noticed, I had tried the same before ;-)
> Having written to Github is a good idea. Although I don't think it's a bug
> but rather an omission. Maybe even on purpose, e.g. for security reasons.
>

As for now i was told to report this to pygments:
http://bitbucket.org/birkenfeld/pygments-main/issues

>   In a later version one could (quite easily) extract meta information
>> from the snippet and provide them in a formatted and structured display.
>>
>
>  In fact, we might want to switch to markdown in snippet descriptions
> because of this.
>
>  The script would be run locally every now and then by an admin.
>>
>
>  Easy to do with a cron job.
>
>  I would prefer doing it as a Git hook.
> It should be possible to check which files have been affected by a commit
> and act upon this information.
>

I suppose that It would have to be done as a post-fetch hook, and we would
probably need cron jobs anyway to ensure that some of the admins fetch
regularly.

>   Some issues to be considered:
>> - Try to determine snippets to be processed (i. e. only new or modified
>> ones)
>>    recompiling snippets with differing LIlyPond versions would result in
>> the images to be modified
>>    (i.e. detected as changes by Git)
>>
>
>  This should be easy: just store the committish of the revision of the
> snippet that was used for producing .md and .png files, and check if think
> that having a .png file in the snippet directory.  If there were changes in
> the snippet file since that commit, recompile.
>
>
> You're more experienced with Git than I am. But I think if we hook into
> the commit itself it would be easier and more reliable to retrieve
> information on the affected files themselves.
>

I haven't used git hooks yet, but as far as i understand it to use a
post-commit hook everyone needs to configure this hook in their
repositories, and probably it wouldn't work with github's web interface.
So, instead of using the post-commit hook we would run the script as
post-fetch hook.

best,
Janek
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] 'snippets' Github interface idea

[Urs L. <ul...@op...>]

Am 13.09.2013 01:20, schrieb Janek Warchoł:
> Hi all,
>
> 2013/9/10 Urs Liska <ul...@op... <mailto:ul...@op...>>
>
>     I had an idea to improve the web presentation of the snippets on
>     Github:
>
>     Write a script that iterates over all snippets and generate a Markdown
>     file to display the snippet in the Github interface.
>     I see two options:
>     - generate an accompanying .md file that can be clicked upon
>     - place all snippets in its dedicated subdirectory and create a
>     README.md file
>
>     I would suggest the second solution although that will result in a
>     large
>     number of subdirectories.
>     This way as soon as one opens the directory the README is displayed
>     automatically.
>
>
> The more i think about this, the more i like it. Having one additional 
> layer of directories seems to be a small price to pay for 
> user-friendly interface.  In fact, with such an interface our 
> repository would be almost as functional as LSR currently is.
>
>     In the basic version the generated file would contain
>     - A heading and a general short introductory text
>     - A generated image (the example output of the compilable file)
>        -> one more incentive to include good examples
>     - The complete code listing
>        (unfortunately it isn't possible to provide code highlighting
>     like in
>     the blog posts)
>
>
> This could simply be a link to the snippet file, if we wanted to make 
> things simple.

I would prefer including the listing. This shouldn't be really 
complicated, and it would make the code readable in the context of the 
description. Opening .ly files in a browser usually isn't really 
exciting ...
>
> Actually, we may be able to provide syntax highligting: as far as i 
> know, you can insert HTML into markdown, so we could use your 
> html-export from Frescobaldi to produce html code and paste it into 
> the .md file!
> ...for some reason this doesn't work as expected.  I've added a 
> markdown file containing html code generated using your Frescobaldi 
> export, and it isn't coloredd.  I think that Github isn't respecting 
> some aspect of html formatting, maybe that's a bug.
> See my attempt here:
> https://github.com/openlilylib/snippets/blob/markdown-test/notation-snippets/scaling-stencils.md

As you noticed, I had tried the same before ;-)
Having written to Github is a good idea. Although I don't think it's a 
bug but rather an omission. Maybe even on purpose, e.g. for security 
reasons.

>
>     In a later version one could (quite easily) extract meta information
>     from the snippet and provide them in a formatted and structured
>     display.
>
>
> In fact, we might want to switch to markdown in snippet descriptions 
> because of this.
>
>     The script would be run locally every now and then by an admin.
>
>
> Easy to do with a cron job.

I would prefer doing it as a Git hook.
It should be possible to check which files have been affected by a 
commit and act upon this information.

>
>     Some issues to be considered:
>     - Try to determine snippets to be processed (i. e. only new or
>     modified
>     ones)
>        recompiling snippets with differing LIlyPond versions would
>     result in
>     the images to be modified
>        (i.e. detected as changes by Git)
>
>
> This should be easy: just store the committish of the revision of the 
> snippet that was used for producing .md and .png files, and check if 
> think that having a .png file in the snippet directory.  If there were 
> changes in the snippet file since that commit, recompile.

You're more experienced with Git than I am. But I think if we hook into 
the commit itself it would be easier and more reliable to retrieve 
information on the affected files themselves.

>
>     - Determine appropriate LilyPond versions to compile the snippets
>
>     I would write such a script in Python.
>
>     What do you think?
>
>
> go for it!

One day ...

Best
Urs
>
> best,
> Janek

-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] 'snippets' Github interface idea

[Janek W. <lem...@gm...>]

Hi all,

2013/9/10 Urs Liska <ul...@op...>

> Hi folks,
>
> I try for the first time to use the oll-user list for the purpose of
> discussion of the new snippets repository.
>
> I suggest doing this in the future for two reasons:
> - automatically include anybody who might be interested
>    (including people one wouldn't have thought of in the first place)
> - keeping the content available in the public mailing list archive
>

+1


> I had an idea to improve the web presentation of the snippets on Github:
>
> Write a script that iterates over all snippets and generate a Markdown
> file to display the snippet in the Github interface.
> I see two options:
> - generate an accompanying .md file that can be clicked upon
> - place all snippets in its dedicated subdirectory and create a
> README.md file
>
> I would suggest the second solution although that will result in a large
> number of subdirectories.
> This way as soon as one opens the directory the README is displayed
> automatically.
>

The more i think about this, the more i like it.  Having one additional
layer of directories seems to be a small price to pay for user-friendly
interface.  In fact, with such an interface our repository would be almost
as functional as LSR currently is.


> In the basic version the generated file would contain
> - A heading and a general short introductory text
> - A generated image (the example output of the compilable file)
>    -> one more incentive to include good examples
> - The complete code listing
>    (unfortunately it isn't possible to provide code highlighting like in
> the blog posts)
>

This could simply be a link to the snippet file, if we wanted to make
things simple.

Actually, we may be able to provide syntax highligting: as far as i know,
you can insert HTML into markdown, so we could use your html-export from
Frescobaldi to produce html code and paste it into the .md file!
...for some reason this doesn't work as expected.  I've added a markdown
file containing html code generated using your Frescobaldi export, and it
isn't coloredd.  I think that Github isn't respecting some aspect of html
formatting, maybe that's a bug.
See my attempt here:
https://github.com/openlilylib/snippets/blob/markdown-test/notation-snippets/scaling-stencils.md

In a later version one could (quite easily) extract meta information
> from the snippet and provide them in a formatted and structured display.
>

In fact, we might want to switch to markdown in snippet descriptions
because of this.

The script would be run locally every now and then by an admin.
>

Easy to do with a cron job.


> Some issues to be considered:
> - Try to determine snippets to be processed (i. e. only new or modified
> ones)
>    recompiling snippets with differing LIlyPond versions would result in
> the images to be modified
>    (i.e. detected as changes by Git)
>

This should be easy: just store the committish of the revision of the
snippet that was used for producing .md and .png files, and check if think
that having a .png file in the snippet directory.  If there were changes in
the snippet file since that commit, recompile.


> - Determine appropriate LilyPond versions to compile the snippets
>
> I would write such a script in Python.
>
> What do you think?
>

go for it!

best,
Janek
-------------- next part --------------
An HTML attachment was scrubbed...

[oll-user] 'snippets' Github interface idea

[Urs L. <ul...@op...>]

Hi folks,

I try for the first time to use the oll-user list for the purpose of 
discussion of the new snippets repository.

I suggest doing this in the future for two reasons:
- automatically include anybody who might be interested
   (including people one wouldn't have thought of in the first place)
- keeping the content available in the public mailing list archive

#########################

I had an idea to improve the web presentation of the snippets on Github:

Write a script that iterates over all snippets and generate a Markdown 
file to display the snippet in the Github interface.
I see two options:
- generate an accompanying .md file that can be clicked upon
- place all snippets in its dedicated subdirectory and create a 
README.md file

I would suggest the second solution although that will result in a large 
number of subdirectories.
This way as soon as one opens the directory the README is displayed 
automatically.

In the basic version the generated file would contain
- A heading and a general short introductory text
- A generated image (the example output of the compilable file)
   -> one more incentive to include good examples
- The complete code listing
   (unfortunately it isn't possible to provide code highlighting like in 
the blog posts)

In a later version one could (quite easily) extract meta information 
from the snippet and provide them in a formatted and structured display.

The script would be run locally every now and then by an admin.
Some issues to be considered:
- Try to determine snippets to be processed (i. e. only new or modified 
ones)
   recompiling snippets with differing LIlyPond versions would result in 
the images to be modified
   (i.e. detected as changes by Git)
- Determine appropriate LilyPond versions to compile the snippets

I would write such a script in Python.

What do you think?
Urs

[oll-user] openlilylib.org website

[Urs L. <ul...@op...>]

Hi all,

it's quite some time since the last activity has happened on this list, 
but we all were busy with other things ...
Today I have completely reviewed the content of the openlilylib.org 
website and I'd be happy about your comments and suggestions.

If you read through it and find something that just shouts for your 
participation please do not hesitate.

Best
Urs

Re: [oll-user] WordPress for openlilylib.org?

[Urs L. <ul...@op...>]

Am 05.06.2013 22:40, schrieb Janek Warchoł:
> 2013/6/4 Urs Liska <acc...@ur...>
>
>> Hi all,
>>
>> what would you think about using WordPress for openlilylib.org?
>>
>> According to Mr. Google and
>> http://www.sitepoint.com/non-blog-wordpress-site/
>> it seems quite straightforward to use WordPress for non-blog sites too
>> (which actually was a problem with all static site generators I saw when
>> searching.
>>
> This may be helpful: http://www.sitepoint.com/non-blog-wordpress-site/
As I had already quoted that link I surely won't disagree ;-)
But there are plenty more info to be found on the net. Maybe I'll try to 
convert the existing template into a WordPress theme, which shouldn't be 
too hard either. But of course I don't care too much about the existing 
design.

Best
Urs
>
> best,
> JAnek
>

Re: [oll-user] WordPress for openlilylib.org?

[Janek W. <lem...@gm...>]

2013/6/4 Urs Liska <acc...@ur...>

> Hi all,
>
> what would you think about using WordPress for openlilylib.org?
>
> According to Mr. Google and
> http://www.sitepoint.com/non-blog-wordpress-site/
> it seems quite straightforward to use WordPress for non-blog sites too
> (which actually was a problem with all static site generators I saw when
> searching.
>
> Advantages as I see them are
> - direct access to edit content (no need to edit locally and upload (via
> FTP or Git))
> - relatively easy to use
> - easy way to grant different access rights
> - no problems to include media (i.e. images, pdfs and binary downloads)
> - it should be simple to include a blog (although I somewhat prefer
> having only one blog, i.e. rather an 'openlilylib' category on
> lilypondblog than a dedicated blog).
> - when also the lilypond blog is run on WordPress there is only one new
> tool to learn.
>

yes, this seems a good idea.


> The only thing that is disturbing me so far is WordPress' content editor
> (although I'm not sure if that's WordPress' fault or from
> wordpress.com). I have the impression it is a damn WYSIWIG thing that
> enters all sorts of dirt in the markup. I found the idea of the site
> generator tools very appealing to edit plain text files with markdown
> syntax. But that's maybe a minor issue, and one that can be overcome.
>

In the editing frame, in the upper right corner there's an option to switch
to "text view".  I think that may solve your problem :)


> As a side note: would blog.openlilylib.org be an adequate address for
> the lilypondblog?
>

I think so, and i'll be pushing in that direction.


2013/6/4 Urs Liska <ul...@op...>

> Well, actually I've already decided to go that way.
> Installation of WP on my server really took me 5 minutes, and a dummy is
> already running at
> openlilylib.ursliska.de
> This address is only a placeholder as long as the current
> www.openlilylib.org has better content. It will take me three more
> minutes to map the right domain name to the WP dir.
>

Great!


> Any ideas or experience with WP?
> First thing obviously is to find a usable theme for a non-blog web site.
>

This may be helpful: http://www.sitepoint.com/non-blog-wordpress-site/

best,
JAnek
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] WordPress for openlilylib.org?

[Urs L. <ul...@op...>]

Well, actually I've already decided to go that way.
Installation of WP on my server really took me 5 minutes, and a dummy is 
already running at
openlilylib.ursliska.de
This address is only a placeholder as long as the current 
www.openlilylib.org has better content. It will take me three more 
minutes to map the right domain name to the WP dir.

Any ideas or experience with WP?
First thing obviously is to find a usable theme for a non-blog web site.

Best
Urs


Am 04.06.2013 15:53, schrieb Urs Liska:
> Hi all,
>
> what would you think about using WordPress for openlilylib.org?
>
> According to Mr. Google and
> http://www.sitepoint.com/non-blog-wordpress-site/
> it seems quite straightforward to use WordPress for non-blog sites too
> (which actually was a problem with all static site generators I saw when
> searching.
>
> Advantages as I see them are
> - direct access to edit content (no need to edit locally and upload (via
> FTP or Git))
> - relatively easy to use
> - easy way to grant different access rights
> - no problems to include media (i.e. images, pdfs and binary downloads)
> - it should be simple to include a blog (although I somewhat prefer
> having only one blog, i.e. rather an 'openlilylib' category on
> lilypondblog than a dedicated blog).
> - when also the lilypond blog is run on WordPress there is only one new
> tool to learn.
>
> The only thing that is disturbing me so far is WordPress' content editor
> (although I'm not sure if that's WordPress' fault or from
> wordpress.com). I have the impression it is a damn WYSIWIG thing that
> enters all sorts of dirt in the markup. I found the idea of the site
> generator tools very appealing to edit plain text files with markdown
> syntax. But that's maybe a minor issue, and one that can be overcome.
>
> I can host it on my server (which isn't a 'donation' but rather using
> space which would otherwise be wasted). The domain name is hosted there
> anyway.
> If the need should arise it seems adequately simple to export the site
> to somewhere else.
>
> As a side note: would blog.openlilylib.org be an adequate address for
> the lilypondblog?
>
> Urs
> -------------- next part --------------
> An HTML attachment was scrubbed...
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

[oll-user] WordPress for openlilylib.org?

[Urs L. <acc...@ur...>]

Hi all,

what would you think about using WordPress for openlilylib.org?

According to Mr. Google and
http://www.sitepoint.com/non-blog-wordpress-site/
it seems quite straightforward to use WordPress for non-blog sites too 
(which actually was a problem with all static site generators I saw when 
searching.

Advantages as I see them are
- direct access to edit content (no need to edit locally and upload (via 
FTP or Git))
- relatively easy to use
- easy way to grant different access rights
- no problems to include media (i.e. images, pdfs and binary downloads)
- it should be simple to include a blog (although I somewhat prefer 
having only one blog, i.e. rather an 'openlilylib' category on 
lilypondblog than a dedicated blog).
- when also the lilypond blog is run on WordPress there is only one new 
tool to learn.

The only thing that is disturbing me so far is WordPress' content editor 
(although I'm not sure if that's WordPress' fault or from 
wordpress.com). I have the impression it is a damn WYSIWIG thing that 
enters all sorts of dirt in the markup. I found the idea of the site 
generator tools very appealing to edit plain text files with markdown 
syntax. But that's maybe a minor issue, and one that can be overcome.

I can host it on my server (which isn't a 'donation' but rather using 
space which would otherwise be wasted). The domain name is hosted there 
anyway.
If the need should arise it seems adequately simple to export the site 
to somewhere else.

As a side note: would blog.openlilylib.org be an adequate address for 
the lilypondblog?

Urs
-------------- next part --------------
An HTML attachment was scrubbed...

[oll-user] Submodules revisited

[Urs L. <ul...@op...>]

Hi all,

having worked on some other things lately I have the impression that the
repo organization is good as it is.
On our organization account https://github.com/openlilylib
there are now quite a lot of repos, and I assume this number could even
increase over time.

All of them have a workable history: Some actually have their original
history preserved, with some I have got as much out of the combined
repos as possible (i.e. back to the point where files have been moved
between folders, because that is where git filter-branch fails), some
are actually new.
_All_ old history is present in the oll-archive repository. This isn't
there to be used anymore but only in case someone has to inspect some
ancient history ...

Now that we have this set of parallel repositories I'm ready to give the
idea of submodules a fresh consideration.
AFAICS this would mean creating a new 'super-repo' and pulling the other
ones in it. This would also have the benefit that there was a place for
general issues relating to the project as a whole.

But as I don't have any experience and still feel insecure I'd like to
ask you for feedback:
- How would I start to set up a submodule approach?
- How would one fetch changes from all modules?
- What do I have to do if I commit updates to a submodule:
  - push to the remote repo?
  - push to the super-repo?
  - push to the remote repo and update the super-repo?

Any guidance gladly accepted.

Best
Urs

Re: [oll-user] OLLib renaming

[Urs L. <ul...@op...>]

Am Donnerstag, den 18.04.2013, 10:31 +0100 schrieb Ian Hulin:
> Hi Urs and all,
> On 18/04/13 09:19, Urs Liska wrote:
> > Hi all,
> > 
> > I'm busy reorganising the repos and making good progress, I think.
> > 
> > When coming to the OLLib subdirectory I realized that we should 
> > reconsider the naming.
> > 
...
> > 
> > Urs
> We've got some slightly conflicting goals, then.
> 1) is what looks good in 'The XXX library part of openLilyLib'
> 2) what is unique and descriptive in the file system structure
> 3) what is *not* too long for people typing the name in a hurry, and
> have mistake-prone fingers, like me.
You're right. Probably I wouldn't have had to ask if there weren't any
conflicts ;-)
> 
> How about openlilylib/oll-library?  (prefix all Open Lily Library
> stuff at this level with oll, separate it with a hyphen[1]), or your
> oll-lib suggestion above.
This means in our openlilylib root directory we'd have:
openlilylib
| oll-base (new: LaTeX classes/packages and maybe some helper scripts)
| oll-lib
| oll-tutorials
but:
| lilyglyphs
| musicexamples
| website
?

Alternative (Jan-Peter's preference):
openlilylib
| base
| lilyglyphs
| musicexamples
| lilylib
| tutorials
| website

I prefer the latter because the oll- is in most cases a redundancy.
Maybe ollib instead of lilylib, but see my comment on Jan-Peter's mail.

Urs


> 
> HTH
> Cheers,
> Ian
> 
> [1] The files within the directory or any parallel to this would not
> need the oll- prefix however.
> 
> 

Re: [oll-user] OLLib renaming

[Urs L. <ul...@op...>]

Am Donnerstag, den 18.04.2013, 11:44 +0200 schrieb Jan-Peter Voigt:
> Hi Urs,
> 
> now I have little time and can take a look at the progression this 
> project made. I have cloned (again ;) ) all repos from github and 
> succesfully compiled some of the tex files.
Be prepared that you might have to do that again, as the repos aren't
quite stable yet. But I hope that this will only result in additional
repos and the corresponding removal of folders in oll-archive.

> As I only use xelatex for some dedicated things, it took some time, to 
> make the cls and sty files visible for my texlive here. I use Ubuntu 
> precise with texlive 2012 and the solution is not very complicated, but 
> one has to know. So I propose to include this hint somewhere for example 
> in a README file:
> I created a directory: mkdir -p ~/texmf/tex/xelatex/
> and then created symbolic links to <path to openlilylib>/lilyglyphs 
> <path to openlilylib>/oll-archive/OLLlatex and <path to 
> openlilylib>/musicexamples in that directory.
> I didn't need to run texhash, because this location is the default place 
> user modifications.
I'm sure that had once been in a readme file, but due to the
reorganization that will have been buried somewhere.
Once the repos are fixed I'll look into that again.

> 
>  From the suggested names I would prefer lilylib or ollib.
I like lilylib - it is just that is actually the finger equivalent to a
tongue twister ;-)

ollib looks somewhat like a _word_ instead of the hybrid between acronym
and abbreviation it is. OLLib was better in this regard, but I think it
was a good suggestion to make all file/dir names lowercase.

See also my reply to Ian's post

Urs

> 
> Best,
> Jan-Peter
> 
> Am 18.04.2013 10:19, schrieb Urs Liska:
> > Hi all,
> >
> > I'm busy reorganising the repos and making good progress, I think.
> >
> > When coming to the OLLib subdirectory I realized that we should
> > reconsider the naming.
> >
> > Originally 'openLilyLib' was to be the name of the LilyPond library, but
> > when I decided to connect my other projects (i.e. the LaTeX packages) to
> > it it was clear that 'openLilyLib' would be the name of the complete
> > project. (I think '...Lib' is a good name for the 'family of resources'
> > I label it elsewhere.)
> > Consequently I renamed the library subdirectory to 'OLLib' - intending
> > to indicate that this is the actual library. But after some time I find
> > this somewhat obscure, and although this part is probably the one that
> > will be of most interest to you it actually is just one of several
> > subprojects.
> >
> > So I ask for suggestions for a better name in the sense 'The XXX
> > library, part of openLilyLib'.
> > We need a 'label' name and a repo/directory name. They may be the same
> > or different, at least the latter being lowercase.
> >
> > My suggestions (I always prepend the root folder):
> > - openlilylib/oll-lib
> > - openlilylib/lilylib
> > - openlilylib/lib
> > - openlilylib/llib
> > - openlilylib/ollib (the same as the current, in lowercase)
> >
> > Any better ideas?
> >
> > Urs
> >
> >
> > ------------------------------------------------------------------------------
> > Precog is a next-generation analytics platform capable of advanced
> > analytics on semi-structured data. The platform includes APIs for building
> > apps and a phenomenal toolset for data science. Developers can use
> > our toolset for easy data analysis & visualization. Get a free account!
> > http://www2.precog.com/precogplatform/slashdotnewsletter
> > _______________________________________________
> > openlilylib-user mailing list
> > ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openlilylib-user
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] OLLib renaming

[Jan-Peter V. <jp....@gm...>]

Hi Urs,

now I have little time and can take a look at the progression this 
project made. I have cloned (again ;) ) all repos from github and 
succesfully compiled some of the tex files.
As I only use xelatex for some dedicated things, it took some time, to 
make the cls and sty files visible for my texlive here. I use Ubuntu 
precise with texlive 2012 and the solution is not very complicated, but 
one has to know. So I propose to include this hint somewhere for example 
in a README file:
I created a directory: mkdir -p ~/texmf/tex/xelatex/
and then created symbolic links to <path to openlilylib>/lilyglyphs 
<path to openlilylib>/oll-archive/OLLlatex and <path to 
openlilylib>/musicexamples in that directory.
I didn't need to run texhash, because this location is the default place 
user modifications.

 From the suggested names I would prefer lilylib or ollib.

Best,
Jan-Peter

Am 18.04.2013 10:19, schrieb Urs Liska:
> Hi all,
>
> I'm busy reorganising the repos and making good progress, I think.
>
> When coming to the OLLib subdirectory I realized that we should
> reconsider the naming.
>
> Originally 'openLilyLib' was to be the name of the LilyPond library, but
> when I decided to connect my other projects (i.e. the LaTeX packages) to
> it it was clear that 'openLilyLib' would be the name of the complete
> project. (I think '...Lib' is a good name for the 'family of resources'
> I label it elsewhere.)
> Consequently I renamed the library subdirectory to 'OLLib' - intending
> to indicate that this is the actual library. But after some time I find
> this somewhat obscure, and although this part is probably the one that
> will be of most interest to you it actually is just one of several
> subprojects.
>
> So I ask for suggestions for a better name in the sense 'The XXX
> library, part of openLilyLib'.
> We need a 'label' name and a repo/directory name. They may be the same
> or different, at least the latter being lowercase.
>
> My suggestions (I always prepend the root folder):
> - openlilylib/oll-lib
> - openlilylib/lilylib
> - openlilylib/lib
> - openlilylib/llib
> - openlilylib/ollib (the same as the current, in lowercase)
>
> Any better ideas?
>
> Urs
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] OLLib renaming

[Ian H. <ia...@hu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Urs and all,
On 18/04/13 09:19, Urs Liska wrote:
> Hi all,
> 
> I'm busy reorganising the repos and making good progress, I think.
> 
> When coming to the OLLib subdirectory I realized that we should 
> reconsider the naming.
> 
> Originally 'openLilyLib' was to be the name of the LilyPond
> library, but when I decided to connect my other projects (i.e. the
> LaTeX packages) to it it was clear that 'openLilyLib' would be the
> name of the complete project. (I think '...Lib' is a good name for
> the 'family of resources' I label it elsewhere.) Consequently I
> renamed the library subdirectory to 'OLLib' - intending to indicate
> that this is the actual library. But after some time I find this
> somewhat obscure, and although this part is probably the one that 
> will be of most interest to you it actually is just one of several 
> subprojects.
> 
> So I ask for suggestions for a better name in the sense 'The XXX 
> library, part of openLilyLib'. We need a 'label' name and a
> repo/directory name. They may be the same or different, at least
> the latter being lowercase.
> 
> My suggestions (I always prepend the root folder): -
> openlilylib/oll-lib - openlilylib/lilylib - openlilylib/lib -
> openlilylib/llib - openlilylib/ollib (the same as the current, in
> lowercase)
> 
> Any better ideas?
> 
> Urs
We've got some slightly conflicting goals, then.
1) is what looks good in 'The XXX library part of openLilyLib'
2) what is unique and descriptive in the file system structure
3) what is *not* too long for people typing the name in a hurry, and
have mistake-prone fingers, like me.

How about openlilylib/oll-library?  (prefix all Open Lily Library
stuff at this level with oll, separate it with a hyphen[1]), or your
oll-lib suggestion above.

HTH
Cheers,
Ian

[1] The files within the directory or any parallel to this would not
need the oll- prefix however.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRb71pAAoJEBqidDirZqASGBMH/1ZTo/Fxi2XXJrH9Q/22varM
PqtVg9Y9WvbLt+OxDxlBzTKO+QnemgnbmenqU/TDTBRt5WZ+n4lnAsUlraPElQIw
HO8/IHxSe+C4xnZNmIivkyjaw7VaOVVu1cvjF6sdh3IAOppzKP1+nAj04UZCLP7v
76Mhb1dySTfiKRuAkH7RjfE2CgqMEcOg6cAAmf+X/ZauAiDY5/STebwLowEyvUwT
YKo7aYHRXhjd6tebUSgWQzmFTHdrhPd4J365es2HaPkRzph9KhtDKsi7V8xvOb3L
yDkHxcOUsJgx/48ZR+TLTjRMEvuz+S9dPdPDHmJiJVn5XDjJuw9mGOBHa6mg+uU=
=A7gO
-----END PGP SIGNATURE-----

Re: [oll-user] OLLib renaming

[Urs L. <ul...@op...>]

Update:

how to organize the directory structure?

We'll have one root directory, and part of the 'installation'
requirements is to make this root dir available to LilyPond.

I see two set-ups how to make the contents available to .ly documents:
(I'll write 'OLLIB' as a placeholder for a to-be-agreed-upon name)


\include "OLLIB.ily" for the full lib -> would be natural, but:
\include "tb/curvestoolbox.ily" is less expressive than
\include "OLLIB/curvestoolbox.ily". And
\include "includes/stylesheets/a4-lied.ily" is much less expressive than
\include "OLLIB/includes/stylesheets/a4-lied.ily"

So I propose to set up the root dir like:
- documentation
- examples
- templates
- OLLIB
  |- includes
  |- tb (see below)
     |- curves (etc.)
  |- full.ily
  |- curves.ily (etc. for loading individual sublibraries)

full.ily loads the complete library (but not examples, templates and
includes)-
curves.ily etc. load partial libraries
tb/ contains the code for the partial libraries, i.e. there is one
subfolder of tb/ for each .ily file

So the user can write forexample:
\include "OLLIB/full.ily"
\include "OLLIB/curves.ily"
\include "OLLIB/includes/scoreblocks/piano4hd.ily"

Examples and templates are items that aren't usually included but opened
and/or copied directly, so they can remain at the root level.

Any comments, disapproval, better ideas?

Urs

Am Donnerstag, den 18.04.2013, 10:19 +0200 schrieb Urs Liska:
> Hi all,
> 
> I'm busy reorganising the repos and making good progress, I think.
> 
> When coming to the OLLib subdirectory I realized that we should
> reconsider the naming.
> 
> Originally 'openLilyLib' was to be the name of the LilyPond library, but
> when I decided to connect my other projects (i.e. the LaTeX packages) to
> it it was clear that 'openLilyLib' would be the name of the complete
> project. (I think '...Lib' is a good name for the 'family of resources'
> I label it elsewhere.)
> Consequently I renamed the library subdirectory to 'OLLib' - intending
> to indicate that this is the actual library. But after some time I find
> this somewhat obscure, and although this part is probably the one that
> will be of most interest to you it actually is just one of several
> subprojects.
> 
> So I ask for suggestions for a better name in the sense 'The XXX
> library, part of openLilyLib'.
> We need a 'label' name and a repo/directory name. They may be the same
> or different, at least the latter being lowercase.
> 
> My suggestions (I always prepend the root folder):
> - openlilylib/oll-lib
> - openlilylib/lilylib
> - openlilylib/lib
> - openlilylib/llib
> - openlilylib/ollib (the same as the current, in lowercase)
> 
> Any better ideas?
> 
> Urs
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

[oll-user] OLLib renaming

[Urs L. <ul...@op...>]

Hi all,

I'm busy reorganising the repos and making good progress, I think.

When coming to the OLLib subdirectory I realized that we should
reconsider the naming.

Originally 'openLilyLib' was to be the name of the LilyPond library, but
when I decided to connect my other projects (i.e. the LaTeX packages) to
it it was clear that 'openLilyLib' would be the name of the complete
project. (I think '...Lib' is a good name for the 'family of resources'
I label it elsewhere.)
Consequently I renamed the library subdirectory to 'OLLib' - intending
to indicate that this is the actual library. But after some time I find
this somewhat obscure, and although this part is probably the one that
will be of most interest to you it actually is just one of several
subprojects.

So I ask for suggestions for a better name in the sense 'The XXX
library, part of openLilyLib'.
We need a 'label' name and a repo/directory name. They may be the same
or different, at least the latter being lowercase.

My suggestions (I always prepend the root folder):
- openlilylib/oll-lib
- openlilylib/lilylib
- openlilylib/lib
- openlilylib/llib
- openlilylib/ollib (the same as the current, in lowercase)

Any better ideas?

Urs

Re: [oll-user] Licensing questions

[Joseph R. W. <jos...@we...>]

On 04/12/2013 08:51 PM, Urs Liska wrote:
> But I wasn't talking about the recent discussion but back when I first
> presented my first tutorial with the Schoenberg example in it.

I think that's something that should be raised with the Free Software
Foundation.  As a general rule their attitude is flexible with respect to
circumstances where it's impossible to achieve goals without using non-free
media (as distinct from non-free software).

Consider e.g. Wikipedia which makes "fair use" of a fair number of copyrighted
photographs which lack free licensing terms.

The worst case scenario might be to separate out those tutorials into a separate
archive which isn't linked to.

By the way, I will get on and draft that email to SFLC this week.  It's been a
busy last few days. :-(

Re: [oll-user] Repository organization

[Janek W. <lem...@gm...>]

2013/4/14 Urs Liska <ul...@op...>

> Am Freitag, den 12.04.2013, 20:54 +0200 schrieb Urs Liska:
> > Maybe that's a good compromise. I'll wait a few days (to see if somebody
> > comes up with another idea), and give it a try.
>
> Seems I'm the one myself ;-)
>

;)


> I realized that at least for the lilyglyph and musicexamples
> repositories I haven't committed anything after merging the repos. So I
> can just restore them :-)
> - OLLib doesn't have any real history so far
> - tutorials don't need a real history so far
> - web doesn't either
> - LaTeX stuff could be done the way you suggested.
>

ok, good luck!
Janek
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] Repository organization

[Urs L. <ul...@op...>]

Am Freitag, den 12.04.2013, 20:54 +0200 schrieb Urs Liska:
> Am Freitag, den 12.04.2013, 19:18 +0200 schrieb Janek Warchoł:
> > 
> > 2013/4/12 Urs Liska <ul...@op...>
> >         So it remains open:
> >         Any ideas how to deal with the situation?
> >         
> > 
> > What about: use --filter-branch to harvest as much history as
> > possible, and stop at that (keeping the existing repo as an archive of
> > the history)?
> > 

> Maybe that's a good compromise. I'll wait a few days (to see if somebody
> comes up with another idea), and give it a try.
> 
Seems I'm the one myself ;-)
I realized that at least for the lilyglyph and musicexamples
repositories I haven't committed anything after merging the repos. So I
can just restore them :-)
- OLLib doesn't have any real history so far
- tutorials don't need a real history so far
- web doesn't either
- LaTeX stuff could be done the way you suggested.

Urs

> Urs
> > 
> > 
> > best,
> > 
> > Janek
> > 
> 
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] Learning manuals vs. reference documentation | lilydoc

[Urs L. <ul...@op...>]

Am Samstag, den 13.04.2013, 00:14 +0200 schrieb Janek Warchoł:
> Hi,
> 
> 2013/4/12 Urs Liska <ul...@op...>
>         Am Freitag, den 12.04.2013, 18:45 +0200 schrieb Janek Warchoł:
>         > This looks like a good idea.  However, i have limited
>         experience with
>         > such systems, so i don't have more thoughts on this topic.
>         
>         
>         We should probably look at two or three languages (e.g. Java
>         and Python)
>         and collect ideas about their syntay (i.e. how to document the
>         source
>         files).
>         Then we should discuss our special cases - because this is
>         another field
>         where we are facing the hybrid nature of LilyPond files as
>         source code
>         and documents.
> 
> 
> ok.  however, i'm afraid i won't have enough time for this anywhere
> soon :(

Probably it's basically enough to think about our needs first.
And here _only_ about the needs for the LilyPond library.

When I'll have managed to set up working Git repos I'll make an
announcement on lilypond-user and invite people to join oll-user to
discuss this on a broader base.

>  
> 
>         For our immediate need we could stick to documenting the
>         source code,
>         but for a real lilyDoc library we should also strive for
>         documenting the
>         content.
>         For example it would be a real improvement if we could enter
>         critical
>         remarks directly in the source code and let a script harvest
>         and output
>         them. This would an extremely cool feature when talking with
>         musicologists.
>         If I could for example enter the latex code for critical
>         remarks
>         directly in the source, then I'd have 2way point-and-click at
>         hand, i.e.
>         I could enter the remarks in the environment where I inspect
>         and correct
>         the score. Afterwards a script would parse the files, sort the
>         remarks
>         and spit out the (nearly finished) critical report. Cool!
> 
> 
> Awesome :)
> 
Not only for musicologist's use.
I now realized that this way one could enter comments when entering the
music, like open questions and critical remarks.
The output of such a script could serve as a special kind of issue
tracker: There is one document (e.g. pdf or html) that collects all
remarks and links them to the soruce code.
Could also made into a collaborative tool for 'crowd editing'.
During work they are either removed or turned into entries for the
critical report, and when the work is finished one can export them to
the format for the report.
The more I think about it the more I'm looking forward to it ...

Best
Urs
> 
> 
> 

Re: [oll-user] Learning manuals vs. reference documentation | lilydoc

[Janek W. <lem...@gm...>]

Hi,

2013/4/12 Urs Liska <ul...@op...>

> Am Freitag, den 12.04.2013, 18:45 +0200 schrieb Janek Warchoł:
> > This looks like a good idea.  However, i have limited experience with
> > such systems, so i don't have more thoughts on this topic.
>
> We should probably look at two or three languages (e.g. Java and Python)
> and collect ideas about their syntay (i.e. how to document the source
> files).
> Then we should discuss our special cases - because this is another field
> where we are facing the hybrid nature of LilyPond files as source code
> and documents.
>

ok.  however, i'm afraid i won't have enough time for this anywhere soon :(


> For our immediate need we could stick to documenting the source code,
> but for a real lilyDoc library we should also strive for documenting the
> content.
> For example it would be a real improvement if we could enter critical
> remarks directly in the source code and let a script harvest and output
> them. This would an extremely cool feature when talking with
> musicologists.
> If I could for example enter the latex code for critical remarks
> directly in the source, then I'd have 2way point-and-click at hand, i.e.
> I could enter the remarks in the environment where I inspect and correct
> the score. Afterwards a script would parse the files, sort the remarks
> and spit out the (nearly finished) critical report. Cool!
>

Awesome :)

Janek
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] Repository organization

[Urs L. <ul...@op...>]

Am Freitag, den 12.04.2013, 19:18 +0200 schrieb Janek Warchoł:
> 
> 2013/4/12 Urs Liska <ul...@op...>
>         So it remains open:
>         Any ideas how to deal with the situation?
>         
>         The simplest solution would be:
>         - Just remove all files except the ones needed for the new
>         repo with a
>         regular commit
>         - Move all remaining files to the desired new location in the
>         directory
>         structure, also with a regular commit.
>         Absolutely painless process, but of course each repo would
>         carry the
>         whole history.
>         
>         Second simplest solution:
>         - Add only the desired files to the new repos
>         - Keep the existing repo as the only instance of the history.
>         
>         I don't like both.
> 
> 
> What about: use --filter-branch to harvest as much history as
> possible, and stop at that (keeping the existing repo as an archive of
> the history)?
> 
> It's not a very good solution, but i'm not sure if doing more is worth
> the trouble.
> 
> I think only you can judge this, (as i've obviously had fallen behind
> with the project): is the history important enough?  Were there many
> situations where having current history significantly helped you?  One
> thing comes to my mind: since the early history is quite tangled, it
> may not be very helpful anyway in a few weeks/months from now.

Probably you're right. Maybe I just lack the freedom of mind to let that
history go ...
(as one experienced musicologist told me: be careful with your critical
remarks. Don't write too many of them, even as the first sketch: Once
you have something written down you don't want to drop that anymore ;-)

Maybe that's a good compromise. I'll wait a few days (to see if somebody
comes up with another idea), and give it a try.

Urs
> 
> 
> best,
> 
> Janek
> 

Re: [oll-user] Licensing questions

[Urs L. <ul...@op...>]

Am Freitag, den 12.04.2013, 18:52 +0200 schrieb Janek Warchoł:
> Hi,
> 
> 2013/4/6 Urs Liska <ul...@op...>
>         One thing I forgot in the above post:
>         If we should settle upon a more permissive license in some
>         parts we'd
>         have to take care that we still comply with GNU's ideas.
>         Not because I'm a purist or because I'm afraid of David K's
>         comments,
>         but because there was a discussion on lilypond-user about GNU
>         programs
>         (i.e. LilyPond) not being allowed to endorse or link to
>         non-free
>         software and/or documentation.
> 
> 
> Indeed.
> 
> Frankly, i got lost in the discussion on -user and all the legal
> problems that arise :(
I think that's what usually happens to most of us.
But I wasn't talking about the recent discussion but back when I first
presented my first tutorial with the Schoenberg example in it.

Best
Urs
> 
> 
> Janek 
> 
> 
> 

Re: [oll-user] Learning manuals vs. reference documentation | lilydoc

[Urs L. <ul...@op...>]

Am Freitag, den 12.04.2013, 18:45 +0200 schrieb Janek Warchoł:
> 2013/4/5 Urs Liska <ul...@op...>

> 
> 
>         2)
>         In what form should the reference documentation be supplied?
>         I think it would really be best to have that in the source
>         files
>         themselves, this being the most straightforward approach to
>         keep it up
>         to date.
>         But we definitely need that reference in pdf form too. Which
>         leads me to
>         an idea that I've had for some time already but didn't have
>         the
>         opportunity to tackle yet: I would really love to have yet one
>         more
>         independent subproject: lilyDoc.
>         This would be similar to Javadoc, pyDoc or any other source
>         code
>         documentation system.[....]
>         What I would suggest is to discuss the possible syntax of
>         do-commenting
>         LilyPond source files and use that for the reference
>         documentation, but
>         leave the development of a full-fledged lilyDoc for the
>         future. OTOH it
>         should be quite simple to write a preliminary script that
>         prepares LaTeX
>         source code from such commented source files (to have them
>         available for
>         PDF documents).
> 
> 
> This looks like a good idea.  However, i have limited experience with
> such systems, so i don't have more thoughts on this topic.
> 
We should probably look at two or three languages (e.g. Java and Python)
and collect ideas about their syntay (i.e. how to document the source
files).
Then we should discuss our special cases - because this is another field
where we are facing the hybrid nature of LilyPond files as source code
and documents.
For our immediate need we could stick to documenting the source code,
but for a real lilyDoc library we should also strive for documenting the
content.
For example it would be a real improvement if we could enter critical
remarks directly in the source code and let a script harvest and output
them. This would an extremely cool feature when talking with
musicologists.
If I could for example enter the latex code for critical remarks
directly in the source, then I'd have 2way point-and-click at hand, i.e.
I could enter the remarks in the environment where I inspect and correct
the score. Afterwards a script would parse the files, sort the remarks
and spit out the (nearly finished) critical report. Cool!
But that's just one idea. This would have to be thoroughly discussed in
a brain-storming, maybe not on a mailing list.

For now we can concentrate on a syntax to document a library, with
extending only in the back of our minds.

Urs
> 
> Janek
> 

Re: [oll-user] Repository organization

[Janek W. <lem...@gm...>]

2013/4/12 Urs Liska <ul...@op...>

> So it remains open:
> Any ideas how to deal with the situation?
>
> The simplest solution would be:
> - Just remove all files except the ones needed for the new repo with a
> regular commit
> - Move all remaining files to the desired new location in the directory
> structure, also with a regular commit.
> Absolutely painless process, but of course each repo would carry the
> whole history.
>
> Second simplest solution:
> - Add only the desired files to the new repos
> - Keep the existing repo as the only instance of the history.
>
> I don't like both.
>

What about: use --filter-branch to harvest as much history as possible, and
stop at that (keeping the existing repo as an archive of the history)?
It's not a very good solution, but i'm not sure if doing more is worth the
trouble.

I think only you can judge this, (as i've obviously had fallen behind with
the project): is the history important enough?  Were there many situations
where having current history significantly helped you?  One thing comes to
my mind: since the early history is quite tangled, it may not be very
helpful anyway in a few weeks/months from now.

best,
Janek
-------------- next part --------------
An HTML attachment was scrubbed...