On Wed, Jan 27, 2016 at 1:16 PM, Clemens Lang wrote:
> On Wed, Jan 27, 2016 at 03:00:52PM +0100, Rainer Müller wrote:
>> > I think the system bsdtar doesn't support this on all OS X versions
>> > that do support hfs compression.
>>
>> Right, on my OS X 10.10.5 Yosemite it does
On Friday January 29 2016 09:23:15 Eric A. Borisch wrote:
>Perhaps an opportunistic execution of afsctool on just-extracted (not
>yet moved into place) files in portimage.tcl (similar to the
>opportunistic use of lbzip2 or pbzip2 during extraction) could be
>done?
Sure, that's a possibility.
On Friday January 29 2016 09:23:15 Eric A. Borisch wrote:
>Perhaps an opportunistic execution of afsctool on just-extracted (not
>yet moved into place) files in portimage.tcl (similar to the
>opportunistic use of lbzip2 or pbzip2 during extraction) could be
>done?
Sure, that's a possibility.
On Fri, Jan 29, 2016 at 9:45 AM, René J.V. wrote:
> On Friday January 29 2016 09:23:15 Eric A. Borisch wrote:
>
>>Perhaps an opportunistic execution of afsctool on just-extracted (not
>>yet moved into place) files in portimage.tcl (similar to the
>>opportunistic use of lbzip2
On Friday January 29 2016 11:14:23 Eric A. Borisch wrote:
>> I'm not sure why you'd want that? Even the "stock" afsctool can take a
>> directory.
>
>Haven't played with it; that's even easier. Does it parallelize, too?
Not the stock version, but the version I've continued developing does. About
On Wed, Jan 27, 2016 at 03:00:52PM +0100, Rainer Müller wrote:
> > I think the system bsdtar doesn't support this on all OS X versions
> > that do support hfs compression.
>
> Right, on my OS X 10.10.5 Yosemite it does not seem to be supported. In
> the ticket you said it was not supported on OS
On Wednesday January 27 2016 15:00:52 Rainer Müller wrote:
> Yes, it is a test, but I would not call that simple. Also, we would only
> need to test this once and it could even be done during configure.
Configure when MacPorts itself is being built?
> afsctool is GPL-3 software, so we should
On 2016-01-26 18:31, René J.V. Bertin wrote:
> On Tuesday January 26 2016 08:55:20 Ryan Schmidt wrote:
>
>> https://trac.macports.org/ticket/36560
> On 2016-01-26 18:12, Joshua Root wrote:
>> Not really thrilled by the inline hex file and shelling out to run
>> a
>
> Isn't that simply a test to
>> I was under the impression that Apple already compressed the files and
>> programs installed with the operating system, using HFS compression, ever
>> since taking up less disk space was listed as a feature of Snow Leopard.
> Yeah, I thought so too, but I also have the impression that may not
Hi,
On 26/01/16 09:47, Vincent Habchi wrote:
I was under the impression that Apple already compressed the files and programs
installed with the operating system, using HFS compression, ever since taking
up less disk space was listed as a feature of Snow Leopard.
Yeah, I thought so too, but
> On Jan 26, 2016, at 1:47 AM, Vincent Habchi wrote:
>
>>> I was under the impression that Apple already compressed the files and
>>> programs installed with the operating system, using HFS compression, ever
>>> since taking up less disk space was listed as a feature of
> On Jan 26, 2016, at 2:26 AM, René J.V. Bertin wrote:
>
> Given the disk savings it can give I really don't understand why the patch
> that adds HFS compression to port activation was never accepted.
For reference, that was this ticket:
On Jan 26, 2016, at 11:55 AM, Ryan Schmidt wrote:
> There were performance concerns earlier in the discussion but I'm not sure if
> the latest version of the patch attached there resolves them.
the latest comment that mentions it says it's a 2x slowdown (better than the
On 2016-1-27 04:04 , Daniel J. Luke wrote:
> On Jan 26, 2016, at 11:55 AM, Ryan Schmidt wrote:
>> There were performance concerns earlier in the discussion but I'm not sure
>> if the latest version of the patch attached there resolves them.
>
> the latest comment that
On Jan 26, 2016, at 12:12 PM, Joshua Root wrote:
> Not really thrilled by the inline hex file and shelling out to run a
> command pipeline before every extract either. Seems like this could be a
> configure check for the system bsdtar supporting the feature instead.
+1
I
On Tuesday January 26 2016 08:55:20 Ryan Schmidt wrote:
>https://trac.macports.org/ticket/36560
Yeah, that was the one.
>There were performance concerns earlier in the discussion but I'm not sure if
>the latest version of the patch attached there resolves them.
Activating hfsCompression is
On Tuesday January 26 2016 10:47:10 Vincent Habchi wrote:
>I’ve applied René method, disabling SIP while compressing /Applications. It
>gave me some significant savings, thus I surmise all the applications are not
>compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.
> On Jan 24, 2016, at 1:42 AM, Vincent Habchi wrote:
>
>> Sure. And it is probably also very easy to introduce regressions that way if
>> the #ifdefs aren't already in place.
>
> Yeah, that’s right. Every cloud has its silver lining. Or the contrary for
> that matter.
>
On Monday January 25 2016 19:39:26 Ryan Schmidt wrote:
>I was under the impression that Apple already compressed the files and
>programs installed with the operating system, using HFS compression, ever
>since taking up less disk space was listed as a feature of Snow Leopard.
Yeah, I thought so
> This typically doesn't take a lot of space, and no compiler option will
> remove the unused code in software that was meant to support different CPUs
> at runtime…
Except that you can use configure to detect what model of processor you’re
running on, and then with a -D flag eliminate all the
> Sure. And it is probably also very easy to introduce regressions that way if
> the #ifdefs aren't already in place.
Yeah, that’s right. Every cloud has its silver lining. Or the contrary for that
matter.
> It'll do the same with your /Applications directory or the entire /opt/local
> tree.
On Sunday January 24 2016 09:46:03 Vincent Habchi wrote:
>Except that you can use configure to detect what model of processor you’re
>running on, and then with a -D flag eliminate all the code that is not
>targeted for your CPU (via #ifdef/#ifndef).
Sure. And it is probably also very easy to
On Sunday January 24 2016 10:42:56 Vincent Habchi wrote:
> Except that it’s no longer possible to compress the build-in Applications
> with OS X 10.11 since Apple introduced SIP
> (http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/8/#h1).
> Even root cannot
On Sun, Jan 24, 2016 at 6:20 AM, René J.V. wrote:
> A trip to single-user mode or into recovery mode to toggle an EFI setting,
> right?
csrutil {enable|disable} and reboot.
--
brandon s allbery kf8nh sine nomine associates
On Saturday January 23 2016 14:19:26 Vincent Habchi wrote:
> Latest one:
>
> port installed | grep VLC
> VLC @2.1.5_7+mod+mpc+osd+qtkit+quartz (active)
That's indeed that latest one provided through MacPorts, but not the latest VLC
version. I've submitted a port for 2.2.1 on Trac months ago,
Hi René,
> Any MKV file? What VLC version?
Latest one:
port installed | grep VLC
VLC @2.1.5_7+mod+mpc+osd+qtkit+quartz (active)
> What does the VLC log tell you (either in-app or by launching the app bundle
> executable directly from a terminal, with the -vvv argument)?
You will find the
Hi there,
I’ve a strange problem with VLC. Clicking on a MKV file will not crash the app,
but it will go into a sort of infinite loop, as if it was not finding anything
to play inside the file and kept on trying again.
ffplay with the same file works fine, though, so this is not a library
> On Jan 23, 2016, at 8:48 AM, Vincent Habchi wrote:
>> Might I suggest that you download the latest VLC player from videolan.org
>> directly, and see if that one gives the same error? If it doesn't, you can
>> then probably simply uninstall the one from MacPorts.
>
> Yep,
On Saturday January 23 2016 12:10:54 Vincent Habchi wrote:
Hi,
>I’ve a strange problem with VLC. Clicking on a MKV file will not crash the
>app, but it will go into a sort of infinite loop, as if it was not finding
>anything to play inside the file and kept on trying again.
>
>ffplay with the
>
> That's indeed that latest one provided through MacPorts, but not the latest
> VLC version. I've submitted a port for 2.2.1 on Trac months ago, but it has
> never been committed.
There’s a “beta” 2.2.2-20150427_3 available on MacPorts, I’ll try it and let
you know.
> Might I suggest that
> On Jan 23, 2016, at 9:36 AM, Vincent Habchi wrote:
> I compiled VLC 2.2.1 using Macports and still have the same error :(
> Seems something is wrong in the MacPorts librairies, but where? ...
>
> VLC media player 2.2.2 Weatherwax (revision 2.2.1-21-g2502874)
> …
>
> On Jan 23, 2016, at 12:33 PM, Vincent Habchi wrote:
>
>> … If you only installed those libraries for VLC then you shouldn't lose
>> much. You would however have more definite proof whether your issue is due
>> to something with the MacPorts build or in VLC itself. If the
On Saturday January 23 2016 14:48:56 Vincent Habchi wrote:
>There’s a “beta” 2.2.2-20150427_3 available on MacPorts, I’ll try it and let
>you know.
Ah, not mine AFAIK. The portfile I submitted on Trac *probably* contains a
VLC-devel port for 3.0.0-150503-g7385062d (my local copy does), but I
> Ah, not mine AFAIK. The portfile I submitted on Trac *probably* contains a
> VLC-devel port for 3.0.0-150503-g7385062d (my local copy does), but I don't
> think I tried building or using that one since May last year (1505).
I could have a stab at compiling it, if you want.
> If you only
On Saturday January 23 2016 18:33:07 Vincent Habchi wrote:
>> Ah, not mine AFAIK. The portfile I submitted on Trac *probably* contains a
>> VLC-devel port for 3.0.0-150503-g7385062d (my local copy does), but I don't
>> think I tried building or using that one since May last year (1505).
>
>I
René,
I compiled VLC 2.2.1 using Macports and still have the same error :(
Seems something is wrong in the MacPorts librairies, but where?
Cheers!
—
VLC media player 2.2.2 Weatherwax (revision 2.2.1-21-g2502874)
[7f9f92f00378] core libvlc debug: VLC media player - 2.2.2 Weatherwax
> You might want to look at the following to clean up those libraries:
>
> $ port info port_cutleaves
[…]
Thanks Craig!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Craig:
> Do other mkv files play OK?
I haven’t many MKV files, all from the same source, and none plays correctly on
VLC.
FFPLAY has no difficulty reading them.
Strange.
Output of mediainfo:
> mediainfo /Volumes/Archives/Vidéos/Series/MLP\ FIM\ S4/YP-7Z-04x02.mkv
General
Unique ID
On Sat, 23 Jan 2016, Vincent Habchi wrote:
> I’ve a fairly new Mac (three-year old or so), so performance is no concern
> during normal operation; however, watching a flick or a show while compiling
> Qt5 can sometimes be jerky. Besides, more CPU efficiency also means less
> battery drain.
39 matches
Mail list logo