Re: [julia-users] Re: calling sort on a range with rev=true

['Greg Plowman' via julia-users]

I think the problem here is that implementing sort(r::Range; 
rev::Bool=false), i.e. for keyword rev only, is that it would mean there is 
no definition for the other keyword arguments. Alternatively, if the other 
keywords were implemented for Range, then the method would not be 
type-stable. As Steven pointed out, sort(-5:5, by=abs) could not be 
represented by a Range.

Admittedly I was initially confused about dispatch with keyword 
arguments, and my understanding is still quite tenuous.
If what I'm saying makes sense then I don't think there is a case for 
filing an issue/PR?
 

On Friday, May 6, 2016 at 2:36:27 AM UTC+10, Milan Bouchet-Valat wrote:

> Le dimanche 01 mai 2016 à 19:11 -0700, 'Greg Plowman' via julia-users a 
> écrit : 
> > 
> > Extending/overwriting sort in range.jl (line 686) 
> > 
> > sort(r::Range) = issorted(r) ? r : reverse(r) 
> > 
> > with the following worked for me. 
> > 
> > function Base.sort(r::Range; rev::Bool=false) 
> > if rev 
> > issorted(r) ? reverse(r) : r 
> > else 
> > issorted(r) ? r : reverse(r) 
> > end 
> > end 
> Makes sense, please file an issue or a pull request (if the latter, be 
> sure to also add tests to prevent regressions). 
>
>
> Regards 
>

Re: [julia-users] Why does julia use END for block end?

[Kevin Squire]

Hi Didier,

Sorry to throw some cold water on your joke.  I half realized that it was a
joke at the end of your email.

One of the things we pride ourselves on is the welcoming nature of our
community.  We're not perfect, but we try pretty hard to keep conversation
respectful at the least. So when I or others see something that might be
construed as unwelcoming or disrespectful, we often speak up.

At this point, knowing you meant the message as a joke, I'd love to say
something snarky about lisp and parentheses... But the truth is I rather
like lisp. ;-)

Cheers!
   Kevin

On Saturday, May 7, 2016, Didier Verna  wrote:

> Kevin Squire > wrote:
>
> > That said, when it comes to opinions and holy wars, we very much like
> > it more peaceful around here.
>
>   That message was a joke, sorry if it was taken too seriously...
>
> --
> ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info
>

Re: [julia-users] Perhaps stupid question: Method type stability and throws

[Cedric St-Jean]

On Sat, May 7, 2016 at 2:19 PM, Yichao Yu  wrote:

> On Sat, May 7, 2016 at 1:21 PM, Cedric St-Jean 
> wrote:
> > Thank you for the detailed explanation!
> >
> > Would it make sense to run the catch blocks/finalizers before unwinding
> the
> > stack? I.e. each `try` pushes its catch/finally block as a "closure"
> onto a
> > separate stack, to be run when an exception occurs, then the stack is
> only
> > unwound once regular control flow is resumed, or collected if no handler
> was
> > found. I was wondering how Common Lisp was able to provide restarts, this
> > seems like a reasonable implementation strategy.
>
> Possibly related [1].
>

Yeah, that's the same idea. I don't care about restarts either, but in SBCL
(and... Python?) it made for a really nice debugger, since the stack isn't
unwound, and the debugger can just be a top-level `catch` block that
inspects the stack. I wonder how Gallium handles this.


> You probably want to do that **after** unwind the stack. Especially
> when you are throwing a stack overflow error for example =)
>

Judging by how undebuggable/unstable stack overflows in SBCL were, my
uneducated guess is that they ran the exception handlers *before* unwinding
the stack!


