<postmodern>
kind of wish there was a .not_nil! that accepted a block. The crystal compiler can't infer that `unless @ptr.nil?` implies @ptr is not `Pointer | Nil` within the `unless`.
<FromGitter>
<Blacksmoke16> `@ptr.try { |ptr| }`?
<postmodern>
awesome, exactly what i needed
<postmodern>
oprypin, just curious if you have a link handy for how you test the #finalize method?
<FromGitter>
<oprypin:matrix.org> postmodern, u mean like unittests? i don't, lol
<FromGitter>
<oprypin:matrix.org> u can print something to the screen if you just want to try it out
<postmodern>
was thinking i'd probably have to use mocks/stubs, but then that gets complex.
<postmodern>
can you call other instance methods from within #finalize ?
<FromGitter>
<Blacksmoke16> i dont see why not, its just an instance method
<FromGitter>
<oprypin:matrix.org> postmodern, the answer to *all* such "can you" questions is the same as "can you do it from within #foo ?"
<FromGitter>
<oprypin:matrix.org> the method is completely normal and the state of the object is completely normal. *and then* the memory deallocation happens
deavmi has quit [Ping timeout: 272 seconds]
<repo>
hey, quick question: are HTTP::Clients thread safe?
<FromGitter>
<Blacksmoke16> i doubt it
<repo>
mh
<repo>
that's a bummer :D
<repo>
what's the constant for the number of crystal threads again?
<repo>
CRYSTAL_THREADS? :D
<FromGitter>
<Blacksmoke16> `CRYSTAL_WORKERS`
<FromGitter>
<oprypin:matrix.org> repo, why not just create a new client every time
<repo>
because i want to reuse the client
<repo>
thanks Blacksmoke16
<FromGitter>
<oprypin:matrix.org> repo, what do you mean lol, "i want" is not a reason
<repo>
tls handshakes are slow
<FromGitter>
<oprypin:matrix.org> oo does it reuse established tls connection? nice
<FromGitter>
<oprypin:matrix.org> anyway, it's super not thread safe
<repo>
sure
<repo>
no prob. will just create one for each thread then
<FromGitter>
<jrei:matrix.org> you could also use a pool
<FromGitter>
<jrei:matrix.org> not sure if HTTP::Client is fiber-safe
<FromGitter>
<Blacksmoke16> its not
<FromGitter>
<jrei:matrix.org> only one request has to be done at a time
<FromGitter>
<oprypin:matrix.org> but it doesn't need to be fiber safe
<FromGitter>
<oprypin:matrix.org> yes a pool is the right solution. it doesn't need threads at all
<repo>
is a pool something built into crystal?
<repo>
or do you generally just mean a thread pool
<FromGitter>
<oprypin:matrix.org> no
<FromGitter>
<Blacksmoke16> to be clear threads and fibers aren't the same thing
<FromGitter>
<oprypin:matrix.org> repo, threads are only a distraction, although sure, in a roundabout way you *can* arrive to some solution using them
<repo>
right
<repo>
yeah
<FromGitter>
<oprypin:matrix.org> u need a pool of clients and so a pool of fibers running them
<FromGitter>
<oprypin:matrix.org> CRYSTAL_WORKERS is irrelevant in the same way cuz it's about threads
<FromGitter>
<jrei:matrix.org> Dude no neet to reinvent the pool repo ;)
<FromGitter>
<jrei:matrix.org> It is *very* basic though
<repo>
yeah :D
<repo>
didn't know about that shard though
<FromGitter>
<jrei:matrix.org> It is quite new yes. There is also crystal-db which has a more advanced one
<repo>
ah cool it lazily creates the items
<repo>
what's the default idle size?
<repo>
"Note that if an exception was raised in the block, the resource won't be added back. This behavior is used to prevent adding an invalid resource, for example a connection causing an IO error."
<repo>
ah sweet
<FromGitter>
<oprypin:matrix.org> i think it instantiates all N connections from the start
<repo>
that's really useful. thanks!
<repo>
ok
<FromGitter>
<jrei:matrix.org> That's right
<FromGitter>
<jrei:matrix.org> I prefered a safe by default behavior, vs fast and unsafe.
<FromGitter>
<jrei:matrix.org> Hum, not 100% sure, a race condition might happen when the hash is written and read at the same time?
<FromGitter>
<jrei:matrix.org> Seems unlikely
<repo>
yeah that was my fear
<FromGitter>
<jrei:matrix.org> Anyway do you really need a hash?
<FromGitter>
<jrei:matrix.org> The domains and tls varies?
<FromGitter>
<jrei:matrix.org> No need for the ||= in your code. I guess you're right, putting the fetch and add on a mutex will be safer...
<repo>
yeah it varies
<repo>
i'm writing a service for on the fly image scaling from arbitrary (white listed) urls
<FromGitter>
<jrei:matrix.org> The hash can only grow though...
<repo>
yeah but in any sane environment you will white list a few urls (or patterns)
<FromGitter>
<jrei:matrix.org> If this urls are known at compile-time, you could avoid all this mutex/logic thing
<repo>
they're not :)
<repo>
also i allow patterns
<repo>
something like `/^.*\.my-domain\.com$/`
<FromGitter>
<jrei:matrix.org> I'm afraid of having an app growing in memory
<FromGitter>
<jrei:matrix.org> Anyway, premature optimization for this thought
<repo>
:)
<repo>
i guess
<repo>
it turned out pretty neat though. handles caching of both originals and conversions based on cache control and expires headers and the params of the conversions
<raz>
sounds too good to be true. but if it works, that would be amazing
<FromGitter>
<djberg96> confused about ECR.embed and relative paths
<FromGitter>
<djberg96> I've got a project with `src/foo.cr` and it uses `ECR.embed` with templates located under `src/templates`
<FromGitter>
<djberg96> i originally did `ECR.embed("./src/templates/check_sizeof.ecr", io)` thinking the "./" would make it relative to its calling location, but that doesn't seem to work if a dependency tries to use it
<FromGitter>
<djberg96> what's the right way? use *DIR*?
<FromGitter>
<djberg96> nm, figured it out
Xeago has joined #crystal-lang
deavmi has quit [Read error: Connection reset by peer]
deavmi has joined #crystal-lang
<FromGitter>
<roduquen> Hi guys, someone is using cryomongo ?
<repo>
hey!
<repo>
raz: yeah i am
<repo>
uh roduquen
<repo>
quick question: is it possible somehow to free up a crystal object without having to wait for GC?
<FromGitter>
<naqvis> free up in what sense?
<FromGitter>
<jrei:matrix.org> you usually not have to do this
<repo>
i allocate a lot of memory really quickly and it seems the gc can't keep up
<repo>
can i somehow use two shards with the same name? e.g. alias them or something?
<repo>
i use j8s/pool but also ysbaddaden/pool
<repo>
the latter is a dependency of crystal-redis
<FromGitter>
<Blacksmoke16> are the types not namespaced?
<FromGitter>
<Blacksmoke16> nope, you're out of luck
<repo>
:(
<repo>
that's really annoying
<FromGitter>
<Blacksmoke16> mhm, this is why namespacing stuff is useful
<FromGitter>
<naqvis> you can consider using `WeakRef` and invoking `GC.collect` to request GC to collect the garbage
<repo>
naqvis: mh ok but that would result in a complete GC run, right?
<FromGitter>
<naqvis> true
<FromGitter>
<naqvis> if you need selective control then you better use custom allocator and de-allocator
<FromGitter>
<naqvis> but that definitely beats the purpose of GC
<FromGitter>
<naqvis> for memory intensive operations, you can consider having custom allocator and de-allocator
<FromGitter>
<jrei:matrix.org> btw why do you *need* this repo?
<repo>
naqvis: how would that work?
<FromGitter>
<Blacksmoke16> @jrei:matrix.org the other pool lib is a dep of a redis shard
<repo>
jrei: i'm converting images, which requires me to load the entire image into memory
<FromGitter>
<jrei:matrix.org> @Blacksmoke16: you mean the redis shard depends on the pool of crystal-db? Yeah
<FromGitter>
<jrei:matrix.org> why do you say that?
<FromGitter>
<jrei:matrix.org> repo: ok, but let the GC deal with this
<repo>
jrei: the process get's killed
<FromGitter>
<Blacksmoke16> repo, can you not do that and use `IO`s?
<FromGitter>
<jrei:matrix.org> you know sometimes a GC is even faster than malloc/free a lot
<repo>
Blacksmoke16: i wish
<repo>
but no
<FromGitter>
<Blacksmoke16> rip
<FromGitter>
<jrei:matrix.org> not sure it is because of the GC...
<repo>
yeah sure, could be something else
<FromGitter>
<naqvis> > *<repo>* @naqvis: how would that work? ⏎ ⏎ Take a look at `GC` module and methods of interest to you would be `malloc_atomic` and `free`
<FromGitter>
<jrei:matrix.org> try calling GC.collect in strategic places if it imrpoves the situation
<repo>
how long would a GC run usually take?
<repo>
i understand it's a very unspecific question
<repo>
i'm just looking for a ballpark figure
<FromGitter>
<jrei:matrix.org> depends of how many objects, and how much work it has to do
<FromGitter>
<jrei:matrix.org> that's just to know if it is because of the GC
<FromGitter>
<jrei:matrix.org> maybe you're reaching the max memory of a crystal program
<FromGitter>
<jrei:matrix.org> AFAIK there is one
<repo>
jrei: not during a single conversion
<repo>
it happens when a lot of them come in
<FromGitter>
<naqvis> AFAIK Boehm GC used by Crystal is MT enabled and GC takes up all other cores except 1 (which is used by Crystal main thread - assuming you are running crystal in ST mode), so whole GC process should be quite fast
<FromGitter>
<jrei:matrix.org> repo: > Pause times below 1/10th of a second are often the case, and applications with relatively small live sets (or slowly changing live sets, for generational collector) can obtain pause times below 1/100th of a second.
<FromGitter>
<naqvis> thing you should consider is the scope of variables your program is holding to reference to memory
<FromGitter>
<naqvis> as GC won't be collecting memory to which there is still a valid reference
<repo>
that's clear
<FromGitter>
<jrei:matrix.org> bdwgc is compiled with `--enable-large-config`
<FromGitter>
<naqvis> so you were suggested to consider use `WeakRef` or similar approach
<FromGitter>
<jrei:matrix.org> maybe in your case using multiple app instances will be better than multi-thread...
<FromGitter>
<jrei:matrix.org> one app per core, more so if the app is relatively-stateless
<FromGitter>
<jrei:matrix.org> and have a Load Balancer in front
<FromGitter>
<jrei:matrix.org> it will be more stable (MT still in preview), faster, and higher availability in case of a crash
_ht has quit [Remote host closed the connection]
<FromGitter>
<rukkiddo> I want to generate secure session ids for my cookies, I am planning something like sha256 of ip + username + timestamp + (random string or uuid)
<FromGitter>
<rukkiddo> is this secure enough?
<FromGitter>
<Blacksmoke16> prob not
<FromGitter>
<Blacksmoke16> could just generate a JWT or something, kill 2 birds with one stone
<FromGitter>
<Blacksmoke16> ah nvm, missed last uuid arg, that would help
<oprypin>
Blacksmoke16, depends if that string is static or not. seems like the suggestion is static. cuz if it's random every time then what's the point of all the other parts lol
<FromGitter>
<Blacksmoke16> i should hope it wouldnt be static
<FromGitter>
<Blacksmoke16> but yea, good point
<FromGitter>
<rukkiddo> it wont be static, I thought I would add it to make sure it is unique
<FromGitter>
<rukkiddo> i actually read from stackoverflow that php does it like this
<FromGitter>
<rukkiddo> let me rephrase
<FromGitter>
<rukkiddo> i mean random string is not static
<FromGitter>
<rukkiddo> other parts supposed to make it unique
<FromGitter>
<jrei:matrix.org> just uuid will be enough
<FromGitter>
<jrei:matrix.org> the collision probability is fairly small, unless you're designing a system at a big scale
<FromGitter>
<rukkiddo> probably i will never have a collision since my system is not big
<FromGitter>
<rukkiddo> but still it is bugging me
<FromGitter>
<rukkiddo> uuid already takes timestamp into calculation right? it already will be unique
<FromGitter>
<rukkiddo> I didnt know there are verisons of uuid actually