[julia-users] PyCall and urllib2
What would be the right way to execute urllib2 call in julia
using PyCall
@pyimport urllib2 as urllib2
request = urllib2.Request(url, json_payload, "{'Content-Type':
'application/json'}")
type: apply: expected Function, got PyObject
while loading In[29], in expression starting on line 1
Thanks,
Dejan
Re: [julia-users] unexpected failure of type inferencing
Jameson,
If I understand your response correctly, the type warning on the first
snippet can be safely ignored.
Meanwhile, I misreported the type errors on the second snippet. In fact, I
made a mistake with my modules, and the second snippet was not loading the
correct version of keytype and datatype. After I fixed my error, both
snippets reported exactly the same type error (on sitofp). Sorry about
that. So the issue is resolved.
Thanks,
Steve Vavasis
On Saturday, July 18, 2015 at 8:46:46 PM UTC-4, Jameson wrote:
>
> Intrinsics.sitofp doesn't have a return type. It needs to be wrapped by a
> call to Intrinsics.box to actually get a return type assigned. There are a
> few places (such as sitofp) where the expr type doesn't matter, so type
> inference doesn't bother marking them. Unfortunately, code_warntype doesn't
> know that, so it highlights those places anyways.
>
>
> On Sat, Jul 18, 2015 at 8:39 PM > wrote:
>
>> I have developed a parameterized type called SortedDict, and a version of
>> the code recently developed is generating type warnings; I can't figure out
>> why. The type SortedDict is parameterized by K (key type), D (data type)
>> and Ord (ordering). Let s be of type SortedDict(ASCIIString, Float64,
>> Forward).
>>
>> The following snippet is generating a type warning when checked with
>> @code_warntype setindex1(s, 5, "c")
>>
>> function setindex1{K, D, Ord <: Ordering}(m::SortedDict{K,D,Ord}, d_, k_)
>> insert!(m.bt, convert(K,k_), convert(D,d_), false)
>> end
>>
>> on a call to Base.sitopf. As far as I know, this is a new problem (i.e.,
>> did not exist in previous versions of 0.4) Shouldn't the compiler know
>> that the result of Base.sitopf is of type Float64?
>>
>>
>> Meanwhile, the following snippet, which I thought would be equivalent, is
>> generating four type warning (according to @code_warntype setindex2(s, 5,
>> "c"): one on each 'convert' invocation and one on the invocations of
>> keytype and datatype each:
>>
>> @inline keytype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = K
>> @inline datatype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = D
>>
>> function setindex2(m::SortedDict, d_, k_)
>> insert!(m.bt, convert(keytype(m),k_), convert(datatype(m),d_), false)
>> end
>>
>> This is in Julia 0.4, 6-day-old master. Why is the type inferencing not
>> working as I would have expected?
>>
>> Thanks,
>> Steve Vavasis
>>
>>
Re: [julia-users] unexpected failure of type inferencing
Intrinsics.sitofp doesn't have a return type. It needs to be wrapped by a
call to Intrinsics.box to actually get a return type assigned. There are a
few places (such as sitofp) where the expr type doesn't matter, so type
inference doesn't bother marking them. Unfortunately, code_warntype doesn't
know that, so it highlights those places anyways.
On Sat, Jul 18, 2015 at 8:39 PM wrote:
> I have developed a parameterized type called SortedDict, and a version of
> the code recently developed is generating type warnings; I can't figure out
> why. The type SortedDict is parameterized by K (key type), D (data type)
> and Ord (ordering). Let s be of type SortedDict(ASCIIString, Float64,
> Forward).
>
> The following snippet is generating a type warning when checked with
> @code_warntype setindex1(s, 5, "c")
>
> function setindex1{K, D, Ord <: Ordering}(m::SortedDict{K,D,Ord}, d_, k_)
> insert!(m.bt, convert(K,k_), convert(D,d_), false)
> end
>
> on a call to Base.sitopf. As far as I know, this is a new problem (i.e.,
> did not exist in previous versions of 0.4) Shouldn't the compiler know
> that the result of Base.sitopf is of type Float64?
>
>
> Meanwhile, the following snippet, which I thought would be equivalent, is
> generating four type warning (according to @code_warntype setindex2(s, 5,
> "c"): one on each 'convert' invocation and one on the invocations of
> keytype and datatype each:
>
> @inline keytype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = K
> @inline datatype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = D
>
> function setindex2(m::SortedDict, d_, k_)
> insert!(m.bt, convert(keytype(m),k_), convert(datatype(m),d_), false)
> end
>
> This is in Julia 0.4, 6-day-old master. Why is the type inferencing not
> working as I would have expected?
>
> Thanks,
> Steve Vavasis
>
>
[julia-users] unexpected failure of type inferencing
I have developed a parameterized type called SortedDict, and a version of
the code recently developed is generating type warnings; I can't figure out
why. The type SortedDict is parameterized by K (key type), D (data type)
and Ord (ordering). Let s be of type SortedDict(ASCIIString, Float64,
Forward).
The following snippet is generating a type warning when checked with
@code_warntype setindex1(s, 5, "c")
function setindex1{K, D, Ord <: Ordering}(m::SortedDict{K,D,Ord}, d_, k_)
insert!(m.bt, convert(K,k_), convert(D,d_), false)
end
on a call to Base.sitopf. As far as I know, this is a new problem (i.e.,
did not exist in previous versions of 0.4) Shouldn't the compiler know
that the result of Base.sitopf is of type Float64?
Meanwhile, the following snippet, which I thought would be equivalent, is
generating four type warning (according to @code_warntype setindex2(s, 5,
"c"): one on each 'convert' invocation and one on the invocations of
keytype and datatype each:
@inline keytype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = K
@inline datatype{K,D,Ord <: Ordering}(m::SortedDict{K,D,Ord}) = D
function setindex2(m::SortedDict, d_, k_)
insert!(m.bt, convert(keytype(m),k_), convert(datatype(m),d_), false)
end
This is in Julia 0.4, 6-day-old master. Why is the type inferencing not
working as I would have expected?
Thanks,
Steve Vavasis
Re: [julia-users] Re: how should I assign load(filepathname, varname_string) to varname given as a string
I'll walk back a bit of what I said, since I'm not entirely clear on your
use case. You can use a macro such as:
@load z
where the definition of @load is:
macro load(s)
:( $(esc(s)) = load(joinpath(loadpath, $(string(s, ".jld" )
end
note that `z` in that case is taken as the literal symbol `:z`, and not the
value of the (non-existent) variable z.
If you are doing this in the global scope anyways, the following is perhaps
better style:
for z in [modules, list]
@eval $(symbol(z)) = load(joinpath(loadpath, $(string(s, ".jld" )
end
This code structure is used fairly often in base to generate methods, for
example.
If you don't have a precise list at compile-time, however, I think the dict
approach is better purely from an introspection standpoint for the user
(it's hard to document a non-static interface). But if the interface is
static, then the above examples should help you get started with embedding
external resources at compile-time.
On Sun, Jul 12, 2015 at 1:55 AM Jeffrey Sarnoff
wrote:
> Jameson, in v0.4 is it best not to care about adding a layer of
> consolidation that is purely artifact -- If so, well ok and yuk.
>
> Some of these named variables are better presented as Dicts of subDicts as
> that well reflects intrinsic intension.
> Other of these named variables are more as rooms in a house, they have
> proximity in common without commonality of purpose.
>
> Is there a way of doing as you suggest without forcing externally
> accessible data vectors to intradict?
>
>
> On Saturday, July 11, 2015 at 8:02:01 PM UTC-4, Jameson wrote:
>
>> A macro can't do this since it is strictly a pure source transform (it
>> cannot access values or variables). `eval` is essentially an escape hatch
>> to allow you to do anything, including this, but only in the global scope
>> (and it's generally not recommended).
>>
>> it was a design decision in julia not to allow this in local scope. there
>> are much better ways of solving the problem that don't cause issues for
>> type inference. I recommend the following solution (in v0.4 syntax):
>>
>> Dict{AbstractString, Any}( [ name => jld_load(joinpath(path, name*".jld))
>> for name in list ] )
>>
>> (not tested, so please forgive any typos)
>>
>>
>> On Sat, Jul 11, 2015 at 5:26 PM Scott Jones
>> wrote:
>>
>>> Why are you limiting it to an ASCIIString? variable names in Julia
>>> frequently have Unicode characters.
>>>
>>>
>>> On Saturday, July 11, 2015 at 4:06:43 PM UTC-4, Jeffrey Sarnoff wrote:
I have been trying to loop over variable names available as an
ASCIIString vector, using each to generate the corresponding jld datafile
path+name and load_ing() the datafile into its original variable name ..
should this be done with string->symbol manipulation and/or is a macro
required to effect an applicative assignment operator? I need some guidance
on how to do it.
>>>
Re: [julia-users] Re: Errors while trying to use cxx and embed Julia together
You are still picking up the f42... version.
On Jul 18, 2015 6:41 PM, "Kostas Tavlaridis-Gyparakis" <
kostas.tavlari...@gmail.com> wrote:
> So, in case it will be of any help to you here is the exact message I
> receive:
>
> julia> Pkg.build("Cxx")
> INFO: Building Cxx
> Tuning for julia installation at: /home/kostav/Julian/julia-f428392003/bin
> BuildBootstrap.Makefile:2:
> /home/kostav/Julian/julia-f428392003/bin/../../deps/Versions.make: No such
> file or directory
> BuildBootstrap.Makefile:3:
> /home/kostav/Julian/julia-f428392003/bin/../../Make.inc: No such file or
> directory
> make: *** No rule to make target
> '/home/kostav/Julian/julia-f428392003/bin/../../Make.inc'. Stop.
> =[ ERROR: Cxx
> ]=
>
> LoadError: failed process: Process(`make -f BuildBootstrap.Makefile
> JULIA_HOME=/home/kostav/Julian/julia-f428392003/bin`, ProcessExited(2)) [2]
> while loading /home/kostav/.julia/v0.4/Cxx/deps/build.jl, in expression
> starting on line 16
>
>
>
>
> [ BUILD ERRORS
> ]
>
> WARNING: Cxx had build errors.
>
> - packages with build errors remain installed in /home/kostav/.julia/v0.4
> - build the package(s) and all dependencies with `Pkg.build("Cxx")`
> - build a single package by running its `deps/build.jl` script
>
>
>
>
>
> On Saturday, July 18, 2015 at 11:35:32 PM UTC+2, Jeff Waller wrote:
>>
>>
>>
>> On Saturday, July 18, 2015 at 5:24:33 AM UTC-4, Kostas
>> Tavlaridis-Gyparakis wrote:
>>>
>>> Hello again and thanks a lot for the suggestions.
>>> Thing is, I went back to the source version of Julia where Cxx is
>>> already built and
>>> runs properly, so there wasn't much for me to do, I run in terminal also
>>> the command of:
>>>
>>> "addHeaderDir("/home/kostav/julia/src/")"
>>>
>>> Then proceeded again with make install and run the version of julia from
>>> this folder but
>>> still not being able to use or install Cxx. So, maybe I didn't
>>> understand properly what you
>>> were suggesting for me to do in the source version of Julia...
>>> Or maybe there is sth else I should try..?
>>>
>>
>> Well it's guesswork on my part, the exact failure would be helpful.
>> However, I'm going
>> to try to do this as well. Not exactly the thing you're doing but
>> related, you're more
>> familiar with Cxx, and I'm more familiar with embed, let's see what can
>> be done.
>>
>
[julia-users] Re: Errors while trying to use cxx and embed Julia together
So, in case it will be of any help to you here is the exact message I
receive:
julia> Pkg.build("Cxx")
INFO: Building Cxx
Tuning for julia installation at: /home/kostav/Julian/julia-f428392003/bin
BuildBootstrap.Makefile:2:
/home/kostav/Julian/julia-f428392003/bin/../../deps/Versions.make: No such
file or directory
BuildBootstrap.Makefile:3:
/home/kostav/Julian/julia-f428392003/bin/../../Make.inc: No such file or
directory
make: *** No rule to make target
'/home/kostav/Julian/julia-f428392003/bin/../../Make.inc'. Stop.
=[ ERROR: Cxx
]=
LoadError: failed process: Process(`make -f BuildBootstrap.Makefile
JULIA_HOME=/home/kostav/Julian/julia-f428392003/bin`, ProcessExited(2)) [2]
while loading /home/kostav/.julia/v0.4/Cxx/deps/build.jl, in expression
starting on line 16
[ BUILD ERRORS
]
WARNING: Cxx had build errors.
- packages with build errors remain installed in /home/kostav/.julia/v0.4
- build the package(s) and all dependencies with `Pkg.build("Cxx")`
- build a single package by running its `deps/build.jl` script
On Saturday, July 18, 2015 at 11:35:32 PM UTC+2, Jeff Waller wrote:
>
>
>
> On Saturday, July 18, 2015 at 5:24:33 AM UTC-4, Kostas
> Tavlaridis-Gyparakis wrote:
>>
>> Hello again and thanks a lot for the suggestions.
>> Thing is, I went back to the source version of Julia where Cxx is already
>> built and
>> runs properly, so there wasn't much for me to do, I run in terminal also
>> the command of:
>>
>> "addHeaderDir("/home/kostav/julia/src/")"
>>
>> Then proceeded again with make install and run the version of julia from
>> this folder but
>> still not being able to use or install Cxx. So, maybe I didn't understand
>> properly what you
>> were suggesting for me to do in the source version of Julia...
>> Or maybe there is sth else I should try..?
>>
>
> Well it's guesswork on my part, the exact failure would be helpful.
> However, I'm going
> to try to do this as well. Not exactly the thing you're doing but
> related, you're more
> familiar with Cxx, and I'm more familiar with embed, let's see what can be
> done.
>
[julia-users] Re: Errors while trying to use cxx and embed Julia together
On Saturday, July 18, 2015 at 5:24:33 AM UTC-4, Kostas Tavlaridis-Gyparakis
wrote:
>
> Hello again and thanks a lot for the suggestions.
> Thing is, I went back to the source version of Julia where Cxx is already
> built and
> runs properly, so there wasn't much for me to do, I run in terminal also
> the command of:
>
> "addHeaderDir("/home/kostav/julia/src/")"
>
> Then proceeded again with make install and run the version of julia from
> this folder but
> still not being able to use or install Cxx. So, maybe I didn't understand
> properly what you
> were suggesting for me to do in the source version of Julia...
> Or maybe there is sth else I should try..?
>
Well it's guesswork on my part, the exact failure would be helpful.
However, I'm going
to try to do this as well. Not exactly the thing you're doing but related,
you're more
familiar with Cxx, and I'm more familiar with embed, let's see what can be
done.
[julia-users] Extracting values from Array{ANY}
Hello I have a text file containing special characters, text and some numbers and I need to extract from it some values which appear every n-th row. Since the file has around 20k rows, I want the algorithm to find first and next rows. I've read text file to matrix with readdlm(), but the type of array is ANY, and findfirst() gives and error "access to undefined reference". Could you give me some guidance, please? Regards Mike
Re: [julia-users] Indexing Array with empty vector in v.0.4.
On Sat, Jul 18, 2015 at 6:00 AM, Felipe Jiménez
wrote:
> Say A is an Array, like A = [1 2 3 4], and I index it with an empty vector.
>
> In Julia v.0.3, A[[]] is empty. I find this convenient when programming.
>
> In Julia v.0.4, A[[]] throws an error.
>
> Is this intended? It sometimes forces me to code if isempty()... else...
The difference is that on 0.4, `[]` is a `Array{Any}`. Write `Int[]`
should work.
>
> My version is 0.4.0-dev+5841 (2015-07-07 14:58 UTC), Commit f428392* (10
> days old master), x86_64-w64-mingw32.
>
> Thank you.
[julia-users] Indexing Array with empty vector in v.0.4.
Say A is an Array, like A = [1 2 3 4], and I index it with an empty vector. In Julia v.0.3, A[[]] is empty. I find this convenient when programming. In Julia v.0.4, A[[]] throws an error. Is this intended? It sometimes forces me to code if isempty()... else... My version is 0.4.0-dev+5841 (2015-07-07 14:58 UTC), Commit f428392* (10 days old master), x86_64-w64-mingw32. Thank you.
[julia-users] Re: Errors while trying to use cxx and embed Julia together
Hello again and thanks a lot for the suggestions.
Thing is, I went back to the source version of Julia where Cxx is already
built and
runs properly, so there wasn't much for me to do, I run in terminal also
the command of:
"addHeaderDir("/home/kostav/julia/src/")"
Then proceeded again with make install and run the version of julia from
this folder but
still not being able to use or install Cxx. So, maybe I didn't understand
properly what you
were suggesting for me to do in the source version of Julia...
Or maybe there is sth else I should try..?
On Friday, July 17, 2015 at 10:31:16 PM UTC+2, Jeff Waller wrote:
>
>
>
> On Friday, July 17, 2015 at 1:44:41 PM UTC-4, Kostas Tavlaridis-Gyparakis
> wrote:
>>
>> Hello,
>> Just to be sure that I am understanding correctly what your proposal.
>> You suggest I should:
>>
>> 1) Completely uninstall Julia
>>
>
>
>> 2) Recompile the source code (i.e. run make)
>>
>
> heh no need for 1,2, the current source tree build should be fine.
>
>
>> 3) Then try using julia from the source code build cxx package
>>
>
> Yea like Isaiah says, originally this built by pointing to the source
> tree,
> it's still there.
>
>
>> 4) Then perform the make install and link the version of julia of the
>> decaxemical folder with my system
>> And hopefully this will work?
>>
>
> The tricky part. There's a reasonable change it will just work, and
> likewise there's a good
> chance it won't and it all revolves around what Cxx expects from Julia and
> does Julia make install
> copy whatever that is into the install directory.
>
>
>> I am just asking to be sure before I proceed with any attempt, as the
>> make command is really time con-
>> suming, so want first to be sure that I am doing what you are actually
>> suggesting (:
>>
>> On Friday, July 17, 2015 at 6:24:21 PM UTC+2, Jeff Waller wrote:
>>>
>>> Yea I think what you're seeing is that Cxx needs to use the source tree
>>> for example Make.inc only exists in the source tree while embedding
>>> assumes the installed tree.
>>>
>>> How to reconcile this the best way I'm not sure yet. I myself found Cxx
>>> interesting enough to try, but the build failed a couple of times and I
>>> haven't had a chance to pick it back up. But here's what I assume
>>> could be done.
>>>
>>> Don't attempt to do them at the same time but first Cxx (using source)
>>> and then embed second (using install).
>>>
>>> Build Cxx following the Cxx instructions.
>>>
>>> Then install (this is the tricky part and only something I can guess at
>>> right now). You might find that a number of things necessary for Cxx
>>> to function are not installed by default, or it will all go smoothly. I
>>> think
>>> though that Cxx is going to need clang in some way and that is definitely
>>> NOT installed by default. I'm not sure how much Julia must/can provide
>>> and how much the Cxx package can/must provide.
>>>
>>> Then build embed against installed stuff.
>>>
>>> Report errors, they may require multiple iterations.
>>>
>>