> The info you need should all be in the closure anyway.
>
> I think this would be mainly useful (avoiding a setjmp) for the try
> blocks with only finally (or a catch block that does not return) since
> otherwise you'll still need to restore the machine state in order to
> continue execution.
>
> Whether this can be implemented efficiently will also depend on if
> capture variable in closure can be implemented efficiently. (In
> general it's probably harder than issue 3 below)
>

Agreed. It may add an extra cost for every try block even on normal
execution...


> P.S. this is exactly how automatic unlocking of julia runtime locks
> are implemented[2]. Implemented for general julia code will be harder
> though.
>
> [1]
> https://groups.google.com/forum/#!searchin/julia-dev/Mason$20Bially/julia-dev/uTeuPv-DVKU/6T4JK3udAgAJ
> [2] https://github.com/JuliaLang/julia/pull/14451
>
> >
> > On Saturday, May 7, 2016 at 10:28:18 AM UTC-4, Yichao Yu wrote:
> >>
> >> On Sat, May 7, 2016 at 8:46 AM, Cedric St-Jean 
> >> wrote:
> >> >> mostly due to various technical reason
> >>
> >> In arbitrary order, the ones I can think of now.
> >>
> >> 1. We collect backtrace
> >>
> >> There are many cases where we don't actually need this info, but
> >> we need better code analysis to be able to figure that out.
> >>
> >> 2. We don't have zero cost exception frame so we need to spill many
> >> registers.
> >>
> >> It's hard for us to have zero cost exception frame unless all the
> >> C libraries are compiled with unwind info. Also note that zero cost
> >> exception frame means even more expensive exception throwing since the
> >> registers are not explicitly saved and we need to unwind the call
> >> stack to restore them. This is a trade off after all.
> >>
> >> 3. Preserving local variables across an exception requires spilling it
> >> to stack and this adds some hidden cost.
> >>
> >> It's a little hard to say how much cost this have, probably not
> >> THAT much unless you have a lot of variables that is modified in try
> >> and used after the exception is caught. Very likely strongly depending
> >> on the code pattern.
> >>
> >> 4. The GC frame allocation is global (well, per-function) instead of
> >> control flow local.
> >>
> >> This cause allocation in not-taken branch to affect the
> >> performance on the taken branch. This is not specific to exceptions
> >> but is particularly bad for exceptions since throwing one sometimes
> >> requires allocation that otherwise doesn't exist in the function (e.g.
> >> `ArgumentError("My error message with $variable spliced in")`) and
> >> these branches are meant to be not taken most of the time (if the
> >> error can happen most of the time, you'd be better off with a error
> >> code return, since exceptions are not designed for that).
> >>
> >> >
> >> > Could you please go into those? I'd like to understand why unwinding
> the
> >> > stack is costlier than returning from a function.
> >> >
> >> > On Saturday, May 7, 2016 at 8:38:03 AM UTC-4, Yichao Yu wrote:
> >> >>
> >> >> On Sat, May 7, 2016 at 6:58 AM, Ben Ward 
> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I have a question which may be laughable to CS people (be gentle,
> I'm
> >> >> > a
> >> >> > Biologist), but we know from guidelines that Julia performs best,
> >> >> > when a
> >> >> > method always returns the same type of value.
> >> >> > So the Julia type inference knows - ok, use this method with an
> Int,
> >> >> > it
> >> >> > will
> >> >> > always return a bool say. How does throws fit into this? To my mind
> >> >> > this
> >> >> > means the method used with an Int may return a bool, but it also
> may
> >> >> > result
> >> >> > 

Re: [julia-users] Why does julia use END for block end?

[Didier Verna]

Kevin Squire  wrote:

> That said, when it comes to opinions and holy wars, we very much like
> it more peaceful around here.

  That message was a joke, sorry if it was taken too seriously...

-- 
ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: Accessing "for" loop variable outside the loop

[Yichao Yu]

On Sat, May 7, 2016 at 2:40 PM, passerby51  wrote:
> OK, I found the asnwer here:
> https://en.wikibooks.org/wiki/Introducing_Julia/Controlling_the_flow#Loop_variables_and_scope
> But it seems that I couldn't find it in the manual. Maybe I didn't search
> well, but if it doesn't appear there it is worth mentioning it.

http://julia.readthedocs.io/en/latest/manual/variables-and-scoping/#soft-local-scope

Suggestions/PR to improve the doc are welcome.

