Is it possible to swap shift-enter for enter in IJulia?
At the moment I use Sublime for my Julia coding but despite using it for
months now I find shift-enter to execute to be a royal pain. No other
program I use does this. I don't mind it in my scripts but in the command
line I find it annoyin
Hi, I'm not sure what the right way to form the range -X:X is when X is
Uint64. It works as expected for smaller Uints
*julia> **Q = uint(4)*
*0x0004*
*julia> **M = 0x4*
*0x04*
*julia> **typeof(Q)*
*Uint64*
*julia> **typeof(M)*
*Uint8*
*julia> **[-1*M:M]*
*9-element Arra
Hi,
Is there any equivalent to accumarray() in
Julia? http://www.mathworks.com/help/matlab/ref/accumarray.html
-Júlio
Hello,
I was wondering if anybody would be open to sharing a room on the 28th June
night at the Hyatt Regency at Boston.
Thanks,
Ranjan
I asked this question a while ago. Has anybody tried to use the ArrayFire
library from Julia, or is anybody working on a wrapper? ArrayFire has
released version 3.
@pyimport ends up creating a closure (`pymember`) around the PyObject
handle (passed as 'o') for the module, here:
https://github.com/stevengj/PyCall.jl/blob/0823f7c08ae1fd8a82cd3fb8fa5ecb5623087864/src/PyCall.jl#L311-L328
I don't immediately see a way to get a reference to 'o' back out (it might
Indeed, that is exactly what I'm doing. I suspect Isaiah had the
mysql_query() API in mind, which is much easier to work with, but less
powerful.
Thanks everyone for your comments.
-- John
On Tuesday, June 2, 2015 at 1:57:50 PM UTC-7, Jameson wrote:
>
> @Isaiah I suspect the array referred to
I need to set a module level variable in a python module through PyCall. If
I use the `pyimport()` function I can successfully set the module variable
on the returned PyObject. Can I get access to this PyObject when using the
`@pyimport` macro instead?
I'm wondering what is the best way to do the equivalant with the
following in python.
```
In [1]: a = range(20)
In [2]: it = iter(a)
In [3]: for i in it:
if i == 10:
break
...:
In [4]: for i in it:
...: print(i)
...:
11
12
13
14
15
16
17
18
19
```
I know that I can call `st
Simon (and Tim),
Thanks for all the help! Everything in the package seems to be working
now. As always, feedback is welcome!
-- Steve Vavasis
On Sunday, May 31, 2015 at 10:09:29 PM UTC-4, vav...@uwaterloo.ca wrote:
>
> Following up on an earlier discussion that I started in this newsgroup, I
I'm not sure that an instrumenting debugger can be made to work well for
Julia, but maybe.
One issue is performance and what code you instrument. If you instrument
everything, then you'll get an impractical slowdown: `1+2` is defined in
Julia code – if you instrument everything, that becomes a fun
@Isaiah I suspect the array referred to is of type `MYSQL_BIND[]`, in which
case John is correct that declaring this as `Vector{MYSQL_BIND}` (where
`MYSQL_BIND` is an appropriated defined isbits type) should work exactly as
desired.
On Tue, Jun 2, 2015 at 11:09 AM John Myles White
wrote:
> I've
And as a tip, start creating a new package with Pkg.generate("Modifyfield",
"MIT") (or whatever license you choose)---it will initialize a very nice
"skeleton" for you. See more at
http://docs.julialang.org/en/latest/manual/packages/#package-development
--Tim
On Tuesday, June 02, 2015 01:34:11
I think there are other packages that achieve similar functionality, no?
On Tuesday, June 2, 2015 at 4:11:29 PM UTC-4, Iain Dunning wrote:
>
> Next versions of RobustStats? It looks like the developer has abandoned it
> so I don't think any more versions are coming.
> If you need the functionalit
On Tuesday, 2 June 2015 20:02:00 UTC+1, vav...@uwaterloo.ca wrote:
>
> Simon,
>
> I have deleted my old implementation of modifyField! and have now switched
> over to your implementation, which is really nice. Please view the latest
> commit:
>
> https://github.com/StephenVavasis/Modifyfield.j
Next versions of RobustStats? It looks like the developer has abandoned it
so I don't think any more versions are coming.
If you need the functionality it could be worthwhile making a fork of it
and getting it working on Julia 0.3 and later again.
Thanks,
Iain
On Tuesday, June 2, 2015 at 1:01:0
On Tuesday, June 2, 2015 at 11:09:51 AM UTC-4, John Myles White wrote:
>
> I've been fixing up the MySQL.jl package recently. To receive data on the
> client-side from prepared statements, I need to pass around an array of
> mutable structs, defined in MySQL C's API, so that C can populate thos
That approach should work fine. If you want to do the mutation in Julia,
the simplest (but slightly verbose) option is to use the immutable
constructor and replace the item in-place in the array. Or you can use
something like the modifyField function generator that Stephen Vavasis
recently posted (
Simon,
I have deleted my old implementation of modifyField! and have now switched
over to your implementation, which is really nice. Please view the latest
commit:
https://github.com/StephenVavasis/Modifyfield.jl
It is not quite working yet, and perhaps you can help. The issue is that
the m
Hi everyone,
I think the ideal debugger needs to do a combination of both,
instrumentation and DWARF-style debugging. The trade offs are very
different (instrumentation gives you easy access to variables, AST-level
stepping at the cost of performance of the instrumented code, while the
other gives
I don't think Debug was mentioned explicitly in your original post, but I see
you did say "navigate stack frames" and certainly Debug can't do that.
How exactly do you think that can be accomplished, without doing something
along the lines of what Keno is doing? I don't have the impression that
Ah! Works now! Thank you :)
Hoping that next versions will resolve such issues.
>
>
It looks like the Rmath dependency of RobustStats is the problem. If you
(temporarily, at least) remove RobustStats then Pkg.update may work again.
On Tue, Jun 2, 2015 at 12:32 PM, Huda Nassar wrote:
> Pkg.status() works fine. Here's what it prints:
>
> Pkg.update used to work, but I have recent
Pkg.status() works fine. Here's what it prints:
Pkg.update used to work, but I have recently updated my OS. I'm working on
OSX Yosemite version 10.10.3 now, but I doubt this is the reason.
And to answer your question, no I didn't update julia recently. The version
I'm using is 0.3.7
julia> P
Yes - but it hasn't gotten much attention over the last two years (and
sorry, I thought I had mentioned Debug.jl in my initial post).
https://github.com/toivoh/Debug.jl/graphs/code-frequency
Feels like there could be a lot of work there that would be tremendously
helpful, but not sure if people
On Jun 2, 2015 11:40 AM, "Stefan Karpinski" wrote:
>
> Oh, good stuff, Andreas – how'd you go about looking for this? Can you
open an issue about this? We should really make sure that all convert
methods are well-behaved.
It would be easier if the output of code_typed(convert,
Tuple{Type{Float32}
I'm not aware of any non-DWARF efforts aside from Debug.jl ... Curious to
know what you are proposing, though. I think you could actually get some
good mileage out of instrumenting `jl_apply` (this is basically how I use
gdb most of the time, except I isolate the function call I want to trap
first
Oh, good stuff, Andreas – how'd you go about looking for this? Can you open
an issue about this? We should really make sure that all convert methods
are well-behaved.
On Tue, Jun 2, 2015 at 11:25 AM, Andreas Noack wrote:
> The convert methods for Date.Period, Complex and Rational are inferred to
https://github.com/toivoh/Debug.jl
--Tim
On Tuesday, June 02, 2015 08:21:51 AM Michael Turok wrote:
> Right, but I'm interested in an debugger that would work without a custom
> compilation of LLVM, and would work with a stock release of julia 0.3*.
>
> On Tuesday, June 2, 2015 at 11:11:09 AM UT
The convert methods for Date.Period, Complex and Rational are inferred to
give Any. The problem in Period is because of the use of the value method
in line 4 of periods.jl. It extracts a field from an abstract type so even
though all subtypes in base have the specified field and have it defined
Right, but I'm interested in an debugger that would work without a custom
compilation of LLVM, and would work with a stock release of julia 0.3*.
On Tuesday, June 2, 2015 at 11:11:09 AM UTC-4, Isaiah wrote:
> https://groups.google.com/d/msg/julia-dev/gcZ5dZJni5o/VYaLkCd756cJ
>
> On Tue, Jun 2, 2
https://groups.google.com/d/msg/julia-dev/gcZ5dZJni5o/VYaLkCd756cJ
On Tue, Jun 2, 2015 at 11:07 AM, Michael Turok
wrote:
> Is there anyone currently focusing on building an AST-level debugger that
> can navigate stack frames and not require modifying code to insert
> instrumentation stubs, etc?
I've been fixing up the MySQL.jl package recently. To receive data on the
client-side from prepared statements, I need to pass around an array of mutable
structs, defined in MySQL C's API, so that C can populate those structs with
data from the server.
If helpful, an example of how this works i
Is there anyone currently focusing on building an AST-level debugger that
can navigate stack frames and not require modifying code to insert
instrumentation stubs, etc?
While the LLVM JIT debugger referenced in the below thread from December
2013 is interesting, seems like there might be more l
I have a querry, Can we submit updations in our proposal now ? How are we
supposed to mention the information about mentor ?
On Sunday, 31 May 2015 16:47:43 UTC+5:30, Rohit Kashyap wrote:
>
> Hi,
> Greetings to all mentors, I request you to go through this Proposal draft
> and submit your feedba
Hi Huda,
Without a little more information, it's a little unclear. Did you recently
upgrade from Julia 0.2 to 0.3? Can you give the output of Pkg.status()?
Cheers,
Kevin
On Mon, Jun 1, 2015 at 11:05 PM, Huda Nassar wrote:
> I think the following is self explanatory:
>
> julia> Pkg.update
I think I was channeling this line from the Style Guide section of the
manual when I made my earlier comment on preferring functions:
"""
Don’t overuse macros
Be aware of when a macro could really be a function instead.
"""
[then a sensible warning about not using @eval inside a macro]
But I supp
I think the following is self explanatory:
julia> Pkg.update()
INFO: Updating METADATA...
INFO: Updating cache of WoodburyMatrices...
INFO: Updating RobustStats...
INFO: Computing changes...
ERROR: Rmath can't be installed because it has no versions that support
0.3.7 of julia. You may need to up
On 2 June 2015 at 13:00, David Gold wrote:
> @Simon: why safer? Rather, what is unsafe about calling symbol within the
> Expr constructor?
I wasn't quite sure how the scoping worked (i.e. what would happen if
the type had not been exported?), but it does seem to be safe.
@Simon: why safer? Rather, what is unsafe about calling symbol within the Expr
constructor?
Also, this case is a pretty cool illustration of the usefulness of generated
functions. I've consistently found myself wishing I could somehow get a macro
to "dispatch" on the types of it's arguments.
It actually is still there, you just need to invoke it in a very strange
way... and it only works for Integer!
x = (&)(55)
will set x to 55...
On Tuesday, June 2, 2015 at 7:59:25 AM UTC+2, Steven G. Johnson wrote:
>
>
>
> On Monday, June 1, 2015 at 7:51:33 PM UTC+2, Scott Jones wrote:
>>
>> Thank
:-) Yes.
On Mon, Jun 1, 2015 at 9:25 AM, Scott Jones
wrote:
>
>
> On Monday, June 1, 2015 at 6:13:29 PM UTC+2, Kevin Squire wrote:
>>
>> FWIW, many libraries choose to use plural names, so that they can have
>> types within those libraries with singular names--e.g., DataFrames.jl has a
>> DataF
Actually, a slightly better form might be:
@generated function modify_field{g}(x, ::Type{Val{g}}, v)
F = fieldnames(x)
D = Any[:(x.$f) for f in F]
D[F .== g] = :v
Expr(:call, :call, x, D...)
end
This avoids the need to call symbol (I don't know if this could be a
problem, but it
An observation specific constant considered an "offset" which it looks like
GLM.jl supports. (reading the source code)
Stephen
On Monday, June 1, 2015 at 8:19:20 AM UTC-4, Patrick Kofod Mogensen wrote:
>
> I have a model which in principle fits in the models handled by GLM.jl. I
> want to esti
You could use the eltype function, but having thought more about it, I
think it might be easier (and more general) if you operate on the objects
instead of the container. Something like:
@generated function modify_field{g}(x, ::Type{Val{g}}, v)
F = fieldnames(x)
D = Any[:(x.$f) for f in
45 matches
Mail list logo
