<sorcus>
Mmm, initialized with `Pointer` and `malloc`. Then it be passed to LLVM? Or not. Oh, that fucking bug with large arrays X-)
<sorcus>
tenebrousedge: I mean a code part, where array allocated on memory via LLVM.
<sorcus>
tenebrousedge: i'm tried to understand how it works. X-)
<sorcus>
:-D
<sorcus>
Even in Rust nobody cares slow compilation with large arrays. :-D :-D :-D
HumanG33k has quit [Quit: Leaving]
return0e_ has joined #crystal-lang
return0e has quit [Ping timeout: 240 seconds]
<sorcus>
Ok, it's very slow because there is a lots of calls like `%131071 = call i32 @"*Pointer(Int32)@Pointer(T)#[]=<Int32, Int32>:Int32"(i32* %131070, i32 65532, i32 9)` which equal to `alloca` - right?
baweaver has quit [Excess Flood]
masterdonx2 has quit [Read error: Connection reset by peer]
baweaver has joined #crystal-lang
MasterdonX has joined #crystal-lang
raz has quit [Ping timeout: 250 seconds]
raz has joined #crystal-lang
<sorcus>
Ok, enough on today. Sweet dreams. :-)
Nicolab has quit [Quit: Leaving.]
<FromGitter>
<watzon> Well @jwoertink I'm working on something. We'll see how it turns out.
<FromGitter>
<stnluu_twitter> looking at the directives
* FromGitter
* tenebrousedge nods
<FromGitter>
<stnluu_twitter> looks like the main use-case is to pack shit for easier transport?
<FromGitter>
<stnluu_twitter> trying to think of a legit use case where there isn't a cleaner less esoteric solution
<FromGitter>
<tenebrousedge> it also converts between endianness
<FromGitter>
<tenebrousedge> you could think of it as an extremely concise "DSL" for byte translation
<FromGitter>
<stnluu_twitter> yeah, "DSL" is the scary part
<FromGitter>
<stnluu_twitter> on that front, i tend to agree with the golang philosophy of sticking with the primitives
<FromGitter>
<stnluu_twitter> but anyway
<FromGitter>
<tenebrousedge> golang makes me break out in a rash
<FromGitter>
<stnluu_twitter> if people like it then people like it
<FromGitter>
<stnluu_twitter> :D
<FromGitter>
<stnluu_twitter> ^ referring to pack
* FromGitter
* tenebrousedge shrugs
<FromGitter>
<tenebrousedge> I think I've maybe used it in anger once
<FromGitter>
<straight-shoota> You do realize that you can do the same things in Crystal with `IO`? It even results in more performant and better readable code.
<FromGitter>
<stnluu_twitter> debugging at 2AM, `normalize_endianness(x)` is a easier to follow than `x.pack("DSL")`
<FromGitter>
<grkek> this is the playground I am referring to
<FromGitter>
<watzon> So I've done my playing around with `String#unpack` in Crystal, and I can definitely understand why it's not a thing in most compiled languages. Now I'm trying to play around with a different syntax. Something more friendly and versatile than `IO::ByteFormat`, but while still keeping things typing friendly.
<FromGitter>
<grkek> \\0\ is not correct in the context or gets just de-serialized improperly
<FromGitter>
<watzon> It returns a 500 error with that input?
<FromGitter>
<grkek> yeah
<FromGitter>
<grkek> it is open source the web site right ?
<FromGitter>
<grkek> where do I find the source of the webserver again
<FromGitter>
<watzon> Yeah it must be getting deserialized improperly. I think @jwoertink made an issue in the carc.in repo, you may want to check there
<FromGitter>
<grkek> it has a cute little stack trace inspector
<FromGitter>
<grkek> let me run it locally and try the same thing
<FromGitter>
<watzon> That's a nifty syntax
<FromGitter>
<watzon> I love what you can do with Crystal, I really do
<FromGitter>
<grkek> do you use ameba ?
<FromGitter>
<grkek> it literally forces you to write like that
<FromGitter>
<grkek> it is very useful
<FromGitter>
<watzon> Yeah, I love it. I use it for some of my bigger projects.
<FromGitter>
<watzon> Like Rubocop, it's wonderful
<FromGitter>
<grkek> > author_ip VARCHAR(39) NOT NULL,
<FromGitter>
<grkek> why does carc.in need an ip collection
<FromGitter>
<watzon> That's a good question
<FromGitter>
<grkek> these days all the people want is to rip someone off and collect tons of info
<FromGitter>
<grkek> that is bullshit which is not needed for an online playground of a language
<FromGitter>
<grkek> it is not used for single IP access because I know you can edit others posts
<FromGitter>
<grkek> right ?
<FromGitter>
<grkek> if it were used it would be justifiable but now it is not at all
<FromGitter>
<Daniel-Worrall> Because sometimes you need to be able to track/block/report/coveryourass when someone posts something really... not what you want on a public repository
<FromGitter>
<grkek> and the IP is a varchar of 39
<FromGitter>
<watzon> Yeah I can't really see anywhere in the repo where it's actually being used
<FromGitter>
<watzon> But also true
<FromGitter>
<grkek> You dont need to track anyone you can just delete the repo
<FromGitter>
<grkek> post*
<FromGitter>
<grkek> 1) you have logging beforehand
<FromGitter>
<grkek> instead of saving it in the db you have logs
<FromGitter>
<grkek> like apache2 does
<FromGitter>
<grkek> you filter through them and find the abuser
<FromGitter>
<grkek> and bam block him
<FromGitter>
<grkek> Don't save data which you dont need in a database
<FromGitter>
<grkek> databases aren't for logging requests :D
<FromGitter>
<watzon> Might be worth asking in an issue
<FromGitter>
<grkek> I was into cyber security before I got into programming
<FromGitter>
<grkek> I know a lot about tracking / blocking / abuse detection
<FromGitter>
<grkek> etc
<FromGitter>
<grkek> this seems like an useless data collection to me as long as it is not an unique identifier to a post which can only be edited by the author
<FromGitter>
<grkek> if it is then I will be glad for that feature and give my ip to the author
<FromGitter>
<grkek> 😸
DTZUZO_ has quit [Ping timeout: 265 seconds]
<FromGitter>
<watzon> It's possible that that's planned, but I think something a little more unique than an IP would definitely be better
<FromGitter>
<watzon> Who knows though
<FromGitter>
<grkek> an UUID
<FromGitter>
<grkek> is enough atm tbh
<FromGitter>
<grkek> unique enough and can be stored without breaching someones privacy
<FromGitter>
<grkek> as in IP
<FromGitter>
<grkek> seems like I need to use btrfs to run sandbox on
<FromGitter>
<grkek> Seems like the stdout is treated as string
<FromGitter>
<grkek> as a string
<FromGitter>
<grkek> will that cause problems ?
<FromGitter>
<grkek> I am not pretty sure how the char::zero gets handled
<FromGitter>
<grkek> after compilation
<FromGitter>
<grkek> As far as I can see the only issue is the stdout string handling
daemonwrangler has quit [Ping timeout: 245 seconds]
Nekka_ has joined #crystal-lang
Flipez4 has joined #crystal-lang
Nekka has quit [Quit: zzz]
Flipez has quit [Quit: Ping timeout (120 seconds)]
woodruffw has quit [Ping timeout: 265 seconds]
Flipez4 is now known as Flipez
Nekka_ is now known as Nekka
<FromGitter>
<zbaylin> Is there a way to enforce the order specs are executed in? For instance, if I have a database request that's dependent on another spec in a different file.
<FromGitter>
<tenebrousedge> are you using spectator?
woodruffw has joined #crystal-lang
<FromGitter>
<zbaylin> No just `crystal spec`
<FromGitter>
<zbaylin> But I can use spectator
<FromGitter>
<zbaylin> Does that lib give me this option?
<FromGitter>
<tenebrousedge> it lets you do `before_each` and `before_all`
daemonwrangler has joined #crystal-lang
return0e has quit [Remote host closed the connection]
<FromGitter>
<tenebrousedge> and it gives you `let`
return0e has joined #crystal-lang
<FromGitter>
<tenebrousedge> specs should usually be order-independent. I think by default spectator will run in a defined order, but it has a wide toolset that should hopefully help you out with writing that either way
<FromGitter>
<Blacksmoke16> `before_each` and others are in the stdlib now
<FromGitter>
<tenebrousedge> `let` too?
<FromGitter>
<Blacksmoke16> no
<FromGitter>
<tenebrousedge> :/
<FromGitter>
<Blacksmoke16> id be more advised to say refactor you specs so that one spec doesnt depend on another
<FromGitter>
<Blacksmoke16> inclined*
zorp has joined #crystal-lang
daemonwrangler has quit [Ping timeout: 258 seconds]
<FromGitter>
<Blacksmoke16> or maybe extract that to a bit higher level and just pass in the value, or raising an exception if a value could not be parsed from the request?
<FromGitter>
<Blacksmoke16> TBD :p
daemonwrangler has quit [Ping timeout: 268 seconds]
daemonwrangler has joined #crystal-lang
daemonwrangler has quit [Ping timeout: 265 seconds]
twistedpixels has quit [Ping timeout: 265 seconds]
<FromGitter>
<stnluu_twitter> @Blacksmoke16 yeah... i wonder where that begin is from
<sorcus>
Blacksmoke16: I'm sorry too, because english not my mother tongue. And sometimes i don't understand fully some messages X-) And my grammar is soooo ugly. :-( :-( :-(
daemonwrangler has joined #crystal-lang
<FromGitter>
<Blacksmoke16> all good
<FromGitter>
<tenebrousedge> it's fine
<FromGitter>
<tenebrousedge> English grammar is always ugly
<sorcus>
:-D
<FromGitter>
<Blacksmoke16> so like i could catch the `ArgumentError` when i call `.convert`, however the error would have to be generic since i would lack access to any of the context, like the name of the param, or its value etc
<FromGitter>
<Blacksmoke16> but i suppose i should do that, at least would be better default behavior than a 500
<FromGitter>
<stnluu_twitter> @Blacksmoke16
<FromGitter>
<tenebrousedge> “The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.”