>
> On Saturday, May 7, 2016 at 11:37:36 AM UTC-7, passerby51 wrote:
>>
>> I was trying to use the for loop variable outside it, after breaking out
>> of the loop, to see how many iterations were executed. But it seems to be
>> that the loop variable is not accessible outside the loop? Is that the case?
>> Does this apply to all the variables defined inside the loop?
>>
>

[julia-users] [ANN] Book: Julia High Performance

[Jeffrey Sarnoff]

Congratulations and Cheers, Avik.

[julia-users] Re: Accessing "for" loop variable outside the loop

[passerby51]

OK, I found the asnwer here:
https://en.wikibooks.org/wiki/Introducing_Julia/Controlling_the_flow#Loop_variables_and_scope
But it seems that I couldn't find it in the manual. Maybe I didn't search 
well, but if it doesn't appear there it is worth mentioning it.

On Saturday, May 7, 2016 at 11:37:36 AM UTC-7, passerby51 wrote:
>
> I was trying to use the for loop variable outside it, after breaking out 
> of the loop, to see how many iterations were executed. But it seems to be 
> that the loop variable is not accessible outside the loop? Is that the 
> case? Does this apply to all the variables defined inside the loop?
>
>

[julia-users] Accessing "for" loop variable outside the loop

[passerby51]

I was trying to use the for loop variable outside it, after breaking out of 
the loop, to see how many iterations were executed. But it seems to be that 
the loop variable is not accessible outside the loop? Is that the case? 
Does this apply to all the variables defined inside the loop?

[julia-users] Write immutable with variable-length array field to a stream

[Andrei Zh]

I work on implementing a binary protocol for a service. This protocol is 
based on messages - structs that support integer numbers, variable-length 
arrays and other structs, i.e. something we could implement in Julia as:

immutable Message1
version::Int16
length::Int32
payload::Array{Message2,1}
end

Creating a serializer for any such message is trivial, but I have about 50 
of them and would like to automate it, i.e. I'd like a generic way to write 
an immutable structure to a stream. So far the closest candidate is 
StrPack.jl , but it doesn't 
support variable-length array, which is the must for me. 

Do we have something for this or I should come up with my own 
function/macro? 

Re: [julia-users] Perhaps stupid question: Method type stability and throws

[Yichao Yu]

On Sat, May 7, 2016 at 1:21 PM, Cedric St-Jean  wrote:
> Thank you for the detailed explanation!
>
> Would it make sense to run the catch blocks/finalizers before unwinding the
> stack? I.e. each `try` pushes its catch/finally block as a "closure" onto a
> separate stack, to be run when an exception occurs, then the stack is only
> unwound once regular control flow is resumed, or collected if no handler was
> found. I was wondering how Common Lisp was able to provide restarts, this
> seems like a reasonable implementation strategy.

Possibly related [1].

You probably want to do that **after** unwind the stack. Especially
when you are throwing a stack overflow error for example =)
The info you need should all be in the closure anyway.

I think this would be mainly useful (avoiding a setjmp) for the try
blocks with only finally (or a catch block that does not return) since
otherwise you'll still need to restore the machine state in order to
continue execution.

