<FromGitter>
<yxhuvud> oprypin: rather, python thinks 0 is false, and everything else is true.
<FromGitter>
<j8r> @yxhuvud except `None`
<FromGitter>
<yxhuvud> Ah, right.
alexherbo2668 is now known as alex2``
rohitpaulk has quit [Ping timeout: 246 seconds]
hightower2 has quit [Ping timeout: 246 seconds]
<FromGitter>
<fenicks> Hi everyone
<FromGitter>
<j8r> Hello the one that has a Crystal logo as avatar 😄
<FromGitter>
<fenicks> I'm using crystal-db with postgresql driver. I looking a way to use bulk/batch insert, any idea ? ConnectionPool looks not enough.
<FromGitter>
<fenicks> @j8r I felt in love. This logo is awesome !
tdc has quit [Quit: Leaving]
<FromGitter>
<straight-shoota> @fenicks You can build a statement using `Connection#build` and then call `Statement#exec`/`Statement#query` with each argument set
<FromGitter>
<straight-shoota> I don't think the postgres driver supports prepared statements yet, though.
<FromGitter>
<jwoertink> https://vlang.io/ "Fast compile, Hot Code Reloading, and a REPL". ... We've got some catching up to do! 😂
<FromGitter>
<fridgerator> I just saw vlang yesterday, looks awesome
rohitpaulk has joined #crystal-lang
<FromGitter>
<fridgerator> "V compiles ≈1.5 million lines of code per second per CPU core" and it can translace c / c++ into v !
<FromGitter>
<fridgerator> translate*
<FromGitter>
<fridgerator> the syntax though, looks inspired by Go quite a bit
<FromGitter>
<jwoertink> Yeah. Looks like it's a closed source language for now. Interesting concept though
<FromGitter>
<pynixwang> more like rust
<FromGitter>
<j8r> It's easy to say that for vlang, they haven't provided anything as for now
<FromGitter>
<j8r> It uses dynamically linked libraries for this
laaron has quit [Ping timeout: 256 seconds]
<FromGitter>
<pynixwang> we need a real repl
<FromGitter>
<fenicks> > @fenicks You can build a statement using `Connection#build` and then call `Statement#exec`/`Statement#query` with each argument set ⏎ ⏎ Will try. Thanks
rohitpaulk has quit [Remote host closed the connection]
<FromGitter>
<bew> @j8r you could do it in Crystal too, i saw a simple poc with hot reloading once, in Crystal
<FromGitter>
<bew> You need to organize your program in a certain way, be able to isolate the state, the inputs, etc.. And routines to unload, reload another vers
<FromGitter>
<bew> Version of the lib, etc..
<FromGitter>
<girng> looks like rust and golang had a baby
<FromGitter>
<jwoertink> When using `expect_raises`, it's a regex for the second arg to say the error should contain "this", right?
<FromGitter>
<jwoertink> I just want to make sure that the error contains something, but not that it's necessarily equal to something
<FromGitter>
<jwoertink> oh, ok. Looks like I needed `Regex.new(my_string)`. I must have had the regex wrong.
<FromGitter>
<Blacksmoke16> @jwoertink it can either be a string or regex
<FromGitter>
<Blacksmoke16> would test message is exactly `Ops`, or could do `expect_raises(Exception, /.*Ops.*/) { raise Exception.new("Ops") }` which would be like contains `Ops`
<FromGitter>
<kinxer> @Blacksmoke16 Hey, serialization wizard, does Crystal have a way to serialize a class constant and verify its presence and equality during deserialization?
<FromGitter>
<Blacksmoke16> i mean not by default but its possible to tap into the serialization process and add them/do your check there
<FromGitter>
<Blacksmoke16> are you using JSON::Serializable?
<FromGitter>
<kinxer> I know that constant access works a bit differently (it would `Example::TYPE`), but I think that gives a basic idea of what I want.
<FromGitter>
<kinxer> I'm writing a GeoJSON (http://geojson.org/) parsing and creation library, and I've been using a standard assigned `getter`, but the string should really just be the same for every instance, so I'm using unnecessary memory.
<FromGitter>
<Blacksmoke16> whats the expected behavior of deserializing that first object with the `type` field?
<FromGitter>
<kinxer> Ideally, it would be to raise an error if the `type` field didn't match the value of `TYPE`.
<FromGitter>
<Blacksmoke16> ah thats what i wanted to know
<FromGitter>
<Blacksmoke16> prob might even be able to to define that on a parent class and just would be inherited by other types
<FromGitter>
<kinxer> That's cool. Thank you.
<FromGitter>
<Blacksmoke16> np, ofc those errors would be at runtime
<FromGitter>
<kinxer> You can even tweak it to work with `JSON::Serializable::Strict` and `JSON::Serializable::Unmapped`: https://play.crystal-lang.org/#/r/6sj8
<FromGitter>
<kinxer> I mean, yeah. But that's gonna have to be the case when deserializing and serializing stuff anyway.
<FromGitter>
<Blacksmoke16> @dscottboggs_gitlab was doing something with instantiating a specific object based on the key of a field in the JSON as well, he might have some ideas as well since it seems to be a similar setup?
<FromGitter>
<kinxer> I'd be interested to hear about that. My biggest hurdle with this library has been deserializing geometries whose `coordinates` fields have different levels of nested arrays (without requiring that `type` be the first field, which isn't supposed to be necessary when handling JSON).
<FromGitter>
<Blacksmoke16> yea for sure, seems it would be quite helpful
alex2``3 has joined #crystal-lang
alex2`` has quit [Ping timeout: 258 seconds]
alex2``33 has joined #crystal-lang
alex2``3 has quit [Ping timeout: 250 seconds]
<FromGitter>
<kinxer> Something to consider: your solution will always put the `type` field at the end of the serialized object, which is the opposite of where you usually want it. Again, it's JSON, so it "doesn't matter", but it's a lot easier to read (as a human) if the `type`is at the beginning.
<FromGitter>
<Blacksmoke16> then you would have to implement your own `to_json` afaik
<FromGitter>
<Blacksmoke16> since that method runs after the standard `to_json` @kinxer
<FromGitter>
<kinxer> Yeah, I figured it would be something like that. For now I'm probably going to stick with a normal `getter`, but I'll have to think about this more.
<FromGitter>
<Blacksmoke16> in *that* case you could still do what you want
<FromGitter>
<Blacksmoke16> sec
<FromGitter>
<kinxer> Oh, I already have an implementation with a normal `getter`.
<FromGitter>
<kinxer> Technically it doesn't have `type` parameter checking, though.
<FromGitter>
<kinxer> 'Cause I have an abstract `Geometry` superclass that uses the `type` to determine what subclass to instantiate.