Perl 6

[Mojca Miklavec]

This is just to let you know that we now have Perl 6 in MacPorts.

We don't ship any modules (modules are installed to ~/.perl6 with
'panda' – the equivalent of cpan).

You can install it with
sudo port install rakudo panda

and install modules with
panda install Task::Star

Feedback and (upstream) bug reports welcome. This is the initial
packaging and a relatively fresh public release of rakudo perl, so
problems are not unexpected.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: registry lock

[René J . V . Bertin]

On Wednesday November 18 2015 13:01:22 Rainer Müller wrote:

>As I said, there is potential to allow certain operations with
>fine-grained locking, but it requires more planning to get this right.
>Just enforcing serialization of all actions that modify the registry is
>the easy solution that works in most cases.

Just remembered this thread looking at a case where I actually made use of the 
locking mechanism.

I can understand it is not trivial to get more fine-grained locking right, but 
it's also a feature that mostly gets in my way, however important it is in 
certain circumstances.
Maybe the "simplest" solution would be to provide an option to ignore the lock 
if it's present, and leave it to the user to know what s/he is doing (and 
assume the consequences, like with -n, -p or -o)?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: registry lock

[René J . V . Bertin]

On Monday January 04 2016 16:18:54 Daniel J. Luke wrote:

> The consequences of ignoring the lock (in the worst case) are worse than -n 
> -p or -o

You're aware that the full path to the lockfile is already printed, almost as 
if to allow people who know what they're doing to copy/paste it into a 
different terminal window and remove it.

An option to ignore the lock has the benefit of documentation, and can be 
coupled to a confirmation request.
I suppose it would also be possible to add additional locking code to protect 
certain operation that should always be exclusive (like install, de/activate).

Anyway, it was just a thought. 

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: registry lock

[Jeremy Lavergne]

When using trace mode and armed with the dependency tree, I know that my
concurrent installs will not be impacting each other. The lock should be
intelligent enough to use the dependency tree�after all, MacPorts is the
one computing it.

I agree with Rene here: the lock should be smart enough to use the
dependency tree.


On 01/04/2016 04:18 PM, Daniel J. Luke wrote:
> On Jan 4, 2016, at 4:13 PM, Ren� J.V. Bertin  wrote:
>> Maybe the "simplest" solution would be to provide an option to ignore the 
>> lock if it's present, and leave it to the user to know what s/he is doing 
>> (and assume the consequences, like with -n, -p or -o)?
> 
> that's a pretty horrible idea.
> 
> The consequences of ignoring the lock (in the worst case) are worse than -n 
> -p or -o
> 
> if you want to improve the locking, I'm sure everyone will be happy about 
> that. If you want to hack your system to not use the lock, you can live with 
> the consequences - but it's not something we should ship.
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: registry lock

[Daniel J. Luke]

On Jan 4, 2016, at 5:13 PM, René J.V. Bertin  wrote:
> You're aware that the full path to the lockfile is already printed, almost as 
> if to allow people who know what they're doing to copy/paste it into a 
> different terminal window and remove it.

you're assuming a lot there.

> An option to ignore the lock has the benefit of documentation, and can be 
> coupled to a confirmation request.

we don't do interactive interrogation generally for port actions (I don't think 
the GSOC that added it for interactive sessions landed in a release, but I 
could be wrong).

Usability research says that that sort of thing ("You're about to shoot 
yourself in the foot, do you wish to continue? Yes/No") doesn't actually work 
to protect users. 

> I suppose it would also be possible to add additional locking code to protect 
> certain operation that should always be exclusive (like install, de/activate).

please do.

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Survey: How do you commit?

[Michael Dickens]

Ditto Ryan's reply. That said, I think SVN is actually OK for what
MacPorts needs. I greatly prefer GIT for actual software development,
because of the cloning, committing, branching, splitting, merging it
provides (offline or online, parts or whole, lots of usable options). I
use SVN for the MP trunk, then when working out patches I'll use GIT on
the "work" directory to keep track of my changes. I find that mixing
works quite well. All of that said, I would not complain if we moved to
just using GIT for everything. Having lived through CVS from 10 years
ago and prior, I think in comparison SVN is amazing and GIT is almost
magic :) - MLD

On Mon, Jan 4, 2016, at 04:10 PM, Clemens Lang wrote:
> On Fri, Jan 01, 2016 at 11:43:17PM -0600, Ryan Schmidt wrote:
> > How do you commit to the MacPorts Subversion repository?
> > 
> > Using a Subversion working copy and "svn commit"?
> 
> This.
> 
> > Using a Git clone and git-svn?
> > Some other method?
> > 
> > Do you have any complaints about that method or are you happy with it?
> 
> It is slow, and it's hard to split changes or do partial commits.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Survey: How do you commit?

