[julia-users] [ANN] DataStreams v0.1: Blog post + Package Release Notes

[Jacob Quinn]

Hey everyone,

Just wanted to put out the announcement of the release of DataStreams v0.1. 
(it was actually tagged a few weeks ago, but I've been letting a few last 
things shake out before announcing).

I've written up a blog post on the updates and release 
here: http://quinnj.github.io/datastreams-jl-v0-1/

The TL;DR is DataStreams.jl now defines concrete interfaces for 
Data.Sources and Data.Sinks, with each being completely decoupled from the 
other. This has also allowed some cool new features like appending to 
Data.Sinks and allowing simple transform functions to be applied to data 
"in-transit".

I included release notes of existing packages in the blog post, but I'll 
copy-paste here below for easier access:

Do note that the DataStreams.jl framework is now Julia 0.5-only.



   - 
   
   *CSV.jl*
   - *Docs* 
  - Supports a wide variety of delimited file options such as delim, 
  quotechar, escapechar, custom null strings; a header can be provided 
  manually or on a specified row or range of rows; types can be 
  provided manually, and results can be requested as nullable or not (
  nullable=true by default); and the # of rows can be provided manually 
  (if known) for efficiency.
  - CSV.parsefield(io::IO, ::Type{T}) can be called directly on any IOtype 
  to tap into the delimited-parsing functionality manually
   - 
   
   *SQLite.jl*
   - *Docs* 
  - Query results will now use the declared table column type by 
  default, which can help resultset column typing in some cases
  - Parameterized SQL statements are fully supported, with the ability 
  to bind julia values to be sent to the DB
  - Full serialization/deserialization of native and custom Julia types 
  is supported; so Complex{Int128} can be stored in its own SQLite 
  table column and retrieved without any issue
  - Pure Julia scalar and aggregation functions can be registered with 
  an SQLite database and then called from within SQL statements: full docs 
  here 
  
   - *Feather.jl*
  - *Docs* 
  - Full support for feather release v0.3.0 to ensure compatibility
  - Full support for returning "factor" or "category" type columns as 
  native CategoricalArray and NullableCategoricalArray types in Julia, 
  thanks to the new CategoricalArrays.jl 
   package
  - nullable::Bool=true keyword argument; if false, columns without 
  null values will be returned as Vector{T} instead of NullableVector{T}
  - Feather.Sink now supports appending, so multiple DataFrames or 
  CSV.Source or any Data.Source can all be streamed to a single feather 
  file
   - *ODBC.jl*
  - *Docs* 
  - A new ODBC.DSN type that represents a valid, open connection to a 
  database; used in all subsequent api calls; it can be constructed using a 
  previously configured system/user dsn w/ username and password, or as a 
  full custom connection string
  - Full support for the DataStreams.jl framework through the 
  ODBC.Sourceand ODBC.Sink types, along with their high-level 
  convenience methods ODBC.query and ODBC.load
  - A new ODBC.prepare(dsn, sql) => ODBC.Statement method which can 
  send an sql statement to the database to be compiled and planned 
  before executed 1 or more times. SQL statements can include parameters to 
  be prepared that can have dynamic values bound before each execution.
   

Re: [julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

or, the more specific

function read_integer(prompt::String="")::Int
print(prompt)
str = chomp(readline())
   return parse(Int, str)
end

On Friday, October 28, 2016 at 1:17:54 AM UTC-4, Jeffrey Sarnoff wrote:
>
> with Yichao's help,
>
>
>
> typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, Bool} 
>
> """
> `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T`
>
> Read an integer or a floating point value from STDIN.
>
>
> The prompt string, if given, is printed to standard output without a
> trailing newline before reading the input.
>
> days = input(Int, "How many days? ")
>
> """
> function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T
> print(prompt)
> str = chomp(readline())
>return parse(T, str)
> end
>
>
>
>
>
>
>
> On Friday, October 28, 2016 at 12:48:33 AM UTC-4, Jeffrey Sarnoff wrote:
>>
>> Thank you, that is helpful.
>>
>> On Friday, October 28, 2016 at 12:22:37 AM UTC-4, Yichao Yu wrote:
>>>
>>> On Fri, Oct 28, 2016 at 12:01 AM, Jeffrey Sarnoff 
>>>  wrote: 
>>> > And although readline() yields a String, if you are asking for, say, a 
>>> Int 
>>> > or a Float64 value, you can add a second version of `input`: 
>>> > 
>>> > ``` 
>>> > typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, 
>>> Bool} 
>>> > 
>>> > """ 
>>> > `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T` 
>>> > 
>>> > Read an integer or a floating point value from STDIN. 
>>> > 
>>> > The prompt string, if given, is printed to standard output without a 
>>> > trailing newline before reading the input. 
>>> > 
>>> > days = input(Int, "How many days? ") 
>>> > 
>>> > """ 
>>> > function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T 
>>> > print(prompt) 
>>> > str = chomp(readline()) 
>>> > return parse(str) 
>>>
>>> Don't use `parse(::String)` for this. It is for parsing julia code, 
>>> not for parsing numbers. Use sth like `parse(Int, str)` intead. 
>>>
>>> > end 
>>> > ``` 
>>> > 
>>> > 
>>> > On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas 
>>> Castelló 
>>> > wrote: 
>>> >> 
>>> >> """ 
>>> >> `input(prompt::String="")::String` 
>>> >> 
>>> >> Read a string from STDIN. The trailing newline is stripped. 
>>> >> 
>>> >> The prompt string, if given, is printed to standard output without a 
>>> >> trailing newline before reading input. 
>>> >> """ 
>>> >> function input(prompt::String = "")::String 
>>> >> print(prompt) 
>>> >> return chomp(readline()) 
>>> >> end 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
>>> >> escribió: 
>>> >>> 
>>> >>> Hello, 
>>> >>> 
>>> >>> How could I input a data from the console? For instance, I would 
>>> like to 
>>> >>> make such that user is able to input the value of x. Is there any 
>>> way to do 
>>> >>> it like in Fortran or something? I can't find anything in 
>>> documentation. 
>>> >>> 
>>> >>> P.S. Also, I believe there is a way to input a string using 
>>> readline() 
>>> >>> function. However, if I do something like: 
>>> >>> 
>>> >>> a = readline() 
>>> >>> "asd" 
>>> >>> 
>>> >>> then I will get "\"asd\"\r\n". 
>>> >>> 
>>> >>> How to avoid these excess symbols? 
>>> >>> 
>>> >>> Thank you in advance! 
>>>
>>

Re: [julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

with Yichao's help,



typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, Bool} 

"""
`input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T`

Read an integer or a floating point value from STDIN.


The prompt string, if given, is printed to standard output without a
trailing newline before reading the input.

days = input(Int, "How many days? ")

"""
function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T
print(prompt)
str = chomp(readline())
   return parse(T, str)
end







On Friday, October 28, 2016 at 12:48:33 AM UTC-4, Jeffrey Sarnoff wrote:
>
> Thank you, that is helpful.
>
> On Friday, October 28, 2016 at 12:22:37 AM UTC-4, Yichao Yu wrote:
>>
>> On Fri, Oct 28, 2016 at 12:01 AM, Jeffrey Sarnoff 
>>  wrote: 
>> > And although readline() yields a String, if you are asking for, say, a 
>> Int 
>> > or a Float64 value, you can add a second version of `input`: 
>> > 
>> > ``` 
>> > typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, 
>> Bool} 
>> > 
>> > """ 
>> > `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T` 
>> > 
>> > Read an integer or a floating point value from STDIN. 
>> > 
>> > The prompt string, if given, is printed to standard output without a 
>> > trailing newline before reading the input. 
>> > 
>> > days = input(Int, "How many days? ") 
>> > 
>> > """ 
>> > function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T 
>> > print(prompt) 
>> > str = chomp(readline()) 
>> > return parse(str) 
>>
>> Don't use `parse(::String)` for this. It is for parsing julia code, 
>> not for parsing numbers. Use sth like `parse(Int, str)` intead. 
>>
>> > end 
>> > ``` 
>> > 
>> > 
>> > On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas 
>> Castelló 
>> > wrote: 
>> >> 
>> >> """ 
>> >> `input(prompt::String="")::String` 
>> >> 
>> >> Read a string from STDIN. The trailing newline is stripped. 
>> >> 
>> >> The prompt string, if given, is printed to standard output without a 
>> >> trailing newline before reading input. 
>> >> """ 
>> >> function input(prompt::String = "")::String 
>> >> print(prompt) 
>> >> return chomp(readline()) 
>> >> end 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
>> >> escribió: 
>> >>> 
>> >>> Hello, 
>> >>> 
>> >>> How could I input a data from the console? For instance, I would like 
>> to 
>> >>> make such that user is able to input the value of x. Is there any way 
>> to do 
>> >>> it like in Fortran or something? I can't find anything in 
>> documentation. 
>> >>> 
>> >>> P.S. Also, I believe there is a way to input a string using 
>> readline() 
>> >>> function. However, if I do something like: 
>> >>> 
>> >>> a = readline() 
>> >>> "asd" 
>> >>> 
>> >>> then I will get "\"asd\"\r\n". 
>> >>> 
>> >>> How to avoid these excess symbols? 
>> >>> 
>> >>> Thank you in advance! 
>>
>