Whether this can be implemented efficiently will also depend on if
capture variable in closure can be implemented efficiently. (In
general it's probably harder than issue 3 below)

P.S. this is exactly how automatic unlocking of julia runtime locks
are implemented[2]. Implemented for general julia code will be harder
though.

[1] 
https://groups.google.com/forum/#!searchin/julia-dev/Mason$20Bially/julia-dev/uTeuPv-DVKU/6T4JK3udAgAJ
[2] https://github.com/JuliaLang/julia/pull/14451

>
> On Saturday, May 7, 2016 at 10:28:18 AM UTC-4, Yichao Yu wrote:
>>
>> On Sat, May 7, 2016 at 8:46 AM, Cedric St-Jean 
>> wrote:
>> >> mostly due to various technical reason
>>
>> In arbitrary order, the ones I can think of now.
>>
>> 1. We collect backtrace
>>
>> There are many cases where we don't actually need this info, but
>> we need better code analysis to be able to figure that out.
>>
>> 2. We don't have zero cost exception frame so we need to spill many
>> registers.
>>
>> It's hard for us to have zero cost exception frame unless all the
>> C libraries are compiled with unwind info. Also note that zero cost
>> exception frame means even more expensive exception throwing since the
>> registers are not explicitly saved and we need to unwind the call
>> stack to restore them. This is a trade off after all.
>>
>> 3. Preserving local variables across an exception requires spilling it
>> to stack and this adds some hidden cost.
>>
>> It's a little hard to say how much cost this have, probably not
>> THAT much unless you have a lot of variables that is modified in try
>> and used after the exception is caught. Very likely strongly depending
>> on the code pattern.
>>
>> 4. The GC frame allocation is global (well, per-function) instead of
>> control flow local.
>>
>> This cause allocation in not-taken branch to affect the
>> performance on the taken branch. This is not specific to exceptions
>> but is particularly bad for exceptions since throwing one sometimes
>> requires allocation that otherwise doesn't exist in the function (e.g.
>> `ArgumentError("My error message with $variable spliced in")`) and
>> these branches are meant to be not taken most of the time (if the
>> error can happen most of the time, you'd be better off with a error
>> code return, since exceptions are not designed for that).
>>
>> >
>> > Could you please go into those? I'd like to understand why unwinding the
>> > stack is costlier than returning from a function.
>> >
>> > On Saturday, May 7, 2016 at 8:38:03 AM UTC-4, Yichao Yu wrote:
>> >>
>> >> On Sat, May 7, 2016 at 6:58 AM, Ben Ward  wrote:
>> >> > Hi,
>> >> >
>> >> > I have a question which may be laughable to CS people (be gentle, I'm
>> >> > a
>> >> > Biologist), but we know from guidelines that Julia performs best,
>> >> > when a
>> >> > method always returns the same type of value.
>> >> > So the Julia type inference knows - ok, use this method with an Int,
>> >> > it
>> >> > will
>> >> > always return a bool say. How does throws fit into this? To my mind
>> >> > this
>> >> > means the method used with an Int may return a bool, but it also may
>> >> > result
>> >> > in a type of (e.g.) ArgumentError getting thrown. So how do throws in
>> >> > functions affect performance and julian's ability to infer types and
>> >> > optimise code (if at all?)?
>> >>
>> >> While throwing or catching an error itself is slow (mostly due to
>> >> various technical reason) they shouldn't affect type stability.
>> >>
>> >> The type inference currently do not reason about what type of
>> >> exception can be thrown and even if it does, this won't affect what we
>> >> usually call the type stability of a function since it is only about
>> >> the **return type** of a function and throwing an error is not return
>> >> (in the sense that `a = cond ? error() : 1`, if the next statement is
>> >> executed, a is always a `Int`).
>> >>
>> >> >
>> >> > Thanks,
>> >> > Ben W.

Re: [julia-users] Perhaps stupid question: Method type stability and throws

[Cedric St-Jean]

Thank you for the detailed explanation!

Would it make sense to run the catch blocks/finalizers before unwinding the 
stack? I.e. each `try` pushes its catch/finally block as a "closure" onto a 
separate stack, to be run when an exception occurs, then the stack is only 
unwound once regular control flow is resumed, or collected if no handler 
was found. I was wondering how Common Lisp was able to provide restarts, 
this seems like a reasonable implementation strategy.

