proposal: move Kawa from Subversion to git on gitlab.com

proposal: move Kawa from Subversion to git on gitlab.com

[Per Bothner]

Now that Kawa 2.2 has been released, the focus of development will be in
the "invoke" branch.  That can't be merged into the trunk yet because it requires
MethodHandles, so it does not work on Java 5, Java 6, or (more importantly) Android.
(I'm considering how best to handle platforms without MethodHandles, but nothing
has been decided or coded yet.)

So it will be easier if we're using something that handles branches better than Subversion.

We talked about moving to Git, and I think that makes sense.  The idea would be to
switch to Git, and then immediately make a quick Kawa 2.3 release.

There are multiple host options, though:

* GitHub - not as Free Software-friendly; FSF disapproved.
* Savannah - not a lot of functionality; run by (too few) volunteers.
* Pagure (from RedHat) - too new, too small.
* Self-host (either GitLab CE or Gogs) - better branding using own
   domain name (maybe git.kawa-lang.org), but not worth the extra work.

That leaves GitLab as the most plausible candidate.  What do people
think about that?

This would only affect version control and (presumably the issue tracker.
The website, the ftp site, and the mailing list are separate issues.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: proposal: move Kawa from Subversion to git on gitlab.com

[Jamison Hope]

I know people at work who have used GitLab, both hosted at gitlab.com
and also CE on a private server, and they had no complaints.  So, it's
fine with me.

Re MethodHandles, I use Kawa on some computers at work that are stuck
with RHEL 6 + Java 6, so please don't break it!

On Nov 12, 2016, at 7:58 PM, Per Bothner <per@bothner.com> wrote:

> Now that Kawa 2.2 has been released, the focus of development will be in
> the "invoke" branch.  That can't be merged into the trunk yet because it requires
> MethodHandles, so it does not work on Java 5, Java 6, or (more importantly) Android.
> (I'm considering how best to handle platforms without MethodHandles, but nothing
> has been decided or coded yet.)
> 
> So it will be easier if we're using something that handles branches better than Subversion.
> 
> We talked about moving to Git, and I think that makes sense.  The idea would be to
> switch to Git, and then immediately make a quick Kawa 2.3 release.
> 
> There are multiple host options, though:
> 
> * GitHub - not as Free Software-friendly; FSF disapproved.
> * Savannah - not a lot of functionality; run by (too few) volunteers.
> * Pagure (from RedHat) - too new, too small.
> * Self-host (either GitLab CE or Gogs) - better branding using own
>  domain name (maybe git.kawa-lang.org), but not worth the extra work.
> 
> That leaves GitLab as the most plausible candidate.  What do people
> think about that?
> 
> This would only affect version control and (presumably the issue tracker.
> The website, the ftp site, and the mailing list are separate issues.
> -- 
> 	--Per Bothner
> per@bothner.com   http://per.bothner.com/

--
Jamison Hope
The PTR Group
www.theptrgroup.com

Re: proposal: move Kawa from Subversion to git on gitlab.com

[Per Bothner]

On 11/12/2016 08:41 PM, Jamison Hope wrote:

> Re MethodHandles, I use Kawa on some computers at work that are stuck
> with RHEL 6 + Java 6, so please don't break it!

Noted!

One idea I had is to define a fake MethodHandle class:

public class CallContext {
    ....
    /* #ifndef use:java.lang.invoke */
    // public static abstract class MethodHandle {
    //     public abstract Object invokeExact(Procedure proc, CallContext ctx);
    // };
    /* #endif */
}

And in code that uses it:

/* #ifdef use:java.lang.invoke */
import java.lang.invoke.Methodhandle;
/* #else */
// import gnu.mapping.CallContext.MethodHandle;
/* #endif */

It's rather gross but it reduces the places where PreProcessing
conditionals would be needed to clutter up the code.
(Actual typedefs would be cleaner.)

A concrete class that extends CallContext.MethodHandle might
use reflection, but it could also be compiler-generated.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

invoke branch (was: proposal: move Kawa from Subversion to git on gitlab.com)

[Per Bothner]

I checked into the invoke branch a change that does this.
It builds and passes the tests using Java 6 (except some Unicode tests).
I assume Android will also work.

We use reflection rather than MethodHandles, which I assume will be slower.

It would be useful to have some sample programs we can benchmark.
We need some numbers of the performance of the invoke branch
compared to the old way (in the trunk) - both Java 6 and Java 8,
both --full-tailcalls and not.


On 11/12/2016 09:06 PM, Per Bothner wrote:
> On 11/12/2016 08:41 PM, Jamison Hope wrote:
>
>> Re MethodHandles, I use Kawa on some computers at work that are stuck
>> with RHEL 6 + Java 6, so please don't break it!
>
> Noted!
>
> One idea I had is to define a fake MethodHandle class:
>
> public class CallContext {
>    ....
>    /* #ifndef use:java.lang.invoke */
>    // public static abstract class MethodHandle {
>    //     public abstract Object invokeExact(Procedure proc, CallContext ctx);
>    // };
>    /* #endif */
> }
>
> And in code that uses it:
>
> /* #ifdef use:java.lang.invoke */
> import java.lang.invoke.Methodhandle;
> /* #else */
> // import gnu.mapping.CallContext.MethodHandle;
> /* #endif */
>
> It's rather gross but it reduces the places where PreProcessing
> conditionals would be needed to clutter up the code.
> (Actual typedefs would be cleaner.)
>
> A concrete class that extends CallContext.MethodHandle might
> use reflection, but it could also be compiler-generated.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: proposal: move Kawa from Subversion to git on gitlab.com

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

Hello,

> There are multiple host options, though:
> 
> * GitHub - not as Free Software-friendly; FSF disapproved.
> * Savannah - not a lot of functionality; run by (too few) volunteers.
> * Pagure (from RedHat) - too new, too small.
> * Self-host (either GitLab CE or Gogs) - better branding using own
>    domain name (maybe git.kawa-lang.org), but not worth the extra work.

FWIW, I much when s/w part of gnu (and non gnu free s/w) be on savannah

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: proposal: move Kawa from Subversion to git on gitlab.com

[Charlie Turner]

On 13 November 2016 at 00:58, Per Bothner <per@bothner.com> wrote:
> * GitHub - not as Free Software-friendly; FSF disapproved.

Out of interest, what happens to Kawa's relationship with the FSF if
it were to pick GitHub, would you have to stop calling it free
software?

The reasons given for why it's disapproved appear to be,

1) The GitHub website uses JavaScript that doesn't work in LibreJS, or
that's it minified in some way to be considered "object code" by the
FSF.

2) GitHub "might use some export control law" to block your repo.

