On Mon, Oct 22, 2012 at 7:41 PM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> But if you want to confirm that there is a problem (that you can run
>> shell commands from within a knitr/Sweave chunk), then you need to
>> have R installed. Sweave comes with R and knitr can be installed with
>> a s
Lars Gullik Bj?nnes wrote:
> | You mean using std::string everywhere? That does not sound nice.
>
> I'd say that, in practise, it really is nice. You never have to verify
It's surprising how different taste people have. I second JMarc here.
Pavel
Lars Gullik Bj?nnes wrote:
> I have a followup patch to the one above that will change to using
> std::shared_ptr (et.al) when available.
I see. Is there possibility to kill the deps on boost entirely?
Pavel
Scott Kostyshak wrote:
> But if you want to confirm that there is a problem (that you can run
> shell commands from within a knitr/Sweave chunk), then you need to
> have R installed. Sweave comes with R and knitr can be installed with
> a simple install.packages('knitr') within R. Let me know if yo
Abdelrazak Younes writes:
| On Mon, Oct 22, 2012 at 11:53 AM, Jean-Marc Lasgouttes
| wrote:
>> Le 22/10/2012 00:41, Lars Gullik Bjønnes a écrit :
>>
>>>
>>> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
>>> drags in std::tr1 stuff.
>>
>>
>>> IMHO a much better solution is
Richard Heck writes:
| On 10/21/2012 03:11 PM, Lars Gullik Bjønnes wrote:
>> Using std::make_shared (and in our case for the time being
>> boost::make_shared)
>> is the preferred way of creating a std::shared_ptr.
>>
| Can we get some kind if mini-tutorial here, then, on how to use this
| routin
Jean-Marc Lasgouttes writes:
| Le 22/10/2012 00:41, Lars Gullik Bjønnes a écrit :
>>
>> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
>> drags in std::tr1 stuff.
>
>> IMHO a much better solution is to just use "std::" prefix where
>> required.
>
| You mean using std::strin
André Pönitz writes:
| On Mon, Oct 22, 2012 at 12:41:08AM +0200, Lars Gullik Bjønnes wrote:
>>
>> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
>> drags in std::tr1 stuff.
>>
>> IMHO the soltion is not to use boost::shared_ptr etc. But to stop
>> using "using namespace s
Abdelrazak Younes writes:
| On Mon, Oct 22, 2012 at 12:41 AM, Lars Gullik Bjønnes
wrote:
>>
>> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
>> drags in std::tr1 stuff.
>>
>> IMHO the soltion is not to use boost::shared_ptr etc. But to stop
>> using "using namespace std"
Pavel Sanda writes:
| Lars Gullik Bj?nnes wrote:
>> diff --git a/src/support/shared_ptr.h b/src/support/shared_ptr.h
>> index 69e42da..792beb2 100644
>> --- a/src/support/shared_ptr.h
>> +++ b/src/support/shared_ptr.h
>> @@ -12,22 +12,6 @@
>> #ifndef LYX_SHARED_PTR_H
>> #define LYX_SHARED_PTR_H
Richard Heck writes:
| On 10/21/2012 03:11 PM, Lars Gullik Bjønnes wrote:
>> Using std::make_shared (and in our case for the time being
>> boost::make_shared)
>> is the preferred way of creating a std::shared_ptr.
>>
| Can we get some kind if mini-tutorial here, then, on how to use this
| routin
Am 22.10.2012 02:32, schrieb Lars Gullik Bjønnes:
Is that what this is?
http://aprenderlyx.com/
No, they make money with LyX without helping to improve it. But this is a company in Venezuela and
they don't care about licensing issues in general. Nevertheless this is legal according to the GP
On Mon, Oct 22, 2012 at 5:31 PM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> > Yes. And would be nice nice if we have some general solution,
>> > so its easy to re-use it in other cases.
>>
>> That would be nice. I could look into this but not for a while. I
>> don't think adding a warning to b
Scott Kostyshak wrote:
> > Yes. And would be nice nice if we have some general solution,
> > so its easy to re-use it in other cases.
>
> That would be nice. I could look into this but not for a while. I
> don't think adding a warning to branch would be possible anyway
> because of the string free
Lars Gullik Bj?nnes wrote:
> diff --git a/src/support/shared_ptr.h b/src/support/shared_ptr.h
> index 69e42da..792beb2 100644
> --- a/src/support/shared_ptr.h
> +++ b/src/support/shared_ptr.h
> @@ -12,22 +12,6 @@
> #ifndef LYX_SHARED_PTR_H
> #define LYX_SHARED_PTR_H
>
> -#ifdef LYX_USE_TR1
> -
On Mon, Oct 22, 2012 at 3:54 PM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> You are right
>> that \write18 is disabled by default.
>
> Fine, I'm happy to hear this.
>
>> I would prefer that on every
>> new document I open, if it has the Sweave/knitr module enabled, I am
>> notified (with an op
Scott Kostyshak wrote:
> On Sat, Oct 20, 2012 at 6:40 PM, Yihui Xie wrote:
> > I think that should be enough. A pointer to the knitr manual in
> > "Help-->Specific Manuals-->Knitr Manual" can be helpful too (I
> > remember Liviu mentioned this once).
>
> Sure, I can do that. Pavel, is that OK? Tr
Scott Kostyshak wrote:
> You are right
> that \write18 is disabled by default.
Fine, I'm happy to hear this.
> I would prefer that on every
> new document I open, if it has the Sweave/knitr module enabled, I am
> notified (with an option of turning such notifications off
> permanently).
Yes. And
On Mon, Oct 22, 2012 at 12:24 PM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> Any thoughts as far as improving security, warning the user, or
>> documentation?
>
> Up to this moment we were trying not to include anything which could be used
> in
> the exec("rm -rf /") way (this was the only r
On Mon, Oct 22, 2012 at 12:41:08AM +0200, Lars Gullik Bjønnes wrote:
>
> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
> drags in std::tr1 stuff.
>
> IMHO the soltion is not to use boost::shared_ptr etc. But to stop
> using "using namespace std". I look briefly as to what
Hi guys,
I'm trying to see if I can stop using literate-article and instead use the
article class (or any other layout) with the "noweb" module instead.
However, when I use the "noweb" module, the Scrap layout is not defined.
How do I fix this?
---Kayvan
Scott Kostyshak wrote:
> Any thoughts as far as improving security, warning the user, or documentation?
Up to this moment we were trying not to include anything which could be used in
the exec("rm -rf /") way (this was the only reason why gnuplot is not supported
by lyx for example, there was work
On Mon, Oct 22, 2012 at 12:41 AM, Lars Gullik Bjønnes wrote:
>
> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
> drags in std::tr1 stuff.
>
> IMHO the soltion is not to use boost::shared_ptr etc. But to stop
> using "using namespace std". I look briefly as to what was discu
On Mon, Oct 22, 2012 at 11:53 AM, Jean-Marc Lasgouttes
wrote:
> Le 22/10/2012 00:41, Lars Gullik Bjønnes a écrit :
>
>>
>> It is mentioned in c9b9748c that "using namespace std" on msvc10 also
>> drags in std::tr1 stuff.
>
>
>> IMHO a much better solution is to just use "std::" prefix where
>> req
On 10/21/2012 07:46 PM, Uwe Stöhr wrote:
The branch, master, has been updated.
- Log -
commit 133251171142bfe0a6aadf438afd2a14ae0c3446
Author: Uwe Stöhr
Date: Mon Oct 22 01:46:13 2012 +0200
uk.po: updates for trunk by Yur
On 10/22/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 22/10/2012 00:41, Lars Gullik Bjønnes a écrit :
It is mentioned in c9b9748c that "using namespace std" on msvc10 also
drags in std::tr1 stuff.
IMHO a much better solution is to just use "std::" prefix where
required.
You mean using std
On 10/21/2012 03:11 PM, Lars Gullik Bjønnes wrote:
Using std::make_shared (and in our case for the time being boost::make_shared)
is the preferred way of creating a std::shared_ptr.
Can we get some kind if mini-tutorial here, then, on how to use this
routine? I see several different ways it's p
Le 21/10/2012 08:54, Liviu Andronic a écrit :
If scripts are detected then a dialogue pops up with a warning and
asks the user how to proceed. This should provide a minimum of
security.
It is not really scripts that are used on editing like in office, but
rather dangerous converters.
JMarc
Le 21/10/2012 03:51, Scott Kostyshak a écrit :
I do not see knitr and Sweave security discussed anywhere. The
Customization guide has 5 paragraphs on security regarding external
templates.
It is a difficult problem indeed. I do not see a better solution that
marking some converters "dangerous"
Le 22/10/2012 00:41, Lars Gullik Bjønnes a écrit :
It is mentioned in c9b9748c that "using namespace std" on msvc10 also
drags in std::tr1 stuff.
IMHO a much better solution is to just use "std::" prefix where
required.
You mean using std::string everywhere? That does not sound nice.
I agr
30 matches
Mail list logo