<FromGitter>
<aboeglin> A NamedTuple is pretty much a Hash, except the structure is fixed, but it's not like the structure of your table will change during execution so it should be fine and more suitable than a Hash for that task.
<FromGitter>
<j8r> or else a struct
<FromGitter>
<aboeglin> @drum445 so basically the little example I put above should be valid, I'll try that when I get a chance, you have an overload for un-named tuples as well, so you'd just give it the types without names, so you'd have the respect the order of the columns like you probably do right now.
<FromGitter>
<aboeglin> I'm not sure you have splats for struct or hash
<FromGitter>
<aboeglin> I think it's pretty much a tuple operator
<FromGitter>
<j8r> for `**` yes
<FromGitter>
<j8r> `**` namedtuple, and `*` tuple
<FromGitter>
<fusillicode_twitter> @j8r I'm wondering why structs are usually favored & suggested in place of tuples 🤔
<FromGitter>
<fusillicode_twitter> personally I find named tuples more flexible to use when you're dealing with just value objects
<FromGitter>
<aboeglin> so the read method wouldn't take a struct
<FromGitter>
<fusillicode_twitter> for example they can be merged :)
<FromGitter>
<aboeglin> @fusillicode_twitter do you have a sample code to show merging of tuples ?
<FromGitter>
<aboeglin> you mean like {key: value, **tuple} ?
<jokke>
this of course can be put into a neat little macro
<FromGitter>
<fusillicode_twitter> I know that `Crest` gives some facilities from this point of view (and not only) but right now I'm using the standard HTTP::Client and I don't know how much time it would cost me to switch to Crest :(
<jokke>
but to be honest it's really hard to detect if something is a file or not in a general way without knowing anything about the request
<jokke>
you could check if filename is set
<jokke>
but i'm not sure if all clients do this
<FromGitter>
<fusillicode_twitter> mmm
<FromGitter>
<fusillicode_twitter> let me check one thing
<jokke>
i'm currently writing a sort of file bin. like a pastebin where you can upload pretty much anything and i decided not to support multipart uploads and use raw binary bodies instead
<FromGitter>
<fusillicode_twitter> well it makes sort of sense
<jokke>
it will have some overhead on multi-file uploads but keep-alive will take care of most of that
<FromGitter>
<fusillicode_twitter> got it...but...how will be handled the upload with just the raw binary body? 🤔
<jokke>
you mean on client side?
<FromGitter>
<fusillicode_twitter> yep
<jokke>
not without js
<jokke>
:/
<FromGitter>
<j8r> my application segfault :(
<FromGitter>
<fusillicode_twitter> my use case is to pick a file from the internet and send it to another api
<FromGitter>
<j8r> Inside a Docker Alpine, I `crystal build --static --link-flags "-lcrypto -lz" src/dppm.cr` https://github.com/DFabric/dppm
<FromGitter>
<j8r> Halite is often a bit too overengineered, crest isn't as type safe because of the use of Symbols
<FromGitter>
<fusillicode_twitter> wow these are really nice insights!
<FromGitter>
<j8r> I use it like `response = Cossack::Client.new(&.use Cossack::RedirectionMiddleware).get url`
<FromGitter>
<fusillicode_twitter> mmm
<FromGitter>
<j8r> but you can use post, sure
<FromGitter>
<fusillicode_twitter> well I would actually need to perform json posts and multipart form uploads together with logging
DTZUZO has joined #crystal-lang
<FromGitter>
<fusillicode_twitter> to me it seems that both halite and crest were pretty good from the logging point of view but I didn't find anything explicitly documented regarding generating separate requests and responses objects
<FromGitter>
<fusillicode_twitter> (I took a look inside Halite source and I saw the `Halite::Request` but the I didn't actually saw how it can be passed and performed to the client)
<FromGitter>
<fusillicode_twitter> It seems that with Crossack I'll need to build a custom logger middleware :(
<FromGitter>
<fusillicode_twitter> and moreover it doesn't have any hint about multipart upload :(
DTZUZO has quit [Quit: WeeChat 2.0]
<FromGitter>
<j8r> it's more basic
<FromGitter>
<fusillicode_twitter> got it
DTZUZO has joined #crystal-lang
<FromGitter>
<j8r> crest and halite are good too, halite are loads of features
DTZUZO_ has joined #crystal-lang
DTZUZO has quit [Ping timeout: 252 seconds]
Heaven31415 has joined #crystal-lang
<Heaven31415>
Hi
<Heaven31415>
Is it okay to call #initialize on some object to recreate it?
<jhass>
I wouldn't say that's a contract anybody really follows for it
<jhass>
so it'd only work by luck
<RX14>
it's likely to work for most objects
<RX14>
given that #initialize assumes the class is garbage data
<jhass>
mh do we actually move class level initializers to #initialize somehow?
<RX14>
i think we do
<RX14>
i'm 80% sure thats how its desugared
<RX14>
given that .new really is just .allocate, #initialize then register the finalizer
<jhass>
still, #allocate shouldn't be that expensive to be really worth to avoid
<RX14>
yeah
<FromGitter>
<fusillicode_twitter> @j8r I think that I've found what Halite is missing XD
<FromGitter>
<fusillicode_twitter> i.e. the possibility to separately a request and let it be performed by an http client
<FromGitter>
<fusillicode_twitter> Crest does have it though
non-aristotelian has joined #crystal-lang
<FromGitter>
<fusillicode_twitter> but I'm really really sad that Halite is missing this fundamental feature :'(
<FromGitter>
<bew> RX14 I noticed a few days ago that initialize is protected, and can't be called from the outside, it's very annoying when you want to initialize some garbage memory (need to manually create a method that calls initialize).
<RX14>
you really shouldnt need to call that from the outside
<FromGitter>
<bew> Don't you think it should be public for this kind of application?
<RX14>
what kind of application
<FromGitter>
<bew> But what if I actually need to? (i know, I'm doing some unsafe stuff, but the language shouldn't block me..)
<RX14>
"i need to" isn't a usecase
<FromGitter>
<bew> I was thinking about an ObjectPool, that pre-alloc a lot of classes (in one GC call), and initialize each one of them on demand
<RX14>
thats called a GC
<RX14>
except it handles multiple different class types
<RX14>
so it's actually better
<FromGitter>
<bew> Yes but no, isn't it slow when you alloc 10000 classes or so?
<FromGitter>
<Blacksmoke16> if you have two modules that define a method with the same name, is there a way to pick which one is used if you include both
<RX14>
order the include definitions
<FromGitter>
<Blacksmoke16> oh, easy enough
<FromGitter>
<Blacksmoke16> cheers
<FromGitter>
<Blacksmoke16> https://play.crystal-lang.org/#/r/57v5 shouldnt this print `{"name": "bar"}` then since it should be using the `JSON::Serialization` method?
<FromGitter>
<Blacksmoke16> yea, will use my `to_json` no matter the order
<RX14>
oh sorry i misread
<RX14>
yeah
<FromGitter>
<bew> Looks weird, because `to_json` is defined on Object iirc, no?
<RX14>
thats because you should be overriding to_json(builder)
<RX14>
the to_json with no args is defined ob object
<RX14>
so JSON::Serializable and your Serialize are defining different methods
<RX14>
so neither will win, both will exist
<jhass>
@bew what's slow is getting memory from the OS, so most if not all GCs get bigger chunks at a time and then assign parts of those as you request memory
<RX14>
@Blacksmoke16 you can still do it with tuples
<RX14>
just define to_json(builder) and use {"name2": @name}.to_json(builder)
<FromGitter>
<Blacksmoke16> gotcha, makes it a bit cleaner
<FromGitter>
<bew> That's right @jhass, and that's also part of why we use a GC, but I wanted to try to release the pressure on the GC for the specific case where you know you want a lot of instances of a specific data class (big or small)
<jhass>
why not just set GC_INITIAL_HEAP_SIZE?
<Yxhuvud>
bew: if you want to do hacks with allocation, it's allocate you'd want to do strange stuff in, not initialize. initialize is just like, take this memory area that was recently allocated (as far as it know), and make certain the data in it make sense.
<Yxhuvud>
(or in `new`, I suppose)
<Yxhuvud>
jhass: another reason to allocate in large chunks in advance can be to improve memory locality for the stuff you allocate
<Yxhuvud>
which is dead easy for structs, but not as simple for objects
<FromGitter>
<j8r> mainly for yaml and json serialization
<FromGitter>
<j8r> hummm half is used for specs, interesting! `Union(Float32, Array(Int32)).from_json(%(1.23)).should eq(1.23_f32)`
<FromGitter>
<Sija> @vladfaust I take this as an example of flattening unions, not as idiomatic writing, in the end `Union` is defined with `*T` arguments meaning a splat - flattening is just a convenient shortcut
<FromGitter>
<vladfaust> Okay, I see
<Heaven31415>
Is it intentional that some C functions doesn't have bindings, like usleep and sleep? Probably because they are dangerous?
<jhass>
In general you shouldn't need to do any direct LibC calls unless you're building an abstraction for those
<jhass>
stdlib should have you covered for most usecases
<FromGitter>
<j8r> to avoid to specify `@x : Int32`?
<Heaven31415>
Exactly! I obviously don't know how compiler works, but from human perspective it looks very clear what type should be deduced, probably it's difficult to do because of how methods are instantiated
<FromGitter>
<ljuti> @straight-shoota Thanks! It’ll probably be just what I need
DTZUZO_ has quit [Ping timeout: 252 seconds]
<FromGitter>
<vladfaust> Just want to share some progress. I can say that Atom is almost ready. I still need to add docs, website and stuff to it, but CrystalJobs is working on Atom right now on my local machine, and it's working good! For sure, API will be updated to work with Jobs themselves until this Sunday, but front-end would take 1-3 days more... ⏎ ⏎ Take a look at the development branch and get amazed by amount of code