Regarding point 1), you don't need to use the GitHub website to
contribute code, so that avoids you being subject to javascript you
don't trust. You don't need to use the GitHub website to read code, or
modify code.

Regarding point 2), the github docs say "...[github.com] does not
currently offer the ability to restrict repository access by country."
you need to go "enterprise" for that ability, so that doesn't seem
applicable to Kawa's situation either.

TL;DR, I think GitHub is great, and it would be shame if we couldn't
use it for the reasons above, or if I'm missing something. I'm not a
lawyer :)

Re: proposal: move Kawa from Subversion to git on gitlab.com

[Per Bothner]

On 11/13/2016 02:55 PM, Charlie Turner wrote:
> On 13 November 2016 at 00:58, Per Bothner <per@bothner.com> wrote:
>> * GitHub - not as Free Software-friendly; FSF disapproved.
>
> Out of interest, what happens to Kawa's relationship with the FSF if
> it were to pick GitHub, would you have to stop calling it free
> software?

No, definitely not.  The most they could say it we could no longer call
it *GNU* software. However, I don't think that much on an issue.  I view their
"report card" as more of recommendation, and a spur to providers to improve.

> The reasons given for why it's disapproved appear to be,
>
> 1) The GitHub website uses JavaScript that doesn't work in LibreJS, or
> that's it minified in some way to be considered "object code" by the
> FSF.
>
> 2) GitHub "might use some export control law" to block your repo.
>
> Regarding point 1), you don't need to use the GitHub website to
> contribute code, so that avoids you being subject to javascript you
> don't trust. You don't need to use the GitHub website to read code, or
> modify code.

Well, we don't want to pick a site that we recommend people not use ...
(Not that I'd go as far.)

> Regarding point 2), the github docs say "...[github.com] does not
> currently offer the ability to restrict repository access by country."
> you need to go "enterprise" for that ability, so that doesn't seem
> applicable to Kawa's situation either.

