<jhass>
rubygems is also shipped with the Ruby tarball
<asterite>
BlaXpirit: Elixir comes with hex. I think this is the correct way to do things: a language is more than just its syntax, it's all the tools that are around it
<waj>
in Ruby, some obvious names for a package become unmaintained
<BlaXpirit>
that's not the only controversial built-in thing
<BlaXpirit>
that julia has
<jhass>
waj: asterite btw how was the flight? recovered from the jetlag? :P
<waj>
still working on that :P
<asterite>
jhass: same old story: the first hours you think you've beat the jet lag, but later you find out that's not true :-P
<jhass>
hehe
<asterite>
for now I feel fine and awake, I slept like 10 hours yesterday :)
<jhass>
cool, then you may want to look at http://carc.in/#/r/6vg and I can finally close that tab :P
<waj>
mm… yup, you must declare it as “macro def”
<jhass>
sure, just found it while browsing the submissions and not saying it should work, just maybe not crash the compiler ;)
<waj>
absolutely
<waj>
back to dependencies, linking to git repositories is nice, but the hard problem to solve is when there are recursive and repeated depdendencies
<waj>
in bundler a solver is used to find the best match
<waj>
but the real problem is that all the dependency version of each version of the packages are needed to solve the equation
<waj>
and checking out each tag might be a little slow :)
<waj>
so I was thinking about placing that info in a file kept in a separate orphan branch
<waj>
a “crystal release” command could maintain that branch automatically
<waj>
then the dependency solver only have to retrieve that file from each repository
<waj>
solve the equation and then pull the source code from each tag
<waj>
that’s basically something that the rubygems server is used for, but in this way we could do it in a distributed way
<jhass>
the downside being that you can only pull released versions
<waj>
you can still reference to HEAD version, or even tags
<waj>
but if that’s the case, no recursive dependencies can be solved
<waj>
the same happens with bundler
<jhass>
no
<jhass>
bundler resolves those by reading the gemspec
<jhass>
from the specified branch/ref
<waj>
yes, but dependencies from a gem linked from github are always pulled from rubygems
<waj>
we can still do the same
<waj>
reading the Projectfile (or the .yml if we decide to merge ysbaddaden’s work)
<asterite_>
Go right now is faster creating lightweight processes and switching between them, but is slower executing algorithms... probably because they don't optimize like we do (that is, using LLVM optimizations :-))
<asterite_>
but both Go and Crystal are fast enough for most apps you'd want to build
<nahtnam>
Ill try out crystal
<nahtnam>
because its syntax = ruby
<vikaton>
asterite_: remember you asked by there was an unstable channel for Rust ?
<asterite_>
vikaton: oh, I was able to compile the code with rust head
<vikaton>
asterite_: yeah, I was wondering how your experience coding in Rust was like if you did any
<asterite_>
Oh, I have no experience... we toyed with waj a bit to learn it and realized you probably need lots of annotations to write a program... or maybe we were doing something wrong
<asterite_>
We definitely want to learn it, we'd like safe concurrency but right now it's hard to acheive... well, you can share by communicating, but you might choose not to follow that rule and the compiler won't prevent you from doing so
<willl>
asterite_: I wanted to play with using the sse crc32 intrinsics (llvm.x86.sse42.crc32.64.64), but got stuck at trying to figure out how to pass the equivalent of -march native since llvm is linked instead of called as a command. any ideas? At least I think it needs -march=native, but that is just a guess from reading mailing lists
<BlaXpirit>
nahtnam, are you sure you apt-get updated
<vikaton>
asterite_: what types of annotations? Rust has type inference, maybe I can help clear things up if you think you are doing something wrong?
<nahtnam>
BlaXpirit: Just did that
<BlaXpirit>
well then maybe it wasn't added properly
<BlaXpirit>
this worked well for me
<asterite_>
willl: where are these intrinsics documented?
<asterite_>
vikaton: mostly the lifetime annotations, 'a ...
<vikaton>
asterite_: those are explicit, you usually don't need to use those but I'm not sure what you were creating
<asterite_>
vikaton: Like, a type that holds a reference to another type
<vikaton>
&'a str is explicit version of &str
<nahtnam>
BlaXpirit: Lol, now its working
<asterite_>
vikaton: in any case, we just toyed with it for an hour, can't really comment on it
<vikaton>
asterite_: example? You might want to pm me so this doesn't become #rust lol