Re: [julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

Thank you, that is helpful.

On Friday, October 28, 2016 at 12:22:37 AM UTC-4, Yichao Yu wrote:
>
> On Fri, Oct 28, 2016 at 12:01 AM, Jeffrey Sarnoff 
> > wrote: 
> > And although readline() yields a String, if you are asking for, say, a 
> Int 
> > or a Float64 value, you can add a second version of `input`: 
> > 
> > ``` 
> > typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, 
> Bool} 
> > 
> > """ 
> > `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T` 
> > 
> > Read an integer or a floating point value from STDIN. 
> > 
> > The prompt string, if given, is printed to standard output without a 
> > trailing newline before reading the input. 
> > 
> > days = input(Int, "How many days? ") 
> > 
> > """ 
> > function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T 
> > print(prompt) 
> > str = chomp(readline()) 
> > return parse(str) 
>
> Don't use `parse(::String)` for this. It is for parsing julia code, 
> not for parsing numbers. Use sth like `parse(Int, str)` intead. 
>
> > end 
> > ``` 
> > 
> > 
> > On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas 
> Castelló 
> > wrote: 
> >> 
> >> """ 
> >> `input(prompt::String="")::String` 
> >> 
> >> Read a string from STDIN. The trailing newline is stripped. 
> >> 
> >> The prompt string, if given, is printed to standard output without a 
> >> trailing newline before reading input. 
> >> """ 
> >> function input(prompt::String = "")::String 
> >> print(prompt) 
> >> return chomp(readline()) 
> >> end 
> >> 
> >> 
> >> 
> >> 
> >> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
> >> escribió: 
> >>> 
> >>> Hello, 
> >>> 
> >>> How could I input a data from the console? For instance, I would like 
> to 
> >>> make such that user is able to input the value of x. Is there any way 
> to do 
> >>> it like in Fortran or something? I can't find anything in 
> documentation. 
> >>> 
> >>> P.S. Also, I believe there is a way to input a string using readline() 
> >>> function. However, if I do something like: 
> >>> 
> >>> a = readline() 
> >>> "asd" 
> >>> 
> >>> then I will get "\"asd\"\r\n". 
> >>> 
> >>> How to avoid these excess symbols? 
> >>> 
> >>> Thank you in advance! 
>

Re: [julia-users] Re: Input a data from the console

[Yichao Yu]

On Fri, Oct 28, 2016 at 12:01 AM, Jeffrey Sarnoff
 wrote:
> And although readline() yields a String, if you are asking for, say, a Int
> or a Float64 value, you can add a second version of `input`:
>
> ```
> typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, Bool}
>
> """
> `input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T`
>
> Read an integer or a floating point value from STDIN.
>
> The prompt string, if given, is printed to standard output without a
> trailing newline before reading the input.
>
> days = input(Int, "How many days? ")
>
> """
> function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T
> print(prompt)
> str = chomp(readline())
> return parse(str)

Don't use `parse(::String)` for this. It is for parsing julia code,
not for parsing numbers. Use sth like `parse(Int, str)` intead.

> end
> ```
>
>
> On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas Castelló
> wrote:
>>
>> """
>> `input(prompt::String="")::String`
>>
>> Read a string from STDIN. The trailing newline is stripped.
>>
>> The prompt string, if given, is printed to standard output without a
>> trailing newline before reading input.
>> """
>> function input(prompt::String = "")::String
>> print(prompt)
>> return chomp(readline())
>> end
>>
>>
>>
>>
>> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev
>> escribió:
>>>
>>> Hello,
>>>
>>> How could I input a data from the console? For instance, I would like to
>>> make such that user is able to input the value of x. Is there any way to do
>>> it like in Fortran or something? I can't find anything in documentation.
>>>
>>> P.S. Also, I believe there is a way to input a string using readline()
>>> function. However, if I do something like:
>>>
>>> a = readline()
>>> "asd"
>>>
>>> then I will get "\"asd\"\r\n".
>>>
>>> How to avoid these excess symbols?
>>>
>>> Thank you in advance!

[julia-users] Re: Input a data from the console

[Jeffrey Sarnoff]

And although readline() yields a String, if you are asking for, say, a Int 
or a Float64 value, you can add a second version of `input`:

```
typealias ParseableNumber Union{Float64, Float32, Signed, Unsigned, Bool} 

"""
`input{T<:ParseableNumber}(::Type{T}, prompt::String="")::T`

Read an integer or a floating point value from STDIN.

The prompt string, if given, is printed to standard output without a
trailing newline before reading the input.

days = input(Int, "How many days? ")

"""
function input{T<:ParseableNumber}(::Type{T}, prompt::String = "")::T
print(prompt)
str = chomp(readline())
return parse(str)
end
```


On Thursday, October 27, 2016 at 1:47:27 PM UTC-4, Ismael Venegas Castelló 
wrote:
>
> """
> `input(prompt::String="")::String`
>
> Read a string from STDIN. The trailing newline is stripped.
>
> The prompt string, if given, is printed to standard output without a
> trailing newline before reading input.
> """
> function input(prompt::String = "")::String
> print(prompt)
> return chomp(readline())
> end
>
>
>
>
> El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
> escribió:
>>
>> Hello,
>>
>> How could I input a data from the console? For instance, I would like to 
>> make such that user is able to input the value of x. Is there any way to do 
>> it like in Fortran or something? I can't find anything in documentation.
>>
>> P.S. Also, I believe there is a way to input a string using readline() 
>> function. However, if I do something like:
>>
>> a = readline()
>> "asd"
>>
>> then I will get "\"asd\"\r\n".
>>
>> How to avoid these excess symbols?
>>
>> Thank you in advance!
>>
>

[julia-users] Re: Sparse arrays in Julia

[Júlio Hoffimann]

Actually, I don't think it makes very much sense, one could use a 
dictionary of tuples instead. Sparse 2D exist for a reason: efficient 
matrix multiplication, etc.

Disregard this email.

-Júlio

Em quinta-feira, 27 de outubro de 2016 17:07:01 UTC-7, Júlio Hoffimann 
escreveu:
>
> Hello,
>
> Is it possible to create a multidimensional sparse array in Julia?
>
> sparse() works for matrices, I wonder if someone can extend it to 
> multidimensional arrays. Where should I open a feature request?
>
> -Júlio
>

[julia-users] Sparse arrays in Julia

[Júlio Hoffimann]

Hello,

Is it possible to create a multidimensional sparse array in Julia?

sparse() works for matrices, I wonder if someone can extend it to 
multidimensional arrays. Where should I open a feature request?

-Júlio

Re: [julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

On 27 October 2016 at 23:33, digxx  wrote:

>
>
> Am Donnerstag, 27. Oktober 2016 23:00:48 UTC+2 schrieb Tommy Hofmann:
>>
>> There is a reason I asked to check for two libflint files three days ago.
>> I saw this error with the missing libflint-13.dll before. The ln command
>> can and will fail silently for various reasons.
>
>
> Maybe just to clarify, coz I found that weird too.
> Back then I ran Julia in cygwin (and I just tested again to see) becoz the
> file libflint-13.dll was present back then.
> When I start Julia in cygwin (I only tried via julia -p 4 - btw how do I
> start multiple processes in windows directly when I just have the icon?
>

You have to right click on it and edit it's properties.


> add -p 4 in the shortcut options??) and build Nemo after cloning it does
> create libflint-13.dll
>

However it is just 1kb and I didnt know (back then) it had to be an exact
> copy of libflint.dll
>

Ah, Cygwin must have created a symlink. Unfortunately these don't work on
Windows natively.


>

> When I run Julia terminal directly libflint-13.dll is not created at all.
>

That is odd, and we'll have to look into that.


>
> I wonder though now is why it doesnt really matter whether I build for 32
> Windows namley API=32 and i686 or for windows 64 API=64 and x86_64.
> Both seem to work, is that intended?
>

Both should work. If you use a 64 bit Julia executable it sould build the
64 bit version. Otherwise it should build the 32 bit version.

Bill.

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Am Donnerstag, 27. Oktober 2016 23:00:48 UTC+2 schrieb Tommy Hofmann:
>
> There is a reason I asked to check for two libflint files three days ago. 
> I saw this error with the missing libflint-13.dll before. The ln command 
> can and will fail silently for various reasons.


Maybe just to clarify, coz I found that weird too.
Back then I ran Julia in cygwin (and I just tested again to see) becoz the 
file libflint-13.dll was present back then.
When I start Julia in cygwin (I only tried via julia -p 4 - btw how do I 
start multiple processes in windows directly when I just have the icon? add 
-p 4 in the shortcut options??) and build Nemo after cloning it does create 
libflint-13.dll
However it is just 1kb and I didnt know (back then) it had to be an exact 
copy of libflint.dll
When I run Julia terminal directly libflint-13.dll is not created at all.

I wonder though now is why it doesnt really matter whether I build for 32 
Windows namley API=32 and i686 or for windows 64 API=64 and x86_64.
Both seem to work, is that intended?

[julia-users] Re: ANN: ParallelAccelerator v0.2 for Julia 0.5 released.

[Todd Anderson]

To answer your question #1, would the following be suitable?  There may be 
a couple details to work out but what about the general approach?

if haskey(Pkg.installed(), "ParallelAccelerator")
println("ParallelAccelerator present")

using ParallelAccelerator

macro PkgCheck(ast)
quote
@acc $(esc(ast))
end
end
else
println("ParallelAccelerator not present")

macro PkgCheck(ast)
return ast
end
end

@PkgCheck function f1(x)
x * 5
end

a = f1(10)
println("a = ", a)


2) The point of ParallelAccelerator is to extract the implicit parallelism 
automatically.  The purpose of @threads is to allow you to express 
parallelism explicitly.  So, they both enable parallelism but the former 
has the potential to be a lot easier to use particularly for scientific 
programmers who are more scientist than programmer.  In general, I feel 
there is room for all approaches to be supported across a range of 
programming ability.  

On Thursday, October 27, 2016 at 10:47:57 AM UTC-7, Chris Rackauckas wrote:
>
> Thank you for all of your amazing work. I will be giving v0.2 a try soon. 
> But I have two questions:
>
> 1) How do you see ParallelAccelerator integrating with packages? I asked 
> this in the chatroom, but I think having it here might be helpful for 
> others to chime in. If I want to use ParallelAccelerator in a package, then 
> it seems like I would have to require it (and make sure that every user I 
> have can compile it!) and sprinkle the macros around. Is there some 
> sensible way to be able to use ParallelAccelerator if it's available on the 
> user's machine, but not otherwise? This might be something that requires 
> Pkg3, but even with Pkg3 I don't see how to do this without having one 
> version of the function with a macro, and another without it.
>
> 2) What do you see as the future of ParallelAccelerator going forward? It 
> seems like Base Julia is stepping all over your domain: automated loop 
> fusing, multithreading, etc. What exactly does ParallelAccelerator give 
> that Base Julia does not or, in the near future, will not / can not? I am 
> curious because with Base Julia getting so many optimizations itself, it's 
> hard to tell whether supporting ParallelAccelerator will be a worthwhile 
> investment in a year or two, and wanted to know what you guys think of 
> that. I don't mean you haven't done great work: you clearly have, but it 
> seems Julia is also doing a lot of great work!
>
> On Tuesday, October 25, 2016 at 9:42:44 AM UTC-7, Todd Anderson wrote:
>>
>> The High Performance Scripting team at Intel Labs is pleased to announce 
>> the release of version 0.2 of ParallelAccelerator.jl, a package for 
>> high-performance parallel computing in Julia, primarily oriented around 
>> arrays and stencils.  In this release, we provide support for Julia 0.5 and 
>> introduce experimental support for the Julia native threading backend.  
>> While we still currently support Julia 0.4, such support should be 
>> considered deprecated and we recommend everyone move to Julia 0.5 as Julia 
>> 0.4 support may be removed in the future.
>>
>> The goal of ParallelAccelerator is to accelerate the computational kernel 
>> of an application by the programmer simply annotating the kernel function 
>> with the @acc (short for "accelerate") macro, provided by the 
>> ParallelAccelerator package.  In version 0.2, ParallelAccelerator still 
>> defaults to transforming the kernel to OpenMP C code that is then compiled 
>> with a system C compiler (ICC or GCC) and transparently handles the 
>> invocation of the C code from Julia as if the program were running normally.
>>
>> However, ParallelAccelerator v0.2 also introduces experimental backend 
>> support for Julia's native threading (which is also experimental).  To 
>> enable native threading mode, set the environment variable 
>> PROSPECT_MODE=threads.  In this mode, ParallelAccelerator identifies pieces 
>> of code that can be run in parallel and then runs that code as if it had 
>> been annotated with Julia's @threads and goes through the standard Julia 
>> compiler pipeline with LLVM.  The ParallelAccelerator C backend has the 
>> limitation that the kernel functions and anything called by those cannot 
>> include code that is not type-stable to a single type.  In particular, 
>> variables of type Any are not supported.  In practice, this restriction was 
>> a significant limitation.  For the native threading backend, no such 
>> restriction is necessary and thus our backend should handle arbitrary Julia 
>> code.
>>
>> Under the hood, ParallelAccelerator is essentially a domain-specific 
>> compiler written in Julia. It performs additional analysis and optimization 
>> on top of the Julia compiler. ParallelAccelerator discovers and exploits 
>> the implicit parallelism in source programs that use parallel programming 
>> patterns such as map, reduce, comprehension, and stencil. For example, 
>> 

Re: [julia-users] Re: Nemo AcbField error

[Tommy Hofmann]

There is a reason I asked to check for two libflint files three days ago. I saw 
this error with the missing libflint-13.dll before. The ln command can and will 
fail silently for various reasons.

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

*Home Free: no longer is getting Nemo's usefulness somewhere else and
costing you time.*

On Thu, Oct 27, 2016 at 4:27 PM, 'Bill Hart' via julia-users <
julia-users@googlegroups.com> wrote:

> Yes, we'll eventually get rid of the warnings. Technically we only fully
> support Julia-0.4 at the moment. However, Nemo is known to work with
> Julia-0.5 with some warnings.
>
> Thanks for persisting with it. I'm glad it is working for you now.
>
> We'll try to figure out how to stop this happening in future, so you don't
> have to go through this again!
>
> Bill.
>
> On 27 October 2016 at 21:39, digxx  wrote:
>
>>
>>
>> Am Donnerstag, 27. Oktober 2016 21:25:54 UTC+2 schrieb Jeffrey Sarnoff:
>>>
>>> You are home free!  Try arbfield(1) twice ..
>>>
>>
>> Yes I know the warning is gone I'm just wondering why it always shows up
>> the first time...
>>
>>
>> home free? in terms of homedir() or what you mean?
>>
>
>

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Tony Kelman]

Given that we're not going to change either llvm or libgit2 to use anything 
other than cmake, and other dependencies are increasingly adopting it as 
well, it's pretty much inevitable that we'll eventually use it if 
first-class MSVC support is ever going to happen. We're very much doing the 
wrong backwards thing by invoking cmake from gnu make, it's not designed 
for that workflow to do the right thing at all. I'm not surprised version 
upgrades confuse it.


On Thursday, October 27, 2016 at 7:27:08 AM UTC-7, Isaiah wrote:
>
> Or even better: let's remove a lot of complexity and move the whole Julia 
>> build system to CMake.
>
>
> The main advantage I see to CMake is support for Visual Studio. I would 
> not consider it a reduction of complexity -- CMake is very much like 
> regexes: now you have two problems. Or perhaps three...
>
> set(number_problems 3 FORCE CACHE PARENT_SCOPE)
>
> I think I saw an issue about this some time
>
>
> https://github.com/JuliaLang/julia/pull/11754
>
>
> On Thu, Oct 27, 2016 at 9:56 AM, Bart Janssens  > wrote:
>
>>
>> On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton > > wrote:
>>
>>>
 I'm not sure if there's any good way to introspect this and trigger a 
>>> reconfigure from Julia's build system without adding a lot of complexity.
>>>
>>
>> Or even better: let's remove a lot of complexity and move the whole Julia 
>> build system to CMake. I think I saw an issue about this some time, so I 
>> guess it's non-trivial, but I'd be willing to help.
>>
>
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Am Donnerstag, 27. Oktober 2016 22:27:52 UTC+2 schrieb Bill Hart:
>
> Yes, we'll eventually get rid of the warnings. Technically we only fully 
> support Julia-0.4 at the moment. However, Nemo is known to work with 
> Julia-0.5 with some warnings.
>
> Thanks for persisting with it. I'm glad it is working for you now.
>
> We'll try to figure out how to stop this happening in future, so you don't 
> have to go through this again!
>
> Bill.
>

I guess I have to thank you... 