I'm confused about the FSF's complaint here. The summary links to a
page that states that export controls exists and that GitHub does
not see it as their job to enforce them.  I don't see anything wrong about that.

> TL;DR, I think GitHub is great, and it would be shame if we couldn't
> use it for the reasons above, or if I'm missing something. I'm not a
> lawyer :)

I agree FSF's points are weak, and if there were a strong reason to
prefer GitHub I wouldn't worry too much.  But there is something to
be said for picking the number 2 "we try harder" choice, if nothing
else than to encourage competition.  GitLab does seem to be a bit
more responsive in general, and to the FSF's concern in particular.
Plus it appears their continuous integration story is better.
Of the various GitHub vs GitLab comparisons I've seen, they both
have weak and strong points, but both are very similar featurewise.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

please checkout Kawa from gitlab.com

[Per Bothner]

https://gitlab.com/kashell/Kawa

To check it out do:
git clone https://gitlab.com/kashell/Kawa.git

To checkout the 'invoke' branch, do:

git checkout invoke

(The invoke branch is where the big changes are happening ...
Performance testing is especially needed.)

So far there is no difference from the Subversion repository;
I haven't even updated the documentation to refer to git.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: please checkout Kawa from gitlab.com

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

Hello Per,

> To check it out do:
> git clone https://gitlab.com/kashell/Kawa.git

For info:

	if I make install twice (I did it by mistake), it fails the second time
	with this message

		cd /opt/bin && \
		  ln -s /opt/share/kawa/bin/kawa kawa
		ln: failed to create symbolic link 'kawa': File exists

	I like to install html doc locally, it fails

		./configure --prefix=/opt
		make. make install, make install-html

	-> it installs kawa doc in my home drectory instead of /opt/share/doc/kawa
	as expected

	it fails see below

Cheers,
David
	
...	
Generating /home/david/Kawa/api/overview-summary.html...
Generating /home/david/Kawa/api/help-doc.html...
102 warnings
cp ./COPYING  $HOME/Kawa/api/COPYING
cd doc;  make install-html HTML_HOME="$HOME/public_html"
make[1]: Entering directory '/mnt/galia/linux/64/local/src/kawa/git/doc'
mkdir /home/david/public_html/kawa
mkdir: cannot create directory ‘/home/david/public_html/kawa’: No such file or
directory Makefile:863: recipe for target 'install-html' failed
make[1]: [install-html] Error 1 (ignored)
cp  /home/david/public_html/kawa/
cp: missing destination file operand after '/home/david/public_html/kawa/'
Try 'cp --help' for more information.
Makefile:863: recipe for target 'install-html' failed
make[1]: *** [install-html] Error 1
make[1]: Leaving directory '/mnt/galia/linux/64/local/src/kawa/git/doc'
Makefile:1971: recipe for target 'install-html' failed
make: *** [install-html] Error 2

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: please checkout Kawa from gitlab.com

[Per Bothner]

On 11/22/2016 02:12 PM, David Pirotte wrote:
>
> 	if I make install twice (I did it by mistake), it fails the second time
> 	with this message
>
> 		cd /opt/bin && \
> 		  ln -s /opt/share/kawa/bin/kawa kawa
> 		ln: failed to create symbolic link 'kawa': File exists

Thanks - I checked in a fix for this.


> 	I like to install html doc locally, it fails
>
> 		./configure --prefix=/opt
> 		make. make install, make install-html
>
> 	-> it installs kawa doc in my home drectory instead of /opt/share/doc/kawa
> 	as expected
>
> 	it fails see below

This one is harder.  The 'install-html' rule is rather bit-rotted; it should
probably be removed.  Not sure what to replace it with, if anything.

As far as I know, there is no GNU standard for installing html files.
I would like change this; see http://per.bothner.com/blog/2016/texinfo-roadmap/
(which is still a rough draft).