[Sterling Smith]

I would be more likely to request commit privileges if there were a git option. 
 Maybe I need to look into the git clone with git-svn method.

-Sterling

On Jan 1, 2016, at 9:43PM, Ryan Schmidt  wrote:

> Quick survey for committers:
> 
> How do you commit to the MacPorts Subversion repository?
> 
> Using a Subversion working copy and "svn commit"?
> Using a Git clone and git-svn?
> Some other method?
> 
> Do you have any complaints about that method or are you happy with it?
> 
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: registry lock

[Daniel J. Luke]

+1 to making the locking work better

-1 to René's idea of adding a 'maybe destroy your macports install' option.

> On Jan 4, 2016, at 5:01 PM, Jeremy Lavergne  
> wrote:
> When using trace mode and armed with the dependency tree, I know that my
> concurrent installs will not be impacting each other. The lock should be
> intelligent enough to use the dependency tree�after all, MacPorts is the
> one computing it.
> 
> I agree with Rene here: the lock should be smart enough to use the
> dependency tree.
> 
> On 01/04/2016 04:18 PM, Daniel J. Luke wrote:
>> On Jan 4, 2016, at 4:13 PM, Ren� J.V. Bertin  wrote:
>>> Maybe the "simplest" solution would be to provide an option to ignore the 
>>> lock if it's present, and leave it to the user to know what s/he is doing 
>>> (and assume the consequences, like with -n, -p or -o)?
>> 
>> that's a pretty horrible idea.
>> 
>> The consequences of ignoring the lock (in the worst case) are worse than -n 
>> -p or -o
>> 
>> if you want to improve the locking, I'm sure everyone will be happy about 
>> that. If you want to hack your system to not use the lock, you can live with 
>> the consequences - but it's not something we should ship.

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144182] trunk/dports/java/gant/Portfile

[Ryan Schmidt]

On Jan 3, 2016, at 8:22 PM, khindenb...@macports.org wrote:
> 
> Revision
> 144182
> Author
> khindenb...@macports.org
> Date
> 2016-01-03 18:22:43 -0800 (Sun, 03 Jan 2016)
> Log Message
> 
> gant: port fixes from #29303; change to github
> Modified Paths
> 
>   • trunk/dports/java/gant/Portfile
> Diff
> 
> Modified: trunk/dports/java/gant/Portfile (144181 => 144182)
> 
> --- trunk/dports/java/gant/Portfile   2016-01-04 01:56:12 UTC (rev 144181)
> +++ trunk/dports/java/gant/Portfile   2016-01-04 02:22:43 UTC (rev 144182)
> @@ -1,9 +1,10 @@
>  # $Id$
>  
>  PortSystem 1.0
> +PortGroup   github 1.0
>  
> +github.setupGant Gant 1.9.5
>  name gant
> -version  1.9.5
>  categories   java devel groovy
>  maintainers  nomaintainer
>  description  A groovy based tool for scripting ant
> @@ -15,19 +16,12 @@
>   an alternative way of doing things 
> using Ant, but using a \
>   programming language rather than XML to 
> specify the rules.
>   
> -homepage http://gant.codehaus.org/
>  platformsdarwin
> -distname ${name}-${version}
> -master_sites http://dist.codehaus.org/gant/distributions
>  checksumsmd5 6930a7bd5209fb6d1e9e8186fd4b18fb \
>   sha1 
> 919c750128af22797b1d53de37c70deda5676ea7 \
>   rmd160 
> 2b23c6e2696629d9fb8878568955e459d51ebcc3

This causes a checksum mismatch because the autogenerated github zipball is not 
the same as the one that was previously hosted on codehaus. Fixed in r144195. 
I'll also look into updating gant to a newer version from github.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144186] trunk/dports

[Ryan Schmidt]

> On Jan 4, 2016, at 12:56 AM, dev...@macports.org wrote:
> 
> Revision
> 144186
> Author
> dev...@macports.org
> Date
> 2016-01-03 22:56:45 -0800 (Sun, 03 Jan 2016)
> Log Message
> 
> misc ports: increment revision to remove references to libncurses.5.

> Modified Paths
> 
>   • trunk/dports/databases/libgda4/Portfile
>   • trunk/dports/gnome/vte-2.90/Portfile
>   • trunk/dports/gnome/vte-gtk2-compat/Portfile
>   • trunk/dports/lang/guile18/Portfile

None of these ports declare a library dependency on ncurses. If they link with 
libncurses, they should have that, else this is just going to be forgotten 
again next time ncurses is updated to a new library version.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev