Anonymous functions in Julia currently have a lot of overhead. However,
I've come up with a temporary solution to this by writing a little macro
which speeds up anonymous function calls - all you have to do is wrap your
functions in @fn and they'll speed up, e.g.
x - x^2
becomes
@fn x - x^2
I think what this question boils down to is this: All else being equal
(performance, price, support), which language is ultimately nicer to
program in?
Mathematica is a fantastic - if not the best around - DSL for symbolic
maths. It's term-rewriting paradigm is pretty much perfectly suited
We've published a project ideas list for GSoC here:
http://julialang.org/gsoc/2014/
We'd like our ideas page to be as healthy and diverse as possible, so
please do make your suggestions. Projects can include things like new
packages, specific language/package features, or something more
Any time, Stefan - and I wholeheartedly agree about keeping this up
permanently. Speaking from experience, the issue tracker can be a little
intimidating for people who want to get involved.
I didn't mean to suggest any preference for CUDA over OpenCL, so I'll add a
note about the latter (this
Ok, I've added an autoformat project to the list. Jake, thanks for your
additions.
Do we have any kind of support for R interop? I might have missed it, but
if not I'll add it to the list.
Also, I'm thinking that it would be great for gradual adoption if there was
a good story for calling
Seems like that link is broken - works for me if I use raw.github.com/...
and then save the file.
Nice work, though! Is there any way you could get this to work with
Three.js?
On Wednesday, 5 March 2014 14:22:28 UTC, Fabian Gans wrote:
Hi all,
I collected some of my convenience functions
Well, I don't know that much about OpenGL, but I figure can take what
you've got and dump the data into Three.js, you've got the basics of
interactive 3D plotting. This would be especially great because it could be
integrated with IJulia / Light Table. Just a thought, really - something
I'd
RE some kind of `@unpack` macro: have a look at this question on Stack
Overflow and its answers:
http://stackoverflow.com/questions/9345056/in-clojure-how-to-destructure-all-the-keys-of-a-map/11182432#11182432
Interestingly enough it is possible to an extent, but for many reasons ends
up being
So, to clarify, Iterators aren't a thing in themselves. Iteration is an
interface, and to call something an iterator just means that you can put it
in a for loop. Tasks and Lazy Lists are both iterators; so are arrays,
sets, dictionaries, and a whole bunch of other things. But although you can
then you can swap types out and code will still work.
so i guess the cost to have take defined for iterators, and for tasks and
for lazy streams is less than i imagined.
andrew
On Saturday, 8 March 2014 08:06:33 UTC-3, Mike Innes wrote:
So, to clarify, Iterators aren't a thing
I think there's definitely a case for allowing any immutable type as
parameters, at least. I would open an issue on github if there isn't one
already, that way you can start a discussion.
names(Type) may be what you are looking for, e.g. names(Complex) = [:re,
:im]
On Saturday, 8 March 2014 14:41:47 UTC, Uwe Fechner wrote:
Thanks, iob.data works.
Is there a way in Julia to find out what are the field names of a Type,
like the dir function in Python?
Best regards:
Uwe
,
don't you want all the best and most powerful tools available - even if
that means that there are lots of ways to solve easier problems?
On Sat, Mar 8, 2014 at 8:36 AM, Mike Innes mike.j...@gmail.com wrote:
Ok, fair enough - I think the confusion for me lies in the fact that I
wouldn't have
, far from it.
Thanks for taking the time to join the discussion, and again, apologies if
you've felt that there's any hostility involved.
On 9 March 2014 11:23, andrew cooke and...@acooke.org wrote:
On Sunday, 9 March 2014 07:48:25 UTC-3, Mike Innes wrote:
Stefan: you want all the best
Yes, as Stefan has pointed out, making your own lexer/parser is not likely
to be the best way to approach this project (and perhaps we should make
that more explicit).
Your best bet here is to have a look at the existing Julia parser - get a
feel for things, then think about improvements you
I'm trying to write an unpack macro, just to learn a bit about
meta-programming (I get it's probably not the best idea,
but sometimes you learn a lot doing stupid things)
Absolutely agreed! But bear in mind that this may be a hard macro to write
in the general case. Nevertheless, I can give
macro unpack(p)
Expr(:block, [:($(n[i]) = $p[$i]) for i = 1:length(n)]...) | esc
end
Ok, that should work better. To avoid the hygiene pass you can wrap
everything in esc; for example
macro unpack()
quote
a = p[1]
b = p[2]
end | esc
end
On 14 March 2014 18:30, John Myles White
On that note is somebody working on a LightTable integration?
As it happens I'm having a go at it. It's probably buggy and definitely
missing features at the moment, but it's already a nice way to develop
packages (no more pesky reloading files).
https://github.com/one-more-minute/Jewel
Absolutely - the plan is to keep the ideas list around so that people who
want to get involved have a nice set of projects to pick from. Aside from
anything else it's probably a good idea to separate actual issues and
would be cool projects.
That said, if we're keeping the ideas list around we
Hey all,
TL;DR: New Light Table integration available
herehttps://github.com/one-more-minute/Jewel
.
I just wanted to share the milestone I recently passed with my Light Table
plugin. Thanks to the recent support for modules, I can now use the Julia
client to develop itself; I make a change,
Thanks for the tipoff, Andrew. Would you mind opening an issue to remind me
to look into Winston?
I've tried to make the readme a bit clearer, and also pushed a new update
which will install the Jewel.jl package for you and start a client on
startup. Hopefully this will make things easier and
Thanks!
I felt that the cloning suggestion was polluting the instructions, but I'll
add it back in its own section when I can. All you have to do is clone the
Jewel repo into one of the following folders:
OS X: ~/Library/Application Support/LightTable/plugins/
Linux:
There are probably better ways to resolve this problem – as Isaiah points
out, if getFuncPointer is fast enough, you needn't do anything at all. If
it's slow, I would probably just memoize it.
That said, if for some reason you particularly needed to inline a runtime
constant, you could do so
Although, getProcAddress is defined by an independent package, right? In
which case you probably want something more like:
module OpenGL
function init_opengl_fns(getProcAddr)
@eval begin
export glGetString, ...
glGetString(name::GLenum) = ccall($(getProcAddr(glGetString)), ,
Ok, if you're using an include then you don't need those @evals. Your @eval
include(gl4_3.jl) is definitely redundant, since include happens at run
time anyway.
You should benchmark it yourself to be sure (or perhaps check the llvm
output) but I'm pretty sure Isaiah is right here – you can
Although, it strikes me as odd that you would need runtime evaluation to
implement a library like this in the first place. Java must have OpenGL
bindings, for example – how do those libraries solve this problem? Are they
just really slow?
, Mike Innes mike.j.in...@gmail.com
wrote:
I agree entirely that macros and eval should be avoided if possible -
so why
have you used them for memoization?
const func_pointers = Dict{String, Ptr{Void}}()
getFuncPointerM(name) =
haskey(func_pointers, name) ?
func_pointers
(1) and (2) do equivalent operations at runtime, they only differ in
how the memoization is implemented (dict vs. global variable). Neither
requires an OpenGL context at compile time, making them roughly
equivalent
(3) caches information derived from the OpenGL context, which may be
If while true loops are idiomatic, could we perhaps make the true optional?
On Tuesday, 8 April 2014 18:57:53 UTC+1, Stefan Karpinski wrote:
Good idea. For what it's worth, these days I would be perfectly happy to
only program with while true loops and explicit breaks.
On Apr 8, 2014, at
It would definitely be good to have something like clojuredocs.org. You
could include the docs for functions in all packages and Base, make
everything searchable. If you could build meaningful connections between
packages, even better.
But – and please forgive me if I've missed the point here
To be fair, the simplest implementation being the fastest isn't
*necessarily* to Julia's credit, since it may also mean that Julia can only
optimise the simplest code. Not saying that's the case here, but it's worth
looking at it from that angle.
Chris' point gives me an idea for an @unroll
Ah, nice
On 10 Apr 2014 15:39, Isaiah Norton isaiah.nor...@gmail.com wrote:
See @simd: https://github.com/JuliaLang/julia/pull/5355
On Thu, Apr 10, 2014 at 10:26 AM, Mike Innes mike.j.in...@gmail.comwrote:
To be fair, the simplest implementation being the fastest isn't
*necessarily
Lisp has certainly had a strong influence on Julia. First class functions,
homoiconicity, running code at compile time and compiling code at runtime,
the interactive REPL, dynamic typing and GC, everything you could really
want from a Lisp is there.
But, syntax does make a difference, I think.
That @sprintf is a macro sort of explains why using a run-time value
doesn't work in the same way, but it isn't really *the* reason since
@sprintf(fmt,
val) could work in principle – it would just have to delegate to a function
if its argument isn't a compile-time string.
If using a run-time
This is something of an unsolved problem at the moment, but one way to
explore is methodswith(AType).
If you're looking for more flexible function chaining, I recommend having a
look at the threading macros in
Lazy.jlhttps://github.com/one-more-minute/Lazy.jl#macros
.
On Saturday, 12 April
It occurs to me that, if you really need this, you can define
sprintf(args...) = eval(:@sprintf($(args...)))
It's not pretty or ideal in terms of performance, but it will do the job.
fmt = %8.1e
sprintf(fmt, 3.141) #= 3.1e+00
On Sunday, 13 April 2014 22:47:12 UTC+1, Dominique Orban wrote:
People often talk about code concision as if it's a simple case of number
of characters or lines per idea / function / project / whatever. And sure,
SLOC is an indicator of how expressive a language is, but a fundamentally
flawed one because it conflates two distinct issues: (1), the number of
I'm using text/julia at the moment. That's following CodeMirror's
standard of using e.g. text/x-python, but with the x dropped because it's
been deprecated.
I'm not sure that packages should export main() functions – that's going to
complicated things when a user wants to require CRC and define their own
main().
How about leaving it unexported and using julia -e using PKG;
PKG.main(ARGS)?
On Sunday, 27 April 2014 16:12:41 UTC+1, andrew cooke
If you need deeper pattern matching Match.jl is a great option, but you may
also be interested in the @switch macro that lives in Lazy.jl – it will
have zero overhead for cases like your example.
https://github.com/one-more-minute/Lazy.jl#macros
On Friday, 2 May 2014 15:11:08 UTC+1, Cameron
You could certainly define homoiconicity as zero syntactical distinction
between data and code – Clojure would pass this test because writing code
and writing a list are exactly the same, whereas Julia would fail it.
This definition is perfectly valid, so the problem isn't that it's
incorrect
JavaScript still sorely misses
macros).
On 7 May 2014 15:24, Jason Merrill jwmerr...@gmail.com wrote:
On Wednesday, May 7, 2014 6:37:20 AM UTC-7, Mike Innes wrote:
You could certainly define homoiconicity as zero syntactical distinction
between data and code – Clojure would pass this test because
As a rule, you generally want to translate
object.func(args...)
into
func(object, args...)
State can be kept in the fields of the object, and accessed using the
dot-notation as above. Julia doesn't have class-base inheritance but you
can still do objects just fine, albeit with slightly
Am I right in thinking that the issues you have with function call
overloading are equivalent to those involved with multiple inheritance? In
the sense that overloading function application effectively makes an array
(for example) a member of both AbstractArray and Callable, which will
create
Hey all,
Markdown.jl https://github.com/one-more-minute/Markdown.jl is available
to try with Pkg.clone(Markdown). It's very much in beta but it's still
pretty useful if (for example) you want to quickly look at a package's
readme.
Parsed markdown should display nicely (ish) in the terminal as
This is certainly possible, but I imagine it's not going to happen except
as an outside project.
Making a compiler like this isn't exactly easy, either – you'd probably
have to do a lot of reaching into Julia's C internals to get to the
type-inferred code.
You're welcome to try this, and I'm
Mike Innes:
So, Light Table calls a command which looks like julia
/Users/feldt/Library/Application
Support/LightTable/plugins/Jewel/jl/init.jl [port] [id].
From the looks of it finding Julia isn't the problem – it's just that
Julia itself is choking on the space and can't find the init.jl
I think your second snippet must have gotten a bit muddled, since `expr`
should end up with the value 5.
macro createVar(name, value)
quote
$name = $value;
end
end
expr = @createVar foo 5
# This is equivalent to `expr = (foo = 5)`, *not* `expr = :(foo = 5)`
expr == 5
If you do want
Alternatively
macroexpand(:@createVar(foo, 5))
Might have the desired behaviour.
On Thursday, 15 May 2014 12:51:15 UTC+1, Mike Innes wrote:
I think your second snippet must have gotten a bit muddled, since `expr`
should end up with the value 5.
macro createVar(name, value)
quote
/latest/manual/metaprogramming/#hygienesection
of the manual.
On Thursday, 15 May 2014 12:53:13 UTC+1, Mike Innes wrote:
Alternatively
macroexpand(:@createVar(foo, 5))
Might have the desired behaviour.
On Thursday, 15 May 2014 12:51:15 UTC+1, Mike Innes wrote:
I think your second
You may also be interested in zip:
for (file, i) in zip(files, 1:length(files))
println(file, , i)
end
# Even better:
using Lazy
for (file, i) in zip(files, range())
println(file, , i)
end
Enumerate is definitely the best solution here, but zip is more general if
you find yourself
Well, if you want the first syntax you can easily define
Base.enumerate(f::Function, args...) = map(t-f(t...), enumerate(args...))
You could always open a pull request if you wanted to see this in Base, too.
On Thursday, 15 May 2014 21:18:31 UTC+1, Cameron McBride wrote:
I missed enumerate()
, but my
julia-fu isn't strong enough that it jumped out at me when I looked over
some source in base/. I expect it's simple, but I don't have time to
figure it out today.
Cameron
On Thu, May 15, 2014 at 4:51 PM, Mike Innes mike.j.in...@gmail.comwrote:
Well, if you want the first syntax you
are effectively a special case of floating point numbers.
On 17 May 2014 13:40, Hans W Borchers hwborch...@gmail.com wrote:
Thanks, Mike, for the prompt answer.
But what if i want to explicitly exclude integers.
I think with Real I would allow them.
On Saturday, May 17, 2014 2:13:09 PM UTC+2, Mike Innes
, 2014 05:03:07 AM Mike Innes wrote:
I may be missing the point here, but wouldn't it be easier to define
sumf
as a macro?
macro sumf(f, xs)
quote
s = 0.0
x = $(esc(xs))
for i = 1:length(x)
s += $(esc(f))(x[i])
end
s
end
end
You might want to have a look through matplotlib's 3D API – personally I'd
be really to see basic 3D plotting working really well.
http://matplotlib.org/1.3.1/mpl_toolkits/mplot3d/tutorial.html
Looking forward to seeing what you come up with!
On Saturday, 17 May 2014 17:51:37 UTC+1, Simon
)
19.427283165919906
Three orders of magnitude is enough of a speed difference to notice :).
--Tim
On Saturday, May 17, 2014 09:31:29 AM Mike Innes wrote:
That macro being slow at the top level isn't really a strike against the
macro technique, because it's easily resolved:
(Although
not
convinced that the macro solution is worse unless you specifically want to
simulate higher-order functions (which you do, of course, so fair enough).
On Sunday, 18 May 2014 07:24:38 UTC+1, Mike Innes wrote:
Fair point. I timed this in a loop and it seems to be about an order of
magnitude slower
This is really cool! Thanks for sharing it, especially with the video.
You might be interested in packaging this
uphttp://docs.julialang.org/en/latest/manual/packages/#package-development–
it doesn't have to be officially registered or anything, but just putting
everything into a module would
If you're looking for a consistent API between 2D and 3D it might be worth
taking some inspiration from Gadfly – I don't know how easy it would be to
extend the Grammar of Graphics style interface to 3D but if you can it
would be a solid base to build on (alongside a more matlab-style API, I
A quick search turns up isleaftype, which seems to do exactly the opposite
of what you want:
isleaftype(AbstractArray) = false
isleaftype(Array{Int, 2}) = true
Hope that helps.
On 21 May 2014 20:15, Stephen Chisholm sbchish...@gmail.com wrote:
Is there a way to check if a given DataType is
Link:
http://stackoverflow.com/questions/23806758/julia-dataframes-problems-with-split-apply-combine-strategy
I definitely agree that having a greater presence on SO would be useful, so
it might be best to answer there (sorry I can't be more directly helpful,
OP)
On 22 May 2014 13:56, Paulo
Great! This feature will be in Light Table soon, too – complete with fuzzy
searching, so that it's easy to browse all available symbols :)
On 22 May 2014 18:27, Steven G. Johnson stevenj@gmail.com wrote:
A quick update for people who haven't been tracking git closely:
The Julia REPL
Why do you say it's too far fetched? I agree that it shouldn't be the
default, but I don't see any technical issues with the idea.
On 23 May 2014 13:36, Andrea Pagnani andrea.pagn...@gmail.com wrote:
The idea to have a pager that allows for browsing efficiently large data
structures as
skills. As I said, I would be already
happy with a simple workaround to redirect STDOUT on less.
On Friday, May 23, 2014 2:45:56 PM UTC+2, Mike Innes wrote:
Why do you say it's too far fetched? I agree that it shouldn't be the
default, but I don't see any technical issues with the idea.
On 23
Incidentally, interop with other packages without a hard dependency is
something that's around the corner, so you will be able to do this soon.
On 23 May 2014 15:32, Adam Smith swiss.army.engin...@gmail.com wrote:
Thanks all for the feedback! I have renamed it to TextPlot.jl, added
support
Cool, I'll add this to my ever-growing list :)
Perhaps less could emit some kind of Scrollable wrapper type, which would
display itself in the REPL as a pager, or in IJulia as an HTML scroll pane?
I've been meaning to try out table display of arrays anyway, so this
would tie in neatly with that.
a name collision.
On Fri, May 23, 2014 at 10:56 AM, Mike Innes mike.j...@gmail.comwrote:
Incidentally, interop with other packages without a hard dependency
is something that's around the corner, so you will be able to do this
soon.
On 23 May 2014 15:32, Adam Smith swiss.arm...@gmail.com
You don't seem to have tried keyword arguments – these are usually the best
option if you have a large set of parameters to pass a single function.
They may not fit your use case but they might be interesting to benchmark
at least.
On 30 May 2014 10:42, Jon Norberg jon.norb...@ecology.su.se
You should definitely open an issue about this – if your timings are right
it's definitely not desirable behaviour.
https://github.com/JuliaLang/julia/issues?state=open
On 31 May 2014 11:00, mike c coolbutusel...@gmail.com wrote:
I've narrowed down the problem. It's not a profiling problem.
This is a great start as way to do external documentation – I've been
thinking a lot about this problem but hadn't even considered this kind of
format.
I imagine that you don't do much parsing of the markdown files except to
separate entries, but I should mention that I started the Markdown.jl
though, sprint(Markdown.terminal_print, ans) strips
out the line wrapping. Is there an easy way to retain that formatting in
the string?
On Monday, 9 June 2014 10:49:56 UTC+2, Mike Innes wrote:
I just fixed it up to work with n level headers – it should do everything
you need it to now
REQUIRE file?
On Monday, 9 June 2014 12:23:56 UTC+2, Mike Innes wrote:
Woops – yeah, terminal_print takes a columns keyword argument.
sprint(io - Markdown.terminal_print(io, md, columns = 80))
On 9 June 2014 11:16, Michael Hatherly michael...@gmail.com wrote:
Great, just pushed some other
.
Is Markdown.html_inline what I should be using to produce html output in
a similar manner to terminal_print?
On Monday, 9 June 2014 14:24:12 UTC+2, Mike Innes wrote:
This is just because Markdown.jl didn't have a release – I don't know if
there's a way to depend on such packages and/or arbitrary
This is really cool.
It looks like there are still some issues with syntax highlighting in these
notebooks (breaking on triple quoted strings, highlighting unicode
characters as errors for example) but this situation should improve greatly
once my CodeMirror mode is ready for IJulia.
On
FWIW – putting to one side the question of whether or not this is a good
idea – it would be possible to do this without new language syntax.
However, you'd have to either pass a type hint or be explicit about the
variables you want:
e.g.
function tick(state::SvfSinOsc, coef::SvfSinOscCoef)
–
just to show off the things you can do with Julia even though you really
shouldn't.
On Thursday, 12 June 2014 09:21:58 UTC+1, Mike Innes wrote:
FWIW – putting to one side the question of whether or not this is a good
idea – it would be possible to do this without new language syntax.
However
12, 2014 4:21:58 PM UTC+8, Mike Innes wrote:
FWIW – putting to one side the question of whether or not this is a good
idea – it would be possible to do this without new language syntax.
However, you'd have to either pass a type hint or be explicit about the
variables you want:
e.g
Is there a particular reason to document functions as opposed to just
methods? I would have thought that documentation for the most generic
method + some specific methods where necessary would be enough. It's best
if documentation is as simple as possible – we do want to encourage people
to use
The issue with only storing text is that we want to support interpolation
of results, including for things like plots. If you only store the text
then those results will be re-evaluated every time the help is displayed.
Really, you'd want to parse everything and evaluate results immediately,
then
as me having type all the names in full? (I am 99.9% the
answer is yes, but I want to be sure!)
On Thursday, June 12, 2014 6:14:15 PM UTC+8, Mike Innes wrote:
Ok, managed to have a quick go at this – source with some examples:
https://gist.github.com/one-more-minute/668c5c7cdd8fd8b81d35
Sure, I don't know exactly the best way to do the caching (it probably
depends on how we handle function metadata in the first place) but there
are definitely ways to store arbitrary Julia data on disk.
On 12 June 2014 15:01, Michael Hatherly michaelhathe...@gmail.com wrote:
Yes, the tree is a
Indeed, Ruby has the ternary operator as well.
I imagine it's unlikely to change at this point, but +1 for trailing ? from
me – just in case :)
On Thursday, 12 June 2014 19:30:58 UTC+1, Stefan Karpinski wrote:
It's definitely a surmountable thing – I'd actually be rather in favor of
using a
.
That's not meant to put off anyone who wants to have a go at this, just
warning that it wouldn't be as trivial as it sounds.
On Friday, 13 June 2014 02:01:28 UTC+1, David Moon wrote:
Mike Innes' atsign with macro is good, but it would be better if it would
iterate over the AST for its last
even much
documentation, so far as I know.
I don't understand your comment about the overhead of the let binding used
by the mutating version of the macro. What extra overhead is that?
On Friday, June 13, 2014 3:57:07 AM UTC-4, Mike Innes wrote:
That was my first thought, too – and it's fine
of the expression in the nearest `with` block.
function f(A)
with A
.c = .a + .b
end
end
However, since this only saves a one character, it really isn't
worthwhile.
function f(A)
Z = A
Z.c = Z.a + Z.b
end
On Thu, Jun 12, 2014 at 6:14 AM, Mike Innes mike.j.in...@gmail.com
function process8 (state::CircuitModel, input::Float)
state.a = 5
end
You're right that you can't tell whether the code above is correct without
knowing about CircuitModel, but it is obvious where all the variables are
coming from and what's happening to them – and that's really valuable
I
have time, though.
On 14 June 2014 10:46, Andrew Simper andrewsim...@gmail.com wrote:
On Saturday, June 14, 2014 5:22:23 PM UTC+8, Mike Innes wrote:
function process8 (state::CircuitModel, input::Float)
state.a = 5
end
You're right that you can't tell whether the code above
function with_out_str(f::Function)
orig_stdout = STDOUT
rd, wr = redirect_stdout()
f()
redirect_stdout(orig_stdout)
return readavailable(rd)
end
macro with_out_str(expr)
:(with_out_str(()-$expr)) | esc
end
You can use this as
@with_out_str begin
... code ...
end
But I think
to
only appear in the console, nowhere else.
On Friday, June 20, 2014 2:47:28 PM UTC-6, Mike Innes wrote:
function with_out_str(f::Function)
orig_stdout = STDOUT
rd, wr = redirect_stdout()
f()
redirect_stdout(orig_stdout)
return readavailable(rd)
end
macro with_out_str(expr
?
On Monday, June 23, 2014 9:02:05 AM UTC-7, Mike Innes wrote:
Turns out that I can't eval the Gadfly scripts because they are now
inside SVGScriptElement blocks (as opposed to HTMLScriptElement), which
don't have a .text property. Any javascript wizards around who know of a
way around
This looks great! When I get the chance I'll look into integrating this
with Light Table, so that if you evaluate a function with a docstring it's
automatically applied.
On 27 June 2014 14:50, Michael Hatherly michaelhathe...@gmail.com wrote:
*Update:*
Some major changes have been made to
What would be great is if Docile could have it's own help database, i.e. a
global dict mapping arbitrary objects to Markdown AST objects. Then you can
patch the Base help() function to look there first and fall back to the
helpdb.
That's roughly the approach we're heading for in Base anyway, so
Hey all,
I've released the latest version of the Julia environment
https://github.com/one-more-minute/Jupiter-LT I'm building. There are a
whole bunch of improvements but the main ones are:
- Support for latex completions (\alpha etc.)
- Support for graphics including Gadfly and
Sigfrids johan.sigfr...@gmail.com wrote:
Do you need to add some package Julia side to make this work?
On Sunday, June 29, 2014 12:46:21 PM UTC+3, Mike Innes wrote:
Hey all,
I've released the latest version of the Julia environment
https://github.com/one-more-minute/Jupiter-LT I'm building
:\Users\admin\AppData\Local\LightTable\plugins\Jewel\jl\init.jl,
in expression starting on line 26
On Sunday, June 29, 2014 8:35:06 PM UTC+3, Mike Innes wrote:
Technically you do need the Jewel.jl package, but this should be
installed for you when the client boots the first time. If this isn't
Luis jmfl...@gmail.com wrote:
Mike, yes you were right thanks. Updated ad now it works (I had the
impression that it warned me to update some time ago so didn't bother to
check it now)
Joaquim
Domingo, 29 de Junho de 2014 19:40:19 UTC+1, Johan Sigfrids escreveu:
I update all by Mike Innes
UTC+2 schreef Mike Innes:
Hey all,
I've released the latest version of the Julia environment
https://github.com/one-more-minute/Jupiter-LT I'm building. There
are a whole bunch of improvements but the main ones are:
- Support for latex completions (\alpha etc.)
- Support for graphics
June 2014 13:16, Mike Innes mike.j.in...@gmail.com wrote:
Alireza – I think you've won the weirdest error competition. This looks
like some kind of low-level graphics issue, so if it's caused by the plugin
something very strange is going on. Does it still happen when Julia is
disconnected? What
at boot.jl:244
in include_from_node1 at loading.jl:128
in process_options at client.jl:285
in _start at client.jl:354
On Monday, June 30, 2014 3:24:43 PM UTC+3, Mike Innes wrote:
PSA: I've just realised that installing the plugin doesn't change the
default theme as I had thought. I've added
1 - 100 of 283 matches
Mail list logo
