<jhass>
but given no central registry it's not taken forever yet ;)
<dostoyevsky>
If all fails I still can write my own crystal implementation and call it Meth, like I did with my scheme implementation when I called it ponzi :)
<txdv>
You can always do your thing
<txdv>
its just that the only person doing your thing will be you
<dostoyevsky>
txdv: That's how all things start anyways...
dostoyevsky has quit [Quit: leaving]
onethirtyfive has quit [Remote host closed the connection]
dostoyevsky has joined #crystal-lang
onethirtyfive has joined #crystal-lang
<txdv>
back in the day we used o have gangs of hackers who would start a project together
<txdv>
now everyone is out for himself
<jhass>
is that so
<jhass>
everything that survived to today seems to have started as a one-person effort
<dostoyevsky>
txdv: Did you read the announcement of PHP or Linux in UseNet?
onethirtyfive has quit [Ping timeout: 250 seconds]
<txdv>
dostoyevsky: no
<txdv>
o, i guess yes
<txdv>
yeah, linus famous "this is nothing big, check my OS out"
<dostoyevsky>
Just some guy with an idea, started something themselves and it took off
<txdv>
yeah, i dont like php
<jhass>
php's terrible function naming is because the guy couldn't be bothered to write a proper hash function for his toy project
<dostoyevsky>
Still haven't learned PHP... I guess I dodged that bullet for long enough :)
<txdv>
php is just an accumulation of awlful things
<txdv>
people who use it tend to write horrible code too
<BlaXpirit>
it's easy to beat on php but that's beside the point
<dostoyevsky>
I remember that maybe 5 years ago, you could get paid quite well being a PHP developer... because that's what most websites used
<dostoyevsky>
txdv: Facebook was written in php, so it must be good
<BlaXpirit>
oh goddammit
<txdv>
and even they moved from php to something with types
<txdv>
"hacklang"
<dostoyevsky>
Linkedin moved from Ruby to Java iirc
<txdv>
twitter too
<txdv>
get big, use static typing
<txdv>
scripting languages are always nice for small projects
pawnbox has quit [Remote host closed the connection]
<dostoyevsky>
I really like node for speed... v8 ist just so fast... best jit ever imho
pawnbox has joined #crystal-lang
<dostoyevsky>
and I do not think I could write faster code in C or Rust for some of the regular expression parsers I use
<txdv>
regex is already slow
<dostoyevsky>
because PCRE's jit isn't going to be as good as v8's
<jhass>
getting big means not using a single technology as your do it all tool anymore, whether it fits the job or not, but hire people that can do the job well with whatever tool necessary to do it well
<jhass>
this "big X" uses/does not use bullshit annoys the hell out of me
<txdv>
yeah, but if you'd hire people to write something to write with crystal, they'd have to write some libs for it first
<txdv>
to write something with crystal*
<txdv>
this is why so many people jump on the java train
<txdv>
*there is already a lib for it*
<dostoyevsky>
jhass: you may never know for sure what Big X is using anyways :)
ponga has joined #crystal-lang
<txdv>
"I can't code with language X because it just doesn't have the ecosystem fo Java" - my most hated argument
<jhass>
I see it more as "there's already 10 libs for it and I'm never sure which one is remotely sane" but yeah
<jhass>
dostoyevsky: more importantly, it's completely irrelevant to my own projects
<jhass>
it's an argument to appeal rather than technological demands
<dostoyevsky>
I think the days where a company sticks to certain technologies are over anyways... most companies just use everything, and have no problem migrating to something entirely new...
<jhass>
sure
<jhass>
and yet even that is irrelevant to you
<jhass>
you're not big
<dostoyevsky>
And then you have mainframes, java, and lots of modern stuff all of a sudden in normal companies
pawnbox has quit [Ping timeout: 240 seconds]
<jhass>
you'll have resources to worry about it if you get, now you don't
<dostoyevsky>
I'd say the tipping point was just how you could communicate with other infrastructures and for a long time there was only Corba as a standard and then they had this EJB idea... but since simple http/rest apis with json have gained traction pretty much anyway, interopability is not an big issue anymore... and even on mainframes, you can have REST/apis in python or other scripting languages too
<Crizkov>
I was checking this http://helloworldcollection.de/ then -> "For a collection of programs that tell more about what programming in the languages actually is like, have a look at the 99 Bottles of Beer collection." But seems that no one has sent examples before???
<jhass>
is the most active community of that kind I know of for Crystal
<Crizkov>
nice!!!, thanks you jhass. Rossetta looks better that 99 bottles of beer (99bb seems outdated)
<BlaXpirit>
indeed
<dostoyevsky>
99 seems awfully small too... today it should be 99 gogols of beer clouds
<Crizkov>
X-D
<dostoyevsky>
Hmmm... so the current Xeon E7 intel processor takes 3TB of ram... using a GC based language will be something of the past soon, imho
<dostoyevsky>
If you are writing apps that use TB of ram, that is
<dostoyevsky>
(Looking at you, Chrome)
Crizkov has quit [Quit: Page closed]
<jhass>
well, how likely is it that those TBs of data are frequently changing
<jhass>
it's more like you read them and then scan through them repeatedly or flip a couple of bits here and there
<jhass>
you wouldn't dealloc/realloc them
<dostoyevsky>
jhass: In my uses cases I really used it like a big database... writing all the time... mostly indexes for TB/log files a day, but with custom allocators in C... Still, someone from my team used Rust with similar successes
Philpax has joined #crystal-lang
<jhass>
yet, was the amount of data that you permanently dealloced/realloced in the TBs, or would you say it would be average usecase that they are? Or is just that you keep a big chunk in memory and realloc/dealloc small chunks over time
<dostoyevsky>
jhass: In my use case I would get like 100G/s of data, so like 10TB a day via a 10G ethernet connection... I wouldn't realloc or dealloc, just use my own O(1) allocator that used fixed block sizes, so memory doesn't fragment... basically I implemented a lookback window for this kind of data that would expire after a week, too much for a traditional database that we used for more long-lived data
<dostoyevsky>
s/100G/100M/ :)
<jhass>
so you have a constant pointer that you always have a reference to, you mark it as opague to the GC (not containing pointers to any other objects) and it wouldn't bother about it
<dostoyevsky>
jhass: Well, it had pointers, it was a big hashtable... but you probably could tell the GC just not to bother about it
<dostoyevsky>
Like I told malloc not to do anythingthing with this
<jhass>
anyway, what I'm trying to say is that just because you have lots of memory, it doesn't mean a GC gets useless for all usecases
<jhass>
just for those where it would have to scan it all the time
<jhass>
which I think are less than one would think initially, in scenarios when working with that amount of memory anyway
<dostoyevsky>
jhass: for now I am not sure how many GCs actually support more than 1G of heap... Maybe only the Azul one
<jhass>
I don't see any heap limit mentioned for bdwgc
<FromGitter>
<Sija> hi, anyone had any experiences with pointers un/boxing between Crystal-land and C?
<jhass>
I take a stick and poke at it until it no longer crashes
<jhass>
in other words, what's your actual question?
<FromGitter>
<Sija> @jhass: I tried to explain the problem in #3140
<jhass>
RX14: you're probably the first to run the specs in release mode...
<RX14>
well...
<RX14>
they SHOULD work
<RX14>
like sha failing in release mode
<RX14>
isnt that a big deal...
<RX14>
jhass, can you reproduce?
<jhass>
compiling the compiler specs in release mode takes too long
<jhass>
but with the stdlib split, perhaps we should add it for that to travis
<jhass>
asterite: ^
<RX14>
yes but shouldn't you test specs in release mode before releasing at least
<jhass>
RX14: I can, currently trying with 3.5 on master and then with 3.8 on master
<RX14>
ok, good
<RX14>
i thought it was my pc for a while
<jhass>
if the last works we'll probably not backport a fix
<RX14>
this PC actually doesn't pass memtest...
<jhass>
hah
<RX14>
it looks like codegen bugs in release mode somehow
<RX14>
some bits changed around
<jhass>
well, yes, or rather codegen that leads to wrong behavior after LLVM's optimizer
<jhass>
hence if it works with 3.8 ...
<RX14>
i have no idea why the process spec fails though
<jhass>
3.5 on master is green already
<jhass>
so we just need to release :P
<RX14>
well i wouldn't trust that it's truly fuxed
<jhass>
Sija: this quite hard to poke at without being able to do it locally on code :/
<FromGitter>
<Sija> @jhass: It seems to me that either Proc docs are wrong in regard to holding the pointer (to callback vs boxed data) or I'm missing sth
<RX14>
optimisations will depends on the code around it right?
<FromGitter>
<Sija> I don't rly get this `Box` thing since I can pass `self.as(Void*)` and l8r on "unbox" it via `foo = data.as(Foo)`, so why would I need to create another object as a holder?
<BlaXpirit>
so it doesn't GC -_-
<BlaXpirit>
yes you don't necessarily need this Box indirection but then you can't pass closures
<FromGitter>
<Sija> @BlaXpirit yeah, I was using it exactly in this way, and it *got GC-ed* :/
<FromGitter>
<Sija> @BlaXpirit What I'm trying to say is that docs are stating sth that's simply incorrect
<BlaXpirit>
what part of "We must save this in Crystal-land so the GC doesn't collect it" is not clear?
<FromGitter>
<Sija> ... neither?
<FromGitter>
<Sija> which part of #3140 is not clear to you?
<BlaXpirit>
you know what? i think you're right, sorry
<FromGitter>
<Sija> uff, thanks for telling me that 'cause i got a bit frustrated already ;)
<FromGitter>
<Sija> docs say "save `callback`" and I say "save `data_as_callback` and (if u need it) `callback`"
<FromGitter>
<Sija> otherwise this whole `Box` thing doesn't work as advertised
<FromGitter>
<Sija> `Box.box` could also bake the reference keeping in somehow
<BlaXpirit>
nah, that's basically a global array
<BlaXpirit>
or set
<FromGitter>
<Sija> either this or fixing every `Box.box` in the code ;)
<FromGitter>
<alex-lairan> Hi everyones, I want to parse my YAML file into a data on my program, I have this code, but I think this is realy ugly ^.^
<crystal-gh>
[crystal] jhass opened pull request #3144: run standard library specs in release mode on travis (master...release_specs) https://git.io/v60o4
<RX14>
jhass, why don't you run all specs in release mode? Might want to run that in parallel using a matrix build too.
<BlaXpirit>
RX14, i don't think that it being a proper matrix or not affects parallel-ness
<jhass>
I'm not confident travis has even enough memory for this
<jhass>
even if it does it probably will take 30+ minutes longer
<RX14>
yeah
<RX14>
this is why I would get my own CI architecture :/
<jhass>
sure, will you pay the servers for us? :)
<RX14>
you can get good servers for very cheap off ebay these days, then go for colo
<RX14>
people don't know the value of their own hardware
<txdv>
hardware is cheap
<RX14>
yeah, human costs i know
<txdv>
i have a server hanging around, running irssi and tmux
<txdv>
:D
<RX14>
well as a student my time is free to me and servers are not, so using aws and the like is just not worth it for me
<BlaXpirit>
my internet connection has no public ip address, goes down sometimes, electricity goes down sometimes (not to mention it costs money) thats why i use a VPS
<BlaXpirit>
of course crystal would need a ton of RAM
<RX14>
only 8gb per job i would say
<RX14>
ram is cheap
<txdv>
16:13:10 up 106 days
<BlaXpirit>
most VPS services are not flexible enough to make RAM cheap. but yeah, u could probably find a good one
<txdv>
although my server has a shitty cpu
<RX14>
you can get some dual cpu machines with 32gb ram for super super cheap on ebay