On Saturday, May 7, 2016 at 10:28:18 AM UTC-4, Yichao Yu wrote:
>
> On Sat, May 7, 2016 at 8:46 AM, Cedric St-Jean  > wrote: 
> >> mostly due to various technical reason 
>
> In arbitrary order, the ones I can think of now. 
>
> 1. We collect backtrace 
>
> There are many cases where we don't actually need this info, but 
> we need better code analysis to be able to figure that out. 
>
> 2. We don't have zero cost exception frame so we need to spill many 
> registers. 
>
> It's hard for us to have zero cost exception frame unless all the 
> C libraries are compiled with unwind info. Also note that zero cost 
> exception frame means even more expensive exception throwing since the 
> registers are not explicitly saved and we need to unwind the call 
> stack to restore them. This is a trade off after all. 
>
> 3. Preserving local variables across an exception requires spilling it 
> to stack and this adds some hidden cost. 
>
> It's a little hard to say how much cost this have, probably not 
> THAT much unless you have a lot of variables that is modified in try 
> and used after the exception is caught. Very likely strongly depending 
> on the code pattern. 
>
> 4. The GC frame allocation is global (well, per-function) instead of 
> control flow local. 
>
> This cause allocation in not-taken branch to affect the 
> performance on the taken branch. This is not specific to exceptions 
> but is particularly bad for exceptions since throwing one sometimes 
> requires allocation that otherwise doesn't exist in the function (e.g. 
> `ArgumentError("My error message with $variable spliced in")`) and 
> these branches are meant to be not taken most of the time (if the 
> error can happen most of the time, you'd be better off with a error 
> code return, since exceptions are not designed for that). 
>
> > 
> > Could you please go into those? I'd like to understand why unwinding the 
> > stack is costlier than returning from a function. 
> > 
> > On Saturday, May 7, 2016 at 8:38:03 AM UTC-4, Yichao Yu wrote: 
> >> 
> >> On Sat, May 7, 2016 at 6:58 AM, Ben Ward  wrote: 
> >> > Hi, 
> >> > 
> >> > I have a question which may be laughable to CS people (be gentle, I'm 
> a 
> >> > Biologist), but we know from guidelines that Julia performs best, 
> when a 
> >> > method always returns the same type of value. 
> >> > So the Julia type inference knows - ok, use this method with an Int, 
> it 
> >> > will 
> >> > always return a bool say. How does throws fit into this? To my mind 
> this 
> >> > means the method used with an Int may return a bool, but it also may 
> >> > result 
> >> > in a type of (e.g.) ArgumentError getting thrown. So how do throws in 
> >> > functions affect performance and julian's ability to infer types and 
> >> > optimise code (if at all?)? 
> >> 
> >> While throwing or catching an error itself is slow (mostly due to 
> >> various technical reason) they shouldn't affect type stability. 
> >> 
> >> The type inference currently do not reason about what type of 
> >> exception can be thrown and even if it does, this won't affect what we 
> >> usually call the type stability of a function since it is only about 
> >> the **return type** of a function and throwing an error is not return 
> >> (in the sense that `a = cond ? error() : 1`, if the next statement is 
> >> executed, a is always a `Int`). 
> >> 
> >> > 
> >> > Thanks, 
> >> > Ben W. 
>

Re: [julia-users] Why does julia use END for block end?

[Kevin Squire]

Hi Didier,

I appreciate your recent interest in Julia, and especially that you've
uncovered a few inconsistencies/bugs that have been addressed, and I've
found many of your questions thought provoking.

That said, when it comes to opinions and holy wars, we very much like it
more peaceful around here.  Specifically, we discourage things like calling
someone's opinion "wrong" or "mistaken".  It's certainly ok to disagree,
but please do so respectfully.

Facts, of course, are subject to verification. ;-)

(I realize that much of what you wrote was tongue in cheek, and I'm not
taking exception with what you wrote--just how it was said.)

Cheers,
   Kevin

On Saturday, May 7, 2016, Didier Verna  wrote:

> DNF > wrote:
>
> > It is very clear and explicit, there is no doubt as to what it means,
> > unlike '}' which is way too small and ambiguous (does it mean end of
> > block, or end of dict definition, etc.), and just does not jump out at
> > you the way it should.
>
>   'end' is extremely verbose, just like 'function', 'global', 'local' etc.
>
>   You are also wrong about the curly brace's ambiguity. If you find it
>   ambiguous, that is because you live in a world overflown with
>   syntax. You don't need end of blocks or dict definitions to be
>   different things. You only really need an end of /expression/. And
>   BTW, I have a hard time figuring out why 'end' wouldn't be ambiguous
>   while '}' would be, especially since 'end' ends so many different
>   things in Julia.
>
>   Finally you are also mistaken about the size (yes, size matters). The
>   curly brace isn't too small. It's too big. It's too noisy. See this
>   little nasty peak in the middle, on the right? It's aggressive, it's
>   impolite, it hurts my eyes.
>
>   No, really, the only 'end' that makes sense, should be soft, discreet,
>   gentle, almost invisible, in perfect harmony with the
>   Universe. There's only one candidate. It's... the right parenthesis
>   ')'.
>
> --
> ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info
>

