ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Fund Crystal's development: | GH: | Docs: | Gitter:
Nekka has quit [Ping timeout: 240 seconds]
Nekka has joined #crystal-lang
repo has quit [Ping timeout: 260 seconds]
repo has joined #crystal-lang
f1refly has joined #crystal-lang
f1reflyylmao has quit [Ping timeout: 265 seconds]
avane has quit [Quit: ZNC -]
chachasmooth has quit [Ping timeout: 264 seconds]
chachasmooth has joined #crystal-lang
avane has joined #crystal-lang
deavmi has quit [Ping timeout: 246 seconds]
deavmi has joined #crystal-lang
DTZUZU has joined #crystal-lang
_ht has joined #crystal-lang
ua has quit [Ping timeout: 272 seconds]
ua has joined #crystal-lang
<FromGitter> <mattrberry> This is just me being nitpicky, but is there a nice way in the stdlib for me to fill a slice with a value? :p ⏎ ⏎ ```@sprite_pixels.size.times { |i| @sprite_pixels[i] = SPRITE_PIXEL }``` ⏎ ⏎ I assume there's not a `#fill(value : T)` method or something like it that I'm missing? []
<FromGitter> <> @mattrberry: `! { SPRITE_PIXEL }`
<FromGitter> <mattrberry> Cool I'll take it, thanks :)
<FromGitter> <mattrberry> Oh yeah, I'm likely going to look into your imgui bindings to get a small frontend going soon. Maybe this weekend :)
<FromGitter> <> @mattrberry good! well, note that there's still no premade setup for sdl
<FromGitter> <mattrberry> Yeah nw, I'm expecting to have to mess around with it a bit
<FromGitter> <mattrberry> Oh also, did you know that someone is making a crystal DS emulator now with your sfml/imgui bindings?
<FromGitter> <mattrberry> Still in the *very* early stages
<FromGitter> <mattrberry> Last I saw they only had a vram dump, but they're implementing at least a subset of the arm instruction set so far in order to get to that point
<FromGitter> <> i didn't see what it used. thanks
<FromGitter> <> now i cannot find it actually
alexherbo2 has joined #crystal-lang
bougyman has quit [Ping timeout: 260 seconds]
<FromGitter> <> :3
<FromGitter> <> wow i cannot believe it's literally the first project using my binding. it took so much work, and yet,..
bougyman has joined #crystal-lang
<FromGitter> <mattrberry> Your imgui bindings or sfml? I know of a handful of other ones using your sfml bindings at least
Stephie has quit [Quit: Fuck this shit, I'm out!]
Stephie has joined #crystal-lang
<FromGitter> <naqvis> > This is just me being nitpicky, but is there a nice way in the stdlib for me to fill a slice with a value? :p ⏎ > ```crystal ⏎ > @sprite_pixels.size.times { |i| @sprite_pixels[i] = SPRITE_PIXEL } ⏎ > ``` ⏎ > I assume there's not a `#fill(value : T)` method or something like it that I'm missing? ... []
<FromGitter> <naqvis> @mattrberry 👆
postmodern has quit [Quit: Leaving]
hightower3 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 240 seconds]
alexherbo2 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 240 seconds]
<FromGitter> <Sija> @naqvis What’s `bytesize(count)` in your example?
<FromGitter> <naqvis> oops
<FromGitter> <naqvis> @Sija `bytesize` is private method inside `Pointer` struct
<FromGitter> <Sija> I know but it doesn’t take any arguments, that’s why I’m asking
<FromGitter> <Sija> oh, this one
<FromGitter> <Sija> thanks for the pointer (pun intended) ;)
<FromGitter> <Sija> @naqvis That seems like sensible addition to the stdlib, will u post a PR with it?
<FromGitter> <naqvis> sure @Sija
alexherbo2 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 272 seconds]
<FromGitter> <toddsundsted> does anyone have metrics for compiler memory required for their release builds? i'm running a vps with 4GB and building a relatively small project ( the build just started to fail and i'm trying to decide whether to invest time to reduce the build size, or just upgrade.
<FromGitter> <toddsundsted> thanks in advance
<FromGitter> <Blacksmoke16> whats the error? also any reason to just build statically and move the binary to the vps?
<FromGitter> <Blacksmoke16> not to*
<FromGitter> <toddsundsted> i'm considering that option. i have a capistrano build set up that's worked well until now--that's the only point of reluctance. i'm seeing "OOM killed process" messages in dmesg
<FromGitter> <toddsundsted> and when i watch progress in htop, i can see the build slowly consume ram and than swap
<FromGitter> <Blacksmoke16> could you add like `--stats --progress` to the build? that would output info showing memory/time usages and stuff
<FromGitter> <toddsundsted> @Blacksmoke16 yes, i'll do that
<FromGitter> <Blacksmoke16> also are you using the latest `0.36.1`?
<FromGitter> <toddsundsted> i'm still on 0.35.1
<FromGitter> <toddsundsted> there's a compilation failure on 0.36.x i'm still investigating
<FromGitter> <Blacksmoke16> gotcha
HumanG33k has quit [Ping timeout: 264 seconds]
<FromGitter> <toddsundsted> hmm... it doesn't look bad at all ⏎ $ /usr/bin/time -v crystal build --stats --progress --release src/ktistec/ ⏎ Parse: 00:00:00.000177074 ( 0.25MB) ⏎ Semantic (top level): 00:00:10.210398295 ( 124.15MB) ⏎ Semantic (new): 00:00:00.008679838 ( 124.15MB) ... []
<FromGitter> <toddsundsted> that build worked, too
<FromGitter> <Blacksmoke16> building statically and just uploading the binary is the way to go tho
<FromGitter> <toddsundsted> yes, i'll look at that.
<FromGitter> <toddsundsted> thanks!
<FromGitter> <toddsundsted> thanks!
HumanG33k has joined #crystal-lang
<FromGitter> <asterite> Note that the memory in that output is just the one Crystal knows about (actually, the GC knows about). LLVM surely uses memory too, but you can't see that. So it might be hitting that 4GB limit, I don't know
<FromGitter> <toddsundsted> got it. i suspect then i'm right on the edge of being able to build on the vps
<FromGitter> <toddsundsted> so it works intermittently
<FromGitter> <Blacksmoke16> id try with `0.36.1`
HumanG33k has quit [Remote host closed the connection]
HumanG33k has joined #crystal-lang
<FromGitter> <toddsundsted> the project triggers a compiler crash on 0.36.x. i was hoping to put that off and hunt that down later
<FromGitter> <asterite> Another thing you can try is pass `--threads 1` so llvm modules are compiled one by one instead of in parallel
<FromGitter> <asterite> I see that Array is behind inherited, it might be the cause of the bug... not that you shouldn't do that, it's just that that thing isn't very well supported right now
<FromGitter> <toddsundsted> @asterite thanks for both hints!
<FromGitter> <toddsundsted> taking a look at that
<FromGitter> <toddsundsted> that might be it. temporarily replacing PaginatedArray with Array succeeds. going to see if i can create a small test case.
<FromGitter> <toddsundsted> actually, just removing the definition of PaginatedArray fixes the problem
<FromGitter> <naqvis> have someone tried running specs on cloned repository of 0.36.1? invoking specific or whole spec is yielding error ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ seems like a regression due to as it has changed `Finalizer` to `type` from `alias` []
alexherbo2 has joined #crystal-lang
<FromGitter> <asterite> Didn't it change from type to alias?
<FromGitter> <naqvis> oops sorry, saw it otherway around
<FromGitter> <Blacksmoke16> cant say im seeing any errors
<FromGitter> <Blacksmoke16> got the latest code?
<FromGitter> <asterite> I'm not seeing errors either. I just ran `bin/crystal spec spec/std/`
<FromGitter> <naqvis> yeah, that was the problem, just checked, i was working on older copy of code
<FromGitter> <Blacksmoke16> 👍
<FromGitter> <asterite> CI also compiles and a new compiler and runs the specs with it, so basically that's already tested
alexherbo2 has quit [Ping timeout: 256 seconds]
riffraff169 has joined #crystal-lang
<FromGitter> <Uzay-G> Hi, I'm trying to parse several GBs of data using a crystal program, but I've been getting some errors / what I think is a memory leak with the message `mmap(PROT_NONE) failed`. I saw this but I'm not sure if any fix was merged in. Is there some flag / method I could use to resolve the memory issues? Maybe should I use a temporary external storage solution I
<FromGitter> ... would call from crystal.
<FromGitter> <Blacksmoke16> are you doing like ``?
<FromGitter> <Uzay-G> yeah
<FromGitter> <Uzay-G> that closes the file after u call it no?
<FromGitter> <Uzay-G> is that wrong?
<FromGitter> <Blacksmoke16> i mean you're loading the entire contents of the file into memory at once
<FromGitter> <Blacksmoke16> using `` and doing something with the related `io` would be more performant
<FromGitter> <Blacksmoke16> like are you going line by line or?
<FromGitter> <Uzay-G> oh the files are split into several
<FromGitter> <Uzay-G> several 43 MB files
<FromGitter> <Uzay-G> it works for the first 80/100 files
<FromGitter> <Uzay-G> but the problem is along the execution of the program I'm saving a part of the file contents into a `Hash`
<FromGitter> <Uzay-G> which is getting bigger and bigger
<FromGitter> <Uzay-G> and then i dump that hash into a file at the end of the program but i can't really dump it midway because all of the data is related
<FromGitter> <Blacksmoke16> ah so cant write the file as you go?
<FromGitter> <Uzay-G> not really
<FromGitter> <Uzay-G> because the data is somewhat related
<FromGitter> <Uzay-G> so i might have info in the last chunk that would have changed what my result of parsing the first chunk
<FromGitter> <Blacksmoke16> are you doing anything fancy with what you're storing in the hash? One option might be to use IOs to read/write as you go to a tmp file, then at the end parse that temp file to build your final file?
<FromGitter> <Blacksmoke16> that way you have very minimal amount of data in memory at. time
_ht has quit [Remote host closed the connection]
<FromGitter> <Blacksmoke16> or tbh id just try doing what you're doing but use `` instead of `` then go from there
<FromGitter> <Uzay-G> > that way you have very minimal amount of data in memory at a time ⏎ but then when i build the final file wouldn't I have the same problem?
<FromGitter> <Uzay-G> > or tbh id just try doing what you're doing but use instead of then go from there
<FromGitter> <Uzay-G> i'll try that out, but so does that mean that doesn't close the file immediately after reading it? What would be the advantages of using
<FromGitter> <Blacksmoke16> it doesnt load all the file contents into memory at once. If you have a little example of what exactly you're doing with the files i could prob give a better example
<FromGitter> <Blacksmoke16> e.g. it would allow using like*args,**options,&block:String-%3E):Nil-instance-method
<FromGitter> <Blacksmoke16> so you only have 1 line in memory at a time. IDK if that'll work for your usecase, but is something to keep in mind
<FromGitter> <Blacksmoke16> and to be clear, i mean the block version of ``, which closes the file after yielding
<FromGitter> <wyhaines> Awesome.
<FromGitter> <Uzay-G> > so you only have 1 line in memory at a time. IDK if that'll work for your usecase, but is something to keep in mind
<FromGitter> <Uzay-G> ye that could work
<FromGitter> <Uzay-G> but im not sure if it's reading the files that causes a problem or the Hash with all of the data
<FromGitter> <Uzay-G> not sure how to resolve that part 💭
<FromGitter> <Blacksmoke16> step 1 would be seeing if the issue is with the files or the hash
<FromGitter> <Uzay-G> hmm just doing this (with the filenames as args gives me warnings):
<FromGitter> <Uzay-G> ```code paste, see link``` []
<FromGitter> <Uzay-G> ```May lead to memory leak and poor performance```
<FromGitter> <Blacksmoke16> do the files have everything on 1 line? :p
<FromGitter> <Uzay-G> no, they have lots of lines, but not on 1 line
<FromGitter> <Blacksmoke16> gotcha, interesting
<FromGitter> <Uzay-G> oh wait sorry that might just be my mistake actually
<FromGitter> <Uzay-G> ^ ignore this one sec
<FromGitter> <Blacksmoke16> 👌
<FromGitter> <Uzay-G> hmm it's a bit hard to parse a csv line by line 😅
<FromGitter> <Blacksmoke16>,separator:Char=DEFAULT_SEPARATOR,quote_char:Char=DEFAULT_QUOTE_CHAR,&)-class-method
<FromGitter> <Blacksmoke16> theres a `CSV` module in stdlib for this
<FromGitter> <Blacksmoke16> can pass `each_row` an `IO` as well
<FromGitter> <Uzay-G> ye im using the CSV module
<FromGitter> <Uzay-G> how does the IO work with the file?
<FromGitter> <Blacksmoke16> ```code paste, see link``` []
<FromGitter> <Uzay-G> ohh ok thanks!
<FromGitter> <Blacksmoke16> yea `File` inherits from `IO::FileDescriptor` which inherits from `IO` therefor `File` is an `IO`
<FromGitter> <franciscoadasme> hey everyone, I find out that `#flat_map` only concatenates if the return type of the block is either an Array or Iterator... why is that?, why not Enumerable or Indexable as well?
<FromGitter> <> @franciscoadasme: i dunno, maybe because 4 years ago was a simpler time, and supporting Iterator is better than not supporting it? ⏎
<FromGitter> <franciscoadasme> I don't follow... I meant that why concatenate only on Array and Iterator instead of simply Enumerable, (excerpt from Enumerable#flat_map) ⏎ ⏎ ```code paste, see link``` []
<FromGitter> <franciscoadasme> I was returning a Tuple in the block for `#flat_map` (to avoid intermediary arrays) and it returned `Array(Tuple(U, ...))` instead of `Array(U)` as one would expect
<FromGitter> <franciscoadasme> To me, an `Enumerable` is a collection of elements, so if I have a collection of collections of T and I flat it, I expect to get a collection of T (regardless of the concrete collection types)... does it make sense or am I missing something?
postmodern has joined #crystal-lang