I did implement an extremely hacky approach to force the type of an object
to change, and it may fail in some situations, but it works well enough:
https://github.com/malmaud/Autoreload.jl/blob/master/src/smart_types.jl#L288
On Sunday, June 7, 2015 at 11:53:03 AM UTC-4, Simon Byrne wrote:
No,
It seems a bit misleading to call that method simply unsafe when in
reality it is pretty much guaranteed to corrupt your entire application.
On Sun, Jun 7, 2015 at 1:13 PM Jonathan Malmaud malm...@gmail.com wrote:
I did implement an extremely hacky approach to force the type of an object
to
Swedish national traveling a lot, currently in Kenya, will arrive in
Stockholm next saturday.
Welcoming new connections both for sporadic meetings and larger gatherings,
gmail and fb: marcus.appelros
What is the application in which you intend to use such a feature?
On Saturday, June 6, 2015 at 6:49:53 PM UTC-4, andrew cooke wrote:
Is there any way to switch the visible type - the thing that is
dispatched on - at runtime?
For example, you might think that a Union() could do this, but
No, you can't change the type of an object.
You can however define types with fields that aren't constrained to be of a
concrete type: while this is worse for performance, it is occasionally
useful, e.g.
type A
a::Union(Void, Int)
end
A(nothing).a = 1
On Saturday, 6 June 2015 23:49:53
While a great many things in Fortran are compiler-dependent, practically
speaking well over 90% of the usage in the Julia ecosystem is going to be
with gfortran. The only reason anything in base Julia might work at all
with ifort on OSX or Linux is due to ifort having gone out of their way to
why do you ask?
On Sunday, 7 June 2015 10:35:10 UTC-3, David Gold wrote:
What is the application in which you intend to use such a feature?
On Saturday, June 6, 2015 at 6:49:53 PM UTC-4, andrew cooke wrote:
Is there any way to switch the visible type - the thing that is
dispatched on -
Just in case there is another solution that may work within the confines of
your application.
On Sunday, June 7, 2015 at 6:01:14 PM UTC-4, andrew cooke wrote:
why do you ask?
On Sunday, 7 June 2015 10:35:10 UTC-3, David Gold wrote:
What is the application in which you intend to use such
interesting. but really i was wondering if there was any way to do so that
worked within the type system (since presumably the jit would need to
emit new code).
seems not, which i guess isn't surprising.
thanks for the comments, everyone.
andrew
On Sunday, 7 June 2015 14:13:46 UTC-3,
interesting. but really i was wondering if there was any way to do so that
worked within the type system (since presumably the jit would need to
emit new code).
seems not, which i guess isn't surprising.
thanks for the comments, everyone.
andrew
On Sunday, 7 June 2015 14:13:46 UTC-3,
it wasn't a question about making a particular application work, thanks.
On Sunday, 7 June 2015 19:14:24 UTC-3, David Gold wrote:
Just in case there is another solution that may work within the confines
of your application.
On Sunday, June 7, 2015 at 6:01:14 PM UTC-4, andrew cooke wrote:
Not exactly what you're asking, but might you be looking for `invoke`?
--Tim
On Sunday, June 07, 2015 03:08:06 PM andrew cooke wrote:
interesting. but really i was wondering if there was any way to do so that
worked within the type system (since presumably the jit would need to
emit new
On Wednesday, June 3, 2015 at 10:05:11 AM UTC+8, Isaiah wrote:
I don't immediately see a way to get a reference to 'o' back out (it might
be useful to save a reference, and would be pretty simple to add that to
PyCall). However, there is a work-around -- do what you would do to find a
I'm skeptical that calling Fortran subroutines inside modules like this is
portable; the mangling is compiler-dependent, no?
(Even calling Fortran subroutines outside modules is compiler-dependent,
but thankfully most compilers these days use lowercase+underscore. Calling
Fortran functions
14 matches
Mail list logo