Re: [julia-users] Re: Why does julia use END for block end?

[Didier Verna]

DNF  wrote:

> It is very clear and explicit, there is no doubt as to what it means,
> unlike '}' which is way too small and ambiguous (does it mean end of
> block, or end of dict definition, etc.), and just does not jump out at
> you the way it should.

  'end' is extremely verbose, just like 'function', 'global', 'local' etc.

  You are also wrong about the curly brace's ambiguity. If you find it
  ambiguous, that is because you live in a world overflown with
  syntax. You don't need end of blocks or dict definitions to be
  different things. You only really need an end of /expression/. And
  BTW, I have a hard time figuring out why 'end' wouldn't be ambiguous
  while '}' would be, especially since 'end' ends so many different
  things in Julia.

  Finally you are also mistaken about the size (yes, size matters). The
  curly brace isn't too small. It's too big. It's too noisy. See this
  little nasty peak in the middle, on the right? It's aggressive, it's
  impolite, it hurts my eyes.

  No, really, the only 'end' that makes sense, should be soft, discreet,
  gentle, almost invisible, in perfect harmony with the
  Universe. There's only one candidate. It's... the right parenthesis
  ')'.
  
-- 
ELS'16, May 9-10, Krakow, Poland: http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Junitex-Builder: Unicode tab completions in Gnome-Builder

[Nathan Smith]

HI Everyone!

I've built a plugin to provide latex to unicode tab completions in the Gnome 
Builder IDE.  Works with *very* recent 
versions of gnome builder (>=3.20). 

Checkout it out at: https://github.com/nsmith5/Junitex-Builder 

Currently, the plugin won't support subscript or superscript characters for 
some reason, but otherwise everything else should work. 

I'm hoping to have Junitex-Gedit finished soon as well to help create a 
better Julia experience on the gnome desktop. Happy to hear any feedback!

Cheers, 
Nathan

Re: [julia-users] Perhaps stupid question: Method type stability and throws

[Yichao Yu]

On Sat, May 7, 2016 at 8:46 AM, Cedric St-Jean  wrote:
>> mostly due to various technical reason

In arbitrary order, the ones I can think of now.

1. We collect backtrace

There are many cases where we don't actually need this info, but
we need better code analysis to be able to figure that out.

2. We don't have zero cost exception frame so we need to spill many registers.

It's hard for us to have zero cost exception frame unless all the
C libraries are compiled with unwind info. Also note that zero cost
exception frame means even more expensive exception throwing since the
registers are not explicitly saved and we need to unwind the call
stack to restore them. This is a trade off after all.

3. Preserving local variables across an exception requires spilling it
to stack and this adds some hidden cost.

It's a little hard to say how much cost this have, probably not
THAT much unless you have a lot of variables that is modified in try
and used after the exception is caught. Very likely strongly depending
on the code pattern.

4. The GC frame allocation is global (well, per-function) instead of
control flow local.

This cause allocation in not-taken branch to affect the
performance on the taken branch. This is not specific to exceptions
but is particularly bad for exceptions since throwing one sometimes
requires allocation that otherwise doesn't exist in the function (e.g.
`ArgumentError("My error message with $variable spliced in")`) and
these branches are meant to be not taken most of the time (if the
error can happen most of the time, you'd be better off with a error
code return, since exceptions are not designed for that).

