pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
pawnbox has quit [Ping timeout: 240 seconds]
pawnbox has joined #crystal-lang
pawnbox has quit [Ping timeout: 240 seconds]
bjz has joined #crystal-lang
<FromGitter>
<jipiboily> If you folks want to see some Crystal screencasts: https://www.dailydrip.com/distillery - only paid customers can vote, though. They produce high quality content (creator of Elixir Sips) ⏎ ⏎ Disclaimer: one of the co-founders is a friend
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<FromGitter>
<jipiboily> Is there a way to have a begin/rescue block at the app level? catch everything?
<FromGitter>
<jipiboily> Would be great for Bugsnag (or others)
bjz has joined #crystal-lang
<FromGitter>
<jipiboily> I guess I’ll need a Kemal middleware in my case and I’ll be alright
<FromGitter>
<Zhomart> @bcardiff thanks for shard. But I decided to use `Slice`. I needed some collection to store shape of an array, e.g. `[2,3,6]` using `struct`.
<FromGitter>
<bcardiff> Slice is basically a pointer with a limit. It's still mutable
<FromGitter>
<jipiboily> @bcardiff thanks for Crystal, haven’t so much fun working on code in a long time :)
<FromGitter>
<jipiboily> Damn easy to pickup (for an experienced Ruby dev at least).
<FromGitter>
<jipiboily> ok, going to bed now; was fun building a shard and a kemal middleware in the last hour. :wave:
<FromGitter>
<schoening> @jipiboily also for non rubyist. I never used a white space language and had a completed project in 3 days :p its awesome
<FromGitter>
<Zhomart> That's true. Sorry, I made mistake on my first question.
<FromGitter>
<schoening> Been thinking for years about how I would want a programming language to be designed if I made one.. turns out that my ideas were pretty much ruby / crystal hehe xD
Renich has joined #crystal-lang
<FromGitter>
<bcardiff> I'm glad you all are having fun. But there are many people to thank to. I am just the one online right now :-P.
<FromGitter>
<schoening> One thing tho.. I wish there was some easy distinction between stack and heap allocated constructors :/ I'm sure there is a reason for them all to use the "new" method. But it also would be nice if there was a distinction. Perhaps HeapAllocatedClass.new and StackAllocatedClass.alloc - does that makes sence?
<FromGitter>
<bcardiff> @Zhomart actually Slice can be readonly, but that usage is a bit internal.
<FromGitter>
<bcardiff> @schoening that distinction is Class (reference types) vs Struct (value types).
<FromGitter>
<bcardiff> but the constructors are called .new always, otherwise some polimorphic code is almost impossible to write.
pawnbox has joined #crystal-lang
<FromGitter>
<schoening> Thanks for clearing up why things are they way they are. I suppose I would like a method for structs that invokes new but with a different name as an option :p ⏎ ⏎ But the distinction you mention is only something I can be aware of by memorizing the language, I was talking syntax wise there is no difference, right?
<FromGitter>
<bcardiff> I don't follow. I mean that in having a unified way to create instances, whether stack or heap, is convenient for writing code like `T.new` where `T` could be a type variable. If there will be different on struct and classes you will need to make a distinction on lot's of places
pawnbox has quit [Ping timeout: 240 seconds]
<FromGitter>
<schoening> Yeah ok, I get that it's convinient and probably best this way. I'm only bringing it up because I occasionally get confused if I am allocating on the heap or stack and I need to check the manual to be sure. And thats not terrible ofc, but thats why I said it could be nice for a noob like me to know where things are allocated by just skimming through my code
<FromGitter>
<schoening> I just never had the mighty power of being able to choose between stack or heap memory :p so now I am trying to do as much as possible on the stack!
<FromGitter>
<Zhomart> Is it ok to store huge data in `Slice`?
Renich has quit [Quit: Renich]
pawnbox has joined #crystal-lang
pawnbox has quit [Ping timeout: 256 seconds]
bungoman has joined #crystal-lang
pawnbox has joined #crystal-lang
bungoman_ has quit [Ping timeout: 246 seconds]
<FromGitter>
<Zhomart> What if `Enumerable#map` returns `Iterable` instead of an `Array`?
<FromGitter>
<yxhuvud> Hey, it is not functioning yet :)
<FromGitter>
<yxhuvud> I'm basically copying the Ruby implementation line for line now (though with constant index size for now).
<FromGitter>
<yxhuvud> And I'm less than 1/3 through the file so don't expect anything soon..
<RX14>
i'd love to see some benchmarks with different hash implementation
<RX14>
iirc there's been a lot of cool hasmap impls floating around recently
<RX14>
for example rust
<FromGitter>
<yxhuvud> Yeah that would be the next step after it actually works. Preferably in a pluggable way that is easy to expand.
<FromGitter>
<sdogruyol> @yxhuvud it's a good thing to start :)
<FromGitter>
<yxhuvud> It is even better to finish!
<FromGitter>
<sdogruyol> yup, you've done the hard part IMHO :)
<FromGitter>
<agibralter> I asked this a few days ago (sorry to repeat, but it was quiet then). Could someone tell me if this looks like a legit way to run a process with crystal and pass a sigint to it? https://gist.github.com/agibralter/37573a57810db641980fa3897cbf64d3
<RX14>
looks right
<FromGitter>
<sdogruyol> seems fine
<FromGitter>
<sdogruyol> i've done something similar before
<FromGitter>
<sdogruyol> though i was using `at_exit` with trap
<FromGitter>
<agibralter> ah cool, thank you!
<FromGitter>
<sdogruyol> :+1:
<FromGitter>
<agibralter> Just curious, is there a preferred CLI library these days?
<RX14>
this is why we have the "do it without macros first" rule
<FromGitter>
<sdogruyol> there are 5 rules and the first 3 are "don't use macros"
<RX14>
it forces you to write normal code then identify the bits which can't be deduplicated without macros
<FromGitter>
<agibralter> Like Ruby and most metaprogramming
<FromGitter>
<sdogruyol> indeed :)
<FromGitter>
<sdogruyol> i'm glad that we don't have `send` in Crystal
<FromGitter>
<agibralter> :smile:
<FromGitter>
<agibralter> Anyone know why shards.lock doesn't store the sha?
<FromGitter>
<sdogruyol> is it necessary?
<FromGitter>
<sdogruyol> Gemfile.lock also doesn't store sha (as i remember)
<FromGitter>
<drosehn> I like the meta-programming ability of ruby, but I use it very sparingly.
<FromGitter>
<agibralter> Well... if someone force pushes a version of a github dependency, won't that be able to change the lib out from under you?
<FromGitter>
<agibralter> Gemfile.lock does for github based dependencies
<FromGitter>
<sdogruyol> ah yeah
<FromGitter>
<sdogruyol> @agibralter you are right
<FromGitter>
<agibralter> I guess it's not the end of the world... someone could force push a version of a gem to Rubygems and that would have the same effect
<FromGitter>
<yxhuvud> My metaprogramming in Ruby is mostly limited to generating methods and instace_exec. Crystal have those covered.
pawnbox has quit [Remote host closed the connection]
<RX14>
i'd prefer if shards.lock just stored sha1 too
pawnbox has joined #crystal-lang
<RX14>
i wonder if theres a reason why it does not
<Papierkorb>
*sha256
<RX14>
git uses sha1
<RX14>
shards uses git
<RX14>
it would be sha1
<RX14>
the commit hash to check out
<Papierkorb>
which is hopefully remedied in a few years
<RX14>
i doubt it
<FromGitter>
<sdogruyol> same
<FromGitter>
<sdogruyol> it's so highly coupled and hard to remove
<RX14>
linus seems to hold the opinion that the current sha1 weakness doesn't compromise git
<RX14>
and i tend to agree with him
<Papierkorb>
Unlikely it is
<FromGitter>
<agibralter> yeah...
<Papierkorb>
But a shatter attack has been demonstrated on Torrent
<Papierkorb>
So it's only a question of time until someone does it with Git
<FromGitter>
<sdogruyol> reminded of torrent i recall that you were writing a torrent shard :P
<Papierkorb>
I did a few months back
<Papierkorb>
Yeah SHA-1 is deeply rooted into anything it does
<RX14>
even md5 is still preimage resistant
<RX14>
and it seems that the current hypothesis is that a preimage attack is required to compromise git
<FromGitter>
<ideasasylum> I'll need to check into what the differences are :confused:
<FromGitter>
<fridgerator> I had better success with the second one
<FromGitter>
<ideasasylum> :thumbsup:
<FromGitter>
<schoening> What's the eta on 1.0 out of curiosity? 2020? (I'm not trolling, I assume this will take quite a while considering the current version number)
<FromGitter>
<KCreate> They mention in one of the recent blog posts
<FromGitter>
<schoening> Hahaha aw man.. with a title like that I do feel a bit like an idiot for asking for an eta xD
<FromGitter>
<KCreate> well regarding they went from 0 to 0.21 within like 5 years, on might assume this rate of increase won't change
<FromGitter>
<crisward> Node went from 0.11 to v 4.0 in a couple of months... version numbers are not always a good indicator, it took them years to get to 0.11
<FromGitter>
<schoening> My god yes.. Node.js version numbers are crazy.
<FromGitter>
<schoening> Was confused for ages by people arguing to use 4 vs 0.12 like.. what is this??
<FromGitter>
<schoening> And in game development nothing ever leaves alpha or "green light" for a long time because then devs can wave bugs off as "we are still in development" xD
<FromGitter>
<fridgerator> the early access plague...
<FromGitter>
<fridgerator> i don't think its going anywhere anytime soon either
<FromGitter>
<fridgerator> because people purchase
<FromGitter>
<schoening> True
Ven has joined #crystal-lang
Ven is now known as Guest27220
<FromGitter>
<sdogruyol> @RX14 thanks for being active on StackOverflow Crystal tag
<FromGitter>
<elorest> <RX14> <Papierkorb> Sorry I missed you guys responding yesterday. At first I thought it would be easy to just wrap libbluetooth as I've wrapped a couple of other c libraries in the last week and it worked fine. I can't seem to find any docs for libbluetooth though and I'm having a hard time finding where a lot of variable/pointer types/structs are even being defined.
<Papierkorb>
elorest, /usr/include/libbluetooth hosts the header files. There aren't too many, so I'd just open them all in my editor. Really, I'd just grep (or w/e you like) for something I need, a structure definition or whatever, and then dig my way through until I'm satisfied
<Papierkorb>
elorest, let me plug `the_silver_searcher`, which is the horrible package name (ArchLinux package name at least) for the `ag` tool, which is a insanely fast grep-for-code. libbluetooth isn't that big yet, but for bigger projects it quickly makes a huge difference in time needed for the search
<FromGitter>
<elorest> Ok thanks. It seems unclear without documentation or examples what methods I would actually even call for what... Also I'm already using the silver searcher for everything. Thanks.
<shelvacu>
why is ag faster than regular grep?
<Papierkorb>
different engine and everything, also does parallel search and has tons of other optimizations
<FromGitter>
<elorest> It's written in c...
<FromGitter>
<elorest> Are you the author?
<Papierkorb>
No
<Papierkorb>
Usually, for a sufficiently large code base, installing that thing and using it to search for X is still faster than grepping for the same X
<RX14>
grep's pretty fast...
<RX14>
i guess me having an SSD skews that quite a bit
<Papierkorb>
My sources are all on SSDs, have been for years, and there's still a noticable difference
<RX14>
there was that other rust-based tool too wasn't there
<RX14>
"is there a proper way to handle pipes in crystal" yes, they're file desciptors they work like any other IO
<RX14>
`#read_line` => Same as #gets, but raises EOFError if called at the end of this IO.
<RX14>
from the docs
<RX14>
while line = io.gets
<FromGitter>
<drosehn> I think he's saying that he needs to know when one process needs to wait for new data before trying to read that new data.
<RX14>
that's the typical way to read a file, or use each_line
<RX14>
each_line is probably better
<RX14>
@drosehn I think zatherz is just trying to read an IO line-by-line
<FromGitter>
<zatherz> I think you're misunderstanding how named pipes work
<FromGitter>
<zatherz> .each_line and .gets terminate after getting input
<RX14>
each_line will return at EOF, yes
<FromGitter>
<drosehn> I'm pretty sure that if I was more awake, I could add a comment here which might be helpful. But I'm not more awake... :smile:
<FromGitter>
<zatherz> okay, the issue is not in how I read the fifo, but in how I write to the fifo; the fifo receives an EOF from the input when it shouldn't
<FromGitter>
<drosehn> Let me make this guess: You have a writing process, and a reading process. And the reader will process data faster than the writer produces new data. So you want your reading-process to ask "is there more data yet?", before it does the next read.
<FromGitter>
<zatherz> reading a pipe will not yield an EOF until EOF is written into the pipe
<RX14>
@zatherz EOF happens when you call io.close
<Papierkorb>
huh is there no #popen yet?
<RX14>
popen?
<RX14>
isn't that a process thing
<Papierkorb>
yes
<RX14>
whats wrong with the current Process.run
<RX14>
ruby's popen and popen3 mess we got rid of
<Papierkorb>
erm you can't get "rid off popen"
<RX14>
and made a useful interface which does everything
<RX14>
what do you mean
<Papierkorb>
How do I use Process.run then to continually feed data into the process?
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Papierkorb>
And continually get data out of it
<RX14>
we did get rid of popen so yeah, we did remove it
<RX14>
you set input: in_io, output: out_io
<RX14>
use an IO.pipe to create IO pipes
<RX14>
and read/write from other fibers
<Papierkorb>
I tried with IO::Memory, upon printing data into it nothing happened
<RX14>
well IO::Memory doesn't block because it's not a pipe#
<RX14>
it's just a IO which reads/writes to a piece of memory
<Papierkorb>
That's not half as good as IO.popen
<Papierkorb>
Now we have to teach that people have to mess with pipes manually
<RX14>
oh
<RX14>
you can use process.run with a block
<RX14>
and use the process.input/process.output
<RX14>
because they're pipes by default
<RX14>
there was a lot of discussion about Process.run...
<RX14>
i think they've ended up with a really nice API
<Papierkorb>
Then the docs need an update w.r.t to that
<RX14>
how so?
<RX14>
the docs are a little barebones but they work
<Papierkorb>
It's not obvious how it's intended to work