<FromGitter>
<krthr> Yup. I'm using Procs... I want to make something like (simple version of) of n8n or IFTTT
<FromGitter>
<Blacksmoke16> whats an example of the API you want?
<ryanprior>
Sounds cool krthr. I've done similar things using channels.
<ryanprior>
If you write your blocks/components to take an input channel and output channel as arguments, then you can chain things up and create all sorts of cool little pipelines.
<FromGitter>
<krthr> For example, providing the posibility to build a flow (visual programming) and executing it in the back. I could use it in my company...
<FromGitter>
<Blacksmoke16> i mean example code
<FromGitter>
<Blacksmoke16> like what is `A`?
<FromGitter>
<krthr> > *<ryanprior>* If you write your blocks/components to take an input channel and output channel as arguments, then you can chain things up and create all sorts of cool little pipelines. ⏎ ⏎ Yeah. That's the idea... And it would also be cool to publish different blocks with different functions. For example: send a mail, get a file, consume http, etc.
<oprypin>
so the duality of yielding functions and arrays
<FromGitter>
<damianham> Thanks everyone for taking the time to consider this and for your responses, much appreciated.
alexherbo2 has quit [Ping timeout: 264 seconds]
<FromGitter>
<watzon> Really what I find coming up again and again is that occasionally I want the Opti n of having a block, without forcing the user to pass a block. Instead what I'm ending up with is a lot of duplicate code because any method I want to do that with I have to make 2 versions of. One with a block and one without.
<jhass>
can you just make the without block version call the with block one with an empty block?
_ht has joined #crystal-lang
<raz>
^ that's exactly what i do every time
<raz>
and agree having &block? would be nicer
<raz>
that's a syntax change i would vote for
<raz>
(the empty-block variant isn't terrible verbosity-wise, but i imagine it also incurs a slight runtime overhead for the empty call)
<oprypin>
you can do this thru macros, but you probably know
zorp has joined #crystal-lang
<raz>
yeh i never tried that. should just be a language feature imho (although not the most urgent one for me personally)
hightower4 has quit [Remote host closed the connection]
<FromGitter>
<naqvis> Yeah make sense to mark that prop as null in output json.
<FromGitter>
<naqvis> it would be neat if primitives or value types can be given default values and reference types as nil (even if they don't include ASR::Serializable) module.
<FromGitter>
<naqvis> and for reference types, you can check if they implement `ASR::Serializable` module, if so then delegate the (de)serializable to that
<FromGitter>
<naqvis> this is how golang handle such cases.
<FromGitter>
<Blacksmoke16> sadly that would also exclude some primitive types, like `Array` or `String`
sz0 has quit [Quit: Connection closed for inactivity]
<FromGitter>
<naqvis> so you think having a kind of cascading effect better here?
<FromGitter>
<naqvis> in your sample case, as Bar is opted for this, so that means all objects inside Bar opt for this?
<FromGitter>
<naqvis> including the Foo
<FromGitter>
<naqvis> this is how Crystal deal with this, but it fails if composed child doesn't respond to `to_json` call
<FromGitter>
<naqvis> and my thought is that, we shouldn't be restricting this functionality in a way current Crystal implementation is doing that
<FromGitter>
<naqvis> take golang as an example
<FromGitter>
<Blacksmoke16> i was doing it on a per type basis, so `Bar` opts in, `Foo` does not
<FromGitter>
<Blacksmoke16> but i cant tell a `String` or `Foo` apart since they both inherit from `Reference`. I suppose i could add some other module/annotation to primitive types, but that seems meh
<FromGitter>
<naqvis> this is because Foos is a value type, but if we change that to reference type, output will show `{"id":1,"foo":null}`
<FromGitter>
<Blacksmoke16> yea i think im fine with this
<FromGitter>
<naqvis> i mean, we should treat Reference types as `null` if that specific type doesn't implement `ASR::Serializable`
<FromGitter>
<naqvis> but for primitives or value types, you can go with default values
<FromGitter>
<Blacksmoke16> just dont have a way to know an actual class from one thats in the stdlib, like string
<FromGitter>
<Blacksmoke16> but having it be null, and paired with exclusion strategies, is fine
<FromGitter>
<naqvis> yeah agree
<FromGitter>
<Blacksmoke16> always can iterate later
<FromGitter>
<naqvis> i mean lib shouldn't be that much strict to raise exception if some obj doesn't implement (de)serializable intf
<FromGitter>
<naqvis> stdlib imo is all or nothing, but we could have gone differently and output what responds to `to_json` and leave others out
<FromGitter>
<naqvis> but i might not have better understanding of decision behind stdlib impl
<FromGitter>
<Blacksmoke16> deserialization side of things deserializes as it builds out the obj
<FromGitter>
<Blacksmoke16> which is a bit diff than how i set things up
<FromGitter>
<naqvis> true and I totally understand
<FromGitter>
<naqvis> during deserialization code can raise exception if something not following the contract
<FromGitter>
<Blacksmoke16> yup
<FromGitter>
<Blacksmoke16> next up is converters, prob use the stdlib approach with class methods on modules, then you can use generics and such
<FromGitter>
<Blacksmoke16> also allower calling setters
<FromGitter>
<naqvis> what if there is no setter defined, will code raise? or just ignore?
<FromGitter>
<Blacksmoke16> sorry, by defaults ivars are set directly
<FromGitter>
<Blacksmoke16> but plan is you can specify a setter, that would get the value if you wanted to do other stuff with it
<FromGitter>
<Blacksmoke16> same idea with getters on serialization, default is use ivar directly, but could go thru getter
<FromGitter>
<naqvis> so rely on init method to initialize all of them?
<FromGitter>
<naqvis> and call setter later (if there are any)?
<FromGitter>
<Blacksmoke16> prob something like that yea, thats how it works yea
<FromGitter>
<naqvis> aah gotcha, sorry I was thinking in terms of `reflection`
<FromGitter>
<naqvis> and I realize crystal doesn't support reflection
<FromGitter>
<Blacksmoke16> so setter stuff is opt in
<FromGitter>
<Blacksmoke16> but default is set ivars directly
<FromGitter>
<naqvis> 👍
<FromGitter>
<Blacksmoke16> setters like that are prob not as common as the default ones made by `property` and such
<FromGitter>
<naqvis> but you would have to call these setters after init is done
<FromGitter>
<nothratal> is there a tendency in the development environment in crystal? What Editor are you using? Is there already something with code completion?
<FromGitter>
<naqvis> yeah true, but good thing is that shard is offering them to call custom setters (if any code has some specific logic need to be run in setter)
<FromGitter>
<naqvis> i mean its always good to offer functionality other than simply making the assumption or enforcing the rules on users of library
<FromGitter>
<naqvis> 👍
<FromGitter>
<Blacksmoke16> essentially im thinking logic in code would be like
<FromGitter>
<naqvis> until unless all of the ivars are initialized in init
<FromGitter>
<Blacksmoke16> mm yea, ill need to think about this more
<FromGitter>
<naqvis> yeah sure
<FromGitter>
<Blacksmoke16> well do i even need this anymore?
<FromGitter>
<Blacksmoke16> given you cant even do it normally, its prob not a big deal
<FromGitter>
<Blacksmoke16> esp with the post deserialize callback
<FromGitter>
<naqvis> i would say no, as you are offering hooks pre/post, so it should be fine
<FromGitter>
<naqvis> i mean needn't to bother with mutators at this stage
<FromGitter>
<naqvis> but for sure, could be great feature left for later versions
<FromGitter>
<naqvis> personally I like your thoughts on providing that mutator methods, as that give impression of kind of reflection
<FromGitter>
<Blacksmoke16> new plan
<FromGitter>
<naqvis> but I also understand, most of the time deserialization would just expect the obj to be created with data populated and dev can call other logics when needed
<FromGitter>
<watzon> What we need is to get something merged into the standard library
<FromGitter>
<naqvis> it was updated recently for Crystal 0.34, so its kind of being updated/maintained
<FromGitter>
<naqvis> i would say at this moment, this would be the best bet if one want to use http2 functionality in crystal 😄
<FromGitter>
<kinxer> Is there a way to run `crystal spec` without control characters in the output (e.g. waiting until all specs have run to output)?
<FromGitter>
<kinxer> That is, terminal control character/sequences.
<oprypin>
kinxer, `export TERM=dumb`
<FromGitter>
<kinxer> Perfect. Thank you.
<FromGitter>
<Blacksmoke16> `--no-color` would prob do it too
<FromGitter>
<kinxer> Since I'm using it on TIO, `--no-color` is actually even better (since I understandably can't just inject env variables into a TIO run).
<jhass>
tried finding a short application of the modulo trick the others have been using but couldn't
<jhass>
the -1 kills it, otherwise it could be slightly shorter
zorp has quit [Ping timeout: 256 seconds]
<sorcus>
Good night :-)
_ht has quit [Quit: _ht]
<FromGitter>
<bew> jhass that tio website is gold, it has the options like footer to put spec, compiler args, etc.. that I always wanted to have on carc.in ^^ I wonder why it's only the first time I've seen it
<jhass>
first for me too, just got it from the codegolf thread above