Re: [julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

Yes, we'll eventually get rid of the warnings. Technically we only fully
support Julia-0.4 at the moment. However, Nemo is known to work with
Julia-0.5 with some warnings.

Thanks for persisting with it. I'm glad it is working for you now.

We'll try to figure out how to stop this happening in future, so you don't
have to go through this again!

Bill.

On 27 October 2016 at 21:39, digxx  wrote:

>
>
> Am Donnerstag, 27. Oktober 2016 21:25:54 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> You are home free!  Try arbfield(1) twice ..
>>
>
> Yes I know the warning is gone I'm just wondering why it always shows up
> the first time...
>
>
> home free? in terms of homedir() or what you mean?
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Am Donnerstag, 27. Oktober 2016 21:25:54 UTC+2 schrieb Jeffrey Sarnoff:
>
> You are home free!  Try arbfield(1) twice ..
>

Yes I know the warning is gone I'm just wondering why it always shows up 
the first time... 


home free? in terms of homedir() or what you mean?

Re: [julia-users] Re: Comprehension (generator) with statement IF and the number of true

[Steven G. Johnson]

On Thursday, October 27, 2016 at 1:23:47 PM UTC-4, DNF wrote:
>
> All higher-order functions? I thought it was mainly anonymous functions. 
> Either way, that's a seriously big slowdown.
>

All higher-order functions can benefit in Julia 0.5, not just anonymous 
functions.  Because each function now has its own type, calling a 
higher-order function like reduce(...) can now compile a specialized 
version for each function you pass it, which allows it to do things like 
inlining. 

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

You are home free!  Try arbfield(1) twice ..

On Thursday, October 27, 2016 at 3:22:39 PM UTC-4, digxx wrote:
>
>
>
> Am Donnerstag, 27. Oktober 2016 20:24:19 UTC+2 schrieb Bill Hart:
>>
>> It could well be libflint-13.dll is the problem. It's just a copy of the 
>> other flint dll, so you can make that any way you like. Just copy the file 
>> and rename the copy.
>>
>> As for the dll DependencyWalker claims is missing, I don't know what it 
>> does and it might not be relevant. We are mainly looking for dlls in the 
>> left hand pane that it says are missing that appear related to gcc, 
>> pthreads, arb, flint, gmp, mpfr, pari, arb, msys, etc. Anything that looks 
>> like an MS dll can probably be ignored.
>>
>> Bill.
>>
>
> I haven't tried the wget.exe proposal of jeffrey yet but it seems that the 
> libflint-13 (for whatever reason is the issue)
> now I get:
>
> julia> arbfield( 1 )
> WARNING: bytestring(p::Union{Ptr{Int8},Ptr{UInt8}}) is deprecated, use 
> unsafe_string(p) instead.
>  in depwarn(::String, ::Symbol) at .\deprecated.jl:64
>  in bytestring(::Ptr{UInt8}) at .\deprecated.jl:50
>  in show(::IOContext{Base.Terminals.TTYTerminal}, ::Nemo.arb) at 
> D:\Julia\v0.5\Nemo\src\arb\arb.jl:118
>  in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, 
> ::MIME{Symbol("text/plain")}, ::Nemo.arb) at .\REPL.jl:132
>  in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::Nemo.arb) 
> at .\REPL.jl:135
>  in display(::Nemo.arb) at .\multimedia.jl:143
>  in print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, 
> ::Bool, ::Void) at .\REPL.jl:154
>  in print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, 
> ::Bool) at .\REPL.jl:139
>  in 
> (::Base.REPL.##22#23{Bool,Base.REPL.##33#42{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState,
>  
> ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at .\REPL.jl:652
>  in run_interface(::Base.Terminals.TTYTerminal, 
> ::Base.LineEdit.ModalInterface) at .\LineEdit.jl:1579
>  in run_frontend(::Base.REPL.LineEditREPL, ::Base.REPL.REPLBackendRef) at 
> .\REPL.jl:903
>  in run_repl(::Base.REPL.LineEditREPL, ::Base.##932#933) at .\REPL.jl:188
>  in _start() at .\client.jl:360
> while loading no file, in expression starting on line 0
> 1.000 
>
>
> will the deprecated usage be changed in the future?
>
> @jeffrey: if I remove the libflint-13 again the error is back...try it 
> yourself. BTW is the wget.exe stuff u wrote still advisable to do or what 
> other advantages do I get out of it?
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Am Donnerstag, 27. Oktober 2016 20:24:19 UTC+2 schrieb Bill Hart:
>
> It could well be libflint-13.dll is the problem. It's just a copy of the 
> other flint dll, so you can make that any way you like. Just copy the file 
> and rename the copy.
>
> As for the dll DependencyWalker claims is missing, I don't know what it 
> does and it might not be relevant. We are mainly looking for dlls in the 
> left hand pane that it says are missing that appear related to gcc, 
> pthreads, arb, flint, gmp, mpfr, pari, arb, msys, etc. Anything that looks 
> like an MS dll can probably be ignored.
>
> Bill.
>

I haven't tried the wget.exe proposal of jeffrey yet but it seems that the 
libflint-13 (for whatever reason is the issue)
now I get:

julia> arbfield( 1 )
WARNING: bytestring(p::Union{Ptr{Int8},Ptr{UInt8}}) is deprecated, use 
unsafe_string(p) instead.
 in depwarn(::String, ::Symbol) at .\deprecated.jl:64
 in bytestring(::Ptr{UInt8}) at .\deprecated.jl:50
 in show(::IOContext{Base.Terminals.TTYTerminal}, ::Nemo.arb) at 
D:\Julia\v0.5\Nemo\src\arb\arb.jl:118
 in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, 
::MIME{Symbol("text/plain")}, ::Nemo.arb) at .\REPL.jl:132
 in display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::Nemo.arb) at 
.\REPL.jl:135
 in display(::Nemo.arb) at .\multimedia.jl:143
 in print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, 
::Bool, ::Void) at .\REPL.jl:154
 in print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, ::Bool) 
at .\REPL.jl:139
 in 
(::Base.REPL.##22#23{Bool,Base.REPL.##33#42{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState,
 
::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at .\REPL.jl:652
 in run_interface(::Base.Terminals.TTYTerminal, 
::Base.LineEdit.ModalInterface) at .\LineEdit.jl:1579
 in run_frontend(::Base.REPL.LineEditREPL, ::Base.REPL.REPLBackendRef) at 
.\REPL.jl:903
 in run_repl(::Base.REPL.LineEditREPL, ::Base.##932#933) at .\REPL.jl:188
 in _start() at .\client.jl:360
while loading no file, in expression starting on line 0
1.000 


will the deprecated usage be changed in the future?

@jeffrey: if I remove the libflint-13 again the error is back...try it 
yourself. BTW is the wget.exe stuff u wrote still advisable to do or what 
other advantages do I get out of it?

[julia-users] Re: ANN: ParallelAccelerator v0.2 for Julia 0.5 released.

[Viral Shah]

Not speaking on behalf of the ParallelAccelerator team - but the long term 
future of ParallelAccelerator in my opinion is to do exactly that - keep 
pushing on new things and get them (code or ideas) merged into Base as they 
stabilize. Without the ParallelAccelerator team pushing us, multi-threading 
would have moved much slower.

-viral

On Thursday, October 27, 2016 at 11:17:57 PM UTC+5:30, Chris Rackauckas 
wrote:
>
> Thank you for all of your amazing work. I will be giving v0.2 a try soon. 
> But I have two questions:
>
> 1) How do you see ParallelAccelerator integrating with packages? I asked 
> this in the chatroom, but I think having it here might be helpful for 
> others to chime in. If I want to use ParallelAccelerator in a package, then 
> it seems like I would have to require it (and make sure that every user I 
> have can compile it!) and sprinkle the macros around. Is there some 
> sensible way to be able to use ParallelAccelerator if it's available on the 
> user's machine, but not otherwise? This might be something that requires 
> Pkg3, but even with Pkg3 I don't see how to do this without having one 
> version of the function with a macro, and another without it.
>
> 2) What do you see as the future of ParallelAccelerator going forward? It 
> seems like Base Julia is stepping all over your domain: automated loop 
> fusing, multithreading, etc. What exactly does ParallelAccelerator give 
> that Base Julia does not or, in the near future, will not / can not? I am 
> curious because with Base Julia getting so many optimizations itself, it's 
> hard to tell whether supporting ParallelAccelerator will be a worthwhile 
> investment in a year or two, and wanted to know what you guys think of 
> that. I don't mean you haven't done great work: you clearly have, but it 
> seems Julia is also doing a lot of great work!
>
> On Tuesday, October 25, 2016 at 9:42:44 AM UTC-7, Todd Anderson wrote:
>>
>> The High Performance Scripting team at Intel Labs is pleased to announce 
>> the release of version 0.2 of ParallelAccelerator.jl, a package for 
>> high-performance parallel computing in Julia, primarily oriented around 
>> arrays and stencils.  In this release, we provide support for Julia 0.5 and 
>> introduce experimental support for the Julia native threading backend.  
>> While we still currently support Julia 0.4, such support should be 
>> considered deprecated and we recommend everyone move to Julia 0.5 as Julia 
>> 0.4 support may be removed in the future.
>>
>> The goal of ParallelAccelerator is to accelerate the computational kernel 
>> of an application by the programmer simply annotating the kernel function 
>> with the @acc (short for "accelerate") macro, provided by the 
>> ParallelAccelerator package.  In version 0.2, ParallelAccelerator still 
>> defaults to transforming the kernel to OpenMP C code that is then compiled 
>> with a system C compiler (ICC or GCC) and transparently handles the 
>> invocation of the C code from Julia as if the program were running normally.
>>
>> However, ParallelAccelerator v0.2 also introduces experimental backend 
>> support for Julia's native threading (which is also experimental).  To 
>> enable native threading mode, set the environment variable 
>> PROSPECT_MODE=threads.  In this mode, ParallelAccelerator identifies pieces 
>> of code that can be run in parallel and then runs that code as if it had 
>> been annotated with Julia's @threads and goes through the standard Julia 
>> compiler pipeline with LLVM.  The ParallelAccelerator C backend has the 
>> limitation that the kernel functions and anything called by those cannot 
>> include code that is not type-stable to a single type.  In particular, 
>> variables of type Any are not supported.  In practice, this restriction was 
>> a significant limitation.  For the native threading backend, no such 
>> restriction is necessary and thus our backend should handle arbitrary Julia 
>> code.
>>
>> Under the hood, ParallelAccelerator is essentially a domain-specific 
>> compiler written in Julia. It performs additional analysis and optimization 
>> on top of the Julia compiler. ParallelAccelerator discovers and exploits 
>> the implicit parallelism in source programs that use parallel programming 
>> patterns such as map, reduce, comprehension, and stencil. For example, 
>> Julia array operators such as .+, .-, .*, ./ are translated by 
>> ParallelAccelerator internally into data-parallel map operations over all 
>> elements of input arrays. For the most part, these patterns are already 
>> present in standard Julia, so programmers can use ParallelAccelerator to 
>> run the same Julia program without (significantly) modifying the source 
>> code.
>>
>> Version 0.2 should be considered an alpha release, suitable for early 
>> adopters and Julia enthusiasts.  Please file bugs at 
>> https://travis-ci.org/IntelLabs/ParallelAccelerator.jl/issues .
>>
>> See our GitHub repository at 
>> https://github.com/IntelL

[julia-users] Re: Writing a subset DataFrame to file is 220 times slower than saving the whole DataFrame

[Fred]

Wow ! Impressive difference, it is 100 time faster without sub() :


s = df[df[:rank_PV].<=r_max,:]
@time write_results(s, name, "significant", sep, h)
Saving... significant/Stat.csv
 0.704880 seconds (7.14 M allocations: 164.687 MB, 2.40% gc time)

s = sub(df, (df[:rank_PV] .<= r_max))
@time write_results(s, name, "significant", sep, h)
Saving...significant/Stat.csv
 86.797541 seconds (21.98 M allocations: 104.215 GB, 4.13% gc time)



Thanks Alex !

Re: [julia-users] Re: Nemo AcbField error

['Bill Hart' via julia-users]

It could well be libflint-13.dll is the problem. It's just a copy of the
other flint dll, so you can make that any way you like. Just copy the file
and rename the copy.

As for the dll DependencyWalker claims is missing, I don't know what it
does and it might not be relevant. We are mainly looking for dlls in the
left hand pane that it says are missing that appear related to gcc,
pthreads, arb, flint, gmp, mpfr, pari, arb, msys, etc. Anything that looks
like an MS dll can probably be ignored.

Bill.

On 27 October 2016 at 18:57, digxx  wrote:

> Actually:
> libflint-13.dll  14,156 KB
> is missing for me
>
> also is .git\
> under Nemo
>
>
> Am Donnerstag, 27. Oktober 2016 18:32:48 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> With 64-bit Win7, in my directory for Julia packages
>>
>> under Nemo:
>> .git\
>> benchmarks\
>> deps\
>> doc\
>> local\
>> src\
>> test\
>> .gitignore
>> .travis.yml
>> appveyor.yml
>> LICENSE.md
>> README.md
>> REQUIRE
>> todo.txt
>> windows_build.txt
>>
>> in deps:
>> antic\
>> arb\
>> flint2\
>> build.jl
>> mpfr-3.1.3.tar.bz2
>> mpir-2.7.2.tar.bz2
>> pari-2.7.4.tar.gz
>> patch-alloc-2.7.4
>>
>>
>> under local:
>> lib\
>>
>> in lib:
>> libarb.dll   22,350 KB
>> libflint.dll 14,156 KB
>> libflint-13.dll  14,156 KB
>> libpari.dll   6,067 KB
>> libgmp-16.dll   673 KB
>> libmpfr-4.dll   451 KB
>> libwinpthread-1.dll  84 KB
>>
>>
>>
>>
>> Note that windows_build.txt is preset for 32-bit Windows;
>> for 64-bit machines, windows_build.txt should be this:
>>
>> # start of file
>> # For Windows 64
>>
>> wget http://mpir.org/mpir-2.7.2.tar.bz2
>> tar -xvf mpir-2.7.2.tar.bz2
>> cd mpir-2.7.2
>> ./configure --enable-shared --disable-static --enable-gmpcompat
>> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
>> make -j
>> cd ..
>> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
>> tar -xvf mpfr-3.1.4.tar.bz2
>> cd mpfr-3.1.4
>> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared
>> --disable-static
>> make -j
>> cd ..
>> git clone https://github.com/wbhart/flint2
>> https://github.com/wbhart/antic
>> cd flint2
>> ./configure --enable-shared --disable-static
>> --with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4
>> --extensions=/home/user/antic
>> # edit Makefile
>> # in CLFAGS replace -ansi -pedantic with -std=c99
>> # add -mtune=core2 -march=core2 to CFLAGS
>> # add -I/home/User/flint2 to INCS
>> # ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared
>> -Wl,--export-all-symbols
>> make -j
>> cd ..
>> wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
>> tar -xvf pari-2.7.6.tar.gz
>> cd pari-2.7.6
>> export PATH=/home/user/mpir-2.7.2/.libs:$PATH
>> LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure
>> --with-gmp-include=/home/user/mpir-2.7.2 
>> --with-gmp-lib=/home/user/mpir-2.7.2/.libs
>> --host=x86_64-pc-mingw
>> cd Omingw-x86_64-pc
>> make gp
>> cd ../..
>>
>> # For Windows 32:
>>
>> # replace x86_64 with i686 throughout
>> # replace ABI=64 with ABI=32
>>
>> # end of file
>>
>>
>> On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>>>
>>> Actually, there is one more thing you could do. Download
>>> DependencyWalker [1] and run it on libarb.dll in place where it currently
>>> is in your Nemo/local/lib directory. It's bound to complain a lot, and
>>> there will be lots of yellow flags. But what we are looking for is missing
>>> dependencies that we are responsible for.
>>>
>>> Bill.
>>>
>>> [1] http://www.dependencywalker.com/
>>>
>>>
>>> On 27 October 2016 at 02:04, Bill Hart  wrote:
>>>
 The only thing I can think of to suggest is try it again from scratch
 in Julia-0.4 so we can rule out the dlls being corrupted on our website
 somehow.

 I can't think what else could be wrong, unless something else changed
 in Julia itself on Windows, between versions 0.4 and 0.5.

 Jeffrey, are you using 64 bit Windows with Julia 0.5?

 Bill.

 On 26 October 2016 at 23:02, digxx  wrote:

