[julia-users] Re: Cxx.jl: Creating a templated class

2016-07-10 Thread Jan Strube
Edit: The cxx line is not valid C++.
   cxx"""UTIL::CellIDDecoder($(collection.coll)) x;
should of course read:
   cxx"""UTIL::CellIDDecoder x($(collection.coll));

Nevertheless, the icxx call seems valid, so I still don't understand why 
this isn't working.
Any insight is greatly appreciated.

On Monday, July 4, 2016 at 10:09:34 PM UTC-7, Jan Strube wrote:
>
> What's the right way to create a templated class on the C++ side with Cxx?
>
> I have an LCCollection 
> ,
>  
> and I would like to create a CellIDDecoder 
> ,
>  
> which needs a template argument.
>
> A simple 
>cxx"""UTIL::CellIDDecoder($(collection.coll)) x;
>   std::cout << x << std::endl;
> results in 
>
> ERROR: LoadError: Creating LLVM constants for type `T` not implemented yet
>  in llvmconst(::Any) at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:22
>  in ArgCleanup(::Cxx.ClangCompiler, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::LCCollection")},(false,false,false)},(false,
> false,false)}, ::Cxx.CppPtr{Cxx.CxxQualType{Cxx.CppBaseType{Symbol(
> "clang::VarDecl")},(false,false,false)},(false,false,false)}) at /home/
> stru821/.julia/v0.5/Cxx/src/cxxstr.jl:192
>  in macro expansion at /home/stru821/.julia/v0.5/Cxx/src/cxxstr.jl:634 [
> inlined]
>  in getCellIDDecoder(::LCIO.LCCollection{Cxx.CppPtr{Cxx.CxxQualType{Cxx.
> CppBaseType{Symbol("EVENT::SimCalorimeterHit")},(false,false,false)},(
> false,false,false)}}) at /home/stru821/.julia/v0.5/LCIO/src/CaloHit.jl:29
>  in testReader(::String) at /home/stru821/.julia/v0.5/LCIO/examples/
> testLCIOCxx.jl:14
>  in include_from_node1(::String) at ./loading.jl:426
>  in process_options(::Base.JLOptions) at ./client.jl:266
>  in _start() at ./client.jl:322
> while loading /home/stru821/.julia/v0.5/LCIO/examples/testLCIOCxx.jl, in 
> expression starting on line 22
>
> I have also tried to return the result of 
> icxx"""UTIL::CellIDDecoder($(collection.coll));
>
> But that replies with an even stranger message:
> :2:45: error: no matching constructor for initialization of 
> 'UTIL::CellIDDecoder'
> UTIL::CellIDDecoder < SimCalorimeterHit > ( __juliavar1 ) ;
> ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:36:3: note: 
> candidate constructor not viable: requires single argument 'encoder_str', 
> but no arguments were provided
>   CellIDDecoder( const std::string& encoder_str ) : _oldHit(0) {
>   ^
> /scratch/software/lcio-test/include/UTIL/CellIDDecoder.h:47:5: note: 
> candidate constructor not viable: requires single argument 'col', but no 
> arguments were provided
> CellIDDecoder( const EVENT::LCCollection* col ) : _oldHit(0) {
> ^
>
> The code clearly has a constructor argument, so I don't understand why the 
> compiler things it doesn't...
>
> If somebody knows how to construct such a templated class, please share.
> Many thanks.
>


[julia-users] Re: caching the pivot ordering for a sparse cholesky factorization?

2016-07-10 Thread Andreas Noack
The for Cholesky and sparse LDLt there are methods for reusing an existing 
symbolic factorization. They are cholfact!/ldltfact!(Factorization,Matrix) 
so you can e.g. do

```

julia> A = sprandn(100,100,0.1) + 10I;


julia> F = cholfact(Symmetric(A));


julia> cholfact!(F, Symmetric(A - I));

```


See 
https://github.com/JuliaLang/julia/blob/f8d67f7521287d9325e91fd2142dad5f222e6eaf/base/sparse/cholmod.jl#L1260-L1272.




On Friday, July 8, 2016 at 4:40:45 AM UTC-4, Gabriel Goh wrote:
>
> Hey,
>
> I have a sequence of sparse matrix factorizations I need to do, each one a 
> different matrix but with the same sparsity structure. Is there a way I can 
> save the AMD (or any other) ordering that sparsesuite returns, it does not 
> need to be recomputed each time?
>
> Thanks a lot for the help!
>
> Gabe
>


[julia-users] Re: Software Carpentry - Julia Lesson

2016-07-10 Thread Chris Rackauckas
I think we should really think about this again soon. Julia should get a 
good core of teaching materials and workshops together.

On Friday, September 11, 2015 at 9:53:55 AM UTC-7, Chase Coleman wrote:
>
> This is more of just a suggestion/placeholder that a Julia lesson gets 
> written for Software Carpentry . 
> They currently have a Python, R, and Matlab lesson 
>  -- If one of the goals is to 
> keep giving Matlab users a better tool then this might be a good place to 
> advertise Julia.
>
> I am willing to write it, but won't have time for another month or month 
> and a half. Just thought I'd throw it out there in case someone else wants 
> to beats me to it; notice that they seem to have a relatively good outline 
> for what the lesson should cover (Patient data, creating functions, making 
> choices, defensive programming, and then some tool specific stuff).
>


[julia-users] Re: caching the pivot ordering for a sparse cholesky factorization?

2016-07-10 Thread Gabriel Goh
I'd love more details Dan!

On Saturday, July 9, 2016 at 8:53:16 PM UTC-7, Dan wrote:
>
> Hi Gabe,
>
> SuiteSparse which comes together with Julia includes a library KLU which 
> does sparse LU factorization. It has the option to return the fill-in 
> reducing order it manages to find for a given sparsity pattern. With this 
> returned structure it can subsequently factorize many matrices (and solve 
> equations). After some tinkering, I have got it to work, so it is possible.
>
> If this is still an issue and using KLU fits the bill, I'll provide more 
> details of my tinkering.
>
> DG 
>
> On Friday, July 8, 2016 at 4:40:45 AM UTC-4, Gabriel Goh wrote:
>>
>> Hey,
>>
>> I have a sequence of sparse matrix factorizations I need to do, each one 
>> a different matrix but with the same sparsity structure. Is there a way I 
>> can save the AMD (or any other) ordering that sparsesuite returns, it does 
>> not need to be recomputed each time?
>>
>> Thanks a lot for the help!
>>
>> Gabe
>>
>

[julia-users] Re: Dear Sublime Text Users

2016-07-10 Thread Jeffrey Sarnoff
using it

On Saturday, July 9, 2016 at 5:49:59 PM UTC-4, Randy Lai wrote:
>
> You need to have some unicodes highlighted and then run the reverse lookup 
> command.
>
> I am using the default font on Mac (I suppose).
>


Re: [julia-users] How To Use Julia with SAP via NetWeaver RFC Library

2016-07-10 Thread Tom Short
Looks like something that could go into a package. If you don't want to do
that, it'd be nice if you could add a license to your code, so others could
use it as a starting point.
On Jul 10, 2016 4:45 PM, "Stefan Schnell"  wrote:

> Hello community,
>
> here an include how to use Julia with SAP via NetWeaver RFC library - but
> only with a few functions, not the complete set of the SAP NetWeaver RFC
> library:
>
> #-Begin-
>
>   #-User Defined Types--
> type RFC_CONNECTION_PARAMETER
>   nameASHost::Ptr{UInt16}
>   valueASHost::Ptr{UInt16}
>   nameSysNr::Ptr{UInt16}
>   valueSysNr::Ptr{UInt16}
>   nameClient::Ptr{UInt16}
>   valueClient::Ptr{UInt16}
>   nameUser::Ptr{UInt16}
>   valueUser::Ptr{UInt16}
>   namePassWd::Ptr{UInt16}
>   valuePassWd::Ptr{UInt16}
>   nameLang::Ptr{UInt16}
>   valueLang::Ptr{UInt16}
> end
>
> type RFC_ERROR_INFO
>   code::Int32
>   group::Int32
>   key::Ptr{UInt16}
>   message::Ptr{UInt16}
>   abapMsgClass::Ptr{UInt16}
>   abapMsgType::Ptr{UInt16}
>   abapMsgNumber::Ptr{UInt16}
>   abapMsgV1::Ptr{UInt16}
>   abapMsgV2::Ptr{UInt16}
>   abapMsgV3::Ptr{UInt16}
>   abapMsgV4::Ptr{UInt16}
> end
>
>   #-Constants---
> const sapnwrfc = "sapnwrfc.dll"
>
>   #-Main
> cd("C:\\Projects\\SAP\\RFC\\Julia")
>
> code = 0
> group = 0
> key = ""
> message = ""
> abapMsgClass = ""
> abapMsgType = ""
> abapMsgNumber = ""
> abapMsgV1 = ""
> abapMsgV2 = ""
> abapMsgV3 = ""
> abapMsgV4 = ""
> RfcErrorInfo = RFC_ERROR_INFO(
>  code, group, pointer(utf16(key)), pointer(utf16(message)),
>  pointer(utf16(abapMsgClass)), pointer(utf16(abapMsgType)),
>  pointer(utf16(abapMsgNumber)), pointer(utf16(abapMsgV1)),
>  pointer(utf16(abapMsgV2)), pointer(utf16(abapMsgV3)),
>  pointer(utf16(abapMsgV4))
> )
>
>   #-RfcGetVersion---
> function RfcGetVersion()
>   majorVersion = Ref{UInt32}(0)
>   minorVersion = Ref{UInt32}(0)
>   patchLevel = Ref{UInt32}(0)
>   ptrVersion = ccall((:RfcGetVersion, sapnwrfc), stdcall,
> Ptr{UInt16}, (Ptr{UInt32}, Ptr{UInt32}, Ptr{UInt32}),
> majorVersion, minorVersion, patchLevel)
>   return utf16(ptrVersion), majorVersion[], minorVersion[],
> patchLevel[]
> end
>
>   #-RfcOpenConnection---
> function RfcOpenConnection(ashost::AbstractString,
>   sysnr::AbstractString, client::AbstractString,
>   user::AbstractString, passwd::AbstractString,
>   lang::AbstractString = "EN")
>   nameASHost = "ASHOST"
>   valueASHost = ashost
>   nameSysNr = "SYSNR"
>   valueSysNr = sysnr
>   nameClient = "CLIENT"
>   valueClient = client
>   nameUser = "USER"
>   valueUser = user
>   namePassWd = "PASSWD"
>   valuePassWd = passwd
>   nameLang = "LANG"
>   valueLang = lang
>   RfcConnectionParameter = RFC_CONNECTION_PARAMETER(
> pointer(utf16(nameASHost)), pointer(utf16(valueASHost)),
> pointer(utf16(nameSysNr)), pointer(utf16(valueSysNr)),
> pointer(utf16(nameClient)), pointer(utf16(valueClient)),
> pointer(utf16(nameUser)), pointer(utf16(valueUser)),
> pointer(utf16(namePassWd)), pointer(utf16(valuePassWd)),
> pointer(utf16(nameLang)), pointer(utf16(valueLang))
>   )
>   return ccall((:RfcOpenConnection, sapnwrfc), stdcall,
> UInt32, (Ref{RFC_CONNECTION_PARAMETER}, UInt32,
> Ref{RFC_ERROR_INFO}), RfcConnectionParameter, 6, RfcErrorInfo)
> end
>
>   #-RfcGetFunctionDesc--
> function RfcGetFunctionDesc(rfcHandle::UInt32,
>   funcName::AbstractString)
>   return ccall((:RfcGetFunctionDesc, sapnwrfc), stdcall,
> UInt32, (UInt32, Ptr{UInt16}, Ref{RFC_ERROR_INFO}),
> rfcHandle, utf16(funcName), RfcErrorInfo)
> end
>
>   #-RfcCreateFunction---
> function RfcCreateFunction(funcDescHandle::UInt32)
>   return ccall((:RfcCreateFunction, sapnwrfc), stdcall,
> UInt32, (UInt32, Ref{RFC_ERROR_INFO}),
> funcDescHandle, RfcErrorInfo)
> end
>
>   #-RfcInvoke---
> function RfcInvoke(rfcHandle::UInt32, funcHandle::UInt32)
>   return ccall((:RfcInvoke, sapnwrfc), stdcall,
> UInt32, (UInt32, UInt32, Ref{RFC_ERROR_INFO}),
> rfcHandle, funcHandle, RfcErrorInfo)
> end
>
>   #-RfcDestroyFunction--
> function 

[julia-users] How To Use Julia with SAP via NetWeaver RFC Library

2016-07-10 Thread Stefan Schnell
Hello community,

here an include how to use Julia with SAP via NetWeaver RFC library - but 
only with a few functions, not the complete set of the SAP NetWeaver RFC 
library:

#-Begin-

  #-User Defined Types--
type RFC_CONNECTION_PARAMETER
  nameASHost::Ptr{UInt16}
  valueASHost::Ptr{UInt16}
  nameSysNr::Ptr{UInt16}
  valueSysNr::Ptr{UInt16}
  nameClient::Ptr{UInt16}
  valueClient::Ptr{UInt16}
  nameUser::Ptr{UInt16}
  valueUser::Ptr{UInt16}
  namePassWd::Ptr{UInt16}
  valuePassWd::Ptr{UInt16}
  nameLang::Ptr{UInt16}
  valueLang::Ptr{UInt16}
end

type RFC_ERROR_INFO
  code::Int32
  group::Int32
  key::Ptr{UInt16}
  message::Ptr{UInt16}
  abapMsgClass::Ptr{UInt16}
  abapMsgType::Ptr{UInt16}
  abapMsgNumber::Ptr{UInt16}
  abapMsgV1::Ptr{UInt16}
  abapMsgV2::Ptr{UInt16}
  abapMsgV3::Ptr{UInt16}
  abapMsgV4::Ptr{UInt16}
end

  #-Constants---
const sapnwrfc = "sapnwrfc.dll"

  #-Main
cd("C:\\Projects\\SAP\\RFC\\Julia")

code = 0
group = 0
key = ""
message = ""
abapMsgClass = ""
abapMsgType = ""
abapMsgNumber = ""
abapMsgV1 = ""
abapMsgV2 = ""
abapMsgV3 = ""
abapMsgV4 = ""
RfcErrorInfo = RFC_ERROR_INFO(
 code, group, pointer(utf16(key)), pointer(utf16(message)),
 pointer(utf16(abapMsgClass)), pointer(utf16(abapMsgType)),
 pointer(utf16(abapMsgNumber)), pointer(utf16(abapMsgV1)),
 pointer(utf16(abapMsgV2)), pointer(utf16(abapMsgV3)),
 pointer(utf16(abapMsgV4))
)

  #-RfcGetVersion---
function RfcGetVersion()
  majorVersion = Ref{UInt32}(0)
  minorVersion = Ref{UInt32}(0)
  patchLevel = Ref{UInt32}(0)
  ptrVersion = ccall((:RfcGetVersion, sapnwrfc), stdcall,
Ptr{UInt16}, (Ptr{UInt32}, Ptr{UInt32}, Ptr{UInt32}),
majorVersion, minorVersion, patchLevel)
  return utf16(ptrVersion), majorVersion[], minorVersion[],
patchLevel[]
end

  #-RfcOpenConnection---
function RfcOpenConnection(ashost::AbstractString,
  sysnr::AbstractString, client::AbstractString,
  user::AbstractString, passwd::AbstractString,
  lang::AbstractString = "EN")
  nameASHost = "ASHOST"
  valueASHost = ashost
  nameSysNr = "SYSNR"
  valueSysNr = sysnr
  nameClient = "CLIENT"
  valueClient = client
  nameUser = "USER"
  valueUser = user
  namePassWd = "PASSWD"
  valuePassWd = passwd
  nameLang = "LANG"
  valueLang = lang
  RfcConnectionParameter = RFC_CONNECTION_PARAMETER(
pointer(utf16(nameASHost)), pointer(utf16(valueASHost)),
pointer(utf16(nameSysNr)), pointer(utf16(valueSysNr)),
pointer(utf16(nameClient)), pointer(utf16(valueClient)),
pointer(utf16(nameUser)), pointer(utf16(valueUser)),
pointer(utf16(namePassWd)), pointer(utf16(valuePassWd)),
pointer(utf16(nameLang)), pointer(utf16(valueLang))
  )
  return ccall((:RfcOpenConnection, sapnwrfc), stdcall,
UInt32, (Ref{RFC_CONNECTION_PARAMETER}, UInt32,
Ref{RFC_ERROR_INFO}), RfcConnectionParameter, 6, RfcErrorInfo)
end

  #-RfcGetFunctionDesc--
function RfcGetFunctionDesc(rfcHandle::UInt32,
  funcName::AbstractString)
  return ccall((:RfcGetFunctionDesc, sapnwrfc), stdcall,
UInt32, (UInt32, Ptr{UInt16}, Ref{RFC_ERROR_INFO}),
rfcHandle, utf16(funcName), RfcErrorInfo)
end

  #-RfcCreateFunction---
function RfcCreateFunction(funcDescHandle::UInt32)
  return ccall((:RfcCreateFunction, sapnwrfc), stdcall,
UInt32, (UInt32, Ref{RFC_ERROR_INFO}),
funcDescHandle, RfcErrorInfo)
end

  #-RfcInvoke---
function RfcInvoke(rfcHandle::UInt32, funcHandle::UInt32)
  return ccall((:RfcInvoke, sapnwrfc), stdcall,
UInt32, (UInt32, UInt32, Ref{RFC_ERROR_INFO}),
rfcHandle, funcHandle, RfcErrorInfo)
end

  #-RfcDestroyFunction--
function RfcDestroyFunction(funcHandle::UInt32)
  return ccall((:RfcDestroyFunction, sapnwrfc), stdcall,
UInt32, (UInt32, Ref{RFC_ERROR_INFO}),
funcHandle, RfcErrorInfo)
end

  #-RfcCloseConnection--
function RfcCloseConnection(rfcHandle::UInt32)
  return ccall((:RfcCloseConnection, sapnwrfc), stdcall,
UInt32, (UInt32, Ref{RFC_ERROR_INFO}),
rfcHandle, RfcErrorInfo)
end


Re: [julia-users] Additional dataframes library

2016-07-10 Thread Milan Bouchet-Valat
Le dimanche 10 juillet 2016 à 09:02 -0700, Brandon Taylor a écrit :
> I'm looking to add an additional dataframes library. I was going to
> pick up all the additional functions that are in tidyr and dplyr that
> aren't covered in dataframes.jl and dataframesmeta.jl but I wanted to
> check whether something like this existed first.
No that I know of, but I'd encourage you to coordinate your work with
Julia Stats developers. For example, you could open issues or pull
requests against DataFramesMeta if your additions would fit well with
the goal of the package. Or if you're not sure, write a message to the
julia-stats mailing list to start a discussion (I won't be able to
reply immediately, but others might).

In particular, it will be probably be relevant to your work to be aware
of the current plan to switch from DataArrays to NullableArrays:
https://github.com/JuliaStats/DataFrames.jl/pull/1008
https://github.com/JuliaStats/DataArrays.jl/issues/73
(see also referenced issues)


Regards


Re: [julia-users] Why two (qualified) macro invocation forms?

2016-07-10 Thread Isaiah Norton
>
> I don't think any of these requires a specific form.
>

Ok.

Anyway, this was originally put in place to allow calling un-exported
macros:
https://github.com/JuliaLang/julia/issues/1107

Question raised here:
https://github.com/JuliaLang/julia/issues/1769#issuecomment-231596892


>
> > On Sun, Jul 10, 2016 at 12:46 AM, Isaiah Norton  >
> > wrote:
> >>
> >> I believe the second form may be vestigial at this point, and agree that
> >> it is inconsistent. The usage is non-existent in base (except for one
> test),
> >> but there is at least one issue for which the current work-around
> requires
> >> the second form: https://github.com/JuliaLang/julia/issues/14208
> >>
> >> On Fri, Jul 8, 2016 at 4:52 AM, Hans-Peter  wrote:
> >>>
> >>> Acc. to the manual [1] either `Mod.@mac` or `@Mod.mac` can be used.
> What
> >>> is the reason for the second form? Is it necessary to make me (other
> >>> people?) think which form should be used preferably? Maybe there is a
> reason
> >>> (didn't find something in issues/maillist) but with my current
> knowledge I'd
> >>> propose to 'push' the first form and deprecate the second.
> >>>
> >>> Both forms are not used often (in Julia source and my v0.4 packages).
> The
> >>> first (Mod.@mac) form is more frequent.
> >>>
> >>> ~~~
> >>> find ~/.julia/v0.4/ -name "*.jl" | xargs ack " \w+\.@\w+"
> >>> find ~/.julia/v0.4/ -name "*.jl" | xargs ack " @\w+\."
> >>> ~~~
> >>>
> >>> Sometimes both forms are being used, e.g.:
> >>>
> >>> ... v0.4/DataArrays/src/DataArrays.jl
> >>> 78:Base.@deprecate removeNA dropna
> >>> ... v0.4/DataArrays/test/reducedim.jl
> >>> 12:Base.Test.@test DataArrays._any(bits, i, j) == v
> >>>
> >>> vs.
> >>>
> >>> ... v0.4/Calculus/src/Calculus.jl
> >>> 62:@Base.deprecate integrate(f,a,b) quadgk(f,a,b)[1]
> >>> ... v0.4/Distributions/test/truncate.jl
> >>> 70:@Base.Test.test_approx_eq_eps(logpdf(d, x), lp, sqrt(eps()))
> >>>
> >>>
> >>> [1]
> >>>
> http://docs.julialang.org/en/latest/manual/modules/#namespace-miscellanea
> >>
> >>
> >
>


Re: [julia-users] File created with different mode in v0.5 than in v0.4

2016-07-10 Thread Yichao Yu
On Sun, Jul 10, 2016 at 11:58 AM, Josef Sachs  wrote:
> What explains this difference between v0.4 (644) and v0.5 (664)?
> I don't see anything in NEWS.md.
> (offhand, I agree that the v0.5 behavior makes more sense.)

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

>
> AWS-Sachs-Ubuntu$ umask
> 002
> AWS-Sachs-Ubuntu$ julia
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.4.7-pre+3 (2016-07-10 08:08 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit eb322c0 (0 days old release-0.4)
> |__/   |  x86_64-linux-gnu
>
> julia> io = open("/home/sachs/temp4", "w");
>
> julia> oct(filemode("/home/sachs/temp4"))
> "100644"
>
> julia> exit()
> AWS-Sachs-Ubuntu$ usr/bin/julia
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.5.0-dev+5260 (2016-07-10 01:41 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit f8d67f7 (0 days old master)
> |__/   |  x86_64-linux-gnu
>
> julia> io = open("/home/sachs/temp5", "w");
>
> julia> oct(filemode("/home/sachs/temp5"))
> "100664"


[julia-users] Additional dataframes library

2016-07-10 Thread Brandon Taylor
I'm looking to add an additional dataframes library. I was going to pick up 
all the additional functions that are in tidyr and dplyr that aren't 
covered in dataframes.jl and dataframesmeta.jl but I wanted to check 
whether something like this existed first.


[julia-users] File created with different mode in v0.5 than in v0.4

2016-07-10 Thread Josef Sachs
What explains this difference between v0.4 (644) and v0.5 (664)?
I don't see anything in NEWS.md.
(offhand, I agree that the v0.5 behavior makes more sense.)

AWS-Sachs-Ubuntu$ umask
002
AWS-Sachs-Ubuntu$ julia
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.7-pre+3 (2016-07-10 08:08 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit eb322c0 (0 days old release-0.4)
|__/   |  x86_64-linux-gnu

julia> io = open("/home/sachs/temp4", "w");

julia> oct(filemode("/home/sachs/temp4"))
"100644"

julia> exit()
AWS-Sachs-Ubuntu$ usr/bin/julia
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0-dev+5260 (2016-07-10 01:41 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit f8d67f7 (0 days old master)
|__/   |  x86_64-linux-gnu

julia> io = open("/home/sachs/temp5", "w");

julia> oct(filemode("/home/sachs/temp5"))
"100664"


Re: [julia-users] Why two (qualified) macro invocation forms?

2016-07-10 Thread Yichao Yu
On Sun, Jul 10, 2016 at 12:52 AM, Isaiah Norton  wrote:
> (also a work-around for a symbol hygiene issue:
> https://github.com/JuliaLang/julia/issues/15085)

I don't think any of these requires a specific form.

>
> On Sun, Jul 10, 2016 at 12:46 AM, Isaiah Norton 
> wrote:
>>
>> I believe the second form may be vestigial at this point, and agree that
>> it is inconsistent. The usage is non-existent in base (except for one test),
>> but there is at least one issue for which the current work-around requires
>> the second form: https://github.com/JuliaLang/julia/issues/14208
>>
>> On Fri, Jul 8, 2016 at 4:52 AM, Hans-Peter  wrote:
>>>
>>> Acc. to the manual [1] either `Mod.@mac` or `@Mod.mac` can be used. What
>>> is the reason for the second form? Is it necessary to make me (other
>>> people?) think which form should be used preferably? Maybe there is a reason
>>> (didn't find something in issues/maillist) but with my current knowledge I'd
>>> propose to 'push' the first form and deprecate the second.
>>>
>>> Both forms are not used often (in Julia source and my v0.4 packages). The
>>> first (Mod.@mac) form is more frequent.
>>>
>>> ~~~
>>> find ~/.julia/v0.4/ -name "*.jl" | xargs ack " \w+\.@\w+"
>>> find ~/.julia/v0.4/ -name "*.jl" | xargs ack " @\w+\."
>>> ~~~
>>>
>>> Sometimes both forms are being used, e.g.:
>>>
>>> ... v0.4/DataArrays/src/DataArrays.jl
>>> 78:Base.@deprecate removeNA dropna
>>> ... v0.4/DataArrays/test/reducedim.jl
>>> 12:Base.Test.@test DataArrays._any(bits, i, j) == v
>>>
>>> vs.
>>>
>>> ... v0.4/Calculus/src/Calculus.jl
>>> 62:@Base.deprecate integrate(f,a,b) quadgk(f,a,b)[1]
>>> ... v0.4/Distributions/test/truncate.jl
>>> 70:@Base.Test.test_approx_eq_eps(logpdf(d, x), lp, sqrt(eps()))
>>>
>>>
>>> [1]
>>> http://docs.julialang.org/en/latest/manual/modules/#namespace-miscellanea
>>
>>
>


Re: [julia-users] Signal / slot (or publish-subscribe) libraries in Julia

2016-07-10 Thread Femto Trader
Just a little comment here about these 2 repositories

https://github.com/femtotrader/PubSub.jl A very basic Julia implementation 
of pub-sub (publish/subscribe) pattern
https://github.com/femtotrader/SignalSlot.jl A very basic Julia 
implementation of signal slot pattern

It's a work in progress... probably not ready for production usage



Le samedi 4 juin 2016 09:58:52 UTC+2, Tim Holy a écrit :
>
> I've sometimes also wished for an imperative version of Reactive, but 
> Shashi 
> has pointed out some pretty serious advantages of a declarative approach. 
> My 
> favorite is `throttle`, which allows you to make many separate updates to 
> various `Signal`s and yet allow some operation that depends on all of them 
> to 
> update only once. A great application is drawing frames at 60Hz, where you 
> might want to update a whole bunch of parameters that affect the drawing 
> but 
> not trigger a redraw on each one. Sheer magic. 
>
> Best, 
> --Tim 
>
> On Friday, June 3, 2016 10:55:12 PM CDT Penn Taylor wrote: 
> > Femto Trader, 
> > 
> > I came up with a way to get emit to work the way you wanted: 
> > https://gist.github.com/penntaylor/a4dd1ed268b2401e54a72705954180c5 
>
>
>