>
> Could you please go into those? I'd like to understand why unwinding the
> stack is costlier than returning from a function.
>
> On Saturday, May 7, 2016 at 8:38:03 AM UTC-4, Yichao Yu wrote:
>>
>> On Sat, May 7, 2016 at 6:58 AM, Ben Ward  wrote:
>> > Hi,
>> >
>> > I have a question which may be laughable to CS people (be gentle, I'm a
>> > Biologist), but we know from guidelines that Julia performs best, when a
>> > method always returns the same type of value.
>> > So the Julia type inference knows - ok, use this method with an Int, it
>> > will
>> > always return a bool say. How does throws fit into this? To my mind this
>> > means the method used with an Int may return a bool, but it also may
>> > result
>> > in a type of (e.g.) ArgumentError getting thrown. So how do throws in
>> > functions affect performance and julian's ability to infer types and
>> > optimise code (if at all?)?
>>
>> While throwing or catching an error itself is slow (mostly due to
>> various technical reason) they shouldn't affect type stability.
>>
>> The type inference currently do not reason about what type of
>> exception can be thrown and even if it does, this won't affect what we
>> usually call the type stability of a function since it is only about
>> the **return type** of a function and throwing an error is not return
>> (in the sense that `a = cond ? error() : 1`, if the next statement is
>> executed, a is always a `Int`).
>>
>> >
>> > Thanks,
>> > Ben W.

[julia-users] Re: Why does julia use END for block end?

[randmstring]

Also, since you're using Atom you could just edit your stylesheet (go to 
Settings => Themes and click the link at the top) to include something like

atom-text-editor::shadow .keyword.control.end.julia {
  color: gray;
}

which would make the end a bit more subtle.

Am Freitag, 6. Mai 2016 20:26:15 UTC+2 schrieb Ford Ox:
>
> Is there any reasoning behind it? It seems to me like a weird choice since 
> you have to type three letters, which is the complete opposite of the goal 
> of this language - being very productive (a lot work done with little code).
> On top of that, brain has to read the word every time your eyes look at it 
> so you spend more time also reading the code - tho this should be easy to 
> omit, by highlighting this keyword by other color than other keywords (the 
> current purple color in ATOM just drives me crazy, since it is one of the 
> most violent colors, so my eyes always try to read that useless piece of 
> information first, instead of the important code).
>

Re: [julia-users] Perhaps stupid question: Method type stability and throws

[Cedric St-Jean]

> mostly due to various technical reason

Could you please go into those? I'd like to understand why unwinding the 
stack is costlier than returning from a function.

On Saturday, May 7, 2016 at 8:38:03 AM UTC-4, Yichao Yu wrote:
>
> On Sat, May 7, 2016 at 6:58 AM, Ben Ward  > wrote: 
> > Hi, 
> > 
> > I have a question which may be laughable to CS people (be gentle, I'm a 
> > Biologist), but we know from guidelines that Julia performs best, when a 
> > method always returns the same type of value. 
> > So the Julia type inference knows - ok, use this method with an Int, it 
> will 
> > always return a bool say. How does throws fit into this? To my mind this 
> > means the method used with an Int may return a bool, but it also may 
> result 
> > in a type of (e.g.) ArgumentError getting thrown. So how do throws in 
> > functions affect performance and julian's ability to infer types and 
> > optimise code (if at all?)? 
>
> While throwing or catching an error itself is slow (mostly due to 
> various technical reason) they shouldn't affect type stability. 
>
> The type inference currently do not reason about what type of 
> exception can be thrown and even if it does, this won't affect what we 
> usually call the type stability of a function since it is only about 
> the **return type** of a function and throwing an error is not return 
> (in the sense that `a = cond ? error() : 1`, if the next statement is 
> executed, a is always a `Int`). 
>
> > 
> > Thanks, 
> > Ben W. 
>

Re: [julia-users] Perhaps stupid question: Method type stability and throws

[Yichao Yu]

