On Sunday, March 12, 2017 at 8:38:02 AM UTC, Jeroen Demeyer wrote:
>
> On 2017-03-12 09:35, Dima Pasechnik wrote:
> > X11?
>
> That can be disabled with --disable-gui
>
this does not work, still (here is a slightly weird error I get on OSX
(with Sage's gcc 5.4)):
g++ -DPACKAGE_NAME=\"\"
On Sunday, March 12, 2017 at 10:05:56 PM UTC, François wrote:
>
> On 13/03/17 11:00, Justin C. Walker wrote:
> > I'm trying to imagine surf without graphics (:-}), but perhaps that's
> not what you mean exactly.
> >
> > Thanks for clarifying.
>
> I don't know surf :) but I imagine it can
On 13/03/17 11:00, Justin C. Walker wrote:
I'm trying to imagine surf without graphics (:-}), but perhaps that's not what
you mean exactly.
Thanks for clarifying.
I don't know surf :) but I imagine it can output
to jpeg and tiff directly. And if X is found to
a basic x-window.
If the gui
On Mar 12, 2017, at 11:43 , Francois Bissey wrote:
>
>> On 13/03/2017, at 07:34, Justin C. Walker wrote:
>>
>>
>> On Mar 12, 2017, at 00:27 , Dima Pasechnik wrote:
>>
>>> there is no "issue" with pandoc. Most linux distros allow you to install it
>>> using package manager,
> On 13/03/2017, at 07:34, Justin C. Walker wrote:
>
>
> On Mar 12, 2017, at 00:27 , Dima Pasechnik wrote:
>
>> there is no "issue" with pandoc. Most linux distros allow you to install it
>> using package manager, and it is easy to install it on OSX or Windows.
>>
>> On the
On Mar 12, 2017, at 00:27 , Dima Pasechnik wrote:
> there is no "issue" with pandoc. Most linux distros allow you to install it
> using package manager, and it is easy to install it on OSX or Windows.
>
> On the other hand, it appears that surf had never been ported to OSX.
No: in fact,
> On 12/03/2017, at 21:38, Jeroen Demeyer wrote:
>
> On 2017-03-12 09:35, Dima Pasechnik wrote:
>> X11?
>
> That can be disabled with --disable-gui
Indeed X absence is not fatal in configure unlike libjpeg.
I guess my point is that before saying it needs porting it
On 2017-03-12 09:27, Dima Pasechnik wrote:
On the other hand, it appears that surf had never been ported to OSX.
What does that mean? It just means that pandoc is more popular than surf.
I somebody has really tried to compile surf on OS X and didn't manage,
that would be a different story.
On 2017-03-12 09:35, Dima Pasechnik wrote:
X11?
That can be disabled with --disable-gui
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
X11?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Apart from dependencies like jpeg what’s the problem with surf?
François
> On 12/03/2017, at 21:27, Dima Pasechnik wrote:
>
> there is no "issue" with pandoc. Most linux distros allow you to install it
> using package manager, and it is easy to install it on OSX or Windows.
there is no "issue" with pandoc. Most linux distros allow you to install it
using package manager, and it is easy to install it on OSX or Windows.
On the other hand, it appears that surf had never been ported to OSX.
--
You received this message because you are subscribed to the Google Groups
On 2017-03-11 20:18, Dima Pasechnik wrote:
in this sense dependence on pandoc is OK,
dependence on surf - much less so.
Isn't the issue with surf the same as pandoc: it requires dependencies
which are not part of Sage.
--
You received this message because you are subscribed to the Google
On Mar 11, 2017, at 01:32 , Jeroen Demeyer wrote:
> Speaking of optional packages, we should also think of a strategy to deal
> with optional packages which have dependencies which are not part of Sage.
>
> For example, the optional rst2ipynb package requires pandoc, which is not in
> Sage.
>
FYI, pandoc installs and runs on all the platforms that sage supports.
But surf does not.
in this sense dependence on pandoc is OK,
dependence on surf - much less so.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group
Speaking of optional packages, we should also think of a strategy to
deal with optional packages which have dependencies which are not part
of Sage.
For example, the optional rst2ipynb package requires pandoc, which is
not in Sage.
On the other hand, in #22378 I wanted to package surf as
On Wed, Mar 1, 2017 at 8:52 AM, Jeroen Demeyer wrote:
> I have been thinking about this too. My personal conclusion was that the
> "type" enumeration (standard, optional, experimental, pip, script) is simply
> too restricted and that we need additional metadata with more
On Wednesday, March 1, 2017 at 7:52:26 AM UTC, Jeroen Demeyer wrote:
>
> I have been thinking about this too. My personal conclusion was that the
> "type" enumeration (standard, optional, experimental, pip, script) is
> simply too restricted and that we need additional metadata with more
>
I have been thinking about this too. My personal conclusion was that the
"type" enumeration (standard, optional, experimental, pip, script) is
simply too restricted and that we need additional metadata with more
degrees of freedom.
Currently, the "type" field is relevant for:
- which packages
Hi,
having the possibility to install all optional packages is interesting for
easy deployment as well as for testing (we need more automated tests of
all optional packages, in particular more patchbots with optional packages
installed). Currently, some optional packages, like gmp/mpir,
20 matches
Mail list logo