> It's weird coz in julia 0.4.x it was running without any problems...
>


>>>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

To see your path, open the terminal and type: Path
move the file wget64.exe, now given the name wget.exe to one of the 
directories in your path.

and maybe this will take: start Julia
Pkg.rm("Nemo")
Pkg.rm("Nemo")
Pkg.update()
Pkg.add("Nemo")
quit()
start Julia
Pkg.build("Nemo")
# let it finish correctly or otherwise
quit()
start Julia
Pkg.build("Nemo")
quit()
start Julia
using Nemo
arbfield64 = ArbField(64)
a = arbfield64( 1 )

if not, remove all of the Nemo package directory
then Pkg.update() and repeat


On Thursday, October 27, 2016 at 1:51:31 PM UTC-4, digxx wrote:
>
>
>
> Am Donnerstag, 27. Oktober 2016 19:33:22 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> libflint-13.dll appears to be a copy of libflint.dll with a different 
>> name and you can try copying libflint.dll to libflint-13.dll
>> The .git\ is not there because you have not tried to add then build Nemo 
>> with git becoming engaged, and that too is worthwhile doing.  
>> Double check that you have libgmp-16.dll and not some other version in 
>> that directory.
>>
>
> Well, how do I do that?
> I presume it's not just adding git to the Nemo directory ;)
>
>  
>

Re: [julia-users] Re: Trait for exactness of numbers

[Ismael Venegas Castelló]

I see thank you very much for your answer! :D

El martes, 25 de octubre de 2016, 13:20:50 (UTC-5), Tim Holy escribió:
>
> > Why not use dispatch instead?
>
> Because subtyping isn't powerful enough for all needs. For example:
>
>
> julia> using Unitful
>
> julia> const mm = u"mm"
> mm
>
> julia> isa(3.2mm, AbstractFloat)
> false
>
>
> You'd probably like to use the fancy logic of `FloatRange` if you're 
> constructing a range `3.2mm:0.1mm:4.8mm`, so the solution is to dispatch on 
> a trait that indicates that arithmetic isn't exact (which is what really is 
> going on inside that code anyway---who cares what kind of number type it 
> is).
>
> Best,
> --Tim
>
> On Tue, Oct 25, 2016 at 12:55 PM, Ismael Venegas Castelló <
> ismael...@gmail.com > wrote:
>
>> Why not use dispatch instead?
>>
>> isexact(::Integer) = true
>> isexact(::Rational) = true
>> isexact(x::Complex) = isexact(x.re)
>> isexact(::Any) = false
>
>
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Am Donnerstag, 27. Oktober 2016 19:33:22 UTC+2 schrieb Jeffrey Sarnoff:
>
> libflint-13.dll appears to be a copy of libflint.dll with a different name 
> and you can try copying libflint.dll to libflint-13.dll
> The .git\ is not there because you have not tried to add then build Nemo 
> with git becoming engaged, and that too is worthwhile doing.  
> Double check that you have libgmp-16.dll and not some other version in 
> that directory.
>

Well, how do I do that?
I presume it's not just adding git to the Nemo directory ;)

 

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

It may be helpful to download 
https://eternallybored.org/misc/wget/current/wget64.exe and copy it 
`wget.exe` then put that file somewhere in your Path (not in the Nemo 
subdirectories).



On Thursday, October 27, 2016 at 1:33:22 PM UTC-4, Jeffrey Sarnoff wrote:
>
> libflint-13.dll appears to be a copy of libflint.dll with a different name 
> and you can try copying libflint.dll to libflint-13.dll
> The .git\ is not there because you have not tried to add then build Nemo 
> with git becoming engaged, and that too is worthwhile doing.  
> Double check that you have libgmp-16.dll and not some other version in 
> that directory.
>
>
>
> On Thursday, October 27, 2016 at 12:57:57 PM UTC-4, digxx wrote:
>>
>> Actually:
>> libflint-13.dll  14,156 KB
>> is missing for me
>>
>> also is .git\
>> under Nemo
>>
>> Am Donnerstag, 27. Oktober 2016 18:32:48 UTC+2 schrieb Jeffrey Sarnoff:
>>>
>>> With 64-bit Win7, in my directory for Julia packages
>>>
>>> under Nemo:
>>> .git\
>>> benchmarks\
>>> deps\
>>> doc\
>>> local\
>>> src\
>>> test\
>>> .gitignore
>>> .travis.yml
>>> appveyor.yml
>>> LICENSE.md
>>> README.md
>>> REQUIRE
>>> todo.txt
>>> windows_build.txt
>>>
>>> in deps:
>>> antic\
>>> arb\
>>> flint2\
>>> build.jl
>>> mpfr-3.1.3.tar.bz2
>>> mpir-2.7.2.tar.bz2
>>> pari-2.7.4.tar.gz
>>> patch-alloc-2.7.4
>>>
>>>
>>> under local:
>>> lib\
>>>
>>> in lib:
>>> libarb.dll   22,350 KB
>>> libflint.dll 14,156 KB
>>> libflint-13.dll  14,156 KB
>>> libpari.dll   6,067 KB
>>> libgmp-16.dll   673 KB
>>> libmpfr-4.dll   451 KB
>>> libwinpthread-1.dll  84 KB
>>>
>>>
>>>
>>>
>>> Note that windows_build.txt is preset for 32-bit Windows;
>>> for 64-bit machines, windows_build.txt should be this:
>>>
>>> # start of file
>>> # For Windows 64
>>>
>>> wget http://mpir.org/mpir-2.7.2.tar.bz2
>>> tar -xvf mpir-2.7.2.tar.bz2
>>> cd mpir-2.7.2
>>> ./configure --enable-shared --disable-static --enable-gmpcompat 
>>> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
>>> make -j
>>> cd ..
>>> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
>>> tar -xvf mpfr-3.1.4.tar.bz2
>>> cd mpfr-3.1.4
>>> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
>>> --disable-static
>>> make -j
>>> cd ..
>>> git clone https://github.com/wbhart/flint2
>>> https://github.com/wbhart/antic
>>> cd flint2
>>> ./configure --enable-shared --disable-static 
>>> --with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
>>> --extensions=/home/user/antic
>>> # edit Makefile
>>> # in CLFAGS replace -ansi -pedantic with -std=c99
>>> # add -mtune=core2 -march=core2 to CFLAGS
>>> # add -I/home/User/flint2 to INCS
>>> # ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
>>> -Wl,--export-all-symbols
>>> make -j
>>> cd ..
>>> wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
>>> tar -xvf pari-2.7.6.tar.gz
>>> cd pari-2.7.6
>>> export PATH=/home/user/mpir-2.7.2/.libs:$PATH
>>> LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
>>> --with-gmp-include=/home/user/mpir-2.7.2 
>>> --with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
>>> cd Omingw-x86_64-pc
>>> make gp
>>> cd ../..
>>>
>>> # For Windows 32:
>>>
>>> # replace x86_64 with i686 throughout
>>> # replace ABI=64 with ABI=32
>>>
>>> # end of file
>>>
>>>
>>> On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:

 Actually, there is one more thing you could do. Download 
 DependencyWalker [1] and run it on libarb.dll in place where it currently 
 is in your Nemo/local/lib directory. It's bound to complain a lot, and 
 there will be lots of yellow flags. But what we are looking for is missing 
 dependencies that we are responsible for.

 Bill.

 [1] http://www.dependencywalker.com/


 On 27 October 2016 at 02:04, Bill Hart  
 wrote:

> The only thing I can think of to suggest is try it again from scratch 
> in Julia-0.4 so we can rule out the dlls being corrupted on our website 
> somehow.
>
> I can't think what else could be wrong, unless something else changed 
> in Julia itself on Windows, between versions 0.4 and 0.5.
>
> Jeffrey, are you using 64 bit Windows with Julia 0.5?
>
> Bill.
>
> On 26 October 2016 at 23:02, digxx  wrote:
>
>> It's weird coz in julia 0.4.x it was running without any problems...
>>
>
>

[julia-users] Re: ANN: ParallelAccelerator v0.2 for Julia 0.5 released.

[Chris Rackauckas]

Thank you for all of your amazing work. I will be giving v0.2 a try soon. 
But I have two questions:

1) How do you see ParallelAccelerator integrating with packages? I asked 
this in the chatroom, but I think having it here might be helpful for 
others to chime in. If I want to use ParallelAccelerator in a package, then 
it seems like I would have to require it (and make sure that every user I 
have can compile it!) and sprinkle the macros around. Is there some 
sensible way to be able to use ParallelAccelerator if it's available on the 
user's machine, but not otherwise? This might be something that requires 
Pkg3, but even with Pkg3 I don't see how to do this without having one 
version of the function with a macro, and another without it.

2) What do you see as the future of ParallelAccelerator going forward? It 
seems like Base Julia is stepping all over your domain: automated loop 
fusing, multithreading, etc. What exactly does ParallelAccelerator give 
that Base Julia does not or, in the near future, will not / can not? I am 
curious because with Base Julia getting so many optimizations itself, it's 
hard to tell whether supporting ParallelAccelerator will be a worthwhile 
investment in a year or two, and wanted to know what you guys think of 
that. I don't mean you haven't done great work: you clearly have, but it 
seems Julia is also doing a lot of great work!

On Tuesday, October 25, 2016 at 9:42:44 AM UTC-7, Todd Anderson wrote:
>
> The High Performance Scripting team at Intel Labs is pleased to announce 
> the release of version 0.2 of ParallelAccelerator.jl, a package for 
> high-performance parallel computing in Julia, primarily oriented around 
> arrays and stencils.  In this release, we provide support for Julia 0.5 and 
> introduce experimental support for the Julia native threading backend.  
> While we still currently support Julia 0.4, such support should be 
> considered deprecated and we recommend everyone move to Julia 0.5 as Julia 
> 0.4 support may be removed in the future.
>
> The goal of ParallelAccelerator is to accelerate the computational kernel 
> of an application by the programmer simply annotating the kernel function 
> with the @acc (short for "accelerate") macro, provided by the 
> ParallelAccelerator package.  In version 0.2, ParallelAccelerator still 
> defaults to transforming the kernel to OpenMP C code that is then compiled 
> with a system C compiler (ICC or GCC) and transparently handles the 
> invocation of the C code from Julia as if the program were running normally.
>
> However, ParallelAccelerator v0.2 also introduces experimental backend 
> support for Julia's native threading (which is also experimental).  To 
> enable native threading mode, set the environment variable 
> PROSPECT_MODE=threads.  In this mode, ParallelAccelerator identifies pieces 
> of code that can be run in parallel and then runs that code as if it had 
> been annotated with Julia's @threads and goes through the standard Julia 
> compiler pipeline with LLVM.  The ParallelAccelerator C backend has the 
> limitation that the kernel functions and anything called by those cannot 
> include code that is not type-stable to a single type.  In particular, 
> variables of type Any are not supported.  In practice, this restriction was 
> a significant limitation.  For the native threading backend, no such 
> restriction is necessary and thus our backend should handle arbitrary Julia 
> code.
>
> Under the hood, ParallelAccelerator is essentially a domain-specific 
> compiler written in Julia. It performs additional analysis and optimization 
> on top of the Julia compiler. ParallelAccelerator discovers and exploits 
> the implicit parallelism in source programs that use parallel programming 
> patterns such as map, reduce, comprehension, and stencil. For example, 
> Julia array operators such as .+, .-, .*, ./ are translated by 
> ParallelAccelerator internally into data-parallel map operations over all 
> elements of input arrays. For the most part, these patterns are already 
> present in standard Julia, so programmers can use ParallelAccelerator to 
> run the same Julia program without (significantly) modifying the source 
> code.
>
> Version 0.2 should be considered an alpha release, suitable for early 
> adopters and Julia enthusiasts.  Please file bugs at 
> https://travis-ci.org/IntelLabs/ParallelAccelerator.jl/issues .
>
> See our GitHub repository at 
> https://github.com/IntelLabs/ParallelAccelerator.jl for a complete list 
> of prerequisites, supported platforms, example programs, and documentation.
>
> Thanks to our colleagues at Intel and Intel Labs, the Julia team, and the 
> broader Julia community for their support of our efforts!
>
> Best regards,
> The High Performance Scripting team
> (Parallel Computing Lab, Intel Labs)
>