On Sat, May 7, 2016 at 6:58 AM, Ben Ward  wrote:
> Hi,
>
> I have a question which may be laughable to CS people (be gentle, I'm a
> Biologist), but we know from guidelines that Julia performs best, when a
> method always returns the same type of value.
> So the Julia type inference knows - ok, use this method with an Int, it will
> always return a bool say. How does throws fit into this? To my mind this
> means the method used with an Int may return a bool, but it also may result
> in a type of (e.g.) ArgumentError getting thrown. So how do throws in
> functions affect performance and julian's ability to infer types and
> optimise code (if at all?)?

While throwing or catching an error itself is slow (mostly due to
various technical reason) they shouldn't affect type stability.

The type inference currently do not reason about what type of
exception can be thrown and even if it does, this won't affect what we
usually call the type stability of a function since it is only about
the **return type** of a function and throwing an error is not return
(in the sense that `a = cond ? error() : 1`, if the next statement is
executed, a is always a `Int`).

>
> Thanks,
> Ben W.

[julia-users] Perhaps stupid question: Method type stability and throws

[Ben Ward]

Hi,

I have a question which may be laughable to CS people (be gentle, I'm a 
Biologist), but we know from guidelines that Julia performs best, when a 
method always returns the same type of value.
So the Julia type inference knows - ok, use this method with an Int, it 
will always return a bool say. How does throws fit into this? To my mind 
this means the method used with an Int may return a bool, but it also may 
result in a type of (e.g.) ArgumentError getting thrown. So how do throws 
in functions affect performance and julian's ability to infer types and 
optimise code (if at all?)? 

Thanks,
Ben W.

[julia-users] Re: Why does julia use END for block end?

[DNF]

I find 'end' to be the best choice of block terminator among the ones I 
have seen. 

It is very clear and explicit, there is no doubt as to what it means, 
unlike '}' which is way too small and ambiguous (does it mean end of block, 
or end of dict definition, etc.), and just does not jump out at you the way 
it should.

You are also wrong that it takes longer to read, since you read it as a 
single unit, you don't parse every single letter, unless you are in the 
process of learning to read. And since it is so unambiguous, it is much 
faster to read than any alternative I've seen.

As for whitespace-dependent, Python style, block delimiters, I have been 
working with those over the last few months, and have learned to abhor 
them. They are very brittle, outdent something by accident and the code 
breaks, perhaps completely invisibly. If you share code with someone that 
uses 2-space indentations (as I have), fixing that is a big headache. Last, 
but not least, it completely lacks the tidy symmetry and definitiveness of 
begin-end blocks, the code seems to slide across the page and then just 
trail off like a bad idea abandoned in mid-thought.

I love 'end', please keep it :)

On Friday, May 6, 2016 at 8:26:15 PM UTC+2, Ford Ox wrote:
>
> Is there any reasoning behind it? It seems to me like a weird choice since 
> you have to type three letters, which is the complete opposite of the goal 
> of this language - being very productive (a lot work done with little code).
> On top of that, brain has to read the word every time your eyes look at it 
> so you spend more time also reading the code - tho this should be easy to 
> omit, by highlighting this keyword by other color than other keywords (the 
> current purple color in ATOM just drives me crazy, since it is one of the 
> most violent colors, so my eyes always try to read that useless piece of 
> information first, instead of the important code).
>

[julia-users] How should I store map with objects.

[Ford Ox]

I want to do small simulation (similiar to games) where I have multiple 
objects that can move and spawn at map. What is the most efficient way to 
do that?

I was thinking about something like this:

@doc "I wont to be able to check for collision in constant time"
map = Array{Union{all objects...}(100, 10)

@doc "I place each object into separate vector, so I can move with them 
with complexity N"
moveable_objects_1 = [MO1 for i = 1:1000] # and place them on map
moveable_objects_2 = .
..._3 = ..
...


Is this the most efficient way?
Also, why do I have to specify the type of map array (Union..), when I will 
technically store there only pointers, which are all of the same size. If I 
use Array{Any}, will it be as fast as using Union{..} ?

Should I make map, moveable_objects_1-5 global variable, so I dont have to 
send it as parameter every time? (That will make my code unusable when 
imported by somebody else right?) Or should I pack them inside one type 
(f.e. type Data)? I am used to [this.](..) so this is kinda new to me.