Skip Collins writes:
> On Wed, Apr 23, 2014 at 10:13 AM, Pascal Fleury wrote:
>> (have not used bash3 in quite a long time :-)
>
> Even OS X Mavericks uses bash 3. So it will be around for quite a long time.
>
I believe Bash 4 is GPLv3 and Bash 3 is GPLv2, so it is very possible
that OSX will n
On Wed, Apr 23, 2014 at 10:13 AM, Pascal Fleury wrote:
> (have not used bash3 in quite a long time :-)
Even OS X Mavericks uses bash 3. So it will be around for quite a long time.
On Tue, Apr 22, 2014 at 5:22 PM, Bastien wrote:
> Mhh... okay then, thanks for mentioning it.
The stackoverflow link contains what appears to be a good workaround
that functions in old and new versions of bash. Perhaps Pascal Fleury
could modify the org code to avoid using 'declare -A' when bash
Skip Collins writes:
> On Tue, Apr 22, 2014 at 5:04 PM, Skip Collins wrote:
>> I suspect this is a Mac-related thing.
>
> OS X 10.8.5 ships with bash version 3 which seems to have some issues
> with declaring arrays:
> http://stackoverflow.com/questions/6047648/bash-4-associative-arrays-error-de
Skip Collins writes:
> On Tue, Apr 22, 2014 at 4:59 PM, Bastien wrote:
>> You should probably check for "sh" in this local.mk line:
>
> Nope. I suspect this is a Mac-related thing.
> Here are the contents of
> my local.mk:
> ORG_ADD_CONTRIB = org-download.el*
> EMACS = /Applications/Emacs.app/C
On Tue, Apr 22, 2014 at 5:04 PM, Skip Collins wrote:
> I suspect this is a Mac-related thing.
OS X 10.8.5 ships with bash version 3 which seems to have some issues
with declaring arrays:
http://stackoverflow.com/questions/6047648/bash-4-associative-arrays-error-declare-a-invalid-option
On Tue, Apr 22, 2014 at 4:59 PM, Bastien wrote:
> You should probably check for "sh" in this local.mk line:
Nope. I suspect this is a Mac-related thing. Here are the contents of
my local.mk:
ORG_ADD_CONTRIB = org-download.el*
EMACS = /Applications/Emacs.app/Contents/MacOS/Emacs
prefix = /usr/loca
Skip Collins writes:
> As I wrote at the top of the report, the test fails when running make
> up2. I am using the unmodified master branch.
You should probably check for "sh" in this local.mk line:
BTEST_OB_LANGUAGES: ...
and replace is by "shell".
--
Bastien
As I wrote at the top of the report, the test fails when running make
up2. I am using the unmodified master branch.
--
skip collins
240 687 7802
On Tue, Apr 22, 2014 at 11:37 AM, Bastien wrote:
> Skip Collins writes:
>
>> Test 80/480 fails when I use make up2 with Mac OS X GNU Emacs 24.3.1
>>
Skip Collins writes:
> Test 80/480 fails when I use make up2 with Mac OS X GNU Emacs 24.3.1
> (x86_64-apple-darwin12.5.0, Carbon Version 1.6.0 AppKit 1187.4) of
> 2014-03-05:
> executing Bash code block...
> Wrote
> /var/folders/dt/9hkw2mj50dd566y5qs2s4b8sq962bh/T/tmp-orgtest/ob-input-32986Ogm
>
Test 80/480 fails when I use make up2 with Mac OS X GNU Emacs 24.3.1
(x86_64-apple-darwin12.5.0, Carbon Version 1.6.0 AppKit 1187.4) of
2014-03-05:
executing Bash code block...
Wrote
/var/folders/dt/9hkw2mj50dd566y5qs2s4b8sq962bh/T/tmp-orgtest/ob-input-32986Ogm
Code block evaluation complete.
Test
Hi Eric,
Eric Schulte writes:
>> Also, if you can sign your patches (git format-patch -s) that'd
>> be even better, but not mandatory.
>
> Should I start signing my patches as well?
Up to you, I don't want to enforce a policy here, I just think it's
good to have signed patch for people who don'
Eric Schulte writes:
>>
>> Also, if you can sign your patches (git format-patch -s) that'd
>> be even better, but not mandatory.
>>
>
> Should I start signing my patches as well?
>
> I'm very happy to, I've just never thought about it. If so is there an
> easy way to make -s a default option for
Pascal Fleury writes:
> Hello,
>
> Great, thanks for the guidance. I hope I managed it all correctly.
>
I've applied this patch.
I made a couple of minor changes in a subsequent commit (a7189aa).
These were indentation and whitespace changes to enforce two coding
conventions,
1. limit line len
>
> Also, if you can sign your patches (git format-patch -s) that'd
> be even better, but not mandatory.
>
Should I start signing my patches as well?
I'm very happy to, I've just never thought about it. If so is there an
easy way to make -s a default option for the Org-mode repo?
Thanks,
--
E
Hi Eric and Pascal,
Eric Schulte writes:
> Also, I think the google-wide copyright stuff is sorted out.
Yes it is: we can accept patch from employees of Google, Inc.
Pascal, I guess it's safe to assume anyone with a @google.com
email address is a Google employee -- let me know if it's not
the
Hi Pascal,
This patch looks great, thanks for making the additions. Once last
request, would you mind formatting it with "git format-patch"? With
that done I'll be happy to apply this to the repo.
Also, I think the google-wide copyright stuff is sorted out.
Best,
Pascal Fleury writes:
> Hi
Hi Eric,
Please find attached a new patch that contains the same changes of the
ob-shell.el exporter as before, but also contains unit tests for checking
that it works.
Let me know if you need some changes in there, and how the google-wide
copyright issues comes along. My information came from Ch
Thanks for making these changes. Once they're in and Bastien figures
out how the google-wide copyright attribution works we should be good to
go.
Thanks!
Pascal Fleury writes:
> Hi Eric, see comments inline.
>
>
> On Thu, Mar 27, 2014 at 6:43 PM, Eric Schulte wrote:
>
>> Hi Pascal,
>>
>> This
Hi Pascal,
This looks like a good patch. If I could make three changes/requests.
1. This patch should also work for "begin_src bash" code blocks. After
a very quick glance it doesn't appear to.
2. Could you include one or two tests ensuring that this patch does what
it intends with bash
20 matches
Mail list logo