[julia-users] Re: Input a data from the console

[Ismael Venegas Castelló]

"""
`input(prompt::String="")::String`

Read a string from STDIN. The trailing newline is stripped.

The prompt string, if given, is printed to standard output without a
trailing newline before reading input.
"""
function input(prompt::String = "")::String
print(prompt)
return chomp(readline())
end




El jueves, 27 de octubre de 2016, 10:16:25 (UTC-5), Aleksandr Mikheev 
escribió:
>
> Hello,
>
> How could I input a data from the console? For instance, I would like to 
> make such that user is able to input the value of x. Is there any way to do 
> it like in Fortran or something? I can't find anything in documentation.
>
> P.S. Also, I believe there is a way to input a string using readline() 
> function. However, if I do something like:
>
> a = readline()
> "asd"
>
> then I will get "\"asd\"\r\n".
>
> How to avoid these excess symbols?
>
> Thank you in advance!
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

libflint-13.dll appears to be a copy of libflint.dll with a different name 
and you can try copying libflint.dll to libflint-13.dll
The .git\ is not there because you have not tried to add then build Nemo 
with git becoming engaged, and that too is worthwhile doing.  
Double check that you have libgmp-16.dll and not some other version in that 
directory.



On Thursday, October 27, 2016 at 12:57:57 PM UTC-4, digxx wrote:
>
> Actually:
> libflint-13.dll  14,156 KB
> is missing for me
>
> also is .git\
> under Nemo
>
> Am Donnerstag, 27. Oktober 2016 18:32:48 UTC+2 schrieb Jeffrey Sarnoff:
>>
>> With 64-bit Win7, in my directory for Julia packages
>>
>> under Nemo:
>> .git\
>> benchmarks\
>> deps\
>> doc\
>> local\
>> src\
>> test\
>> .gitignore
>> .travis.yml
>> appveyor.yml
>> LICENSE.md
>> README.md
>> REQUIRE
>> todo.txt
>> windows_build.txt
>>
>> in deps:
>> antic\
>> arb\
>> flint2\
>> build.jl
>> mpfr-3.1.3.tar.bz2
>> mpir-2.7.2.tar.bz2
>> pari-2.7.4.tar.gz
>> patch-alloc-2.7.4
>>
>>
>> under local:
>> lib\
>>
>> in lib:
>> libarb.dll   22,350 KB
>> libflint.dll 14,156 KB
>> libflint-13.dll  14,156 KB
>> libpari.dll   6,067 KB
>> libgmp-16.dll   673 KB
>> libmpfr-4.dll   451 KB
>> libwinpthread-1.dll  84 KB
>>
>>
>>
>>
>> Note that windows_build.txt is preset for 32-bit Windows;
>> for 64-bit machines, windows_build.txt should be this:
>>
>> # start of file
>> # For Windows 64
>>
>> wget http://mpir.org/mpir-2.7.2.tar.bz2
>> tar -xvf mpir-2.7.2.tar.bz2
>> cd mpir-2.7.2
>> ./configure --enable-shared --disable-static --enable-gmpcompat 
>> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
>> make -j
>> cd ..
>> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
>> tar -xvf mpfr-3.1.4.tar.bz2
>> cd mpfr-3.1.4
>> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
>> --disable-static
>> make -j
>> cd ..
>> git clone https://github.com/wbhart/flint2
>> https://github.com/wbhart/antic
>> cd flint2
>> ./configure --enable-shared --disable-static 
>> --with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
>> --extensions=/home/user/antic
>> # edit Makefile
>> # in CLFAGS replace -ansi -pedantic with -std=c99
>> # add -mtune=core2 -march=core2 to CFLAGS
>> # add -I/home/User/flint2 to INCS
>> # ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
>> -Wl,--export-all-symbols
>> make -j
>> cd ..
>> wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
>> tar -xvf pari-2.7.6.tar.gz
>> cd pari-2.7.6
>> export PATH=/home/user/mpir-2.7.2/.libs:$PATH
>> LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
>> --with-gmp-include=/home/user/mpir-2.7.2 
>> --with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
>> cd Omingw-x86_64-pc
>> make gp
>> cd ../..
>>
>> # For Windows 32:
>>
>> # replace x86_64 with i686 throughout
>> # replace ABI=64 with ABI=32
>>
>> # end of file
>>
>>
>> On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>>>
>>> Actually, there is one more thing you could do. Download 
>>> DependencyWalker [1] and run it on libarb.dll in place where it currently 
>>> is in your Nemo/local/lib directory. It's bound to complain a lot, and 
>>> there will be lots of yellow flags. But what we are looking for is missing 
>>> dependencies that we are responsible for.
>>>
>>> Bill.
>>>
>>> [1] http://www.dependencywalker.com/
>>>
>>>
>>> On 27 October 2016 at 02:04, Bill Hart  wrote:
>>>
 The only thing I can think of to suggest is try it again from scratch 
 in Julia-0.4 so we can rule out the dlls being corrupted on our website 
 somehow.

 I can't think what else could be wrong, unless something else changed 
 in Julia itself on Windows, between versions 0.4 and 0.5.

 Jeffrey, are you using 64 bit Windows with Julia 0.5?

 Bill.

 On 26 October 2016 at 23:02, digxx  wrote:

> It's weird coz in julia 0.4.x it was running without any problems...
>


>>>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

@Bill: it's telling me for example
EXT-MS-WIN-KERNEL32-QUIRKS-L1-1-1.DLL   error opening file. 
file not found

thats not what u mean, or?
Thats in the middle tab...
Additionally it says quite generally:
Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export 
function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.

Where should this be?

Re: [julia-users] Re: Comprehension (generator) with statement IF and the number of true

[DNF]

All higher-order functions? I thought it was mainly anonymous functions. 
Either way, that's a seriously big slowdown.