There are two (or three) mechanisms for making html documentation
(all these assuming you're in the doc directory):
(1) 'make kawa-html', which uses 'makeinfo --html'.
(2) A more convoluted path, which uses 'makeinfo --docbook', and then
uses the DocBook style sheets to create html or epub.
The are two sub-variants:
(2a) 'make web/index.html' creates a web-site with a navigation bar and
my own styling.  This is the source of the Kawa website.
(2b) 'make kawa-manual.epub' makes a EPUB electronic book.
The file kawa-manual.epub is included with the Kawa binary distribution, and
it is used by the kawa --browse-manual command.  See:

https://www.gnu.org/software/kawa/Binary-distribution.html (final subsection)
https://www.gnu.org/software/kawa/Options.html#browse-manual-option

I have mostly been focusing on (2a) and (2b), rather than (1).
The preferred way to "install the documentation" is (2b).
I'd be curious to hear if others can manage to build kawa-manual.epub.
If you want to try, you meed the DocBook XSL stylesheets, and to
override the DOCBOOK_XSL_DIR variable in doc/Makefile (or create
the symlink as described in the Makefile).
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

make kawa-manual.epub (Re: please checkout Kawa from gitlab.com)

[Sudarshan S Chawathe]

A quick report: I was able to build kawa-manual.epub as suggested below
after creating a symlink to the system docbook-xsl directory as
suggested in the Makefile.  (The main Kawa build was fine too.)

The above was using the gitlab version of Kawa (on the invoke branch) on
Debian Jessie x86 32-bit with OpenJDK 1.8.0_111.

Regards,

-chaw

> Subject: Re: please checkout Kawa from gitlab.com
> From: Per Bothner <per@bothner.com>
> Date: Tue, 22 Nov 2016 23:42:20 -0800

> I have mostly been focusing on (2a) and (2b), rather than (1).
> The preferred way to "install the documentation" is (2b).
> I'd be curious to hear if others can manage to build kawa-manual.epub.
> If you want to try, you meed the DocBook XSL stylesheets, and to
> override the DOCBOOK_XSL_DIR variable in doc/Makefile (or create
> the symlink as described in the Makefile).

Re: make kawa-manual.epub (Re: please checkout Kawa from gitlab.com)

[Per Bothner]

On 11/23/2016 05:17 AM, Sudarshan S Chawathe wrote:
> A quick report: I was able to build kawa-manual.epub as suggested below
> after creating a symlink to the system docbook-xsl directory as
> suggested in the Makefile.  (The main Kawa build was fine too.)

Good - I was afraid there might be too many dependencies on my
personal setup.

I should add a --with-docbook-stylesheets=PATH configure
option, and have 'make all' default to building kawa-manual.epub
when this configure option is specified.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: make kawa-manual.epub (Re: please checkout Kawa from gitlab.com)

[Per Bothner]

On 11/23/2016 10:04 AM, Per Bothner wrote:
>
>
> On 11/23/2016 05:17 AM, Sudarshan S Chawathe wrote:
>> A quick report: I was able to build kawa-manual.epub as suggested below
>> after creating a symlink to the system docbook-xsl directory as
>> suggested in the Makefile.  (The main Kawa build was fine too.)
>
> Good - I was afraid there might be too many dependencies on my
> personal setup.
>
> I should add a --with-docbook-stylesheets=PATH configure
> option, and have 'make all' default to building kawa-manual.epub
> when this configure option is specified.

Did that - it's in git now.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: please checkout Kawa from gitlab.com

[Kumar Appaiah]

On Tue, Nov 22, 2016 at 08:56:35AM -0800, Per Bothner wrote:
> https://gitlab.com/kashell/Kawa
> 
> To check it out do:
> git clone https://gitlab.com/kashell/Kawa.git

Hi.

I've verified that the following allows you to automagically build and
run tests on the Gitlab CI:

https://gitlab.com/kumanna/Kawa/raw/c066d65d5fc36ae09f2af8491dafb253dea658e1/.gitlab-ci.yml

You can see a sample build and test here:

https://gitlab.com/kumanna/Kawa/builds/6617815
https://gitlab.com/kumanna/Kawa/builds/6617816

You might want to consider checking it in. I'l also see if I can hack
a gitignore over the weekend, if you haven't done so already.

Thanks.

Kumar
-- 
Kumar Appaiah

Re: please checkout Kawa from gitlab.com

[Per Bothner]

On 11/24/2016 05:33 PM, Kumar Appaiah wrote:
> I've verified that the following allows you to automagically build and
> run tests on the Gitlab CI:
> ....
> You might want to consider checking it in.

Cool!  I'll take a closer look.

>I'l also see if I can hack
> a gitignore over the weekend, if you haven't done so already.

I had started on this, and I just checked in an initial .gitignore.

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/