<travis-ci>
crystal-lang/crystal#1dd26e6 (release/0.17 - Compiler: automatically consider a method as "macro def" when `@type` is found inside macro code. Fixes #2647. Related to #2565): The build was broken. https://travis-ci.org/crystal-lang/crystal/builds/132921727
<miketheman>
good day, all
<miketheman>
curious about the branching/merging strategy on master - it appears that fixes are being applied to the release branch first, insted of to master?
<miketheman>
Makes for a somewhat "interesting" commit history log of master, which makes it a bit harder to reason about
<jhass>
miketheman: yes, changes which should be included into 0.17.4 go into the release branch, changes towards 0.18 only go directly into master
<jhass>
git log --no-merges hides merge commits
<jhass>
keeping the release branch an exact subset of master has several advantages, most importantly no duplicated commits
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vrPFc
<jhass>
and I would argue that as a Github UI issue :P
<miketheman>
very true. :P
<miketheman>
As long as it's intentional. Since it "appears" to me that features are being added to the released branch (not bugfixes) and then merged into master, whereas my "vision" is that you develop a feature on master, and if it makes sense you merge it to a release branch
<jhass>
less so merge it into one as more creating one from it
<jhass>
and we're < 1.0 so everything goes, even according to semantic versioning :P
<jhass>
so for the moment major vs patch is more about the "scope" of stuff
<jhass>
how broadly it affects the language
<miketheman>
fair enough
<BlaXpirit>
jhass, not really. the releases make very good sense
<BlaXpirit>
0.x.y - change of y does not introduce backwards incompatible changes
<BlaXpirit>
...or major features
<txdv>
jhass: how much do you think is crystal faster compared to ruby?
<BlaXpirit>
very
<BlaXpirit>
what kind of answer do you expect
<miketheman>
"7"
<jhass>
txdv: depends on the workload, but for most it's closer to C than to Ruby
<BlaXpirit>
jhass, i know but first of all we don't know if crystal developers follow semver, and i'm not talking about semver but about my observations
<miketheman>
Caveat Programmer
trapped has quit [Read error: Connection reset by peer]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
<miqlas-H>
bye Guys!
miqlas-H has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
pawnbox has quit [Ping timeout: 244 seconds]
<asterite>
All the branches and merge mess is because I want to release 0.17.4 soon, which contains backwards changes (I don't want to make breaking changes now because the last release happened recently, so to give some air to upgrade code). After that, I'll probably start committing directly to master towards 0.18.0 (thus making some breaking changes I have in mind)
<jhass>
<3
<zodiak>
can I ask (sorry) if there is any word/progress/ticket I can read up on about parallelism/pthreads/etc (sorry again :)
<crystal-gh>
[crystal] asterite opened pull request #2648: JSON: added `root` option to mapping, and `root` argument overload to… (release/0.17...feature/json_root) https://git.io/vrXfp
<asterite>
zodiak: there isn't. But we'll probably tackle it next month. waj is on vacations and he'll be back in three or four weeks, and after that we'll do it. It might take a while because I can imagine we'll have to write a GC from scratch
<asterite>
I've been thinking and maybe doing parallelism is more important than fixing the bugs related to generics, because right now some part of generics are broken so you don't use them, but you can still make programs. But once we add parallelism some code bases will have to change (to be concurrent-safe)
<zodiak>
my gc-fu is weak, but I have dabbled with the boehm c-lib stuff before, it's maybe not parallelism safe but maybe a starting point ?
<zodiak>
the reason I am holding off on trumpeting crystal for microservices around work is because i know someone is going to say 'but what about X that makes use of all cores'
<zodiak>
it's a mentality thing I guess
<jhass>
I mean for example for the sidekiq.cr case you can simply run N instances
<asterite>
we are currently using boehm, but the main issue we have it that it doesn't scan thread local storage: https://github.com/ivmai/bdwgc (search for one of the WARNINGs)
<asterite>
so for that we must change it, compile it and distribute a modified copy ourselves... but it's not a simple task, we'll have to learn how it works. But, in Crystal we can do a precise GC, so maybe it's better to just drop boehm
<asterite>
zodiak: I think many use node.js for microservices, and node.js also runs on one thread
willl has joined #crystal-lang
<zodiak>
asterite: this is another reason why the digerati here are shouting 'no node' :)
<zodiak>
don't get me wrong, some single proc things are awesome (redis etc)
<zodiak>
I jst think there is a .. well .. 'mindset' out here in S.Cali that the 'next big thing' has to use "all the cores"
<zodiak>
maybe I am biased
<zodiak>
boehm is also sort of a 'simple gc' - granted (better than I could probably invent mind you :)
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/vrXLf
<miketheman>
jhass: I'm taking a stab at adding the `Socket.gethostname` method you showed in the mailing list. You had mentioned something about platform portability testing - any guidance on that?
dhk has quit [Quit: Leaving]
<jhass>
well for the moment it would be good to verify it works on OS X too, but taking a look at FreeBSD and Alpine/musl-libc would be good too
<miketheman>
Is it "allowed" to scaffold a variable during spec tests by shelling out to the platform's `hostname` to assert equality?
mhib has joined #crystal-lang
<jhass>
should be okay, again given it actually works on OS X too ;)
<miketheman>
yeah - I dev on OS X, and it works so far. :)
<jhass>
cool
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<miketheman>
mind if i tag you in the PR?
<jhass>
also check the manpages for deprecation warnings
<willl>
asterite: I would second the move in focus to parallelism. I also think that would probably need a move off of boehm, which also might need more bookkeeping and maybe unfortunately losing c compatible structs, but it's better to explore these things now pre 1.0
<asterite>
willl: why losing c compatible structs?
<willl>
as I understand it, most gc techniques not boem require bookkepeing near the data,
<willl>
but boem scans heaps for pointer looking things, right?
<willl>
*boehm
<crystal-gh>
[crystal] jhass pushed 1 new commit to master: https://git.io/vrXGm
<crystal-gh>
crystal/master fb22a89 Jonne Haß: Merge branch 'release/0.17'
<miketheman>
II'm kind of wishing the issues and pr's made more use of the Labels in github for simple parsing of large lists - I see myself as less of a `compiler` person and more of a `std lib`, so it'd be nice to be able to focus there. ;)
<BlaXpirit>
miketheman, ??? current situation seems great to me