On Thursday, October 27, 2016 at 4:55:40 PM UTC+2, Steven G. Johnson wrote:
>
>
>
> On Wednesday, October 26, 2016 at 3:29:39 PM UTC-4, DNF wrote:
>>
>> Actually, I see only a very marginal performance difference between your 
>> mapeBase_v4 (the first v4, don't know about the second v4) and the loop 
>> version, roughly 10%. Not sure why you're seeing a big difference.
>>
>>>
> Perhaps he is using Julia 0.4 and you are using 0.5?  Higher-order 
> functions are much faster in 0.5.
>

[julia-users] Re: ANN: ParallelAccelerator v0.2 for Julia 0.5 released.

[Todd Anderson]

That's interesting.  I generally don't test with gcc  and my experiments 
with ICC/C have shown something like 20% slower for LLVM/native threads for 
some class of benchmarks (like blackscholes) but 2-4x slower for some other 
benchmarks (like laplace-3d).  The 20% may be attributable to ICC being 
better (including at vectorization like you mention) but certainly not the 
2-4x.  These larger differences are still under investigation.

I guess something we have said in the docs or our postings have created 
this impression that our performance gains are somehow related to MKL or 
blas in general.  If you have MKL then you can compile Julia to use it 
through its LLVM path.  ParallelAccelerator does not insert calls to MKL 
where they didn't exist in the incoming IR and I don't think ICC does 
either.  If MKL calls exist in the incoming IR then we don't modify them 
either.  

On Wednesday, October 26, 2016 at 7:51:33 PM UTC-7, Ralph Smith wrote:
>
> This is great stuff.  Initial observations (under Linux/GCC) are that 
> native threads are about 20% faster than OpenMP, so I surmise you are 
> feeding LLVM some very tasty
> code. (I tested long loops with straightforward memory access.)
>
> On the other hand, some of the earlier posts make me think that you were 
> leveraging the strong vector optimization of the Intel C compiler and its 
> tight coupling to
> MKL libraries.   If so, is there any prospect of getting LLVM to take 
> advantage of MKL?
>
>
> On Wednesday, October 26, 2016 at 8:13:38 PM UTC-4, Todd Anderson wrote:
>>
>> Okay, METADATA with ParallelAccelerator verison 0.2 has been merged so if 
>> you do a standard Pkg.add() or update() you should get the latest version.
>>
>> For native threads, please note that we've identified some issues with 
>> reductions and stencils that have been fixed and we will shortly be 
>> released in version 0.2.1.  I will post here again when that release takes 
>> place.
>>
>> Again, please give it a try and report back with experiences or file bugs.
>>
>> thanks!
>>
>> Todd
>>
>

Re: [julia-users] Re: Nemo AcbField error

[digxx]

Actually:
libflint-13.dll  14,156 KB
is missing for me

also is .git\
under Nemo

Am Donnerstag, 27. Oktober 2016 18:32:48 UTC+2 schrieb Jeffrey Sarnoff:
>
> With 64-bit Win7, in my directory for Julia packages
>
> under Nemo:
> .git\
> benchmarks\
> deps\
> doc\
> local\
> src\
> test\
> .gitignore
> .travis.yml
> appveyor.yml
> LICENSE.md
> README.md
> REQUIRE
> todo.txt
> windows_build.txt
>
> in deps:
> antic\
> arb\
> flint2\
> build.jl
> mpfr-3.1.3.tar.bz2
> mpir-2.7.2.tar.bz2
> pari-2.7.4.tar.gz
> patch-alloc-2.7.4
>
>
> under local:
> lib\
>
> in lib:
> libarb.dll   22,350 KB
> libflint.dll 14,156 KB
> libflint-13.dll  14,156 KB
> libpari.dll   6,067 KB
> libgmp-16.dll   673 KB
> libmpfr-4.dll   451 KB
> libwinpthread-1.dll  84 KB
>
>
>
>
> Note that windows_build.txt is preset for 32-bit Windows;
> for 64-bit machines, windows_build.txt should be this:
>
> # start of file
> # For Windows 64
>
> wget http://mpir.org/mpir-2.7.2.tar.bz2
> tar -xvf mpir-2.7.2.tar.bz2
> cd mpir-2.7.2
> ./configure --enable-shared --disable-static --enable-gmpcompat 
> --build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
> make -j
> cd ..
> wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
> tar -xvf mpfr-3.1.4.tar.bz2
> cd mpfr-3.1.4
> ./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
> --disable-static
> make -j
> cd ..
> git clone https://github.com/wbhart/flint2
> https://github.com/wbhart/antic
> cd flint2
> ./configure --enable-shared --disable-static 
> --with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
> --extensions=/home/user/antic
> # edit Makefile
> # in CLFAGS replace -ansi -pedantic with -std=c99
> # add -mtune=core2 -march=core2 to CFLAGS
> # add -I/home/User/flint2 to INCS
> # ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
> -Wl,--export-all-symbols
> make -j
> cd ..
> wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
> tar -xvf pari-2.7.6.tar.gz
> cd pari-2.7.6
> export PATH=/home/user/mpir-2.7.2/.libs:$PATH
> LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
> --with-gmp-include=/home/user/mpir-2.7.2 
> --with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
> cd Omingw-x86_64-pc
> make gp
> cd ../..
>
> # For Windows 32:
>
> # replace x86_64 with i686 throughout
> # replace ABI=64 with ABI=32
>
> # end of file
>
>
> On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>>
>> Actually, there is one more thing you could do. Download DependencyWalker 
>> [1] and run it on libarb.dll in place where it currently is in your 
>> Nemo/local/lib directory. It's bound to complain a lot, and there will be 
>> lots of yellow flags. But what we are looking for is missing dependencies 
>> that we are responsible for.
>>
>> Bill.
>>
>> [1] http://www.dependencywalker.com/
>>
>>
>> On 27 October 2016 at 02:04, Bill Hart  wrote:
>>
>>> The only thing I can think of to suggest is try it again from scratch in 
>>> Julia-0.4 so we can rule out the dlls being corrupted on our website 
>>> somehow.
>>>
>>> I can't think what else could be wrong, unless something else changed in 
>>> Julia itself on Windows, between versions 0.4 and 0.5.
>>>
>>> Jeffrey, are you using 64 bit Windows with Julia 0.5?
>>>
>>> Bill.
>>>
>>> On 26 October 2016 at 23:02, digxx  wrote:
>>>
 It's weird coz in julia 0.4.x it was running without any problems...

>>>
>>>
>>

[julia-users] Re: Writing a subset DataFrame to file is 220 times slower than saving the whole DataFrame

[Alex Mellnik]

I'm not sure what's wrong with sub, but don't use it -- it's definitely 
worse than just making a copy of the subset you want to write.  

s = df[df[:rank_PV].<=r_max,:]
@time write_results(s, name, "significant", sep, h)



On Thursday, October 27, 2016 at 5:07:31 AM UTC-7, Fred wrote:
>
> Hi,
>
> In the same program,  I save in a file a DataFrame "df" and a subset of 
> this DataFrame in another file. The problem I have is that saving the 
> subset is much slower than saving the entire DataFrame : 220 times slower. 
> It is too slow and I don't what is my mistake.
>
> Thank you for your advices !
>
> in Julia 0.4.5 : 
>
> Saving the entire DataFrame
> Saving... results/Stat.csv
> 1.115944 seconds (13.78 M allocations: 319.534 MB, 2.59% gc time)
>
>
> Saving the subset of the DataFrame 
> Saving... significant/Stat.csv
> 246.099835 seconds (41.79 M allocations: 376.189 GB, 4.77% gc time)
> elapsed time: 251.581459853 seconds
>
>
> in Julia 0.5 : 
>
> Saving the entire DataFrame
> Saving... results/Stat.csv
> 1.060365 seconds (7.08 M allocations: 116.025 MB, 0.73% gc time)
>
> Saving the subset of the DataFrame 
> Saving... significant/Stat.csv
> 226.813587 seconds (37.40 M allocations: 376.268 GB, 2.42% gc time)
> elapsed time: 232.95933586 seconds
>
> 
> # my function to save the results to a file
>
> function write_results(x, name, dir, sep, h)
>   outfile = "$dir/$name"
>   println("Saving...\t", outfile)
>   writetable( outfile, x, separator = sep, header = h)
> end
>
>
> # save my DataFrame df : very fast
> @time write_results(df, name, "results", sep, h)
>
>
> # subset DataFrame s
> s = sub(df, (df[:rank_PV] .<= r_max))
>
> # save my subset DataFrame s : incredibly slow !
>
> @time write_results(s, name, "significant", sep, h)
>
>
>

Re: [julia-users] Re: Nemo AcbField error

[Jeffrey Sarnoff]

With 64-bit Win7, in my directory for Julia packages

under Nemo:
.git\
benchmarks\
deps\
doc\
local\
src\
test\
.gitignore
.travis.yml
appveyor.yml
LICENSE.md
README.md
REQUIRE
todo.txt
windows_build.txt

in deps:
antic\
arb\
flint2\
build.jl
mpfr-3.1.3.tar.bz2
mpir-2.7.2.tar.bz2
pari-2.7.4.tar.gz
patch-alloc-2.7.4


under local:
lib\

in lib:
libarb.dll   22,350 KB
libflint.dll 14,156 KB
libflint-13.dll  14,156 KB
libpari.dll   6,067 KB
libgmp-16.dll   673 KB
libmpfr-4.dll   451 KB
libwinpthread-1.dll  84 KB




Note that windows_build.txt is preset for 32-bit Windows;
for 64-bit machines, windows_build.txt should be this:

# start of file
# For Windows 64

wget http://mpir.org/mpir-2.7.2.tar.bz2
tar -xvf mpir-2.7.2.tar.bz2
cd mpir-2.7.2
./configure --enable-shared --disable-static --enable-gmpcompat 
--build=core2-w64-mingw64 LDFLAGS=-static-libgcc ABI=64
make -j
cd ..
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.4.tar.bz2
tar -xvf mpfr-3.1.4.tar.bz2
cd mpfr-3.1.4
./configure --with-gmp-build=/home/User/mpir-2.7.2 --enable-shared 
--disable-static
make -j
cd ..
git clone https://github.com/wbhart/flint2
https://github.com/wbhart/antic
cd flint2
./configure --enable-shared --disable-static 
--with-mpir=/home/user/mpir-2.7.2 --with-mpfr=/home/user/mpfr-3.1.4 
--extensions=/home/user/antic
# edit Makefile
# in CLFAGS replace -ansi -pedantic with -std=c99
# add -mtune=core2 -march=core2 to CFLAGS
# add -I/home/User/flint2 to INCS
# ensure EXTRA_SHARED_FLAGS contains -static-libgcc -shared 
-Wl,--export-all-symbols
make -j
cd ..
wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.6.tar.gz
tar -xvf pari-2.7.6.tar.gz
cd pari-2.7.6
export PATH=/home/user/mpir-2.7.2/.libs:$PATH
LDFLAGS=-static-libgcc CFLAGS="-mtune=core2 -march=core2" ./Configure 
--with-gmp-include=/home/user/mpir-2.7.2 
--with-gmp-lib=/home/user/mpir-2.7.2/.libs --host=x86_64-pc-mingw
cd Omingw-x86_64-pc
make gp
cd ../..

# For Windows 32:

# replace x86_64 with i686 throughout
# replace ABI=64 with ABI=32

# end of file


On Wednesday, October 26, 2016 at 8:09:33 PM UTC-4, Bill Hart wrote:
>
> Actually, there is one more thing you could do. Download DependencyWalker 
> [1] and run it on libarb.dll in place where it currently is in your 
> Nemo/local/lib directory. It's bound to complain a lot, and there will be 
> lots of yellow flags. But what we are looking for is missing dependencies 
> that we are responsible for.
>
> Bill.
>
> [1] http://www.dependencywalker.com/
>
>
> On 27 October 2016 at 02:04, Bill Hart  > wrote:
>
>> The only thing I can think of to suggest is try it again from scratch in 
>> Julia-0.4 so we can rule out the dlls being corrupted on our website 
>> somehow.
>>
>> I can't think what else could be wrong, unless something else changed in 
>> Julia itself on Windows, between versions 0.4 and 0.5.
>>
>> Jeffrey, are you using 64 bit Windows with Julia 0.5?
>>
>> Bill.
>>
>> On 26 October 2016 at 23:02, digxx > 
>> wrote:
>>
>>> It's weird coz in julia 0.4.x it was running without any problems...
>>>
>>
>>
>

[julia-users] Re: Pkg.add("IJulia") fails

[bker]

Seems similar error to this 
thread: https://groups.google.com/d/msg/julia-users/-ZbGyFFPCm8/UByZrFoNBwAJ

I tried installing a compiler like the one guy said and that didn't seem to 
help :(

On Thursday, October 27, 2016 at 7:54:41 AM UTC-4, bker wrote:
>
> Windows 7 Professional. Tried the install on another computer on the same 
> network and it was fine so presumably it's not a blocked URL.
>
> On Wednesday, October 26, 2016 at 9:46:16 PM UTC-4, Tony Kelman wrote:
>>
>> What version of windows are you using?
>
>

[julia-users] [ANNOUNCE] TestSetExtensions.jl

[Spencer Russell]

Hey All,

I just registered the TestSetExtensions package, which collects some extensions 
and convenience utilities to maximize your testing enjoyment. It builds on the 
new Base.Test infrastructure in Julia v0.5 (also available in v0.4 with the 
BaseTestNext package). It's designed so that you shouldn't need to modify your 
tests at all if you're already using @testset and @test - all the interactions 
with this package happen at the top-level of your tests.

https://github.com/ssfrr/TestSetExtensions.jl 


Right now is supports two features:

Printing out green dots as your tests run so you can see them progressing
Collecting your test files and running them automatically so you don’t have to 
manually add them to `runtests.jl`, and also so you can easily specify a 
sub-set of your tests to run from the command line

I mostly wrote it to encapsulate the things I want for my tests, but I’m happy 
to take PRs for new features.

Please kick the tires and let me know if it works (or doesn’t work) for you!

ssfrr

[julia-users] Re: Input a data from the console

[Tomas Mikoviny]

it will be read as a string so you can skip the quotes..
to remove the ballast (single trailing newline from a string) use "chomp" 
function

julia> user_input = chomp(readline());
asd

julia> user_input
"asd"


On Thursday, October 27, 2016 at 5:16:25 PM UTC+2, Aleksandr Mikheev wrote:
>
> Hello,
>
> How could I input a data from the console? For instance, I would like to 
> make such that user is able to input the value of x. Is there any way to do 
> it like in Fortran or something? I can't find anything in documentation.
>
> P.S. Also, I believe there is a way to input a string using readline() 
> function. However, if I do something like:
>
> a = readline()
> "asd"
>
> then I will get "\"asd\"\r\n".
>
> How to avoid these excess symbols?
>
> Thank you in advance!
>

Re: [julia-users] Profile.print() options for easier reading of profile output data

[Mauro]

Lars and I once put a tool together which writes the info into a .pro
file, similar to memory profiling with a .mem file.  Never made it into
a PR but maybe of use:

https://github.com/mauro3/ProfileFile.jl

On Tue, 2016-10-25 at 23:36, Angel de Vicente  
wrote:
> Hi,
>
> I'm trying to profile a simple code I wrote that has just two
> functions. When I call Profile.print() I get a lot of detail about
> modules that (at least at this point) I'm not interested in profiling
> (in this case, for example the Primes module, and the REPL itself).
>
> ,
> | julia> Profile.print()
> | 97 ./event.jl:68; (::Base.REPL.##3#4{Base.REPL.REPLBackend})()
> |  97 ./REPL.jl:95; macro expansion
> |   97 ./REPL.jl:64; eval_user_input(::Any, ::Base.REPL.REPLBackend)
> |97 ./boot.jl:234; eval(::Module, ::Any)
> | 97 ./:?; anonymous
> |  97 ./profile.jl:16; macro expansion;
> |   69 /home/angelv/temp/p21.jl:8; p21(::Int64)
> |1  /home/angelv/temp/p21.jl:0; sumfactors(::Int64)
> |1  /home/angelv/temp/p21.jl:23; sumfactors(::Int64)
> | 1 ./abstractarray.jl:21; vect(::Int64, ::Vararg{Int64,N})
> |49 /home/angelv/temp/p21.jl:24; sumfactors(::Int64)
> | 1  ...v/.julia/v0.5/Primes/src/Primes.jl:246; factor!(::Int64, 
> ::Dict{Int64,Int64})
> |  1 ...v/.julia/v0.5/Primes/src/Primes.jl:154; isprime(::Int64)
> |   1 ...v/.julia/v0.5/Primes/src/Primes.jl:213; witnesses(::Int64)
> |1 .../.julia/v0.5/Primes/src/Primes.jl:210; _witnesses(::UInt64)
> | 1  ...v/.julia/v0.5/Primes/src/Primes.jl:252; factor!(::Int64, 
> ::Dict{Int64,Int64})
> | 1  ...v/.julia/v0.5/Primes/src/Primes.jl:254; factor!(::Int64, 
> ::Dict{Int64,Int64})
> |  1 ./dict.jl:692; get
> | ...
> `
>
> I think it would be nice to have three more options to the Profile.print
> function, which should not be difficult to implement:
>
> 1. to print percentages
> 2. to limit the output based on a list of regex
> 3. to be able to select the number of spaces added at each indentation
>level
>
> So, for example, I could make a call like
>
> julia> Profile.print(consider=[r"/home/angelv/temp]",percentage=true,indent=3)
> 71.10%69 /home/angelv/temp/p21.jl:8; p21(::Int64)
>01.00%1  /home/angelv/temp/p21.jl:0; sumfactors(::Int64)
>01.00%1  /home/angelv/temp/p21.jl:23; sumfactors(::Int64)
>50.50%49 /home/angelv/temp/p21.jl:24; sumfactors(::Int64)
>18.60%18 /home/angelv/temp/p21.jl:25; sumfactors(::Int64)
> 28.90%28 /home/angelv/temp/p21.jl:11; p21(::Int64)
>19.60%19 /home/angelv/temp/p21.jl:24; sumfactors(::Int64)
>06.20%6  /home/angelv/temp/p21.jl:25; sumfactors(::Int64)
>01.00%1  /home/angelv/temp/p21.jl:27; sumfactors(::Int64)
>
>
> This would make reading the profile data much simpler for when you are
> developing new code and are not interested in profiling other modules.
>
> Is this reasonable? Could this be implemented? (My proficiency with
> Julia is very basic right now, but if this is considered a useful
> addition, I could try to contribute with changes to profile.jl)
>
> Cheers,

[julia-users] Re: Input a data from the console

[Aleksandr Mikheev]

Okay, I accidentally figured the answer for the P.S. by myself. 

четверг, 27 октября 2016 г., 18:16:25 UTC+3 пользователь Aleksandr Mikheev 
написал:
>
> Hello,
>
> How could I input a data from the console? For instance, I would like to 
> make such that user is able to input the value of x. Is there any way to do 
> it like in Fortran or something? I can't find anything in documentation.
>
> P.S. Also, I believe there is a way to input a string using readline() 
> function. However, if I do something like:
>
> a = readline()
> "asd"
>
> then I will get "\"asd\"\r\n".
>
> How to avoid these excess symbols?
>
> Thank you in advance!
>

[julia-users] Input a data from the console

[Aleksandr Mikheev]

Hello,

How could I input a data from the console? For instance, I would like to 
make such that user is able to input the value of x. Is there any way to do 
it like in Fortran or something? I can't find anything in documentation.

P.S. Also, I believe there is a way to input a string using readline() 
function. However, if I do something like:

a = readline()
"asd"

then I will get "\"asd\"\r\n".

How to avoid these excess symbols?

Thank you in advance!

Re: [julia-users] 0.5 how to convert to Int

[Steven G. Johnson]

On Thursday, October 27, 2016 at 4:21:39 AM UTC-4, Ángel de Vicente wrote:
>
>
>
> program...@gmail.com  writes: 
>
> > BIG THX, but what about Float array ? 
>

round(Int, rand(5)) also works.  (In 0.6 this will probably be deprecated 
in favor of round.(Int, rand(5)) ...)

Re: [julia-users] Re: Comprehension (generator) with statement IF and the number of true

[Steven G. Johnson]

On Wednesday, October 26, 2016 at 3:29:39 PM UTC-4, DNF wrote:
>
> Actually, I see only a very marginal performance difference between your 
> mapeBase_v4 (the first v4, don't know about the second v4) and the loop 
> version, roughly 10%. Not sure why you're seeing a big difference.
>
>>
Perhaps he is using Julia 0.4 and you are using 0.5?  Higher-order 
functions are much faster in 0.5.

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Isaiah Norton]

>
> Or even better: let's remove a lot of complexity and move the whole Julia
> build system to CMake.


The main advantage I see to CMake is support for Visual Studio. I would not
consider it a reduction of complexity -- CMake is very much like regexes:
now you have two problems. Or perhaps three...

set(number_problems 3 FORCE CACHE PARENT_SCOPE)

I think I saw an issue about this some time


https://github.com/JuliaLang/julia/pull/11754


On Thu, Oct 27, 2016 at 9:56 AM, Bart Janssens 
wrote:

>
> On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton 
> wrote:
>
>>
>> I'm not sure if there's any good way to introspect this and trigger a
>> reconfigure from Julia's build system without adding a lot of complexity.
>>
>
> Or even better: let's remove a lot of complexity and move the whole Julia
> build system to CMake. I think I saw an issue about this some time, so I
> guess it's non-trivial, but I'd be willing to help.
>

[julia-users] Recursive data structures with Julia

[Angel de Vicente]

Hi,

I've been trying to implement some code to build Binary Search
Trees. The code below works, I'm able to build a tree and then print it
in ascending order, but it is quite ugly, with those Nullable types and
having to access subtrees with code like tree.value.left instead of
directly tree.left

Being used to nullify a pointer for this, I'm not sure how to best
proceed in Julia. Is there a better way to build recursive data
structures? 

(I read the section on "Incomplete Initialization" at
http://docs.julialang.org/en/release-0.5/manual/constructors/, but I'm
not sure I can use the idea in there, since I want some elements of the
tree to point to nothing, not to some other element in the tree.)

Many thanks,
Ángel de Vicente

,
| julia> include("bst.jl")
| b
| 
| julia> tree = b.build_bst([10,2,4,8,2])
| Dropping 2. No repeated values allowed
| 
Nullable{b.Bst}(b.Bst(10,b.Bst(2,#NULL,b.Bst(4,#NULL,b.Bst(8,#NULL,#NULL))),#NULL))
| 
| julia> b.print_bst(tree)
| 2
| 4
| 8
| 10
| 
| julia> 
`


,
| module b
| 
| type Bst
| val::Int
| left::Nullable{Bst}
| right::Nullable{Bst}
| end
| Bst(key::Int) = Bst(key, Nullable{Bst}(), Nullable{Bst}())  
| 
| "Given an array of Ints, it will create a BST tree, type: Nullable(Bst)"
| function build_bst(list::Array{Int,1})
| head = list[1]
| tree = Nullable(Bst(head))
| for e in list[2:end]
| place_bst(tree,e)
| end
| return tree
| end
| 
| "Adds element 'e' in the BST 'tree' (which cannot be a NULL BST)"
| function place_bst(tree::Nullable{Bst},e::Int)
| if e == tree.value.val
| println("Dropping $(e). No repeated values allowed")
| elseif e < tree.value.val
| if (isnull(tree.value.left)) 
| tree.value.left = Nullable(Bst(e))
| else
| place_bst(tree.value.left,e)
| end
| else
| if (isnull(tree.value.right)) 
| tree.value.right = Nullable(Bst(e))
| else
| place_bst(tree.value.right,e)
| end
| end
| end
| 
| "Prints a BST (does not accept a NULL BST as input)"
| function print_bst(tree::Nullable{Bst})
| if !isnull(tree.value.left) print_bst(tree.value.left) end
| println(tree.value.val)
| if !isnull(tree.value.right) print_bst(tree.value.right) end
| end
| 
| end
`

-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Bart Janssens]

On Thu, Oct 27, 2016 at 3:24 PM Isaiah Norton 
wrote:

>
> I'm not sure if there's any good way to introspect this and trigger a
> reconfigure from Julia's build system without adding a lot of complexity.
>

Or even better: let's remove a lot of complexity and move the whole Julia
build system to CMake. I think I saw an issue about this some time, so I
guess it's non-trivial, but I'd be willing to help.

[julia-users] Re: CoinOptServices

[Frank Kampas]

I removed CoinOptServices and WinRPM and was then able to add 
CoinOptServices

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Isaiah Norton]

>
> Thanks!  is there a way of doing it automatically and recursively until it
> finds the appropiate CMakeLists.txt file so I do not have to trawl for it? in
> addition, as it seems pretty simple I am surprised this does not happen
> ‘automagically’.


The generated Makefiles have absolute, symlink-resolved paths because CMake
doesn't want the version to change underneath (I guess?). But the cmake
binary itself is called back by make to detect whether a reconfiguration is
necessary. Hence this error.

I'm not sure if there's any good way to introspect this and trigger a
reconfigure from Julia's build system without adding a lot of complexity.
If you want to figure out which projects to reconfigure: `find
/path/to/julia -name *CMakeCache*`.

On Thu, Oct 27, 2016 at 3:46 AM, Federico Calboli 
wrote:

>
> > On 27 Oct 2016, at 10:34, Bart Janssens  wrote:
> >
> > Normally this is solved by running "cmake ." in the build directory or
> directories of the library or libraries compiled using cmake.
>
> Thanks!  is there a way of doing it automatically and recursively until it
> finds the appropiate CMakeLists.txt file so I do not have to trawl for it?
> in addition, as it seems pretty simple I am surprised this does not happen
> ‘automagically’.
>
> BW
>
> F
>
> >
> > Cheers,
> >
> > Bart
> >
> > On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli 
> wrote:
> > Hi, toady on a whim I tried
> >
> > make cleanall && make testall
> >
> > but it did not work because when julia was built cmake was at 3.6.1 and
> now it is a 3.6.2
> >
> > make[2]: /usr/local/Cellar/cmake/3.6.1/bin/cmake: No such file or
> directory
> > make[2]: *** [cmake_check_build_system] Error 1
> > make[1]: *** [/usr/local/julia/usr/lib/libmbedcrypto.dylib] Error 2
> > make: *** [julia-deps] Error 2
> >
> > Now I have:
> >
> > ../Cellar/cmake/3.6.2/bin/cmake
> >
> > This problem seems extremely silly, given that it forces me *not* to
> upgrade my cmake (and maybe other software), when the make routine could do
> the equivalent of `which cmake' and use the result.
> >
> > Leaving this aside, is there a way of rebuilding julia with the correct
> cmake without basically removing the whole thing and rebuilding from 0?
> >
> > BW
> >
> > F
>
>
>
>

[julia-users] Re: promote_op seems flakey (in a pure context)

[Jeffrey Sarnoff]

Do you have a minimal example?

On Tuesday, October 25, 2016 at 8:26:46 PM UTC-4, Andy Ferris wrote:
>
> I seem to be getting non-deterministic behaviour from `promote_op`, e.g. 
> where the output of the function is different at the REPL, in a function 
> and in a generated function.
>
> Inside the function generator it sometimes works to give the correct 
> result and sometimes returns `Any`. I haven't seen it fail at the REPL, but 
> I'm getting test failures in StaticArrays master because of this.
>
> I'm not sure if this is one of those "not valid in a pure context" (i.e. 
> `@pure` or `@generated`) functions as it's implementation seems to involve 
> inference and `Generator`s and so on. Or maybe it's a bug and I should file 
> a report?
>
> Thanks for any feedback,
> Andy
>

Re: [julia-users] Using -args to execute a function for different parameters

[Yichao Yu]

On Thu, Oct 27, 2016 at 8:48 AM,   wrote:
> Hi Josef,
>
> I shall paste a function that I used for my python files. Would it be okay
> if I asked you for some help to do the same in Julia? I've implemented most
> of the code but this still remains to be done in Julia and I wasn't aware
> such a package exists. Thanks a lot
>

https://github.com/carlobaldassi/ArgParse.jl

> def main(argv):
>
> parser = argparse.ArgumentParser(description='optimization')
>
> parser.add_argument( '-i', '--info',
>  action='store_true',
>dest='infoFlag',
>default=False,
>required=False,
>help='show transformation information' )
>
> parser.add_argument( '-o', '--output',
> action='store',
> dest='output',
> default="solution",
> help='output file name' )
>
> parser.add_argument( '-l', '--logPath',
> action='store',
> dest='logPath',
> default="",
> help='path where logfiles should be written' )
>
> parser.add_argument( '-p', '--singlePath',
>  action='store_true',
>dest='singlePath',
>default=False,
>required=False,
>help='unplittable flow problem flag' )
>
> parser.add_argument( '--lp',
>  action='store_true',
>dest='lp',
>default=False,
>required=False,
>help='flag for writing a lp file to
> .lp' )
>
> parser.add_argument(  '--xml',
>  action='store',
>dest='xmlInstance',
>metavar='xmlInstanceFilename',
>default=None,
>required=True,
>help='name of the xml instance file' )
>
> parser.add_argument(  '--nRC',
>  action='store_true',
>dest='noRoutingCosts',
>default=False,
>required=False,
>help='flag for disabeling link mapping costs' )
>
> parser.add_argument(  '--uEC',
>  action='store_true',
>dest='unitEdgeCosts',
>default=False,
>required=False,
>help='flag for unit edge costs' )
>
> global args
> args = parser.parse_args()
>
> global logFile
>
> if not args.xmlInstance:
> print "No instance file"
> return
>
> start = rtime.localtime()
> start = str(start[:6])[1:-1].replace(", ", "-")
>
> phy_network, demands = readXML(args.xmlInstance)
> logFile = open( args.logPath + "{}-{}.log".format(
> args.xmlInstance.split("/")[-1], start ), "w" )
>
> printLog("Start Time: {}".format( start ))
>
> solveProblem( phy_network, demands, args.output)
>
> end = rtime.localtime()
> printLog( "Log file closed at {}".format( str(end[:6])[1:-1].replace(",
> ", "-") ) )
>
> logFile.close()
> if __name__ == "__main__":
>   main(sys.argv[1:])
>
>
>
>
> On Thursday, 27 October 2016 14:30:10 UTC+2, Josef Sachs wrote:
>>
>> > On Thu, 27 Oct 2016 04:51:42 -0700 (PDT),  said:
>>
>> > Hello, I've been using Julia for a month probably and I would now
>> > like to execute a bash script containing a set of commands to run
>> > the same file for different arguments.
>>
>> Within Julia, you can inspect the global constant ARGS.
>> See http://docs.julialang.org/en/release-0.5/manual/getting-started/
>>
>> For something more sophisticated, see
>> https://github.com/carlobaldassi/ArgParse.jl

Re: [julia-users] Using -args to execute a function for different parameters

[varun7rs]

Hi Josef,

I shall paste a function that I used for my python files. Would it be okay 
if I asked you for some help to do the same in Julia? I've implemented most 
of the code but this still remains to be done in Julia and I wasn't aware 
such a package exists. Thanks a lot

def main(argv):

parser = argparse.ArgumentParser(description='optimization')
   
parser.add_argument( '-i', '--info',
 action='store_true',
   dest='infoFlag',
   default=False,
   required=False,
   help='show transformation information' )

parser.add_argument( '-o', '--output',
action='store',
dest='output',
default="solution",
help='output file name' ) 

parser.add_argument( '-l', '--logPath',
action='store',
dest='logPath',
default="",
help='path where logfiles should be written' ) 

parser.add_argument( '-p', '--singlePath',
 action='store_true',
   dest='singlePath',
   default=False,
   required=False,
   help='unplittable flow problem flag' )

parser.add_argument( '--lp',
 action='store_true',
   dest='lp',
   default=False,
   required=False,
   help='flag for writing a lp file to 
.lp' )

parser.add_argument(  '--xml',
 action='store',
   dest='xmlInstance',
   metavar='xmlInstanceFilename',
   default=None,
   required=True,
   help='name of the xml instance file' )

parser.add_argument(  '--nRC',
 action='store_true',
   dest='noRoutingCosts',
   default=False,
   required=False,
   help='flag for disabeling link mapping costs' )

parser.add_argument(  '--uEC',
 action='store_true',
   dest='unitEdgeCosts',
   default=False,
   required=False,
   help='flag for unit edge costs' )

global args
args = parser.parse_args()

global logFile

if not args.xmlInstance:
print "No instance file"
return 

start = rtime.localtime()
start = str(start[:6])[1:-1].replace(", ", "-") 

phy_network, demands = readXML(args.xmlInstance) 
logFile = open( args.logPath + "{}-{}.log".format( args.xmlInstance.
split("/")[-1], start ), "w" )

printLog("Start Time: {}".format( start )) 

solveProblem( phy_network, demands, args.output)

end = rtime.localtime()
printLog( "Log file closed at {}".format( str(end[:6])[1:-1].replace(", 
", "-") ) )

logFile.close()
if __name__ == "__main__":
  main(sys.argv[1:])




On Thursday, 27 October 2016 14:30:10 UTC+2, Josef Sachs wrote:
>
> > On Thu, 27 Oct 2016 04:51:42 -0700 (PDT),  > said: 
>
> > Hello, I've been using Julia for a month probably and I would now 
> > like to execute a bash script containing a set of commands to run 
> > the same file for different arguments. 
>
> Within Julia, you can inspect the global constant ARGS. 
> See http://docs.julialang.org/en/release-0.5/manual/getting-started/ 
>
> For something more sophisticated, see 
> https://github.com/carlobaldassi/ArgParse.jl 
>

Re: [julia-users] Using -args to execute a function for different parameters

[Josef Sachs]

> On Thu, 27 Oct 2016 04:51:42 -0700 (PDT),  said:

> Hello, I've been using Julia for a month probably and I would now
> like to execute a bash script containing a set of commands to run
> the same file for different arguments.

Within Julia, you can inspect the global constant ARGS.
See http://docs.julialang.org/en/release-0.5/manual/getting-started/

For something more sophisticated, see
https://github.com/carlobaldassi/ArgParse.jl

[julia-users] Writing a subset DataFrame to file is 220 times slower than saving the whole DataFrame

[Fred]

Hi,

In the same program,  I save in a file a DataFrame "df" and a subset of 
this DataFrame in another file. The problem I have is that saving the 
subset is much slower than saving the entire DataFrame : 220 times slower. 
It is too slow and I don't what is my mistake.

Thank you for your advices !

in Julia 0.4.5 : 

Saving the entire DataFrame
Saving... results/Stat.csv
1.115944 seconds (13.78 M allocations: 319.534 MB, 2.59% gc time)


Saving the subset of the DataFrame 
Saving... significant/Stat.csv
246.099835 seconds (41.79 M allocations: 376.189 GB, 4.77% gc time)
elapsed time: 251.581459853 seconds


in Julia 0.5 : 

Saving the entire DataFrame
Saving... results/Stat.csv
1.060365 seconds (7.08 M allocations: 116.025 MB, 0.73% gc time)

Saving the subset of the DataFrame 
Saving... significant/Stat.csv
226.813587 seconds (37.40 M allocations: 376.268 GB, 2.42% gc time)
elapsed time: 232.95933586 seconds


# my function to save the results to a file

function write_results(x, name, dir, sep, h)
  outfile = "$dir/$name"
  println("Saving...\t", outfile)
  writetable( outfile, x, separator = sep, header = h)
end


# save my DataFrame df : very fast
@time write_results(df, name, "results", sep, h)


# subset DataFrame s
s = sub(df, (df[:rank_PV] .<= r_max))

# save my subset DataFrame s : incredibly slow !

@time write_results(s, name, "significant", sep, h)

[julia-users] Re: Pkg.add("IJulia") fails

[bker]

Windows 7 Professional. Tried the install on another computer on the same 
network and it was fine so presumably it's not a blocked URL.

On Wednesday, October 26, 2016 at 9:46:16 PM UTC-4, Tony Kelman wrote:
>
> What version of windows are you using?

[julia-users] Using -args to execute a function for different parameters

[varun7rs]

Hello,
I've been using Julia for a month probably and I would now like to execute 
a bash script containing a set of commands to run the same file for 
different arguments.
The file myFile.jl contains calls to some functions to accomplish a task 
and this task needs to be rerun for different datasets which are input as 
csv files.
I want to realise something like the following. I need to run the same file 
for different datasets which are input as csv files. Python provides a 
-args option but I'm 
unaware of how to do this in Julia. I'd be very grateful for any 
assistance. 
Thank You

julia myFile.jl dataset1.csv
julia myFile.jl dataset2.csv
julia myFile.jl dataset3.csv
julia myFile.jl dataset4.csv
:
:
:

[julia-users] Re: ImageView very slow

[Josef Heinen]

Paul: Would be helpful to see the real data (file) you want to visualize 
and the plot you are expecting.

Re: [julia-users] 0.5 how to convert to Int

[Angel de Vicente]

programista...@gmail.com writes:

> BIG THX, but what about Float array ?

map(x->round(Int,x),rand(Bool,5))
map(x->round(Int,x),rand(5))

both do work.
-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

Re: [julia-users] 0.5 how to convert to Int

[programistawpf]

BIG THX, but what about Float array ?
julia> Int.(rand(Bool,10))
10-element Array{Int64,1}:
 1
 0
 1
 1
 1
 0
 1
 0
 0
 0

julia> Int.(rand(10))
ERROR: InexactError()
 in macro expansion at .\broadcast.jl:129 [inlined]
 in macro expansion at .\simdloop.jl:73 [inlined]
 in macro expansion at .\broadcast.jl:123 [inlined]
 in _broadcast!(::Type{Int64}, ::Array{Int64,1}, ::Tuple{Tuple{Bool}}, 
::Tuple{Tuple{Int64}}, ::Tuple
 ::Type{Val{1}}) at .\broadcast.jl:117
 in broadcast!(::Type{T}, ::Array{Int64,1}, ::Array{Float64,1}) at 
.\broadcast.jl:172
 in broadcast_t(::Type{T}, ::Type{T}, ::Array{Float64,1}, 
::Vararg{Array{Float64,1},N}) at .\broadcas
 in broadcast(::Type{T}, ::Array{Float64,1}) at .\broadcast.jl:230

W dniu czwartek, 27 października 2016 10:00:42 UTC+2 użytkownik Ángel de 
Vicente napisał:
>
> Hi, 
>
> program...@gmail.com  writes: 
>
> > in ver 0.5 how to convert to Int f.e bool or Float 
> > 
> > julia> int(rand(Bool,10)) 
> > ERROR: UndefVarError: int not defined 
> > 
> > julia> convert(Int64,rand(Bool,10)) 
> > ERROR: MethodError: Cannot `convert` an object of type Array{Bool,1} to 
> an 
> > object of type Int64 
> > This may have arisen from a call to the constructor Int64(...), 
> > since type constructors fall back to convert methods. 
> > 
>
> just learning Julia, so probably there are better ways, but this works: 
>
> , 
> | julia> VERSION 
> | v"0.5.0" 
> | 
> | julia> Int(rand(Bool)) 
> | 1 
> | 
> | julia> [Int(x) for x in rand(Bool,5)] 
> | 5-element Array{Int64,1}: 
> |  0 
> |  1 
> |  0 
> |  1 
> |  0 
> | 
> | julia> 
> ` 
>
> -- 
> Ángel de Vicente 
> http://www.iac.es/galeria/angelv/   
>

Re: [julia-users] 0.5 how to convert to Int

[Angel de Vicente]

Hi,

programista...@gmail.com writes:

> in ver 0.5 how to convert to Int f.e bool or Float
>
> julia> int(rand(Bool,10))
> ERROR: UndefVarError: int not defined
>
> julia> convert(Int64,rand(Bool,10))
> ERROR: MethodError: Cannot `convert` an object of type Array{Bool,1} to an
> object of type Int64
> This may have arisen from a call to the constructor Int64(...),
> since type constructors fall back to convert methods.
>

just learning Julia, so probably there are better ways, but this works:

,
| julia> VERSION
| v"0.5.0"
| 
| julia> Int(rand(Bool))
| 1
| 
| julia> [Int(x) for x in rand(Bool,5)]
| 5-element Array{Int64,1}:
|  0
|  1
|  0
|  1
|  0
| 
| julia> 
`

-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Federico Calboli]

> On 27 Oct 2016, at 10:46, Federico Calboli  wrote:
> 
> 
>> On 27 Oct 2016, at 10:34, Bart Janssens  wrote:
>> 
>> Normally this is solved by running "cmake ." in the build directory or 
>> directories of the library or libraries compiled using cmake.
> 
> Thanks!  is there a way of doing it automatically and recursively until it 
> finds the appropiate CMakeLists.txt file so I do not have to trawl for it?  
> in addition, as it seems pretty simple I am surprised this does not happen 
> ‘automagically’.

Actually I found where to run "cmake .” and it seems to work (even if I 
realised that I did not fix the utf8 library…).  In any case the fact I have to 
do by hand it is perplexing…

BW

F





> BW
> 
> F
> 
>> 
>> Cheers,
>> 
>> Bart
>> 
>> On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli  wrote:
>> Hi, toady on a whim I tried 
>> 
>> make cleanall && make testall
>> 
>> but it did not work because when julia was built cmake was at 3.6.1 and now 
>> it is a 3.6.2
>> 
>> make[2]: /usr/local/Cellar/cmake/3.6.1/bin/cmake: No such file or directory
>> make[2]: *** [cmake_check_build_system] Error 1
>> make[1]: *** [/usr/local/julia/usr/lib/libmbedcrypto.dylib] Error 2
>> make: *** [julia-deps] Error 2
>> 
>> Now I have:
>> 
>> ../Cellar/cmake/3.6.2/bin/cmake
>> 
>> This problem seems extremely silly, given that it forces me *not* to upgrade 
>> my cmake (and maybe other software), when the make routine could do the 
>> equivalent of `which cmake' and use the result.  
>> 
>> Leaving this aside, is there a way of rebuilding julia with the correct 
>> cmake without basically removing the whole thing and rebuilding from 0?
>> 
>> BW
>> 
>> F
> 
> 
> 

--
Federico Calboli
f.calb...@gmail.com

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Federico Calboli]

> On 27 Oct 2016, at 10:34, Bart Janssens  wrote:
> 
> Normally this is solved by running "cmake ." in the build directory or 
> directories of the library or libraries compiled using cmake.

Thanks!  is there a way of doing it automatically and recursively until it 
finds the appropiate CMakeLists.txt file so I do not have to trawl for it?  in 
addition, as it seems pretty simple I am surprised this does not happen 
‘automagically’.

BW

F

> 
> Cheers,
> 
> Bart
> 
> On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli  wrote:
> Hi, toady on a whim I tried 
> 
> make cleanall && make testall
> 
> but it did not work because when julia was built cmake was at 3.6.1 and now 
> it is a 3.6.2
> 
> make[2]: /usr/local/Cellar/cmake/3.6.1/bin/cmake: No such file or directory
> make[2]: *** [cmake_check_build_system] Error 1
> make[1]: *** [/usr/local/julia/usr/lib/libmbedcrypto.dylib] Error 2
> make: *** [julia-deps] Error 2
> 
> Now I have:
> 
> ../Cellar/cmake/3.6.2/bin/cmake
> 
> This problem seems extremely silly, given that it forces me *not* to upgrade 
> my cmake (and maybe other software), when the make routine could do the 
> equivalent of `which cmake' and use the result.  
> 
> Leaving this aside, is there a way of rebuilding julia with the correct cmake 
> without basically removing the whole thing and rebuilding from 0?
> 
> BW
> 
> F

Re: [julia-users] 0.5 how to convert to Int

[Mauro]

you must have missed Julia 0.4 which told you:

   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.7 (2016-09-18 16:17 UTC)
 _/ |\__'_|_|_|\__'_|  |
|__/   |  x86_64-pc-linux-gnu

julia> int(4.0)
WARNING: int(x::AbstractFloat) is deprecated, use round(Int,x) instead.
 in depwarn at deprecated.jl:73
 in int at deprecated.jl:50
while loading no file, in expression starting on line 0
4

On Thu, 2016-10-27 at 09:36, programista...@gmail.com wrote:
> in ver 0.5 how to convert to Int f.e bool or Float
>
> julia> int(rand(Bool,10))
> ERROR: UndefVarError: int not defined
>
> julia> convert(Int64,rand(Bool,10))
> ERROR: MethodError: Cannot `convert` an object of type Array{Bool,1} to an
> object of type Int64
> This may have arisen from a call to the constructor Int64(...),
> since type constructors fall back to convert methods.

Maybe the nicest now is



  _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0 (2016-09-19 18:14 UTC)
 _/ |\__'_|_|_|\__'_|  |
|__/   |  x86_64-pc-linux-gnu

julia> Int.(rand(Bool, 4))
4-element Array{Int64,1}:
 0
 1
 0
 1

[julia-users] 0.5 how to convert to Int

[programistawpf]

in ver 0.5 how to convert to Int f.e bool or Float

julia> int(rand(Bool,10))
ERROR: UndefVarError: int not defined

julia> convert(Int64,rand(Bool,10))
ERROR: MethodError: Cannot `convert` an object of type Array{Bool,1} to an 
object of type Int64
This may have arisen from a call to the constructor Int64(...),
since type constructors fall back to convert methods.

Paul

Re: [julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Bart Janssens]

Normally this is solved by running "cmake ." in the build directory or
directories of the library or libraries compiled using cmake.

Cheers,

Bart

On Thu, Oct 27, 2016 at 9:28 AM Federico Calboli 
wrote:

> Hi, toady on a whim I tried
>
> make cleanall && make testall
>
> but it did not work because when julia was built cmake was at 3.6.1 and
> now it is a 3.6.2
>
> make[2]: /usr/local/Cellar/cmake/3.6.1/bin/cmake: No such file or directory
> make[2]: *** [cmake_check_build_system] Error 1
> make[1]: *** [/usr/local/julia/usr/lib/libmbedcrypto.dylib] Error 2
> make: *** [julia-deps] Error 2
>
> Now I have:
>
> ../Cellar/cmake/3.6.2/bin/cmake
>
> This problem seems extremely silly, given that it forces me *not* to
> upgrade my cmake (and maybe other software), when the make routine could do
> the equivalent of `which cmake' and use the result.
>
> Leaving this aside, is there a way of rebuilding julia with the correct
> cmake without basically removing the whole thing and rebuilding from 0?
>
> BW
>
> F
>

[julia-users] automatically moving from cmake 3.6.1 to cmakex.y.z

[Federico Calboli]

Hi, toady on a whim I tried 

make cleanall && make testall

but it did not work because when julia was built cmake was at 3.6.1 and now 
it is a 3.6.2

make[2]: /usr/local/Cellar/cmake/3.6.1/bin/cmake: No such file or directory
make[2]: *** [cmake_check_build_system] Error 1
make[1]: *** [/usr/local/julia/usr/lib/libmbedcrypto.dylib] Error 2
make: *** [julia-deps] Error 2

Now I have:

../Cellar/cmake/3.6.2/bin/cmake

This problem seems extremely silly, given that it forces me *not* to 
upgrade my cmake (and maybe other software), when the make routine could do 
the equivalent of `which cmake' and use the result.  

Leaving this aside, is there a way of rebuilding julia with the correct 
cmake without basically removing the whole thing and rebuilding from 0?

BW

F

[julia-users] Re: ANN: ParallelAccelerator v0.2 for Julia 0.5 released.

[Jeffrey Sarnoff]

With appreciation for Intel Labs' commitment, our thanks to the people who 
landed v0.2 of the ParallelAccelerator project.

On Wednesday, October 26, 2016 at 8:13:38 PM UTC-4, Todd Anderson wrote:
>
> Okay, METADATA with ParallelAccelerator verison 0.2 has been merged so if 
> you do a standard Pkg.add() or update() you should get the latest version.
>
> For native threads, please note that we've identified some issues with 
> reductions and stencils that have been fixed and we will shortly be 
> released in version 0.2.1.  I will post here again when that release takes 
> place.
>
> Again, please give it a try and report back with experiences or file bugs.
>
> thanks!
>
> Todd
>