On Sunday, January 1, 2017 at 6:18:24 PM UTC-8, Paul Masson wrote:
>
> On Sunday, January 1, 2017 at 5:33:31 PM UTC-8, Andrey Novoseltsev wrote:
>>
>> Trying to get back to threejs:
>>
>> - it is apparently possible to use HTTPS for rawgit.com and it has a CDN
>> which we actually must use to av
On Sunday, January 1, 2017 at 5:33:31 PM UTC-8, Andrey Novoseltsev wrote:
>
> Trying to get back to threejs:
>
> - it is apparently possible to use HTTPS for rawgit.com and it has a CDN
> which we actually must use to avoid being blocked
>
Sorry for some confusion I've created: I was sure I had u
Trying to get back to threejs:
- it is apparently possible to use HTTPS for rawgit.com and it has a CDN
which we actually must use to avoid being blocked
- "more usual CDNs" provide threejs, but not extra files like OrbitControl
- it seems that the recommended way of using threejs is to download
On Thursday, December 29, 2016 at 2:42:59 AM UTC-8, Volker Braun wrote:
>
> Instead of an ever-increasing list of undocumented environment variables
> like THEBE_DIR it would be nice to get that kind of runtime data from a
> configuration file...
>
>>
>>
Two pointers to related tickets:
https://
On Thu, Dec 29, 2016 at 11:58 AM, Volker Braun wrote:
> On Thursday, December 29, 2016 at 11:48:24 AM UTC+1, Erik Bray wrote:
>>
>> I agree. In a way I see sage.env as that configuration file--
>
>
> Of course its not unrelated, but I'd think of it as our internal api for
> accessing configuratio
On Thursday, December 29, 2016 at 11:48:24 AM UTC+1, Erik Bray wrote:
>
> I agree. In a way I see sage.env as that configuration file--
Of course its not unrelated, but I'd think of it as our internal api for
accessing configuration data. The configuration file itself shouldn't be
installed in
On Thu, Dec 29, 2016 at 11:42 AM, Volker Braun wrote:
> Instead of an ever-increasing list of undocumented environment variables
> like THEBE_DIR it would be nice to get that kind of runtime data from a
> configuration file...
I agree. In a way I see sage.env as that configuration file--the fact
Instead of an ever-increasing list of undocumented environment variables
like THEBE_DIR it would be nice to get that kind of runtime data from a
configuration file...
On Thursday, December 29, 2016 at 11:15:20 AM UTC+1, Erik Bray wrote:
>
> On Tue, Dec 27, 2016 at 11:34 PM, Paul Masson > wrote
On Tue, Dec 27, 2016 at 11:34 PM, Paul Masson wrote:
> I'm very much in favor of making Three.js a standard package, with the
> following caveats:
>
> 1) As of r80 the Three.js library has been reorganized to use ES6 Modules.
> There is little point in asking people to download the entire library
On Wednesday, 28 December 2016 18:12:36 UTC-7, Paul Masson wrote:
>
>
>
> On Wednesday, December 28, 2016 at 3:47:53 PM UTC-8, Andrey Novoseltsev
> wrote:
>>
>> On Tuesday, 27 December 2016 15:34:51 UTC-7, Paul Masson wrote:
>>>
>>> I'm very much in favor of making Three.js a standard package, wit
On Wednesday, December 28, 2016 at 3:47:53 PM UTC-8, Andrey Novoseltsev
wrote:
>
> On Tuesday, 27 December 2016 15:34:51 UTC-7, Paul Masson wrote:
>>
>> I'm very much in favor of making Three.js a standard package, with the
>> following caveats:
>>
>> 1) As of r80 the Three.js library has been
On Tuesday, 27 December 2016 15:34:51 UTC-7, Paul Masson wrote:
>
> I'm very much in favor of making Three.js a standard package, with the
> following caveats:
>
> 1) As of r80 the Three.js library has been reorganized to use ES6 Modules.
> There is little point in asking people to download the e
I'm very much in favor of making Three.js a standard package, with the
following caveats:
1) As of r80 the Three.js library has been reorganized to use ES6 Modules.
There is little point in asking people to download the entire library (even
with examples excluded as in the current optional pack
> I think it is already the default way to show 3d graphics in the notebook
> in the last versions. Isn't it?
>
> Correct. But I think he means how to use it from the *command line* -
yes? I wouldn't know about this; one would have to autolaunch a browser, I
guess, and other annoyances, not
I think it is already the default way to show 3d graphics in the notebook
in the last versions. Isn't it?
El miércoles, 7 de octubre de 2015, 9:28:32 (UTC+2), tdumont escribió:
>
> Le 07/10/2015 08:42, kcrisman a écrit :
> > >
> >
> > MMMhhh, interesting!
> >
> > Do you think it
Le 07/10/2015 08:42, kcrisman a écrit :
> >
>
> MMMhhh, interesting!
>
> Do you think it would be possible to replace jmol by jsmol in sage?
> or keep both and choose which on to use?
>
>
> This is already possible! In the notebook - thanks to tons of work by
> Jonathan and Vol
>
> >
>
> MMMhhh, interesting!
>
> Do you think it would be possible to replace jmol by jsmol in sage?
> or keep both and choose which on to use?
>
This is already possible! In the notebook - thanks to tons of work by
Jonathan and Volker. I don't know how that would work from command line
Le 06/10/2015 15:44, Jonathan a écrit :
> I believe the javascript version of Jmol, JSmol, actually uses a
> modified version of threejs for some of its 3D rendering. Thus it is
> also embedded in the Jmol/JSmol package.
>
> Jonathan
>
MMMhhh, interesting!
Do you think it would be possible to
I believe the javascript version of Jmol, JSmol, actually uses a modified
version of threejs for some of its 3D rendering. Thus it is also embedded
in the Jmol/JSmol package.
Jonathan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscr
>
> As far as I remember, the idea was to replace jmol with it.
> (But may be I am wrong).
>
>
That was an idea - or at least to have this as another option. I believe
(?) William uses, or used for a while, a souped-up version for 3d graphics
in SMC.
> Is this always an active project? Is
20 matches
Mail list logo