Under Windows, in the Julia 0.3.1 REPL I get a weird Pkg.add() error:
...Version 0.3.1 (2014-09-21 21:30 UTC)
...x86_64-w64-mingw32
julia Pkg.add(Jewel)
ERROR: IJulia can't be installed because it has no versions that support
0.3.1 of julia
in wait at task.jl:284
in wait at
julia Pkg.status()
7 required packages:
- CUDA 0.1.0 2caa0935 (dirty)
- Cairo 0.2.12 f2f8203f (dirty)
- Gaston0.0.0 3ac1410f (dirty)
- IJulia0.1.12
-
...and Pkg.update() lists thousands of errors, finishing with:
WARNING: Images and Cairo had build errors...
After these Jewel can be added. Strange...
Btw. not all Ctrl-keys work. E.g. ^K is the Windows console Mark command
(English versions), and it has precedence over the REPL Kill command.
Maybe the REPL finally has to part from the Windows console class?
Is GLPlot supposed to work under Windows?
julia Pkg.clone(https://github.com/SimonDanisch/GLPlot.jl;)
INFO: Cloning GLPlot from https://github.com/SimonDanisch/GLPlot.jl
INFO: Computing changes...
ERROR: unknown package React required by GLPlot
in error at error.jl:21
in requirements at pkg/query.jl:9
Pkg.update() fixed the problem: example.jl produces nice plots of vivid
colors. The other .jl files in the example folder (e.g.
.julia\v0.3\GLPlot\example\image.jl) all produce errors. I guess they were
not meant to be run stand alone.
as well. Especially image.jl. For volume.jl, there are some sporadic errors
on ubuntu.
Also React seems to be surprisingly platform dependent.
@ Ian
I actually removed all unregistered packages to make it work. So All my
unregistered packages are out...
2014-07-25 23:43 GMT+02:00 Laszlo
...with the newest nightly, and after installing GhostScript (recommended
by ImageMagick) the printed errors are a bit different:
~~~
Warning: New definition
scale(ScaleNone{T:Integer},S:FloatingPoint) at
C:\Users\xxx\.julia\v0.3\Images\src\scaling.jl:56 is ambiguous with:
volume.jl:
~~~
INFO: loaded GLFW 3.0.4 Win32 WGL MinGW DLL from
C:\Users\xxx\.julia\v0.3\GLFW\deps\usr\lib\glfw3
ERROR: WriteBlob Failed
`c:\Users\xxx\.julia\v0.3\GLPlot\example\video\01.png' @
error/png.c/MagickPNGErrorHandler/1805
in error at error.jl:21
while loading
Yes. In image.jl comment line 30 and un-comment line 31. It displays then a
movable square, filled with gradually changing colors.
In volume.jl comment line 50. It will display 3 pairwise perpendicular
planes, each with a square grid on it. We can rotate and move them.
However, the images
terminal-communication internals.
On Wednesday, July 16, 2014 8:48:11 PM UTC-4, Laszlo Hars wrote:
I don't know, how to file an issue. Where can I get instructions? (The
STDERR behavior may be intentional. I kept asking about it in this group,
for months, but nobody was interested
We explained to you several times how to capture multi-line input.
You missed my points again. This was not the issue in this thread. Still,
if you look at the code snippets I posted here, you can see that I knew how
to handle multi-line input. I did not need your friendly reminder or
an issue?
Cheers,
Kevin
On Wed, Jul 16, 2014 at 4:36 PM, Laszlo Hars laszl...@gmail.com
javascript: wrote:
I hoped that at some point Julia error messages would again appear in
STDERR. No luck. Even the Release candidate 0.3.0-rc1 fails to write, e.g.
DomainError to STDERR (provoked
.
PS: https://github.com/JuliaLang/julia/issues/7633
On Wed, Jul 16, 2014 at 8:48 PM, Laszlo Hars laszl...@gmail.com
javascript: wrote:
I don't know, how to file an issue. Where can I get instructions? (The
STDERR behavior may be intentional. I kept asking about it in this group
I wanted to parse a string, which I can enter in the Julia REPL console:
a b c
with the desired result:
a \b\ c
These all fail:
julia eval(parse( a \b\ c ))
ERROR: no method *(ASCIIString, Array{Uint8,1})
julia eval(parse(a \b\ c))
ERROR: ParseError(extra token \\\ after end of expression)
in
The given example is not a parseable string.
I wanted to parse the valid string below (of course with longer segments
represented by the letters a, b and c, in more complex structures). The
point is to get all the internal quotes escaped in a returned string
expression, which I can assign to a
Thanks, Jameson. That almost does the job. I think I can smooth the rough
edges now! (If someone finds an even simpler solution, I'd appreciate that.)
fredagen den 4:e juli 2014 kl. 04:31:42 UTC+2 skrev Laszlo Hars:
Of course, 2str, 2*str and str*2 could be equivalent, as they are for
other data types. For me two (copies of) str is just more natural than
str1 times str2. Similarly, add str2 to str1 for concatenation
follows the natural
with error messages remain. The recent nightly builds of
Julia don't seem to write the error messages to STDERR, and so redirecting
it does not help.
On Friday, July 4, 2014 1:38:17 PM UTC-6, Laszlo Hars wrote:
(Terry) Typing commands in the REPL, I can see output on the screen and
it's also logged
the Julia REPL output.
On Friday, July 4, 2014 12:36:55 AM UTC-6, Steven G. Johnson wrote:
On Thursday, July 3, 2014 9:20:55 PM UTC-4, Laszlo Hars wrote:
Looking into Steve's code we see it cheats. Our problem has been that the
Julia console output does not appear on STDOUT, only the results
Thanks, Steve. I'd never imagined that the solution is that complicated.
Now I have something to digest for a couple of weeks :)
On Friday, July 4, 2014 11:32:13 AM UTC-6, Steven G. Johnson wrote:
Nevertheless, the thread was started saying that evaluation of computer
generated code was
when does the receiving side evaluate the code?
There are different solutions. E.g. I can send its length information with
the data, and call parse-evaluate when that many bytes arrived. (I coded
this up, and it is working, too). However, the function I posted for
evaluating computer generated
Thanks, Steve. Good to know that something works under MacOS.
Unfortunately, I get nothing to the Windows clipboard with your 2-engine
method, which was the problem that started this thread. (Also, my
application does not need an infinite Julia loop: I can just surround the
code to be executed
else, like printing something. Maybe, the print(orig_STDOUT, s) command
does the trick? This should be easy to Julia experts, but drives newbies
crazy.
On Thursday, July 3, 2014 5:24:39 PM UTC-6, Laszlo Hars wrote:
Oh, I see. It is not a 2-engine solution. It was not clear to me from
Steve's
Looking into Steve's code we see it cheats. Our problem has been that the
Julia console output does not appear on STDOUT, only the results of print()
do. Steve's code evaluates the input expression and then prints it. What we
see in STDOUT is not the Julia console output, but results of
Of course, 2str, 2*str and str*2 could be equivalent, as they are for other
data types. For me two (copies of) str is just more natural than str1 times
str2. Similarly, add str2 to str1 for concatenation follows the natural
language better. Also, you could define str1-str2 as deleting str2 from
This is what I have in my juliarc.jl file
~~~
pushdisplay(TextDisplay(STDOUT)) # display() does not write to STDOUT:
evalu(1+2) vs. evalu(print(1+2))
const STDOUT_orig = STDOUT
function evalu(s::String)# paste to console: evalu(Julia
commands )\n
try
rd, = redirect_stdout()
will be
on top of the display stack.
On Tue, Jul 1, 2014 at 5:12 PM, Steven G. Johnson steve...@gmail.com
javascript: wrote:
On Tuesday, July 1, 2014 1:20:25 PM UTC-4, Laszlo Hars wrote:
This is what I have in my juliarc.jl file
~~~
pushdisplay(TextDisplay(STDOUT))
I think
I spent several hours struggling with display() not using STDOUT. I found
that
pushdisplay(TextDisplay(STDOUT))
does not make display() to use STDOUT. I think it has something to do with
the Latex symbol support, because my old functions stopped working around
the time it was introduced.
Thanks Mike, this would allow fixing the problem, that display results
don't appear in STDOUT. The help says:
Display x using the topmost applicable display in the display
stack, typically using the richest supported multimedia output for
x, with plain-text STDOUT output as a fallback.
wrote:
On Sunday, June 29, 2014 12:04:00 PM UTC-4, Laszlo Hars wrote:
Now only the problem of catching syntax error messages remain
My example code already catches syntax errors. I don't see the
difficulty here.
The immediate goal is to capture everything the Julia console outputs for a
block of input (pasted from the Windows clipboard) and log it in a file, or
put it in the clipboard. The calling program then gets this data as IJulia
does, and processes it. (I can do it, with clearing the Julia
UTC-6, Steven G. Johnson wrote:
On Saturday, June 28, 2014 4:40:21 PM UTC-4, Laszlo Hars wrote:
One application of it is my AutoHotkey macro for MS Word. It has three
hotkeys. #1: takes the text from the caret backwards to a prescribed string
(double space), and passes this to Julia
...anyone? I'd appreciate ideas, even if they are untested.
, Laszlo Hars laszl...@gmail.com
javascript: wrote:
...anyone? I'd appreciate ideas, even if they are untested.
Thanks, Stéphane, for the link. That package uses Julia as a TCP server,
and passes the Julia code as a string. The result is returned in an
IOBuffer. It is certainly an alternative to pasting the clipboard to the
console, but does not solve my problems: print() and multi-line input is
not
, Laszlo Hars wrote:
The Julia nightly versions a couple months ago allowed simple
redirections of STDOUT and STDERR to user pipes, from where the data could
be read. Everything used to work fine, but not anymore.
The redirect_stdout() and redirect_stderr() functions to redirect stdio to
pipes
Thanks, Steve, but it just does not work for my problem. In my first post I
wrote that this simple redirection does not work with regular console
output, only with print(). Try it yourself:
~~~
rdstdout, wrstdout = redirect_stdout()
1+2
s = readavailable(rdstdout)
clipboard(s)
~~~
- the
I tried to get answers in various threads to my question below, but so far
nobody could help. Let me try in a separate thread… I use the latest Julia
0.3.0 nightly under Windows.
The problem: I have computer generated Julia code. The simplest case is
when a block of Julia instructions is
We could summarize our finding so far about the Julia console output
~ For Windows, with the latest nightly 0.3.0 Julia version
- Warnings are written to STDERR, they can easily be redirected, captured
to a variable
- Error messages might or might not get written to STDERR, but they cannot
be
...can someone at least verify that the 0.3.0 Julia console output in
Windows is not written to STDOUT, and error messages are not written to
STDERR? (The results of print() do appear on STDOUT)
will receive the
EOF signal*
On Sat, Jun 21, 2014 at 12:51 PM, Laszlo Hars laszl...@gmail.com
javascript: wrote:
...can someone at least verify that the 0.3.0 Julia console output in
Windows is not written to STDOUT, and error messages are not written to
STDERR? (The results of print() do
...furthermore: I naively thought the same code would capture the console
output in a variable. It does not. What am I still missing?
~~~
begin
stdout_orig = STDOUT
rd, wr = redirect_stdout()
try
1+2
finally
redirect_stdout(stdout_orig)
close(wr)
out = readall(rd)
println((length(out),out))
end
...and this is what I meant by saying that print() does produce data on
STDOUT (but regular console output does not):
~~~
begin
stdout_orig = STDOUT
rd, wr = redirect_stdout()
print(1+2)
redirect_stdout(stdout_orig)
close(wr)
out = readall(rd)
println((length(out),out))
end
~~~
RESULT (as
Could someone help with redirecting stderr? For example, the following code
does not get the error message shown in the Julia console in Windows 7,
Julia Version 0.3.0-prerelease+3789:
~~~
stderr_orig = STDERR
rd, wr = redirect_stderr()
1^-1
close(wr)
eof(rd)
close(rd)
out = readall(rd)
may not be included
when running the tests.
On 20 June 2014 22:29, Laszlo Hars laszl...@gmail.com javascript:
wrote:
I am confused: I can change all the outs to errs, but what variable
will contain the error message to be inspected? The error messages seem to
only appear in the console
A related issue: in the new (0.3.0-prerelease+3335) Julia console under
Win7 the text we see does not appear in the stdout pipe, nor do error
messages in the stderr. I had some code, which captured the content of
these pipes and put it on the Windows clipboard, but they stopped working.
Was it
Stefan, I used rotations in the factor() experiments a while ago, and it
was slow. When is a function inlined in Julia? Can we ask the JIT compiler
politely to do it? Maybe the explicit function calls made it slow in my
code?
COOL!
A little side note: some parts can still be tweaked. E.g. the function
reflect_bits(). Here are a few variations, although they don't affect the
running time:
~~~
function reflect1(n::Uint8) # Two '' operators and some parentheses removed
n = n 4 | n 4
n = (n 0xcc) 2 | (n
Stefan, do you know about any plans of LLVM to support rotations and bit
reversals in the near future? Those are the most important ones missing. I
tried rot8(x) = x8 | x56, and in my Windows-7 x64 machine it was slow
(more than twice slower than a shift alone). Bit reversing Int64 takes
be good to have some kind of popularity measure. In this way
one could list only the popular packages which are in use and not the
experimental ones.
Am Samstag, 19. April 2014 02:51:47 UTC+2 schrieb Laszlo Hars:
Tim: We spend too much time on this. I don't believe that telling in the
package
one could list only the popular packages which are in use and not the
experimental ones.
Am Samstag, 19. April 2014 02:51:47 UTC+2 schrieb Laszlo Hars:
Tim: We spend too much time on this. I don't believe that telling in the
package home page under what OS the package was tested, and what
It looks like the very simple change I noted yesterday makes the CUDA
package work under Windows. Before spamming the GIT depository, could
somebody verify it the fix really works? Or if it can be written in a
better way?
Add the following two lines to CUDA.jl, just above the include(...)
Jake:
I also have volunteered some of my time to this community. E.g. I had to
adapt Gaston to Windows systems, and documented the effort.
The description of a package listed in the Julia website ought to contain
notes that a package was only tested under a certain OS, and should not be
Tim: We spend too much time on this. I don't believe that telling in the
package home page under what OS the package was tested, and what external
functions are used is too much burden. It should be the norm, but obviously
I am alone with this view. -Laszlo
Some progress... For Windows, in the base.jl file libcuda has to be
replaced with nvcuda.dll. Not very intuitive... After installing CUDA,
this dll resides in the Windows System32 directory, so it is always found.
We can try speeding up the search for the dll, with adding the line
I added the package CUDA, but obviously it needs some tweaking for Windows
(e.g. after installing CUDA 6.0 for Win7-64 there is no libcuda, which I
was supposed to add to the library loading path). Can anyone help me with a
list of things I need to do in Windows to get the Julia CUDA package
my mistake... Can an administrator edit my post, and remove the reference
to the GNU Radio, and the C code snippet? It is just a straightforward
(pretty stupid) implementation of the standard, and carries no useful
information. I only used it to verify the Julia CRC code results, but there
are
I tried to simplify the inner loop to:
~~~
for word::D in data
remainder = (remainder word_size)
end
~~~
It still took more than half the time of the original (with table indexing
and two XORs) in my Win7-x64 machine. It shows that not much speed-ups with
the real operations can
note that the running time does not change with a partial loop unroll, like
this:
~~~
function signed_loop{D:Unsigned, A:Unsigned}(::Type{D}, r::A, data,
table::Vector{A})
local j = 0
for i = 1 : div(length(data),20)
r = (r 8) $ table[1 + (data[j+=1]$convert(D,r))]
r =
...and adding @inbounds begin ... end around the r-update instruction block
actually slows things down
Btw, I think this is the standard CRC32 written in Julia (without the
4-byte trick, or data conversion or padding), based on the GNU Radio
implementation
~~~
module CRC32 ###
export crc32
const t =
Has anyone done some work to access the bit manipulation instructions of
Intel CPU's?
For low level optimizations I would need rotations of unsigned integers.
Other useful intrinsic functions were byteswap, bitreverse,
bitscan-forward, bitscan-backward... There is an excellent online book
bit reverseal operation.
On Mon, Mar 31, 2014 at 9:52 AM, Laszlo Hars laszloh...@gmail.comwrote:
Has anyone done some work to access the bit manipulation instructions of
Intel CPU's?
For low level optimizations I would need rotations of unsigned integers.
Other useful intrinsic functions
I checked the types with printing all typeof(var), and everything is Int64
The comment next to the function header tells the output format, and you
can see in the (quite short) function code if it uses PRIMES or not. That
is all what varies. I don't know much about the Google formatter. I am also
not sure about putting experiment code on github, even if I knew how to
is this what you mean:
https://gist.github.com/LaszloHars/9876748
Thanks for the links and info about gist. It is really easy to use.
Here are the 4 gists with the factoring functions:
Julia 64-bit integer factorization to dictionary, with prime table and
mod30 coprime trial divisors
https://gist.github.com/LaszloHars/9876748
Julia 64-bit integer
An interesting idea, which also turned out to be slow in the current Julia
version (0.3.0):
There are 8 coprimes to 30, so one can reduce the data needs by only
keeping the gaps to the next coprimes in an array (g), and use the last
three bits of a counter for circular indexing. (Assuming the
a reliable difference between the two when acquiring more data
to make a comparison that tries to overcome noise in individual
measurements.
-- John
On Mar 27, 2014, at 10:02 PM, Laszlo Hars laszl...@gmail.comjavascript:
wrote:
Yes, these timings are in the global scope, but I see
Thanks, John, for your replies. In my system your code gives reliable
results, too, if we increase the loop limits to 10^9:
julia mean(t1s ./ t2s)
11.924373323658703
This 12% makes a significant difference in my function of nested loops
(could add up to a factor of 2 slow down). So, the
bytes allocated)
5001
All three functions produce identical native code. Can you send
exactly what your function definitions are, how you're timing them and
perhaps the output of code_native(f1,())?
On Fri, Mar 28, 2014 at 10:48 AM, Laszlo Hars laszloh...@gmail.com
wrote:
Thanks
I tried to speed up a Julia function of several levels of loops, but got
unexpected speed relations. The problem is demonstrated with:
~~~
tic()
j = k = 1
while k = 10^8
j += k 1
k += 1
end
toc()
tic()
j = k = 1
while true
k 10^8 break
j += k 1
k += 1
end
toc()
Yes, these timings are in the global scope, but I see the same speed
differences inside a function.
In a function:
elapsed time: 1.069738859 seconds
elapsed time: 0.965128370 seconds
still 11% difference
Thanks, Jameson. For us, beginners, could you add some notes about how to
use it, and what is happening under the hood?
It is certainly true that selecting the proper algorithm is very important,
and we don't normally have a clue about the internal working of Mathematica.
Returning to finding amicable numbers... In my old PC Euler's
divisor-summation method is faster when n 300,000. With a better
factorization
You could try this function to compute the sum of divisors faster, and
using very little memory:
~~~
function sumFactors(n)
f = 1
for (p,e) in factor(n)
f *= div(p^(e+1)-1,p-1)
end
return f
end
~~~
We can program Euler's recursion for the sum of divisors, too. It only
makes sense, when we need to compute the sum of divisors for many integers
in 1:n, because then we can reuse the already computed values. It is the
case, when we search for amicable numbers: we compute the vector of
Anyone? Any idea? This error prevents using Julia graphics. Does it mean
that nobody uses graphics in Julia, or is there something wrong with my
installation, which I could fix somehow?
On Sunday, March 9, 2014 11:35:26 AM UTC-6, Laszlo Hars wrote:
forgot to say:
Win7 x64
Julia Version
Thanks, Isaiah, for your response. Below is what I see.
~~~
Version 0.3.0-prerelease+1400 (2014-02-05 19:14 UTC)
Commit 6f3a4b6* (37 days old master)
x86_64-w64-mingw32
~~~
julia Pkg.update()
INFO: Updating METADATA...
INFO: Computing changes...
INFO: No packages to install, update or remove
~~~
I removed every piece of the Julia installation, and reinstalled in new
directories the newest prerelease:
Version 0.3.0-prerelease+1897 (2014-03-07 09:35 UTC)
Now Cairo (and Tk) installs w/o errors. I just wish Julia gave more
informative error messages. (I spent two days struggling with the
It looks like I will not be able to use this REPL until the TTY bug gets
fixed in Julia. Pity...
In the mean time I tried to improve the syntax error catching task. (I was
wrong with the assignment eating up part of the error: the code captured
parts of the string, and upon return we saw only
at the start of the repl loop (which looks like nothing)
On Sun, Mar 9, 2014 at 6:43 AM, Laszlo Hars laszl...@gmail.comjavascript:
wrote:
Your instructions, Isaiah, fixed the IJulia installation problem. It is
working now! Thanks!
With your help I could get a step closer to a possible
When installing Cairo I got this error:
~~~
ERROR: i not defined
in next at env.jl:127
in merge! at dict.jl:77
while loading ...\.julia\Cairo\deps\build.jl, in expression starting on
line 225
~~~
build.jl is only 130 lines long, so something does not add up. Does anyone
know a simple fix?
...a couple of examples, why eval(quote...end) is better than
eval(parse(...)):
~~~
julia eval(parse(x=1
x+1))
# - ERROR: extra token after end of expression
# in parse at string.jl:1219
julia eval(quote x=1
x+1 end)
# - 2
~~~
julia eval(parse(a = \ab \cd\ \)) # need to escape inside quote
`parse()` first, then syntax errors are returned
Nothing is returned, if there was a parse error. However, I can catch the
error with try/catch. This is what I meant with graceful error handling.
Also, it only works with string arguments, not with expressions. As I said,
passing nested strings
It is harder with julia-0.3.0-prerelease. I tried the win64 version in
Windows 7. (Other Windows versions should be similar, but I cannot test
them.)
We still need a batch file. I named it Julia.bat. It contains (with my test
setup path) only 2 lines
~
@c:\t\Julia
When I run Julia programs (*.jl files) via the supplied julia.bat, any
error message pops up in a command window, which gets immediately closed,
so there is no chance I can read it. An extra line in the batch file solves
the program: if errorlevel 1 pause
That is, the julia.bat could look like
90 matches
Mail list logo
